> 声明：本文是对 Microsoft Research 论文《From Local to Global: A Graph RAG Approach to Query-Focused Summarization》（arXiv:2404.16130，2024 年 4 月提交、2025 年 2 月修订）的技术解读，所有方法描述与评测数据均来自该论文及微软公开文档。涉及其他系统的对比，仅基于其官方公开说明，未核实的细节一律不写。

传统向量 RAG 解决了「从一堆文档里找几段相似内容来回答问题」，但有一类问题它结构性地答不好：

「这批资料整体反映了哪些主题？」
「过去三年这个方向的核心转变是什么？」
「这几百篇论文共同定义了什么叫 state of the art？」

这类问题的答案不在任何单个文档块里，而是分散在整个语料中、需要归纳汇总。微软在 2024 年把这个问题正式提出来，并给出了一套至今仍是标杆的解法，叫做 GraphRAG。这篇文章把论文拆开讲清楚，最后落到一件对你做知识库产品更实际的事：GraphRAG 这种「重图谱」路线，和你现在手里的「轻量图谱」到底差在哪，什么时候该上、什么时候是杀鸡用牛刀。

## 一、论文是谁，解决的是什么病

论文全名《From Local to Global: A Graph RAG Approach to Query-Focused Summarization》，第一作者 Darren Edge，Microsoft Research，2024 年 4 月挂在 arXiv（编号 2404.16130），2025 年 2 月出了修订版。它要解决的病，论文摘要原话讲得很清楚：

> RAG fails on global questions directed at an entire text corpus, such as "What are the main themes in the dataset?", since this is inherently a query-focused summarization (QFS) task, rather than an explicit retrieval task.

翻译成人话：传统 RAG 是「把问题转成向量，取最相似的几段，拼给大模型生成」。对于「整个数据集的主要主题是什么」这种问题，没有任何一段文字能单独回答它，所以向量检索返回的一堆碎片，模型看了也归纳不出全局洞察。论文把这类需求称为 query-focused summarization（面向查询的摘要）或 global sensemaking（全局意义构建）。GraphRAG 的出发点就是补上这块短板。

这里有一个容易混的点先说清：GraphRAG 不是要取代向量 RAG，而是作为一层补充。局部事实查询（「某条款是什么」「某参数多少」）向量 RAG 又快又便宜，GraphRAG 没必要上；全局归纳查询才是它的主场。

## 二、核心方法：在索引阶段把重活干完

GraphRAG 的精髓，是「先用大模型把非结构化文本炼成一张带层级结构的知识图谱，提前把数据的语义结构总结好」，而不是等到用户提问才去拼。整个流程可以分成两阶段、四步。

先放一张链路图，方便对照后面每一步：

```text
源文档
  │
  ├─① 文本切分 → 每个文本单元
  │
  ├─② LLM 抽取：实体 + 关系 + 关键声明(claims)
  │        │
  │        ▼
  │   实体知识图谱（节点=实体，边=关系）
  │        │
  │        ▼
  ├─③ Leiden 社区检测：把紧密相连的实体聚成社区（分层）
  │        │
  │        ▼
  ├─④ 自下而上：为每个社区预生成 LLM 摘要（多层抽象）
  │
  ▼
查询阶段
  ├─ Global Search：每个社区摘要各自生成局部回答 → map-reduce 汇总
  ├─ Local Search：从问题点名的实体出发，沿图遍历邻居
  └─ 最终答案（带 community → entity → source 的可追溯链）
```

第一步，实体与关系抽取。对每个文本单元，用 LLM 抽出其中的实体（人、组织、地点、概念等）、实体之间的关系，以及关于实体的关键声明（claims）。这一步是成本的大头——每个文本单元通常需要多次 LLM 调用。

第二步，图谱构建与社区检测。把抽出的实体和关系汇聚成一张全局知识图谱，然后用 Leiden 算法做社区检测。社区就是图里联系紧密的实体子群，而且检测是分层的：小社区聚成大社区，形成一棵层级树。

