企业 RAG 项目最容易被低估的不是召回率，而是权限。内部知识库里有公开制度、部门文档、项目资料、客户信息、合同内容。如果检索阶段把无权限资料塞进上下文，再指望模型“不说出来”，这个系统从设计上就已经不安全。
面试里能把权限过滤讲清楚，会明显区别于只做过演示版知识库的人。企业场景里，正确答案不仅要准确，还要确认用户有权看到依据。
权限不能放到生成之后
有些实现会先全库检索，再让模型回答时注意权限。这是危险的。只要无权限内容进入上下文，模型就有可能直接引用、间接总结，或者在多轮对话里泄露线索。
正确顺序应该是：先确认用户身份和权限，再在检索阶段过滤可访问文档，最后才把候选片段交给模型。模型只能基于用户有权访问的资料回答。权限不是提示词约束，而是后端数据边界。
文档元数据要足够细
权限过滤依赖文档元数据。至少要知道文档属于哪个组织、部门、项目、角色、密级、有效期，以及是否允许被问答系统使用。只有一个文档标题和正文，很难做可靠权限判断。
更细的问题是段落级权限。有些文档前半部分公开，后半部分只给特定角色看。如果系统只按文档级授权，可能要么过度开放，要么过度屏蔽。企业 RAG 要根据业务敏感度决定权限粒度，不能一刀切。
检索和重排都要保权限
权限过滤不只发生一次。向量召回前可以根据元数据过滤，召回后还要再次校验；重排阶段不能把无权限片段重新混进候选；缓存检索结果时，也要把用户权限、组织和文档版本纳入缓存键。
权限变化尤其容易出问题。员工转岗、项目结束、文档密级调整后，旧缓存如果还能命中，就可能泄露资料。因此企业 RAG 的缓存失效和权限同步同样重要。
答案要引用可见依据
企业问答最好能给出答案依据，让用户知道回答来自哪些文档片段。依据本身也必须是用户有权访问的。如果答案说得很确定，却不给依据，排查时很难判断是模型推断、资料过期还是权限过滤出了问题。
当然，引用依据不代表把整段敏感内容都展示出来。可以展示标题、段落摘要或可访问片段，根据权限和业务场景控制粒度。关键是系统内部要能追溯这次回答用了哪些资料。
面试里的成熟表达
可以这样讲：企业 RAG 的权限必须前置到检索和上下文构造阶段，不能交给模型自觉。文档要有组织、角色、项目、密级、版本等元数据；召回、重排、缓存和答案引用都要保持权限一致；权限变化后要失效旧缓存，并保留审计链。这样回答，RAG 项目就从“能答问题”升级成了“能在企业里安全使用”。
权限过滤还要处理“无结果”的体验。用户没有权限时，不应该暗示某份文档存在；资料确实不存在时，也不能伪装成权限不足。更稳的做法是给出中性的回答：当前可访问资料中没有足够依据，并在后台记录原因分类，供管理员排查。
这个细节在企业场景很关键。安全系统不仅要防止直接泄露，也要避免通过回答方式泄露组织结构、项目名称或文档存在性。