超越文本块：Graph RAG 如何用知识图谱重塑大模型的推理边界

Posted on 2026-05-20 In AI 技术

在当今的 AI 开发领域，检索增强生成（RAG，Retrieval-Augmented Generation） 已经成为解决大语言模型（LLM）幻觉、知识过时和领域知识缺失的“标配”架构。然而，随着应用场景的深化，传统的基于向量的 RAG（我们常说的 Naive RAG）正暴露出越来越明显的短板。

当你询问“在金庸武侠小说中，华山派有哪些弟子，他们之间是什么关系？”时，传统 RAG 只能机械地检索包含“华山派”或“弟子”的文本块。它缺乏全局视野，无法像人类一样在脑海中构建出一张错综复杂的人物关系网。

为了打破这一瓶颈，AI 界引入了一项革命性的技术组合：Graph RAG（图谱增强检索生成）。通过将知识图谱与 RAG 深度融合，我们赋予了大模型“举一反三”和“逻辑推理”的能力。

本文将带你深入浅出地剖析 Graph RAG 的核心原理、架构设计，并手把手教你使用 LangChain 和 Neo4j 搭建一个真实的 Graph RAG 应用。

一、传统 RAG 的“天花板”：为什么我们需要 Graph RAG？

在探讨 Graph RAG 之前，我们必须先弄清楚传统 RAG 到底出了什么问题。

传统 RAG 的核心逻辑是：文本分块 -> 向量化 -> 向量相似度检索 -> LLM 生成。这种机制在处理精确的事实查询（如“什么是相对论？”）时表现优异，但在面对以下场景时却显得捉襟见肘：

多跳推理失败：比如查询“A 公司收购的子公司的 CEO 是谁？”。向量检索可能能找到“A 公司的收购记录”和“某 CEO 的资料”，但如果这两段文本不在同一个向量空间附近，LLM 就无法将它们关联起来。
全局性查询失效：比如“总结这份财报中提及的所有风险因素及其关联”。传统 RAG 只能返回被切碎的局部文本块，无法提供宏观的全局视野。
语义多义性与实体消歧：“苹果”是水果还是公司？仅靠向量距离往往难以精准区分。

Graph RAG 的破局之道：从“字面相似”到“逻辑关联”。

Graph RAG 引入了知识图谱的实体和关系。它不再把文档看作一堆孤立的文本块，而是将其解析为一张巨大的网。在这张网中，节点代表实体（如人名、公司、概念），边代表它们之间的关系（如“就职于”、“收购了”、“位于”）。

通过这种方式，Graph RAG 不仅能找到相关的文本，还能沿着关系边进行图遍历，从而轻松解决多跳推理问题，并为大模型提供极具结构化、因果关系的上下文。

二、 Graph RAG 的核心架构与工作流

要构建一个 Graph RAG 系统，我们通常需要以下核心组件：

LLM（大语言模型）：作为引擎，负责从非结构化文本中抽取实体和关系，并最终生成回答。
图数据库：如 Neo4j、NebulaGraph 等，用于存储和查询图谱数据。
向量数据库：如 Chroma、Pinecone，用于存储实体的向量表示（在混合检索中极为重要）。

一个典型的 Graph RAG 工作流包含三个关键阶段：知识抽取、图谱存储、检索与生成。

1. 知识构建：从非结构化文本到图谱

这是 Graph RAG 的第一步，也是最困难的一步。我们需要利用 LLM 将长文本拆解，提取出节点和关系。
例如，对于文本“马斯克在 2002 年创立了 Space X”，LLM 需要将其转化为三元组：

(马斯克) - [创立于 (2002)] -> (SpaceX)

2. 图谱存储与社区发现

抽取出的三元组会被存入图数据库。为了支持全局性查询，Graph RAG（如微软的论文中所述）通常会使用**图算法（如 Leiden 算法）**进行社区发现。
系统会将紧密相连的节点聚类成一个个“社区”，并为每个社区生成摘要。当你询问宏观问题时，系统只需检索相关社区的摘要即可。

3. 混合检索策略

在实际的 Graph RAG 中，我们很少只使用图查询。最佳实践是**“向量检索 + 图遍历”的混合检索**：

Step 1: 将用户问题向量化，在图数据库或向量库中找到最相关的 N 个核心实体（起点）。
Step 2: 根据这些核心实体，在图谱中向外扩展 K 层（K-hop），提取相关的子图结构。
Step 3: 将提取出的子图（转化为自然语言文本）与用户的原始问题一并喂给 LLM，生成最终答案。

三、实战演练：用 LangChain + Neo4j 构建你的第一个 Graph RAG

