GraphRAG: How AI Answers Questions Hidden Across Many Documents

GraphRAG：AI如何回答隐藏在众多文档中的问题

ByteByteGo

2026年8月19日

AI的下一个瓶颈是部署。（赞助）

将新型模型转化为能在真实客户运营环境中运行的系统仍然充满挑战。

这种差距催生了能够跨越代码、客户背景和生产结果之间界限的工程师需求。由此诞生了：前线部署工程师。

免费的《2026年FDE职位状态报告》映射了围绕这项工作的新兴劳动力市场。

在此查看报告

想象一个基于AI的检索系统，它指向了您团队五年来的工程文档，包括设计文档、事故复盘和架构决策记录。有人询问哪个服务负责支付重试逻辑时，系统会给出一个准确且引用充分的答案。然而当有人询问所有复盘中反复出现的故障原因时，答案质量却明显下降。

根据具体设置，系统可能会列出几个恰好使用了"recurring"这个词的事件，但答案中无法让我们理解背后的模式。换句话说，提问的初衷并未得到满足。

从外部看，这两个问题可能看似相似。但从架构层面来看，它们却是完全相反的：

• 第一个问题的答案存在于特定文档中，这正是相似性搜索设计的初衷。
• 第二个问题的答案只有在完整遍历并理解整个文档集合后才能显现，这需要完全不同的检索机制。

GraphRAG专为处理第二种类型的问题而设计，本文将深入探讨这一技术。我们将涵盖以下内容：

• 标准RAG检索的工作原理及其局限性
• 知识图谱及其如何从普通文档中构建
• GraphRAG的索引流程
• 社区检测与分层摘要
• 本地搜索与全局搜索
• 成本、延迟与维护的权衡
• 标准RAG仍为更优选择的场景
• 代理式RAG

免责声明：本文基于来自多个来源的公开信息。文末有参考文献。如发现任何不准确之处，请在评论区指出。

检索基础

标准RAG（检索增强生成）依赖于一个紧凑的流程。

我们从文档集合中提取文档，将每个文档切分为数百到数千个标记的片段，然后将每个片段输入嵌入模型。嵌入模型返回一个向量，这基本上是一个长数字列表，代表文本的含义。具有相关含义的片段会产生在相同数字空间中彼此接近的向量。所有这些向量都会被存储到向量索引中。

在查询时，问题也会经历同样的处理。问题同样转化为向量，索引会返回与之最接近的几个片段向量，这些片段的原始文本会与问题一起放入提示中。语言模型随后根据提供的文本生成答案。

整个设计基于一个简单的假设，即回答问题的文本会与该问题本身相似。对于大多数查询来说，这一假设成立得相当好。例如，“哪个服务负责支付重试逻辑”这样的问题，其使用的词汇与记录该职责归属的架构决策文档中的词汇是相同的。这些向量彼此接近，检索能返回正确的文档，并且引用会指向读者可以实际验证的位置。

相似性限制

关于问题与答案相似的这一假设，仅适用于特定类型的问题，而非普遍适用。

微软的GraphRAG文档将查询分为本地查询和全局查询两类。本地查询的答案例似查询本身，并且存在于少量文本区域中，涵盖大多数“谁、什么、何时、何地”类问题。而全局查询需要跨数据集的大范围内容或全部内容进行推理。

我们之前提到的两个示例问题正好位于这条分界线的两端。“哪个服务负责重试逻辑”属于本地查询。然而，“所有事后分析中哪种故障最常重复发生”则属于全局查询。

第二个问题的答案质量下降的原因在于，“最常重复发生”这一短语生成的向量会使索引返回最接近它的内容。在事故报告语料库中，最近邻文档可能包含“反复发生”或“频繁”等词汇，这仅是词汇上的巧合。然而，该问题的真实答案却分布在200个文档中，这些文档覆盖了整个语料库，而非集中于某个可检索的位置。

