RAG上下文窗口中的PII泄露：检测、预防与管道设计

一个用户向你的RAG助手询问公司休假政策。系统检索了相关的政策文档，组装上下文并发送给LLM。回答准确且有用。但它也包含了一位人力资源经理的姓名、员工编号和电子邮件地址——这些联系信息嵌入在政策文档中。这就是PII泄露。

通过RAG管道发生的PII泄露并非假设场景。它们每天都在生产系统中发生。RAG的架构——检索文档、注入LLM提示词、生成回答——在多个环节创造了个人身份信息进入上下文窗口并最终出现在面向用户的输出中的可能性。LLM不知道什么是敏感信息。它平等地对待上下文中的每一个token。

本文映射了RAG管道中PII可能泄露的每一个环节，解释了每种泄露发生的原因，并提供了一个实用的预防框架。

RAG管道中的PII泄露面

一个标准的RAG管道有六个阶段。PII可以在其中五个阶段进入和泄露。

阶段1：文档摄入 源文档被加载到管道中。PDF、Word文档、电子邮件、数据库导出、工单、CRM记录。

PII风险：源文档经常在设计上就包含PII。人力资源文档有员工姓名和社会安全号码。工单有客户电子邮件和电话号码。CRM导出有联系方式。医疗记录有患者标识符。文档本身就是PII。

阶段2：解析和提取 文档被解析为文本。扫描文档使用OCR。电子表格进行表格提取。标题和属性进行元数据提取。

PII风险：解析器提取所有内容，包括嵌入在页眉、页脚、元数据字段和水印中的PII——这些是人类读者可能都不会注意到的。PDF的元数据可能包含作者的全名和电子邮件。Word文档的修订历史可能包含每个编辑过它的人的姓名。

阶段3：分块 解析后的文本被分割成块用于嵌入和检索。

PII风险：分块不加区分。如果文本中有PII，它就会出现在分块中。一个包含政策声明的分块也会包含出现在同一段落中的任何员工姓名、电话号码或电子邮件地址。

阶段4：嵌入和存储 分块被嵌入为向量并与原始分块文本一起存储在向量数据库中。

PII风险：向量数据库存储每个分块的原始文本用于检索。这创建了一个PII数据存储，可能不受与源系统相同的访问控制约束。你的向量数据库现在是源文档中每一条PII的副本。

阶段5：检索和上下文组装 用户查询触发向量搜索，top-k分块被组装到LLM提示词中。

PII风险：检索基于语义相似性，而非访问控制。关于"员工福利"的查询可能检索到包含某个特定员工福利注册详情的分块，包括其姓名、出生日期和家属信息。检索系统不会检查查询用户是否有权查看该员工的数据。

阶段6：LLM生成 LLM基于上下文生成回答。

PII风险：LLM将上下文中的PII包含在其回答中。它没有什么是敏感信息的概念。如果上下文包含一个电话号码，且该号码与答案相关，LLM就会将其包含在内。

常见的PII泄露场景

以下是我们在生产中最常见的场景：

场景1：热心的联系人。 政策文档包含"如有疑问，请联系Jane Doe，邮箱jane.doe@company.com或分机4521。"RAG系统检索到政策分块，LLM热心地在每个关于该政策的回答中包含Jane的联系信息——即使用户没有请求。

场景2：模板中的示例。 一个表单模板包含示例数据："姓名：John Smith，SSN：123-45-6789，出生日期：01/15/1980。"示例数据本意是展示如何填写表单。RAG系统将其视为真实数据，并在相关查询中检索到它。

场景3：知识库中的邮件线程。 一个支持团队将其电子邮件历史索引用于RAG。邮件包含客户姓名、电子邮件地址、订单号，有时还有明文支付详情。每个检索到的邮件分块都可能包含客户PII。

场景4：看似脱敏实则未脱敏的PDF。 一个文档通过在PDF查看器中用黑色矩形覆盖敏感文本来"脱敏"。底层文本从未被删除。PDF解析器提取了视觉遮挡下方的文本，本应脱敏的PII进入了RAG管道。

场景5：多租户系统中的跨租户数据。 一个SaaS产品为所有租户使用共享的向量数据库。租户A的查询检索到了租户B的文档分块，因为检索层没有强制执行租户隔离。租户B的员工姓名和内部数据出现在租户A的回答中。

脱敏关卡的放置位置

PII预防需要在管道的特定位置设置脱敏关卡。单一关卡是不够的——需要纵深防御，因为没有单一的脱敏技术能捕获所有情况。

关卡1：分块前脱敏（主要防线）

位置： 文档解析之后，分块和嵌入之前。

功能： 扫描完整的解析文本以查找PII模式，并在文本进入分块管道之前删除、掩码或替换检测到的PII。

检测技术：

• 结构化PII的正则表达式模式（社会安全号码、电话号码、电子邮件地址、信用卡号码）
• 命名实体识别（NER）用于姓名、组织和地点
• 领域特定标识符的自定义字典（员工编号、患者MRN、账号）

脱敏策略：

• 删除： 完全删除PII（"联系Jane Doe，分机4521"变为"联系"）
• 掩码： 用占位符token替换（"联系[人名]，[电话分机]"）
• 泛化： 用类别标签替换（"联系人力资源代表"）

为什么这个关卡最重要： 一旦PII作为分块文本的一部分进入向量存储，删除它需要重新索引整个受影响的语料库。在PII被分块和嵌入之前捕获它，比之后捕获要经济得多。

关卡2：分块级审计（次要防线）

位置： 分块之后，嵌入和存储之前。

