GraphRAG与传统RAG怎么选？二者的融合方案是什么

最近工作比较忙，一直在重构公司现有的RAG推荐系统。在给GraphRAG提交了几个PR并成功合并后，暂时没有继续对GraphRAG做出更多贡献。然而，最近同事和粉丝纷纷私信我，他们最常问的问题有："什么时候应该使用GraphRAG？"，"在哪些场景下应该使用传统的RAG"以及"我们目前在公司使用的是传统RAG，那要如何与GraphRAG相结合呢？"。为了系统地解答这些问题，我决定写一篇文章，对这些问题进行详细的探讨。我将先从多个方面解释GraphRAG和传统RAG的区别，然后给出二者如何结合的简单思路。

我们最近建了交流群，感兴趣的朋友可以入群交流哈，二维码放在文末了，如果过期可以加我v: longyunfeigu

GraphRAG

在GraphRAG框架下，我们能够将产品、品牌、类别以及用户兴趣视作相互联系的实体，也即图形的节点。例如：

• 产品：华为P50 Pro

• 摄像头：莱卡四摄

• 品牌：华为

• 类别：智能手机

• 用户兴趣：高清摄影、适合游戏、旗舰机型

华为P50 Pro 可被关联至“华为”这一品牌、“智能手机”这一类别，“高清摄影”、“游戏”以及“旗舰机型”这些用户兴趣点上，这种图形化的表示方式对于推荐相关产品十分有用。

传统RAG

传统的RAG可能会选择将以上数据以一个文本块的形式进行存储：

HUAWEI P50 Pro是一款具备徕卡四射的华为旗舰机，搭载有XD Fusion Pro原色引擎、XD Optics计算光学技术、XD Fusion Pro超级滤光系统等华为影像技术，可以提升手机在拍摄时的成像质量。主摄采用了5000万像素原色镜头，可以记录拍摄场景的肉眼色彩观感。

因此，当用户搜寻“优秀摄影效果的手机”时，系统会基于语义匹配来找出这个文本块。

然而，GraphRAG的优势就体现在，它可以轻松地在图形结构中寻找“其他使用莱卡摄像头的手机”。相较之下，传统的RAG如果没有明确符合这一需求的文本块，就需要依赖编程来进行查询分解与处理计划。

拿产品推荐系统举例，考虑一个用户的查询：“有哪些适合长时间佩戴并且具有降噪功能的耳机？”

• 在GraphRAG系统中，这个查询可以从“耳机”节点出发，探索多个与耳机相关的产品节点。系统会首先检索这些产品的“特性”节点，寻找那些与“长时间佩戴舒适性”相关的耳机；然后，系统会进一步检索与“降噪功能”相关的特性节点，找到符合条件的耳机产品。通过这种多维度的关联筛选，GraphRAG能够为用户推荐既舒适又具备降噪功能的耳机，精确满足用户的需求。

• 在**传统的 RAG **系统中，系统会尝试通过关键词如“智能手机”、“高质量视频”、“良好口碑”等来搜索对应的文本块。然而，如果存储的文本块中没有同时包含这些关键词的相关信息，系统可能会返回一些只与部分关键词匹配的内容，这样的推荐可能并不能完全满足用户的需求。比如，系统可能会推荐一款虽然具备高质量视频功能，但在用户评价方面表现平平的智能手机。

所以我们可以得出结论：GraphRAG 在应对复杂查询、跨越多个特性进行检索时，具有显著优势。

随着数据量的不断增加，GraphRAG 能够通过自然地新增节点与关系，将新信息无缝集成到现有的知识图谱中，无需对已有数据进行大规模重组。其结构化和层次化的特性使得数据检索更加高效。GraphRAG 利用先进的图遍历算法和层次化导航技术，能够迅速缩小检索范围，提升查询速度。

例如，一个用户可能会从广泛的“电子产品”开始查询，然后逐步缩小范围到“智能手机”，再进一步到“适合游戏的高性能智能手机”。这种层次化的检索方式，即便在面对庞大的数据集，也能通过有效的导航快速定位到相关信息。此外，GraphRAG 还可以利用社区反馈和用户行为数据进一步优化检索路径，提高命中率。但是GraphRAG对于新增的数据会重新进行社区检测，这一步还是比较耗费资源的。

相比之下，传统的 RAG 系统主要依赖于文本块来存储数据，这些数据块往往是非结构化或半结构化的。随着知识库的扩展，新增的数据可能需要重新组织现有的文本块，甚至可能导致相似内容的多版本重复存储，存储效率较低且管理困难。数据规模的增加还显著影响系统的检索性能，面对复杂或模糊的查询时，容易受到噪音数据的干扰。

例如，当用户查询“高性能智能手机”和“游戏”相关的内容时，如果数据库中存在大量类似但不相关的文本块，系统可能会返回大量冗余结果。要过滤这些不相关的内容，传统的 RAG 系统可能需要引入复杂的重排序算法，这不仅增加了系统的复杂性，也显著降低了检索效率。

