XingGraph中篇：目前图谱做RAG乱象和思考（纯手打分析好文，进来看看吧~）Graph + RAG 是当下热点，微

别迷信图谱：实测 GraphRAG 后，我发现了纯图谱路线的三大硬伤

摘要：Graph + RAG 是当下热点，微软开源的 GraphRAG 更是被疯狂"套壳"。我用冰箱技术文档完整实测了一遍纯图谱路线：简单属性题答得漂亮，多跳对比题勉强能过，但一到因果推理题就露馅——三元组只能存「属性标签」，存不了「因果传导链」，回答里最关键的"为什么"全是 LLM 拿属性标签脑补出来的，置信度直接掉到 64%。本文拆解了 GraphRAG 的建图全流程，指出三元组的三点硬伤、纯图谱幻觉率高的根源，顺带吐槽了"向量 + 图谱多路融合"方案里 context 分配、链路追踪上的新问题，以及那些花里胡哨却没什么用的图谱可视化。一句话：新技术别只听人吹，自己跑一遍才知道水有多深。

引言：为什么大家都在做图谱

先从需求说起。之前大家也明确了NaiveRAG一堆问题，一个真正能落地的 RAG 链路，必须保证这些能力：

有可追踪的链路
有实体关联，夸chunk关联
可拓展业务术语关系
幻觉率尽可能低
想看到LLm沿着正确的明确的路线前进

也正因为如此，知识图谱成了趋势，Graph Engineering 又翻红，也是异曲同工。

那么，现在就来看看当下比较火热的 Graph + RAG 项目，从它们身上找出优点和缺点，然后去补足自己的场景。

一、GraphRAG 的完整建图流程

最火热、被了解最多的自然是微软开源的 GraphRAG，很多项目都是基于它拓展出来的。也有很多项目纯属套壳——直接集成这个项目，就大放厥词说自己已经有了图谱能力，能克服原始 Native RAG 的缺点了。然而，他们根本没搞清楚 GraphRAG 真正做了什么，以及它的缺点到底是什么。

GraphRAG 这名字占得真好听，里面一堆功能。先一步步看：图谱是怎么建立的。

文档切分：生成文本单元。
实体和关系抽取：
- 识别实体：人名、组织、地点、事件、概念等
- 识别实体类型
- 识别实体之间的关系
- 生成关系描述
- 还可能做多轮抽取（叫 Gleanings），用来补漏，防止一次抽取不全。
构建知识图谱：把抽取结果构建成图。
- 节点：实体
- 边：关系
- 边属性：关系类型、关系描述、权重等
社区检测：用图算法对图谱做社区检测，最常用的是 Leiden 算法。社区检测会把连接紧密的实体聚成一个社区。GraphRAG 通常会生成层级社区结构：小社区可以合并成大社区。
生成社区报告：对每个社区，用 LLM 生成一份社区报告（Community Report）。报告通常包含：
- 社区主题
- 关键实体
- 主要关系
- 内容摘要
- 社区在整个语料库中的意义
这些社区报告是 GraphRAG 做全局检索的重要基础。
生成嵌入索引：对实体、关系、文本单元、社区报告等分别生成嵌入向量，方便后续检索时做相似度匹配。
存储：最终把图、文本单元、社区报告、向量等存到图数据库和向量数据库中。

好，听着倒是挺全乎的：能对 chunk 抽取其中的实体和实体属性建成边，或者实体与实体之间建边，还有重新抽关系的流程，防止抽取的关系落下。

等图里的实体多了、复杂了，还能用图算法 Leiden 建立社区，生成社区报告——越听越离谱。

那真正的结果是什么样呢？我也实测了。

二、实测：拿冰箱文档走一遍

假设这是已经被 MinerU 处理过的文件的 MD，直接拿给 LLM 走流程：

可以看到，这个文件里都是一些关于某款冰箱的技术参数，建立出来的图谱关系，就是大家印象中的图谱：

好，这是剪出来的图谱大概的样子。这里展示效果可能不够好，但大家都能理解：就是这一个实体，各种乱七八糟的关系和属性都建成了边。

那问个问题吧：

