GraphRAG 详解

一、引言

ChatGPT 这类大语言模型火出圈之后，企业级 LLM 的应用也跟着热了起来。留心观察的话，你会发现这些应用里，相当大一部分都用了 RAG 技术。

关于 RAG 的基础知识，之前那篇《高级 RAG 技术——图解概览》已经讲得很清楚了。今天想聊的是，传统 RAG 在某些场景下，就算用了进阶方法，也还是有几个不太好跨过去的坎。

效率是一个绕不开的坎。向量搜索依赖聚类、树形结构或者 HNSW 这类近似最近邻算法——这些算法在处理超高维度数据，或者特别复杂的信息结构时，表现往往不尽如人意。而且像 HNSW 这种索引，构建和维护起来，计算资源的消耗也相当可观。

可解释性是另一个麻烦。文本被转化成向量后，本质上就是一串数字数组。你盯着这堆数字，根本看不出它代表什么含义。在检索阶段，系统只关心片段匹配，至于这些片段组合起来到底表达了什么，向量本身是说不清楚的。

整体理解受限也是个老问题。RAG 检索到的内容块虽然来自文档库，但相关的上下文并不一定会被完整地带到答案里。结果就是，系统对问题、答案和原始文档之间，始终缺乏一个全局的把握。

数值与文本混在一起时，向量搜索的准确度会明显下降。向量数据库里，文本经过 Embedding 转化成向量，而数值型数据要么直接使用，要么标准化后使用——两者特征完全不同，系统在中间很容易混淆。我自己做这类应用时，碰到表格和文本混杂的规范文档，向量搜索的准确度就经常让人头疼。

最后是工程挑战。RAG 系统涉及检索、排序、生成等多个环节。保证数据在各组件之间无缝传输、接口统一，再把它们高效地集成和优化——这本身就是一个不小的工程难题。

二、Graph RAG

1. Knowledge Graph

Graph RAG 里的 Graph，指的就是知识图谱——一种用来表示实体及其相互关系的结构化图形数据模型。

节点代表实体，比如人、地点、事件；边则代表这些实体之间的关系，比如人物关系、地理位置。举个直观的例子，《天龙八部》里的人物关系图谱，或者《蒙娜丽莎》的知识图谱，再比如深圳地铁 2024 年的运行图——这些都是知识图谱的典型应用。

在 Graph RAG 中，实体和关系以图的形式存储在图数据库里，作为 RAG 流程的一部分发挥作用。

2. 知识的两种表示方法：Vectors & Graphs

从人、向量和知识图谱三个不同的视角来看一个“苹果”——

人对“苹果”的理解远比字面意思丰富。大脑会为它赋予想象：果香、脆甜、甚至可以联想到牛顿的故事。这是人类感知、记忆和概念共同作用的结果。

向量对“苹果”的表达则是一组数字，通过编码部分地捕捉了文本的语义。在 RAG 过程中，这组数字通过计算与其他向量比较相似度。但问题在于，人几乎不可能从这组数字里解读出任何含义，更别提用它来理解上下文或融合到更长的文本里了。

知识图谱对“苹果”的表达则是“声明式”的。用 AI 的术语来说，它是“符号化”的。对人类而言，知识图谱直观易懂——标签和关系都用自然语言写就，看一眼就明白。对机器而言，符号化表示标准化、形式化，解析起来不费力气，还能进行逻辑和算法推理。就拿上面《天龙八部》的人物图来说，机器很容易就能推出来：段正淳是乔帮主的岳父（手动狗头）。

3. Graph RAG 运行模式

GraphRAG 本质上还是 RAG，只不过与传统 RAG 相比，它的检索路径上多了一个知识图谱。基本架构没变，区别在于数据库里同时存储了结构化的知识图谱数据和文本 Embedding 后的向量数据。

实际应用中，可以把图数据和向量分别存在两个不同的数据库里，也可以直接用 Neo4j 这种支持向量搜索的图数据库。典型的运行模型大致分三步：

