一文看懂GraphRAG与传统RAG的7大区别及融合方案，你会怎么选择？

大飞攻城狮

于 2024-09-04 09:43:37 发布

阅读量2.2k

点赞数 15

文章标签：人工智能大模型大模型入门 AI大模型大模型教程大模型学习

本文链接：https://blog.csdn.net/m0_63171455/article/details/141884899

版权

GraphRAG是一种基于知识图谱的检索增强生成（RAG）应用，不同于传统基于向量检索的RAG应用，其允许进行更深层、更细致与上下文感知的检索，从而帮助获得更高质量的输出。

我们已经用几篇文章演示过GraphRAG应用的基本创建与使用过程（基于Langchain/LlamaIndex，以及Microsoft GraphRAG框架）。那么什么时候应该使用GraphRAG，而什么时候又应该回归传统的RAG？二者能组合应用吗？本文将对此进行探讨：

7个方面对比GraphRAG与传统RAG
GraphRAG与传统RAG的融合使用

对比GraphRAG与传统RAG

这里不再累述传统RAG与GraphRAG的基本原理，直接从几个不同角度来看它们之间的区别，以帮助作出技术选择。

适合的场景

使用传统RAG还是GraphRAG从根本上取决于数据特征与查询问题两个方面，因此这也是它们在适用性的根本差异。很难用绝对量化的方式去定义这样的差异，但通常来说，具备如下特征的数据更适合使用GraphRAG：

**有着较多的相互关联实体与复杂关系，且结构较明确的数据。**比如：

人物关系网络数据：如社交网络中的用户关系、历史人物之间的关系、家族图谱等。
企业中的具有复杂实体关系的结构化数据。比如公司结构、供应链、客户等之间的关系。
医学知识与疾病诊断数据：涉及疾病、症状、治疗、药物、传播、病例等之间复杂关系。
法律法规与判例分析数据：涉及法律条款之间的引用关系、解释、判例与适用法律条款的关系。
产品推荐系统数据：涉及到产品、用户、浏览内容、不同产品之间的关联、用户之间的关系等。

除了数据本身外，使用者的查询问题是要考虑的另外一方面。**GraphRAG更擅长处理涉及复杂关系、语义推理和多步逻辑关联的查询，或者关于知识本身元数据的问题。**比如

多跳关系查询：在xxx的同学的朋友中，谁在阿里巴巴工作？
语义关联查询：哪些公司提供LLM产品，并且已经取得国家认证许可？
知识推理查询：根据患者的症状和病史，推断可能的疾病并提供治疗方案。
涉及聚合统计查询：过去两年中大模型增加了多少，哪些公司占主导地位？
时序关联查询：查询过去10年的xxx公司的投资与并购事件？

GraphRAG针对这样的问题提供了更强的数据导航与综合能力，而在传统RAG中只能检索出向量上相似的“块”（chunk），而对其他部分则更可能产生幻觉。相对来说，传统RAG则更适合回答基于数据内容的事实性问题，比如“xxxx产品是哪一年正式发布的？”

知识表示

GraphRAG与经典RAG采用了不同的知识表示形式。假如现在需要构建一个基于已有产品、用户等数据的推荐系统，那么如何对已有的数据集进行知识表示呢？

【GraphRAG】

在 GraphRAG 中，可以将产品、品牌、类别和用户兴趣表示为相互关联的实体（即Graph图结构）。例如：

产品：小米 15 Pro
芯片：高通骁龙8Gen2
品牌：小米
类别：智能手机
用户兴趣：高端手机、强大的摄影、适合游戏

小米15 Pro 可以与“小米”品牌、“智能手机”类别、“高端手机”、“摄影”、“游戏”兴趣相关联，后续将会看到，这种结构化表示可以更好的用于相关产品的推荐。

【传统RAG】

在传统 RAG 中，可能会将以上数据存储为一个文本块：

那么当用户搜索“高性能摄像头手机”时，系统会根据关键词的语义相似性来匹配到这个文本块。

