GraphRAG 到底在干嘛？——微软这篇博客的深度拆解-编程实验室

原文：GraphRAG: Unlocking LLM discovery on narrative private data - Microsoft Research

微软 2024 年初发了一篇技术博客，核心就一句话：传统 RAG 在复杂数据面前不够用，GraphRAG 用知识图谱 + 图聚类补上了这块短板。

这不是学术论文，更像是一篇"技术安利文"，目标读者是技术决策者和工程师。下面我把它拆开来聊。

传统 RAG 到底差在哪？

GraphRAG 要解决的问题，得先从传统 RAG 的痛点说起。文章指出了两个传统 RAG 搞不定的场景：

串不起来的信息

想象你问 AI："Novorossiya 做了什么？"

传统 RAG 拿着"Novorossiya"这个词去做向量搜索，结果检索回来的 10 个文本片段里，没有一个直接提到这个名字——答案散落在不同的文档里，靠的是实体之间的间接关联才能拼出来。向量搜索只会找"长得像"的文本，这种需要"跳着找"的推理它做不了。

GraphRAG 就不一样了：它在知识图谱里找到 Novorossiya 这个节点，然后沿着关系边一路走下去——行动、目标、相关组织——最后把完整答案拼出来。

说白了，向量检索是"局部匹配"，而真实世界的知识经常是通过实体关系链间接连起来的。

回答不了"大问题"

再比如你问："这堆数据里排名前 5 的主题是什么？"

传统 RAG 傻眼了——"主题"这个词太泛了，向量搜索不知道该往哪个方向找，碰巧匹配到一些包含"主题"这个词的无关文本，答案自然跑偏。

这本质上是个粒度问题：向量 RAG 的检索单元是文本片段（chunk），但"整体主题"这种问题需要对整个数据集有宏观理解，任何单个 chunk 都撑不起这个回答。

GraphRAG 靠预先建好的社区聚类和社区摘要，直接从宏观结构里提取主题，轻松搞定。

GraphRAG 怎么干的？

整个流程分两个阶段：先离线建索引，再在线回答问题。

离线建索引：三步走

原始文档 │ ▼ ┌─────────────────────────────┐ │ Step 1: 实体和关系抽取 │ LLM 逐块处理文档，提取所有 │ (Entity & Relationship │ 实体（人、地、组织等）和 │ Extraction) │ 它们之间的关系 └─────────────────────────────┘ │ ▼ ┌─────────────────────────────┐ │ Step 2: 知识图谱构建 │ 将抽取的实体和关系组装成 │ (Knowledge Graph │ 一个完整的图结构 │ Construction) │ └─────────────────────────────┘ │ ▼ ┌─────────────────────────────┐ │ Step 3: 社区检测与摘要 │ 对图进行自底向上的层次聚类 │ (Community Detection │ （如 Leiden 算法），为每个 │ & Summarization) │ 社区生成 LLM 摘要报告 └─────────────────────────────┘

简单说就是：先让 LLM 把文档里的人、事、物和它们的关系都挖出来，拼成一张大图，然后对这张图做分群，给每个群写一份摘要。

在线回答：看问题类型选策略

问题类型	怎么找答案
具体问题（如"Novorossiya 做了什么"）	在图里定位实体 → 沿关系遍历 → 收集相关文本 → 生成回答
宏观问题（如"前 5 个主题"）	直接用社区摘要 → 逐层聚合 → 生成全局回答

几个值得深挖的技术点

为什么用 LLM 建图，而不是传统 NLP？

传统做法是用 NER（命名实体识别）+ 关系抽取模型，但这些模型有硬伤：得预先定义好实体类型和关系类型，换个领域就不灵了，隐含关系更是抓不住。

LLM 的优势很明显： -零样本就能干活，不用为每个领域单独训练 -能读懂言外之意，比如从"总检察长办公室报告了 Novorossiya 的创建"里抽出"政府关注"这层隐含关系 -不受 schema 限制，实体和关系类型让 LLM 自己发现

当然代价也很直接：LLM 调用贵，索引阶段要处理整个数据集，计算开销不小。

社区检测——GraphRAG 的杀手锏