第三步，社区摘要预生成。对每一层、每一个社区，提前用 LLM 生成一份摘要。这是 GraphRAG 最关键的设计——它在用户提问之前，就已经把「数据长什么样」总结好了。这也意味着 GraphRAG 能在没有任何查询的情况下，就报告出整个语料的宏观结构。

第四步，查询时组装。Global Search 面向宏观问题，用 map-reduce 方式让每个社区摘要各自生成局部回答，再汇总成最终答案；Local Search 面向具体实体的细节问题，从问题点名的实体出发沿图遍历邻居。论文里还有 DRIFT Search 等后续扩展，不在本文范围。

一句话概括差异：普通 RAG 是「问题 → 找相似片段 → 答」；GraphRAG 是「问题 → 沿预先构建的知识图谱和社区摘要 → 汇总答」。

## 三、效果到底好多少

论文在两个约百万 token 的数据集（播客转录、新闻文章）上做了评测，由第二个 LLM 当裁判，对比 GraphRAG 和朴素 RAG 的答案。结论很明确：

- 在答案的 comprehensiveness（全面性）上，GraphRAG 以 72% 到 79% 的胜率优于朴素 RAG；
- 在 diversity（多样性）上，以 62% 到 81% 的胜率优于朴素 RAG；
- 具体数值随数据集和图谱层级浮动；
- 朴素 RAG 在 directness（直接性，即答得最干脆）上反而更好——局部事实查询它本来就该赢。

注意一个诚实的边界：论文没有测量两种方法各自「幻觉率」谁高谁低。也就是说，GraphRAG 让答案更全更发散，但不等于更不容易编。这是评测里常被忽略的一句 caveat。

## 四、代价：一度是劝退级别的

GraphRAG 最被诟病的就是索引成本。论文和微软 README 都明确写了，索引 can be an expensive operation（可能是一项昂贵的操作），建议从小规模开始。公开复现中提到，在播客数据集上用 GPT-4 Turbo 完成索引大约花了 281 分钟。

成本高的根源在第一步：每个文本单元要做多次 LLM 调用抽实体和声明，因此索引成本是纯 embedding 方案的几十倍量级。如果语料频繁变动，每次重建图谱都要重付这笔钱，隐性成本更麻烦。

微软自己也在「自救」。2024 年 11 月推出的 LazyGraphRAG，把几乎所有 LLM 调用推迟到查询时才做——索引阶段不再预抽实体、不再预生成社区摘要，像向量 RAG 一样轻量建索引，等真正有查询来了再按需做图相关计算。官方给出的数字是：索引成本与向量 RAG 持平，仅为完整 GraphRAG 的约 0.1%，全局查询成本大幅降低，而答案质量与完整 GraphRAG 相当。这个「0.1%」本身就是一个强信号：完整 GraphRAG 那套全量预计算，对很多场景其实是过度设计。

## 五、它和传统向量 RAG 的本质区别

把关键维度摆在一张表里，避免被「知识图谱」四个字唬住：

| 维度 | 传统向量 RAG | GraphRAG（微软原版） |
| --- | --- | --- |
| 检索单元 | 文本块（chunk） | 实体 + 社区摘要 |
| 擅长的问题 | 局部事实查询 | 全局归纳 / 多跳 / 跨文档 |
| 索引阶段成本 | 低（只 embedding） | 高（每块多次 LLM 抽取） |
| 是否预生成摘要 | 否 | 是（分层社区摘要） |
| 全局 sensemaking | 弱 | 强（招牌能力） |
| 可追溯链 | 块 → 源 | community → entity → source |
| 适合语料规模 | 任意 | 稳定、较大（否则社区价值低） |

一句话：向量 RAG 是「相似片段拼接」，GraphRAG 是「先建全局语义结构再汇总」。两者不是替代关系，是互补的两层。