理论讲完，让我们来点硬核的。接下来，我们将使用 LangChain、OpenAI API 和 Neo4j 构建一个极简但功能完备的 Graph RAG 管道。

环境准备：确保你本地运行着 Neo4j 数据库实例，并配置了 OpenAI API Key。

1. 安装依赖

1	pip install langchain langchain-openai langchain-community neo4j

2. 连接数据库并初始化 LLM

在代码中配置 Neo4j 的连接凭证和 LLM 模型。

import os
from langchain_community.graphs import Neo4jGraph
from langchain_openai import ChatOpenAI, OpenAIEmbeddings

# 配置环境变量
os.environ["OPENAI_API_KEY"] = "your-openai-api-key"

# Neo4j 数据库连接配置
NEO4J_URI = "bolt://localhost:7687"
NEO4J_USERNAME = "neo4j"
NEO4J_PASSWORD = "your-password"

# 实例化图谱连接
graph = Neo4jGraph(url=NEO4J_URI, username=NEO4J_USERNAME, password=NEO4J_PASSWORD)

# 实例化 LLM 和 Embedding 模型
llm = ChatOpenAI(temperature=0, model="gpt-4o-mini")
embeddings = OpenAIEmbeddings()

3. 文档解析与图谱构建

这是魔法发生的地方。我们将一段非结构化文本交给 LangChain 的 LLMGraphTransformer，让它自动提取实体和关系并存入 Neo4j。

from langchain_community.graphs.indexes import LLMGraphTransformer
from langchain_core.documents import Document

# 准备非结构化文本数据
text = """
Elon Musk is the CEO of Tesla. Tesla is headquartered in Austin, Texas. 
Tesla manufactures the Model S, Model 3, and Cybertruck. 
Elon Musk also founded SpaceX in 2002.
"""
documents = [Document(page_content=text)]

# 初始化图谱转换器
llm_transformer = LLMGraphTransformer(llm=llm)

# 将文本转换为图文档
graph_documents = llm_transformer.convert_to_graph_documents(documents)

# 将图数据保存到 Neo4j 数据库
graph.add_graph_documents(
    graph_documents, 
    baseEntityLabel=True, # 添加基础标签以优化后续检索
    include_source=True   # 保留文档来源信息
)

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

发生了什么？
执行这段代码后，你可以打开 Neo4j 的浏览器界面（通常为 http://localhost:7474），输入 MATCH (n) RETURN n，你会惊讶地发现，LLM 已经自动帮你把文本变成了包含节点（如 Elon Musk, Tesla）和关系（如 CEO_OF, HEADQUARTERED_IN）的漂亮图谱！

4. 构建混合检索链

有了图谱，接下来我们要解决“如何根据问题从图谱中检索信息”。我们结合向量化（找实体）和图遍历（找关系）。

from langchain_community.vectorstores import Neo4jVector

# 构建混合检索器 (同时结合向量和全文索引)
hybrid_retriever = Neo4jVector.from_existing_graph(
    embedding=embeddings,
    url=NEO4J_URI,
    username=NEO4J_USERNAME,
    password=NEO4J_PASSWORD,
    index_name="entity_index",
    node_label="Entity", # 我们刚才创建的实体标签
    text_node_properties=["id", "type"], # 要向量化的属性
    embedding_node_property="embedding", # 存储向量的属性名
    retrieval_query="""
    // 检索到实体后，向其周围扩展 2 跳（2-hop）关系
    MATCH (node)-[r]->(neighbor)
    WITH node, r, neighbor
    RETURN node.id + ' - ' + type(r) + ' -> ' + neighbor.id AS text_chunk,
           score,
           {
               source: node.id
           } AS metadata
    ORDER BY score DESC
    LIMIT 5
    """
)

5. 提问与生成

现在，让大模型基于检索到的图谱上下文来回答问题。

from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough
from langchain_core.prompts import ChatPromptTemplate

# 定义 RAG 提示词模板
template = """你是一个智能助手。请根据以下提供的知识图谱上下文信息来回答用户的问题。
如果你不知道答案，请直接说不知道，不要尝试编造答案。

上下文（图谱提取的关系）:
{context}

用户问题: {question}
回答:"""

prompt = ChatPromptTemplate.from_template(template)

# 构建 RAG 链
chain = (
    {
        "context": hybrid_retriever | (lambda docs: "\n".join(doc.page_content for doc in docs)),
        "question": RunnablePassthrough()
    }
    | prompt
    | llm
    | StrOutputParser()
)

# 测试多跳推理问题！
question = "特斯拉的 CEO 还创立了哪家公司？"
answer = chain.invoke(question)

