Embedding的隐私架构：你的向量数据库对用户了解多少

大多数工程师认为embedding是安全抽象的——一堆无法被逆向工程的浮点数。这个假设是错误的，而感知与现实之间的鸿沟正是用户数据泄露的地方。

最新研究仅凭文本embedding就实现了超过92%的精确token序列重建准确率——包括完整姓名、健康诊断和电子邮件地址——而无需访问原始编码器模型。这些不是理论攻击。可迁移的逆向技术在黑盒场景下同样有效：攻击者构建一个模仿你的embedding API的代理模型，就可以发动攻击。无论你使用的是专有模型还是开源模型，攻击面都存在。

本文涵盖embedding隐私风险的三个层面：逆向攻击的实际能力、检索管道中访问控制悄然失效的位置，以及能为用户提供适当控制权的架构模式——按用户命名空间、检索时权限过滤、审计日志和删除安全设计。

为什么Embedding是一种不同类型的隐私问题

传统加密数据库有清晰的思维模型：静态加密、授权访问时解密、审计解密事件。数据在授权前是不透明的。

Embedding不是这样工作的。当你对文档进行向量化时，你创建了一个有损变换，编码了从原始内容派生的语言和行为模式。这些模式持续存在于向量中。最近邻查询不会解密任何东西——它只是计算距离——但它可以揭示特定人的病史在你的索引中，或者具有特定姓名的员工存在于你的HR文档中。

这个问题以三种方式叠加：

• 编码不是加密。 文本embedding模型产生的1536维浮点向量保留了语义结构。攻击者无需标记训练数据，仅通过余弦相似度比较就能提取敏感属性——国籍、职业、生日、医疗诊断——在某些属性类别上达到超过94%的准确率。
• 权限在摄入时被剥离。 当你将SharePoint、Confluence或Google Drive的文档摄入向量存储时，原始ACL元数据几乎从不被保留。文档变成对所有人可查询的。
• 删除在结构上是困难的。 对于关系型数据库，删除记录是一条SQL DELETE。对于embedding，用户数据与受其影响的向量之间没有清晰的映射关系。GDPR第17条给你30天时间。大多数团队根本没有经过测试的删除程序。

攻击面：逆向、成员推断和探测

理解攻击者实际能做什么，决定了哪些防御值得构建。

Embedding逆向攻击是最严重的。该攻击训练一个模型来逆转embedding操作——从向量重建原始文本。2024年的一篇论文证明这些攻击是可迁移的：攻击者从公开可用的embedding构建代理模型，可以将其应用于他们从未直接访问过的目标系统。实际含义是：任何你通过API提供的embedding——即使是截断或加噪版本——都可能成为攻击目标。

最近邻探测利用embedding空间的几何特性。攻击者发送精心设计的查询并观察相似度分数。如果查询"员工John Smith"返回异常高的分数，就确认了该名字出现在语料库中，即使实际内容从未被返回。这是对你向量索引的字典攻击，不需要特殊访问权限——只需要API调用。

成员推断提出了一个更微妙的问题：这个特定文档是否包含在索引中？攻击者利用检索输出的统计特性来推断存在或缺席。在医疗RAG系统中，即使从未看到源文档，这也足以重建患者标识符和诊断结果。

这些攻击都不需要攻破你的基础设施。它们利用的是embedding接口本身。

RAG管道中访问控制失效的位置

标准RAG管道存在结构性访问控制缺口：相似度搜索针对索引中的所有向量运行，无论底层文档适用什么权限。

设想一家公司在Confluence上构建内部知识助手。市场、工程、财务和HR都在同一个Confluence实例中有文档。助手摄入了所有这些文档。市场部员工提问。检索步骤对索引中的每个文档计算余弦相似度——包括HR的机密薪酬数据、未发布的财务预测和工程安全设计。如果这些文档恰好与查询在语义上相关，它们就会被返回。

员工没有导航到受限页面。他们只是提了一个问题。系统完成了剩下的事情。

三种常见失效模式导致了这个问题：

没有检索时过滤。 向量查询运行，结果返回，然后应用层才检查用户是否能读取它们。但到那时，检索已经发生了。后置过滤还会降低质量：如果你检索了前20个文档然后过滤掉15个，LLM使用的是剩余的上下文。

命名空间滥用。 一些团队为每个部门创建隔离的向量存储实例——HR一个，财务一个，通用一个。这可行但运营成本高，无法处理跨部门文档。也无法扩展到按用户或按文档粒度。

过于宽泛的源权限。 大多数组织在其源系统中已经存在权限问题——共享驱动器上太多人拥有读取权限，因为没人审计ACL。RAG通过使发现自动化来放大这个问题。传统文件访问要求知道文档的存在。RAG使一切都可以通过自然语言发现。

真正有效的架构模式

按用户命名空间和分片隔离

多租户RAG最干净的模型是每个租户严格物理隔离。Weaviate的多租户架构为每个租户提供独立的分片，具有独立的存储、向量、倒排索引和元数据。对一个租户的操作不能触及另一个租户的分片。删除很简单：删除租户就删除其分片。系统可扩展到每节点50,000+个活跃租户。