## 六、和你手里的轻量图谱差在哪

讲完论文，落到更实际的一件事：很多人听到「知识图谱 + RAG」就以为是一回事，其实图谱可以做得天差地别。以我自己在用的一个轻量知识库（CoreNote）为例，它的图谱和 GraphRAG 完全不是同一个重量级，这个对照最能说明选型逻辑。

根据 CoreNote 的官方说明，它的图谱是「基于文件结构、标题和关键词建立关系，并支持手动创建节点」。这意味着：

- 它不做实体抽取，不会让 LLM 去读每段文字、抽出「人、组织、概念」和它们之间的关系；
- 它没有 Leiden 社区检测，也不会预生成分层社区摘要；
- 因此它本质上不具备 GraphRAG 那种「跨文档全局归纳」的能力——你问「这批资料整体主题是什么」，它答不了，它擅长的是「沿文件结构/标题把相关资料聚到一起，再可溯源地回答局部问题」。

把两者的差异也摆成一张表：

| 维度 | GraphRAG（重图谱） | CoreNote 式轻量图谱 |
| --- | --- | --- |
| 图谱来源 | LLM 抽取实体 + 关系 | 文件结构 / 标题 / 关键词连边 |
| 实体抽取 | 是 | 否 |
| 社区聚类 + 分层摘要 | 是（Leiden，招牌） | 否 |
| 全局归纳问答 | 强 | 不支持 |
| 多跳推理 | Local / Global 多跳 | 弱 |
| 索引成本 | 高（每块多次 LLM） | 低 |
| 核心定位 | 全局 sensemaking 方法论 | 局部可溯源问答 + 资料组织 |

这个对照不是为了贬低轻量图谱，而是划清边界：GraphRAG 的全局归纳能力是真实且独特的，但代价高昂；轻量图谱用极低成本和可维护性，换掉了那块昂贵的全局能力，对绝大多数「找具体答案」的场景完全够用。两者根本不在一个层面竞争。

## 七、选型判断：三个问题决定你要不要上 GraphRAG

别被「知识图谱」这个词带着走。要不要上完整 GraphRAG，问自己三个问题：

第一，你的查询是全局型还是局部型？如果绝大多数是「找具体答案」（某条款、某参数、某事件细节），向量 RAG 或带轻量图谱的方案就够了，上完整 GraphRAG 是杀鸡用牛刀。如果你有大量「归纳整个语料」的需求（主题分析、趋势总结、跨文档宏观洞察），那 GraphRAG 的社区摘要 + Global Search 是目前最成体系的方法，别的方案替代不了。

第二，你的问题需要多跳推理吗？「A 公司的 CEO 曾在哪家公司任职，那家公司又被谁收购」——这种要沿实体关系走好几步的，是图结构的主场。如果大多是单跳（一段文本就能答），图带来的收益有限。

第三，预算和数据规模匹配吗？数据量大 + 预算有限，优先考虑 LazyGraphRAG 或轻量图谱方案，把 LLM 调用推迟到查询时或只用于召回增强；数据量适中 + 追求极致全局质量，完整 GraphRAG 值得投入；语料每天变、要求增量索引，原生 GraphRAG 不支持增量，频繁重建成本会失控。

一个经验下限：如果语料少于几百篇文档，Leiden 聚类产出的社区质量很低，标准向量 RAG 加个 reranking 往往更划算。GraphRAG 真正发挥价值，通常在百万 token 量级、且查询以归纳为主的稳定语料上。

## 八、小结

GraphRAG 是 2024 年 RAG 领域最重要的进展之一，它把「全局意义构建」这件事第一次做成了系统化的方法论。社区聚类 + 分层摘要 + Global Search 这套组合，精准命中了向量检索的天然盲区——全局归纳、多跳、跨文档综合。

