一、项目背景

客户是一家省属国资集团，去年在内网做了大模型私有化部署，业务上跑智能客服、合同辅助审查、内部知识问答三条线。跑了半年，模型效果卡在一个不上不下的水平：通用问题答得还行，一碰到集团自己的业务术语和流程就露怯。

他们很清楚问题在哪，也知道解法是拿真实调用日志做迭代。麻烦在于合规。这些日志里什么都有：客服会话里客户报的身份证号和手机号，合同审查里的金额、账号、公司全称，知识问答里偶尔还夹着未公开的人事信息。信息安全部门的态度很明确，原始日志一律不得离开生产环境，更不能进训练集群。

于是就形成了一个死结。业务侧说没有真实数据模型永远好不了，安全侧说数据出不去。我们接手时，这个死结已经卡了三个月，中间试过两个方案都被安全评审打回。

二、落地场景

技术底座是他们已有的 AI 私有化部署环境，模型服务层跑 vLLM，向量库用的 Milvus，我们在这套东西外面加了一层日志治理链路。

链路的第一站放在采集侧，也就是紧贴模型服务的位置。日志在写入任何持久化介质之前先过一道脱敏，这是安全侧的硬要求：磁盘上不能落原始文本。脱敏后的日志进入治理库，原始文本只在内存里存在过。

治理库里的日志会做质量打分，评估这条会话是否适合作为迭代样本。多轮闲聊、模型明显跑偏、用户中途放弃的会话，价值都不高。打分高的进候选池。

候选池的数据再走一遍标注流程，标注员看到的已经是脱敏后的版本。标注完成的样本进训练数据集，用于后续的 LoRA 微调和检索知识库补充。

整条链路上做了权限分层：采集侧只有服务账号能访问，治理库运维可读脱敏后内容，标注员只能看到分配给自己的样本，训练集群只能读不能改。审计日志覆盖每一次数据访问。

三、关键技术挑战与解决思路

敏感实体识别的准确率是第一道关，也是安全评审最较真的地方。漏检一条身份证号，整个方案就可能被否掉。我们没敢只靠一种方法。规则层用正则覆盖强格式实体，身份证、手机号、银行卡、统一社会信用代码这些都有明确校验规则，身份证还能校验末位校验码，误报率低。模型层用了一个轻量的命名实体识别模型，专门抓人名、公司名、地址这类无固定格式的实体。两层结果取并集，宁可多脱不可漏脱。

实际跑起来才发现真正麻烦的是长尾。有用户在客服会话里把身份证号中间加了空格，有人用中文数字写手机号，还有合同里的金额写成"壹佰贰拾万元整"。这些正则全抓不到。我们的处理办法是加了一层归一化预处理，把全角转半角、中文数字转阿拉伯数字、去掉数字间的空格和连字符，再送进识别。这一步把漏检率从千分之三点几压到万分之四以下。这个数字是拿三万条人工标注的测试集跑出来的，评审时他们盯着这个测试集看了很久。

脱敏的可逆性是个绕不开的权衡。不可逆脱敏最安全，但业务排查故障时看到一堆星号什么也定位不了。我们做了分级：身份证、银行卡这类走不可逆哈希，只保留哈希值用于同一实体的关联判断；人名、公司名走可逆的格式保留加密，密钥由安全部门单独托管，业务申请审批后可以临时解密单条记录，全程审计。这个设计是和安全部门来回磨了四轮才定下来的，中间有一版因为密钥管理方案不满足他们的要求被退回重做。

脱敏吞吐一开始也拖了后腿。第一版实现是同步阻塞，模型响应完要等脱敏跑完才返回，把首字延迟拉高了八十多毫秒，业务侧当场就不干了。改成异步旁路后，模型响应直接返回，日志走独立管道处理，对主链路零影响。命名实体识别模型也做了批处理，攒够一批或者超过五百毫秒就触发一次推理，单机吞吐从每秒六百多条提到三千二百条。

