为什么你的 RAG 还在“瞎编“？因为大模型缺了一张知识图谱

西邮彭于晏

39人浏览 · 2026-07-30 14:50:13

西邮彭于晏 · 2026-07-30 14:50:13 发布

为什么你的 RAG 还在"瞎编"？因为大模型缺了一张知识图谱

RAG 解决了大模型"知识截止"的问题，但没解决"幻觉"和"不会推理关系"的问题。补上这块短板的，是把知识图谱请进 RAG——这就是 2024 年以来最火的 GraphRAG。

引子：大模型的两大原罪，RAG 只补了一半

大模型有两个天生的毛病：知识有截止日期（训练完就"失忆"），以及张口就编（幻觉）。

RAG（检索增强生成）治好了第一个——把最新文档塞进上下文，模型就不用全靠记忆。但它没治好第二个，因为传统 RAG 的本质是**“拼文本”**：把文档切块、向量化、按相似度召回几段，拼到 prompt 里让模型生成。

问题就出在"拼"字上：

它不知道实体之间的关系，只能猜；
它分块切断了上下文，跨文档的关联它接不上；
它不会多跳推理，问"苹果公司创始人还投了哪家被微软收购的公司"，它往往答得支离破碎。

这不是prompt写得不好，是架构的天花板。要破这个天花板，得给大模型一张知识图谱。

一、大模型为什么需要知识图谱？传统 RAG 的四个致命伤

把传统 RAG 的痛点拆开看，正好四刀：

1. 实体混淆
"苹果"是公司还是水果？"小米"是手机还是粮食？向量检索只看语义相似度，分不清同名异义的实体。知识图谱里每个实体有唯一 ID 和属性，从根上消歧。

2. 关系丢失
文本被切成独立块，块与块之间的关联被切断。“A 收购了 B，B 属于 C 行业”——这种关系在分块后散落各处，模型得自己脑补，容易补错。

3. 多跳推理弱
需要"串两步以上"的问题（如"某公司 2023 年的子公司，其母公司在 2021 年投了谁？"），传统 RAG 只能线性拼接文本，推理链一断就翻车。有基准测试显示，在多跳问答集（如 HotpotQA）上，传统 RAG 的准确率比 GraphRAG 低约 15%–20%。

4. 可解释性差
传统 RAG 最多溯源到"某段文本"，说不清"为什么这么答"。图谱能给出显式推理路径（A—收购→B—属于→C 行业），答案可审计、可追溯。牛津大学 2025 年提出的 MedGraphRAG，正是靠这个特性在 11 个医学数据集上把事实一致性提升了约 8%。

一句话总结：

向量 RAG 让模型"想起"相关文字，知识图谱让模型"看懂"实体之间的逻辑关系。 这两者结合，幻觉率显著下降，复杂查询才能扛住。

二、大模型"调用"知识图谱，到底有几种姿势？

"大模型调用知识图谱"不是只有一种玩法，按结合深度从浅到深，主流就三种：

姿势一：Text2Cypher（把问题翻成图查询）
最直白。让 LLM 把自然语言问题翻译成图数据库的查询语言（如 Neo4j 的 Cypher），直接查图谱，把结果喂回模型。适合已有成熟知识图谱的场景。

// 问：A 公司收购了哪些公司，它们分别属于什么行业？
MATCH (a:Company {name: "A"})-[:ACQUIRED]->(b:Company)-[:IN_INDUSTRY]->(i:Industry)
RETURN a.name AS 收购方, b.name AS 目标公司, i.name AS 行业

姿势二：GraphRAG（先建图，再检索）
最主流。你的数据可能只是一堆非结构化文档，没有现成图谱——没关系，用 LLM 先把文档抽成实体和关系、建成知识图谱，检索时"走图"而不是"搜向量"。这是微软 2024 年开源的 GraphRAG 管道干的事，也是本文重点。

姿势三：KG 增强 Prompt（图谱当上下文）
最轻量。不改动检索架构，只是把"相关子图"序列化后塞进 prompt，给模型多一份结构化线索。集成成本低，但显式推理能力弱，适合快速迭代的业务场景。

一张表看清楚：

姿势	核心逻辑	优势	劣势	最适合
Text2Cypher	问题 → 图查询语言 → 直接查 KG	高精度、强可解释	依赖现成图谱，容错低	已有 KG 的金融/医疗强逻辑场景
GraphRAG	文档 → 自动建图 → 图检索增强	全局感知强、可处理非结构化文档	建图成本高、延迟略增	企业知识库、产业链/风险分析
KG 增强 Prompt	子图当上下文塞进 prompt	集成快、兼容传统 RAG	推理能力弱	轻量知识库、快速验证

三、GraphRAG 是怎么工作的？以微软方案为例

微软 GraphRAG 把流程拆成"索引构建"和"查询推理"两大阶段，思路很清晰。

阶段一：索引构建（离线，建一次或增量）

分块：原始文档切成 TextUnit（默认约 1200 字符，带重叠）。
抽取实体关系：用 LLM 从每个 TextUnit 里识别实体（人物/组织/概念）和关系（合作/属于/提出），生成图的节点和边。
社区发现：对整张图做层次化聚类（微软用的是 Leiden 算法），把相关性高的实体归成"社区"，并为每个社区生成一份摘要。
嵌入与存储：文本块、实体、社区报告各自生成向量存入向量库；图结构存入图数据库。

