GraphRAG、Agentic RAG 值不值得用?9 种方案实测说了大实话

致Great

413人浏览 · 2026-06-26 17:37:21

致Great · 2026-06-26 17:37:21 发布

GraphRAG 是不是智商税？AWS 实测 9 种 RAG 方案，结果最强的竟是最朴素的那个

论文：Is GraphRAG Needed? From Basic RAG to Graph-/Agentic Solutions with Context Optimization

机构：Amazon Web Services（AWS）生成式 AI 创新中心 & Cisco

论文链接：https://arxiv.org/pdf/2606.25656

一、研究背景：花里胡哨的 RAG 越来越多，但真的有用吗？

这两年只要做大模型落地，绕不开一个词——RAG（检索增强生成）。它的逻辑很朴素：大模型本身不一定知道某个领域的最新知识，那就先去外部知识库里"翻资料"，把相关内容塞进上下文，再让模型基于这些资料回答。这套方法在"纯文本问答"上已经被验证得很成熟了。

但麻烦在于，真实世界的知识库往往不是一堆干干净净的文本，而是半结构化的：既有大段的文字描述，又有实体之间错综复杂的关系。论文一上来就举了个精准医疗领域的例子，这个问题很能说明痛点：

“哪个基因参与了囊泡运输、位于着丝点、并且参与抗原处理通路？”

你品一下这个问题——它同时要求模型既理解"基因的属性"，又要在多个实体之间做多跳推理（multi-hop）。普通的文本检索 RAG 面对这种问题就有点抓瞎了，因为它压根没有"关系"这层信息。

正因为基础 RAG 在这种场景下力不从心，业界陆续冒出了一堆"进阶版"：

GraphRAG：把知识图谱搬进来，让模型能顺着实体之间的关系做多跳推理；
Modular RAG：把整条流水线拆成一个个可插拔的模块（查询改写、检索、重排序等等）；
Agentic RAG：直接派一个自主智能体出马，让它自己规划、自己调工具、自己迭代纠错。

听起来一个比一个高级。但论文抛出了一个特别扎心的问题：这些复杂架构真的带来了有意义的提升吗？而且，我们现有的评测指标真的能测出它们的差异吗？ 大家都在追新追酷，却很少有人认真把它们和一个"调优过的简单基线"放在一起公平比一比。

于是这篇文章的三大贡献也就出来了。第一，它搭了一个统一的评测框架，实现了 9 种标准化的 RAG 方案，从最基础的文档检索一路覆盖到文本-图谱混合检索、智能体多步规划、智能体+图谱融合等等,全部在同一个半结构化知识库上做对比。第二，它提出了一套上下文工程（context engineering）方法，专治 GraphRAG 和 Agentic RAG 的"上下文/内存爆炸"老毛病，token 用量直接砍掉 19%~53%。第三，也是最有洞察力的一点，它发现了一个叫**“检索-生成鸿沟”（retrieval-generation gap）**的现象——检索得越多，生成质量并没有跟着同比例变好。

二、相关工作：站在哪些人的肩膀上

这块论文写得比较克制，主要交代了三条线索。

第一条是半结构化知识库本身的评测。这领域有个很重要的基准叫 STaRK，专门用来评估"文本 + 关系"这种混合资源上的检索效果；还有大家比较熟的 HotpotQA、ComplexWebQuestions，主要考验多跳推理能力。这篇论文后面的实验就是基于 STaRK 里的精准医疗子集来做的。

第二条是 GraphRAG，核心思路是借助知识图谱做"关系感知"的检索，让模型能利用实体之间的结构信息。

第三条是 Agentic RAG，重点是引入自主智能体，让它动态地编排检索和推理过程。

论文最后点出了一句关键话：把这些方法用在半结构化知识库上，确实同时能享受"图谱的结构精确性"和"智能体的灵活性"两个好处，但它们相比简单基线到底值不值，仍然是个悬而未决的问题——而这正是本文想回答的。

三、核心方法：9 种方案 + 一套省 token 的上下文工程

3.1 先把问题定义清楚

论文沿用了 STaRK 的设定。一个知识库包含一堆文本文档 $D\mathcal{D}$ 和一张知识图谱 $G=(V,R)\mathcal{G} = (\mathcal{V}, \mathcal{R})$ 。其中每个实体 $i$ 对应一篇描述它的文档 $di∈Dd_i \in \mathcal{D}$ ，以及图谱上的一个节点 $vi∈Vv_i \in \mathcal{V}$ ，而 $R\mathcal{R}$ 则是节点之间的各种关系集合。