功能： 扫描每个单独的分块以查找通过关卡1的PII。这会捕获在文档中碎片化分布、只有在分块中重新组装后才能被识别的PII，或第一个关卡的检测规则遗漏的PII模式。

存在原因： 没有任何PII检测系统具有100%的召回率。关卡2使用可能不同的检测规则提供第二轮检查（例如，更激进的正则表达式集、不同的NER模型，或对高敏感文档的人工审核）。

关卡3：检索时过滤（第三防线）

位置： 向量搜索返回候选分块之后，上下文组装之前。

功能： 在检索到的分块被组装到LLM提示词之前扫描其中的PII。如果检测到PII，分块要么被实时脱敏，要么被排除在上下文之外。

权衡： 这个关卡为每个查询增加了延迟。它也意味着PII仍然存在于向量存储中——只是在读取时被过滤。出于合规目的，如果法规要求PII根本不能存储在向量数据库中，这可能是不够的。

何时使用： 作为与关卡1和2配合的安全网，或在你继承了一个在没有PII脱敏的情况下索引的向量存储且无法立即重新索引的情况下。

关卡4：输出过滤（最后手段）

位置： LLM生成之后，回答展示给用户之前。

功能： 扫描LLM生成的回答中的PII模式，并在展示前进行脱敏。

局限性： 这个关卡无法阻止LLM看到PII——它只能阻止用户在回答中看到PII。PII仍然被发送到了LLM API，这可能违反数据处理协议。如果你使用的是第三方LLM API，在这个关卡触发时PII已经离开了你的环境。

何时使用： 作为双重保险措施，绝不能作为主要防线。

检索中的访问控制

PII脱敏是必要的但不充分的。即使PII已被脱敏，检索仍应尊重文档级的访问控制。标记为"人力资源机密"的文档不应被普通员工的查询检索到，即使其分块中的所有PII已被删除。

在检索层实现访问控制：

• 基于元数据的过滤： 在索引时为每个分块标记访问控制元数据（部门、分类级别、租户ID）。根据查询用户的权限为每个检索查询添加强制过滤器。
• 命名空间隔离： 为不同的访问级别使用单独的向量存储命名空间或集合。普通用户的查询只搜索普通命名空间。
• 行级安全： 如果你的向量数据库支持，实现行级安全策略来限制给定用户可以检索哪些分块。

实用实施检查清单

在构建或审计RAG管道的PII安全性时使用此检查清单：

1. 盘点你的源文档。 哪些文档类型包含PII？什么类型的PII？在构建管道之前创建PII数据地图。
2. 实施关卡1（分块前脱敏）。 这对于处理可能包含PII的文档的任何管道都是不可协商的。
3. 用真实文档测试脱敏。 合成测试文档不包含你真实文档中的PII模式。用实际（或逼真的）数据进行测试。
4. 验证存储分块中的脱敏。 索引后，从向量存储中抽样分块并手动检查是否有幸存的PII。
5. 实施访问控制元数据。 为分块标记访问级别并在检索时强制执行过滤。
6. 添加关卡3（检索时过滤）以实现纵深防御。 在修复之前缺乏脱敏的管道后的过渡期尤其重要。
7. 记录和审计。 记录处理了哪些文档、检测到并脱敏了什么PII、以及哪些分块被提供给了哪些用户。这个审计轨迹对合规至关重要。
8. 用对抗性查询测试。 尝试通过设计用于获取敏感信息的问题来检索PII。"谁负责福利注册？"不应返回特定人员的姓名——如果该姓名本应被脱敏的话。
9. 安排定期PII审计。 初始管道设置后摄入的新文档可能包含你的检测规则未涵盖的PII模式。至少每季度审计一次。

为什么管道架构很重要

RAG系统中的大多数PII泄露不是由复杂的攻击造成的。它们是由于没有人在正确的位置放置脱敏关卡而导致PII进入管道造成的。管道的构建目标是优化检索质量——解析、分块、嵌入、检索——而PII处理是事后才想到的，或者在原型阶段完全被跳过且在投入生产前从未添加。

Ertas Data Suite包含一个PII Redactor节点，它位于可视化管道画布上解析和分块之间。当你在Ertas中构建RAG索引管道——文件导入、解析器、PII Redactor、RAG Chunker、嵌入、Vector Store Writer——脱敏关卡是一个可见的、可审计的阶段。你可以检查脱敏器检测到的内容、审查边界情况，并在脱敏后的分块到达向量存储之前验证其是否干净。

脱敏不是隐藏在工具函数中的。不是某人必须记住要运行的后处理脚本。它是画布上的一个节点，具有记录的输入和输出，精确地放置在管道中它需要在的位置。

当你的合规团队问"PII在哪里被脱敏的？"时，你可以向他们展示管道。当审计员问"你能证明PII在存储之前被删除了吗？"时，你有日志。这就是将PII预防作为设计原则与将PII预防作为事后补救之间的区别。

监管现实

GDPR第5条要求数据最小化——仅收集和处理为指定目的所必需的个人数据。HIPAA要求在将受保护的健康信息用于治疗、支付或运营以外的目的之前对其进行去标识化。欧盟AI法案对处理个人数据的高风险AI系统施加透明度义务。

一个摄入包含PII的文档、将PII存储在向量数据库中、发送给第三方LLM API并展示给未授权用户的RAG管道，同时违反了多项法规的多个条款。罚款不是理论上的——GDPR执法已经征收了数十亿欧元的处罚。

RAG管道中的PII脱敏不是锦上添花。它是处理包含个人数据文档的任何系统的合规要求。从一开始就将关卡建入管道中。在数据泄露之后再进行改造在各个方面都更加昂贵。