Yao Lei
首页文章
←返回文章列表

为什么 GraphRAG 不是 RAG 的下一代

RAG大语言模型AI 应用
13 分钟-阅读

GraphRAG 是为查询聚焦摘要量身设计的方法，不是 dense RAG 的替代品。把它误读成"下一代"，要么钱花错地方，要么把它该上的场景错过。

2024 年下半年开始，技术社交媒体里反复出现一种说法：GraphRAG 是 RAG 的下一代，dense 那一套该退役了。要不要"升级"成了选型会议上的常驻议题。

这个判断里的几乎每个词都需要拆开看。GraphRAG 真正解决的是一类特定问题——对整个语料做全局聚合式提问。它在这类问题上的表现远好于传统 dense RAG，但代价也大得惊人，而且它从设计目标到工程评测都没有针对生产环境里 RAG 真正的痛点（chunk 切错、召回失败、检索范围内的幻觉）。把 GraphRAG 当成 dense RAG 的替代品来用，结果通常是钱花得很多、效果却不一定更好；把它彻底无视，又会错过它本应胜任的那一类问题。

下面按工程视角把这件事拆开。

GraphRAG 是 Microsoft 提出的一个特定方法

把 GraphRAG 还原到出处。这个名字最早出自 Darren Edge、Ha Trinh、Newman Cheng 等 Microsoft Research 团队在 2024 年 4 月 24 日提交到 arXiv 的论文 "From Local to Global: A Graph RAG Approach to Query-Focused Summarization"（arXiv:2404.16130）。同年 7 月 2 日 Microsoft 把对应代码以 MIT 协议开源到 microsoft/graphrag，12 月 16 日发布了 1.0 版本。

论文标题里的"Query-Focused Summarization"是关键限定。论文摘要直接给出 GraphRAG 的目标场景：当用户的问题不是"X 是什么"，而是"这批文档的整体主题是什么"或"过去一年用户最常抱怨的三类问题是什么"——这种需要在整个语料上做归纳的"全局问题"，传统检索 + 生成的 RAG 拿不到足够覆盖。Microsoft 在官方公告里用的措辞是"complex data discovery"和"narrative private data"，从来没有"next-generation RAG"这类话。

GraphRAG 的流水线分两阶段。

索引阶段（offline）：

  1. 把语料切成 TextUnit，默认 600 token、100 token 重叠。和 dense RAG 一样。
  2. 对每个 TextUnit 调 LLM，按预设 prompt 抽取实体（entity name、type、description）和关系（source、target、description）。Claim 抽取默认关闭，Microsoft 自己在文档里写明"claim extraction generally requires prompt tuning to be useful"。
  3. 用精确字符串匹配做实体归并，构建知识图——节点是实体，边是关系，节点和边上都带 LLM 生成的描述。
  4. 在图上跑分层 Leiden 社区检测（Traag et al. 2019），递归到不能再细分。Level 0 是最粗的几个根社区，往上是越来越细的子社区。
  5. 对每一层的每个社区，用一个固定模板的 prompt 由 LLM 自底向上生成社区摘要。

查询阶段（online）有三种模式：

  • Global search：问题先映射到选定层级的所有社区摘要，对每个社区并行调 LLM 生成局部回答，再用 map-reduce 合成最终答案。最少消耗"社区数 + 1"次 LLM 调用。
  • Local search：问题先匹配到实体，沿图扩散到邻接实体、关系、源文本、所在社区摘要，拼成上下文，做一次 LLM 调用。结构上接近 dense RAG，但召回单位是图节点和子图。
  • DRIFT search：2024 年 10 月加入，把 local search 用社区上下文扩展成"先生成跟进问题再聚合"的多轮流程。

Microsoft 在论文里给出的评测方式也值得注意。数据集是两份开放语料：1669 段播客访谈和 3197 篇 AP 通讯社新闻。评价指标不是 accuracy、precision/recall，而是 comprehensiveness、diversity、empowerment 这三项 LLM-judge 偏好。结果是 GraphRAG 在 comprehensiveness 和 diversity 上对 naive RAG 的胜率约 70%–80%，根级摘要在生成代价只占完整摘要 2%–3% 的前提下仍然有竞争力。

这两件事——目标场景限定在 QFS、评测用的是 LLM-judge 主观偏好——基本决定了 GraphRAG 不可能是"全场景升级"。它衡量的不是 RAG 工程师每天在 grafana 上盯的那些指标。

"下一代"叙事错在哪

把 GraphRAG 叙事成下一代 RAG，有几处经不起推敲。