此时一个合理的质疑是，现代大语言模型的上下文窗口足够大，可以完全规避这个问题。微软确实进行了相关测试，将GraphRAG与分别引入8,000和64,000个token上下文的向量检索方法进行对比。然而在全局查询场景中，更大的上下文窗口反而在全面性、多样性和支持材料质量方面留下了更大缺口。

这一现象通常被标记为“幻觉”问题。实际上发生的情况是，检索返回的材料与问题关联度很低，模型却据此生成了流畅的文本。

[网络研讨会] 如何停止对代理进行过度监护（赞助）

代理可以生成代码。但要让这些代码符合系统要求、团队规范和历史决策，才是真正的难点。你最终会花费大量时间和token在修正循环中。

更多的MCP规则、更大的上下文窗口虽然为代理提供了更多信息访问权限，但并未带来真正的理解能力。领先团队的做法是构建一个上下文层，为代理提供完成当前任务所需的精准信息。

9月2日加入我们的免费网络研讨会，了解：

• 团队在AI成熟度曲线上常遇到的瓶颈及常见解决方案为何失效
• 上下文层如何提升质量、效率和成本控制
• 实时演示：有无上下文层支持下完成相同编码任务的对比

如果你想最大化利用AI代理的价值，这场研讨会值得你参与。

立即注册

知识图谱

要突破答案质量的边界，需要记录文档之间的关联关系，而非将每个文本片段视为独立单元。知识图谱是实现这一目标的一种方式。

知识图谱存储两类内容：

• 实体是语料库中讨论的名词，例如人员、服务、团队、事件和决策。

• 关系是这些实体之间的类型化连接。

两者都包含纯文本描述。

从事件复盘中摘取一句话：“支付团队于3月3日部署新的重试处理器后，结账服务开始返回超时。” 对这句话进行实体抽取会生成结账服务、支付团队和重试处理器三个实体，并记录团队部署了处理器且部署发生在超时之前的关系。

当数千个句子各自贡献节点和边后，会形成单一文档中不存在的路径。例如，某位工程师可能在一份设计文档中被提及，某项服务在另一份文档中被提及，某次事件在第三份文档中被描述，而从该工程师到该事件的路径会经过中间节点。

LinkedIn 的客户服务团队在2024年SIGIR会议上发表了该方法的研究成果。他们之前将支持工单存储为纯文本，这导致每个工单的内部结构以及工单之间的关联都被丢弃。通过围绕知识图谱重建检索系统，在保留结构后平均倒数排名提升了77.6%，生产环境中每问题中位解决时间下降了28.6%。同样，Neo4j 的文档将词法图（链接文档与其片段）与实体图（链接文档描述的事物）分开处理。

大多数 GraphRAG 系统会构建这两类图并跨图查询。

图构建

从原始文档构建该图是一个流水线过程，其大部分成本集中在单一阶段。

以微软公开的索引流程为例，其包含六个阶段：

• 文档被切分为文本单元，这与标准 RAG 的分块步骤相同。

• 语言模型处理每个文本单元，提取包含标题、类型和描述的实体，以及包含源、目标和描述的关系。

• 共享相同标题和类型的实体在文本单元间合并，描述信息收集到数组中。第二次语言模型处理将每个数组压缩为单一描述。关系也接受相同处理。

• 可选的声明抽取阶段生成与实体相关的时间限定事实性陈述。

• 组装后的实体图被聚类为社区层次结构。

• 生成社区报告，将文本单元、实体描述和报告内容嵌入向量存储。

合并步骤承担了大部分成本。例如，某个服务在200个文档中被提及，抽取时会产生200个独立描述。所有这些描述必须整合为单一连贯描述后，图才能投入使用。

每个抽取的实体、关系和声明都会保留指向原始文本单元的指针。正是这个指针使得生成的回答能够引用特定文档中的特定段落。

此外，对整个语料库进行两次语言模型处理会带来大量推理成本。微软的文档估计图抽取约占总索引成本的75%。最后，抽取质量也依赖于针对特定领域优化的提示词。

