揭秘GraphRAG：超越炒作，实践者如何判断其真正价值与设计要点

自微软于2024年初推出GraphRAG以来，它便成为了业界关注的焦点。尽管多数在线内容侧重于技术实现，但从实践者的角度来看，深入探讨GraphRAG相比传统RAG所带来的增量价值何时能抵消其额外的架构复杂性和投入，显得尤为重要。本文将尝试解答以下对于构建可扩展且稳健的GraphRAG系统至关重要的几个问题：

1. 何时需要GraphRAG？哪些因素有助于做出决策？
2. 若决定实施GraphRAG，应遵循哪些设计原则以平衡系统复杂性与实际价值？
3. 一旦部署GraphRAG，是否能以相同的准确性回答关于文档存储的任何问题？或者，是否存在需要注意的局限性，并应尽可能地实施方法加以克服？

GraphRAG与传统RAG管道对比

一个典型的传统RAG管道通常如下图所示：

传统RAG的嵌入与检索

相比之下，GraphRAG的嵌入管道则如下图所示。其检索与响应生成步骤将在文章后续部分进行讨论。

GraphRAG的嵌入管道

尽管GraphRAG管道的构建方式以及上下文检索以生成响应的方法可能存在多种变体，但与传统RAG的主要区别可归纳如下：

• 在数据准备阶段，文档会被解析以提取实体和关系，然后存储在知识图中。
• 可选但更优的做法是，使用嵌入模型对图节点值和关系进行嵌入，并存储起来以便进行语义匹配。
• 最后，文档会被分块、嵌入，并将索引存储用于相似性检索。这一步骤与传统RAG相同。

何时需要GraphRAG？

设想一个应用于执法部门的搜索助手场景，其语料库是多年来积累的浩繁调查报告文档。每份报告的第一页顶部都标有报告ID。文档的其余部分则详细描述了涉案人员及其角色（如被告、受害者、证人、执法人员等）、适用的法律条款、事件描述、证人陈述以及查获的资产等信息。

尽管本文侧重于设计原则，但在技术实现方面，可以选用Neo4j作为图数据库，GPT-4o用于实体和关系提取、推理及响应生成，而text-embedding-3-small则可用于生成嵌入。

在决定是否需要GraphRAG时，应考虑以下因素：

长文档处理

传统的RAG在分块处理时，可能会丢失数据点之间的上下文或关系。例如，当查询“车牌号PYT1234涉案的报告ID是什么？”时，如果车牌号与报告ID不在同一个分块中（报告ID通常位于第一个分块），传统RAG很可能无法给出正确的答案。因此，如果处理的文档篇幅较长，且包含大量分散在不同页面的实体（如人物、地点、机构、资产标识符等），并且需要查询这些实体之间的复杂关系，那么GraphRAG将是更优的选择。

跨文档上下文关联

传统的RAG无法在多个文档之间建立信息连接。如果查询需要跨文档链接实体，或者对整个语料库进行聚合分析，那么GraphRAG就显得不可或缺。例如，以下类型的查询：

“有多少起孟买的入室盗窃报告？”

“是否存在多案涉嫌的个人？相关的报告ID是什么？”

“请告知与ABC银行相关的案件详情。”

在由相互关联的文档组成的语料库中，这类基于分析的查询是常见需求，它能够识别看似不相关事件之间的模式。另一个例子是医院管理系统，给定一组症状，应用程序应能响应类似的既往患者病例和所采用的治疗方案。

考虑到大多数实际应用都需要这种能力，那么是否存在GraphRAG可能过度设计而传统RAG足以胜任的应用场景呢？答案是肯定的，例如公司的人力资源政策数据集。这类数据中，每个文档通常处理一个独立的主题（如休假、薪资、健康保险等），内容结构使得实体及其关系，以及跨文档链接通常并非查询的重点。

搜索空间优化

尽管GraphRAG的上述能力已广为人知，但它作为卓越的过滤器，能够将查询的搜索空间缩小到最相关的文档，这一点却鲜为人知。对于包含数千乃至数百万文档的庞大语料库而言，这一点至关重要。随着分块数量的增加，向量余弦相似度搜索会逐渐失去粒度，从而降低为查询上下文选择分块的质量。

从几何角度来看，这并不难理解。表示一个分块的归一化单位向量只是N维球体表面上的一个点（N为嵌入模型生成的维度数）。当越来越多的点密集地填充该区域时，它们会相互重叠，变得过于密集，以至于在计算给定查询的余弦匹配时，很难将任何一个点与其邻近点区分开来。

归一化单位向量的密集嵌入分布

可解释性

可解释性是密集嵌入搜索空间的一个必然结果。当余弦相似度进行语义匹配的准确性达到某个阈值后，诸如在匹配前对查询进行提示词丰富等技术将无法再有效提升检索到的上下文分块质量，因此很难解释为什么某些分块与查询匹配而另一些则不匹配。

