Microsoft GraphRAG 原理与选型：什么时候值得用知识图谱？

文档核验日期：2026 年 10 月 26 日。核验依据包括 Microsoft GraphRAG 文档、项目仓库，以及 Neo4j 和 LlamaIndex 文档。下文的比较基于这些文档描述的机制，不是性能测试。产品反馈场景均为说明性示例。

Microsoft GraphRAG 是什么？

Microsoft GraphRAG 会在用户提问之前，先为文档集构建一份概览。它用大语言模型（LLM）从文档中提取实体和关系，把相互连接的实体划分为社区，再为各个社区生成摘要。查询引擎随后便可利用这些结构回答问题。Microsoft 官方概览介绍了这一方法及其主要检索模式。

实体是数据中有名称的对象，比如客户、产品、人物或项目。关系则把实体连起来：客户使用某个产品，项目依赖某项服务。实体与关系共同组成知识图谱。社区是一组相互连接的实体，其摘要概括了文档集中这一部分的情况。

可以把文档集想象成一座园区。向量搜索找到的是内容与问题相似的房间；图谱关系把房间连接起来；社区摘要则像从高处连廊俯瞰园区。如果问题是整个园区里正在发生什么，只挑几个相似的房间查看，就可能漏掉整片楼群。

这也解释了一种常见失误：检索增强生成应用会先把检索到的证据交给模型，再让模型作答。它能准确找到导出政策，却无法深入回答“这些访谈中，客户普遍遇到了哪些困扰？”后一个问题需要覆盖整个文档集，而原文中可能根本没有哪一段直接给出了答案。

“Graph RAG”也泛指一类利用图谱进行检索的系统。本文聚焦 Microsoft 的实现。其他框架中基于图谱的应用，并不一定会构建 Microsoft 式的社区报告，也不一定采用它的全局搜索方法。

GraphRAG 原理：索引阶段做了什么？

关键变化发生在索引阶段：GraphRAG 根据原始数据生成一批描述性内容，供后续查询反复使用。Microsoft 的标准索引方法用 LLM 完成提取和摘要生成，再通过图聚类形成社区结构。

实际流程中，各环节有明确的依赖关系：

1. 把文档拆成文本单元。 每个单元都是一块源文本。保留它与原文档的关联，就能追溯提取结果来自哪里。
2. 提取实体和关系。 LLM 阅读每个文本单元，描述其中的实体及其联系。
3. 整合图谱。 对匹配到的实体和关系，其描述会被合并并汇总。文档规定的合并规则使用实体名称与类型，以及关系的起点和终点。
4. 发现社区。 图聚类算法 Hierarchical Leiden 按不同粒度，将相互连接的实体划分成组。
5. 生成社区报告和向量嵌入。 LLM 为社区撰写摘要。需要参与搜索的产物还会生成嵌入，也就是用于相似度搜索的数值表示。

这些步骤遵循 Microsoft 的索引数据流。声明提取是额外的可选流程，默认关闭。构建标准图谱和报告，并不要求先提取声明。

以产品反馈文档集为例，一次访谈可能同时提到 Atlas 项目、导出失败和审批流程；另一次访谈则可能把 Atlas 与共享工作区联系起来。如果提取过程捕捉到了这些关系，即使文档措辞不同，社区报告也能把相关问题汇集到一起。

薄弱点也在这里。如果提取时漏掉了关系、把不同实体误合并，或没能识别同一实体的不同别名，后续摘要就会继承这些结构偏差。连接再整齐的图谱，也仍然只是对文本的一种解读。

默认情况下，Microsoft 将索引输出保存为 Parquet 表。Parquet 是一种列式文件格式；嵌入则写入配置好的向量存储。这种默认布局不要求另设图数据库。参见索引概览。

Global、Local、DRIFT 和 Basic 搜索怎么选？