这里GraphRAG的优势在于，它可以很轻松在Graph图中遍历找到“还有哪些采用莱卡摄影的手机”，而在传统RAG中，如果没有明显的文本块匹配这里的问题，就需要依赖程序对此进行查询分解与规划。

知识检索

虽然在传统RAG与GraphRAG中，你也可以根据需要定义自己的检索机制与算法，但无论如何，你很难突破底层知识表示的界限。在一个产品推荐系统中，考虑这样一个查询问题的检索（推荐产品）：

“有哪些适合拍摄高质量视频的智能手机，并且具有良好的用户口碑？”

**在 GraphRAG 中，**这样的查询可以从“智能手机”节点开始，查找到多个关联的手机产品节点，并检索这些手机产品关联的”特性“节点，查找与“高质量视频”特性节点发生联系的手机；用相同的方式查找与“优秀”用户口碑节点发生联系的手机，进而通过多维度关联筛选可以找到与用户需求高度匹配的产品。用一个模拟的Cypher语句来表示这个查找：

**在传统 RAG 中，**系统会试图通过如“智能手机”、“高质量视频”、“良好口碑”等关键词检索近似文本块；如果存储的文本块中没有同时提到这些关键词的近似信息，系统可能会返回一些仅仅与部分关键词相关的内容，但这些推荐可能并不完全符合用户的需求。比如可能会推荐一款具备良好视频拍摄功能、但口碑一般的产品。

这里可以看出，GraphRAG可以有效地连接和聚合多个相关特性，即使它们在不同的节点中表达，也能通过图谱中的关系找到最佳检索结果。因此，它能更精确地满足复杂、多维的用户查询。而传统 RAG 主要依赖于文本块的相似匹配，如果查询问题与存储文本不完全匹配或不在同一个文本块中，就可能无法返回最相关的结果，导致生成结果不够精准。这种差异使得 GraphRAG 在应对复杂查询、跨越多个特性进行检索时，具有显著优势。

综合性查询

传统RAG的一大痛点是它虽然能够较好的回答一些事实性问题，但是在面对一些统计性、总结性、概要性的QFS问题（Query-Focused Summarization）时却无能为力，或需要采用更复杂的技术手段来解决。

【GraphRAG】

知识图谱的结构化特征有助于回答关于数据本身的一些“元”问题，比如“2023年市场上一共新推出了几款骁龙8Gen2芯片的手机？”。

而Microsoft GraphRAG这样针对非结构化文本构建GraphRAG的框架，设计的一个主要出发点也是能够更好的回答基于高层语义理解的总结性查询问题。其借助社区检测算法来识别知识图谱中的多个社区，并利用LLM对这些社区进行总结与摘要。因此，当回答类似这样的问题：

“最近几年高端智能手机的整体发展趋势是怎样的？”

Microsoft GraphRAG会通过Map-Reduce算法首先从多个不同的关联社区（比如不同年份社区）来搜集到“高端智能手机”的信息（Map），最后汇总生成全局性答案（Reduce）。

【传统RAG】

传统 RAG 可能会检索到包含“高端智能手机”、“发展”或“最近几年”等关键词的文本块，但难以将这些块串联起来，形成一个连贯的趋势叙事。会导致结果往往是片段化的信息，难以全面地回答查询。

传统的RAG应对这样总结性问题的常用方法是：使用较复杂的RAPTOR范式（索引树状RAG）、或者类似LlamaIndex中的tree_summarize的答案生成模式。

隐藏关系理解

**GraphRAG其更容易通过图谱中的隐形关系来理解上下文；而传统RAG则更依赖在明确的文本块中显性的匹配关联，在理解隐性关系时存在局限。**这种对隐性关系的理解有助于提供更有见地的见解。

【GraphRAG】

在 GraphRAG 中，“iPhone 15 Pro” 和 “小米 15 Pro” 可能被理解为是相关的，即使在任何文本块中没有直接将它们进行比较。因为它们都属于“高端智能手机”类别，并且在”手机摄影”特性上表现突出。GraphRAG 可以理解这些产品的共同特性，将它们自然地联系起来。