很多方法都会用知识图谱来增强 RAG，但 GraphRAG 真正独特的地方在于社区检测：

用 Leiden 之类的算法把知识图谱切成多层次的社区（你可以理解为"话题群组"）
给每个社区预先生成一份 LLM 摘要报告
不同层次的社区对应不同的抽象级别，回答问题时按需选粒度

这就是它能回答"大问题"的秘密——不用临时遍历整张图，直接查预先写好的摘要就行。

生成社区报告时，LLM 拿到的输入是该社区内实体和关系的 CSV 表：Entities 表（实体 ID、名称、描述）、Relationships 表（源、目标、描述、combined_degree）、以及可选的 Claims 表。关系按combined_degree降序排列，优先塞最重要的，token 超了就截断。

溯源——每句话都能查到出处

GraphRAG 特别强调溯源能力，整条证据链是这样的：

用户查询 → GraphRAG 回答 + [数据：实体 (ID), 关系 (ID)] → 关系 ID 指向知识图谱中的具体边 → 边关联到原始源文档的具体片段

回答 → 图里的实体/关系 → 原始文档，一路可追溯。对企业级应用来说，这个能力非常关键——你能验证 AI 说的每一句话。

实验是怎么做的？

数据集

用的是 VIINA 数据集（新闻文章暴力事件信息），选得很讲究：

涉及多方冲突，信息碎片化，够复杂
包含俄乌双方新闻源，观点对立，有矛盾信息
2023 年 6 月的数据，确保不在 LLM 训练集里
数千篇文章，远超上下文窗口，不用 RAG 没法处理

评估结果

用了四个指标来打分：

指标	说的是啥	怎么评
全面性	答案完不完整	LLM 评分器成对比较
人类赋权	有没有给出处让你验证	LLM 评分器成对比较
多样性	有没有多角度回答	LLM 评分器成对比较
忠实度	有没有瞎编	SelfCheckGPT 绝对测量

结果挺有意思：GraphRAG 在前三项上大幅领先传统 RAG，但忠实度上两者差不多。也就是说，GraphRAG 的提升主要在"找得更全"，而不是"编得更少"。

别光看优点，局限也得知道

这毕竟是篇安利文，自然报喜不报忧。几个需要注意的坑：

索引成本高——每个文档块都要调 LLM 来抽实体和关系，大数据集可能要跑几小时甚至几天，用 GPT-4 级别的模型，API 费用相当可观。

增量更新是个难题——文章压根没提数据变了怎么办。实际上新增文档要重新抽取、合并，社区结构可能因此改变，得重新聚类、重新生成摘要，这在工程上还没有很好的解法。

抽取质量看 LLM 脸色——LLM 抽实体和关系不是百分百准的，可能漏掉隐含实体、搞错关系，不同模型的抽取质量差异也大，一致性难保证。

查询会慢一些——图遍历 + LLM 生成比简单的向量检索 + LLM 生成链路更长，延迟自然更高。

不是所有问题都需要它——文章自己也承认，简单的事实性查询（比如"什么是 Novorossiya"），传统 RAG 就够用了。GraphRAG 的优势集中在多跳推理和全局总结这两个场景。

打个比方帮你建立直觉

假设你是公司新人，想了解"最近三个月最重要的项目进展"。

传统 RAG 就像翻文件柜：你走到档案室，用"项目进展"当关键词去翻。找到几十份文件，散落在不同抽屉里——会议纪要、邮件、报告都有。你得自己把碎片拼起来。

GraphRAG 就像问一个什么都知道的老同事：他不仅读过所有文件，还记得"张三的 A 项目和李四的 B 项目其实有关联"，知道"上个月的预算调整影响了三个部门"。他能直接给你一个有条理的完整回答。

传统 RAG	GraphRAG
工作方式	搜关键词，找相关段落	先建关系网，再沿着关系回答
擅长的问题	"X 是什么？""X 怎么做？"	"X 和 Y 有什么关系？""整体情况是什么？"
类比	图书馆管理员帮你找书	侦探帮你把线索串成完整故事
短板	碎片化，缺全局视角	建关系网需要时间和算力