一、先划清边界：这套服务到底解决什么问题

部署对象不是单个模型文件，而是一组围绕”敏感信息不离开本地、云端只处理脱敏结果”协同工作的组件：隐私过滤服务、策略引擎、记忆治理服务、占位符与映射管理、审计与监控。

核心结论前置：这套服务的成败不取决于模型识别能力，而取决于三件事——策略是否版本化可回滚、脱敏结果是否不可重识别、审计日志是否本身干净。

适用边界：适用于以文本为主的中文/多语言长期记忆与个性化对话场景，端侧具备轻量推理能力。不适用于需要云端直接处理原始图像、语音波形或需要明文回填的强合规链路——这类场景应改为端侧闭环处理。

验收标准应满足：端侧完成敏感实体识别与替换；云端只落库脱敏文本、摘要与向量；还原需授权+审计；全链路可观测；支持灰度与回滚。

二、你会遇到哪些落地场景

用户担心”我的偏好被云端记住会不会泄露”？——端云协同个性化助手
端侧识别手机号、邮箱、地址、证件号、账号字段并替换为占位符，云端模型只处理占位符版本，上下文语义保留而明文不外流。

企业知识库里混着客户名和合同条款怎么办？——知识库智能问答
提问到达模型前经过隐私过滤；需长期保存问答记录时，只保存脱敏后内容。

多轮对话的历史记忆能不能直接存？
不能。写入前做实体识别、分类分级、占位符替换；检索只返回脱敏版本，必要时走授权还原。

终端算力不够、云端策略又在变，端云结果不一致怎么办？
端侧做正则、词表与轻量模型初筛；云侧做复杂语义复核。必须设计端云协议、策略版本同步与降级策略，保证端侧不可用时系统仍安全运行（宁可过度脱敏，不可放行明文）。

三、四层架构与关键模块

层级	主要职责	关键组件
端侧预处理层	输入采集、基础规则与轻量模型识别、本地脱敏	词表、轻量模型、本地脱敏模块、策略缓存
云侧隐私治理层	实体复核、生成占位符、策略标签、审计记录	过滤服务、策略引擎、实体识别模型、映射管理
记忆存储与检索层	保存脱敏记忆，支持检索、更新、删除、生命周期	记忆库、向量检索、对象存储、元数据表
网关与审计监控层	鉴权、限流、路由、日志、指标、告警	网关、日志服务、监控告警、访问控制

关键模块要点

1. 隐私识别模块：规则引擎处理格式明确数据（证件号、卡号的校验位可判真伪），模型推理处理上下文模糊的敏感表达。两者结果需带 rule_id 与 model_version。
2. 占位符替换模块（重点）：占位符必须保留语义可读性，但不要建议使用普通哈希摘要——手机号、证件号取值空间小，MD5/SHA256 可被彩虹表或暴力枚举直接反推。正确做法：
   • 使用密钥化伪随机函数（如 HMAC-SHA256）加随机盐，密钥托管在 KMS，按环境隔离并定期轮换；
   • 占位符采用 {{type}}_{{seq}} 这类不携带原值的序号形式，原值-占位符映射表单独存放并静态加密；
   • 映射表访问走独立服务与独立凭据，禁止业务服务直读，任何读取都落审计；
   • 重识别风险评估：统计单用户可区分占位符数量、结合时间戳与设备指纹判断准标识符组合是否可反推身份；对高基数准标识符（罕见地址、罕见病史）额外做泛化或抑制。
3. 策略引擎：策略版本化，支持灰度与回滚，每条命中都记录 policy_version。
4. 记忆治理：设置保留周期、过期清理、用户删除与授权撤销，长期记忆不得无限增长。
5. 审计与监控：只记录请求标识、命中类型、结果摘要与异常码，不记录请求正文。

四、资源规划：给一组可直接套用的最小公式

计算资源估算（云侧推理）

• 峰值所需并发：C = QPS_peak × t_infer(s)
• 实例数：N = ceil( C / (b × U) )，其中 b 为单实例可稳定承载的并发（含批处理大小），U 为目标水位，建议 0.6–0.7
• 显存：VRAM ≈ 权重字节 + KV_cache + 激活开销，再乘 1.2 安全系数

