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的过滤在查询时使用元数据字段应用访问逻辑，提供灵活性，但代价是依赖查询时执行而非架构隔离。

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