Microsoft GraphRAG：社区报告与全局问答
Microsoft GraphRAG 是微软提出的图增强 RAG 方法及其开源实现。原始研究主要解决跨文档的全局归纳问题：建库时从文本抽取实体关系图，按图连接划分社区，为每个社区生成报告；查询时让多批报告分别回应问题，再汇总成回答。这条基于社区报告的查询流程称为 Global Search，也是本篇的重点。
例如，“这一季度的项目资料里，主要风险有哪些？”没有指定某个项目，相似度最高的几个片段未必覆盖整个资料库。GraphRAG 在建库时就整理各社区涉及的对象、关系和事件，提问后再从这些报告中提取相关观点。它将部分归纳工作提前完成，使查询能在有限上下文中使用更广范围的资料。
同一套索引还支持围绕具体对象查询的 Local Search，以及结合社区信息与多轮局部查询的 DRIFT Search。通用的实体关系建模见知识图谱 RAG。
从实体关系到社区报告
看下面几条项目记录：
| TextUnit | 原文记录 |
|---|---|
T1 | 海岬项目由顾遥负责，依赖映川供应商交付控制板。 |
T2 | 映川的控制板延迟两周，导致海岬项目的联调顺延。 |
T3 | 青禾项目也采购映川控制板，已启动备选供应商评审。 |
T4 | 云帆项目因测试环境不足，压缩了回归测试范围。 |
索引先把文档切成 TextUnit，抽取实体和关系，合并相同对象的描述。例如前三段可以形成：
(海岬项目, 负责人, 顾遥) <- T1
(海岬项目, 依赖交付, 映川) <- T1
(映川, 交付延期影响联调, 海岬项目) <- T2
(青禾项目, 采购自, 映川) <- T3索引保存实体、关系及它们的文本描述，并记录来源 TextUnit。上面的三元组展示了对象之间的连接；关系描述还会保留“延迟两周”这类无法仅用边类型表达的内容。
随后，层次化 Leiden 算法依据图连接划分社区。社区是内部连接相对密集的一组节点，层次化划分则会把较大的社区继续分成较小的社区。共享供应商、人员或项目的记录由此有机会进入同一组，即使用词不同，也能通过共同实体联系起来。
例如，海岬、青禾及映川相关节点可能被划入同一社区，云帆和测试环境相关节点可能属于另一社区。具体分组取决于整张图的连接及算法配置。算法输出的是节点集合，社区的业务主题由后续报告概括。
LLM 再为各社区生成 Community Report，读取社区内实体和关系的描述，整理主题摘要与具体发现。较高层报告还可以利用下级社区报告组织更大范围的信息。这些报告在用户提问前就已生成，之后可用于回答多个问题。
映川相关社区的报告可以概括：“两个项目关联映川控制板，海岬已有延期记录，青禾正在评审备选方案。”报告压缩了三段记录，又保留了两个项目所处状态的区别。若写成“两个项目都已延期”，后续查询即使正确选中了这份报告，也会使用错误前提。
社区报告是派生摘要，可以压缩原文，也可能丢失例外。它需要保留到实体、关系和 TextUnit 的追溯信息。
Global Search：让社区报告分别回应问题
对于“这些项目的风险主要集中在哪里”，Global Search 从选定层级的社区报告出发。报告数量可能超过一次调用的上下文容量，所以查询分成 map 和 reduce 两步：
- 将报告分成多个批次，每批与同一个用户问题一起交给模型。每次 map 提取本批报告中与问题相关的观点，并给出重要性评分。
- 汇集各批观点，按评分筛选并控制总长度，再由 reduce 调用合并重复内容、归纳主题，生成最终回答。
社区报告 A、B ── map（用户问题）── 供应商交付依赖及相关项目
社区报告 C、D ── map（用户问题）── 测试资源不足及影响
↓
筛选并汇集相关观点
↓
reduce → 全局回答在这个例子里，一批报告提供“供应商交付依赖”，另一批提供“测试资源不足”。最终回答可以说明两类风险，并区分“已发生的延期”和“为防范风险开展的评审”。
Global 的生成依据主要是社区报告，并不要求每次都重新检索原始 TextUnit。回答引用的报告仍应能追溯到实体、关系及其来源；需要核实“延迟两周”等具体细节时，可以沿来源映射回读 T2。
Global 的覆盖面取决于参与查询的报告及其内容。更细粒度的社区通常意味着更多报告和调用；更粗的报告更省上下文，却可能压掉少见事件。重要性评分也是模型生成的排序信号，不能解释为事实正确率。
这种方法适合主题归纳。若问题变成“共有多少项目延期”，应回到项目清单和结构化统计。报告中的概括或提及次数不能替代精确计数，同一项目可能出现在多份报告中。
Local Search：围绕一个对象查细节
用户问“海岬项目为什么推迟联调，谁负责跟进？”时，用全部社区报告进行归纳范围过大。Local Search 先用问题匹配实体描述，找到海岬项目等入口，再收集关联关系、邻近实体、社区报告和原始 TextUnit。候选经过排序、过滤和上下文预算限制后交给模型。
这里 T2 支持“控制板延期导致联调顺延”，T1 支持“顾遥是项目负责人”。若要确定谁具体负责催交，还需采购分工记录。Local 的上下文可以同时包含实体关系、摘要和原文，因此既能利用图连接，也能读取段落中的细节。
可选的 claim 抽取还会生成 Covariate 数据，供查询使用。它是独立的索引能力，生成社区报告并不要求先启用 claim 抽取。
DRIFT Search：先找方向，再追问细节
“供应依赖影响了哪些项目，还应核查什么？”兼有宽范围探索与具体追问。DRIFT 先比较问题与相关社区报告，生成初始回答和后续问题；再通过 Local Search 回答这些问题，按中间结果继续展开，形成问题与答案的层次结构。
例如初始报告提示映川关联海岬和青禾，后续查询便可分别追问：“海岬延期的直接记录是什么？”“青禾评审是否已确定替代供应商？”第二个问题若只有 T3，答案只能是已启动评审，不能把备选方案写成已经落地。
DRIFT 因此增加了多轮检索与生成。限制追问分支、深度和总预算，才能避免沿着宽泛主题持续扩张。它与 Global 的区别在于用社区信息引导局部探索，而非对一批报告做一次整体归纳。
三种查询方式的选择
| 问题 | 优先考虑 | 主要代价 |
|---|---|---|
| 某个项目发生了什么 | Local | 实体定位和局部上下文组织 |
| 全部资料的主要主题 | Global | 多批报告的 map-reduce |
| 宽问题需要逐项核实 | DRIFT | 社区起点与多轮局部搜索 |
Global 读取报告并归纳，Local 从实体进入相关上下文，DRIFT 用社区信息引出局部追问。资料库建立同一套图索引后，可以按问题选择入口，无需让所有请求都执行全局汇总。
与同样使用层次摘要的 RAPTOR 相比，Microsoft GraphRAG 的分组依据不同。RAPTOR 按文本表示聚类并递归摘要；Microsoft GraphRAG 先抽取实体关系，再根据图连接组织社区。后者可以连接用词不同却涉及同一供应商的记录，也更依赖实体抽取和合并质量：同名供应商被错误合并，就可能生成并不存在的共同风险主题。
社区报告带来的成本
共同的前置成本是抽取、合并、社区发现和报告生成。新增关系还可能改变社区划分，使原来的报告需要更新。不能因为索引完成过一次，就长期复用不再对应当前数据的摘要。
删除或收紧某份资料的权限时，也要处理它对实体描述和报告的贡献。移除原始 TextUnit 后，旧报告仍可能泄露其内容。包含不同权限来源的报告不能直接向所有能看到社区名称的人开放，应按可见来源生成对应视图或隔离索引。
全局问题较少、资料变化又很频繁时，持续维护社区报告的成本可能较高。以单条事实查询为主的资料库，通常应先做好文本检索；需要反复归纳跨文档主题时，预先生成的社区报告才更有用。
原始资料
- From Local to Global: A Graph RAG Approach to Query-Focused Summarization：原始论文及全局归纳任务。
- 官方索引数据流：TextUnit、实体关系、Leiden 社区和社区报告。
- 官方查询文档：Local、Global 和 DRIFT 的具体查询过程。DRIFT 按官方查询文档介绍，不归入原始论文已经提出的能力。