Pinecone的命名空间模型提供逻辑分区——对许多用例已足够，但没有每租户分片的物理隔离。Qdrant的基于payload的过滤在查询时使用元数据字段应用访问逻辑，提供灵活性，但代价是依赖查询时执行而非架构隔离。

对于用户拥有自己文档的应用——笔记应用、文档问答产品——分片隔离是正确的默认选择。代价是规模化时的一些索引碎片化，但访问控制保证是清晰的。

检索时权限过滤

对于文档具有复杂、重叠权限的应用——例如企业知识库——按用户分片变得不切实际。可被多个团队成员读取的文档无法存在于单个租户分片中。

这里正确的模式是使用基于关系的访问控制（ReBAC）系统进行预过滤检索。在运行相似度搜索之前，查询你的授权系统以获取请求用户可以访问的文档ID集合。将该集合作为过滤器传递给向量查询。相似度搜索只针对授权文档运行。

这要求你的授权系统能够高效回答"哪些资源可以被这个用户读取？"——传统RBAC系统通常不针对这类查询进行优化，但专用ReBAC系统（SpiceDB、OpenFGA、Zanzibar派生系统）就是为此设计的。

替代方案是后置过滤检索：检索候选文档，然后检查权限。当命中率高时这种方法有效——大多数检索文档能通过权限检查。当命中率低时（用户只能访问语料库的一小部分），后置过滤既慢又降低质量。

带有pgvector和行级安全的PostgreSQL是更简单权限模型的实用中间路径。文档段表上的RLS策略确保每个相似度查询自动限定在请求用户可以读取的行上。不需要应用层过滤。

向量检索的审计日志

传统数据库在行级别记录读取操作。向量存储默认很少这样做，这造成了合规缺口：你没有记录谁检索了什么，或者用户运行了哪些浮现出机密文档的查询。

最低限度需要记录：

• 用户标识符
• 时间戳
• 查询意图（不是原始查询向量——哈希或截断它）
• 返回文档的ID
• 相似度分数

不应记录：原始向量、包含PII的原始查询文本，或完整文档内容。目标是可审计性，而不是创建敏感数据的第二个副本。

将审计日志存储在与应用数据库分离的不可变系统中——CloudWatch、Splunk、带对象锁定的S3。数据库管理员不应该能够删除审计记录。以固定间隔而非每次查询同步转发日志，以避免给检索增加延迟。

对访问模式进行异常检测能提供有意义的信号：突然查询其正常领域以外文档的用户，或在短时间内发出数百个高相似度查询的用户，值得调查。

为删除而设计

如果你的产品存储用户生成的内容并进行embedding，你需要在上线前而不是收到GDPR请求后制定经过测试的删除程序。

实际架构涉及三个组件：

元数据链接。 每个向量必须存储对其源文档ID的引用。删除文档时，你的管道将该删除级联到所有派生向量。这听起来显而易见，但需要刻意设计：如果你在embedding前对文档进行分块，每个块需要将源文档ID作为payload元数据携带。

同步管道。 源系统（S3、数据库、CMS）的删除必须传播到向量存储。AWS Bedrock Knowledge Bases在你同步知识库时自动处理这个问题——删除的源文件在下次同步时会导致其向量被删除。如果你管理自己的管道，你需要等效逻辑：源系统中的删除事件触发向量存储中的按过滤器删除查询。

带密钥删除的加密。 对于最高风险的数据，用按用户或按文档密钥对静态向量进行加密。删除请求到达时，删除密钥。向量在没有物理删除的情况下变得不可恢复，这在简化运营流程的同时满足了被遗忘权的精神。这是受监管行业最干净的方法。

一个重要注意事项：备份。如果你对向量存储进行快照，这些快照包含从你可能被要求删除的数据派生的向量。要么将个人数据排除在快照之外，要么实施基于密钥的加密使备份在没有密钥的情况下无用，要么在删除时构建审计和清理备份的程序。

最小可行隐私架构

对大多数团队来说，当务之急是填补三个最常见的缺口：

1. 强制执行检索时过滤。 在发布任何针对多用户数据的RAG功能之前，确保相似度搜索限定在请求用户可以访问的文档范围内。如果权限图很复杂，用你的授权系统进行预过滤；如果更简单，使用RLS或命名空间隔离。

2. 记录谁检索了什么。 在你的向量存储上启用审计日志。将日志路由到不可变存储。如果你的向量存储不支持检索级别日志，在应用层添加。

3. 测试你的删除程序。 编写一个测试：创建文档，进行embedding，删除源文件，验证向量已消失。在上线前运行。如果可以，在CI中运行。

Embedding逆向防御——差分隐私、同态加密——适用于embedding可能通过API暴露或由不受信任基础设施处理的医疗、法律和金融应用。对大多数应用来说，架构隔离和访问控制每单位工程投入提供的实际保护更多。

根本转变是将你的向量存储不视为搜索索引，而是视为具有用户和权限的数据库。这种框架使正确的模式变得显而易见。