在企业知识库和智能问答系统中，文档常常包含大量敏感信息：员工个人信息、客户联系方式、合同金额、商业机密等。如果这些内容不加处理直接进入检索和生成环节，轻则导致内部信息不当扩散，重则违反 GDPR、个人信息保护法、行业合规要求，带来严重法律风险。因此，RAG 系统在落地时，必须将敏感信息脱敏与合规处理作为一项刚性能力，而非事后补丁。
1. 脱敏的必要性
RAG 系统可能从两个层面暴露敏感信息：
- 检索结果直接包含敏感原文：如果知识库切片中留有身份证号、电话号码、银行卡号等，这些内容可能直接出现在给 LLM 的上下文中。
- 生成回答复述敏感内容：模型可能根据检索到的片段，直接将这些信息编织进回答，展示给没有对应权限的用户。
即使系统仅面向内部员工，也应遵循“最小必要原则”，确保回答中不会泄漏与当前问题无关、或用户无权查看的信息。对于需要审计留痕的场景，回答本身还需避免包含任何凭据或隐私数据，否则日志就可能成为新的泄露点。
2. 常见脱敏策略
在实践中，可以采用分层、分阶段的脱敏机制，覆盖入库前、检索后和生成后三个关键节点。
入库前
在文档切片、向量化之前，对原始内容进行自动识别和脱敏处理，这是最根本的一道防线。常用手段包括：
- 规则匹配：使用正则表达式识别身份证号、手机号、邮箱、银行卡号等标准格式字段，替换为脱敏标记，例如“张[已脱敏]”、“138**1234”。
- 命名实体识别（NER）：用轻量级模型识别人名、地名、组织名等，根据需要对特定类型实体进行泛化，如将具体姓名替换为“客户甲”。
- 敏感词与关键字过滤：维护一份敏感词表，扫描文档中包含商业机密、内部代号、未发布产品名等内容，进行模糊化或拦截。
这些处理后的文档才进入向量库，确保检索到的片段已经是安全的。
检索后
对检索结果再次进行防护，以防入库时漏掉的敏感信息进入模型视线。可以在检索服务中加入一层脱敏过滤器，对送入 LLM 的每个 chunk 做二次扫描，匹配敏感信息模式，发现即替换或丢弃该片段。
生成后
即使前两个环节已过滤，仍建议对模型最终回答进行敏感信息扫描，防止模型从非敏感内容中“推断”出敏感信息（概率很低，但合规检查应严守）。此外，也可以在生成接口外挂过滤器，阻止含有疑似敏感内容的回答返回给用户，或替换为安全提示。
3. 合规处理要点
除技术脱敏外，还需从流程和权限上确保合规：
- 文档分类与权限标签：对知识库文档标记密级（公开、内部、机密等），在检索时根据用户角色过滤可访问片段。例如，普通员工无法检索到薪酬结构相关文档。
- 访问审计与日志脱敏：记录所有提问和回答，但日志中不得保存脱敏前的原始敏感数据。回答中的脱敏标记应保持一致，确保审计可追溯但内容不泄露。
- 模型使用合规：如果使用第三方大模型 API，必须确保检索内容在传输过程中加密，且服务商承诺不将数据用于训练。对于极高密场景，应考虑本地部署模型。
- 数据留存与删除：遵循数据最小化原则，设定合理的日志保留期限，支持按需删除或匿名化处理。
4. 与 RAG 流程的无缝结合
RAG 架构的切片和检索链路为脱敏提供了天然插入点，无需大幅改动现有系统。一个典型增强流程是：
- 文档上传后，首先经过脱敏预处理，生成清洁版本；
- 清洁文档进行切片、向量化并入库；
- 检索时，根据用户角色过滤可检索的向量范围；
- 生成回答后，再经过一轮轻量脱敏校验；
- 答案及出处返回给用户，同时审计日志记录脱敏后的问答对。
5. 真实实践建议
- 先做减法：初期不必追求完美脱敏，从最明显的正则模式开始，逐步加入 NER、角色权限，避免一开始过度复杂化。
- 脱敏而不失可读性：标记方式要保持回答通顺。例如将“张三，身份证 110101199001011234”替换为“张先生，身份证已省略”，比变成一串“*”更友好。
- 定期扫描更新：敏感信息类型会随业务变化增加（如新增医疗数据、生物特征），需要定期更新脱敏规则和词表。
- 测试验证：准备一组包含各种敏感示例的测试文档，定期运行端到端测试，确保脱敏各环节未失效。
通过上述措施，RAG 系统可以在提供高效知识服务的同时，守住信息安全和合规底线，避免“便捷”与“风险”失衡。