GraphRAG：AI如何回答隐藏在多份文档中的问题
人工智能的下一个瓶颈是部署。（赞助）
将新模型转化为能在真实客户运营中运行的系统仍然很难。
这一空白正在创造对能够在代码、客户环境和生产成果之间切换的工程师的需求。于是：前线部署的工程师登场。
该免费联邦发展与发展部2026年就业报告围绕这项工作绘制了新兴劳动力市场的地图。
想象一个基于人工智能的检索系统，指向你团队五年的工程文档，包括设计文档、事故分析和架构决策记录。有人问哪个服务拥有支付重试逻辑，系统给出的回答相当准确且引用充分。
然而，当有人问所有事后分析中最常出现的故障原因时，答案质量就会下降。
根据不同的设置，回答可能会列出少数涉及“反复”一词的事件，但我们从回答中无法了解背后的模式。换句话说，提出这个问题的理由并未被满足。
这两个问题从外表看可能相似。然而，在建筑上，它们是截然相反的：
- 第一个答案可以在特定文档中找到，这正是相似性搜索的初衷。
- 第二个答案只有在对整个收藏进行调查和理解后才会出现。这需要完全不同的取回机制。
GraphRAG 设计用于处理第二类问题，本文将对此进行更多了解。以下是我们将涵盖的内容：
- 标准RAG检索是如何运作的，以及它的极限在哪里
- 知识图，以及如何从普通文档中构建出来
- GraphRAG 索引流水线
- 社区检测与层级摘要
- 局部搜索与全局搜索
- 成本、延迟和维护权衡
- 当标准RAG仍然是更好的选择时
- 代理性RAG
免责声明：本文基于来自多个公开来源的详细信息。最后有参考。如果你发现任何不准确之处，请评论。
检索基础知识
标准的RAG（检索增强生成）依赖于紧凑的流水线。
我们取一组文档，将每个文件切成几百到几千个令牌的块，然后通过嵌入模型处理每个块。嵌入模型返回一个向量，基本上是一长串数字，代表该文本的含义。
具有相关含义的块会产生在同一数值空间中紧密相邻的向量。所有这些向量都被放进一个向量索引中。
在查询时，同样的处理方式适用于问题。问题也变成向量，索引返回最接近它的几个区块向量，这些区块的原始文本会与问题一起放入提示词中。
语言模型随后从提供的文本中生成答案。
整个设计基于一个简单的假设：回答问题的文本会类似于该问题。对于很大一部分查询，这一假设依然成立。例如，像“哪个服务拥有支付重试逻辑”这样的问题，包含与架构决策记录中所有权记录相同的词汇。
这些载体彼此靠近，检索时返回正确的文档，引用点也指向读者能真正核实的地方。
相似性限制
关于问题与答案相似的假设适用于特定类别的问题，但绝非普遍现象。
Microsoft的GraphRAG文档区分了本地查询与全局查询。局部查询的答案与查询相似，且存在于少数文本区域内，涵盖大多数关于谁、什么、何时和何地的问题。
全局查询需要跨数据集的大部分或全部进行推理。
我们之前的两个例子问题分别位于这条线的两侧。“哪个服务拥有重试逻辑”这个问题是本地的。然而，“哪种故障导致的在所有尸检中最频繁”这个问题是全球性的。
第二个答案质量下降的原因是“最频繁重复”这个短语会产生一个向量，而索引返回的是最接近它的向量。在事件报告语料库中，最近的邻居通常是使用“recurring”（重复）或“频繁”（FQUENT）等词汇的文档，这只是词汇的巧合。
然而，问题的真正答案存在于两百份文档中，以分布方式分布，覆盖整个语料库，而非仅占用一个可检索的位置。
此时合理的反对意见是，现代上下文窗口足够大，可以完全绕开这个问题。Microsoft 正是对此进行了测试，将 GraphRAG 与矢量检索对比，分别获取了 8,000 和 64,000 个上下文标记。
然而，在全球问题上，较大的窗口在全面性、多样性和支持性来源质量方面留下了空白。
这种结果通常被称为幻觉问题。实际上，检索返回的内容与问题影响不大，模型从中生成流畅文本。
[网络研讨会]如何停止对经纪人进行“保护”（赞助）
代理可以生成代码。为你的系统、团队惯例和以往决策做对，是最难的部分。你最终会在修正循环中浪费时间和代币。
更多的MCP、规则和更大的上下文窗口让代理能够访问信息，但无法理解。领先的团队拥有上下文层，为客服提供他们当前任务所需的信息。
- 团队在AI成熟度曲线上卡住的地方以及为何常见的修复方法难以做到
- 上下文层如何解决质量、效率和成本问题
- 现场演示：同样的编码任务，有上下文层和没有上下文层
如果你想最大化AI代理带来的价值，这款游戏值得你花时间。
知识图谱
在回答质量上跨越这一界限，需要记录文档之间的关系，而不是将每个段落视为独立的文本单元。知识图谱是一种记录方式。
知识图谱存储两种信息：
- 实体是语料库所指的名词，如人、服务、团队、事件和决策。
- 关系是这些实体之间的类型连接。
两者均附有纯文本描述。
摘一段事件事后总结：“结账服务在支付团队于3月3日部署新的重试处理器后开始返回超时。”对该句子进行提取后，会生成结账服务、支付团队和重试处理程序的实体，并记录团队部署了处理程序且部署发生在超时之前的关系。
当成千上万句子各自贡献节点和边时，就会出现单一文档不包含的路径。工程师可能在一个设计文档中被命名，服务在第二个文档中命名，事件在第三个文档中描述，从该工程师到该事件的路径会经过两个中间节点。
LinkedIn的客户服务团队于2024年在SIGIR上发布了这一方法的成果。他们的支持工单以纯文本形式存储，丢弃了每个工单的内部结构以及工单之间的关联。
围绕保持平均互惠排名提升了77.6%，且每期中位数解决时间在生产中下降了28.6%，重新构建了知识图谱。同样，Neo4j的文档将词汇图（将文档与其块）与实体图（连接这些文档描述的内容）分开。
大多数 GraphRAG 系统构建两者并跨它们查询。
图构造
从原始文档构建该图是一个流水线，其大部分成本集中在单一阶段。
供参考，Microsoft 的索引工作流程分为六个阶段：
- 文档被切分成文本单元，采用与标准RAG相同的分块步骤。
- 语言模型处理每个文本单元，提取携带标题、类型和描述的实体，以及包含源、目标和描述的关系。
- 共享标题和类型的实体会在文本单元间合并，它们的描述会被收集到数组中。第二种语言模型的通道将每个数组压缩为一个描述。关系也会受到同样的对待。
- 权利主张提取可选择性运行，产生关于实体的限时事实陈述。
- 组装后的实体图被聚类成社区层级。
- 社区报告被生成，文本单元、实体描述和报告内容嵌入向量存储中。
合并步骤承担了大量费用。例如，一项跨越两百份文档的服务在提取过程中会产生两百个独立描述。每一个变量都必须被调和成一个连贯的描述，图才可用。
每个提取的实体、关系和权利要求都会保留指向其来源文本单元的指针。这个指针让生成的答案能够引用特定文档中的某个段落。
此外，两个语言模型对整个语料库的传递会增加大量的推理能力。Microsoft的文档估计，图提取大约占总索引成本的75%。最后，提取质量还取决于针对该领域的提示。
另外，FastGraphRAG用传统NLP替代了提取中的语言模型，将名词短语视为实体，区块内的共现视为关系。索引成本大幅降低，生成的图噪声也大幅增加
社区检测
实体和关系的图很好地回答了连接问题。然而，回答整套合集的问题还需要再加一层。
GraphRAG 在实体图上运行分层式莱顿聚类。该算法递归地将图划分为称为群集的簇，并持续细分，直到群落大小低于某个阈值。输出是一个包含多个层级的层级结构。
这些层级表现为同一底层图的分辨率控制。第0级包含少量广阔的社区，每个社区覆盖一个大区域。更深层包含更多社区，每个社区覆盖更狭窄的区域。
一个处于0级的单一支付社区可能会分裂成两个层级的独立社区，用于重试行为、结算和欺诈检查。
对于每个社区、每个层级，语言模型都会生成社区报告。每份报告都包含该社区的概览及其主要实体、关系和主张。报告随后被简化成简写版本，以便查询时简洁使用。
这一步让整套收藏的问题都能回答。在索引过程中，会在有人问之前，写出一堆文件集体的摘要。当一个全球性问题出现时，回答它所需的材料已经以文本形式存在。
提供报告的具体层级是一个具有实际影响的决定。Microsoft的文档指出，响应质量受到这一选择的高度影响。较低级别的回答更为详尽，因为报告细节更多，但也花费更多时间和代币，因为需要处理的报告更多。
查询模式
通过一个图表和报告层级放在磁盘上，检索可以沿着两条结构不同的路径进行。GraphRAG 支持这两种方式。
局部搜索首先将查询与实体描述嵌入匹配，从而生成一组入口实体。从每个入口点开始，扩展方向并行地沿五个方向展开：
- 提及实体的文本单元。
- 包含该内容的社区报告。
- 与其相连的邻近实体。
- 那些建立联系的关系。
- 协变量，即任何与之相关的提取要求。
每个候选集都会独立排序和筛选。幸存者被压缩在一个预定义大小的单一上下文窗口中。该展开是有界的，排名是显式的，这使得局部搜索更接近结构化的收集与排序操作，而非跨图的开放式路径寻觅。
全局搜索则保持实体图不变。来自特定层级的社区报告会被拆分成批次，这些批次会被重新洗牌，以确保批次顺序保持随机。地图阶段将每批数据通过语言模型运行，生成一个中间答案，每个点都带有数值重要性评级。
然后，简化阶段收集所有批次中评分最高的分数，并从中生成最终答案。
回归我们的支付问题的映射现在可以更加清晰。问题是：“哪个服务拥有重试逻辑”会命名一个实体，所以本地搜索会定位它并围绕它展开。
此外，“哪个故障导致重复次数最多”这个问题没有具体点名实体，因此全局搜索会在覆盖整个语料库的预先编写报告中汇总。
请看下面的示意图：
第三种模式——漂移搜索，融合了两者。它首先将查询与最相关的社区报告进行比较，生成一个广泛的初始答案和后续问题，然后对这些后续问题进行本地搜索，并返回按相关性排序的问题和答案层级。
GraphRAG 还提供一个基本的搜索模式，即纯的 top-k 向量检索，适用于仍需使用该工具的查询。当回答内容宽泛而浅薄，或狭隘而精准时，查询模式通常会解释原因。
[图6。本地搜索和全局搜索并列] 左面板追踪查询至匹配实体，然后是五个并行扩展流，再是每个流的排名和过滤，最后是一个组装好的上下文窗口。
右侧面板将查询与社区报告批次并列，分为并行映射调用，生成有评级的中间答案，然后过滤，再到减少调用，最终得到答案。
成本权衡
到目前为止，我们关注的是与GraphRAG相关的各种功能。然而，成本决定了某项特定能力是否值得为特定系统采购。
标准RAG在两端的成本都较小，每次查询只需一次嵌入处理和一次最近邻查找。相比之下，GraphRAG大幅度地重新分配了这些支出。索引时间吸收了语料库中的两次语言模型处理，以及每个社区在每个层级的报告生成。
查询时间随后分开，本地搜索在预设的上下文窗口下运行，全局搜索则通过语言模型跨多个报告批次运行，针对单个问题。
该索引也是一个派生的文物。新文档的到来意味着提取、聚类和摘要会对受影响材料进行重新处理，社区层级本身也可能随着图的增长而发生变化。
对于每天都在变化的语料库来说，这成为一项持续的运营承诺。
Microsoft自己的后续工作直接涉及了成本问题。例如，LazyGraphRAG 使用自然语言处理而非语言模型构建索引，完全跳过摘要，并将所有语言模型工作推迟到查询时间。
在这种情况下，索引成本与向量RAG一致，且为完整GraphRAG的0.1%。全局查询质量与全球搜索持平，查询成本下降了700倍以上。
Microsoft仍然反对让所有部署都采用LazyGraphRAG。他们所说的理由是，预设的实体、关系和社区摘要具有超越问答的价值，因为人们会直接阅读并分享这些报告。
Microsoft自身评估的两项发现如下：
- 向量RAG仍然是本地查询更强的选择，因为答案与问题相似且位于特定文本区域。
- GraphRAG 的优势在于其全面性、多样性以及支持的原始材料。在忠诚度方面，它的得分与基础RAG相当。
第二点很重要，每当有人问GraphRAG是否能减少幻觉时。证据支持更好的报道和更完善的来源，但并未声称每个具体说法的事实准确性更高。
能动检索
由于不同题型有利于不同的检索策略，系统建立时坚持一种策略会放弃其他策略。
能动性RAG有助于制定对该约束的回应。
语言模型对输入查询进行分类，选择检索策略，执行并综合结果。可用的策略可能包括针对局部问题的向量搜索、针对语料库范围问题的全局搜索、用于结构化数据的SQL查询，以及针对当前问题的网页搜索。
LlamaIndex 记录了该内容的两层版本：
- 复合检索器根据每个索引提供的描述选择要查询的索引。
- 在所选索引中，自动路由模式会选择适用于该查询的检索方法。
换句话说，路由决策发生在两层之间。
这种做法也有其代价。它在检索前增加了语言模型调用，这增加了延迟和每次查询的花费。路由错误还会导致调试问题，因为错误的检索结果可能来自于错误的策略。
从基础RAG到高级RAG，再到GraphRAG，再到代理RAG的整体进程描述了系统何时承诺检索策略的一系列决策过程。它作为梯子效果很好，每一步都优于下面的步骤。
结论
在这篇文章中，我们深入探讨了GraphRAG，并对其进行了详细理解。以下是需要记住的关键学习点：
- 局部查询的答案与问题相似，且分布在少数文本区域内，而全局查询则需要跨集合的大部分推理。
- 相似性搜索返回最接近查询向量的区块，因此全局问题往往检索词汇匹配，而非底层模式。
- 更大的上下文窗口会留下这个空隙。在Microsoft测试中，64,000个令牌的矢量检索在全球问题上仍落后。
- 知识图谱存储实体和类型关系，并附有描述，保留了直接分块时被丢弃的连接。
- GraphRAG 索引会对语料库执行两次语言模型通道，一次提取实体和关系，一次合并它们的描述。
- 图提取约占索引成本的75%，是减少开支时首先要考虑的阶段。
- 分层莱顿聚类在同一实体图上产生多个分辨率层级的社区。
- 每个社区、每个层级都会生成一份社区报告，因此语料库整体内容的摘要在任何问题出现之前就已存在。
- 本地搜索从匹配实体展开，并将结果排序到一个上下文窗口，而全局搜索则在社区报告中运行地图-减少。
- 指数是导出且易损的。LazyGraphRAG 通过将语言模型工作移至查询时间，将索引成本降低至 GraphRAG 完整版的 0.1%。
- 向量RAG在本地查询中依然更强，而代理检索则是每次查询选择一种策略，而不是在系统构建时承诺某一策略。
点赞
收藏
点踩
分享