GraphRAG vs 传统RAG：我实测了主流方案，结果和你想的不一样

本体与AI · 第2篇

去年我帮一个客户搭企业问答系统，上来就选了GraphRAG——觉得有图谱加持肯定比纯向量检索强。

结果呢？简单问题答得一塌糊涂，复杂问题偶尔能惊艳一把，但整体体验还不如最朴素的向量RAG。

不是我一个人踩这个坑。密歇根州立大学和Meta今年发了一篇评测论文，结论和我的实战感受几乎一模一样：GraphRAG和传统RAG各有各的地盘，不是谁替代谁。

今天我就把实测结果、论文数据、还有踩坑经验全摊开来说。看完这篇，你下次选方案至少能少走两个月弯路。

▎ 先搞清楚：GraphRAG到底加了什么

传统RAG的逻辑很简单：

用户提问 → 向量检索最相似的N段文本 → 拼起来喂给大模型 → 生成回答

相当于你在一个超级大的图书馆里，用"意思相近"来找参考书，然后把找到的书摘几段拼成答案。

GraphRAG在这基础上多了一步：先把文档拆成实体和关系，构建一张知识图谱，查询时沿着图谱找关联信息，再喂给模型。

打个比方——传统RAG是"按关键词翻书"，GraphRAG是"先画一张人物关系网，再顺着网找线索"。

两种RAG的核心流程对比传统 RAG① 用户提问② 向量检索相似文本段③ 拼接文本 → 喂给LLM④ 生成回答GraphRAG① 用户提问② 知识图谱中沿关系检索关联实体 & 文本③ 拼接图谱+文本 → 喂给LLM④ 生成回答关键差异：步骤② 从"翻书"变成了"顺网找"

听起来很美好对吧？有图谱加持，信息关联更紧密，回答应该更准。

但现实没那么简单。

▎ 实测数据：GraphRAG赢在哪、输在哪

密歇根州立大学、俄勒冈大学和Meta联合发的这篇论文（arXiv:2502.11371），测了问答、摘要、多跳推理三大类任务，覆盖了Natural Questions、HotpotQA、MultiHop-RAG等多个数据集。老实说，这是目前我看过做得最扎实的一篇RAG vs GraphRAG对比。

我把最核心的数据提炼成了一张表：

问答任务 F1 分数对比（Llama 3.1-8B）方法单跳(NQ)多跳(HotpotQA)胜出场景传统 RAG64.78 ★60.04简单事实问答KG-GraphRAG50.2742.60❌ 全面落后Community-Local63.0161.66 ★多跳推理Community-Global54.4845.16宏观摘要(仅)融合方案最优最优全面场景📌 核心发现：• 单跳事实问题：传统RAG领先（64.78 vs 63.01）• 多跳推理问题：Community-Local GraphRAG胜出（61.66 vs 60.04）• KG-GraphRAG因图谱覆盖率仅65%，全面落后——实体缺失是致命伤

说几个我印象深的细节：

第一，KG-GraphRAG（纯三元组方案）惨败。只用知识图谱的三元组做检索，F1分数掉了将近15个点。原因很直接——自动构建的知识图谱实体覆盖率只有65%左右，三分之一的信息直接丢了。你指望一张残缺的地图导航，能靠谱吗？

第二，Community-Local模式是多跳推理的王者。微软GraphRAG的Local Search，先在图谱上定位相关社区（就是一群紧密关联的实体），再把社区内的文本拉出来喂给模型。这种方式在HotpotQA上拿到了61.66的F1，比传统RAG的60.04还高了1.6个点。

第三，Community-Global模式在精确问答上严重幻觉。Global Search擅长给出宏观摘要和多样视角，但在"Null查询"（答案应该是不存在的那种问题）上表现极差——模型会编出不存在的信息。论文还发现了一个更扎心的问题：微软原始GraphRAG论文声称Global优于RAG的结论，可能受了LLM评估的位置偏差影响——把两个答案换个顺序，LLM裁判就判出相反结果了。

▎ 我的实测经历：搭企业问答系统的血泪教训

说完了论文数据，聊聊我自己踩的坑。

去年我给一个做供应链管理的客户搭内部问答系统，数据源是他们的合同库、采购记录、供应商档案，大约200万条数据。

第一阶段我用了最朴素的向量RAG：Chroma做向量库，Llama 3.1-8B做生成。搭了两天就能用了，简单问题——"XX供应商的资质到期了吗""合同编号CT-2024-087的金额是多少"——答得又快又准。

但客户提了两个需求，向量RAG搞不动：

1. 跨供应商比价："A供应商和B供应商在同类物料上的报价差多少？"这要同时关联两家供应商的多个合同，向量检索捞出来的片段经常对不上号。

2. 风险传导分析："如果C供应商出了合规问题，哪些合同会受影响？"这需要顺着供应商→合同→项目→订单的关系链走，向量检索压根没这个能力。

于是第二阶段我上了GraphRAG：Neo4j存实体关系图，用微软的GraphRAG框架做社区检测和Local Search。

效果？复杂问题确实好了一截。比价类查询的准确率从不到50%提到了大约70%，风险传导分析甚至能给出完整的链路。

但代价也很明显：

