告别传统 RAG 的“碎片化”盲区：Graph RAG 如何用知识图谱重塑大模型检索生成

Posted on 2026-05-21 In AI 技术

在当今的 AI 应用领域，检索增强生成（RAG, Retrieval-Augmented Generation） 已经成为企业落地大语言模型（LLM）的标配架构。然而，随着业务场景的日益复杂，许多开发者发现，传统的基于向量数据库的 RAG（Vector RAG）似乎遇到了瓶颈。

当你询问“某某公司的核心高管在过去三年主导了哪些关键并购？”时，传统 RAG 往往会表现得像是个“失忆症患者”——它可能检索到了某一次并购的新闻稿，也找到了该高管的简历，但它无法将这两条孤立的信息建立关联，更难以跨越多个文档进行复杂的逻辑推理。

这就是传统 RAG 的“碎片化”盲区。为了解决这一痛点，技术社区将目光投向了一个古老而又充满活力的技术：知识图谱。由此，Graph RAG（基于知识图谱的检索增强生成） 应运而生。

本文将带你深入浅出地剖析 Graph RAG 的核心原理、架构设计，并通过实际的代码示例，手把手教你如何构建一个属于自己的 Graph RAG 系统。

一、传统 RAG 的痛点在哪里？

在引入 Graph RAG 之前，我们需要搞清楚：为什么向量化检索不够用了？

传统 RAG 的核心 workflow 是：文档分块 -> 文本向量化 -> 向量相似度检索 -> 拼接 Prompt -> LLM 生成。

这种模式在处理“事实性问答”（如“什么是牛顿第一定律？”）时表现优异，但在以下场景中却显得力不从心：

缺乏全局视野：文本被切分成小块，丢失了文档整体的结构和上下文关联。
多跳推理困难：当问题的答案分布在多个不同的文档、段落中，且需要通过隐含的逻辑链条串联时（如 A 导致了 B，B 影响了 C），单纯依靠余弦相似度很难精准检索到所有相关的 Chunk。
语义相似但逻辑无关的干扰：向量检索本质上是“字面意思”的相似度匹配。如果两句话使用了相似的专业术语，但表达的意思完全相反或属于不同的实体，传统 RAG 极易产生“张冠李戴”的幻觉。

简而言之，传统 RAG 擅长检索“事实”，但不擅长理解“关系”。

二、什么是 Graph RAG？

Graph RAG 是一种将知识图谱与大语言模型深度结合的架构。

如果说传统 RAG 是给大模型提供了一堆散落的“百科全书卡片”，那么 Graph RAG 就是直接给大模型提供了一张高度结构化的**“思维导图”或“关系网”**。

在 Graph RAG 中，信息不再是以孤立的文本块存在，而是被解析为：

实体：如人名、地名、组织、概念等（图的节点）。
关系：实体之间的连接，如“属于”、“任职于”、“收购了”等（图的边）。
属性：实体和关系的附加描述。

通过这种网状结构，Graph RAG 可以沿着关系边进行图遍历，轻松实现跨越多文档的多跳推理。

三、 Graph RAG 核心工作流详解

构建一个完整的 Graph RAG 系统，通常包含以下四个核心阶段：

1. 知识抽取

这是构建图谱的第一步。利用 LLM 对非结构化文本进行处理，提取出实体和关系。

Prompt 示例：“请从以下文本中提取所有重要的实体及其关系，并以 JSON 格式输出，格式为 [{"entity1": "...", "relationship": "...", "entity2": "..."}]。”

2. 图谱构建

将抽取出的三元组存入图数据库（如 Neo4j、NebulaGraph，甚至 NetworkX 等本地图结构）。
在这个阶段，系统还需要进行实体消歧和实体对齐（例如识别出文本中的“马斯克”和“Elon Musk”是同一个节点，并进行合并）。

3. 混合检索

这是 Graph RAG 的魔法所在。当用户提出查询时，系统通常会执行双重检索：

向量检索：寻找语义相似度高的文本块或实体节点。
图检索：以检索到的实体为起点，沿着关系边进行游走，获取关联节点和子图。

4. 上下文增强与生成

将检索到的图结构数据（如“实体-关系-实体”的三元组列表、或者子图的文本化描述）与用户的原始问题拼接，输入给 LLM，生成最终答案。

四、动手实践：用 LlamaIndex + Neo4j 构建 Graph RAG

纸上得来终觉浅，让我们通过一段实际的代码来构建一个最小可行的 Graph RAG pipeline。

环境准备：

Python 3.9+
启动一个 Neo4j 图数据库实例（可以使用 Neo4j Desktop 或 Docker）
安装必要的库：pip install llama-index llama-index-graph-stores llama-index-llms-openai neo4j

1. 初始化环境与大模型

import os
import openai
from llama_index.core import Settings
from llama_index.llms.openai import OpenAI
from llama_index.embeddings.openai import OpenAIEmbedding
from llama_index.graph_stores.neo4j import Neo4jPGStore

# 配置 OpenAI API Key (确保你有网络环境或使用Azure/OpenAI代理)
os.environ["OPENAI_API_KEY"] = "YOUR_OPENAI_API_KEY"

# 初始化 LLM 和 Embedding 模型
Settings.llm = OpenAI(temperature=0, model="gpt-4o")
Settings.embed_model = OpenAIEmbedding(model="text-embedding-3-small")

# 连接到 Neo4j 图数据库
# 假设你的 Neo4j 运行在本地 bolt://localhost:7687，用户名 neo4j，密码 your_password
graph_store = Neo4jPGStore(
    username="neo4j",
    password="your_password",
    url="bolt://localhost:7687",
)

