先这样答
在 RAG 中引入文档权限，核心原则是权限过滤必须发生在检索阶段之前或之中，绝对不能采取先检索再过滤的策略。如果先进行向量检索召回前列结果，再用代码筛除无权访问的文档，极易出现召回名额被无权文档占满的情况，导致最终给到模型的有效上下文为空。因此，必须采用「先过滤后检索」或者支持标量过滤的引擎内联过滤机制。
具体实现路径分为两条，取决于业务中权限域的数量与复杂度。第一种是元数据标量过滤。在文档切分与向量化阶段，给每一个 Chunk 附加上权限相关的元数据，例如部门、密级或具体的 ACL 标签。当用户发起检索请求时，后端服务读取当前用户的身份信息并带入检索链路，由向量引擎在执行相似度计算的同时进行标量过滤。第二种是多租户物理隔离。对于权限域较少的场景，可以直接在 Collection 级别或分区级别进行隔离。将拥有相同权限的文档切分后存入同一个分区，检索时直接路由到对应分区。这里存在切分与权限的矛盾——按权限预切库的方式过滤速度更快，但会牺牲检索的全局性；而 Chunk 级别的 ACL 更加灵活，代价则是元数据维护较重。在实际设计中，权限域的具体数量决定了要在哪一边做出妥协。
除了检索链路本身，生成侧和审计环节也需要配套兜底。在生成侧，模型给出的引用来源只能暴露用户当前有权查看的文档，答案中的敏感字段需要做脱敏处理。同时，需要在提示词中增加严格约束，要求模型只依据提供的片段作答，减少模型从其自身参数知识中泄漏敏感信息的风险。在审计层面，检索日志必须详细记录什么身份的用户检索了哪些内容，对越权尝试触发告警。在 Agent 场景下，还要特别防范间接注入，确保用户输入的自然语言不能影响系统设定的权限上下文。
在面试官面前可以这样收束：文档权限不仅是向量库的工程实现问题，而是需要在切分策略、引擎标量过滤以及生成侧脱敏之间做平衡，核心依据就是业务中权限域的具体数量。
面试官会怎么追问
-
「内部文档给 Agent 用有没有考虑泄露用户隐私或越权问题，特别是防范 Prompt 注入？」 在 Agent 场景下，防范间接注入诱导跨权检索是关键。用户的权限身份必须由后端系统通过登录凭证直接注入检索请求，绝不能允许用户的自然语言输入去影响或修改权限上下文。同时，在最终的生成环节配置严格的提示词约束，强制模型仅依据当前检索到的合法片段作答，避免模型被诱导输出参数中记忆的敏感信息。
-
「倒排或向量索引怎么同时解决切分和权限问题？」 这两者在设计上存在固有矛盾。如果业务的权限域数量有限，推荐采用按权限预切库的策略，同权限文档进入同一分区，这样检索效率最高，但牺牲了跨域检索的全局性。如果权限划分非常细粒度，就必须在切分阶段给每个 Chunk 绑定 ACL 标签，利用引擎原生支持的标量过滤机制来处理，这会增加元数据的维护成本。
-
「为什么不能先用向量检索召回最相关的文档，然后再用代码把没有权限的过滤掉？」 这种后置过滤的做法会导致严重的截断问题。假设系统设定召回前十条最相关的文档，如果这十条文档恰好都是当前用户无权查看的，经过代码过滤后，传递给模型的有效上下文就会变成空集。哪怕排名第十一位的文档既高度相关又有权限，也会因为未能进入前列而被漏掉，因此必须采用引擎内联过滤。
回答的坑
- 认为可以在检索完成后再做权限校验。这种做法违背了检索的基本逻辑，一旦高相关度但无权限的文档占满了召回名额，过滤后会导致模型无内容可答，必须将过滤动作前置到检索阶段或引擎内部。
- 忽略了生成侧和 Agent 输入端的风险。只讲向量库里的权限隔离是不够的，如果不在生成侧对引用来源做脱敏，或者允许用户输入篡改权限上下文，依然会发生越权和敏感信息泄露。
同系列的题