Graph RAG 实战指南：用知识图谱打破传统 RAG 的“语义迷雾”

Posted on 2026-05-07 In AI 技术

# AI 生成 # GLM-5.1

在当前的大模型（LLM）应用浪潮中，检索增强生成已经成为企业落地 AI 的标配架构。然而，随着业务场景的日益复杂，开发者们逐渐发现传统的基于向量数据库的 RAG 系统，在面对复杂推理、全局性提问和多跳问题时，显得力不从心。

为了突破传统 RAG 的瓶颈，**Graph RAG（基于知识图谱的检索增强生成）**应运而生。它巧妙地将大模型的语言理解能力与知识图谱的结构化推理能力结合在一起，成为了下一代 RAG 系统演进的重要方向。

本文将从传统 RAG 的痛点出发，深入浅出地为你剖析 Graph RAG 的核心原理、架构设计，并手把手带你通过 LlamaIndex 实现一个简版的 Graph RAG 系统。

一、传统 RAG 的“中年危机”：为什么我们需要知识图谱？

在了解 Graph RAG 之前，我们需要先弄清楚传统 RAG 到底出了什么问题。

传统 RAG 的工作流非常直观：

切片与向量化：将文档切成固定大小的 Chunk，并通过 Embedding 模型转化为向量。
向量检索：将用户的 Query 也转化为向量，在向量数据库中计算余弦相似度，召回 Top-K 个 Chunk。
大模型生成：将召回的 Chunk 作为上下文，连同 Query 一起喂给 LLM 生成最终答案。

这种架构在**“事实性问答（单跳问答）”**中表现优异，比如问“公司年假有几天？”。但在面对以下场景时，往往会遭遇“滑铁卢”：

1. 碎片化导致的“语境迷失”

文档切分会破坏原始文本中完整的逻辑链条和实体关系。比如在一本悬疑小说中，向量检索可能找回了“作案工具是一把带有红宝石剑柄的匕首”和“男主人公的祖传宝剑丢失了”这两个 Chunk，但 LLM 很难直接将这两者在缺乏显式关联的情况下推理出真凶。

2. 多跳推理的灾难

当问题需要综合多个维度的信息才能得出结论时（例如：“相比2022年，2023年公司在人工智能领域的研发投入增长了多少百分比？”），由于信息散落在不同的段落甚至不同的文档中，简单的向量相似度搜索往往无法一次性召回所有必要的组合信息。

3. “全局性”问题的盲区

如果你问“总结一下这本财报中提到的所有战略转型方向”，传统 RAG 只能随机抽样几个相似的 Chunk，这会导致信息严重遗漏。它缺乏一种从宏观视角对信息进行高度抽象和概括的能力。

知识图谱的引入，正是为了解决“实体关联”和“全局视角”的问题。 图谱以“实体-关系-实体”的三元组形式存储数据，天然保留了现实世界中的网状结构，让机器具备了“顺藤摸瓜”的推理能力。

二、揭开 Graph RAG 的面纱：核心概念与架构

Graph RAG 并不是完全推翻传统 RAG，而是在其基础上引入了图谱的构建和检索机制。一个标准的 Graph RAG 系统通常包含以下两个核心闭环：

1. 索引阶段：从非结构化文本到知识图谱

不同于传统 RAG 的 Text -> Chunk -> Vector 路径，Graph RAG 的路径是：
Text -> Chunk -> LLM提取实体和关系 -> 构建知识图谱

在这个阶段，LLM 充当了一个信息抽取专家的角色。它会阅读切分后的文本，识别出其中的关键实体（如人名、地名、组织、概念等）以及它们之间的逻辑关系（如“属于”、“投资”、“位于”等），并将其转化为结构化的图数据存储在图数据库（如 Neo4j、NebulaGraph）中。

2. 检索与生成阶段：图遍历与上下文组装

当用户提出问题时：