示例：峰值 QPS 20，单请求约 800 tokens，实测 t_infer(P95) ≈ 0.18s → C = 3.6；单实例稳定并发 b = 8，U = 0.7 → N = ceil(3.6/5.6) = 1，考虑冗余与滚动更新取 2 实例。若改用 7B 级模型 FP16：权重约 14GB，KV cache 约 0.5MB/token，1024 token × batch 8 ≈ 4GB，加激活与框架开销 → 约 20GB，应选 24GB 显存规格。

注意：以上为估算示例，t_infer 与 b 必须以你的模型、量化方式和序列长度实测替换，不可直接引用。

端侧资源：优先保证低延迟与内存占用，轻量模型建议常驻内存，词表用前缀树或 Aho-Corasick，策略缓存设置过期时间与签名校验。

存储与日志容量：日志字节/天 ≈ QPS_avg × 86400 × 单条日志字节 × 副本数 × 冗余系数(1.5)。审计日志保留期按合规要求定，监控指标短周期保留、异常样本长期保留。

规划时必须评估的指标：平均 QPS、峰值并发、平均/最长文本长度、模型推理耗时、规则匹配耗时、数据库读写频率、日志采集频率、重试带来的额外负载。

五、前置准备与安全合规检查清单

1. 明确隐私边界：个人身份信息、联系方式、证件号、账号凭证、地址、健康状态、财务信息、企业内部标识、用户声明不愿被记录的内容。无法自动判定的，默认走脱敏（保守策略）。
2. 运行环境：应用运行时、推理环境、规则引擎依赖、配置中心、日志与监控采集、数据库客户端、对象存储 SDK；容器化部署需固定镜像 digest、启动参数、健康检查地址、资源限制。
3. 资源配额：计算实例、推理资源、数据库连接数、对象存储与日志容量、带宽与负载均衡、备份空间，生产预留余量。
4. 配置与密钥：配置文件中不得出现明文密钥，敏感配置走环境变量或密钥管理服务注入。
5. 网络策略：仅开放必要路径，数据库、对象存储管理接口、模型管理接口不得暴露公网。
6. 测试数据：明确敏感、边界敏感、非敏感、多实体混排、长文本、短文本、特殊字符、多语言、异常与恶意构造样本。
7. 安全合规检查清单：用户删除请求是否在所有副本、向量索引与备份中同步生效；授权撤销是否立即使还原接口失效；跨地域留存是否有清单与数据流向图；审计日志最小字段（request_id、主体、动作、policy_version、结果码）是否齐备；保留周期到期是否有清理任务与成功率指标；导出与备份是否加密并纳入访问审批。
8. 回滚方案：保留旧版本镜像、旧策略包、旧配置与数据库变更脚本。

六、部署流程：每步的输入、动作与通过标准

步骤一 初始化基础环境：创建计算资源、网络、数据库、对象存储、日志与监控入口、负载均衡。通过标准：网络连通性、权限与配额核验全部通过。

步骤二 上传或构建应用包：镜像与模型文件带版本号并校验完整性（记录 sha256），生产与测试使用不同配置。通过标准：校验和与版本清单一致。

步骤三 部署依赖组件（含版本矩阵与失败退出）

先固化依赖版本矩阵，例如：数据库驱动 major.minor、缓存客户端版本、模型文件 digest、词表版本、策略包版本、SDK 版本；任一版本不符即中止部署，禁止”先起来再说”。

就绪检查（任一项失败即 exit 1，不进入步骤四）：

set -euo pipefail
nc -z db.internal 5432                    # 数据库端口可达
redis-cli -h cache.internal ping | grep -q PONG
curl -fsS https://oss.internal/health >/dev/null   # 对象存储可达
curl -fsS http://infer.internal/v1/ready  # 模型推理服务已加载完成
sha256sum -c model.sha256                 # 模型文件完整性

步骤四 配置隐私策略：实体类型、置信度阈值、占位符模板、脱敏级别、是否允许云端还原、角色可见记忆粒度、日志详细度、异常输入处理。策略包版本化，先在灰度环境验证。

步骤五 启动隐私过滤服务（含探针与就绪判定）

startupProbe:      { httpGet: { path: /healthz, port: 8080 }, failureThreshold: 30, periodSeconds: 5 }
readinessProbe:    { httpGet: { path: /readyz,  port: 8080 }, failureThreshold: 3,  periodSeconds: 5 }
livenessProbe:     { httpGet: { path: /healthz, port: 8080 }, failureThreshold: 6,  periodSeconds: 10 }

