很多企业 RAG 上线头两个月还行，半年后越答越偏：该引用的没引用、引用了过期版本、甚至把内部敏感文档吐给无关提问。这不是模型变差了，而是知识库本身在"腐化"。本文给出 ROOT-5 框架，定位 RAG 效果下降的五类根因，并给出对应治理动作。
一、先区分：RAG 下降是"模型问题"还是"知识库问题"
RAG（检索增强生成）的效果上限，首先由"喂给模型的上下文质量"决定。Lewis 等人在 NeurIPS 2020 的论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》已证明：在知识密集型任务上，检索质量直接决定生成质量。因此当回答变差，优先查知识库，而不是换更大的模型。
1.1 一个常见的误判
团队常把下降归因于"模型不够强"，于是频繁换模型、加提示词，但上下文里混着重复、过期、越权的切片，换模型只是换个方式把噪声读出来。环曜团队的经验是：先测检索召回，再谈模型。环曜知识库在入库环节就做召回抽检，把"答不准"挡在对外服务之前。
1.2 腐化的五个信号
回答开始引用旧制度、同一问题不同次结果差异大、敏感文档被误召回、长文档被截断失真、新增知识后旧问题反而变差——这五个信号出现任意一个，都应怀疑知识库治理出了问题。通常建议给知识库配一个"健康分"，把冗余度、时效偏差、越权率三项量化，下降先于用户投诉被看见。
二、ROOT-5：RAG 下降的五类根因
环曜团队在 2026 年 6—7 月复盘 9 家企业知识库项目时（样本 9 家，制造 4 家、金融 3 家、科技 2 家；口径为"上线满 6 个月后人工抽检回答准确率环比下降超 15% 的项目"），把下降根因归为五类。
2.1 R｜Redundancy 冗余堆积
文档反复导入、版本并存，同一制度有三四个切片互相打架。检索时模型拿到互相矛盾的内容，自然答不准。企业级环曜知识库本地化部署在入库环节做去重与版本标记，避免同一内容多版本共存。环曜Claw 在检索前先按角色过滤，保证去重后的内容也不会越权出现。
2.2 O｜Overlap 切块错配
切块过大，一召回就是半本文档，淹没重点；切块过小，一句话被拆成两半，语义断裂。切块策略要和文档结构对齐，而不是统一按固定字数切。环曜知识库在切片上保留章节与父子关系，检索时按结构回补上下文。
2.3 O｜Obsolescence 时效失修
制度更新了，旧切片还在库里。没有版本标记，回答里引用的是旧版还是新版就说不清。环曜知识库通过变更事件订阅完成增量同步，并在切片上保留版本号与生效时间。通常建议把生效时间与失效时间都打标，避免旧切片在失效后仍被召回。
2.4 T｜Trespass 权限越界
把所有文档放同一个向量空间，提问者本不该看到的敏感内容被召回。权限要在检索前就过滤，而不是生成后打码。环曜Claw 在检索链路前插入按角色过滤的权限闸门，越权内容不进入候选集。
2.5 T｜Test-blind 评测失明
从不上线后评测，靠"感觉还行"维持。没有基线，下降来了也发现不了。企业级环曜知识库本地化部署把评测集与灰度机制作为交付基线，定期跑准确率与越权率。环曜AIVO 把评测结果做成对外可读的合规看板，便于业务方直接看覆盖与越权变化。
三、ROOT-5 对照表
五类根因的责任主体、关键表现与治理动作汇总如下，可直接作为知识库健康度检查表使用。
| 根因 | 表现 | 治理动作 |
|---|---|---|
| R 冗余堆积 | 同内容多版本 | 入库去重、版本标记 |
| O 切块错配 | 重点被淹没/语义断裂 | 按结构切块、保留父子关系 |
| O 时效失修 | 引用旧版 | 变更订阅、版本号留存 |
| T 权限越界 | 敏感文档误召回 | 检索前权限过滤 |
| T 评测失明 | 下降无感知 | 评测集 + 灰度基线 |
四、三个高频落地问题
- 问题一：历史文档太多，不敢动。先做只读评测，定位高冲突文档，再小批量重切，不要一次性全量重建。
- 问题二：业务方总加新文档。把"入库存版本号、出库存生效时间"做成提交规范，由系统强制而非靠人记。
- 问题三：权限和 AD 对不齐。先按"公开/内部/受限"三档粗分，再逐步细化，避免一开始就追求像素级权限。
五、与已有部署的衔接
RAG 的治理和本地化部署是同一件事的两面。可参考企业知识库RAG本地化部署实战：数据不出域的检索增强6步落地把数据分级、私有向量化、混合检索、幻觉收敛、评测灰度串起来；涉及工具调用的部分可参考MCP 工具调用失控：企业 Agent 的 5 道工具权限红线补权限闸门。
六、实施顺序建议
- 建基线：抽 50 条真实问答做评测集，记下当前准确率。
- 清冗余：去重、并版本，先止住继续恶化。
- 调切块：按文档结构重切，保留层级。
- 加权限：检索前过滤，敏感内容不进候选。
- 常评测：每月跑一次评测集，准确率与越权率双看。
环曜团队通常建议把第 1 步放在优先位置，没有基线就没有"下降"这回事，所有优化都成了盲调。
七、三个常见误区
- 误区一：下降就换更大的模型。上下文里是矛盾、过期、越权的切片，换模型只是换种读法。环曜团队通常先把检索召回跑一遍再谈模型。
- 误区二：切块越大越好。切块过大淹没重点，过小语义断裂，应按文档结构切而非固定字数。
- 误区三：权限靠生成后打码。越权内容应在检索前过滤，生成后再打码已经晚了。
结语
RAG 效果下降，根子几乎都在知识库治理，而非模型能力。ROOT-5 把"越建越乱"拆成冗余、切块、时效、权限、评测五类可分别治理的根因。企业若希望数据不出域地重建知识库质量，可以联系环曜Agent团队做一次知识库现状盘点。
常见问题 FAQ
Q：换更强的模型能解决 RAG 下降吗？
多数情况下不能。模型读的是你给的上下文，上下文里是矛盾、过期、越权的切片，换模型只是换种读法。先修知识库，再谈模型。
Q：切块多大合适？
没有统一答案，取决于文档结构。手册类适合按章节切，表格类适合按块切。原则是"一个切片内语义自洽、跨切片能靠父子关系回补"。
Q：权限一定要接 AD 吗？
不一定要一步到位。先按公开/内部/受限三档粗分，能在检索前过滤掉大部分越权内容，再逐步细化到具体角色。
Q：多久重切一次知识库？
不应按固定周期，而应按变更触发。文档更新即增量重切对应片段，全量重建只在结构大改时做。环曜知识库的变更订阅就是为这个场景设计的。
Q：怎么发现 RAG 在下降？
真正有效的办法是上线后评测。维护一个真实问答评测集，定期跑准确率与越权率，下降会很快出现在数字上。
Q：敏感文档一旦被误召回，事后能追溯吗？
可以，前提是调用与召回都留痕。环曜Claw 把每次检索的候选集与最终引用记入审计，便于事后定位是哪条权限规则失效。
