Agentic RAG 选型：GraphRAG 还值得投入吗

RAG 系统的选型正在变得尴尬。

一边是 GraphRAG。它把文档里的实体、关系、社区或层次结构提前抽取出来，试图让检索不再停留在“query 和 chunk 谁更相似”这一层。多跳问答、跨文档归纳、实体关系追踪，这些任务确实更像是在一张知识结构上行走。

另一边是 Agentic Search。它不急着离线建图，而是让大语言模型在推理过程中自己决定要不要检索、搜什么、搜几轮、什么时候停止。一次检索找不到答案，就改写查询再搜；证据不完整，就继续追问下一个线索。结构不一定提前建好，而是在多轮搜索里动态形成。

问题也随之变得直接：如果模型已经能边推理边检索，还需要为 GraphRAG 支付额外的离线构图成本吗？

论文 Do We Still Need GraphRAG? Benchmarking RAG and GraphRAG for Agentic Search Systems 正是在回答这个问题。它配套开源了 RAGSearch，把 Dense RAG、GraphRAG 以及多种 Agentic Search 系统放到同一套 benchmark 里比较。它的结论不是“GraphRAG 胜利”，也不是“GraphRAG 过时”，而是更接近工程现场的判断：

Agentic Search 会显著抬高 Dense RAG 的上限，尤其在搜索策略设计良好或经过 RL 训练时；但在复杂多跳推理、稳定性和小模型场景中，GraphRAG 仍然有明显价值。

这篇论文适合当作 RAG 系统选型的技术决策材料来读。它关注的不是单个方法的榜单排名，而是把几个关键变量拆开：有没有图结构、有没有 agent、多轮搜索怎么设计、模型大小如何影响图结构收益、离线成本和在线效率是否值得。

RAG 的两条升级路线

传统 Dense RAG 的流程很清楚：文档切块，向量化，建立索引；用户提问时，把问题转成向量，在向量库里找相似片段，再交给模型生成答案。这个方案工程上轻，更新方便，适合大量事实性问答。

它的问题也很清楚。一次检索很脆弱。

例如用户问：“某家公司收购另一家公司后，对它的云服务产品线有什么影响？”答案可能分散在公司公告、产品文档、新闻稿和财报里。Dense RAG 如果第一轮只命中其中一段，模型很容易基于残缺证据回答。

GraphRAG 的思路是提前把知识组织起来。系统不只保存文本块，还会抽取实体和关系，或者构建层次摘要、社区结构、超图结构。查询进入系统后，检索可以沿着实体、关系或层次节点扩展。它的优势不是“语义相似度更强”，而是给多跳问题提供了更明确的路径。

Agentic Search 则换了一个方向。它把检索过程交给模型调度。模型可以先查一个线索，再根据结果生成下一次查询，直到证据足够。例如：

问题：A 公司的某项合作后来影响了哪条产品线？
第 1 轮：检索 A 公司合作事件
第 2 轮：根据合作对象检索相关业务线
第 3 轮：检索产品更新或财报描述
第 4 轮：整合证据并回答

这类系统的关键不在于“多搜几次”，而在于每一轮搜索都由上一轮证据驱动。好的 agent 会分解问题、验证证据、发现缺口；差的 agent 只是把相似查询重复几遍，甚至把噪声带进上下文。

图 1：Dense RAG、GraphRAG 与 Agentic Search 的差异

flowchart TD
  Q["用户问题"] --> D["Dense RAG: 一次向量检索"]
  D --> A1["基于检索片段生成答案"]

  Q --> G["GraphRAG: 沿图结构检索"]
  G --> E["实体 / 关系 / 层次节点"]
  E --> A2["整合结构化证据生成答案"]

  Q --> S["Agentic Search: 多轮搜索决策"]
  S --> R1["检索第一批线索"]
  R1 --> R2["改写查询或分解子问题"]
  R2 --> R3["继续检索与验证"]
  R3 --> A3["基于搜索轨迹生成答案"]

GraphRAG 提供的是离线结构，Agentic Search 提供的是在线结构。两者并不冲突，但它们消耗的成本不同：GraphRAG 主要消耗离线构图成本，Agentic Search 主要消耗在线推理延迟和更多模型调用。

RAGSearch 做了什么

RAGSearch 的贡献在于把两个变量拆开比较：底层 retriever 是否使用图结构，上层是否使用 agentic search。

论文覆盖的检索后端包括 Dense-RAG、HippoRAG2、LinearRAG、RAPTOR、GraphRAG 和 HyperGraphRAG。它们代表了从纯向量检索，到实体图、层次结构、超图结构等不同路线。

上层 agentic search 系统分为两类：