print(f"问题: {question}")
print(f"回答: {answer}")

预期输出：

问题: 特斯拉的 CEO 还创立了哪家公司？
回答: 特斯拉的 CEO 是 Elon Musk，他还创立了 SpaceX。

为什么这很酷？
请注意，在原始文本中，“Elon Musk is the CEO of Tesla” 和 “Elon Musk also founded SpaceX” 是两句话。在传统向量检索中，如果用户提的问题只包含“特斯拉”，可能检索不到“SpaceX”的文本块。但在 Graph RAG 中，系统首先通过“特斯拉”找到“Elon Musk”节点，然后通过图谱边向外遍历，立刻发现了“创立了 SpaceX”的关系。这就是图数据库解决多跳推理的巨大优势。

四、进阶探讨：微软 Graph RAG 架构的启示

上面的代码展示了基础的 Graph RAG 流程。但在处理海量企业文档时，图会变得异常庞大，每次查询都进行 K-hop 扩展可能导致“图爆炸”（信息过载，Token 爆表）。

近期，微软研究院开源的 GraphRAG 项目为我们提供了企业级架构的新思路。它的核心创新点在于：全局社区检索。

微软的方案分为以下几步：

底层抽取：与我们的实战类似，利用 LLM 抽取实体和关系。
社区发现：使用图算法（如 Hierarchical Leiden）将整个大图划分为不同层级、紧密相连的“社区”。比如“技术部社区”、“市场部社区”。
社区摘要：利用 LLM 为每一个社区生成一段描述性摘要，将这些摘要作为新的节点存入图中。
全局查询：当用户提出宏观问题（如“这份财报的核心观点是什么？”）时，系统不再去遍历底层的千万个节点，而是直接查询高层次的“社区摘要”，然后利用 LLM 对多个社区摘要进行 Map-Reduce 汇总，得出全局结论。

这种**“图结构 + 层级摘要”**的设计，彻底解决了传统 RAG 无法回答全局性问题的痛点，是 Graph RAG 走向企业级应用的关键里程碑。

五、 Graph RAG 的挑战与最佳实践

虽然 Graph RAG 看起来无比强大，但在实际落地中，开发者往往会遇到不少坑。以下是几点挑战和最佳实践分享：

常见挑战

图谱构建成本高昂：在步骤 3 的代码中，我们让 LLM 提取三元组。对于数百万字的文档库，这会消耗大量的 Token 和时间。
图谱幻觉：LLM 在提取关系时可能会张冠李戴，生成错误的关系，导致图谱存在“脏数据”。
Schema 控制困难：如果没有统一的图谱 Schema，LLM 可能会对同一个实体生成无数种变体（如“苹果公司”、“Apple Inc”、“苹果”），导致图谱碎片化。

最佳实践

约束 Schema（Schema-Constrained Extraction）：在调用 LLM 提取实体前，明确给定允许的节点类型和关系类型。比如在医疗领域，规定只能提取“疾病”、“症状”、“药物”，以及“治疗”、“引起”等关系。
实体消歧与对齐：在数据入图之前，增加一个向量相似度判断环节。如果新提取的实体与图中已有实体相似度极高（如“马斯克”和“Elon Musk”），应当将其合并为同一个节点。
混合架构：不要抛弃传统的向量检索。最好的系统往往是“双擎驱动”：对于简单的事实查询，使用传统 RAG 以降低延迟和成本；对于复杂的关联查询，路由到 Graph RAG。

六、总结与展望

如果说大模型（LLM）是一个拥有极高智商但缺乏背景知识的大脑，那么传统 RAG 就像是给这个大脑塞了几本剪报，而 Graph RAG 则是给这个大脑植入了一张结构化、网状的“记忆海马体”。

Graph RAG 通过引入知识图谱，赋予了 AI 系统前所未有的逻辑推理能力和宏观洞察能力。虽然目前在图谱自动化构建、数据清洗等方面仍有成本门槛，但随着更轻量级的开源小模型（如 GLiNER 等专门用于 NER 的模型）的出现，Graph RAG 的构建成本正在快速下降。

在未来，我们甚至可以预见，Graph RAG 将与 AI Agent 深度绑定。Agent 不再只是机械地搜索网页，而是能在与用户的交互中不断构建、更新知识图谱，最终实现真正的认知自动化。

拥抱 Graph RAG，就是拥抱 AI 基础设施的下一个范式转移。现在就打开你的终端，动手构建你的第一张知识图谱吧！

一、 传统 RAG 的“天花板”：为什么我们需要 Graph RAG？