知识库搜得到，不等于看得到

一家做工业设备维保的公司，去年给售后团队上了内部知识助手。销售在群里问：华东那家客户的维保合同，今年续签价是多少。

助手答了，还把合同里那一页贴了出来。

问的人没有这份合同的权限。问的人也没有绕开系统，系统更没有报错。是检索这一步，把无权限的合同片段当成了相关材料，一起交给了模型。

一、答案不是模型编的，是检索先取错了

内部知识助手做事分两步。第一步，按问题去知识库（公司文档集中存放、能被检索的那一套）里找相关片段；第二步，把片段和问题一起交给模型，让模型组织成一句话。

两步之间有一个默认假设：找出来的片段，问的人都能看。

这个假设在演示环境里通常成立。演示用的文档是产品手册、公开报价、入职须知。

到了真实环境，同一个库里还放着合同、人事档案、故障报告、客户名单。

检索只比较文字像不像，不问「这个人能不能看」。它会把最像的几条一起交上去。

二、错在候选那一层，不在最后一句

很多人第一反应是给答案加一道检查：生成完再看一眼，发现敏感内容就遮掉。

这道检查挡不住开头那个例子。

生成之前，模型已经读过了无权限的合同页。模型可能换一种说法复述价格，也可能把客户名、折扣、付款条件换一种说法写进答案。

更麻烦的是，读过的内容不只留在答案里。检索日志、调用追踪、评测记录、缓存（把算过的结果存起来，下次直接用），都可能留下一份。

OWASP 的大模型应用风险清单里有一项叫「向量与嵌入弱点」。它指的不是检索库本身有漏洞，而是检索这一层常常缺少传统数据库那样的访问控制和审计。

越权发生在「取」这一步。只在「说」这一步拦，已经晚了。

三、提示词不是权限边界

有的团队把「不许透露无权内容」写进系统提示词，觉得这样就能管住。

系统提示词是给模型的指令，不是访问控制。模型可以遵守，也可能被一段更强势的材料带偏。

2026 年 10 月 30 日，一篇公开的企业知识库实践文章把这句话写成了第一条原则：提示词不是权限边界。

把保密交给模型的自觉，等于把门锁交给一个可以商量的对象。

四、正确顺序：先问能不能看，再问像不像

做法并不复杂。用户提问时，先拿到身份和可见范围，再把范围作为过滤条件带进检索。

检索只在可见材料里找。候选集从一开始就不含无权限的片段。

2026 年 10 月 23 日，另一篇公开的企业知识库实践文章，把登录上下文与文档授权放在业务层，检索服务只接收过滤后的范围。

行业里把这种做法叫检索前过滤（pre-filter）。反过来，先取回一批再删掉无权限的，叫检索后过滤（post-filter）。

顺序一换，后面的答案、日志、缓存都跟着干净。

五、权限从哪里来，不要另建一套

身份接现有的登录系统，组织关系接现有的人员名单。文档权限接文档系统自己的授权。

不要为知识助手另建一套「知识库权限」。另建一套，很快就会和业务系统分叉。

员工离职，业务系统停了账号，知识库里还留着；项目结束，项目成员名单清了，检索范围还开着。

单点登录只回答「你是谁」，不回答「你能看哪几份」。后一个问题要回到文档系统去问。

六、文档的权限要落到片段上

一段长文档进库前会被分成小段，行业里叫切片（把长文档分成小段再入库）。切片之后的每一段，都要继承原文档的权限。

元数据（附在片段上的说明字段）至少要带四样：租户或公司、文档编号、版本、可见范围。

只带文档编号不够。文档改了版，旧片段可能还在库里；权限范围变了，旧片段还按老范围被取出来。

一份材料同时属于两个项目时，按更严的那份算，不按更松的那份算。

七、两路检索都要过滤

企业知识库通常不只一路检索。一路按关键词找，一路按向量找（向量是把一段文字变成的一串数字，用来比较意思近不近）。

关键词这一路有权限过滤，向量这一路没有，漏就漏在没过滤的那一路。

两路结果合并之前，各自都要带上同一个范围。合并之后再排，不能先排完再删。