类型	代表方法	特点
训练无关 Agent	Search-o1、GraphSearch	主要依赖 prompt、工作流设计、查询分解和证据验证
RL 训练 Agent	Search-R1、Graph-R1	通过强化学习优化搜索策略，让模型学习何时检索、检索什么、如何利用结果

这套设计让论文能够回答一个更细的问题：GraphRAG 的优势到底来自图结构本身，还是来自更复杂的 agent 设计？如果 Dense RAG 换上强 agent，它和 GraphRAG 的差距会缩小到什么程度？

为了减少评测偏差，论文统一了 LLM backbone、检索预算和推理协议，并在完整测试集上报告结果。测试覆盖 general QA 和 multi-hop QA，前者更接近单跳事实问答，后者要求跨多个证据完成推理。

这个设置很重要。RAG 系统在真实应用里不能只看准确率，还要看预处理成本、在线延迟、稳定性和维护成本。一个方案如果在某个 benchmark 上高出几个点，却需要昂贵的离线构图和复杂的维护流程，未必适合高频更新的知识库。

结论一：单跳问题不太需要图，多跳问题非常吃结构

论文最清楚的一组结果来自 single-shot 设置，也就是不引入多轮 agent，只比较一次检索时 Dense RAG 和 GraphRAG 的差异。

在 general QA 上，Dense RAG 与 GraphRAG 几乎打平，GraphRAG 平均只领先约 0.47 分。这个结果不难理解。单跳事实性问题通常只需要找到一个相关片段，例如“某篇论文的作者是谁”“某个产品支持什么功能”。只要 chunk 切分合理、向量检索命中关键段落，显式图结构的额外收益有限。

在 multi-hop QA 上，GraphRAG 的优势变得很大，平均领先约 27.23 分。多跳问题通常要求系统先定位一个实体，再沿着关系找到另一个实体，最后把多个证据合并。例如：

问题：写过作品 A 的作者，他出生城市所在国家的首都是哪里？
步骤 1：找到作品 A 的作者
步骤 2：找到作者出生城市
步骤 3：找到城市所属国家
步骤 4：回答该国家首都

Dense RAG 很可能在第一轮检索中只命中作品 A 的介绍，而漏掉出生城市或国家信息。GraphRAG 如果提前抽取了实体和关系，就能沿着“作品 - 作者 - 出生地 - 国家 - 首都”的链路扩展。

这说明 GraphRAG 的核心价值不是让所有问题都更准，而是让结构性问题更稳。对于企业知识库也是一样：如果用户主要问“某条制度是什么”，Dense RAG 足够；如果用户问“某项制度如何影响不同部门的审批链路”，结构化检索的价值会明显上升。

结论二：Agentic Search 能增强 Dense RAG，但设计差异很大

引入 Agentic Search 后，Dense RAG 的表现确实会提升。它可以补救一次检索失败：第一轮结果不完整，就换一个查询继续搜；证据互相冲突，就再找验证材料。

但论文也给了一个提醒：多轮检索本身不是保证。

Search-o1 + Dense 的结果并不稳定，在某些多跳数据集上甚至低于 single-shot。原因可能是通用多轮交互缺少足够强的约束，模型多搜几轮后反而引入无关证据。GraphSearch + Dense 的提升则更明显，因为它把 query decomposition 和 evidence verification 这类步骤显式写进工作流。

这个差异对工程实践很有用。很多系统接入 agent 后，会把“可多轮检索”误认为“会正确检索”。实际上，agent 需要明确的搜索纪律：

搜索能力	没有约束时的风险	更可靠的做法
查询改写	换词但不换信息需求	根据缺失证据生成下一轮查询
问题分解	把问题拆得过碎或偏题	按实体、时间、关系拆成可验证子问题
证据验证	把早期错误继续放大	要求后续检索验证关键断言
停止判断	搜索不足或搜索过度	以证据覆盖度而不是轮数决定停止

因此，Dense RAG + Agentic Search 的效果上限很高，但前提是 agent 的工作流设计足够认真。只是在提示词里写“请多轮搜索”，通常不够。

结论三：RL 有帮助，但不一定比好工作流更划算

论文比较了训练无关 agent 和 RL-based agent。Search-R1、Graph-R1 这类方法会通过强化学习训练模型的搜索策略，让模型学会什么时候调用检索、如何生成查询、怎样利用返回结果。

结果显示，RL agent 确实能稳定超过对应的 training-free baseline。这说明搜索策略是可以被训练出来的，尤其当任务有明确奖励信号时，模型可以逐渐学会更有效的检索行为。

但论文也观察到，RL agent 常常输给设计良好的 GraphSearch。GraphSearch 不依赖训练，却通过显式工作流把问题分解、证据检查等步骤编码进推理路径。