放到精准医疗的语境里就很好懂了：某个基因或疾病的文档 $d_i$ 写的是它的文字描述，而图谱节点 $v_i$ 编码的是它和别人的关系，比如"副作用"“父子类别”"表现出某种症状"等等。给定一个用户问题 $q$ ，目标就是从知识库里捞出正确的那一组实体和关系来作答。

关键在于：选哪种 RAG 方案，既取决于你手头有没有现成的关系数据，也取决于问题本身有多复杂。所以论文把 9 种方案分成了三大类来逐一拆解。

3.2 三大类、九种方案

第一类是 Regular RAG（普通 RAG）。 场景 1 是最朴素的基线，只索引实体描述文档，靠向量相似度检索，然后把文档拼起来丢给模型生成答案。场景 2 则做了个很简单的小动作——在每篇文档后面，把它在图谱上的 1-hop 邻居按关系类型分组附上去再索引。这是一种不动用图搜索、就能塞进关系信息的偷懒办法，缺点是只能覆盖一跳关系。记住这个场景 2，后面它会有"高光时刻"。

第二类是 GraphRAG。 场景 3 只用预定义的知识图谱、完全不碰文本，纯靠图搜索；场景 4 是反过来——从文档里用 NER + 关系抽取自己算出一张图谱，再配合向量检索；场景 5 则是"混合派"，既做文档向量检索，又在预定义图谱上做 h-hop 遍历，把两边的信息拼成一个综合上下文。它的图谱检索大致是这么几步走：先用 LLM 从问题里抽出实体，再从对应节点做 k 跳遍历提取子图，然后把子图序列化成三元组 $⟨\langle$ 主语, 谓语, 宾语 $⟩\rangle$ 的文本，最后喂给模型生成。

第三类是 Modular & Agentic RAG。 场景 6 是固定流水线：查询改写 → 向量检索 → 重排序 → 生成，一步接一步、规规矩矩。场景 7 把这些模块全变成"工具"交给一个智能体，让它自己决定怎么调、调几次。场景 8 更狠——只给智能体一个检索工具，但在提示词里告诉它"改写、重排、筛选这些活儿你自己脑补着干"，看它能不能内化这些能力。场景 9 则在场景 8 基础上再加一个图谱检索工具，考验它能不能协调两种知识源。

3.3 省 token 的上下文工程：三招 + 一个批量检索

这是论文很实用的一块。作者在跑 GraphRAG 和 Agentic RAG 时发现 token 烧得离谱，经常逼近甚至超出上下文上限。冗余主要来自两处：一是传统三元组格式，两个实体之间有多条关系时，实体名会被反复重复;二是 Strands Agents 这类智能体框架会把整段会话历史塞进每一次调用，导致重叠的子图和重复文档越堆越多。

针对这些问题，论文出了三招。第一招是"关系分组的图表示"，把传统三元组改写成更紧凑的 entity1 - (relation1 relation2 relation3) - entity2 格式。这一下就把 $n$ 条关系的 token 开销从 $O (n)$ 压到了 $O (1)$ 。第二招是图检索去重，整个会话只维护一张统一的子图，新检索到的内容做实体级和关系级去重后再合并，保证上下文是亚线性增长。第三招是文档去重，用内容哈希识别并干掉重复的文档或片段。

除此之外还有一个很巧的设计——批量智能体检索（Hybrid ReAct-ReWOO）。默认的 ReAct 是"想一步、调一次工具、看结果、再想",每次调用都要重发整段历史，特别费 token。论文的做法是让智能体一次性想好多个互补的子问题，打包成一次检索调用搞定，外层还是 ReAct 的迭代判断，内层借鉴了 ReWOO 提前规划的思路。这样 LLM 的来回轮次大大减少，伪代码如下：

Require: 问题 q，检索工具 T，最大迭代次数 K
  M ← ∅                              # 智能体记忆
  for k = 1 ... K do                 # ReAct 外层循环
    {q1, q2, ..., qm} ← PLAN(q, M)   # 思考：拆成多个子问题
    R_batch ← T({q1, ..., qm})       # 行动：一次批量检索（ReWOO 风格）
    R_new ← DEDUP(R_batch, M)        # 加入记忆前先去重
    M ← M ∪ R_new
    if SUFFICIENT(q, M) then break   # 观察：信息够了就停
  end for
  a, E ← GENERATE(q, M)
  return a, E

四、实验效果：一连串"反直觉"的结果

实验用的是 STaRK-Prime 数据集（12.9 万个实体、810 万条图谱关系，来自 PrimeKG），核心 LLM 统一用 Claude 3.7 Sonnet 保证公平。这里有个很重要的细节：论文不像原始 STaRK 那样只评"检索排名"，而是评端到端的生成质量——让模型真正生成自然语言答案、给出一组实体 ID，再拿去和标准答案比。指标包括 Hit@1、Hit@5、Recall@20、MRR，以及 token 用量和检索覆盖率 RoR。