第一，Microsoft 自己从来没这么说。论文标题就是 QFS，2024 年 9 月 Azure AI Foundry 写过一篇官方博文标题就叫 "Unlocking insights: GraphRAG + Standard RAG in Financial Services"——明明白白是 "+"，不是替代。同样 11 月 Microsoft 在 Azure Database for PostgreSQL 上推出的 GraphRAG Solution Accelerator，定位也是"标准 RAG 之上的补充组件"，不是"标准 RAG 的升级"。

第二，GraphRAG 不解决 RAG 在生产环境里真正头疼的几件事：

  • Chunk 边界问题没解决。GraphRAG 仍然先把文档切成 TextUnit（默认 600 token），切错的地方在图里照样错。
  • 召回失败仍然存在。arXiv:2502.11371 这篇 2025 年 2 月的独立 benchmark "RAG vs. GraphRAG: A Systematic Evaluation and Key Insights" 里测出来：在 HotpotQA 上构建出来的图里，只覆盖 65.8% 的答案实体；NaturalQuestions 上覆盖 65.5%。换句话说，34% 的答案信息在实体抽取阶段就被默默丢掉了，连进图的资格都没有。
  • 检索范围内的幻觉。同一篇评测指出 GraphRAG 的 global search 在 MultiHop-RAG 的 Null 查询（理想答案应该是"信息不足"）上表现明显劣于 dense RAG——它会基于社区摘要凭空编出听起来像答案的内容。Microsoft 自己的评测对此没覆盖，因为他们的指标是 comprehensiveness、不是 hallucination rate。

第三，整个生态在 2024 年下半年的演化方向就是给 GraphRAG 减负。Microsoft 自己 2024 年 11 月 25 日就发布了 LazyGraphRAG，把社区摘要从索引阶段推迟到查询阶段，索引代价号称从原版的 99.9% 降下来（与 vector RAG 持平），查询代价号称是原版 global search 的 4%。这是 GraphRAG 公开七个月之后的官方"修正"。如果原版真的是"下一代"，Microsoft 不会这么急着出 v2。

GraphRAG 真赢在哪

否认"下一代"叙事不等于否认 GraphRAG。它在两类问题上确实强：

Query-Focused Summarization / 全局归纳问题。这是论文 setup 的目标场景，也是它真正赢的地方。"这批 5000 份客服记录里反映的主要问题类型是什么""过去三年我们公司发布的产品公告整体呈现什么战略变化"——这种问题用 dense RAG 是没办法答的：你拿 top-5 的检索片段过去生成，模型只能看到样本里的 5/5000，永远归纳不出"整体"。GraphRAG 的社区摘要这一步等于把"整体"提前压缩了一遍，查询时拿到的是整张图层级化的浓缩，自然能讲全局故事。

多跳推理问题。HippoRAG（arXiv:2405.14831，OSU，2024 年 5 月，NeurIPS 2024）在 MuSiQue、2WikiMultiHopQA、HotpotQA 这三个多跳 QA 数据集上对 dense baseline 都有显著领先。arXiv:2502.11371 的独立 benchmark 复核了这点：图结构对多跳推理的检索召回有结构性帮助——dense retrieval 召回的是相似片段，而多跳问题要求的是"沿关系链跳两三步"，相似度索引天然不擅长。

下面这张图把 Microsoft GraphRAG 索引和查询的主要数据流画清楚。

图 1：Microsoft GraphRAG 主要数据流

flowchart TD
  subgraph 索引阶段
    D[文档库] --> T[切成 TextUnit<br/>默认 600 token]
    T --> E[LLM 抽取<br/>实体 + 关系]
    E --> G[构建知识图<br/>节点=实体, 边=关系]
    G --> L[分层 Leiden<br/>社区检测]
    L --> S[LLM 为每个社区<br/>生成摘要]
  end
  subgraph 查询阶段
    Q[用户问题] --> Mode{选模式}
    Mode -- 全局问题 --> GS[Global search<br/>N 个社区并行 LLM<br/>+ 1 次聚合]
    Mode -- 具体实体 --> LS[Local search<br/>子图扩散 + 1 次 LLM]
    Mode -- 跟进追问 --> DS[DRIFT search<br/>local + 社区上下文]
  end
  S -.提供给.-> GS
  G -.提供给.-> LS
  G -.提供给.-> DS

GraphRAG 真输在哪

输的地方同样具体。

事实查询（detail-centric QA）。arXiv:2502.11371 的核心结论之一就是：dense RAG 在"X 的 Y 是什么"这类细节性问题上稳定优于 GraphRAG global search。社区摘要在压缩过程里会丢细节——你把 1000 个 TextUnit 摘成一段 500 字的社区摘要，原文里那个"具体条款第 4.3 款"自然就模糊掉了。global search 出来的回答会显得"什么都讲到一点、什么都不深"。

