为什么很多公司在做 PII 脱敏时，选模型反而成了最不重要的事情

最近在对比 Amazon Nova 系列和一些本地开源模型的脱敏表现，结果挺有意思。在一组针对德语 PII（个人可识别信息）的脱敏测试中，Nova Pro 的准确率是 94%，而一个在笔记本上跑的 4GB 开源权重模型跑出了 93%。这意味着，通过 API 调用的云端大模型，在处理这类特定任务时，竟然跟一个本地轻量级模型打平了。

更让我惊讶的是 Nova Micro 的表现，它在准确率上竟然跟专门的 Amazon Comprehend 测了个平手，但单位文档的成本只有后者的二十分之一。而测试中表现最差的，反而是那些专门为德语微调过的模型。

这件事给了我一个很深的启发：在处理 PII 脱敏时，我们习惯性地陷入“模型性能”的内卷，但实际上，真正的瓶颈从来不是模型选哪个，而是你的数据根本不敢往模型里送。

很多团队在设计架构时，习惯性地认为内网权限可以兜底。但现实是，权限边界在业务系统内部是清晰的，可一旦原始数据进入了共享的 RAG 索引，或者被塞进某个 Prompt 模板里，这种边界会立刻蒸发。最糟糕的情况是，生产数据泄露到开发环境几乎是不可避免的——走正规的合规流程可能要审批三天，而通过不合规的快捷方式只要三分钟，一线工程师几乎都会选择后者。

所以，脱敏层必须绝对前置。在数据触达模型之前，就应该先过一遍脱敏逻辑，把具体的身份信息替换成带类型的占位符（例如将具体姓名替换为 [PERSON_NAME]），这样模型在提取结构化信息时，就不需要接触到真实的敏感数据。

针对不同规模的业务场景，我认为脱敏方案的选型逻辑应该是这样的：

如果是个人使用或临时处理小规模文档，完全没必要自己造轮子。如果你有 Claude Enterprise 席位或者使用 Kiro 这种桌面应用，直接加一个 PII 脱敏 Skill 就足够了。在这个量级下，Token 成本几乎可以忽略不计，在这种场景下，模型的上下文判断力远比省几毛钱的 Token 更有价值。

如果是团队级的自动化处理，则需要根据数据驻留要求来选。如果数据允许进入 AWS 环境，Nova Micro 是目前的性价比之王：在德语测试中它有 92% 的准确率，且具备亚秒级延迟，处理十万份文档的成本大约仅为 3.9 美元。如果你追求最高精度，Nova Pro 的德语准确率能达到 94%，但十万份文档的成本会上升到 88 美元左右。虽然它比 Haiku 便宜三分之二，但在决定升级到 Pro 之前，你得确认业务中是否真的存在大量复杂的金融标识符需要处理，否则这就是浪费钱。

当然，如果你的需求是极低延迟且不需要写 Prompt，Amazon Comprehend 依然是强力选手，它提供 100 毫秒级的延迟，且开箱即支持 30 多种实体类型，省去了管理模型版本迭代的麻烦。

总结来看，很多架构师把 PII 脱敏当成一道“算术题”（比较模型准确率和价格），但它其实是一道“架构题”。你应该先把脱敏层独立出来并前置，确保数据流向的合规，然后再去挑选最合适的模型。