第一个反直觉点：简单加 1-hop 关系，效果竟然干翻了复杂的 GraphRAG。 普通 RAG 里，场景 2（文档 + 1-hop 关系）拿到了 Hit@1 0.6972、MRR 0.7531，是所有基础方法里最好的。而精心设计的混合 GraphRAG（场景 5）最高也就 Hit@1 0.6514 左右，反而被场景 2 这种"土办法"超过了。论文给的解释是：场景 2 把关系按类型分组了，而场景 5 用的是冗长的三元组格式，上下文一长，模型就容易犯"lost in the middle"（中间信息被忽略）的毛病。

第二个反直觉点：纯图谱搜索几乎废了。 场景 3 只靠预定义图谱、不带任何语义信息，Hit@1 只有可怜的 0.1376。这说明光有结构、没有语义，图搜索根本玩不转。而场景 4 那种"自己从文档里算图谱"的方案表现极不稳定，因为自动抽出来的图谱质量远不如预定义的，劣质图谱甚至会拖累最终效果。

第三个反直觉点，也是最有意思的：最强的是工具最少的那个智能体。 在 Modular/Agentic 这一类里，场景 7（智能体 + 多模块工具）赢过场景 6（固定流水线），说明智能体自主规划确实有价值。但真正的赢家是场景 8——只给一个检索工具的自主智能体，拿下了全场最高的 Hit@1 0.6881、MRR 0.7549。更扎心的是，给它开启"思考模式"或加上图谱检索工具（场景 9），不仅没帮上忙，反而变差了。

不过场景 8 也暴露了一个致命问题。论文在附录里贴了一个真实案例：智能体在回答"为什么加州农业密集区前列腺癌发病率上升"时，连续调用了 13 次检索工具，其中有 6 次直接撞上了上下文溢出报错，最后只能越搜越窄、给出残缺答案。这正是上下文工程要救场的地方。

上下文工程的效果也很漂亮：场景 5 在性能基本持平的情况下省了 53% 的 token；场景 9 更典型——优化后不仅省了 24% 的 token，Hit@5 和 R@20 还都涨了；把图谱路径数扩到 500 时，省了 42% 还顺带把各项指标都做上去了。这说明优化不只是省钱，还真的帮智能体更好地消化了扩大后的检索结果。

检索-生成鸿沟：本文最值钱的洞察

这是全文最关键的发现。作者把检索覆盖率和模型实际利用率分开来看，结果触目惊心：在场景 5-Opt（500 路径、20 子图）下，检索覆盖率高达 83.5%，但模型真正提取出来用的只有 47.9%。换句话说，资料明明都捞到了，模型却"视而不见"。

深挖之后，论文总结出三个原因：

第一是位置注意力衰减。被提取的实体平均出现在 token 位置的 10.5% 处，而被漏掉的在 36.8% 处——前者足足早了 3.5 倍。按位置分桶看更明显：前 10% 的实体命中率 85.5%，到 30%~40% 就暴跌到 26.3%，70% 往后基本归零。这就是经典的"lost in the middle"。

第二是模型偏爱"标准答案"而非穷举。在牙龈疾病的案例里（问题用的是复数"哪些疾病"），标准答案有 21 个，检索到了 18 个，模型却只挑了 4 个——它更愿意给出"牙周炎"这种人人都知道的规范术语，而跳过"化脓性根尖牙周炎"这类专业亚型，活脱脱像个做鉴别诊断的临床医生，而不是一个穷举列表的机器。

第三是问题措辞会"暗示"答案数量。在高血压药物的案例里，问题用了单数"What is an investigational…“，结果哪怕有十几个正确答案、而且都排在上下文很靠前的高注意力区，模型也只吐出了一个。单数问法直接让模型以为"只要一个答案就行”。

这三点合起来传达了一个很重要的警示：Hit@k、MRR 这类"检索导向"的指标，很可能高估了高级检索策略的真实收益。评估 RAG 系统时，应该把"检索覆盖率"和"生成利用率"分开来测。

五、论文总结

这篇论文用 9 种方案的硬核实测告诉我们，GraphRAG/Agentic RAG 这类炫酷架构并不是越复杂越好——一个只配一把检索工具的自主智能体，或者给文档简单补上 1-hop 关系的朴素做法，往往就能打赢精心设计的图谱方案；真正卡脖子的不是"检索到多少"，而是模型"能用上多少"，这道检索-生成鸿沟才是 RAG 下一步该攻克的真问题。

对做落地的同学来说，最实用的两个 takeaway 是：别一上来就堆复杂架构，先把简单方案调好；以及一定要分开评测检索和生成，别被漂亮的检索指标骗了。