GraphRAG 是不是智商税AWS 实测 9 种 RAG 方案结果最强的竟是最朴素的那个论文Is GraphRAG Needed? From Basic RAG to Graph-/Agentic Solutions with Context Optimization机构Amazon Web ServicesAWS生成式 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}D和一张知识图谱G ( V , R ) \mathcal{G} (\mathcal{V}, \mathcal{R})G(V,R)。其中每个实体i ii对应一篇描述它的文档d i ∈ D d_i \in \mathcal{D}di​∈D以及图谱上的一个节点v i ∈ V v_i \in \mathcal{V}vi​∈V而R \mathcal{R}R则是节点之间的各种关系集合。放到精准医疗的语境里就很好懂了某个基因或疾病的文档d i d_idi​写的是它的文字描述而图谱节点v i v_ivi​编码的是它和别人的关系比如副作用“父子类别”表现出某种症状等等。给定一个用户问题q qq目标就是从知识库里捞出正确的那一组实体和关系来作答。关键在于选哪种 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 nn条关系的 token 开销从O ( n ) O(n)O(n)压到了O ( 1 ) O(1)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再拿去和标准答案比。指标包括 Hit1、Hit5、Recall20、MRR以及 token 用量和检索覆盖率 RoR。第一个反直觉点简单加 1-hop 关系效果竟然干翻了复杂的 GraphRAG。普通 RAG 里场景 2文档 1-hop 关系拿到了 Hit1 0.6972、MRR 0.7531是所有基础方法里最好的。而精心设计的混合 GraphRAG场景 5最高也就 Hit1 0.6514 左右反而被场景 2 这种土办法超过了。论文给的解释是场景 2 把关系按类型分组了而场景 5 用的是冗长的三元组格式上下文一长模型就容易犯lost in the middle中间信息被忽略的毛病。第二个反直觉点纯图谱搜索几乎废了。场景 3 只靠预定义图谱、不带任何语义信息Hit1 只有可怜的 0.1376。这说明光有结构、没有语义图搜索根本玩不转。而场景 4 那种自己从文档里算图谱的方案表现极不稳定因为自动抽出来的图谱质量远不如预定义的劣质图谱甚至会拖累最终效果。第三个反直觉点也是最有意思的最强的是工具最少的那个智能体。在 Modular/Agentic 这一类里场景 7智能体 多模块工具赢过场景 6固定流水线说明智能体自主规划确实有价值。但真正的赢家是场景 8——只给一个检索工具的自主智能体拿下了全场最高的 Hit1 0.6881、MRR 0.7549。更扎心的是给它开启思考模式或加上图谱检索工具场景 9不仅没帮上忙反而变差了。不过场景 8 也暴露了一个致命问题。论文在附录里贴了一个真实案例智能体在回答为什么加州农业密集区前列腺癌发病率上升时连续调用了 13 次检索工具其中有 6 次直接撞上了上下文溢出报错最后只能越搜越窄、给出残缺答案。这正是上下文工程要救场的地方。上下文工程的效果也很漂亮场景 5 在性能基本持平的情况下省了 53% 的 token场景 9 更典型——优化后不仅省了 24% 的 tokenHit5 和 R20 还都涨了把图谱路径数扩到 500 时省了 42% 还顺带把各项指标都做上去了。这说明优化不只是省钱还真的帮智能体更好地消化了扩大后的检索结果。检索-生成鸿沟本文最值钱的洞察这是全文最关键的发现。作者把检索覆盖率和模型实际利用率分开来看结果触目惊心在场景 5-Opt500 路径、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…“结果哪怕有十几个正确答案、而且都排在上下文很靠前的高注意力区模型也只吐出了一个。单数问法直接让模型以为只要一个答案就行”。这三点合起来传达了一个很重要的警示Hitk、MRR 这类检索导向的指标很可能高估了高级检索策略的真实收益。评估 RAG 系统时应该把检索覆盖率和生成利用率分开来测。五、论文总结这篇论文用 9 种方案的硬核实测告诉我们GraphRAG/Agentic RAG 这类炫酷架构并不是越复杂越好——一个只配一把检索工具的自主智能体或者给文档简单补上 1-hop 关系的朴素做法往往就能打赢精心设计的图谱方案真正卡脖子的不是检索到多少而是模型能用上多少这道检索-生成鸿沟才是 RAG 下一步该攻克的真问题。对做落地的同学来说最实用的两个 takeaway 是别一上来就堆复杂架构先把简单方案调好以及一定要分开评测检索和生成别被漂亮的检索指标骗了。