GraphRAG设计原则

为了实现一个平衡复杂性、投入和成本的实用解决方案，在设计知识图谱时应考虑以下原则：

应提取哪些节点和关系？

将完整文档发送给大型语言模型（LLM）并要求其提取所有实体及其关系，这种做法确实很吸引人。实际上，如果在不使用自定义提示的情况下调用Neo4j的‘LLMGraphTransformer’，LLM就会尝试这样做。然而，对于大型文档（超过10页），这种查询将耗费大量时间，并且由于任务的复杂性，结果也可能不尽理想。当需要处理数千份文档时，这种方法将无法奏效。相反，应重点关注那些在查询中会频繁提及的最重要实体和关系，并构建一个星形图，将所有这些实体连接到中心节点（例如，对于犯罪数据库是报告ID，对于医院应用可以是患者ID等）。

例如，对于犯罪报告数据，人物与报告ID的关系（如被告、证人等）至关重要，而两个人是否属于同一家庭则可能不那么重要。然而，对于家谱搜索应用，亲缘关系正是构建该应用的核心原因。

从数学角度来看，星形图是一种更优方法的原因也很容易理解。一个包含K个实体的文档，如果假设只存在一种实体间关系，则可能有多达KC 2种关系。对于一个包含20个实体的文档，这意味着可能存在190种关系。另一方面，一个将19个节点连接到一个关键节点的星形图，则只有19种关系，这使得复杂性降低了90%。

采用这种方法，可以仅提取人物、地点、车辆牌照号、金额和机构名称（而不包括法律条款ID或查获资产），并将它们连接到报告ID。一个包含10份案例报告的图谱如下图所示，其生成仅需数分钟。

犯罪报告数据的星形聚类图

迭代式采纳复杂性

在项目的初始阶段（或最小可行产品MVP），应专注于处理最具价值和最频繁的查询。并针对这些查询所涉及的实体和关系构建图谱。这通常能够满足大约70-80%的搜索需求。对于剩余的部分，可以在后续迭代中逐步增强图谱，发现额外的节点和关系，并与现有的图聚类进行合并。需要注意的是，随着新数据的不断生成（例如新案件、新患者等），这些新文档必须一次性解析出所有相关的实体和关系。举例来说，在一个包含20个实体的图聚类中，最小星形聚类有19个关系和1个关键节点。如果在下一次迭代中，新增了查获资产，并创建了5个额外的节点和15个关系。那么，如果这份文档是作为新文档传入的，则需要在一个提取任务中一次性创建25个实体和34个关系。

利用图谱进行分类和上下文提取，而非直接用于用户响应

检索和增强（RAG）管道可能存在多种变体，具体取决于是否以及如何使用图节点和元素的语义匹配。经过一些实验，以下是一种可行的管道设计：

GraphRAG的检索与增强管道

具体步骤如下：

• 用户查询被用于从知识图谱中检索相关的节点和关系。这通常分两步进行：首先，LLM根据用户查询构建一个Neo4j Cypher查询。如果查询成功，则会精确匹配用户查询中给定的条件。例如，在构建的图谱中，像“有多少份来自孟买的报告？”这样的查询将获得精确匹配，因为在数据中，孟买与多个报告集群相关联。

• 如果Cypher查询未能返回任何记录，查询将回退到与图节点值和关系进行语义匹配，以找到最相似的结果。这在处理像“有多少份来自孟买（Bombay）的报告？”这样的查询时非常有用，它将返回与孟买（Mumbai）相关的报告ID，这是正确的结果。然而，语义匹配需要谨慎控制，因为它可能导致误报，这一点将在下一节中详细解释。

• 值得注意的是，在上述两种方法中，都会尝试提取与查询节点相关的报告ID周围的完整集群，以便为分块检索步骤提供尽可能准确的上下文。其逻辑如下：

• 如果用户查询是关于某个特定报告ID的（例如：“告诉我关于报告SYN-REP-1234的详细信息”），系统会获取与该ID连接的实体（人物、机构等）。虽然仅凭报告ID本身很少能找到正确的文档分块（因为LLM对报告ID等字母数字字符串不附加任何语义），但通过添加与之相关的人物、机构以及报告ID的额外上下文，便能够获得这些信息出现的精确文档分块。

• 如果用户查询是“告诉我关于车牌号PYT1234所涉事件的详细信息？”，系统会首先从图谱中获取与该车牌号相关的报告ID，然后针对该报告ID，获取该集群中的所有实体，再次为分块检索提供完整的上下文。