但它不是万能药。完整形态代价高昂，微软自己都用 LazyGraphRAG 把索引成本砍到 0.1% 来「自救」，本身就说明全量预计算对很多场景是过度设计。更聪明的工程实践，往往是「理解图能带来什么，然后只为你真正需要的那部分能力付费」：要做重全局归纳的产品或研究，深入 GraphRAG；要做便宜好用的日常知识库，轻量图谱 + 可溯源问答就够。

技术选型的本质，从来不是选最强的，而是选最匹配的。

## 常见问题

问：GraphRAG 能直接替代向量 RAG 吗？
答：不能，它是互补层。局部事实查询向量 RAG 更快更便宜，GraphRAG 主攻全局归纳类问题。

问：GraphRAG 一定要用 GPT-4 吗？
答：不一定，任何兼容的 LLM 端点都可以，但抽取和摘要阶段都依赖 LLM 调用，成本主要来自这里。

问：小语料（几十篇文档）适合用 GraphRAG 吗？
答：通常不划算。社区检测在少量文档上产出低价值微社区，标准向量 RAG 加 reranking 更经济。

问：CoreNote 的图谱和 GraphRAG 是一回事吗？
答：不是。CoreNote 是文件结构/标题/关键词连边的轻量图谱，不做实体抽取和社区摘要，不支持全局归纳，成本和复杂度都低一个量级。

问：LazyGraphRAG 和完整 GraphRAG 怎么选？
答：要全局归纳且预算敏感，优先 LazyGraphRAG（索引成本约 0.1%）；要极致全局质量且数据稳定，完整版值得投入。

问：GraphRAG 会减少幻觉吗？
答：论文未测量幻觉率。它让答案更全面、更多样，但不等于更不容易编造，引用时仍需核对原文。

声明：本文是对 Microsoft Research 论文《From Local to Global: A Graph RAG Approach to Query-Focused Summarization》（arXiv:2404.16130，2024 年 4 月提交、2025 年 2 月修订）的技术解读，所有方法描述与评测数据均来自该论文及微软公开文档。涉及其他系统的对比，仅基于其官方公开说明，未核实的细节一律不写。

从 Local 到 Global：读懂微软 GraphRAG 论文，以及它和你手里的轻量图谱差在哪

声明：本文是对 Microsoft Research 论文《From Local to Global: A Graph RAG Approach to Query-Focused Summarization》（arXiv:2404.16130，2024 年 4 月提交、2025 年 2 月修订）的技术解读，所有方法描述与评测数据均来自该论文及微软公开文档。涉及其他系统的对比，仅基于其官方公开说明，

编程语言

GraphRAG通过构建实体知识图谱与分层社区摘要，解决传统RAG无法回答全局归纳类问题（如语料主题、跨文档趋势）的短板。相比向量检索的“找相似片段”，它以社区聚类+预生成摘要实现map-reduce式全局问答，全面性胜率最高达79%，但索引成本可达向量方案的数十倍。轻量图谱方案（如CoreNote）不做实体抽取与社区检测，适合局部可溯源问答；选型需权衡查询类型、多跳需求与预算。

知识图谱

代码解释

GraphRAG

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

GraphRAG通过构建实体知识图谱与分层社区摘要，解决传统RAG无法回答全局归纳类问题（如语料主题、跨文档趋势）的短板。相比向量检索的“找相似片段”，它以社区聚类+预生成摘要实现map-reduce式全局问答，全面性胜率最高达79%，但索引成本可达向量方案的数十倍。轻量图谱方案（如CoreNote）不做实体抽取与社区...

从 Local 到 Global：读懂微软 GraphRAG 论文，以及它和你手里的轻量图谱差在哪-腾讯云开发者社区-腾讯云

从 Local 到 Global：读懂微软 GraphRAG 论文，以及它和你手里的轻量图谱差在哪

从 Local 到 Global：读懂微软 GraphRAG 论文，以及它和你手里的轻量图谱差在哪

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