过滤之后候选会变少，召回（该找回来的材料里实际找回来多少）会下降。要把候选池放大一些，再取最相关的前几条。

八、缓存会把答案送到别人手上

语义缓存（按问题的意思存答案，不按字面）最危险。两个销售问的意思差不多，系统直接把前一个人的答案给了后一个人。

如果前一个人能看那份合同，后一个人不能，这一下就漏了。

缓存键至少要带三样：用户或角色、租户、权限版本。权限一变，旧键作废。

检索结果的缓存、嵌入结果的缓存，同样要带范围。只按问题文本做键，迟早串。

九、日志和评测集是第二个漏点

为了排查问题，很多系统把完整的检索上下文写进日志。这等于把越权材料复制到另一个地方。

日志里留编号、长度、耗时就够了。正文按权限脱敏，或者只对授权的人可见。

调用追踪也一样。一次请求里带了哪几段材料，追踪系统往往记得比业务库还全。

评测集更容易被忽略。造题时把真实合同、真实客户名单放进去，评测本身就在制造泄露。

十、权限变了，索引要跟得上

文档撤回、密级调整、项目结束、员工转岗，都会让可见范围变化。

如果权限只在建索引时算一次，下一次全量重建之前，旧范围一直有效。这个窗口可能是一天，也可能是一周。

两种做法可以配合。关键文档在检索时实时查一次权限，慢一点但准；普通文档把权限版本写进片段，变更时增量更新。

窗口会持续多久，要写进系统说明。别让业务方以为「撤回了就立刻看不到」。

十一、给出处，点开还要再验一次

答案附上来源是好事。但来源链接不能绕过权限。

用户点开原文时，按当前身份再校验一次。校验不过，就提示这份材料无权查看，而不是把正文直接展开。

检索层漏了一条，查看层还有一道门。两道门都过的材料，才真正到了用户眼前。

这也让越权更容易被发现：用户点不开，说明检索那一步有问题。

十二、怎么验：专门造一批该拒答的题

只看答案准不准，测不出越权。要按角色造题。

销售问合同价，客服问人事档案，外包问架构图，实习生问管理层会议纪要。每一题的正确结果都是拒答。

两条线一起看：越权率（不该答的答了几条）和漏答率（该答的没答几条）。

上线前跑一遍。换模型、换索引、改权限之后，再跑一遍。

十三、落地顺序：六步，别从缓存开始

第一步，接身份，拿到用户和可见范围。第二步，给文档和片段打上权限元数据。第三步，检索前过滤。第四步，缓存键带权限。第五步，日志、追踪、出处脱敏。第六步，越权评测。

每一步都能单独验收，不用等整套做完。

语义缓存放在最后。前面几步没做稳就上缓存，等于给漏点加了一个放大器。

十四、三种常见做法，各自漏在哪

只做租户隔离：公司之间分开了，同一公司内部的部门、项目、客户之间照样互相可见。

只做目录权限：目录这一层管住了，表格里的行、附件、图片里的信息不跟着走。

只做答案后过滤：答案遮住了，候选被占用、日志有副本、换个说法照样漏。

三种做法都不是错，只是各自只盖住了一部分。要盖住整条路，权限得在检索那一步就在场。

十五、小团队的最小做法

如果只有几十个人、文档不算多，不必一上来就做全套。

先接组织架构，按部门和项目两个维度打标签，检索前按标签过滤。缓存先关掉，日志只留编号。

不要自建权限中心。用现有系统的成员名单，每天同步一次；合同、人事这类关键文档，检索时实时查。

先做到「不该看的搜不到」，再谈「答得准」。顺序反过来，越做越危险。

十六、跟站内几篇的分工

《大模型进业务系统，第一道关不是模型，是权限》讲入口该先管什么。

《智能体的权限，加上去谁收回来》讲权限只加不减会出什么问题。

《智能体读走数据，我们怎么自己先发现》讲已经读走之后怎么发现。

《AI 答得不准，先别急着换模型》讲检索质量本身。

这一篇只讲一件事：检索那一步，权限要在场。