近年来,检索增强生成(Retrieval-Augmented Generation,简称 RAG)成为推动大规模语言模型在实际业务中落地的重要模式。通过先检索相关文档再将这些上下文提供给模型,RAG 极大提升了问答准确性与事实性。然而在多用户、多租户、权限复杂的真实环境中,传统 RAG 存在严重的数据泄露风险:如果检索或上下文过滤不严格,模型可能在响应中暴露用户无权查看的敏感信息。ReRAG 倡导的核心理念就是在检索阶段与生成阶段都严守访问控制,确保未经授权的内容永远不会进入模型上下文,从而把"靠模型自觉遵守权限"这一不可靠做法替换为可审计、可证明的权限隔离机制。ReRAG 的实践示例之一是将 Google Zanzibar 风格的关系型访问控制(ReBAC)与向量检索有机结合,实现权限感知的 RAG 流程。Google Zanzibar 提出的细粒度权限模型擅长表达复杂的关系与委托场景,比如用户、组、资源与角色之间的多层次联系。
Ory Keto 是开源的 Zanzibar 实现,能够以高性能服务化方式管理"谁能访问什么"的关系。把 Keto 与向量数据库或 sqlite-vec 等嵌入存储结合,便能在检索环节筛除无权文档,从源头上杜绝非法数据进入 LLM 的上下文窗口。在典型的 ReRAG 流程中,文档上传时会被打上元数据标签并生成向量嵌入;这些嵌入存储在支持 KNN 查询的数据库中,例如 sqlite-vec,它允许在 SQLite 中进行本地向量检索并节省运维复杂度。查询阶段先生成查询向量,再进行向量检索得到候选集;随后系统对候选文档逐条进行权限判定,通过与 Ory Keto 的读 API 校验调用者是否具备访问关系。只有通过授权的文档会被拼接进 LLM 的上下文,最终由本地或远端模型(例如 Ollama 托管的 LLM)生成回答。这个流程保证了未经授权的内容在任何情况下都不会出现在 prompt 中,从而防范了基于 prompt 的注入攻击和模型意外泄露敏感信息的风险。
一个关键实现挑战是当权限分布稀疏时,简单地从向量数据库取 TopK 可能会得到大量无权文档,导致需要不断扩大候选池或回退到全库扫描。ReRAG 倡导的"自适应递归搜索"通过倍增候选池规模并设置安全上限,在效率与完整性之间找到平衡。第一轮取 TopK×2,校验权限后若不足则倍增候选数量,最多进行若干次重试直到满足返回数量或遍历完数据。对于大规模语料库,这种方法避免了每次请求都进行昂贵的全库权限预筛;对于权限高度稀疏的场景,则可以考虑反向优化:先用权限系统预过滤出允许访问的文档 ID 列表,再在向量库内部做带 ID 限制的近邻检索。在技术栈选择上,ReRAG 的参考实现采用了开源组件以便本地化与可审计性。Ory Keto 提供了成熟的关系权限服务,支持写入与读取分离的端口,利于横向扩展与权限变更的一致性保障。
Ollama 可在 Docker 容器中运行本地模型,既能处理嵌入生成,也能提供推理服务,适合对数据不出境有严格要求的企业。sqlite-vec 则将向量检索能力嵌入到轻量级的 SQLite 中,对小到中等规模语料非常友好,且无需单独管理向量数据库。实际部署时应考虑以下几方面的工程与合规要点。鉴权模式要与组织现有 IAM 集成,生产环境中应避免使用 mock token,而是采用 JWT、OIDC 或企业 SSO,并确保 Keto 的写读访问受控且变更可审计。数据加密方面可在静态存储层启用 SQLite 的加密扩展或采用外部磁盘加密;传输层使用 TLS 保障服务间调用与客户端通信安全。日志与审计必须记录每一次权限检查、检索请求以及返回的候选集,以便事后复核与合规审计。
此外,限流和速率控制也是必要的安全边界,防止恶意用户通过大量查询尝试穷举敏感内容的存在。性能优化层面,需要权衡向量检索质量与查询延迟。对于高并发场景,单机 sqlite-vec 可能成为瓶颈,可以考虑迁移到支持 ANN 索引(如 HNSW)的向量引擎或托管型服务,同时保留权限过滤逻辑。另一种可行方案是在应用层对候选 ID 进行分片与并行权限校验,或在 Keto 侧实现批量权限查询接口以减少网络往返。从产品与业务角度看,ReRAG 对那些必须遵守数据隔离、隐私法规或具有租户间敏感边界的业务尤为重要。法律、税务、医疗、HR、法律咨询等场景中,用户或组织对数据访问有明确定义,RAG 若未做权限隔离将面临合规风险。
ReRAG 的优势不仅在于阻止数据被模型看到,更在于能生成可审计的访问路径,证明系统在任何时刻只使用了被授权的信息,满足合规审计要求。尽管 ReRAG 在保障隐私方面具有明显优势,但它并非万能。模型会话中仍需防范生成式攻击,例如用户可能通过巧妙提问迫使模型揭示其在上下文中可见但敏感的信息。为此应在生成阶段加入内容策略过滤、敏感信息识别与可疑输出阻断机制。与此同时,向量检索本身的去标识化技术值得研究,例如通过只返回文档片段的摘要或经过策略化裁剪的片段来进一步降低敏感暴露风险。在工程实践中,落地 ReRAG 可按阶段推进。
首先在非敏感数据上构建端到端原型,验证从嵌入生成、向量搜索到 Keto 权限校验的请求链路与日志记录能力。然后在受控的生产小流量中启用权限过滤,通过红队测试与审计模拟各种越权场景以找出策略漏洞。最后全面上线时结合企业 IAM、审计平台与密钥管理服务,确保凭证与加密密钥管理稳固。开源与社区方向的扩展也值得关注。将 ReRAG 模型与现有向量数据库(如 pgvector、Weaviate、Milvus)做兼容性桥接,或者把 Keto 权限查询能力内嵌到向量引擎的检索层都能带来性能与可维护性的提升。另一个有价值的方向是实现权限感知的向量索引构建,在向量分区或索引层面预先考虑权限分组,从而在检索时内置访问控制而不是后置过滤。
ReRAG 并非仅为大型互联网公司准备,许多中小型企业也能从中获益。对于希望在内部部署 LLM、避免将敏感数据发往第三方云的组织,ReRAG 提供了一套可审计且可控的方法论。结合本地化的 Ollama 模型和 SQLite 向量存储,可以在硬件与运维成本可控的前提下达到合规与隐私保护的目标。总之,检索增强生成在提升模型能力方面带来了巨大的价值,但在多用户多权限场景下必须对权限与隐私负责。将 Google Zanzibar 风格的 ReBAC 与向量检索结合,形成 ReRAG 能够在源头上阻止越权信息进入模型上下文,增强系统的可审计性与合规性。未来随着向量检索与权限系统更深的融合,以及对索引层权限意识的优化,ReRAG 有望成为企业级智能问答与知识检索系统的标准实践之一。
对于工程师而言,关键在于在早期设计阶段就把权限作为首要维度纳入索引与检索流程,而不是事后补救;对于产品经理而言,理解并衡量隐私风险、合规需求与用户体验之间的权衡,将决定 ReRAG 能否在生产环境中实现价值最大化。 。
