GraphRAG 深度解析：知识图谱增强的检索生成

前言

#

在做 RAG 项目的过程中，我发现传统向量检索在处理跨文档关联问题时效果一直不太理想。比如用户问「这家公司这几年的战略方向有什么变化」，系统返回的往往是几段零散的文字片段，前后逻辑对不上。后来了解到 GraphRAG 这个方向，它在传统 RAG 基础上引入了知识图谱，能够理解实体之间的关系，对宏观性问题的回答质量有明显提升。这篇文章就来详细聊聊 GraphRAG 的核心机制和实际应用中的取舍。

传统 RAG 的瓶颈

#

传统 RAG 在过去两年确实有效缓解了大模型的幻觉问题，但随着应用场景越来越复杂，三个局限越来越明显。

只能检索「点」，看不到「线」

#

传统 RAG 只能找到零散的文本片段，无法理解实体间的关系。比如知识库里有张三的信息，也有李四的信息，但系统不知道张三是李四的直属上级，也不知道他们正在合作同一个项目。它能检索到「点」，但看不到「线」和「面」¹。

宏观问题回答质量差

#

当你问一些概括性、主题性的问题，比如「这篇年报的核心观点是什么」，传统 RAG 只能给你缺乏逻辑联系的零散段落。就像让一个只看过电影片段的人给你讲剧情大纲，他只能复述画面，讲不出主线。

无法处理多步推理

#

需要多步推理的查询，传统 RAG 基本束手无策。比如「张三负责的部门中，哪个部门的业绩增长最快」，这需要先找到张三，再找到他负责的部门，再比较各部门业绩。每一步都依赖上一步的结果，传统 RAG 没有这种推理链条。

GraphRAG 的核心：从文本检索到知识图谱查询

#

GraphRAG 将传统基于文本的检索，升级为基于知识图谱的查询模式。这个升级主要通过三个关键环节实现。

知识图谱构建

#

这是 GraphRAG 和传统 RAG 最大的区别，也是整个系统的基础。构建过程分三步。

第一步是实体抽取。 通过大模型自动识别文档中的各类实体：人物、机构、事件、地点等。相当于从文本中把「谁」和「什么」挑出来。

第二步是关系构建。 构建实体-关系-实体的三元组。比如：

(张三) --[汇报给]--> (李四)
(市场部) --[负责]--> (品牌推广)

这一步建立的是实体之间的连接线。

第三步是知识融合。 将不同来源的同一个实体进行合并。比如年报第一章提到「公司 CEO 张三」，第三章又提到「张总」，系统需要识别出这是同一个人。

每个节点和关系都带有语义描述，通过这些描述文本生成 Embedding，供后续检索阶段使用。最终形成完整的知识图谱，相当于给知识库建了一个「认知中枢」²。

社区划分

#

光有图谱还不够，还需要对整个图谱进一步划分为不同的社区（即子图）。这个过程也分三步。

1. 社区发现算法：识别哪些节点之间联系程度高，让它们聚在一起构成社区。就像在一个公司里，同一个部门的员工日常联系更紧密，自然形成一个小圈子。
2. 社区摘要生成：让大模型为每个社区生成内容摘要。比如某个社区的摘要可能是「某公司 2025 年 Q1 财报情况」，另一个社区可能是「产品线组织架构」。
3. 社区 Embedding：用摘要文本得到子图的向量表达。

到这里，整个图谱建设完成。你拥有的不再是一堆散乱的文本片段，而是一个有结构、有层次、有关系的知识网络 ³。

两种检索策略

#

GraphRAG 提供了两种检索策略，分别应对不同类型的问题。

局部检索（Local Search）

#

局部检索从用户问题中提取关键实体出发，收集直接相关的事实信息。流程如下：

1. 识别问题中的关键实体（比如「微软」）
2. 通过问题 Embedding 与节点 Embedding 的语义匹配，将实体与图谱节点链接
3. 以候选节点为锚点，沿关系边向外扩展（跳数越多，知识结构越复杂丰富）
4. 将遍历中收集的节点和关系边形成子图，作为上下文输入大模型

打个比方：局部检索就像从地图上的一个点出发，沿着道路不断向外探索，走过的路和路边的建筑都会被记录下来。

适用场景：简单事实查询（「微软总部在哪里」）和多跳复杂推理。

全局检索（Global Search）

#

全局检索基于已划分好的社区子图展开。流程是：

1. 将用户问题编码为向量
2. 与所有社区的 Embedding 做相似度匹配
3. 选出最相关的若干社区子图
4. 将子图摘要文本、关键实体列表、关系列表作为检索结果输入大模型

打个比方：全局检索就像先看整本书的目录，找到最相关的几个章节，然后把这几个章节的摘要给你看。

适用场景：宏观性、主题性问题（「这篇文章讨论了哪些话题」），或者没有明确实体指向的概括性问题 ⁴。

GraphRAG 的现实挑战

#

GraphRAG 很强，但也不是万能的。在实际项目中，它面临三个实实在在的挑战。

计算成本高

#

实体抽取和关系抽取都依赖大模型来做，需要大量计算资源和处理时间。传统 RAG 建个知识库可能几小时搞定，GraphRAG 可能要跑好几天。对于数据量大的场景，这个时间成本必须考虑进去。

知识质量存疑

#

完全依赖大模型来抽取实体和关系，一旦抽取结果有问题，错误就会被固化到图谱中。这比散落的幻觉更可怕，因为结构化的错误更容易被当真 ⁵。所以在一些对准确性要求极高的场景中，可能还需要人工审核或额外的质量校验机制。

知识更新困难

#

更新一个知识点不是改一个文档那么简单，而是需要重新跑知识抽取和融合流程，难以实现实时更新。对于需要频繁更新知识的场景，这个代价太大了。

实践建议：两者结合才是最优解

#

GraphRAG 和传统 RAG 各有适用场景，在实际项目中一般将两者结合使用：

• GraphRAG 适合推理深度和全局理解要求高的场景，比如金融研报分析、法律条文关联推理、企业知识管理等
• 传统 RAG 在简单检索和实时性要求高的场景中仍有优势，比如客服 FAQ、产品使用手册查询等

比较平衡的做法是先用传统 RAG 处理简单的检索查询，遇到需要复杂推理或全局理解的问题时再调用 GraphRAG。也可以把两者作为互补的检索通道，结果合并后再交给大模型生成。这种混合架构在工程实现上并不复杂，但在回答质量上会有明显提升。