GDPR 的删除难题：为什么你的 LLM 记忆存储是法律风险

大多数构建 RAG 管道的团队对 GDPR 的理解方式是错误的。他们关注推理调用——模型是否生成了 PII？——却忽略了静静地藏在向量数据库中的更严重的风险敞口。每当用户提交一份文档、一张支持工单或一条个人笔记，经过分块、嵌入和索引后，该向量存储在 GDPR 下就成为了个人数据处理器。当用户行使被遗忘权时，"按 ID 删除"并不能解决问题。

被遗忘权不仅仅是从关系型数据库中删除一行数据。由个人数据派生的嵌入向量携带着可恢复的信息：研究表明，句子级嵌入中 40% 的敏感数据可以用简单代码重建，对于较短文本，这一比例高达 70%。派生的表示形式是个人数据，而非经过净化的抽象。GDPR 第 17 条适用于此，监管机构正在密切关注。

为什么向量数据库的设计不考虑删除

近似最近邻搜索的主流范式将向量视为索引后基本不可变的数据。FAISS——为大多数早期向量搜索基础设施提供动力或灵感的库——没有原生的删除操作。删除一个向量意味着重建索引或维护单独的阻止列表——如果删除比例超过索引的 10–15%，查询质量就会下降，直到从头重新索引。

即使是后来添加了删除功能的数据库，通常也将其作为软操作实现：在元数据中将向量标记为已删除，在查询时过滤掉，定期压缩。从性能角度来说，这是正确的技术权衡，但它有一个具体的法律含义：至少在下一个压缩周期之前，用户行使被遗忘权后，数据仍物理存在于存储中。墓碑标记的记录是否满足第 17 条的要求存在真正的争议，大多数数据保护机构尚未发布明确指导。

Pinecone 支持通过单个 API 调用进行基于元数据的删除，对于命名用户来说效果很好。但无服务器 Pinecone 索引根本不支持按元数据删除——只支持按 ID 前缀删除——这意味着你需要在摄入时维护从用户身份到向量 ID 的映射。如果没有做到，删除将成为全表扫描操作，甚至更糟。

更深层的问题不是 API 表面，而是大多数团队在没有用户级隔离的情况下，将数据摄入共享命名空间。当用户要求被遗忘时，如果他们的数据与其他所有人的数据共存于一个扁平索引中，就无法干净地删除他们的向量。

三种真正有效的架构模式

存储层的用户范围命名空间

最可靠的 GDPR 兼容架构是在索引时而非检索时，在物理或逻辑层面分离用户数据。在查询时进行过滤（传递 where user_id = X 条件）并不满足被遗忘权——数据仍然存在。分离必须发生在存储层。

Weaviate 的多租户模型为每个租户提供专用分片：独立的倒排索引、向量索引和元数据桶。删除租户相当于删除一个文件。该系统支持每个集群超过一百万个并发活跃租户。Qdrant 通过带有每租户访问控制的载荷级分区采用了类似方法。如果在架构设计时采用，两种方法都有效。将命名空间隔离改造到共享索引上代价高昂。

实践要求：在摄入时，用来源用户的标识符标记每个向量，并将其路由到用户范围的分区。这在写入时增加了开销，并使跨用户聚合查询变得复杂，但它使删除请求无需维护单独的 ID 映射层即可处理。

嵌入前脱敏

解决删除问题最简洁的方案是一开始就不嵌入个人数据。Tonic.ai 的研究表明，在嵌入前对敏感内容进行脱敏，可以使所得向量的敏感数据恢复率达到 0%，而直接嵌入原始文本时恢复率为 40–70%。事后无法"取消嵌入"姓名或地址；可以防止其进入索引。

嵌入前脱敏通过扫描摄入内容中的 PII 模式——姓名、地址、标识符、财务数据——并在嵌入调用前用确定性占位符标记替换它们来实现。"John Smith 的账户余额为 4200 美元"变为"[PERSON_001] 的账户余额为 [AMOUNT_001]"。嵌入捕获语义结构，而不编码可恢复的个人数据。

确定性标记化在这里至关重要。随机匿名化会破坏跨文档的引用完整性；同一实体应在会话或语料库中始终映射到同一标记，以确保检索仍能正确工作。多个隐私工程库实现了这一点，值得将管道构建为在嵌入前调用它们，而不是作为事后补充。

这种方法需要前期投入于 PII 检测，以处理你的特定数据类型。现成的基于正则表达式的扫描器会遗漏很多内容；使用带有分类提示的次级 LLM 调用进行语义扫描可以捕获更微妙的模式，但会增加延迟和成本。对于任何预期会收到删除请求的数据，这种权衡是值得的。

有界保留的索引墓碑标记

对于摄入时无法脱敏的数据——历史语料库、你无法控制内容的上传文档——索引墓碑标记是备用方案。收到删除请求后立即将向量标记为已删除，在查询时过滤它们，并按照定义的计划（每日压缩、每周完整重新索引）执行物理删除。该计划成为你处理活动记录文档的一部分。

加载中…