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

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

最怕的是它回答得很顺。

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

这时候团队很容易有一个冲动：加一个 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 往往会基于错误上下文写出一个很像回事的答案。尤其是企业知识库，很多制度文档长得很像，标题也像，语气也像。相似不等于有用，但向量检索很容易把“相似”当成“答案”。

所以，当标准 RAG 答错时，第一步不是问要不要上 Agentic RAG，而是先做失败归因：

• 正确文档有没有进索引？
• chunk 有没有把关键条件切断？
• metadata 有没有区分地区、角色、时间、生效状态？
• 是否需要 hybrid search，而不是只靠向量相似度？
• rerank 有没有把真正回答问题的片段推上来？
• 答案有没有引用，引用能不能回到原文？
• 有没有一套固定评估集，持续看召回和答案质量？

这些东西没做好，agent 也救不了你。

它最多只是帮你把同一个坏索引查三遍。

Graph RAG：问题不在片段里，而在关系里

标准 RAG 问的是：“哪几个文本片段和这个问题最像？”

Graph RAG 问的是另一个问题：“这些实体、关系和主题怎么连起来？”

这两句话差别很大。

很多文章把 Graph RAG 简化成“RAG + 图数据库”。这个说法太粗了。图数据库可以是实现方式之一，但 Graph RAG 的核心不是换一个存储引擎，而是把实体、关系、社区主题这类结构提前抽出来，做成可以检索的索引资产。

举个更贴近企业内部的例子。

用户问：“这个客户去年几次投诉，最后都和哪些系统改动有关？”

答案可能不在某一个 chunk 里。它散在 CRM、工单、会议纪要、发布记录、事故复盘里。你要先知道“客户 A”对应哪些合同、哪些工单、哪些服务；再看这些服务背后关联哪些系统；再把发布时间线串起来。

标准 RAG 可能召回几段看起来相关的投诉记录。但它不知道哪些实体需要连起来，也不知道“客户—工单—系统—发布—事故”这条路径才是问题的骨架。

Graph RAG 的价值就在这里。

它把原始文本里的实体和关系抽出来，让检索不只停留在“相似片段”，而是能沿着关系找上下文。Microsoft GraphRAG 里的 Local Search，就是把知识图谱里的结构化数据和原始 text chunks 结合起来：先找到和用户问题语义相关的实体，再取 connected entities、relationships、community reports 和相关文本片段，排序过滤后给 LLM。

还有一类问题更明显：全局主题。

比如：“这批客户访谈里，最集中的三个抱怨是什么？”

这不是找某个片段。因为没有一个 chunk 天生写着“本文档全集的前三个主题”。标准向量检索很难靠 query similarity 找到正确上下文。Graph RAG 的 Global Search 会依赖提前生成的 community reports，用 map-reduce 的方式从整体结构里汇总答案。

这就是 Graph RAG 的适用边界：

• 法律、合规、政策，条款和主体之间关系很密。
• 生物医学、科研语料，实体关系和多跳路径很重要。
• 企业组织知识，人、项目、系统、服务、决策记录互相缠在一起。
• 用户问的不是某一段文档，而是“这批材料整体说明了什么”。

但 Graph RAG 不是免费午餐。

它把复杂性提前了，也把成本提前了。

你要做实体抽取、关系抽取、社区发现、摘要生成。你还要维护更新。文档一变，关系可能也要变；实体抽错，后面的推理路径就会歪；语料规模上来以后，构建和增量更新都不轻。

所以 Graph RAG 不适合拿来装饰一个简单 FAQ 系统。

如果你的问题就是“请假流程在哪里”，用图谱绕一圈，大概率只是让系统更贵、更慢、更难维护。

Graph RAG 应该出现在关系真的值钱的地方。

Agentic RAG：它多出来的是决策点，不是魔法

Agentic RAG 最吸引人的地方，是它看起来更像“人”。

它可以读懂问题，拆成子问题，决定查哪个数据源，检索以后再判断材料够不够。不够，就换个 query，换个 source，再查一次。最后再综合回答。

这确实比一次检索、一次生成更灵活。

但灵活这件事，在工程里永远有价格。

Agentic RAG 多出来的不是一个“更聪明”的标签，而是一串运行时决策点：

• 要不要拆问题？
• 拆成哪几个子问题？
• 先查文档库，还是先查 SQL，还是调 API？
• 这次检索结果算不算够？
• 不够的话，是改写 query，还是换数据源？
• 最多重试几次？
• 两个来源冲突时听谁的？

每一个决策点都可能提高答案质量，也都可能引入新的错误。

拆错问题，会把简单问题变复杂。选错工具，会查错系统。评估器判断错，会把不充分的证据当成充分。retry 没边界，会把延迟和成本打穿。trace 不完整，线上排查时你甚至说不清楚它为什么走到这个答案。

这不是理论洁癖。生产系统里，Agentic RAG 最大的问题往往不是“能不能跑”，而是“错了以后怎么解释”。

标准 RAG 错了，你至少能看召回结果。Agentic RAG 错了，你要看的是整条路径：原始问题怎么被改写，拆成了什么，调用了哪些工具，每一步拿到了什么，为什么判断够了，最后又怎么综合。少一段日志，排查就断了。

所以 Agentic RAG 适合的问题，应该真的值得这些运行时决策：

• 用户问题模糊，需要先改写或拆解。
• 证据散在多个系统里，比如文档、数据库、工单、代码仓库、外部网页。
• 第一次检索经常拿到“相关但不回答问题”的材料。
• 回答前需要检查证据是否充分，是否冲突，是否需要重查。
• 业务可以接受更高延迟、更高 token 成本和更复杂的观测链路。