实体识别：首先从用户的 Query 中提取出核心实体（种子节点）。
子图提取：以这些核心实体为起点，在知识图谱中进行遍历（如 N-hop 遍历），获取与其高度相关的其他节点和边。
上下文增强：将提取出的“子图结构”或转化为文本后的图谱上下文，与向量检索的结果（如果有）融合，共同作为 Prompt 喂给大语言模型生成回答。

微软的 GraphRAG 创新：社区检测与全局摘要

值得一提的是，微软最近开源的 GraphRAG 项目将这一技术推向了新的高度。它在构建图谱后，引入了层次化社区检测（Leiden 算法），将庞大的图谱划分为不同层级的“社区”，并利用 LLM 为每个社区生成摘要。
这样一来，系统不仅能回答具体的局部问题，还能基于社区摘要回答全局性的总结类问题，极大地弥补了 LLM 在长文本全局信息抽取上的短板。

三、动手实战：使用 LlamaIndex 构建知识图谱 RAG

空谈理论不如动手实践。接下来，我们将使用目前大模型领域非常流行的框架 LlamaIndex，配合轻量级的图数据库，构建一个最基础的 Graph RAG 应用。

环境准备

确保你安装了以下 Python 依赖，并配置好 OpenAI 的 API Key（这里默认使用 OpenAI 作为底座模型，你也可以替换为本地大模型）。

1	pip install llama-index llama-index-graph-stores llama-index-llms-openai llama-index-embeddings-openai networkx

第一步：初始化 LLM 和 Embedding 模型

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

# 设置 OpenAI API Key
os.environ["OPENAI_API_KEY"] = "YOUR_API_KEY"

# 配置全局 Settings
Settings.llm = OpenAI(temperature=0, model="gpt-4o-mini")
Settings.embed_model = OpenAIEmbedding(model="text-embedding-3-small")

第二步：准备测试数据并构建文档

为了让效果明显，我们构造一段包含多重实体和人物关系的简单文本。

from llama_index.core import Document

text = """
阿尔伯特·爱因斯坦于1879年出生于德国乌尔姆。
他在瑞士苏黎世联邦理工学院（ETH Zurich）完成了高等教育。
后来，他提出了相对论，并因此获得了诺贝尔物理学奖。
爱因斯坦后来移居美国，并在普林斯顿大学担任教授。
特斯拉的CEO埃隆·马斯克非常崇拜爱因斯坦。
"""

# 构建 LlamaIndex Document 对象
documents = [Document(text=text)]

第三步：构建知识图谱索引

LlamaIndex 提供了非常优雅的 KnowledgeGraphIndex。它能自动调用 LLM 从文本中抽取（实体，关系，实体）的三元组，并存入底层的图存储中。

为了简单演示，我们这里使用基于内存的 NetworkX 作为图存储（在生产环境中，你可以无缝替换为 Neo4j 或其他图数据库）。

from llama_index.core.indices.knowledge_graph import KnowledgeGraphIndex
from llama_index.graph_stores.networkx import NetworkXGraphStore

# 初始化 NetworkX 图存储
graph_store = NetworkXGraphStore()

# 构建知识图谱索引
# max_object_length: 控制抽取实体的最大长度
kg_index = KnowledgeGraphIndex.from_documents(
    documents,
    graph_store=graph_store,
    max_object_length=128,
    max_triplets_per_chunk=10, # 每个 Chunk 提取的最大三元组数量
    show_progress=True,
)

技术细节解析：在执行上述代码时，LlamaIndex 会在底层向 LLM 发送类似如下的 Prompt：

“请从以下文本中提取知识三元组，并返回 JSON 列表格式：[(实体1, 关系, 实体2), …]。文本：…”

你可以通过以下方式查看我们刚刚构建的图谱结构（三元组）：

# 打印提取出的部分三元组
triplets = kg_index.refresh_ref_docs()
for triplet in triplets[:5]:
    print(f"实体1: {triplet[0]}, 关系: {triplet[1]}, 实体2: {triplet[2]}")

