你的 Embedding 是个人身份信息 (PII)：反向攻击与向量数据库中的被遗忘权

在你公司的内部数据分类政策中，总会有这么一个表格。原始客户文本——支持票据、医疗笔记、聊天记录——被归入“敏感”行，受到加密要求、访问控制和删除服务等级协议（SLA）的保护。然而，还有一个存储着 这些文本对应的 嵌入向量（embeddings）的向量库，它被归类为……什么也不是。衍生数据。匿名数学。只是一堆浮点数。

这种分类是错误的，而且这种错误现在已经得到了实验证明。逆向攻击（Inversion attacks）可以从嵌入向量中重建原始文本——在研究最充分的场景下，92% 的案例可以 准确 恢复 32 个 token 的输入，包括临床笔记中的全名。如果攻击者拿到你的向量后能读出你客户的话，那么你的向量就继承了这些话语的敏感性。监管机构已经开始公开声明这一点，而大多数检索架构尚未对随之而来的后果做好准备：删除请求必须触及每个索引、每个快照和每个衍生工件——而不仅仅是行存储（row store）。

嵌入向量从未是单向的

此前人们普遍认为嵌入是一种有损哈希（lossy hash）：文本输入，语义输出，而且这种映射在任何实际意义上都是不可逆的。随着一系列被称为“嵌入逆向”（embedding inversion）的技术出现，这种假设不复存在。

里程碑式的研究成果 vec2text 通过迭代优化（iterative refinement）来工作。它训练一个条件语言模型，接收目标向量和文本假设，对假设进行嵌入，并利用假设向量与目标向量之间的 差异 来提出修正。运行该循环几十次，假设就会收敛——不仅是转述，而且通常是完全相同的原始字符串。针对生产级的嵌入模型，该方法逐字恢复了 92% 的 32 token 输入，BLEU 分数超过 97。应用在临床笔记语料库上时，它恢复了患者的全名。

后续的研究工作使这种攻击变得更加实用，而非更难：

• 无需查询权限。 可迁移的逆向攻击在 不同的 嵌入模型上训练代理模型并对齐空间，因此持有你向量转储的攻击者根本不需要调用你的嵌入 API。
• 跨领域泛化。 可复现性研究证实，这种效应在不同数据集和嵌入模型中普遍存在，而不仅仅局限于原始论文的设置。
• 更长的文本也会泄露。 精确重建的效果随长度增加而下降，但姓名、日期、诊断结果、账号——这些使文本变得敏感的实体——恰恰是逆向攻击恢复最可靠的 token，因为它们是嵌入模型为了在检索中发挥作用而必须编码的高信息特征。

最后一点值得强调，因为它击碎了最常见的辩解。嵌入向量之所以利于搜索，正是 因为 它们保留了数据块的独特特征。关于“Jane Doe 在 3 月 14 日的二级诊断”的数据块之所以可检索，正是因为这些身份信息被编码了。效用与泄露是同一种属性。你不可能免费获得一个检索效果好但逆向效果差的嵌入向量；任何增加噪声或投影掉某些维度的防御措施，都是在以牺牲召回率为代价来换取隐私。

监管机构比你的架构先行一步

如果你希望争辩说嵌入向量是匿名的衍生数据，欧洲数据保护委员会（EDPB）在 28/2024 号意见书中已经堵死了这条路。委员会的立场是：只有当从 AI 模型（以及直接延伸出的学习表征存储）中提取个人数据的可能性 微乎其微 时，该模型才是匿名的——而且评估必须明确考虑到成员推理（membership inference）和逆向攻击。门槛很高，需逐案处理，且举证责任在你。

对照 92% 的精确恢复率，结论显而易见。由个人文本构建的向量库就是个人数据库。这不是“可以商榷的”，也不是“出于谨慎起见”。根据既定标准的直接应用：提取不仅是有可能的，而且是一种已经发布并带有开源工具的技术。

这带来了大多数团队尚未考虑到的两个后果：

1. 附着在源文本上的每一项义务都适用于向量。 访问控制、静态加密、索引泄露时的违规通知、跨境传输限制、留存期限。
2. GDPR 第 17 条的删除请求同样适用。 “被遗忘权”必须以触达 Postgres 行数据的相同力度触及向量库——这种擦除必须是可验证且不可逆的，而不仅仅是表面文章。

第二点正是架构悄然失效的地方。

为什么“删除数据块，保留向量”无法通过审计

审视一下当典型的 RAG 技术栈收到删除请求时实际发生了什么，并数数数据在哪些地方残留了：