选择查询模式，要看答案需要什么证据。全局搜索关注整个文档集的共性；局部搜索从相关实体出发。其余模式则用于更广泛的探索，或提供向量检索基线。

Global 全局搜索：归纳整个文档集的主题

如果要回答“这些文档的主要主题是什么？”，全局搜索就是评估 Microsoft GraphRAG 的核心理由。它从社区层级中选定一个层级，用该层级的社区报告作为作答材料。

这一方法采用 map-reduce：先分批处理，再合并结果。在 map 阶段，各批报告生成局部答案，其中包含带评分的要点；reduce 阶段再挑出有用的要点，组织成最终答案。社区报告越细，答案可能越详细，所需资源也可能越多。参见全局搜索文档。

对审阅客户反馈的产品负责人来说，预期收益是覆盖面更广：新用户上手、审批和协作等问题都有机会进入答案。单纯多检索一些相似段落，并不能保证这些不同方面都被覆盖。

但要明确它的边界：全局搜索是在综合报告，并不是精确统计每个问题被多少客户提及。如果决策需要按频次排序，应先用分析单位明确、包含去重规则的流程完成计数，再让模型解释结果。

Local 局部搜索：围绕实体查找关联证据

局部搜索适合“Atlas 项目与导出问题有什么关联？”这类问题。它先找到语义相关的实体，再收集与之连接的图谱信息及相关原文片段，最后筛选材料，使其适配作答时的上下文窗口。参见局部搜索文档。

当答案依赖分散在多份文档中的关系时，这种方式很有用。图谱提供入口和连接，原文提供支撑细节。不过，局部搜索仍然依赖相似度匹配，也受到上下文容量限制，因此不能保证纳入每一条相关关系。

DRIFT 搜索：从整体背景逐步深入

DRIFT 从相关社区信息出发，生成后续问题，再用局部搜索继续追查。它适合探索性问题：先得到一个较宽泛的答案，再由此发现更具体的调查方向。参见 DRIFT 文档。

例如，“这些客户为什么协作困难？”可能引出审批、共同负责以及导出交接等不同方向。把 DRIFT 设为日常问题的默认模式之前，应先评估额外搜索是否确实找到了有用证据。

Basic 基础搜索：保留对照基线

Basic 通过向量搜索检索相似文本块。Microsoft 提供这一模式，是为了便于比较不同查询类型。对于“导出政策怎么规定？”这样的具体问题，它是很有用的对照。参见查询引擎文档。

GraphRAG 与 RAG：先比较问题，再比较索引

只要能可靠回答问题，就保留最简单的检索方案。下表分别比较适用问题、索引工作和维护要求。这些是架构层面的判断，不是实测成本或速度排名。

混合搜索解决的问题与全局综合不同。Microsoft 的混合搜索文档介绍了如何组合全文检索与向量检索结果。如果应用找不到精确的产品代码，应先考虑混合搜索。用全局社区摘要解决词法检索问题，绕得太远。

Agentic RAG改变的是搜索流程。模型可以决定是否检索、判断相关性、改写问题，然后再次搜索，LangGraph 的智能体检索教程演示了这一过程。当应用需要决定下一步收集哪些证据时，可以采用 Agentic RAG。

这些方案可以组合使用。智能体可以调用图谱检索器，基于图谱的检索器也可以从混合搜索开始。关键是确认：哪一种新增机制能解决已经观察到的失误。一次把所有机制都加上，反而更难判断。

为什么 GraphRAG 的索引工作更多？

相较于纯向量索引的嵌入处理，标准 GraphRAG 还增加了生成式处理。不能拿一个放之四海而皆准的倍数，直接套在文档数量上估算成本。实际工作量取决于文本、提取配置，以及生成的图谱和报告。

规划试点时，可以用下面这个模型：

索引工作量 = 文本块处理 + 各轮提取 + 描述摘要 + 社区报告 + 嵌入。

这是试点核算模型，不是厂商报价公式。按阶段记录工作量，才能看清新增数据后，究竟是哪一部分在增长。

