企业 RAG 如何做文档级权限过滤？从检索到引用逐层验证

企业知识库里的文档权限不是一句“请模型不要泄露”就能解决的。搜索服务的应用密钥通常让后端查询整个索引；它不能自动代表正在提问的员工。若检索已经把受限段落交给模型，最后的回答即使碰巧没有引用，也不能算权限设计通过。

这篇课文聚焦一个独立问题：对这次请求，谁能看到哪份文档，以及拒绝决定是否一直持续到最终引用？ 检索评测检查合格证据有没有命中和排序；这里先规定“合格”的权限含义，再验证每条数据路径。工作成果是一份可填写的权限传递工作表，不依赖某一家向量数据库。

从可信身份开始，而不是从提问文字开始

在服务端验证登录会话或令牌，得到稳定的用户主体、当前租户以及受该租户约束的组或角色。租户和组应来自可信的身份与授权系统；用户输入的“我是财务主管”、模型推测出的部门、浏览器自行提交的组名都不能扩大权限。若主体不存在、租户归属不清或授权服务不可用，就拒绝这次受保护检索，不要退化成无过滤搜索。

先写一条明确的允许规则，例如：文档.tenant_id == 当前租户，并且该文档是租户内公开，或者其允许主体/组与经验证的当前身份匹配；显式拒绝与文档级例外还要按业务策略处理。这里的表达式只是设计示意，不是可直接粘贴的某个搜索引擎语法。跨租户即使组名同叫“Finance”，也不能因字符串相同而互通。

Azure AI Search 的安全过滤模式把主体当作索引中的字符串进行匹配，官方明确说明这个模式自身不做身份认证或授权。因此应用必须负责可信身份、映射和每次查询带过滤条件。Azure 也提供基于源权限元数据的原生文档级方案，但不同数据源与功能有预览范围；选用时应按当前产品、API 版本和来源单独核对，不能把其保证推广到其他搜索后端。

给每个可检索片段保留可判定的权限

为父文档记录稳定文档 ID、租户 ID、来源版本、权限策略版本和可用的主体/组标识。切块后，每条子片段必须可追溯到父文档，并携带搜索时判断权限所需的字段。Azure 的父子索引投影文档建议将父字段重复到子片段；若采用两个索引，要记住普通查询没有自动的跨索引连接。可用一张抽样核对表检查父文档有 12 个片段时，12 个片段的租户与 ACL 是否一致。

“继承”也有例外：一份全员手册后附的薪酬附件若只限人事，不应与手册正文共用一条宽泛授权。入库时把附件拆成独立权限单元，或让较窄的片段权限覆盖父级默认值。无法确定有效权限的片段应暂不进入可检索集合。类似地，文件标题、提取摘要、表格单元和向量对应的可返回文本都要遵循同一边界；仅把 acl 字段设为不返回，并不等于内容已被保护。

在检索和回取处都执行授权

请求进入搜索前，由后端构造租户条件和允许的主体/组条件，覆盖关键词、向量、混合检索、重排和建议查询等实际使用的入口。不要先取全局 Top-k 再在应用里删掉越权命中：它可能已经让不该看的文本进入日志或下游，也会让少量可见文档被全局排名挤掉。保存可复核的过滤表达式、搜索请求 ID、索引版本、返回片段 ID，但生产日志不要照抄敏感原文。

检索结果往往还会触发父段扩展、全文回取、附件预览和引用链接生成。每一个读取点都要用当前请求身份重新确认文档权限，不能因为一个片段通过就让同一父文档下所有附件通过。送进模型的上下文只包含已授权内容；生成的引用 ID 再映射到实际原件时也要检查权限。直接打开来源链接时，源系统仍需执行自己的授权。对于答案或检索缓存，至少把租户、可见范围或授权策略版本纳入隔离设计，并在权限变动后失效相关条目；单靠问题文本作为缓存键会跨用户复用受限回答。

把撤权当成一次有截止时间的变更

