Appearance
2.4 权限、时效性与知识治理
如果说前面几节讨论的是“怎么把知识放进来”,这一节讨论的就是“放进来之后,怎么保证知识一直可控、可更新、可隔离”。
真正上线的 RAG 系统,知识治理从来不是附属功能,而是基础能力。
这一节尤其要避免一个常见误区:
把治理理解成“后面再补的后台能力”。
现实里,权限、版本、时效、多租户边界一旦没有在数据和检索链路里提前设计,后面通常很难靠局部修补补回来。因为这些问题会直接进入:
- 数据接入
- 元数据设计
- 索引组织
- 查询过滤
- 上下文构造
- 缓存策略
- 审计追踪
所以这一节的重点不只是“为什么重要”,而是“在工程上到底应该怎样把这些边界做进去”。
这一节真正想帮你建立的,是一个更接近上线系统的视角:
知识库不是把内容存进去就结束了,而是要持续回答“谁能用、什么时候能用、当前还能不能用”这几个问题。
如果这些问题没有被系统稳定回答,知识越多,后面的风险往往越大。
学这一节时,最值得先建立的判断
在继续往下看之前,最好先把这几个判断立住:
- 权限边界必须进入检索和上下文构造,不是只停留在前端展示层
- 版本和时效不是附加信息,而是知识是否可被使用的基本条件
- 多租户隔离不是“用户看不到别人的页面”这么简单,而是要防止别人的知识进入当前回答链路
- 治理能力不是上线以后再补的后台功能,而是数据接入和索引设计阶段就要开始考虑的基础约束
这一节会回答什么问题
学这一节时可以重点带着三个问题看
- 这条知识是否允许当前用户使用?
- 这条知识在当前时间是否仍然有效?
- 这条知识是否属于当前租户或当前业务边界?
如果系统不能稳定回答这三个问题,就很难算真正具备生产级知识治理能力。
读完这一节后,你最好还能更稳地判断:
- 某个权限问题到底应该在接入层、检索层还是上下文构造层解决
- 某个版本问题更像更新链路问题,还是索引和缓存失效问题
- 某个多租户风险更适合逻辑隔离,还是已经该升级到更强的隔离方式