文本块决定重复提取的工作量。 文本块越多，需要分析的文本单元就越多。分块大小和重叠范围，会改变提取器反复读取的上下文量。Microsoft 的配置还提供 max_gleanings，用于控制额外的提取轮次。不要假设每个文本块始终只需要一次 LLM 调用。参见配置参考。

图谱规模决定后续要处理多少材料。 两个文档集即使大小相近，实体和关系丰富的那个，也可能比主题集中的那个产生更多需要整合的描述。重复提及带来需要合并的描述；多样的连接则塑造需要生成报告的社区。这些差异源于提取和摘要阶段，并不只由文档数量决定。

报告又增加了一项生成工作。 社区内容需要归纳，层级结构还会产生不同层次的概览。嵌入也依然是索引的一部分。要梳理这些工作量来源，应从标准方法的任务清单入手。

复用缓存可以省去重复的模型处理。 Microsoft 会缓存 LLM 调用结果，供后续索引运行复用。首次构建和更新应分别测量；命中缓存的重跑，不能说明处理一个全新文档集需要多少资源。参见缓存配置。

查询工作要单独预算。索引完成后，全局搜索的 map-reduce 和 DRIFT 探索仍可能涉及多次模型操作。索引试点成功，并不意味着回答延迟也能接受。

文档更新了，主题摘要为什么还会过时？

新文档进入存储，并不意味着全局搜索使用的报告已经更新。时效性目标必须覆盖查询实际读取的派生索引。

Microsoft 提供了 graphrag update；当前 CLI 文档说明，新索引默认写入 update_output。配置还提供独立的更新存储，以保留已有输出。因此，增量更新确实存在，但仅有更新命令还不等于拥有完整的同步策略。参见 CLI 参考和更新存储配置。

假设一段客服对话纠正了此前关于 Atlas 的说法。新文档可能已经入库，线上使用的社区报告却仍在描述旧情况。即使直接检索能找到更正内容，这仍然是维护失效。

请针对实际部署的版本和配置，测试新增、更正和删除操作。检查源文本块、提取出的关系，以及局部和全局搜索的答案。本文引用的 CLI 文档，并不能证明每一种变更都会自动按应用所需的语义传播到所有环节。

对运维人员来说，实际要求是：索引版本可见，源数据截止点明确。先发布一组彼此一致的产物，再把查询指向该版本。如果业务需要即时回答快速变化记录中的问题，在评估报告刷新流程期间，应保留直接检索路径。

另外两条 Graph RAG 实现路线

Neo4j 和 LlamaIndex 都提供了图谱检索组件，但在提取、存储和查询上有不同选择。应评估各自文档描述的具体机制，不要把“GraphRAG”当成一种可以随意互换的产品。

用 Neo4j 实现 GraphRAG

Neo4j GraphRAG for Python 提供 VectorCypherRetriever：先找到相似节点，再执行检索查询，收集更多上下文。Cypher 是 Neo4j 的图查询语言。这个包还支持结合向量索引与全文索引的混合检索，以及将问题转成数据库查询的 Text2Cypher。参见 Neo4j 检索器指南。

如果开发者希望明确控制“找到相关节点后，继续沿哪些关系查找”，这条路线就很合适。例如，先检索一个项目，再通过预先定义的图查询，获取与它相连的依赖项。

Neo4j 的图谱构建工具也支持用 LLM 提取实体和关系、写入图谱，以及消解重复实体。文档描述的提取错误处理机制，在没有另行配置时，可以忽略处理失败的文本块。因此，除了查询能否运行，还要检查数据摄取是否完整。参见知识图谱构建器指南。

这里的边界是：向量搜索之后再执行图查询，本身并不会生成 Microsoft 那样的层级社区报告。如果需求是广泛归纳主题，就要明确这一层由谁、如何构建。

LlamaIndex 属性图