这一步的精髓在于分层摘要：既有一句话级别的局部信息，也有"全局社区"级别的高层概括。

阶段二：查询推理（在线，实时响应）

根据用户问题的类型，GraphRAG 支持三种检索模式：

Local（局部）：针对具体问题，沿实体做多跳遍历，找直接相关的节点和边；
Global（全局）：针对"这份语料整体在讲什么"这类概括性问题，先召回高层社区摘要，再下钻细节——这是传统 RAG 几乎做不到的；
Drift（混合）：在局部检索中"漂移"出去，捕捉意外但相关的信息。

最后，把"图节点/边 + 社区报告 + 原文片段"组装成紧凑上下文，注入 LLM 生成答案，并标注证据来源。

微软的原始论文《From Local to Global》报告：在全局性问题（global sensemaking）上，GraphRAG 在回答的**完整性（completeness）和多样性（diversity）**上显著优于"ChatGPT + 文本块检索"的朴素基线——这正是传统向量 RAG 的软肋。

四、上手：两段关键代码（示意）

不想只听原理？给你两个能落地的抓手。

抓手一：微软 GraphRAG 官方管线（最小可用）
这是官方推荐的 CLI 用法，基本是"装好→建索引→提问"三步：

pip install graphrag
# 1. 初始化项目（生成 .env 和 settings.yaml）
python -m graphrag.init --root ./rag

# 2. 在 ./rag/input 放入你的文档，配置好 API Key 后建索引
python -m graphrag.index --root ./rag

# 3. 提问：--method global 走全局检索，local 走局部检索
python -m graphrag.query --root ./rag "这份资料主要讲了哪些技术趋势？" --method global

抓手二：LlamaIndex 的 Property Graph Index（开发者更熟）
如果你已在用 LlamaIndex，它的 Property Graph Index 把"建图 + 检索"封装得很顺手：

from llama_index.core import SimpleDirectoryReader
from llama_index.core.indices.property_graph import PropertyGraphIndex
from llama_index.llms.openai import OpenAI

documents = SimpleDirectoryReader("./data").load_data()
index = PropertyGraphIndex.from_documents(
    documents,
    llm=OpenAI(model="gpt-4o"),   # 用 LLM 自动抽取实体与关系
    show_progress=True,
)
# 直接问，索引会自动走"图检索 + 文本检索"的混合路径
engine = index.as_query_engine()
print(engine.query("哪几家公司之间存在收购关系？分别属于什么行业？"))

注意：以上为示意代码，跑通需配置对应 API Key 和依赖。生产环境还要考虑增量更新（新文档只抽增量、不重建全图）和成本控制——全量建图对大模型调用次数不低，文档量大时建议分层提取 + 并行处理。

五、什么时候该上 GraphRAG，什么时候别

和所有技术一样，GraphRAG 不是银弹。

值得上：

查询需要多跳推理（“我们供应商的供应商是谁？”）；
需要可解释的推理路径（合规、法律、医疗）；
数据本身就是关系型的（组织架构、文献引用网、金融交易网络）；
要回答跨大语料的全局主题问题（“今年客户反馈的主要议题是什么？”）。

先别上：

只是简单事实检索（“XX 的定价是多少？”），向量 RAG 就够了；
数据之间没什么实体关系；
延迟和成本极其敏感，GraphRAG 在复杂查询下延迟通常比传统 RAG 高 2–3 倍（这是真实工程代价）。

2025 年的 GraphRAG-Bench（厦门大学等团队提出）也印证了这点：GraphRAG 在复杂推理和上下文摘要任务上稳定优于朴素 RAG，但在简单事实检索上，差距会收窄到向量检索就够用的程度。

六、观点：知识图谱是 LLM 的"事实锚"和"长期记忆"

我把话挑明：

RAG 解决"模型记不住新东西"，GraphRAG 解决"模型想不清关系"。前者补的是知识的时效性，后者补的是知识的逻辑性。

这是一个范式层面的升级，不是小修小补。2025–2026 年这个方向明显在爆发：微软 GraphRAG 之后，LightRAG（更轻更快）、LlamaIndex Property Graph、以及主打查询分流的 FRAG、主打时序推理的 GraphIRAG 接连出现；Neo4j、ArangoDB 等图数据库把向量索引和图查询做成原生混合。

但也要泼盆冷水：建图和增量维护是硬工程。高质量图谱构建耗时耗力；数据持续变化时，要么设计增量更新，要么承受全量重建的成本；还有模型中毒（注入恶意三元组）、检索攻击等安全隐患。GraphRAG 不是"接个库就完事"，它是个需要长期运维的系统。

给开发者的建议：先别急着上重型 GraphRAG。如果你的场景是简单问答，先把向量 RAG 做扎实；当你开始频繁遇到"实体混淆、关系接不上、多跳答不准"时，再引入知识图谱——从轻量的 KG 增强 Prompt 试起，逐步过渡到 GraphRAG。让图谱成为模型的"事实锚"，而不是另一个负担。