答案按身份收口：为什么大模型的权限不能放在前端

问题：检索增强会带来一个新的越权入口

业务系统里的越权很好理解：你没权限看那张表，接口就该拒绝你。大模型系统不一样——模型会把检索到的内容「组织」成一句自然语言回答。一旦检索范围超了，越权就不再表现为「看到一条记录」，而表现为「知道了一件不该知道的事」，且往往没人发现。

我们在政务与校园场景里反复遇到同一个提问顺序：先做问答效果，再补权限。这个顺序几乎一定会返工，因为权限会改变检索范围，检索范围会改变答案，答案的评价标准也随之改变。

被排除的三条路径

路径一：前端过滤

拿到全部检索结果后，在页面上隐藏无权查看的条目。问题在于：内容已经进入模型上下文，模型可能已经把它复述进了答案；同时前端可被绕过，日志里也看不出「是系统没给」还是「用户没看」。

路径二：提示词约束

在系统提示里写「不要回答超出用户权限的内容」。这是请求模型的自觉，而不是系统的能力。模型没有权限模型，它只有上下文；上下文里有的东西，它就可能说出来。

路径三：按角色粗分知识库

为每个角色建一套向量库，物理隔离。看似最安全，但角色一多，知识就重复入库、更新不同步；更麻烦的是，多数政企场景的真实要求是「按字段、按项目、按时间」的细粒度，角色维度根本表达不了。

切口：把权限判断放到检索之前

我们的做法是把权限从「生成阶段」前移到「检索阶段」，用一个可配置的权限过滤层来执行：

• 知识入库时打权限标记：来源部门、密级、可见角色、有效期
• 检索请求携带身份上下文，服务端先过滤，再做向量召回与重排
• 答案必须带出处，出处指向被允许的那段原文
• 越权请求留痕：不是「没查到」，而是「被拒绝，理由是什么」

顺序很关键：先过滤，后检索，再生成。反过来就一定会漏。

代价

先说清楚这个选择让客户付出了什么：

• 知识入库前要有人做标记，这部分工作量在校方或委办局一侧，不在我们这一侧
• 检索范围变小，早期「什么都问得到」的演示效果会打折扣，推广时要解释
• 权限变更需要走配置流程，不能靠临时改代码，节奏比「先上线再补」慢

怎么验证它真的成立

不看演示，看四件事能不能被导出：

• 用低权限账号提问，能否稳定检索到高权限文档（应当为否，且拒绝理由可读）
• 随机抽查 20 条答案，能否回溯到被允许的原文段落
• 越权请求日志能否导出「谁、何时、问了什么、被哪条规则拒绝」
• 权限配置变更后，检索范围是否在下次请求即时生效

适用与不适用

适用：政务、公安、高校、医疗等存在分级授权要求的场景；知识源分散在多个部门、需要按项目或字段授权的场景。

不适用：纯公开知识库（如产品手册问答），没有身份分级需求；单用户离线工具，不存在越权面。为这类场景套权限层只会增加成本。

证据边界

本文结论来自我们在政务与校园场景的落地项目，属于工程判断而非研究结论；具体项目的越权测试数据与日志样例未获客户授权公开。若你的场景与上述前提不同（例如知识源完全公开），结论可能不成立，欢迎直接指出来。