作为独立的一点，FastGraphRAG用传统NLP替代了抽取过程中的语言模型，将名词短语视为实体，将块内的共现视为关系。索引过程的成本大幅降低，但生成的图包含更多噪声。

社区检测

实体和关系构成的图能够很好地回答连接类问题。但要回答涉及整个文档集合的问题，还需要在其基础上增加一层处理。

GraphRAG在实体图上运行分层Leiden聚类算法。该算法递归地将图划分为称为社区的簇，并持续细分直到社区规模低于设定阈值。输出结果是一个包含多个层级的层次结构。

这些层级相当于对同一底层图的分辨率控制。第0层包含少量宽泛的社区，每个社区覆盖较大区域。更深层级包含更多社区，每个社区覆盖更狭窄的区域。第0层的一个支付社区可能在向下两层时细分为重试行为、结算和欺诈检查等独立社区。

每个层级的每个社区都会由语言模型生成社区报告。每个报告包含该社区的概述及其关键实体、关系和主张。随后这些报告会被再次总结为简明版本，以便在查询时使用。

这一步使回答整个文档集合的问题成为可能。在索引阶段，文档集合的总结性内容会被提前写入，远早于任何查询发生。当出现全局性问题时，所需材料早已以文本形式存在。

选择哪个层级提供报告是一个具有实际影响的决策。微软的文档指出，这个选择会显著影响响应质量。较低层级的报告包含更多细节，因此能生成更全面的回答，但处理大量报告也会消耗更多时间和token。

查询模式

当图结构和报告层级已存储在磁盘上时，检索可以沿着两种结构不同的路径进行。GraphRAG支持这两种方式。

本地搜索首先将查询与实体描述的嵌入向量进行匹配，产生一组入口实体。从每个入口点出发，会同时向五个方向扩展：

• 提到该实体的文本单元
• 包含该实体的社区报告
• 与该实体相连的相邻实体
• 构成这些连接的关系
• 协变量，即附加到该实体的任何提取主张

每个候选集都会独立进行排序和过滤。幸存者会被打包到预定义大小的单一上下文窗口中。扩展过程有明确边界，排序过程是显式的，这使得本地搜索更接近结构化的收集-排序操作，而非在图中进行开放式路径搜索。

全局搜索则不接触实体图。从选定层级选取的社区报告被拆分为批次，然后打乱批次顺序以保持随机性。映射阶段将每个批次输入语言模型，生成中间答案，其中每个点都带有数值重要性评分。归约阶段会收集所有批次中评分最高的点，并从中生成最终答案。

现在，我们可以更清晰地将这些映射回我们的支付问题。问题“哪个服务负责重试逻辑”指定了一个实体，因此本地搜索会定位它并围绕它展开。而问题“哪种故障最常重复发生”没有指定特定实体，因此全局搜索会跨所有预写报告进行聚合分析。

请参见下图：

第三种模式是DRIFT搜索，它结合了前两种模式。它首先将查询与最相关的社区报告进行对比，生成一个广泛的初步答案并提出后续问题，然后对这些后续问题运行本地搜索，最终返回按相关性排序的问题和答案层次结构。

GraphRAG还提供了一种基础搜索模式，即普通的Top-K向量检索，适用于仍需使用该工具的查询。当返回的答案宽泛浅显，或狭窄精确时，查询模式通常会解释这种差异。

[图6. 本地搜索与全局搜索并排对比] 左侧面板追踪查询到匹配实体，然后是五个并行扩展流，接着是每流的排序和过滤，最后是单个组装的上下文窗口。右侧面板追踪查询与随机排列的社区报告批次，进入并行映射调用生成评分的中间答案，然后进行过滤，最后通过归约调用生成最终答案。

成本权衡

到目前为止，我们探讨了与GraphRAG相关的各种功能。然而，成本决定了特定功能是否值得为某个系统部署。