源系统撤销访问以后，索引副本和查询缓存未必同时更新。Azure 索引更新文档指出内容更新经后台索引后才可搜索，因此“更新请求成功”不能证明下一条查询已按新 ACL 拒绝。为撤权定义可接受的生效窗口，并在窗口内由实时权威授权检查阻断旧索引命中，或暂停该文档的检索；随后查询每个相关片段，确认旧主体再也拿不到正文、摘要、父段、引用与缓存答案。

把变更记成可审计的状态：源权限版本、索引中可见版本、缓存失效时间、负向探针首次通过时间。如果使用自定义字符串过滤，尤其要测“组成员被移除”而文档 ACL 未变的情况；此时更新的可能是请求方的组声明或会话，而不是文档索引。过期令牌仍带旧组时，权限收紧可能不会立刻生效，具体时限要由身份系统和应用会话规则承担。

案例一：同名小组不能跨租户读资料

以下是合成案例。A 与 B 两家客户都用 Finance 作为小组名。A 的财务员工询问“A 的供应商付款规则”，搜索索引里同时有两家客户措辞相近的付款文件。A 的员工应看到 A 的公开规则和允许给 A 财务组的附录；B 的付款文件即使排第一，也必须在搜索结果、模型上下文和引用列表中缺席。

先用 A 财务身份做正向对照，再用 B 财务身份问同一句，最后移除租户声明重试。记录每次的租户、组来源、实际过滤条件和返回片段 ID。如果把 Finance 当作全局组名，B 的片段可能误入 A 的结果；如果只在模型回答里要求“不提 B”，则检索层仍已失败。修复方向是将组标识绑定租户并由服务端签发，而不是调低相似度分数。

案例二：撤权后旧引用仍能打开

同样是假设案例：一份采购协议正文可供采购组阅读，但法律附录只开放给法务。采购助手过去为法务人员生成过带附录引用的回答；后来该人员离开法务组。新的请求应既拿不到附录片段，也不能复用先前缓存的回答或凭旧引用 ID 回取附录。

测试顺序是：先在允许身份下确认附录可用；撤销组资格并记录时间；用新的会话及仍在有效期内的旧会话分别查询；直接访问先前的引用与预览；最后检查索引同步后所有子片段的 ACL。若旧会话仍可读，要定位令牌/会话更新窗口；若搜索拒绝但引用可打开，是引用解析器漏了授权；若引用拒绝而缓存仍显示正文，是缓存隔离或失效故障。三者都不能用“模型最后没有引用”判通过。

用一组拒绝测试决定是否放行

从真实策略中抽取至少一份普通文件、一份限组文件、一份例外附件和一次撤权变更。每份文件配“允许身份”正向对照，再加入同租户无权组、另一租户同名组、缺失身份、权限已撤销四种负向身份。对每个身份检查搜索命中、实际下游上下文、父段/预览、引用解析、缓存命中五个位置；有任何越权内容出现都阻断上线。另一条独立指标是允许身份仍能检出有用资料，避免权限过滤写错后把所有结果清空。

下方工作表逐行填写一个请求：预期允许/拒绝、源 ACL 与索引版本、可信主体与租户、实际过滤条件、返回 ID、模型输入、引用回取、缓存和撤权结果。把失败定位到第一个越界位置，修复后重跑同一组正负向案例，并保留复核人和日期。如果这组权限测试通过，再用引用与时效审计判断允许的片段是否真的支持答案；文档切块试验可帮助检查例外附件有没有被错误继承。

不适用边界

本页帮助验证一条 RAG 数据路径是否执行既定文档 ACL，不负责替业务定义谁应该获得授权，也不能以有限测试证明系统绝无泄露。多区域索引、备份、分析日志、导出和离线训练副本还需要按各自的数据治理规则检查。不同搜索产品的过滤语义与原生权限功能并不相同；采用具体后端时，应把本文的测试转成该后端的实际请求与可观察证据。