动态语料。dense RAG 的索引更新成本是"新文档算几个 embedding 写进库"。GraphRAG 不是——新文档会引入新实体、改变关系网、可能让某些社区分裂或合并。彻底重建意味着重跑实体抽取（每片 1 次 LLM 调用）、重跑社区摘要（每个社区 1 次 LLM 调用），成本与原始建索引相当。LazyGraphRAG 的诞生很大程度就是为了规避这个增量痛点——它把社区摘要往后挪到查询时算，索引时就不用面对这个一致性问题。

Null query（"信息不足"应答）。前面已经讲过——global search 倾向于凭社区摘要拼答案，不太愿意承认"这个问题在我索引的语料里没有依据"。这对法务、医疗、金融这类场景是硬伤。

工程账：成本到底差多少

把 dense RAG 和 GraphRAG 的成本摆在一起。所有数字都是 2024–2025 H1 的公开报价或第三方测算。

索引成本（一次性，每百万 token）：

  • Dense RAG：用 OpenAI text-embedding-3-small，约 $0.02。
  • GraphRAG（Microsoft 原版）：
    • Microsoft 自家公布的 Azure AI Foundry 例子：30000 词约 38371 token 索引一次约 $0.34，折算每百万 token 约 $8–9——这是用便宜模型的乐观估计。
    • 第三方估算 GPT-4 级模型做实体抽取：每百万 token $20–50。
    • 业内流传的极端案例：早期 GraphRAG 索引 5 GB 法律语料花了约 $33000。

**这是 10²–10³ 量级的差距。**给一个 10 GB 的中等规模企业语料建一次 dense 索引是个位数美元，建一次 GraphRAG 索引可能在五位数美元。

查询成本（每次提问）：

  • Dense RAG：1 次检索 + 1 次生成 LLM 调用。
  • GraphRAG global search：选定社区层级里每个社区 1 次 LLM 调用 + 1 次聚合 LLM 调用。社区数 N 取决于语料大小和选的层级，通常在几十到几百。即使在 Microsoft 论文里"代价最优"的根级查询，单次问答也比 dense RAG 多用一个数量级以上的 token。
  • GraphRAG local search：与 dense RAG 接近。

增量索引：

  • Dense RAG：新增/修改一个文档 = 重算几个 chunk 的 embedding。几乎免费。
  • GraphRAG：新文档可能改变实体、边、社区结构、社区摘要。完整一致性需要重跑相关部分，工业上通常退化为"每天/每周一次全量重建"。

成本结构本身就告诉你这不是 dense RAG 的替代。替代品的成本结构应该是"差不多 + 效果更好"，而不是"高一到三个数量级 + 在某些问题上更好"。

"GraphRAG"已经是一个伞形词

到 2025 年上半年，"GraphRAG"已经不指代一种方法，而是一组方法的统称。下面这些都自称或被称为 GraphRAG：

  • Microsoft graphrag：原版参考实现，MIT 协议。
  • Microsoft LazyGraphRAG（2024-11）：把社区摘要推迟到查询时。
  • HippoRAG（OSU，2024-05，NeurIPS 2024）：用 Personalized PageRank 在 LLM 构建的 KG 上做检索，模仿海马体索引。专攻多跳 QA。
  • LightRAG（HKUDS，2024-10）：双层（低/高）检索，默认 GPT-4o-mini，公开定位就是 Microsoft GraphRAG 的轻量替代。
  • nano-graphrag（社区，2024 H2）：约 1100 行 MIT 实现，作者明说"官方实现读起来太痛苦"。
  • FastGraphRAG：用 NLTK/spaCy 抽名词短语 + 共现做边，跳过 LLM 实体抽取。
  • LangChain langchain-graphrag：把 Microsoft 规范移植到 LangChain，支持非 Azure LLM。
  • LlamaIndex PropertyGraphIndex（2024-05 引入，0.11 加强）：相对独立的属性图设计，不完全跟 Microsoft 走。
  • Neo4j neo4j-graphrag + GraphRAG Manifesto（2024-07）：把知识图谱作为"解决 RAG 准确性"的卖点，是数据库厂商视角。

这九种方法在"图是什么形态、谁来抽实体、要不要做社区检测、查询走 global 还是 local"上各不相同。说"GraphRAG 是下一代"，等于在说一组结构不同、代价不同、目标场景不同的方法是同一个方法。这种话讲不通。

真正的"下一代"在哪里

GraphRAG 不是 RAG 的下一代，那真正的下一代在哪里？答案可能是这个问题本身问错了——RAG 不会被某一个东西"替代"，它正在按问题分化成几条平行的流水线。

Hybrid retrieval（dense + sparse + cross-encoder rerank）。这是 2024–2025 工业界最稳的方案。BM25 与 dense embedding 用 RRF 融合做粗排，cross-encoder 做精排。它解决的是 dense RAG 召回不稳的痛点，工程成熟度远高于 GraphRAG，效果也更稳定。它没有论文标题党，但它是默认配置。