能看到回答还是很准确的。想想那也是理所应当：这本来就是你的边，而且表格也写得非常明确，在这个图里也能看到，型号后面的一堆属性都给你展示出来了。

好，接着再问问难点的题：

可以看到，这个问题跨的节点比较长，如果放到图谱中的样子应该是：

美的和海尔这两个型号，通过多跳图谱连接连到了一起。从问答图里也能看出来，回来的是一堆美的的属性、一堆海尔的属性。

看着是不是回答得还不错？但是仔细想想呢？

这返回的是一堆属性边、再一堆属性边。后面的回答结果，是不是都是 LLM 拿到这一堆属性，自己编出来的？就是大模型模仿人——看到一个冰箱比别的冰箱多了个"双风道循环系统"，然后就去编了：说这是可以防止串味、控味效果最好。这种图谱设计，把事无巨细的属性都连到了实体上，一个实体挂一堆属性，真的合理吗？先不说 context，就说这一堆属性真的能挂得这么好吗？如果不是类似这种、一个实体的属性清晰的表格，换成别的段落，能提取得这么好吗？

接着上例子：

好，这个例子问得就比较隐晦了，不是那么直接地问 A 的属性，或者 A 和 B 的属性差别。

能看到图中红色的答案是：单压机带动整个系统 + 单风道集中送风。

咱们可以找到原文，正确的回答应该是怎么分析：

单循环制冷系统：整套冰箱仅配置 1 个蒸发器，依赖风机和风道将冷量被动输送至冷藏室、冷冻室等各个舱室，通过风门开关控制不同舱室的送风量。

这才是正确的原文，也是正确的回答。

但最终图谱回答只输出了两个粗粒度结论：单压机带动整个系统、单风道集中送风，丢失了「单蒸发器」「冷量被动输送」「风门开关被动分配」这三个核心结构细节；且整体置信度只有 64%。

三、从实测看三元组的三大硬伤

硬伤一：只能存「属性标签」，存不了「因果传导链」

图谱里可以存下：

单循环制冷系统 --制冷剂循环方式--> 单压机带动整个系统
单循环制冷系统 --送风模式--> 单风道集中送风

但它存不了这条完整逻辑链（如果真要这样存储，太复杂了吧，这么细节的推理全要存，图谱得多夸张）：

单蒸发器 → 冷量统一产出 → 单风道被动输送 → 风门开关分配 → 各舱室冷量不均

三元组只能表达"实体有什么属性"，表达不了"A 导致 B，B 导致 C"的多层因果传导。回答里的"为什么会导致分配不均"，本质是大模型根据两个属性标签、结合通用常识补出来的——可以看看上面大模型回复的时候，绿色框里全是 LLM 自己脑补出来的分析思路，就像模仿一个人类在推销产品时，看到一个高科技名词"单压机单风道"，就自己脑补把这个词和分配不均关联起来了——这不是图谱推理出来的。这也是置信度只有 64% 的核心原因：事实属性 100% 确定，因果关联是模型脑补的，置信度很低，加权后整体偏低。

硬伤二：过程性描述拆不成干净的三元组

原文里"依赖风机和风道将冷量被动输送""通过风门开关控制送风量"都是过程性描述，很难拆成干净的三元组：

拆太细：要新建「风门」「蒸发器」「冷量输送」一堆中间实体，实体数量爆炸，抽取准确率骤降；
拆太粗：就只能留下"单风道""单压机"这种标签化属性，丢失中间的结构逻辑细节。

现在的图谱输出就是典型的「粗粒度抽取结果」——能说出大类特征，但讲不清深层结构原因。

硬伤三：就算硬建，也是又贵又难

如果硬要让纯图谱也答出这道题，你需要把整个过程拆成 7 个实体 + 8 条关系，还要新增"导致"这类因果边：

实体节点

单循环制冷系统
蒸发器
送风风道
风门开关
冷量
舱室
冷量分配不均

关系边

1. 单循环制冷系统 --配置--> 蒸发器
2. 蒸发器 --数量--> 1个
3. 单循环制冷系统 --依赖--> 送风风道
4. 送风风道 --输送--> 冷量
5. 冷量 --输送方式--> 被动输送
6. 单循环制冷系统 --通过--> 风门开关
7. 风门开关 --控制--> 舱室送风量
8. 单蒸发器+被动送风+风门分配 --共同导致--> 冷量分配不均