案例片段（已脱敏）： 一条归一化预处理救回来的漏检：原始文本 我的证件号是 4401 0119 8506 12 3 45X，直接正则匹配不到，归一化去空格后命中身份证规则，校验位通过，脱敏为 [ID:8f3a...c21]。同一用户在另一次会话里报了完整无空格的同一号码，哈希值一致，系统识别为同一实体并做了会话关联，但两条记录里都看不到明文。 分级脱敏的一段配置意图：身份证与银行卡走不可逆哈希且不保留长度特征；人名走格式保留加密，张伟 加密后仍是两个汉字，便于业务阅读语句结构；金额字段整体替换为区间标签，例如 1200000 替换为 [AMOUNT:百万级]，既保留了语义又不泄露具体数额。

四、效果数据

链路上线运行四个月的数据。敏感信息漏检率在持续扩充的测试集上稳定在万分之四以下，安全部门每月抽检两千条人工复核，累计发现漏检 3 条，都是极端长尾写法，补进规则后未再复现。脱敏吞吐单机每秒三千二百条，集群横向扩展，生产峰值每秒一万一千条无压力。对模型服务首字延迟的影响归零。

数据回流这块，四个月累计沉淀高质量样本约一万八千条，其中一万一千条用于三轮 LoRA 微调，剩余的补进了检索知识库。智能客服的一次解决率从百分之六十一提到百分之七十四，合同审查的关键条款识别召回率从百分之七十九提到百分之八十八。模型迭代周期从原来的"没有周期"变成稳定的两周一轮。以上均为项目复盘口径的脱敏数据。

五、可复用经验总结

合规不是技术方案的约束条件，它本身就是需求的一部分。这个项目卡了三个月，前两个方案被打回，根本原因是把脱敏当成一个功能点来做，而不是把数据全生命周期的合规当成架构目标。第三版我们先画数据流图，标出每一段数据在哪个介质上以什么形态存在、谁能访问，安全部门看完这张图才松口。

脱敏位置要尽量靠前。落盘之后再脱敏，等于承认磁盘上曾经有过明文，审计上说不过去。把脱敏放在采集侧、落盘之前，虽然工程上麻烦一些，但审计逻辑干净。

识别的长尾问题只能靠真实数据喂出来。规则和模型在实验室里都能跑到很高的指标，一上生产就被各种奇怪写法打脸。留好漏检反馈通道，让安全抽检的结果能快速补回规则库，比一开始就追求完美的识别器现实。

可逆性要分级，别搞一刀切。全不可逆业务用不了，全可逆安全不认。按实体的敏感等级分档，配上审批和审计，两边都能接受。

还有一点我想说实话：这类项目的技术难度其实不算高，难的是跟安全部门达成共识的过程。我们前两轮吃亏就吃在没有一开始就把他们拉进设计过程，等做完了再去评审，自然处处碰壁。

附：工程落地细节

归一化预处理是独立的一层，可以单独测试和迭代，不和识别逻辑耦合，这样加新的写法变体不用动主逻辑。命名实体识别模型选的是参数量很小的一个，识别质量够用，关键是延迟低、单机能多开实例。哈希用的是加盐 HMAC，盐值按业务线隔离，防止跨业务线的实体碰撞关联。格式保留加密的密钥走硬件加密机，业务侧的解密申请走工单，单次申请只能解一条，有效期两小时。样本质量打分是个多因子加权，考虑对话轮次、用户是否重复提问、是否触发人工转接、响应是否被点踩，权重每月根据微调效果回调一次。审计日志单独存一套只追加的存储，运维也删不掉。

附：一点实在的提醒

回流数据的质量比数量重要得多。我们中途有一段时间为了凑样本量把打分阈值调低，结果那一轮微调后模型在几个指标上不升反降，回滚重来。后来把阈值调回去，宁可样本少一点。垃圾进垃圾出这个道理谁都懂，但真到了赶进度的时候还是容易犯。