这个结果并不矛盾。RL 的优势是灵活，但它需要从数据和奖励中学会行为模式；工作流的优势是直接，把人类已经知道有效的搜索结构写进系统。对于很多团队来说，先做一个可解释、可调试的搜索工作流，可能比直接训练 RL agent 更现实。

一个典型的落地顺序可以是：

1. 先实现 Dense RAG + reranker，保证基础召回。
2. 增加 query decomposition，让复杂问题拆成多个可检索子问题。
3. 增加 evidence verification，要求关键结论至少有证据支撑。
4. 记录线上搜索轨迹和失败案例。
5. 查询量和标注条件成熟后，再考虑训练搜索策略模型。

这样做的好处是每一步都能独立验证，不需要一开始就承担 RL 训练的成本。

结论四：GraphRAG 不只是更准，也更稳

GraphRAG 的优势不只体现在平均准确率上，还体现在稳定性上。论文使用 document hit rate 和 Contain-EM 方差等指标观察检索与答案波动，结果显示 GraphRAG 更容易命中正确文档，多次运行之间的答案波动也更低。

这个结论在生产系统里很关键。线上用户不只关心系统“平均是否聪明”，也关心它是否稳定。有些 RAG 系统最麻烦的地方不是一直错，而是同一个问题今天答对、明天答偏；一次给出完整证据，下一次只找到半段上下文。

GraphRAG 的稳定性来自提前组织好的结构。实体和关系一旦抽取完成，检索路径不完全依赖 query 与 chunk 的相似度，也不完全依赖模型临场发挥。对于金融、法律、医疗、科研问答这类场景，稳定性往往比一点平均分更重要。

但稳定性有代价。构图要消耗离线计算，语料更新后还要维护图结构。如果知识库每天大量变化，GraphRAG 的维护成本可能抵消它在检索稳定性上的收益。

结论五：模型越大，图结构的边际收益越小

论文还做了 backbone 尺寸相关的分析。结果显示，LLM 越强，GraphRAG 相对 Dense RAG 的优势越小。

在 RL-based 系统中，3B 模型下 GraphRAG 与 Dense RAG 的平均差距约为 +14.70；到 7B 时，差距缩小到约 +9.75。在 training-free 系统中，从 7B 到 32B，GraphRAG 相对 Dense 的平均 gap 也继续缩小。

这说明更大的模型可以用在线推理能力补回一部分离线结构能力。它能更好地分解问题，更好地理解检索结果，也更能在多轮搜索中维持任务目标。

不过这不等于大模型可以完全替代 GraphRAG。大模型的在线结构是临时生成的，容易受到早期检索结果影响；GraphRAG 的离线结构则更可复用、更可控。它们的差别更像两种成本分配：

成本位置	代表方案	优势	风险
离线结构	GraphRAG	可复用、稳定、适合多跳关系	构图贵，语料更新后维护复杂
在线推理	Agentic Search	灵活，适合动态知识库	延迟高，搜索轨迹可能不稳定
训练策略	Search-R1 / Graph-R1	可学习搜索行为	需要训练数据、奖励设计和评测闭环

如果使用的是较小模型，图结构能补足模型推理和长链检索能力的不足；如果使用的是更强模型，Dense RAG + Agentic Search 的竞争力会上升。

选型时该看哪些条件

RAGSearch 给出的答案可以整理成一个决策框架。

优先选择 Dense RAG + Agentic Search 的情况：

• 用户问题以单跳事实问答为主。
• 知识库更新频繁，重建图谱成本高。
• 查询模式变化大，很难提前设计稳定结构。
• backbone 足够强，能通过多轮搜索补足部分结构能力。
• 团队需要快速迭代，先验证业务价值。

优先选择 GraphRAG + Agentic Search 的情况：

• 用户问题以多跳推理、实体关系、跨文档综合为主。
• 知识库相对稳定，离线构图成本可以被长期查询摊销。
• 对稳定性、可解释性、证据链完整性要求高。
• 使用较小模型，需要外部结构弥补推理能力。
• 错误答案的业务代价较高，例如金融、法律、医疗、科研场景。

Retriever 的选择也可以更具体一些。多跳推理为主时，实体中心的图结构更容易给 agent 提供明确线索；长文档需要分层归纳时，RAPTOR 这类层次结构更自然；通用问答和高频更新知识库仍然适合从 Dense FAISS 类方案起步。

Agent 设计上，如果没有训练预算，优先把 GraphSearch 风格的显式工作流做好，包括问题分解、检索、证据验证和答案整合。如果有训练预算，再考虑 Search-R1 / Graph-R1 这类 RL-based 方案，并关注 GRPO 等更适合长序列策略优化的训练算法。

