在生成式人工智能快速普及的当下,检索增强生成(Retrieval-Augmented Generation,简称 RAG)成为让大模型回答领域专属问题的关键技术。RAG 通过检索与上下文补全,把相关文档或片段注入到模型提示中,从而获得更准确且有事实依据的回答。然而在多用户或多租户环境中,RAG 的传统实现会带来严重的隐私与合规风险:未经授权的内容可能在检索阶段进入模型上下文,从而被无意中或被恶意提示工程泄露给不具备访问权限的用户。针对这一痛点,ReRAG 将关系型访问控制(ReBAC,Relationship-Based Access Control)与 RAG 深度结合,提供一种保证"从未让未经授权内容进入 LLM 上下文"的实务方案。核心思想是将权限过滤前移到检索层,只有授权的文档才参与向量检索或才会被最终送入模型,从而从根本上防止数据泄露与提示注入导致的外泄风险。 为什么传统 RAG 会泄露数据?RAG 的实现通常分为两个阶段:首先进行语义检索,找到与询问相关的文档片段;然后将这些片段合并进 prompt,由 LLM 生成最终回答。
在多用户体系或复杂权限场景下,如果检索层没有意识到用户权限,就会把所有相关片段都返回给模型。即便后续提示里尝试"只回答可见内容",模型仍可能在隐式记忆或联想中泄露敏感信息。提示注入攻击进一步加剧了风险:攻击者可能设计恶意查询或包含误导性上下文,诱导模型披露原本属于受限用户的信息。因此,解决方案不能只是依赖模型"自觉合法",而要在系统层面确保未经授权的内容根本不被模型看到。 ReBAC(关系型访问控制)为何适配 RAG?传统的基于角色的访问控制(RBAC)在很多组织中已被广泛使用,但在面对复杂的拥有关系、团队协作、代理权限以及层级与动态授权时显得力不从心。Google Zanzibar 提出的一套关系型授权模型,擅长表达诸如"经理可以访问其直接下属的文档""外部顾问只能读取指定项目的资料"等细粒度关系。
Ory Keto 作为 Google Zanzibar 思路的开源实现,提供高性能的关系校验 API,能够在文档级别回答"用户是否有权限访问文档 X"。将 ReBAC 应用于 RAG,可以在向量检索前或检索后立即对候选结果做强制过滤,确保只有用户有权查看的文档片段进入 LLM,上下文与生成阶段因此被固化为非泄露状态。 实现要点:从数据上标注到递归检索 安全的 ReRAG 实现涉及多层工程设计。首先,文档入库时需要附带元数据,至少包括 document id、所有者、标签与用于 ReBAC 判断的关系属性。构建向量库时同时保存 embedding 与元数据信息。为了在本地快速做向量检索,sqlite-vec 提供了基于 SQLite 的向量索引能力,允许在数据库层面完成 KNN 检索并返回距离分数与对应 id。
这样既避免把全部向量加载到应用内存,又可以借助 SQL 做联合查询与过滤。 检索阶段的关键在于"权限感知检索"。直接对全文库做 vanilla KNN,再对结果做权限过滤,可能导致需要不断扩大候选池才能拿到足够的授权结果,特别是在权限稀疏的场景中。为了解决这一问题,ReRAG 采用了一种自适应递归检索策略:先以 topK × 2 作为初始候选数进行 KNN 检索,对这些候选执行 ReBAC 授权检查;如果授权后的候选数不足,则成倍扩大检索候选数(例如乘以 2),并重复授权过滤,直到达到需要的 topK 或者检索所有文档或达到安全上限(例如最多 10 次)。这种方案在多数情况下能在几次检索内得到满足的授权结果,同时避免一次性查询过大候选集导致的性能与内存问题。 系统组件与技术栈选择 在开源实现中,优先考虑可复现与轻量化部署。
Ory Keto 用于关系与权限判断,提供读写分离的端点。Ollama 作为本地 LLM 运行层,可以在 Docker 环境中快速托管模型,用于 embedding 生成与最终回答推理。sqlite-vec 在单文件 SQLite 中构建向量索引,兼顾性能与可移植性。整体服务层用 Go 语言实现,便于高并发处理与与 sqlite-vec 的 CGO 集成。 在部署与 demo 层面,常见流程包括:通过 API 上传文档并生成 embedding,写入 documents 表与 vec_documents 虚拟表;在 Keto 中写入关系声明如"user:alice member_of team:finance"或"document:tax_return related_to taxpayer:john_doe",并以这些关系驱动 ReBAC 策略。在查询时,服务先向 Ollama 请求 embedding,然后对 sqlite-vec 发起自适应 KNN 检索,对候选集逐条向 Keto 发起权限校验,最终将通过授权的文本片段拼接为 prompt,并调用 Ollama 的 LLM 生成回答。
重要的一点是,未经授权的文档不进入任何拼接或提示,从而从根本上阻止信息被模型"看到"。 安全与合规考虑 ReRAG 的优势在于把"不可见"变成可控的边界。将授权判断前置到检索层,能确保被判定为不可见的数据既不上到模型也不被记录到模型可能的上下文中,从而降低提示注入与模型溢出带来的泄露风险。为了进一步提高合规性,应当在全链路保留审计日志,记录每一次授权查询的请求者、匹配到的候选文档 id、授权结果与时间戳,便于事后审计与合规检查。 此外,传输层建议启用 TLS,存储层若有合规需求可以采用 SQLite 的 SQLCipher 或其它加密手段保护静态向量库。对敏感字段使用字段级加密,并限制运维与日志的访问权限,可以进一步降低内部风险。
鉴别机制建议采用 JWT 或企业级 OIDC,以便将用户身份与权限系统可靠地绑定;在演示或原型阶段可使用 mock token,但生产环境应替换为真实的认证机制。 性能优化与工程实作细节 在高并发或大规模文档库场景下,需要兼顾检索效率与授权检查的吞吐。sqlite-vec 的优势之一是把向量检索推到数据库层执行,减少应用层的内存占用。但授权检查若逐个候选请求 Keto,会带来大量网络开销,可以采用批量授权检查或把常见的权限信息缓存于本地(并结合短时失效策略),以减少往返延迟。对于极大规模的数据集,sqlite-vec 可能成为瓶颈,此时可以考虑将向量存储迁移到专门的向量数据库或 pgvector、Weaviate、Pinecone 等服务,仍然在检索结果层执行 ReBAC 过滤。 另外,embedding 的生成与更新策略也直接影响系统体验。
对频繁变更的文档,应设计增量更新与批量 reindex 流程;对于实时性要求高的场景,可以把最新文档放到短时缓存与内存索引,定期合并到主向量库。自适应递归检索的参数(初始倍数、最大尝试次数、候选增长因子)需要根据实际权限分布与查询统计调优,以在查询延迟与结果完整性之间取得平衡。 使用场景与业务价值 ReRAG 在企业级搜索、客户支持、法律检索、医疗档案查询等场景中具有明显价值。例如在财务或税务系统中,不同员工或外部顾问仅能查看与其权限范围内的报表或报税资料;在医疗系统中,医生只能访问其授权患者的病历片段;在法律检索中,律师团队可以基于项目或当事方的关系来限定可见文档。通过把权限约束融入 RAG 的检索阶段,组织不仅能减少合规风险,还能更精确地对 LLM 输出负责,从而降低潜在的法律与商业损失。 局限性与未来方向 尽管 ReRAG 显著提升了 RAG 的安全性,但也有需要权衡的地方。
关系授权判断可能成为性能瓶颈,尤其在权限规则复杂或关系查询十分频繁的情境下。Keto 等 ReBAC 系统需要合理的策略设计与索引以维持低延迟。另一方面,向量检索本身的可解释性较差,如何在授权通过后向用户解释为什么这些文档被选中,以及如何证明某些内容未被呈现,都是值得探索的问题。 未来工作可以包括把 ReBAC 与向量索引更深层结合,例如在向量表中预先维护文档的授权标签或倒排关系,从而在查询时直接用 SQL 做联合授权过滤,避免大量往返请求。另一个方向是用可证明的保密计算或安全多方计算,将一些敏感的授权决策以隐私保护的方式分摊与计算,提升在跨组织协作场景下的安全边界。 结语 在多用户、多租户与严格合规要求并存的现实环境中,单纯依赖模型"自觉合法"的思路已经不再可靠。
将关系型访问控制与检索增强生成结合,能从根源上阻止未经授权信息进入模型上下文,显著降低数据泄露与提示注入风险。借助开源组件如 Ory Keto、Ollama 与 sqlite-vec,可以在本地或私有云环境中快速搭建实验性或生产级的 ReRAG 系统。对于希望在保持生成式 AI 能力的同时强化数据安全与合规性的组织,ReRAG 提供了一条务实且可审计的路径。 。