Self-reflective / agentic RAG。Self-RAG（Asai et al., arXiv:2310.11511, 2023-10）、Adaptive-RAG（Jeong et al., 2024）、CRAG（Yan et al., 2024）这一系列工作处理的是 RAG 在生成端的失败模式——什么时候该检索、检索回来不够好怎么再来一次、答案要不要带置信度声明。这一类方法处理的恰好是 GraphRAG 没碰的那部分问题。

长上下文作为小语料的备选。Gemini 1.5 Pro 在 1M token 上 needle-in-a-haystack 召回 99.7%（厂商数据，多 needle 场景下回落到约 60%），但每次调用比 RAG 贵约 1000 倍，延迟也高 30–60 倍。在语料规模 < 1M token 且查询频次不高的场景下，长上下文可以直接替代 RAG。Google DeepMind 2024 年 7 月 arXiv:2407.16833 的 Self-Route 给出的混合方案据测可以为 Gemini-1.5-Pro 减 65% 成本。

GraphRAG 系列。处理全局归纳问题和多跳推理问题。

这四条线并行存在，没有一条"取代"另一条。

选型决策

实际工程里怎么挑？按问题类型走，不按时间新旧走。

问题类型 例子 默认选择
单文档事实查询 "X 的退货政策是什么" Dense RAG（hybrid + rerank）
多跳推理 "A 的供应商是 B，B 上次违约是什么时候" GraphRAG / HippoRAG
全局归纳 "过去一年用户最常抱怨的三类问题" GraphRAG global search
需要"信息不足"应答 合规/法务问答 Dense RAG + 引用 + 置信度
动态语料 新闻、客服记录 Dense RAG（GraphRAG 增量成本太高）
静态语料 / 小规模 一本书、几十份合同 长上下文或 Dense RAG
生成端失败模式重 答错时检测不出 Self-RAG / CRAG

下面这张图把选型路径画清楚。

图 2：RAG 选型决策

flowchart TD
  Q[新需求] --> A{语料规模?}
  A -->|小或静态, 不超过 1M token| LC[长上下文]
  A -->|中大或动态| B{问题类型?}
  B -->|找具体事实| C[Dense RAG + Hybrid + Rerank]
  B -->|多跳关系推理| D[GraphRAG 或 HippoRAG]
  B -->|全局归纳总结| E[GraphRAG global search]
  B -->|不确定问题边界| F[Self-RAG 或 Adaptive-RAG]
  C --> R[评估 + 调优]
  D --> R
  E --> R
  F --> R
  LC --> R

实际生产里的混合模式

生产环境里的成熟做法基本是混合。Microsoft 自己的 Azure 文档反复强调 GraphRAG 和 Standard RAG 应该联用：日常 QA 走 dense（毫秒级、便宜），周度/月度的分析报告走 GraphRAG（小时级、按需触发）。在 Microsoft 2024 年 11 月发布的 Azure Database for PostgreSQL GraphRAG Solution Accelerator 里，0.5M 美国判例的法律研究助手就是这种结构——日常案例查询走 dense + 引用，跨案例的法理趋势分析走图。

更细一点的工程做法：

  • 索引时 dense 向量和图共用一份 TextUnit 切片，避免两套切片维护成本。
  • 实体抽取作为 dense RAG 的 metadata 附加，召回时同时返回 chunk 和 chunk 上挂的实体——这就是 LlamaIndex PropertyGraphIndex 默认的形态。
  • 查询路由层用一个 LLM 判断问题类型，决定走哪条路径——这正是 Adaptive-RAG 的设计。

注意这套做法里 GraphRAG 是其中一个组件，不是"系统升级"。把它当替代品上线，往往是先经历一波账单震惊，然后回退到 hybrid + GraphRAG 按需。

一句话结尾

GraphRAG 不是 RAG 的下一代，是 RAG 在"全局归纳"这一类问题上的分化产物。把它当替代品来推销或选型，对它和 dense RAG 都是误解；把它放在"按问题选工具"的工具箱里，它的位置就清楚了。

参考资料

YL

我是姚磊

大模型应用开发者，关注 RAG、Agent 和产品化工程。沉淀实践中的判断、踩坑记录和可复用方法。联系我：yaolei_agent@163.com

LLM AppsRAGProductEngineering Notes
评论
相关文章

如何为 AI Agent 构建记忆：从 Trace 到可复用上下文

2026-06-24

Loop Engineering 的艺术：如何为 Agent 叠加有效循环

2026-06-16

如何构建自定义 Agent Harness：把模型接入真实世界的脚手架

2026-06-03