因此当用户查询“适合拍摄的高端智能手机”时，GraphRAG 可以基于这些隐性关联提供更全面的推荐。

【传统RAG】

而在传统 RAG 中，系统只能根据文本块中明确提到的内容进行理解。如果某个文本块没有同时提到 “iPhone 15 Pro” 和“小米 15 Pro”，传统 RAG 可能无法将这两个产品联系起来。

可扩展性

随着知识库的扩展，GraphRAG在存储效率与检索能力等方面具备更好的扩展性。

【GraphRAG】

随着数据的增长，GraphRAG 可以通过新增节点和关系自然的加入已有的知识图谱，不需要重组已有的数据，同时其结构化、层次化的特点能够保持检索的高效性。因为它能借助高效的图遍历算法与层次化的导航，来快速的缩小检索的范围。

比如：一个查询可以从广泛的“手机”类别开始，然后逐步缩小到“高端智能手机”，最后深入到“适合摄影”。这种层次结构使得即使在数据增长的情况下，也能通过高效导航快速定位相关信息（在Microsoft GraphRAG还可以借助社区定位来缩小检索范围）。

【传统RAG】

传统 RAG 主要依赖于文本块存储数据。这些文本块通常是非结构化或半结构化的，随着知识的扩展，增加的新数据可能需要重新组织现有的文本块，甚至重复存储相似内容的多个版本，导致存储效率低下，并难以有效管理。同时数据规模的扩大也会显著影响系统的检索性能，且在面对复杂或语义含糊的查询时，容易受到更多噪音数据的干扰。

比如：

当需要匹配包含“高端智能手机”和“摄影”关键词语义的文本块，如果数据库中包含大量类似但不相关的内容，系统可能会返回一大堆冗余结果。为了过滤掉不相关的块，还可能需要引入重排序算法，这会增加系统复杂性并降低效率。

性能与成本

尽管GraphRAG有着更好的数据扩展性，但GraphRAG由于在索引创建（需要提取与识别实体与关系、生成必要描述信息、识别社区、生成摘要等）和查询处理中（需要检索更多关联的节点、关系与社区信息等）引入了额外的复杂性和计算开销，这对于简单的查询任务，特别是GraphRAG与传统RAG都能较好应对的问题来说可能是不合理的。

下面是微软论文中的一个查询示例，比较了GraphRAG与传统RAG之间的性能与LLM调用次数的差异：

尽管GraphRAG生成的结果更加全面，但 GraphRAG 使用了几乎10 倍的时间和10 倍的 token （LLM调用）才能完成。因此，在使用GraphRAG时需要充分考虑这里的性能与成本问题！

GraphRAG与传统RAG的组合使用

整体来说，GraphRAG 在处理复杂、互联的数据集以及需要深度关系理解的查询时，表现出色。它能够显著提升信息检索的精度和深度，特别是在需要多层次分析和推理的情况下。然而，这种能力的提升也伴随着更高的系统复杂性和资源消耗。因此，在决定是否采用 GraphRAG 之前，必须仔细分析具体的应用场景、数据结构以及典型的查询模式。

在以下情况下，传统 RAG 仍然是更理想的选择：

简单、事实性查询：对于类似“iPhone 13 是在何时发布的？”这样的简单查询，传统 RAG 能够更快速、直接地提供答案
实施难度较低：对于较小的数据集或简单的应用场景，传统 RAG 的设置和维护通常更加容易，适合快速部署和使用

在实际应用中，单一的检索方法往往难以适应所有需求。**为实现最佳性能和准确性，可以考虑设计一个智能路由系统，根据查询的类型和可用数据的特性，动态选择最适合的检索方法。**这种灵活的策略可以包括传统RAG、Advanced RAG、GraphRAG、文本到 SQL的检索，或其他优化的搜索方法，确保每个查询都能使用最合适的工具进行处理。这里的关键在于构建一个强大的路由系统（通常需要借助LLM实现），能够智能地将查询引导至最优的检索路径。