今天来研读微软团队的研究 《From Local to Global: A GraphRAG Approach to Query-Focused Summarization》
GraphRAG 的开源实现：点这里
有关 LLM-as-a-judge 的提出，参见研究：《Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena》
1. 为什么要引入 GraphRAG ？ 传统 RAG 有什么不足？
对于一些能精准落于知识库中的一个小规模子集的查询（比如对于一些关于文本细节的查询，而和这些文本细节有关的支撑信息恰好能在一块文本记录中完全查询到），传统的基于向量的 RAG 范式（vector RAG）能有很良好的表现。但是 vector RAG 无法解决那些需要对整个知识库做出宏观理解和判断的问询，比如 “在过去十年中，跨学科研究对科学发现产生影响的关键趋势有哪些？”
基于此，作者提出了 GraphRAG ，旨在解决这种在大规模文本语料上做全局理解的任务。具体而言，分为以下四个步骤：
GraphRAG 首先用一个 LLM 构造知识图谱，该知识图谱的节点指代了语料中关键的实体，边指代了这些实体之间的关系。
将这个知识图谱划分为一个具备层级结构的社群网络。关系紧密的实体会被聚在一个小社群里，而多个小社群又会组合成更大的上级社群。
用 LLM 对每个社群 “从底往上” 的生成摘要。从最底层（最具体、最小的社群）开始生成摘要，并通过递归地整合低层级摘要以生成高层级（更宏观）的社群摘要。这些不同层级的社群摘要，共同构成了对整个数据集的全局性描述与洞察。
当用户提出一个问询时，GraphRAG 采用 Map-Reduce 架构来处理。在 Map 阶段，每一个社群摘要都会独立地、并行地针对用户的提问生成一个局部答案 。在 Reduce 阶段，系统将这些局部答案收集起来，并组合生成一个全局最终答案。
那么如何评估这个系统的能力呢？由于全局性问题通常没有标准答案，其回答水平的高低难以用传统的准确率等指标来衡量，因此作者提出了一种基于 LLM-as-a-judge 技巧的评估方式。这个过程分为三步：
使用第一个 LLM，根据特定语料库的实际应用场景，生成一组多样化的、宏观的“全局性问题”。
让两个不同的 RAG 系统（比如 GraphRAG 和 传统 vector RAG）分别回答这些问题。
使用第二个 LLM 扮演裁判，根据预先设定好的标准（具体标准后续会介绍）对两个 RAG 系统的回答进行评判和打分。
作者在两个具有代表性的真实世界文本数据集上进行了对比测试，并用 GPT-4 作为 LLM ，发现 GraphRAG 的表现显著优于传统的 vector RAG 。
2. GraphRAG 的原理是什么？
2.1 GraphRAG 工作流
2.1.1 源文档 -> 文本块
将语料集中的文档切分成文本块。块大小的设计会对系统的能力产生影响。如果块大小较大，则后续 LLM 调用次数减少（从而减少成本），但是会使得块中较早出现的信息的召回率下降。
2.1.2 文本块 -> 实体 & 关系
在这一步中，采用 LLM 从每一个文本块中提取出重要的实体以及实体之间的关系。此外，LLM 会对每一个实体与关系生成简短的描述信息。为了增强 LLM 的提取效果，可以在提示词中选取与语料集领域有关的合适示例做 few-shot prompting 。
此外，LLM 还能对实体提取出断言（Claims），断言指的是关于实体的重要事实性陈述。它通常包含时间、事件、以及与其他实体的互动。与实体的描述信息不同的是，断言的作用是对一些复杂的、动态的事实做补充描述。例如，“Quantum Systems 于 2016 年收购了 NeoChip，并一直持有其所有权，直到 NeoChip 上市。” 这一事实陈述较为复杂，难以用简短的实体描述信息表示，作为断言单独存在较为合适。
我的理解：“描述”是静态的语义属性归纳（如：A 是某公司的 CEO），而“断言”是带有时空属性的事件元组（如：A 于 2016 年发起收购并在 2021 年卸任）。在构建知识图谱时，断言实际上充当了“动态时间边”的角色。
2.1.3 实体 & 关系 -> 知识图谱
由于同一个元素（实体/关系/断言）可能在多篇文档中都有出现，因此在第 2 步中可能被重复提取，形成大量的实例（Instances）。在形成知识图谱时，需要对同一元素的不同实例做聚合：
对于同一实体的不同实例：将描述信息聚合起来做一个合并摘要（这样可以让最终节点保留对实体的完整综合性描述）。
对于同一关系的不同实例：将相同关系合并成一条边。注意，重复出现的次数转化为这条边的权重，权重越高，说明这一关系在语料库中越重要。
对于同一断言的不同实例：采用与实体/关系类似的合并与去重机制。
这里作者提出了一个问题：如何判断“同一实体的不同实例”？（例如，如何知道 "Apple"、"Apple Inc." 和 "苹果公司" 指的是同一个东西？）
作者这里采用的是精确字符串匹配，这个方式比较粗糙，不过很容易就能改造成一些柔性方案（比如引入向量相似度或 Levenshtein 距离）。但作者发现，其实 GraphRAG 对这些没有对齐的重复实体有很强的韧性，在后续的步骤中会自然而然地将它们聚合到一个社群中作社群摘要。
2.1.4 知识图谱 -> 图谱社区
通过第 3 步，我们现在得到了一个知识图谱，它可以看作原始语料库的一个索引。我们可以采用许多社群检测算法来将图谱划分为一个个社群。每一个社群之中都是强相关的节点。在本文中，作者层次化地采用了 Leiden 社群检测算法：
输入原始知识图谱，Leiden 算法根据节点之间连接的紧密程度，切分成几个大社群。
对每一个大社群内部，再次运行 Leiden 算法，将其切分成更小的社群。不断递归向下。
直到遇到最底层的、无法再被划分的叶子社群为止。
每一层的社群划分都应当是相互独立，完全穷尽的，即图谱中的每一个节点只会属于该层级中的某一个社群（不发生重复），且必须属于某一个社群（不发生遗漏）。这为后面的步骤中采用分治的策略来实现全局摘要提供了基础。
2.1.5 图谱社区 -> 社区摘要
GraphRAG 采用一种 “从底往上” 的方式来生成各层级的社群摘要。
对于叶子社群：
在最底层的叶子社群中，由于面对的是原始的图谱信息，可能会内容过多，因此会对边（edge）采用优先级排序，将优先级最高的信息送入 LLM 提取摘要。这里的优先级是用 “整体显著性” 来衡量的。一条边的整体显著性等于源节点和目标节点的度数之和。
将一个社群中的边按照整体显著性的大小做降序排列。每次挑出整体显著性最高的边，将它的 [源节点描述] + [目标节点描述] + [边自身的描述] + [相关 Claims] 打包，并送入 LLM 。
直到输入 Token 数达到设定上限为止。
对于更高层级的社群：
如果把该高层社群下的所有原始元素描述都能塞进 LLM 的上下文窗口而不超过 Token 数的设定上限，那么就参照叶子层的方式生成社群摘要。
如果超出了上限（无法完全装下），算法会将所有子社群按照原始元素 Token 数进行降序排列，并迭代地把最 “臃肿” 的子社群里面的 “原始元素描述（长文本）” 替换为该子社群预先生成好的 “社群摘要（短文本）” 。
直到它们能完全放入上下文窗口为止。
2.1.6 社区摘要 -> 社区答案 -> 全局答案
对于一个给定层级的社群，核心流程如下：
准备社群摘要。系统首先把选定层级的所有社群摘要随机打乱，然后切分成固定 Token 大小的文本块（文本块大小是预先设定好的）。随机打乱能让相关信息均匀分布，提高整体检索的鲁棒性。
Map 阶段。系统并发地把这些打乱的分块送入 LLM。每个线程的 LLM 独立阅读自己分到的那部分摘要文本块，针对用户的提问生成一个中间局部答案。注意，这里要求 LLM 在生成局部答案的同时，顺便给自己这个答案对于回答目标问题的有用程度打一个 0-100 的分数。如果 LLM 觉得自己负责的这部分摘要文本块跟用户的提问风马牛不相及，它就会打 0 分。被打了 0 分的答案会被系统过滤掉。
Reduce 阶段。系统将所有通过过滤的局部答案按照评分从高到低进行降序排列，并迭代地将答案送入 LLM ，直到达到 Token 设定上限。LLM 就用这些与用户提问最相关的局部答案，生成一个最终的全局答案，并返回给用户。
这里有一个需要注意的问题：到底采用哪一个层级的社群最为合适？采用不同层级的社群来回答用户的问题，会产生怎样不同的效果以及工程开销？这将在下一大节探讨。
2.2 全局性问题的生成
前文提到，作者采用 “LLM-as-a-judge” 技巧来评估 GraphRAG 系统回答全局性问题的能力。下面描述了 “出题” 阶段的算法流程。
具体而言，这一算法分为三个步骤：
基于语料生成潜在用户画像。将语料库的高层级全局描述及其建设目的（而非全文）输入给 LLM ，让 LLM 思考 “哪些人会是这个知识库的潜在用户？” 并生成 K 个潜在用户画像。
基于画像衍生业务任务。针对上一步生成的每一个虚构用户，LLM 需要进一步推演：“这个人在他的日常工作中，会带着什么具体的业务任务来查阅这个知识库？”并给出 N 个相关任务。
基于“画像 + 任务”最终提炼全局问题。LLM 对每一个给定的（用户，任务）对，生成 M 个高层级全局问题。这些问题需要系统理解整个语料库才能正确回答。
算法结束时，我们对整个数据集得到了 K * N * M 个文本问题。
上述这一套出题算法有以下几个优势：
出题 LLM 自始至终只阅读了语料库的高层级全局描述及其建设目的，因而生成的问题必然是高层次全局性的，这迫使 RAG 系统回答问题时必须系统理解整个语料库。
算法采用了 语料描述 -> 用户画像 -> 业务任务 -> 最终问题 的链式路径，这实际上是通过结构化拓扑的方式，拉宽了大模型出题的“想象力边界”，确保了最终生成的问题集在应用场景上具有更高的多样性和全面性。
下面可以看一些示例：
2.3 评估全局感知能力的准则
作者采用 LLM 来评估系统对 “高层次全局性问题” 的 “全局感知能力” 表现。评估准则可以概括为以下三条：
全面性（Comprehensiveness）：回答覆盖了问题的多少细节与方面？
多样性（Diversity）：回答在提供不同视角和见解时有多丰富和多变？
赋能度（Empowerment）：回答在多大程度上帮助读者理解主题，并使其能够做出明智的判断？
此外，作者注意到，如果系统生成一篇非常冗长的报告，上述三个指标依然能得到很好的成绩，但这并不是我们想要得到的。因此，作者引入了一个 “对抗指标” ：直接性（Directness）
直接性（Directness）：回答有多具体、多清晰地直接针对了问题？
作者指出，他们并没有预期过任何方法能在上述四个指标上同时取得超高分。因为 Directness 这一指标本身就是用作 “锚点” 的，用于验证另外三个指标的得分提升是健康、合理的，与全面性、多样性这两个指标存在一定的对抗。
在具体执行评估时，作者采用了 “打擂台” 的方式。具体要点如下：
给裁判 LLM 喂入 [问题] + [系统 A 的回答] + [系统 B 的回答]，并指定某一个评价标准（比如多样性）。
裁判 LLM 必须做出明确选择：判 A 胜、判 B 胜、或者打平手。
针对同一个问题和同一对回答，由于大模型的生成具有随机性，作者跑了多次重复实验并取平均胜率。
3. 实验及结果
3.1 实验 1
3.1.1 数据集的选取
作者选取了两个百万 token 量级的语料集：
播客逐字稿数据集。这个数据集来自微软 CTO Kevin Scott 主持的科技与科学访谈播客《Behind the Tech》的公开逐字稿。它被切分为 1,669 个 文本块，每个文本块包含 600 个 Token，块与块之间有 100 个 Token 的重叠，总体量约为 100 万 Token。播客文本带有极强的口语化、长对话、多话题交织的特点。这种文本对于传统的 vector RAG 极不友好，因为上下文缺乏严密的逻辑段落结构，非常考验 RAG 系统从散乱对话中“拼凑全局主题”的能力。
新闻文章数据集。这个数据集涵盖 2013 年 9 月至 2023 年 12 月长达十年的新闻跨度数据集，包含娱乐、商业、体育、科技、健康和科学等多个领域的报道。它被切分为 3,197 个 文本块，同样是 600 Token 块大小 + 100 Token 重叠，总体量约为 170 万 Token。新闻数据集的特点是实体密集、跨越十年时间线、涉及领域极广。同一个公司或人物可能会在数百篇不同时间、不同领域的新闻里出现。这非常考验 RAG 系统对海量复杂“实体-关系”图谱的构建与跨时间线的归纳提炼能力。
3.1.2 实验对比条件
为了评估 GraphRAG 的效果，作者设计了 6 种实验组别，将不同层级的 GraphRAG（C0-C3）与传统方法（直接文本 Map-Reduce 以及经典的向量 RAG）放在同等 Context Window 下进行严格的“控制变量”对比。具体而言：
C0（Root-level，根层级/最高层）： 使用数量最少的顶层社群摘要。视野极高、极宏观，但牺牲了底层细节。
C1（High-level，高层级）： 使用 C0 的子社群摘要（若无子社群则沿用 C0）。
C2（Intermediate-level，中间层级）： 使用 C1 的子社群摘要，代表中等粒度的语义抽象（若无子社群则沿用 C1）。
C3（Low-level，低层级/叶子层）： 使用最底层的社群摘要，数量最多、细节最丰富，但视野相对局部（若无子社群则沿用 C2）。
TS（Text Summarization）：不建图、不运行莱顿算法，直接把原始文本切片随机打乱、分块，然后跑与 GraphRAG 相同的 Map-Reduce 汇总流程。
SS（Semantic Search，即传统 Vector RAG）：经典的向量检索增强生成。根据 Query 的 Embedding 向量在数据库中检索相关度最高的原始文本块（Chunks），按照相似度从高到低塞满上下文窗口，最后由 LLM 一次性生成回答。
上述实验保证无关变量的一致性，具体而言：
Context Window 预算一致： 所有 6 种条件给 LLM 留出的上下文 Token 上限是完全一样的。作者生成社群摘要、社群答案以及最后的全局答案时，上下文窗口都被统一限制在 8,000 Tokens。
回答 Prompt 保持一致： 使用相同的提示词模板进行答案生成（仅对引用来源的格式做微调）。
针对 100 万 Token 的播客数据集，作者在一台配置相对普通的虚拟机上（16GB 内存，Intel Xeon Platinum 8171M CPU @ 2.60GHz），使用 OpenAI 官方的 gpt-4-turbo API 节点（2M TPM, 10k RPM），耗时 281 分钟（约 4.7 小时）构建了完整的图谱索引。由此可见，GraphRAG 在预处理阶段的主要时间开销是在网络 RTT 延迟以及 API 速率限制上，对于本地硬件算力的要求并不是很高。
此外，在实际工业落地时，作者没有手写 Leiden 社群检测算法，而是使用了 graspologic 库。这也为我们自己在工程开发时提供了一个很好的选择。
3.1.3 实验结果展示
实验 1 中的两个数据集中，播客数据集共提取出 8,564 个节点，20,691 条边；新闻数据集共提取出 15,754 个节点，19,520 条边。
下表展示了在回答全局问题时，不同方法（C0–C3 vs. TS）在 Map 阶段需要读取的文本总量：
上面的数据展示出了，尽管 GraphRAG 在图谱索引建立、社区摘要生成等预处理阶段耗费了不短的时间和较多的 Token 数，但是真正到在线查询阶段，它通过 C0/C1 等高层摘要，能大幅节省 Token 开销，在长期的使用过程中能够迅速偿还预处理阶段的一次性开销。
下图展示出了在两个实验数据集上，6 种不同实验组别 “打擂台” 的结果矩阵：
上面的数据展示出了几个关键信息：
GraphRAG 对 Vector RAG 在全面性和多样性上取得了显著优势，但是在 vector RAG 在直接性上略胜一筹。
GraphRAG 与 Vector RAG 和 TS 方法在赋能度上互有胜负。作者通过分析 LLM 裁判的推理逻辑发现，裁判认为能否提供具体的例子、直接引用和原告出处，是帮助用户做出明智判断的关键。而由于 GraphRAG 在社群摘要阶段对文本进行了层层抽象，导致部分原句引用和例证被平滑掉了。作者指出，未来可以通过微调实体提取 Prompt 等方式补齐 GraphRAG 的这一短板。
用社群摘要对比 TS 方法（直接对原始文本做 Map-Reduce），可以发现社群摘要在全面性和多样性上展现出了小幅但非常稳定的提升。
C0 方法具备很强的可扩展性。尽管 C0 的表现相比 C1-C3 有微小的下降，但它依然保持了对 Vector RAG 的大幅度优势（全面性胜率 72%，多样性胜率 62%）。而它付出的在线 Token 成本却只有 TS 的不到 3%。
3.2 实验 2
3.2.1 实验方案
实验 1 中利用 LLM-as-a-judge 技巧来评估系统给出的答案的 “全面性” 和 “多样性” 。但是，LLM 会不会本身就存在偏见，引入某种系统偏差呢？因此，作者在在实验 2 中引入了一套基于 “事实断言”（Claim-based）的客观量化指标。具体而言：
定义事实断言（Factual Claim）：一个明确呈现某种可验证事实的陈述。例如，句子 “加州和纽约实施了可再生能源激励措施” 被拆解为两个事实断言：“加州实施了可再生能源激励措施” 以及 “纽约实施了可再生能源激励措施” 。
提取事实断言：利用一个基于 LLM 的工具 Claimify 。Claimify 可以在系统给出的回答中识别出包含事实断言的句子，再将其原子化拆解为一个个简单、独立的单体 Claim。作者应用 Claimify 到实验 1 中各个组别条件下生成的所有回答，去除重复项后，共提取出 47,075 个独立 Claim，平均每个回答包含约 31 个 Claim。
在实验 2 的这一套方法下，重新定义全面性和多样性：
注意，在计算“多样性（聚类数量）”时，作者采用了一套标准的 NLP 文本距离聚类方案：
聚类算法： 使用 Scikit-learn 的凝聚层次聚类（Agglomerative Clustering）。
合并策略： 采用 全链接（Complete Linkage），即只有当两个簇中最远点之间的距离小于等于设定阈值时才合并。
距离度量（Distance Metric）： 使用 1 - ROUGE-L 。ROUGE-L 衡量文本的重合度，距离越近代表表达的意思越贴近。
消除阈值干扰： 考虑到距离阈值的大小直接决定了聚类簇的数量，作者测试并汇报了一整条阈值区间下的结果。
Complete Linkage 要求簇内最远两点距离必须小于阈值才进行合并，这意味着它对“不相似度”的要求极其苛刻，倾向于生成结构更紧凑、语义界限更分明的簇。这也解释了为什么在衡量多样性时，用这种聚类算法计算出的簇数量会具有很高的数据说服力。
3.2.2 实验结果展示
下表展示了用 “事实断言” 方法衡量的 “全面性” 数据对比：
可以发现，全局方法（C0–C3 & TS）在事实密度（衡量全面性）上显著超过 Vector RAG（SS）。这也验证了实验 1 的结论。
下表展示了用 “事实断言” 方法衡量的 “多样性” 数据对比：
可以发现以下几点：
在播客数据集上，所有全局搜索条件（C0–C3、TS）在所有的距离阈值（Distance Thresholds）下，其聚类簇数量都显著高于向量 RAG（SS）（p < .05）。
在新闻数据集上，只有最高层的社群摘要（C0）在所有距离阈值下都显著超越了 SS（p < .05）。虽然 C1–C3 的平均聚类簇数量依然高于 SS，但这种统计显著性只出现在部分距离阈值下。虽然实验 2 没有像实验 1 一样全部达成全线显著的结果，但是全局方法与 SS 之间的多样性均值差距趋势方向是完全一致的（即新闻数据集上的差距总体小于播客数据集）。
在全面性和多样性这两个客观指标上（无论是在播客还是新闻数据集），GraphRAG 的各个变体（C0–C3）之间，以及 GraphRAG 与纯文本 Map-Reduce（TS）之间，均未观察到统计学上的显著差异。
最后，作者对实验 1 的 LLM 裁判和实验 2 的 Claim 统计做了对齐度校验。结果发现，在LLM 裁判给出了明确胜负（非平局）的样本上，LLM 裁判判出的胜者与 Claim 客观指标算出的胜者呈现出了高度的吻合，其中：
全面性对齐度： 在 78% 的对比中，LLM 裁判选择的胜者与 Claim 事实点数量更多的条件完全一致。
多样性对齐度： 在 69%–70% 的对比中（跨所有距离阈值），LLM 裁判选择的胜者与聚类簇数量更多的条件完全一致。
（这里聚焦于非平局样本，是因为 Claim 计数方式下很难出现 “平局” 。作者发现，如果选择一个阈值来定义平局，结果会对阈值的选择非常敏感。因此在 LLM 明确给出胜负的样本上来做对齐度校验）
4. 未来演进方向
不同领域与业务场景的泛化能力验证。扩展验证这套架构在医学、法律、金融、工程等其他领域，以及不同数据规模和业务场景下的泛化能力。
幻觉率的评估方式。可以引入像 SelfCheckGPT 这样的机制来量化对比 GraphRAG 与 Vector RAG 在“幻觉/编造率”上的差异。
结合 Embedding 的“局部-全局”混合 RAG（Hybrid RAG Schemes）。例如，将用户 Query 与图谱中的节点、边描述以及 Claims 进行向量嵌入匹配，定位到具体的实体聚类后，即时生成特定社群报告，再跑 Map-Reduce 汇总。
向上卷起（Roll-Up）与向下钻取（Drill-Down）的交互式方式探索：
向上卷起： 从局部细节出发，沿着社群树向上递归，将低层级的发现逐步汇总为高层级的宏观结论。
向下钻取： 用户先看高层级的宏观摘要（C0），当对某个特定方向感兴趣时，顺着摘要里的线索，像点击文件夹一样逐层下钻到低层社群（C0 -> C1 -> C2 -> ... -> 叶子层），甚至直接定位到原始文本 Chunk 。
5. 总结
在本文的研究中，作者提出了 GraphRAG，这是一种结合了知识图谱生成与面向查询的摘要的 RAG 方法，旨在支持人类对整个文本语料库的全局意义构建。
初始评估表明，相比于传统的向量 RAG 基线，GraphRAG 在回答的全面性和多样性上均有显著提升；同时，与另一种不依赖图结构、直接对源文本进行 Map-Reduce 摘要的全局方法（TS）相比，GraphRAG 也展现出了更优越的对比表现。
对于需要在同一个数据集上进行多次全局查询的场景，基于实体的图索引中的根层级（Root-level）社群摘要（C0）提供了一种数据索引方式：它不仅显著优于向量 RAG，而且能以极低的 Token 成本，达到与其他全局方法相当的竞争性表现。