LlamaIndex 的 PropertyGraphIndex 负责编排图谱构建与检索。属性图保存带标签的实体、实体属性以及实体之间的关系。提取器作用于文本块；SchemaLLMPathExtractor 可以将提取范围限制在允许的实体和关系模式内。VectorContextRetriever 找到带嵌入的图节点，再检索相连路径；通过检索选项，还可以获取源文本。参见属性图指南。

如果开发者希望在应用框架内配置提取器和检索器，这条路线更合适。文档中的插入、更新或插入（upsert）和删除操作，提供了维护图谱的组件；但应用仍需制定策略，处理源数据变化和派生事实。

这里的边界是：可用操作取决于图存储。默认的 SimplePropertyGraphStore 不是图数据库，也不支持 Cypher。存储与检索方式应一起选择，也不能默认属性图索引包含 Microsoft 的全局摘要流程。

GraphRAG 教程：围绕现有问题做评估

先选一个范围可控的文档集，以及答案能够由人审阅的问题。Microsoft 的仓库提醒，索引构建可能开销很大；入门指南也建议先用小数据集熟悉流程，再投入大规模任务。

工作区和凭据配置好之后，可以使用以下命令；它们采用当前文档中的 CLI 语法：

graphrag index --method standard
graphrag query "What are the main themes across these documents?" --method basic
graphrag query "What are the main themes across these documents?" --method global

在当前 CLI 参考中，查询文本是位置参数。

评估输出时，要同时看覆盖面和证据支撑。列出的主题更多，却编造了关系，这样的答案并没有解决问题。请审阅者把每个重要主题追溯到证据，记录遗漏了哪些预期主题，并检查是否把不同群体强行归纳成了一个笼统结论。

对开发者来说，只有图谱修复了原本答不好的那类问题，同时让事实查找仍保持可接受的表现，才值得采用。对运维人员来说，更新流程必须经得起更正和删除操作。对委托开发系统的采购方来说，在把图谱可视化当成答案改善的证据之前，应先要求团队用有代表性的文档演示上述能力。

如果证据已经存在，模型却反复用错格式或表现出错误行为，应重新考虑 RAG 与微调的取舍。更复杂的索引解决的是证据获取问题，并不一定适用于所有生成失败。

哪些 GraphRAG 说法被夸大了？

比起“图谱让 RAG 更好”，更站得住脚的说法其实要窄得多：特定的图谱与查询方法，可以改善特定类型的证据收集。

有连接，不代表真实。 提取出的关系和社区报告都可能出错。应把它们视为可检索的解读，并保留来源链路。图路径可以让检索过程更容易检查，却不能证明其背后的断言正确。

答案串联了更多关系，也未必更完整。 看似全面的摘要，仍可能漏掉一个孤立的问题。审阅样本应包含少数主题和难以归类的例外，尤其当它们可能改变产品决策时。

社区摘要不是频次表。 重复提及、实体连接程度，以及模型判断的重要性，都不等于去重后的客户计数。在声称某个主题最常见之前，先定义分析单位。

这个代码仓库不是 Microsoft 托管服务。 Microsoft 的仓库说明将代码定位为方法演示，而非 Microsoft 官方支持的产品或服务。部署、监控和数据更新仍需有人负责。

GraphRAG 常见问题

下周就能开始的评估

挑出应用目前答得不好的那个主题类问题，明确一个好答案需要从整个文档集中收集哪些证据。围绕这项失误做一次小规模 GraphRAG 评估，并保留现有检索器作为对照。

如果跨文档综合是反复出现的产品需求，也有人能够负责派生索引，就可以行动。如果语料变化比报告验证更快，或者没人能判断主题类答案是否完整，就先等等。如果主要工作负载是已经可靠的事实查找，就保留现有设计。最终有价值的是做出有依据的检索方案选择，无论图谱最终是否保留。

想获取构建 AI 系统的实用指南，欢迎订阅通讯。