比如一个内部技术支持助手，用户只说“上周支付回调失败那次后来怎么处理的？”

这句话里有时间、有系统、有事故、有处理结果。系统可能要查事故记录、发布记录、支付服务日志摘要、工单评论，甚至还要判断“上周那次”到底指哪次。这个时候，固定 top-K 检索很容易不够。Agentic RAG 的 source routing、query refinement、retrieval validation 才有价值。

但如果用户问的是“报销单最多多久审批完”，你让 agent 自由思考三轮，就有点过了。

别忘了：Agentic RAG 的价值来自决策点，成本也来自决策点。

三种 RAG 的区别，可以这样记

标准 RAG 解决的是：答案在文档里，怎么找出来。

Graph RAG 解决的是：答案在实体关系和全局结构里，怎么串起来。

Agentic RAG 解决的是：我还不确定该怎么查，查完也不确定够不够。

这三句话比“谁更先进”有用。

因为真实系统很少按名词选型。你面对的是一堆失败样本：这个问题没召回，那个答案没引用，这类查询总是漏掉跨部门限制，另一些用户问得太模糊，系统不知道该查哪里。

这时你要做的不是把架构图画得更豪华，而是把失败分类。

如果 70% 的错误来自基础检索：文档没入库、chunk 切坏、metadata 缺失、rerank 不行、知识库过期，那你应该先修标准 RAG。

如果错误集中在实体关系、多跳路径、全局主题，那 Graph RAG 更相关。

如果错误集中在查询模糊、证据分散、需要检索后判断，那 Agentic RAG 才更相关。

我会用这五个问题做第一轮判断。

第一，答案是否通常能在少数文档片段里找到？

如果是，优先标准 RAG。别为了显得先进，把一个文档问答系统改成小型推理引擎。

第二，问题是否依赖实体关系、多跳关联或全局主题？

如果是，考虑 Graph RAG。尤其是法律、合规、组织知识、服务依赖这类关系密集的场景。

第三，问题是否经常模糊，需要拆解或跨多个数据源？

如果是，考虑 Agentic RAG，或者更现实一点：先做 Hybrid RAG。比如固定管线加 query rewrite、retrieval validation、有限 retry，不要一步到位把所有检索权都交给 agent。

第四，业务能不能承受更高延迟和不稳定成本？

Agentic RAG 的延迟不是固定多 100ms 这么简单。一次 query 可能变成多次 LLM 调用、多次工具调用、多次检索。你得先问清楚：这个业务允许吗？用户等得起吗？账单扛得住吗？

第五，当前失败主要来自哪里？

这是最关键的一问。

别从方案倒推问题。先拿失败样本说话。

给每条错误打标签：召回错、排序错、上下文不够、文档过期、问题模糊、跨源缺失、证据冲突、生成偏离。标完你会发现，很多团队以为自己需要 Agentic RAG，其实只是没有认真做过 retrieval evaluation。

更现实的演进顺序：先基线，再结构，再循环

如果从零做企业知识库，我不建议一开始就设计成 Agentic RAG。

更稳的顺序是三步。

第一步，做一个足够干净的标准 RAG 基线。

文档清洗、chunk 策略、metadata filter、hybrid search、rerank、引用、评估集。这些活不性感，但它们决定了系统下限。没有这个基线，你后面加任何复杂结构，都不知道到底提升了什么。

第二步，看失败是不是集中在关系和全局问题。

如果用户总是问“这个政策和那个合同怎么同时适用”“这个服务变更影响哪些客户”“这批反馈的主线是什么”，再引入 Graph RAG。先从小范围实体和关系开始，不要一上来抽整个公司的知识图谱。

第三步，只在确实需要运行时判断时，加有限 Agentic 能力。

这里的关键词是“有限”。

给 agent 设边界：可用工具、最多调用次数、最多 token、超时、fallback、trace、每一步证据记录。不要让它在生产环境里自由探索。自由探索适合 demo，不适合一个有 SLA、有预算、有审计要求的系统。

很多时候，中间态反而最实用：标准 RAG 管主链路，关键查询加 query rewrite 和 retrieval validation；某些关系型问题走 GraphRAG retriever；真正复杂的跨源调查，再交给 agent 调度。

这比“全面升级 Agentic RAG”更像工程。

最后还是那句话：先别崇拜复杂度

RAG 系统做久了，很容易把问题归到“架构还不够高级”。

标准 RAG 答错了，就想 Graph RAG。Graph RAG 还不够，就想 Agentic RAG。Agentic RAG 出错了，再加 evaluator、planner、critic、memory。链路越来越长，图越来越漂亮，问题却不一定更少。

因为很多系统缺的不是更多智能，而是更清楚的责任边界。

标准 RAG 负责把确定问题的答案找出来。Graph RAG 负责把稳定关系和全局结构沉淀下来。Agentic RAG 负责处理那些确实需要运行时判断的不确定问题。

别让它们互相背锅。

下次你的 RAG 又答错了，先别问“是不是该上 Agentic”。

先把错误样本摊开，问一句更工程的问题：

这次失败，是固定管线没做好，是关系结构没建出来，还是查询本身真的需要运行时决策？

如果只是 chunk 烂、索引旧、rerank 缺失，上 Agent 只是在更贵地犯同样的错。

能用固定管线解决的问题，不要交给运行时 agent。

能用索引资产解决的问题，不要每次查询都重新思考。

— Zampo