Skip to content

2.4 权限、时效性与知识治理 ​

如果说前面几节讨论的是“怎么把知识放进来”,这一节讨论的就是“放进来之后,怎么保证知识一直可控、可更新、可隔离”。

真正上线的 RAG 系统,知识治理从来不是附属功能,而是基础能力。

这一节尤其要避免一个常见误区:

把治理理解成“后面再补的后台能力”。

现实里,权限、版本、时效、多租户边界一旦没有在数据和检索链路里提前设计,后面通常很难靠局部修补补回来。因为这些问题会直接进入:

  • 数据接入
  • 元数据设计
  • 索引组织
  • 查询过滤
  • 上下文构造
  • 缓存策略
  • 审计追踪

所以这一节的重点不只是“为什么重要”,而是“在工程上到底应该怎样把这些边界做进去”。

这一节真正想帮你建立的,是一个更接近上线系统的视角:

知识库不是把内容存进去就结束了,而是要持续回答“谁能用、什么时候能用、当前还能不能用”这几个问题。

如果这些问题没有被系统稳定回答,知识越多,后面的风险往往越大。

学这一节时,最值得先建立的判断 ​

在继续往下看之前,最好先把这几个判断立住:

  • 权限边界必须进入检索和上下文构造,不是只停留在前端展示层
  • 版本和时效不是附加信息,而是知识是否可被使用的基本条件
  • 多租户隔离不是“用户看不到别人的页面”这么简单,而是要防止别人的知识进入当前回答链路
  • 治理能力不是上线以后再补的后台功能,而是数据接入和索引设计阶段就要开始考虑的基础约束

这一节会回答什么问题 ​

学这一节时可以重点带着三个问题看 ​

  1. 这条知识是否允许当前用户使用?
  2. 这条知识在当前时间是否仍然有效?
  3. 这条知识是否属于当前租户或当前业务边界?

如果系统不能稳定回答这三个问题,就很难算真正具备生产级知识治理能力。

读完这一节后,你最好还能更稳地判断:

  • 某个权限问题到底应该在接入层、检索层还是上下文构造层解决
  • 某个版本问题更像更新链路问题,还是索引和缓存失效问题
  • 某个多租户风险更适合逻辑隔离,还是已经该升级到更强的隔离方式