别急着给 RAG 加 Agent，先看复杂性放错了没有

Mon, 29 Jun 2026 21:05:03 +0800

内部知识库上线以后，最怕的不是它直接说“不知道”。

最怕的是它回答得很顺。

用户问：“远程办公政策对外包同事怎么适用？”系统召回了远程办公制度，给了一段完整解释，甚至还附了引用。看起来没问题。但真正限制写在外包合同里，它没召回。

这时候团队很容易有一个冲动：加一个 agent，让它自己检查，自己重查，自己判断答案够不够。

听起来合理。

但你先别急。

很多 RAG 系统的问题，不是因为它还不够 agentic，而是最基础的检索账没算清楚：chunk 切得太粗，metadata 没用起来，rerank 没有，文档新旧混在一起，评估集也没有。这个时候上 Agentic RAG，只是让系统用更多 token、更长链路、更难调试的方式，继续召回错误材料。

RAG 选型里最容易误判的一点就在这里：标准 RAG、Graph RAG、Agentic RAG 不是从低级到高级的升级路线。

它们真正的区别，是复杂性放在哪里。

标准 RAG 把复杂性放在固定检索管线里。Graph RAG 把复杂性提前做成图谱和摘要这些索引资产。Agentic RAG 把复杂性放到运行时，让 agent 每次查询时做拆解、选源、判断和重试。

复杂性不会消失。你只是决定让谁承担它。

标准 RAG：如果答案就在文档里，它仍然是起点

标准 RAG 的基本流程，大多数人已经很熟：用户问题转成 embedding，到向量库里找相似片段，取 top-K chunks，塞给 LLM，让它基于上下文生成答案。

这套东西看起来简单，但简单不是缺点。

在很多企业知识库场景里，它反而是优势：路径短、成本低、延迟可预测，出了问题也比较容易定位。你能看到召回了哪些 chunks，能检查 prompt，能看 rerank 前后顺序，能把错误归到“没召回”“召回了但排序靠后”“上下文太长被淹没”“文档本身过期”。

这就是工程系统里很重要的一件事：可解释的失败，比聪明但黑盒的失败好处理得多。

标准 RAG 适合的问题，通常有几个特征：

用户问题比较明确。
答案通常就在少数文档片段里。
知识源比较干净，比如 FAQ、产品手册、内部制度、开发者文档。
业务更在意稳定、便宜、低延迟。

比如员工问“年假怎么折算”，客服问“退货周期是多少”，开发者问“这个 API 的鉴权参数怎么传”。这类问题不需要系统像侦探一样跨系统调查。它只需要把正确片段找出来，不要把相似但无关的片段拿回来。

标准 RAG 真正脆弱的地方也在这里。

它通常不会主动判断：我召回来的这些东西，真的回答了问题吗？

如果 top-K 错了，后面的 LLM 往往会基于错误上下文写出一个很像回事的答案。尤其是企业知识库，很多制度文档长得很像，标题也像，语气也像。相似不等于有用，但向量检索很容易把“相似”当成“答案”。

知识库 on Zampo Blog

别急着给 RAG 加 Agent，先看复杂性放错了没有

标准 RAG：如果答案就在文档里，它仍然是起点