2. 文档解析与图谱构建

LlamaIndex 提供了非常强大的 PropertyGraphIndex，它可以自动化地完成从文档读取、实体关系抽取到图谱写入的全过程。

from llama_index.core import Document
from llama_index.core.indices.property_graph import PropertyGraphIndex
from llama_index.core.node_parser import SentenceSplitter

# 1. 准备非结构化文本数据
texts = [
    "苹果公司由史蒂夫·乔布斯、斯蒂夫·沃兹尼亚克和罗纳德·韦恩创立于1976年。",
    "蒂姆·库克在2011年接替史蒂夫·乔布斯，成为苹果公司的现任CEO。",
    "苹果公司总部位于加利福尼亚州的库比蒂诺，该建筑被称为Apple Park。",
    "苹果公司开发了iOS操作系统，并在2007年发布了第一代iPhone。"
]

documents = [Document(text=t) for t in texts]

# 2. 文本分块
splitter = SentenceSplitter(chunk_size=256, chunk_overlap=0)
nodes = splitter.get_nodes_from_documents(documents)

# 3. 构建知识图谱索引
# 注意：这一步会调用 LLM 抽取节点和关系，并自动存入 Neo4j 数据库
index = PropertyGraphIndex(
    nodes=nodes,
    property_graph_store=graph_store,
    llm=Settings.llm,
    embed_model=Settings.embed_model,
    show_progress=True,
)

print("知识图谱构建完成！")

代码解析： 执行上述代码后，LlamaIndex 内部的 LLM 会被提示去提取文本中的 Entity（如苹果公司, 蒂姆·库克）以及 Relation（如 CEO_OF, LOCATED_IN），并将其作为节点和边自动插入到 Neo4j 中。

3. 执行混合检索查询

当图谱构建完成后，我们可以通过自然语言进行查询。Graph RAG 的查询引擎会自动将问题转化为图查询（或结合向量检索找到起点），然后获取关联子图。

# 将索引转换为查询引擎
# 默认使用混合检索策略（向量+图遍历）
query_engine = index.as_query_engine(include_text=True)

# 测试一个需要跨文档理解的多跳问题
question = "苹果公司的现任CEO是谁？公司总部在哪里？"
response = query_engine.query(question)

print("-" * 50)
print(f"问题: {question}")
print(f"回答: {response.response}")
print("-" * 50)

# 我们还可以查看检索到了哪些图关系
print("检索到的图谱路径:")
for source_node in response.metadata.values():
    print(source_node)

预期输出分析：
当询问“现任CEO和总部”时，系统通过“苹果公司”这个核心实体节点，向外沿着 CEO_OF 关系找到了“蒂姆·库克”，沿着 LOCATED_IN 关系找到了“库比蒂诺”。LLM 接收到这些结构化的三元组后，能够生成极其精准、无幻觉的回答。

五、进阶探讨：Graph RAG 的前沿优化策略

虽然基础的 Graph RAG 已经很强大，但在企业级生产环境中，还需要进行一系列的优化：

1. 微软的 GraphRAG 全局摘要

微软在 2024 年开源的 microsoft/graphrag 库引起了巨大轰动。其核心创新在于解决了**“全局性查询”的问题。
传统图检索依然依赖实体的匹配。如果用户问：“总结一下财报中提到的所有宏观风险”。微软的解法是：利用图聚类算法（如 Leiden 算法）对图谱进行社区划分**，然后让 LLM 为每一个社区生成摘要。在回答全局性问题时，直接检索相关的社区摘要，从而提供极具深度的全局视角。

2. 图谱 Embedding (Graph Embedding)

除了对文本进行向量化，我们还可以对图结构本身进行向量化（如 Node2Vec、TransE）。这样在检索时，不仅可以匹配“字面相似度”，还能匹配“拓扑结构相似度”，进一步提升召回率。

3. 结合 Agent 的自主图遍历

将 Graph RAG 作为工具交给 AI Agent。LLM 可以根据图谱的 Schema（如 Schema(TypeA)-[REL]->(TypeB)），动态生成图查询语言（如 Cypher 语句），实现完全自主的、多步骤的图深度游走。

六、总结：我们应该使用 Graph RAG 吗？

技术没有银弹，Graph RAG 也不例外。

Graph RAG 的优势在于对复杂关系的精确建模、支持多跳推理、以及提供全局视角的总结。它非常适合应用于智能客服、法律合同审查、医疗病历分析、金融风控网络等重逻辑、多实体关联的场景。

但它的代价也同样明显：

构建成本高昂：知识抽取需要大量调用 LLM API，特别是在处理海量企业文档时，构建图谱的时间和资金成本远高于传统向量库。
数据质量敏感：如果 LLM 抽取了错误的实体或关系，会导致图谱出现“脏数据”，直接污染后续的生成结果（Garbage in, Garbage out）。

最佳实践建议：
不要盲目追风。如果你的应用场景只是简单的 FAQ 问答、或是单文档内的信息提取，传统 Vector RAG 依然是最高效、最经济的选择。但如果你发现业务逻辑被大量的“实体关系”所主导，传统 RAG 总是“胡言乱语”，那么是时候拥抱 Graph RAG，为你的大模型装上“逻辑关系”的引擎了。

未来，向量检索与图检索的混合融合必将成为 RAG 架构的主流。掌握了 Graph RAG，你就掌握了构建下一代高质量 AI 应用的关键钥匙。

一、 传统 RAG 的痛点在哪里？

二、 什么是 Graph RAG？