一个更实用的混合架构

论文最有启发的地方，不是把 GraphRAG 和 Agentic Search 放在对立面，而是说明结构可以出现在不同位置。

稳定、高价值、关系密集的知识，可以离线构成图。频繁变化、时效性强、结构不稳定的内容，可以交给 Dense RAG 和 Agentic Search 在线检索。上层 agent 再根据问题类型决定走哪条路径。

图 2：混合式 Agentic RAG 架构

flowchart TD
  Q["用户问题"] --> C["问题路由"]
  C -->|单跳事实 / 高频更新| D["Dense RAG"]
  C -->|多跳关系 / 稳定知识| G["GraphRAG"]
  C -->|复杂不确定| H["混合检索"]

  D --> A["Agentic Search 控制器"]
  G --> A
  H --> A

  A --> V["证据验证"]
  V --> O["生成答案与证据引用"]

这种架构的重点是不要把所有知识都图谱化，也不要把所有复杂性都推给在线 agent。系统可以先用问题路由判断复杂度：简单事实走 Dense RAG，多跳关系走 GraphRAG，不确定问题走混合检索。这样既能控制离线成本，也能把图结构用在最值得的位置。

在工程实现上，可以从一套最小可用配置开始：

Dense RAG + reranker
  -> 增加 query decomposition
  -> 增加 evidence verification
  -> 标记多跳失败案例
  -> 对稳定高频实体构图
  -> 引入 GraphRAG 路由

这条路径比“一开始全量构图”更稳，也比“只靠 agent 临场搜索”更可控。

这篇 benchmark 的边界

RAGSearch 的价值在于控制变量和横向比较，但它的结论仍然有边界。

第一，Agentic Search 方法的选择会影响结论。Search-o1、GraphSearch、Search-R1 和 Graph-R1 覆盖了典型路线，但不能代表所有 agent 设计。更强的工具调用框架、更细的状态管理、更好的 memory 机制，都可能改变 Dense RAG 与 GraphRAG 的差距。

第二，GraphRAG 方法的实现质量差异很大。不同实体抽取器、关系抽取策略、社区摘要方式、图遍历策略，都会影响最终表现。统一 benchmark 能保证公平，但未必等于每个方法的最佳工程形态。

第三，公开 QA benchmark 与真实业务问题仍有距离。HotpotQA、2WikiMultiHopQA、MuSiQue 能很好地测试多跳推理，但企业内部知识库还涉及权限、时效性、版本冲突、表格和附件解析等问题。

第四，成本计算需要放回业务场景。离线构图的成本是否可接受，取决于语料规模、更新频率、查询量和错误代价。同样一套 GraphRAG，在论文库里可能划算，在每天更新的大规模客服知识库里可能不划算。

这些边界不会削弱论文结论，反而提示了它的正确用法：把它当作选型框架，而不是照搬答案。

结论：GraphRAG 没有消失，只是位置变了

Agentic Search 改变了 RAG 系统的能力边界。Dense RAG 不再只能做一次相似度检索，它可以在 agent 的调度下多轮搜索、逐步补证据、动态构造推理路径。对大量单跳问答和中等复杂度问题，这已经足够有效。

GraphRAG 的价值也没有消失。它仍然适合复杂多跳推理、关系密集知识库和稳定性要求高的场景。它的问题不是“有没有用”，而是“成本是否值得”。

更准确的判断是：结构没有被 Agentic Search 消灭，而是被重新分配了。它可以存在于离线图谱里，也可以存在于 prompt 工作流里，还可以由模型在多轮检索中临时生成。工程选型的关键，是决定哪一部分结构应该提前构建，哪一部分结构应该在线生成，哪一部分结构值得通过训练学出来。

如果知识库变化快、问题简单、模型足够强，Dense RAG + Agentic Search 是更轻的起点。如果问题多跳、语料稳定、错误代价高，GraphRAG 仍然值得投入。真正稳妥的方向，很可能不是纯 Dense，也不是纯 Graph，而是让 Dense RAG、GraphRAG 和 Agentic Search 在同一个系统里按问题类型协同工作。

参考资料

• Do We Still Need GraphRAG? Benchmarking RAG and GraphRAG for Agentic Search Systems：https://arxiv.org/abs/2604.09666
• RAGSearch GitHub Repository：https://github.com/FanDongzhe123/RAGSearch
• Search-o1：https://arxiv.org/abs/2501.05366
• Search-R1：https://arxiv.org/abs/2503.09516
• GraphSearch：https://arxiv.org/abs/2509.22009
• Graph-R1：https://arxiv.org/abs/2507.21892