PII Redaction for LLM：大模型应用的敏感信息脱敏策略

这篇文章解决什么问题

LLM 应用会处理用户输入、RAG 文档、工具返回、Trace、评测样本和反馈记录，其中很容易包含手机号、邮箱、身份证、地址、客户名、合同号、API Key、数据库连接串等敏感信息。

PII Redaction 的目标不是简单把所有内容都删掉，而是在尽量保留任务可用性的同时，降低敏感信息进入模型、日志、缓存、评测集和训练数据的风险。

脱敏发生在哪些位置

位置	目的
输入前	防止敏感信息进入模型上下文
RAG 入库时	避免敏感字段被检索和引用
工具返回后	防止工具泄漏过多数据给模型
输出前	防止模型把敏感信息展示给用户
Trace 写入前	防止日志系统成为敏感数据仓库
评测集生成时	防止线上样本泄漏到测试数据
缓存写入前	防止跨用户复用敏感答案

脱敏不是单点能力，而是贯穿 Agent 数据流的防线。

敏感信息分类

类别	示例
直接身份信息	姓名、手机号、邮箱、身份证
业务敏感信息	客户编号、合同号、订单号、工单号
认证信息	API Key、token、cookie、密码
财务信息	金额、银行卡、发票、付款信息
医疗/法律/人事	病历、诉讼、人事评价
内部系统信息	内网地址、数据库名、路径、错误堆栈
训练敏感数据	未授权用于训练的用户内容

不同类型敏感信息的处理策略不同：有的可以 mask，有的应该完全删除，有的只能保留 hash。

脱敏策略

策略	示例	适用场景
Mask	138****8888	展示或日志
Tokenize	USER_123	保留实体一致性
Hash	sha256(value)	去重和追踪
Drop	删除字段	高敏数据
Generalize	北京市朝阳区 -> 北京	地理模糊化
Encrypt	加密存储	需要可恢复场景

对于 Agent 任务，Tokenize 很有用：模型可以知道“同一个客户”但看不到真实身份。

RAG 文档脱敏

RAG 入库时建议：

1. 文档解析后先识别敏感字段。
2. 根据字段类型选择 mask / tokenize / drop。
3. 将原文和脱敏文分开存储。
4. 向量化默认使用脱敏文本。
5. citation 指向用户有权访问的原文。
6. 记录 redaction_version。
7. 权限足够时才允许查看原文。

如果把包含密钥或个人信息的原文直接 embedding，后续很难彻底清除。

工具返回脱敏

工具层应该做字段最小化：

• 查询用户资料时，只返回任务需要字段。
• 查询订单时，隐藏支付账号和地址细节。
• 查询日志时，去掉 token 和内部路径。
• 查询数据库时，限制 SELECT 字段。
• 返回给模型前做 PII scan。

不要让模型自己决定哪些字段敏感。工具服务端应该先处理。

Trace 和评测数据

Trace 最容易被忽略。建议：

• 保存 input_hash，而不是完整用户输入。
• 保存脱敏 prompt，而不是完整 prompt。
• 保存 tool args hash 和摘要。
• 评测集只使用脱敏样本。
• 人工标注平台不展示原始敏感字段。
• 对评测样本记录 redaction_version。

如果要用线上失败样本做评测，必须经过脱敏和授权检查。

脱敏质量评估

指标	说明
pii_detection_recall	敏感信息识别召回率
false_redaction_rate	误脱敏比例
utility_score	脱敏后任务是否还能完成
leakage_rate	输出或日志中泄漏比例
redaction_latency	脱敏耗时
redaction_version_coverage	样本是否记录脱敏版本

脱敏太弱会泄漏，脱敏太强会损害任务效果，需要评估平衡。

面试表达模板

我会把敏感信息脱敏放在 LLM 数据流的多个位置：输入前、RAG 入库时、工具返回后、Trace 写入前、评测集生成时和缓存写入前。不同字段采用 mask、tokenize、hash、drop 或 encrypt。RAG 默认向量化脱敏文本，原文只在权限足够时通过 citation 查看。线上失败样本进入评测集前必须经过脱敏和授权检查，并记录 redaction_version。

常见误区

误区一：只在输出前脱敏

输出前脱敏太晚，敏感信息可能已经进入模型、日志、缓存和评测集。

误区二：脱敏就是正则替换手机号

真实数据里有业务敏感、认证信息、内部路径、合同号等多种类型。

误区三：脱敏后就可以随便训练

训练用途仍然需要用户授权、用途隔离和数据保留策略。

相关链接

• LLM 数据治理
• Agent 审计日志设计
• RAG 知识生命周期
• Agent 租户隔离测试