启动探针用于覆盖模型加载耗时，未就绪前流量不得进入。就绪判定：curl -fsS localhost:8080/readyz 返回 200 且 body 中 model_loaded=true、rules_loaded=true、policy_loaded=true、db_pool=ok。

失败退出条件：模型加载超时、词表校验失败、策略配置解析失败、任一依赖连接池初始化失败、/readyz 连续 3 次返回非 200 —— 均判定启动失败并退出，不允许带缺陷实例承接流量。

步骤六 启动记忆治理服务：校验数据库连接池、写入/读取/删除测试、过期策略生效、脱敏记忆可检索、审计日志完整。

步骤七 配置服务网关：访问地址、鉴权方式、限流、请求体大小上限、超时、错误响应格式、健康检查路由、访问日志字段。网关禁止记录请求正文。

步骤八 小流量开放：域名解析、证书、访问控制、名单规则、限流阈值、告警全部确认后再放量。

步骤九 灰度发布：观察识别准确率、误报率、P95 延迟、错误率、资源水位、日志异常、数据库写入成功率；指标异常立即停止扩量并回滚。

步骤十 全量上线与持续观察：服务稳定性、脱敏正确性、误删非敏感内容、用户侧空结果、个性化效果是否退化、审计完整性、资源水位。

七、配置说明：参数、推荐区间与调优口径