1. 通过向量或关键词搜索，找到初始节点集。这一步需要预先对知识图谱里的节点数据进行向量化。
2. 遍历图结构，获取相关节点的信息。这一步通常基于图的结构进行，不需要额外的向量化处理。
3. 使用基于图的排序算法（比如 PageRank）对文档重新排序。这类算法利用图结构信息来评估节点的重要性或相关性，不依赖向量表示，而是基于图的连接结构和关系信息。

当然，不同应用场景下，GraphRAG 的运行模式也会随之变化。

三、GraphRAG Lifecycle

使用 GraphRAG 的生成式 AI 应用，运行模式与常规 RAG 基本一致，只是在开始时多了一个“Create Graph”的步骤。

这个“创建图”的过程，类似于传统 RAG 把文档分块、向量化后加载到向量数据库中。图结构在工程上有几个好处：

1. 图的迭代性很强，可以从一个“最小可用图”开始，逐步扩展。
2. 数据纳入知识图谱后，进化变得容易很多。往图谱里添加更多类型的数据，既能充分利用数据网络效应带来的好处，又能通过提升数据质量来增强应用价值。
3. 图创建相关的技术栈发展很快，随着工具的完善，创建图这件事会变得越来越容易。

四、Create Graph

既然提到了创建图，就有必要详细展开一下 GraphRAG 中这个环节。构建知识图谱的第一步，是理解与 GenAI 最相关的两种图：域图和词汇图。

1. Domain graph-域图

域图是一个用于表示某个特定领域知识与关系的知识图谱。它聚焦于某个主题或领域，是该领域内世界模型的具体表现形式。比如和小龙女相关的一个简单域图，就能很好地说明这一点。

创建域图有几种不同的路径，取决于引入的数据来源——是结构化数据、非结构化文本，还是两者兼有。非结构化数据源构建知识图的工具正在快速演进，像新的 Neo4j 知识图构建器，就能处理 PDF、网页、YouTube 视频片段或者维基百科文章，并且自动从中创建知识图谱。如果客户、产品、地理信息相关的数据存储在关系型数据库里，则可以直接使用成熟的“关系到图谱”映射方法来创建域图。

2. Lexical Graph-词汇图

词汇图则是一个用来表示文档结构的图，主要描述文本内容的组织方式。它聚焦于文本的分段——比如段落、句子或者其他文本片段——以及它们之间的相互关系。

词汇图通过图的形式来展示文档的内部结构，每个节点代表一个文本片段，每条边代表片段之间的关系。一个简单的词汇图示例如下。

域图和词汇图可以按照一定的方式结合起来使用。创建词汇图相对简单，主要涉及基本的解析与分块策略。

五、GraphRAG 的优势

相比传统 RAG，GraphRAG 有几个明显的优势。

1. 准确性与可用性

最直观的感受是，GraphRAG 能获得更高质量的回复。微软的论文《From Local to Global: A Graph RAG Approach to Query-Focused Summarization》里，研究人员发现 GraphRAG 能显著提高 RAG 环节中“检索”的性能——检索到的上下文相关度更高，最终产生的回答也更准确，更贴近原始索引。

更关键的是，GraphRAG 在提供答案时，需要的 Token 数量比替代方法少了 26% 到 97%。也就是说，它不仅准确度高，成本也更低。

LinkedIn 最近发表的论文提供了一个很好的案例。他们把 GraphRAG 用在了客服应用上，结果发现，GraphRAG 不仅提高了回答的正确性，答案也变得更丰富。客服团队解决单个问题的时间中位数，直接减少了 28.6%。

2. 提升数据价值，加快产品迭代速度

知识图谱在概念和视觉上都足够直观，所以从知识图谱的角度去理解数据，往往会带来新的洞察。图谱能生动地呈现出应用底层的数据情况。

另外，图谱提供了能追溯到原始答案的“钩子”。你可以沿着这些钩子组成的因果链，一路追踪到数据源头。对 LLMs 应用来说，图谱中独立的数据块能保留其价值，同时数据本身的结构也能存储并传递额外意义——这些都可以用来为应用程序增加更多智能。