• 构建图谱花了整整一周。实体抽取、关系抽取、社区检测，每个步骤都要调。200万条数据跑一遍索引构建就要好几个小时。

• 简单问题反而变慢变差了。图谱检索多了两步（定位实体→遍历关系），单个事实查询的响应时间从2秒变成了5秒，准确率也掉了几个点。因为有时候图谱压根没抽到那个实体。

• 增量更新是个噩梦。客户每天新增几百条合同，向量库加个embedding几秒钟搞定，图谱要重新跑实体抽取和社区检测……我最后搞了个"双库并行"，向量库实时更新，图谱每天凌晨批量重建。

什么时候该用哪种方案？✅ 选传统 RAG单跳事实查询："XX的金额是多少"精确细节提取：数字、日期、人名高频简单问答客服场景数据实时性要求高（分钟级更新）计算资源有限，快速上线优先数据源质量不稳定，图谱构建难✅ 选 GraphRAG多跳推理："A和B差多少""X影响了谁"跨实体比较、关联分析风险传导、合规链路追溯全局宏观摘要：覆盖整个数据集已有高质量知识图谱（本体建模好）时序类查询："事件先后顺序"

▎ 最优解：不是选一个，是两个一起用

论文里最有意思的一个发现：在MultiHop-RAG数据集上，13.6%的问题只有GraphRAG答对了，11.6%的问题只有传统RAG答对了。

这意味着什么？两种方案天生就是互补的。你选任何一种，都会丢掉另一种能答对的问题。

论文测试了两种融合策略：

Selection策略：先让LLM判断问题是"事实型"还是"推理型"，事实型走RAG，推理型走GraphRAG。提升约1.1%——聊胜于无，但分类器本身也会误判。

Integration策略：两种方案都跑一遍，把两份检索结果拼在一起喂给LLM。提升约6.4%——这才是真正有意义的提升，代价就是计算量翻倍。

我的实战方案是这样的：

我最终用的融合架构用户提问问题路由分类器简单/事实型复杂/推理型不确定向量 RAGGraphRAG双路并行LLM 生成回答

简单问题直接走向量RAG，2秒出结果；复杂问题走GraphRAG，5秒出结果但质量好；不确定的就双路并行，拼两份结果一起喂给模型。

实际跑下来，整体准确率比纯RAG高了8-10个点，比纯GraphRAG高了5-6个点，简单问题的响应时间没受影响。

唯一的问题是开发成本——你要维护两个检索通道，图谱构建和向量索引都得做。不过对于企业级应用来说，这点工作量换来10%的准确率提升，这笔账算得过来。

▎ LightRAG：轻量级GraphRAG的新选择

微软的GraphRAG框架确实重。实体抽取、社区检测、分层索引，一整套下来，200万条数据跑几个小时。

今年有个叫LightRAG的开源项目火了，思路更轻量：

• 不做社区检测，直接在图谱上用双层检索（实体级+文本级）

• 增量更新，新增数据不用重建整张图

• 构建速度比微软GraphRAG快10倍以上

我用Docker Compose在阿里百炼的Qwen模型上部署了一套LightRAG，10万条数据索引构建只用了不到20分钟，增量更新几秒钟搞定。简单问题的准确率和纯向量RAG差不多，多跳推理比微软GraphRAG稍逊一筹（毕竟没做社区检测），但省下来的时间和算力是真金白银。

如果你的场景是中等规模数据、需要实时更新、复杂问题占比不超过30%，LightRAG是目前最务实的选择。别折腾微软那套重型框架了，先用LightRAG跑起来再说。

▎ 最后给你一个选型决策清单

别被概念唬住。选方案就看这几条：

1. 你的问题类型是什么？

80%简单事实问答 → 纯向量RAG就够了

30%以上多跳推理 → 必须上GraphRAG或融合方案

2. 你的数据质量怎么样？

实体覆盖率低于70% → KG-GraphRAG大概率不如RAG

有高质量本体建模 → GraphRAG会大幅加成

3. 你的更新频率要求？

分钟级实时 → 向量RAG为主，图谱异步更新

天级/周级 → GraphRAG可以每天批量重建

4. 你的资源限制？

一个人维护、快速上线 → LightRAG或纯向量RAG

有专职团队 → 融合方案最优

5. 你有没有本体建模能力？

没有 → 纯向量RAG更安全

有 → GraphRAG会发挥你真正的优势

5分钟选型决策流程多跳推理占比 > 30%？否✅ 纯向量RAG是有本体建模能力？否⚠️ LightRAG先试是简单问题也要快？否纯GraphRAG是🏆 融合方案

▎ 互动时间

你们团队现在用的哪种RAG方案？有没有试过GraphRAG？踩过什么坑？

留言说说你的经历，我挑几个最真实的案例，下篇文章里做深度拆解。

对了，如果你正在纠结选型，把你的场景（数据量、问题类型、更新频率）发到评论区，我帮你判断该走哪条路。

▎ 关注「本体与AI」

下一篇写《5个知识图谱建模工具横评：OntoRefine vs Protégé vs Neo4j vs Stardog vs 自研》。GraphRAG好不好用，很大程度取决于你构建图谱的工具选得对不对。关注公众号，周四见。

回复"RAG选型"获取这篇提到的论文链接和我整理的选型对比表。