第四步：基于知识图谱的检索与查询

索引构建完成后，我们就可以进行 Graph RAG 的核心——检索和生成了。当我们发起查询时，系统同样会利用 LLM 从 Query 中提取实体，然后到 NetworkX 图数据库中进行子图匹配，最后将命中的三元组和原始文本片段一起送给 LLM。

# 创建查询引擎
# graph_store 能力允许引擎在图谱中进行检索
query_engine = kg_index.as_query_engine(
    include_text=True,     # 在上下文中包含原始文本
    response_mode="tree_summarize", # 使用总结模式生成答案
    embedding_mode="hybrid",        # 结合关键词和向量检索图谱节点
    similarity_top_k=5,
)

# 提出一个多跳问题
question = "爱因斯坦在哪上的大学？这所大学位于哪里？"
response = query_engine.query(question)

print("=== 回答 ===")
print(response.response)

进阶：Graph RAG 与 Vector RAG 的深度融合

在真实的生产环境中，纯图谱检索和纯向量检索都不是万能的。最成熟的方案是构建双路检索：将向量数据库（如 Chroma、Milvus）和图数据库（如 Neo4j）结合起来。

向量检索负责找“语义相似”的宽泛信息。
图检索负责找“逻辑强相关”的结构化关联。

你可以使用 LlamaIndex 的 SQLAutoVectorQueryEngine 或自定义 Retriever，将图的 N-hop 遍历结果与 Vector 的 Top-K 结果进行 Reciprocal Rank Fusion (RRF，倒数排名融合)，从而得到最全面的上下文。

四、 Graph RAG 的适用场景与挑战

Graph RAG 虽然强大，但并非银弹。在实际落地中，我们需要客观评估其优劣。

典型的最佳适用场景

情报与安防分析：挖掘人物、地点、事件之间隐藏的关系网络（如反洗钱调查）。
医疗与法律领域：涉及复杂的术语、规则、因果关系和例外情况，图谱能提供极高的精准度。
代码库分析与 DevOps：理解各个微服务、类、接口之间的调用关系，快速定位架构问题。
智能客服（产品生态）：处理具有多种配件、售后规则、兼容性要求复杂的硬件产品问答。

当前面临的挑战（痛点）

图谱构建成本高昂（时间与金钱）：依赖 LLM 进行信息抽取不仅消耗大量 Token，而且推理时间极长。处理几百 MB 的文档可能需要花费大量的 API 费用和数小时的时间。
幻觉导致的图谱污染：LLM 在抽取三元组时如果产生“幻觉”，就会把错误的知识写入图谱，这种“结构化的错误”比普通的文本幻觉更难被发现和修复。
实体对齐：LLM 可能在第一段提取出“爱因斯坦”，在第五段提取出“阿尔伯特”，图谱需要有一种机制将它们合并为同一个节点。目前很多框架在这个环节做得还不够自动化。
图数据库的运维门槛：相比传统的向量数据库，图数据库的部署、查询语言（如 Cypher）的学习和性能调优，对研发团队提出了更高的要求。

五、总结

传统 RAG 就像是给大模型提供了一堆散落的“书籍页码”，而 Graph RAG 则是给大模型提供了一张“思维导图”。它通过知识图谱重建了数据之间的结构化关联，赋予了大模型强大的逻辑推理和多跳分析能力。

随着图数据库技术的演进以及轻量级小模型在“信息抽取（IE）”任务上的性能提升，构建 Graph RAG 的成本正在快速下降。未来，“Vector + Graph” 的双引擎混合 RAG 将成为构建企业级知识库的标准范式。

如果你现在的 RAG 项目正面临“召回率低”、“逻辑关联差”、“无法回答宏观总结类问题”的困境，那么现在正是引入知识图谱、试水 Graph RAG 的最佳时机！