LlamaIndex 最近展示的一个图就很典型，它通过“MENTIONS”把词汇图和域图关联了起来。

3. 可解释性及安全性

大语言模型缺乏可解释性，这让基于 LLMs 的应用很难在决策层面赢得信任。但知识图谱完全不同。图谱的数据是可以导航的，可以查询，也能随时修正和更新。在决策层面，用图结构的数据比用向量结构的数据，明显更容易理解和信赖。

数据质量方面也是如此。把数据放进知识图谱里，更容易发现错误并进行溯源——不仅能在计算中使用，还能在解释中加以利用。这一点在向量表示中是根本做不到的。

从安全性角度看，GraphRAG 可以通过图结构自然地表示和管理复杂的关系——包括用户、角色、权限、资源之间的多对多关系。通过图的节点和边的属性与标签，可以实现更细粒度的权限管理和动态调整。特别是，GraphRAG 支持基于上下文的动态权限管理，可以根据时间、地点、用户状态等上下文信息，实时调整访问权限。

下图是一个简单的安全策略示意，可以在具备细粒度访问控制的知识图谱中实现：

在数据隐私方面，Graph RAG 可以通过分析图结构中应用的访问模式和路径，检测异常行为并及时响应。

六、可能适合 Graph RAG 的场景

GraphRAG 不是万能的。传统 RAG 效果好的时候，贸然换成 GraphRAG 并不明智。只有在某些特定场景下，当你有事实证据证明传统 RAG 确有局限时，才值得考虑尝试 GraphRAG：

1. 受限于向量搜索的能力：
   检索阶段获取的信息，与用户查询意图之间存在较大偏差时。

2. 改进 RAG 方法后仍然效果不佳：
   已经用了包含 BM25 精确搜索的混合搜索方法，优化了排序流程，甚至对嵌入向量进行了微调，结果还是不尽如人意的时候。

3. 复杂关系数据或跨领域知识集成：
   数据库里包含大量相互关联的实体，需要整合不同领域的信息并建立联系。比如社交网络、组织结构这类数据，或者跨学科研究、综合情报分析等任务。

4. 有较高可解释性要求的场景：
   GraphRAG 提供的图结构，让结果的推理过程更加透明和可解释。

5. 多跳查询需求：
   需要多步推理或跨越多个关系的查询，比如寻找间接关系或因果链分析。

6. 细粒度访问控制：
   需要基于复杂关系实现精细的数据访问权限，比如大型组织的数据共享系统。

7. 动态数据环境：
   数据频繁更新，需要实时反映关系变化的时候，比如实时事件分析或动态系统监控等场景。

总的来说，以上是几个可以考虑使用 GraphRAG 的场景。实际落地的时候，还需要从数据、性能、工程实现复杂度等多个方面综合评估，最终决定是否要上 GraphRAG。

总结

传统 RAG 以向量搜索为核心，在某些场景下面临准确度不高、可解释性差、整体理解能力有限等问题。GraphRAG 在准确度、可解释性、安全性以及数据价值提升方面，都表现得更好。

GraphRAG 的数据表征以符号化的图结构为核心，把实体和实体间关系存储在图数据库中。对人类来说表达直观、可解释性强；对机器来说易于解析，并能进行逻辑和算法推理。

GraphRAG 本质上是对 RAG 的扩展，在传统 RAG 的基础上增加了创建和利用图结构的步骤。图谱创建通常包括两个层面：反映领域知识的域图和反映语言结构的词汇图。这种图结构让 GraphRAG 能够捕捉更复杂的关系和上下文。

传统 RAG 效果好的时候，没必要强行换成 GraphRAG。应该从适用场景出发，综合考虑工程实现和数据等多方面因素，再判断是否值得使用。

尽管 GraphRAG 优势明显，但也面临挑战——图构建的复杂性、大规模图的性能问题、以及对专业知识的更高要求，都是需要在实际应用中权衡的因素。