标准RAG在两端成本都较为适中，索引时进行一次嵌入处理，每次查询进行一次最近邻查找。相比之下，GraphRAG显著重新分配了成本。索引阶段需要对语料库进行两次语言模型处理，并在每个层级的每个社区生成报告。查询阶段则分为两部分：本地搜索以较低成本针对准备好的上下文窗口运行，而全局搜索则需要对多个报告批次运行语言模型来回答单个问题。

索引本身也是一个衍生产物。新文档的加入意味着需要重新对受影响内容进行提取、聚类和摘要，而社区层次结构本身可能随着图的增长而发生变化。对于每日更新的语料库，这会成为持续的运营投入。

微软后续的工作直接解决了成本问题。例如，LazyGraphRAG通过NLP而非语言模型构建索引，完全跳过摘要生成，并将所有语言模型工作推迟到查询阶段。在这种情况下，索引成本与向量RAG相当，仅为完整GraphRAG的0.1%。全局查询质量与全局搜索相当，但查询成本下降了700多倍。

微软仍不建议所有部署都使用LazyGraphRAG。他们的理由是，预构建的实体、关系和社区摘要的价值不仅限于问答，因为人们会直接阅读和分享这些报告。

微软自身评估的两个发现如下：

• 向量RAG在本地查询中仍是更优选择，当答案与问题相似且位于特定文本区域时。

• GraphRAG的优势体现在全面性、多样性和对源材料的支持上。在忠实性方面，其表现与基线RAG相当。

第二个要点在有人质疑GraphRAG是否减少幻觉时尤为重要。现有证据表明GraphRAG能提升覆盖范围和信息溯源质量，但尚未能证明其在单个事实准确性上具有优势。

智能检索

由于不同类型的查询需要不同的检索策略，系统构建时若固守单一策略将丧失其他可能性。

智能RAG通过动态策略选择解决了这一限制。语言模型会先对查询进行分类，再选择对应的检索策略执行并整合结果。可用策略包括：针对本地问题的向量搜索、针对全局问题的全库检索、针对结构化数据的SQL查询，以及针对时效性内容的网络搜索。

LlamaIndex实现了该架构的双层版本：

• 复合检索器根据每个索引提供的描述信息，决定查询哪个索引
• 在选定索引内，自动路由模式会进一步判断具体查询适用的检索方法

换句话说，路由决策在两个层级都会发生。

该方案也带来额外成本：检索前增加了语言模型调用，导致延迟和单次查询成本上升。路由错误还会引发调试难题，因为错误的策略可能导致原本正确的检索返回错误答案。

从基础RAG到高级RAG再到GraphRAG最终到智能RAG的演进过程，本质上是系统在不同阶段对检索策略选择时机的决策序列。这种演进路径如同阶梯，每个阶段都优于前一个阶段。

结论

本文深入探讨了GraphRAG技术，以下是关键要点：

• 本地查询的答案通常与问题相似，且集中在少量文本区域；而全局查询需要跨大量文本内容进行推理
• 相似度搜索返回与查询向量最接近的文本块，因此全局问题往往匹配词汇而非底层模式
• 更大的上下文窗口仍无法完全解决这一问题，微软测试显示64,000 token的向量检索在全局问题上仍表现不佳
• 知识图谱通过存储实体及其带描述的类型关系，保留了普通分块处理会丢失的关联信息
• GraphRAG索引过程对语料库进行两次语言模型处理：第一次提取实体和关系，第二次合并描述信息
• 图谱提取约占索引成本的75%，是降本优化的首要考察阶段
• 分层Leiden聚类算法能在同一实体图上生成多个粒度级别的社区结构
• 每个层级的每个社区都会生成社区报告，因此在任何查询到来前，语料库的整体观点摘要已就绪
• 本地搜索从匹配实体扩展并排序至一个上下文窗口，而全局搜索则通过社区报告进行Map-Reduce处理
• 索引具有衍生性和时效性，LazyGraphRAG通过将语言模型工作移至查询阶段，将索引成本降至完整GraphRAG的0.1%
• 向量RAG在本地查询上仍具优势，智能检索则根据每个查询动态选择策略，而非系统构建时固定策略