企业级RAG系统正从单纯的知识检索演变为复杂的知识治理体系。权限控制、版本管理、评测机制与BadCase闭环等关键环节，决定了系统能否长期可信。本文深度剖析知识库运营中的五大核心挑战，揭示如何构建既能精准回答又能持续进化的智能知识管理系统。

第一篇我写的是知识入库：文档解析、文本切片、召回、重排，这些决定了 RAG 能不能找到正确知识。

但知识能被找到，只是第一步。

真正进入使用阶段后，问题会变得更复杂：谁能看什么？旧制度还能不能答？答错了怎么发现？用户点踩之后谁来修？每个 chunk 要不要打权限、版本、来源、责任人这些元数据？知识库没人维护，会不会慢慢变脏？

到这一步，RAG 就不只是检索和生成了，而是变成了一套知识治理系统。

一、权限过滤必须发生在检索前

企业 RAG 里，权限是最容易被低估、但又最不能出错的部分。

很多人会下意识觉得，只要在提示词里告诉大模型“敏感信息不要回答”，就能解决权限问题。但这其实不够。

大模型不是权限系统。它只能基于你给它的上下文回答。真正的权限控制，必须发生在检索之前。

这里要区分两个概念：知识库分区和权限过滤。

知识库分区解决的是“资料放在哪个房间”，权限过滤解决的是“这个人有没有门禁”。

比如一个市场部员工问：

北京出差住宿能报多少？

系统可以先判断这是报销类问题，路由到财务制度库。但这不代表他可以看到财务库里的所有内容。普通员工只能看全员可见的报销标准，不能看到财务内部预算表、成本测算表或供应商底价。

换成产品规则，就是：

• 这个问题属于“报销制度”范围；
• 只查询当前有效的知识；
• 只查询全员可见或该员工有权限查看的内容；

不查询财务内部预算、供应商底价、部门专属表格。

这就是为什么每个 chunk 都要打元数据。这里的元数据不一定要理解成数据库字段，产品经理更应该把它理解成一套“知识使用规则”：这条知识属于哪个业务范围、谁能看、是否当前有效、来源在哪里、出了问题找谁确认。

如果这些规则没有在入库时定义清楚，后面检索时就只能靠模型猜，这对企业场景是不够安全的。

二、制度会更新，旧知识不能继续被默认召回

知识库上线后，制度一定会变。

报销标准会调整，审批流程会变化，代理商入驻材料会更新，旧截图会失效。如果没有版本治理，知识库很快就会出现新旧口径混在一起的问题。

比如旧版制度里写：

北京住宿报销上限 400 元。

新版制度改成：

北京住宿报销上限 200 元。

如果两个 chunk 都被召回，大模型就可能给出冲突答案。它可能回答 400，也可能回答 200，甚至把两者混在一起。

所以每条知识都需要有状态。为了好理解，可以先分成三类：未审核、当前有效、已废弃。

旧制度不一定要删除，但必须退出默认问答范围。也就是说，旧版 400 元那条可以保留为历史记录，但知识状态要从“当前有效”改成“已废弃”。系统默认只使用“当前有效”的知识回答问题，避免新旧口径同时进入上下文。

如果只改了一条规则，不一定要把整份文档重新跑一遍入库流程。更稳的做法是对新旧文档做差异对比，定位变更章节，只重新处理变化部分。

比如系统识别到：

旧值：北京住宿上限 400 元

新值：北京住宿上限 200 元

变更章节：差旅报销标准 > 一线城市住宿标准

变更类型：金额规则变更

这条变更应该进入待审核状态，由财务 owner 确认。审核通过后，新 chunk 设为当前有效，旧 chunk 退为历史版本。

这里的关键不是“谁点了上传按钮”，而是“谁对内容负责”。

一个更稳的发布流程应该是：

这样做不是为了把流程复杂化，而是为了避免 RAG 在看似正常回答时，把旧制度也一起带进上下文。

三、没有评测集，就不知道优化有没有用

RAG 系统不能只靠“感觉回答得还行”来判断效果。

评测要拆开看。因为一个错误答案，可能来自不同环节：可能是没召回正确资料，可能是资料召回了但模型答偏了，也可能是回答看起来对，但业务上没有解决用户问题。

我更倾向于把 RAG 评测拆成三层：

评测指标也不是一刀切。RAG 很难一开始所有指标都 100%，但要分清哪些指标可以通过迭代逐步提升，哪些指标必须作为上线红线。

这些阈值不是固定标准，更像试点阶段的参考线。不同业务的容忍度不一样，关键是先区分“可以通过运营慢慢优化的问题”和“上线前就必须挡住的红线问题”。

不同行业的评测重点也不同：

所以，RAG 评测不是追求所有指标一开始都 100%，而是要区分哪些指标可以迭代提升，哪些指标必须作为上线红线。

四、BadCase 不是失败，是知识库进化入口

上线之后，BadCase 很重要。

用户点踩、转人工、重复追问、低相似度召回、无答案兜底，这些都不是单纯的失败记录，而是系统继续优化的入口。

关键是不要只记录“这个回答错了”，而是要知道错在哪里。

不同类型的 BadCase，对应的修复方向也不一样。召回错误要回到检索链路，知识缺失要补资料，权限问题要修知识规则，版本问题要处理新旧状态，多轮上下文问题要做上下文拼接和指代消解。

所以 BadCase 管理不是客服记录，而是一套知识库运营机制。它的价值不在于证明系统错了，而在于让每一次错误都能变成下一轮优化的入口。

一个 RAG 系统能不能变好，不只看第一次回答得怎么样，更看它有没有把错误沉淀成下一轮优化。

而要做到这一点，靠的不是某一个 Prompt，而是长期的知识库维护机制。

五、没人负责维护，RAG 会慢慢变脏

知识库不是一次性交付的资料仓库。

它会过期，会重复，会冲突，会被新增内容污染，也会因为没人维护而慢慢失去可信度。

所以除了技术字段，还需要组织流程。

技术上可以有版本字段，但真正决定知识库是否可信的，是组织流程：谁提交、谁审核、谁发布、谁负责下线旧内容。

如果这些责任不清楚，RAG 知识库很快会变成一个看起来智能、实际上没人敢信的资料仓库。

我更认可把知识库当成一个长期运营的产品，而不是一个上传文档的功能。

它至少需要三类角色：

RAG 的知识库不是越大越好，而是越新、越准、越有边界越好。

结尾：可信赖比能回答更重要

第一篇讲知识入库，决定了回答效果的上限。

这一篇讲权限、版本、评测、BadCase 和维护机制，决定了系统能不能长期可信。

跑通链路只能说明技术可行，真正能长期使用，靠的是权限、版本、评测和 BadCase 闭环。

RAG 做到最后，不只是让大模型“能回答”，而是让用户知道：这个答案来自哪里，是否当前有效，我有没有权限看，出了问题谁会修。

这也是我理解的企业级 RAG：不是一个问答入口，而是一套持续运转的知识治理系统。