• 索引中的软删除。 基于 HNSW 的系统（大多数向量数据库的默认选择）通常通过标记向量 ID 并在查询时跳过来处理删除。向量本身会留在索引文件中，直到压缩（compaction）重建索引，而这可能很少触发甚至从不触发。最近关于“幽灵向量”（ghost vectors）的研究表明，软删除的嵌入向量在 HNSW 索引文件中仍然物理存在且可重建。从查询结果中抑制并不等于擦除；GDPR 相关指南明确要求擦除必须是不可逆的，而标记（flag）正是可逆的定义。
• 快照和备份。 你的索引会为灾难恢复进行快照。被删除的向量存在于删除前拍摄的每一个快照中，其留存周期取决于你的基础设施团队出于与隐私无关的原因所做的选择。
• 无法追溯的代理 ID。 数据块通过内容哈希获得 ID 或自增键。如果你没有存储每个数据块的来源（provenance）—— 哪个用户，哪个源文档 ——你甚至无法找到你必须删除的那些向量。请求带着用户 ID 到达；而你的索引只认识 UUID。
• 衍生聚合数据。 聚类质心、缓存的查询结果、从包含用户数据的多文档上下文中嵌入的摘要。每一个都是具有自己生命周期的衍生表征，且没有指向源数据的指针。
• 重新嵌入的周期。 一些团队会定期（每周、每季度）从源数据重新构建索引。删除通过下次重建时的遗漏来“生效”，这意味着有效的删除 SLA 等于重建间隔。如果法务承诺的是 30 天，而重建周期是季度性的，那么这个缺口就是等待审计员发现的隐患。

这些情况都并不少见。它们是大多数流行工具的默认行为，而这恰恰是问题所在：合规路径需要刻意的架构设计，而不合规路径则是你通过运行快速入门指南（quickstart）就能得到的。

删除传播架构

修复工作并非一次性的英雄式清除脚本。它将删除视为一种通过与摄取相同的流水线进行传播的事件。其核心组件包括：

每个向量上的溯源元数据。 在写入时，将主体标识符（用户 ID、患者 ID、租户 ID）和源文档引用附加到每个分块（chunk）的元数据中。这是整个设计中杠杆率最高的决策：如果元数据存在，按 user_id 过滤删除只需一行代码；如果不存在，那就是一项考古工程。在现有索引上补全溯源信息意味着需要从源系统重新推导血缘关系——这需要花费数周而非数小时的预算。

贯穿索引流水线的墓碑（Tombstones）。 删除请求会触发一个携带主体 ID 集的墓碑事件。嵌入数据的每个消费者都会订阅：主向量索引、副本索引、缓存、派生聚合任务。每个消费者都要进行确认；死信队列负责捕获失败的任务，因为“我们认为它已传播”这种说法经不起审计。在物理擦除之前的窗口期，墓碑也会拦截检索——查询时过滤是一种可以接受的过渡措施，只要它是迈向不可逆删除的一步，而不是其替代品。

有界的压缩窗口。 由于 HNSW 软删除会使数据物理留存，因此请按照短于删除 SLA 的间隔安排压缩（或索引重建）。如果法律部门承诺的是 30 天，那么压缩至少每两周运行一次。这会将“最终擦除”转化为你可以写入合规文档的数字。

备份过期作为真正的删除日期。 按记录清除备份通常是不切实际的；标准模式是有界的备份保留期限，加上恢复时的墓碑重放——任何恢复的快照在提供流量之前都必须重新应用删除日志。那么，你真正的删除保证就是 max(压缩窗口, 备份保留期限)，而你应该报告的是这个数字，而不是行删除的时间戳。

聚合应当重建而非修补。 包含已删除数据的质心（Centroids）和摘要应从存续成员中重新计算。跟踪哪些聚合消费了哪些来源——这是高一个层级的溯源纪律。

已经公布其方法的团队（例如，使托管 RAG 知识库遵循被遗忘权请求的记录模式）都趋向于这种相同的形式：通过溯源识别、从源和索引中删除、验证，并明确处理失败路径。

防止下一次事故的分级规则

上述架构修复了你现有的向量库。而政策修复则能防止接下来的五个系统重蹈覆辙，它可以用一句话概括：

派生表示继承产生它们的数据的敏感度分类。

医疗笔记的嵌入（Embeddings）就是医疗数据。客服对话的嵌入就是客户通信。分类随转化过程流转——经过嵌入、摘要、聚类和缓存——只有当你能针对当前的攻击技术证明恢复确实微不足道时，分类才会取消。这是 EDPB 的测试标准，也是一个合理的工程测试：它强迫你在设计阶段提出“这个产物可以被反向推导吗？”的问题，此时溯源元数据的成本只是一个额外的字段；而不是在请求阶段提出，此时由于其缺失，代价将是一个季度的努力。

这一规则之所以令人不安，正是因为它所指向的地方。不仅仅是向量数据库：还包括 Redis 中的嵌入缓存、从生产查询中采样的评估集、从用户对话中提炼的微调语料库、聚类用户反馈的分析流水线。其中每一个都是个人数据的下游，而目前在大多数公司中，每一个都被归类为“内部——派生”。

关于向量反演的论文并没有创造这种风险；它们只是揭示了风险。文本一直存在于向量之中。现在内化这一点的团队可以将删除作为一项流水线功能来构建。而那些不这样做的团队，则会将其视为一起事故——一个被泄露的索引最终演变成被泄露的语料库，或者一个删除请求最终演变成对一个用户的文字究竟散布在多少个地方的“大发现”。