GraphRAG

知识图谱的结构化特征使其在处理数据本身的“元”问题时表现出色，例如“2023年市场上新发布了多少款搭载骁龙8Gen2芯片的手机？”。

Microsoft GraphRAG 针对非结构化文本构建了一个专门的框架，其设计的核心目标之一是能够更好地回答基于高层语义理解的总结性问题。通过社区检测算法，GraphRAG 可以识别并划分知识图谱中的多个社区，然后利用大规模语言模型（LLM）对这些社区进行总结和概括。Microsoft GraphRAG 会先通过Map-Reduce算法从多个关联社区（例如不同年份的社区）中搜集有关“高端智能手机”的信息（Map），然后汇总这些信息以生成全面的答案（Reduce）。

"元信息"（Metadata）是关于数据的数据。在计算机科学中，元信息用于描述其他数据的属性，包括创建日期、作者、位置和文件大小等。这样的信息对数据的管理和处理非常有用。

"元信息问题"则是指那些需要查询或处理元信息的问题。例如，“这张照片是谁拍的？”、“这份报告是何时编写的？”等。在知识图谱中，元信息可能包括实体的类型、属性、以及它们之间的关系等，因此，“元信息问题”可能涉及到的是如何从知识图谱中抽取或推导出有关这些元信息的问题。

传统RAG

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

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

GraphRAG

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

传统RAG

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

选择使用传统RAG还是GraphRAG主要取决于数据特征和查询需求，这两者构成了其适用性上的关键区别。一般来说，以下特征的数据更适合使用GraphRAG：

数据中包含大量相互关联的实体和复杂的关系，并且结构较为清晰。例如：

• 社交网络中的用户关系：如朋友、家庭成员、同事之间的联系。
• 企业内部的复杂关系：包括部门架构、供应链网络、客户关系等。
• 医疗数据：涵盖疾病、症状、治疗方法、药品以及病例等复杂关联。
• 法律数据：涉及法律条文、判例之间的引用关系、解释与适用情况等。
• 产品推荐系统：涉及到产品、用户、浏览内容、不同产品之间的关联、用户之间的关系等。

除了数据特征外，查询需求也是选择算法的重要考量。GraphRAG更擅长处理涉及复杂关系、语义推理和多步逻辑关联的查询，或者关于知识本身元数据的问题。。例如：

• 多跳关系查询：如“某人的同事的朋友中，谁在某公司工作？”
• 语义关联查询：如“哪些公司提供某类产品并已获得官方认证？”
• 知识推理查询：如“根据患者的症状和病史，推断可能的疾病并建议治疗方案。”
• 时序关联查询：如“查询某公司过去十年的投资和并购情况？”

对于这些复杂查询，GraphRAG提供了更强的导航与综合分析能力。而传统RAG则更适合处理基于数据内容的具体事实性问题，对复杂关系的处理则较为有限。

虽然GraphRAG在数据扩展性方面表现出色，但在实际应用中，其在索引创建和查询处理过程中引入的复杂性和计算开销不容忽视。特别是在索引阶段，GraphRAG需要进行实体和关系的提取与识别，生成必要的描述信息，识别社区并生成摘要；而在查询处理阶段，则需检索更多关联的节点、关系和社区信息。这些额外的步骤对简单查询任务来说，尤其是那些传统RAG也能有效处理的问题，可能显得不太经济。

尽管GraphRAG生成的结果更为详尽，但其所需的时间和token数量（LLM调用）几乎是传统RAG的十倍。因此，使用GraphRAG时，务必权衡其性能与成本，确保在合适的场景下发挥其优势。

总的来看，GraphRAG在处理复杂且高度相互联系的数据集和需要深度关联理解的查询上，显示出了强大的效能。它可以显著提升信息查找的准确性和深入程度，尤其是在需要进行多级分析和推导的情况下。然而，这种性能提升也带来了系统复杂度和资源使用量的增加。因此，在决定是否采用 GraphRAG 之前，必须仔细分析具体的应用场景、数据结构以及典型的查询模式。

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

• 简单且基于事实的查询：例如，对于“iPhone 13 的发布日期是什么？”这样的简单问题，传统 RAG 能够更迅速和明确地给出答案。

• 较低的实施难度：在数据集较小或应用场景不复杂时，传统RAG的配置与维护过程较为简单，便于快速实施和操作。

在实际使用场景中，往往一个单一的搜索策略难以覆盖所有需求。为了达到最优效果和准确率，我们可以考虑创建一个智能路由系统，这个系统会根据问题的类别和可获得数据的属性，动态地挑选出最适合的搜索策略。关键点在于搭建一套强大的路由系统（通常需要借助LLM来完成），这样就能够聪明地将查询指向最佳的搜索路径。