一、一个被忽视的问题
传统RAG（检索增强生成）已经成了大模型落地的标配方案——把文档切块、向量化、检索、喂给LLM。
但一个普遍存在的现象是：在需要跨文档、多跳推理的场景下，RAG依然会产生幻觉。
比如问一个医疗场景的问题：
“高血压合并糖尿病的患者，首选的ACEI类药物是哪几种？禁忌症分别是什么？”
传统RAG的答案是：拼凑了几个相关的文本块，但把“卡托普利”列到了禁忌症列表里——原文说的是“严重肾功能不全者禁用”，AI把因果关系搞混了。
问题出在哪里？
不是RAG不够好，而是“分块检索”这种方式，天然无法理解实体之间的逻辑关系。
二、传统RAG的局限性：为什么“分块”不够？
传统RAG的核心流程是：分块 → 向量化 → 相似度检索 → 拼接生成。
这套流程的问题在于：
| 问题 | 说明 | 后果 |
|---|---|---|
| 语义断裂 | 把一个完整概念切到不同块里 | 关键信息丢失 |
| 关系丢失 | 实体间的因果关系、时序关系被忽略 | 逻辑错误 |
| 无法多跳推理 | “A影响B，B影响C，A对C的影响？” | 需要跨越多个块的推理无法完成 |
| 检索噪声 | 检索到相似但无关的内容 | LLM被误导 |
这些特征在单文档、简单问答场景下问题不大，但在需要理解关系、跨文档推理的场景下，就是硬伤。
因此，一个合理的结论是：
传统RAG解决的是“找相似文本”，企业真正需要的是“理解实体关系”。
三、什么是GraphRAG？
GraphRAG的思路很直观：把知识从“一堆文本块”变成“一张关系网”。
用阿里云技术文档的话说：“GraphRAG通过在传统向量检索的基础上引入知识图谱，将非结构化文本中隐含的实体和关系显式化、结构化”。
类比一下：
- 传统RAG ≈ 查字典（找到包含关键词的段落）
- GraphRAG ≈ 看地图（看到实体之间的连接路径）
一个完整的GraphRAG流程，通常包含三个层次：
3.1 知识抽取层
从非结构化文本中提取实体-关系-实体三元组。例如：
（高血压，合并，糖尿病）（ACEI类药物，治疗，高血压）（卡托普利，属于，ACEI类药物）
3.2 图谱存储与检索层
把三元组存入图数据库，检索时同时进行：
- 向量检索：找到相关文本块（保召回）
- 图检索：找到相关实体和关系子图（保精度）
3.3 增强生成层
把“文本块 + 关系子图”一起喂给LLM，让模型基于结构化的关系信息生成答案。
四、核心区别：一张表说清楚
| 维度 | 传统RAG | GraphRAG |
|---|---|---|
| 知识表示 | 文本块（Chunk） | 实体-关系-实体（三元组） |
| 检索方式 | 向量相似度 | 图检索 + 向量检索 |
| 推理能力 | 单步匹配 | 多跳路径推理 |
| 可解释性 | 黑盒 | 可追溯推理路径 |
| 典型失效场景 | 跨文档关系问题 | 关系断裂（正在被解决） |
效果差异有多大？
一篇发表在生物医学信息学期刊上的研究显示：
- 传统ChatGPT-4在临床问答上的准确率：37%
- DeepSeek-R1：52%
- 基于知识图谱的GraphRAG框架：98%
幻觉率从63%降至1.7%。
五、GraphRAG的技术演进方向
GraphRAG本身也在快速演进。几个值得关注的方向：
5.1 静态图谱 → 动态图谱
传统GraphRAG依赖预构建的静态知识图谱。最新的Relink框架提出了“边推理边构建”的新范式——根据具体查询动态构建证据图谱，在五个开放域问答基准测试上平均提升了5.4%的EM和5.2%的F1。
5.2 最小充分子图检索
另一个方向是检索最小且充分的推理子图——只提取回答问题必须的证据，剔除冗余信息，提升推理效率。
5.3 混合检索成为主流
学术界的共识是：GraphRAG不是替代向量RAG，而是补充。最佳实践是混合检索——向量检索保召回，图检索保精度。
六、什么时候需要GraphRAG，什么时候传统RAG就够了？
传统RAG足够的情况：
- 单文档内的简单问答
- 事实性检索（“什么是XX”）
- 资源有限的轻量级应用
需要GraphRAG的情况：
- 跨文档、多跳推理（如“A对C的间接影响”）
- 实体和关系是关键要素的场景（医疗、金融、法律、制造）
- 对可解释性有要求的场景
七、一个简化的技术参考
如果你正在考虑引入GraphRAG，以下几个技术方向值得关注：
- 知识抽取：从非结构化文本中提取三元组（S-P-O）
- 图数据库选型：Neo4j、NebulaGraph、JanusGraph
- 混合检索：向量检索 + 图检索的融合策略
- 动态图谱构建：按需构建证据子图，而非全量图谱
目前开源生态（LlamaIndex、LangChain、RAGFlow）和部分商业产品都在这些方向上探索。
八、延伸阅读
本文讨论的GraphRAG技术演进方向，与
[ZGI]项目在“企业级知识图谱+混合检索”上的实现思路基本一致。如果你对该方向的具体落地感兴趣，可以参考ZGI的技术文档或开源仓库。
写在最后
GraphRAG不是万能药，它解决的是传统RAG的一个特定短板：从“查相似文本”到“理解关系”。
这个演进路径很有意思：
- 第一阶段：纯LLM（靠参数记忆，容易幻觉）
- 第二阶段：传统RAG（查文本块，但不理解关系）
- 第三阶段：GraphRAG（理解关系，支持多跳推理）
- 第四阶段：Agentic RAG（自主规划、调用工具）
希望这篇文章能帮你理清一个关键问题：
你的RAG，是在“匹配文本”，还是在“理解关系”？