即便建到这么细，依然有两个无解问题：

第 8 条"共同导致"的因果边，在自然语言里表述千变万化，抽取准确率极低，很容易漏建或错建；
用户提问时，图谱查询引擎很难精准走到这条因果路径上，大概率只会召回前几条属性边，还是答不出"为什么"。

四、为什么纯图谱的幻觉率居高不下

从上面一系列讲解，大家能看出来这种很傻的方式的缺点了吧——幻觉尤其高。主要原因就是：

第一步就把文本打碎成 实体-关系-实体 三元组；
所有推理、查询都依赖预定义的边；
原文只是抽取原料，检索时不直接召回原文，只返回图谱节点；
代价是：把原本的意思给打碎。如果把所有分析都放在建图谱这一步，事无巨细地让第一次入图谱时就把边建好——一是做不到，反复抽取多次也拿不全；二是时间消耗太大；三是所有检索精度都压在了第一步；四是业务人员想定位原文时找不到了，因为已经打碎了，让 LLM 去分析关系建图谱去了。

五、回到 Naive RAG：检索原文的价值

一顿输出，差不多都讲完了。

这个项目有大公司背书，又发布得很早，以至于很多项目都这样做。我看了一堆文章和项目，没看到有人质疑过。现在的 LLM 爆炸阶段，一有新技术，先让 LLM 分析下有多好多好，然后翻翻文章、公众号都在吹牛，那我也吹吹牛，脑袋越来越不转了，人云亦云，不好好了解。

所以对于一个新技术的正确态度是：最好去实践实践。如果没有实践的机会和时间，那也要了解下上面讲的建图流程和检索流程。

现在我觉得"技术直觉"是这个时代最牛的能力。现在各种开源项目都附带着自己的网站博客，做得花里胡哨，吹牛的话通过 LLM 随便吹，实在太能包装了。一般没点技术、不懂原理的人，很容易被骗——只有真正使用起来的人才知道其中的困难和缺点。不要等到快落地生产、快交付了，才发现一堆问题。

有这种技术直觉，可能是天赋，也可能是技术了解得深，一眼就能看到漏洞。这也是应该学习的方向吧。

好了，现在应该能看到纯图谱的缺点了。这时候大家又开始怀念以前的 Naive RAG 了——起码能检索回来原文段落呀，这个原文段落给最后的 LLM 看，肯定能回复得很好。

但 Naive RAG 的方式是：

完全不做结构化预处理
纯语义相似度召回
推理全部交给 LLM 读原文
零抽取、弱结构、强语义兜底

也看到有项目将两者结合了。

六、多路融合真能解吗？

多路融合，就是把原来的向量路、关键词路和现在的图谱路都融合起来，检索一堆信息送给 LLM 看：

能看到这个结构图了——这是某某开源项目所谓的"多路融合混合检索"。

但是它有啥问题呢？随着文章的 chunk 变多：

给向量路多少 context，给图谱路多少 context？

如果检索到的向量路回来一堆 chunk，图谱路的 context 被淹没：90% 的向量路 chunk + 10% 的图谱信息，这让 LLM 怎么分析？和原来的单向量路有多少区别？这里的图谱路哪里缓解了原来 Naive RAG 的缺陷？chunk 和 chunk 之间的关系也没有建立起来呀，这图谱路只能做到多给点信息，没啥帮助了。

还有，图谱的作用也没了。我要的可追踪在哪里？我在检索一个型号，到底是不是走的这个型号的路线检索的？这里加了一个向量路，还怎么追踪链路？

上面都是我看到这个分析结果的第一下直觉反应。后面我就拿着直觉反应和 LLM 聊，不断验证自己对于别人吹牛的亮点技术的直觉反应对不对。很不错的方式，和 LLM 一起进化。知识不能事无巨细地进化，这种直觉就像艺术的直觉一样，LLM 是做不到的，LLM 只能模仿。而这个"能模仿"已经很厉害了——因为很多人就没脑子，只会照葫芦画瓢。