• 步骤1或步骤2中获得的图谱结果，连同用户查询，随后作为上下文提供给LLM，以自然语言形式生成答案，而不是Cypher查询生成的JSON或语义匹配的节点->关系->节点格式。在用户查询仅要求聚合指标或连接实体（如与汽车相关的报告ID）的情况下，LLM此时的输出通常已足够作为对用户查询的良好响应。然而，系统会将其保留为中间结果，称为“图谱上下文”。

• 接下来，图谱上下文与用户查询一起用于查询分块嵌入，并提取最接近的分块。

• 系统将图谱上下文与检索到的分块结合起来，形成一个完整的“组合上下文”，然后将其提供给LLM，以综合生成对用户查询的最终响应。

请注意，在上述方法中，知识图谱被用作一个分类器，旨在快速缩小用户查询的搜索空间，定位相关的文档集群，并将其作为分块检索的上下文。这种策略实现了从大型语料库中高效且准确的检索，同时提供了图数据库固有的跨实体和跨文档链接能力。

挑战与局限性

如同任何架构一样，GraphRAG在实际应用中也会显现出一些限制。其中一些，例如在设计图谱时平衡复杂性和成本，已在上文中讨论。以下是需要注意的其他几个方面：

• 如前文所述，知识图谱节点和关系的语义检索有时会导致不可预测的结果。设想这样一种情况：查询一个未被提取到图聚类中的实体。首先，精确的Cypher匹配会失败，这是预期的；然而，回退的语义匹配无论如何都会检索到它认为相似的结果，尽管这些结果与查询无关。这会意外地产生不正确的图谱上下文，从而检索到错误的文档分块，并导致事实性错误的响应。这种行为比RAG回复“我不知道”更糟糕，因此在生成图谱上下文时，需要通过详细的负面提示词（negative prompting）来严格控制LLM，使其在此类情况下输出“无记录”。
• 在构建图谱时，通过LLM一次性处理整个文档来提取所有实体和关系，即使经过详细的提示词调优，也常常会因“注意力下降”而遗漏其中一些。这是因为当文档长度超过一定限制时，LLM的召回率会下降。为了缓解这一问题，最佳做法是采用基于分块的实体提取策略，具体如下：
  • 首先，一次性提取报告ID。
  • 然后将文档分割成多个分块。
  • 逐个分块地提取实体，并由于正在创建星形图，将提取到的实体连接到报告ID。

• 去重与规范化：在将名称插入图谱之前进行去重至关重要，以确保在多个报告集群中正确创建共同的实体链接。例如，警官约翰逊（Officer Johnson）和督察约翰逊（Inspector Johnson）在插入图谱前应统一规范化为约翰逊（Johnson）。

• 更重要的是对金额进行规范化，如果希望运行诸如“有多少起欺诈报告涉及10万到100万之间的金额？”的查询。为此，LLM将正确生成像(amount > 100000 AND amount < 1000000)这样的Cypher查询。然而，从文档中提取到图聚类中的实体通常是字符串形式，例如‘5 Million’，如果文档中就是这样呈现的。因此，在插入图谱之前，必须将这些字符串规范化为数值。

• 节点应包含文档名称作为属性，以便在结果中提供溯源信息。

• 图数据库（如Neo4j）提供了一种优雅、低代码的方式来构建、嵌入和检索图谱中的信息。但有时也会出现行为异常且难以解释的情况。例如，在针对某些类型查询进行检索时，如果预期结果中包含多个报告集群，LLM会生成一个格式完美的Cypher查询。该Cypher查询在Neo4j浏览器中运行时可以正确获取多个记录集群，然而，在管道中运行时却可能只获取一个。

总结

最终，构建一个能够精确细致地表示文档中每个实体及所有关系，并能以同样高精度回答用户所有查询的知识图谱，很可能是一个构建和维护成本过于高昂的目标。因此，在GraphRAG项目中，如何在复杂性、时间和成本之间取得恰当的平衡，将是决定项目成功的关键因素。

此外，还应牢记，尽管RAG主要用于从非结构化文本中提取洞察，但一个实体的完整信息通常也分散在结构化（关系型）数据库中。例如，一个人的地址、电话号码和其他详细信息可能存在于企业数据库甚至ERP系统中。要获取一个事件的完整详细信息，可能需要利用LLM通过多模态（MCP）代理查询这些数据库，并将这些信息与RAG相结合。但这将是另一篇文章探讨的话题。

展望未来

本文主要关注GraphRAG的架构和设计方面，后续文章将深入探讨其技术实现。届时将包含提示词、关键代码片段，并详细阐释管道工作原理、所提及的结果及局限性。

值得思考的是，将GraphRAG管道扩展以纳入多模态信息（如图像、表格、图表），从而提供更完整的用户体验。可以参考关于构建真正的多模态RAG的文章，该方案能够同时返回图像和文本。