privacy_policy:
  entity_types: [phone, email, address, credential, health, internal_id]
  confidence_threshold: { credential: 0.95, phone: 0.85, address: 0.85, email: 0.80, health: 0.88, internal_id: 0.75 }
  placeholder_template: "{{type}}_{{seq}}"
  placeholder_hash: { algo: hmac-sha256, key_ref: kms://privacy/ph_v1, salt_rotation_days: 90 }
  allow_cloud_restore: false
  require_audit_on_restore: true
service: { port: 8080, timeout_ms: 1200, retry_times: 1, max_request_bytes: 1048576 }
memory_store: { retention_days: { raw_text: 7, masked_text: 30, vector: 30 }, encrypt_at_rest: true, allow_user_delete: true }
audit: { log_level: info, include_raw_sample: false, raw_sample_rate: 0.01, retention_days: 180 }

参数	推荐区间	测量口径	调优方向
confidence_threshold	凭证/证件 0.90–0.95；手机号、地址 0.80–0.88；内部标识 0.70–0.80	分类型统计 Precision/Recall；误报率=误报数/非敏感样本数，漏检率=漏检数/敏感样本数	高敏感类型宁可高召回；低敏感类型可提阈值减少语义损伤
retention_days	原文 7 天、脱敏文本与向量 30–90 天、审计 ≥180 天	查”最旧未清理记忆时间戳”与清理任务成功率	按业务用途与合规要求定，不得默认永久保留
include_raw_sample	默认 false，开启需审批且 ≤24h、采样 1%–5%	统计开启时长、访问主体与访问次数	仅用于疑难漏检定位，用完即关

阈值调优方法：构建分层标注测试集，每类型 200–500 条（含明确敏感、边界敏感、非敏感、易混淆负例），人工标注金标；在 0.60–0.98 区间以 0.02 步长扫描阈值，绘制 Recall-误报率曲线，选取”误报率满足业务上限前提下 Recall 最大”的拐点，而非直接看总体 F1。每次调参必须记录 policy_version 与对应测试集版本，便于回归比对。

八、上线验证：可执行用例表

用例ID	样本类型	输入要点	预期占位符	预期命中规则ID	通过标准	负责人
TC-01	明确敏感	完整手机号	phone_1	R-PH-001	替换且原值不出现在日志	应用开发
TC-02	多实体混排	姓名+邮箱+地址	email_1,addr_1	R-EM-002,R-AD-003	全部命中、顺序稳定	应用开发
TC-03	长文本	>4000字，敏感词在尾部	正确替换	R-*	无截断漏检	算法
TC-04	边界样本	疑似证件号但无校验位	保守脱敏	R-ID-005	走保守策略而非放行	算法
TC-05	非敏感负例	普通产品名、版本号	不替换	—	误报率 ≤ 目标值	算法
TC-06	异常输入	超长、空体、非法编码	安全拒绝	—	返回标准错误码，服务不崩	运维
TC-07	越权还原	无授权调还原接口	—	—	403 且记审计	安全
TC-08	用户删除	删除后检索	—	—	原文、向量、缓存均不可检索	运维

另需完成可用性、性能（平均与 P95 延迟、连接池无耗尽、队列无持续积压）、指标看板（脱敏成功率、漏检、误报、还原请求数、资源利用率）与回滚演练验证。

九、常见问题与排查：带上定位字段再查日志

统一在日志与审计中携带：request_id、trace_id、session_id、policy_version、model_version、rule_id、entity_type、stage（edge/masked/audit）、result_code。缺少这些字段，线上问题几乎无法定位。

日志检索示例（字段化存储，按 request_id 取全链路）：

request_id:"req-8f21c" → 取 edge/masked/audit 三段记录，比对命中类型与占位符编号
count(policy_version="pv-2026071" AND result_code="miss") by entity_type   # 分类型漏检趋势
percentile(90, duration_ms) by model_version                              # 版本间延迟对比

问题	常见原因	排查动作	告警阈值示例
敏感信息漏检	词表不全、阈值过高、领域术语未覆盖、长文本截断、端侧漏筛且云侧未复核	按 entity_type 拆漏检率；降阈值观察误报；补词表；关键类型强制云侧复核	分类型漏检率 >0.5% 持续 5 分钟告警
误报率过高	阈值过低、规则过宽、缺白名单、占位符破坏语义	提阈值、缩规则范围、加业务白名单、低风险类型改为提示	误报率 >3% 或个性化命中率下降 >10%
端云结果不一致	模型版本不同、策略未同步、词表过期、传输截断	统一版本号；策略版本化下发；端侧抽样云侧复核；加请求标识做链路追踪	抽样不一致率 >1% 阻断策略下发
启动失败	模型缺失、配置格式错、依赖不通、端口占用、配额不足	看启动日志；跑步骤三检查脚本；最小配置启动验证	就绪探针连续 3 次失败即告警
推理延迟过高	模型过大、并发过高、批设置不合理、写入阻塞	扩推理资源；缩短单次文本；审计与记忆异步写；结果缓存	P95 > 800ms 或队列积压 >1000 条
记忆污染	脱敏过度丢个性化信息、错误策略写入、回滚后旧记忆残留、删除未同步	启用记忆版本与审计；关键策略变更走灰度；保留人工纠偏入口	用户删除同步失败 >0 次即告警

十、运维与优化

稳定性：健康检查、自动重启、超时控制、重试限制、限流、熔断降级、灰度与回滚。隐私过滤在主链路上，云侧模型不可用时应降级为端侧规则脱敏或保守脱敏，严禁直接放行明文。

告警阈值建议：分类型漏检率 >0.5%、误报率 >3%、P95 延迟 >800ms、错误率 >1%、队列积压 >1000 条或持续增长 5 分钟、还原请求量环比激增 3 倍、审计写入失败 >0 条、清理任务失败即告警；回滚触发条件为”漏检类告警 或 错误率 >5% 持续 5 分钟 或 核心功能不可用”。

安全控制：最小权限、密钥轮换、传输与静态加密、访问白名单、审计日志保护、还原审批、日志脱敏。

性能与成本：规则与结果缓存（缓存键须包含 policy_version，避免跨版本串味）、长文本分段、推理批处理、数据库异步写入、向量索引优化、低峰缩容、日志生命周期、过期记忆自动清理。任何优化不得以牺牲脱敏正确性为代价。

可维护性：策略、模型、配置三类版本管理；变更审批、灰度流程、回滚预案、指标看板、定期演练与审计抽查。

十一、总结

真正的交付物是”端侧初筛、云侧复核、密钥化占位、受控还原、全程审计”的工程闭环，而非一个开关。落地时优先解决五件事：按 QPS 与延迟公式定量规划资源；固化依赖版本矩阵与失败退出条件；占位符使用密钥化哈希并严控映射表访问；策略阈值以标注测试集的分类型 Precision/Recall 为依据而非拍脑袋；所有日志与审计携带 request_id、policy_version、model_version、rule_id 以支撑分钟级定位。在此基础上配合灰度发布与明确的回滚触发条件，才能在保住个性化能力的同时把敏感信息泄露风险压到可控范围。