GraphRAG 正在改变检索增强生成：当知识图谱遇上 LLM

传统 RAG 有一个致命缺陷：它能回答"点"的问题，回答不了"面"的问题。

你问"这个微服务的 QPS 上限是多少？"——传统 RAG 轻松搞定。你问"这个系统经历过哪些重大架构变更？"——传统 RAG 直接跪了。因为答案不在任何一个文档片段里，而是分散在几十个文档中。

微软 2 月发布的 GraphRAG 试图解决这个问题。四个月过去了，这个方向的关注度不降反升。我也在项目里试了一下。

核心思路

传统 RAG：切文档 → 向量化 → 检索 → 喂给 LLM

GraphRAG 多了一步：在向量检索之前，先用 LLM 从文档中提取实体和关系，构建一个知识图谱。然后在这个图上做社区发现（Community Detection），为每个"社区"（一组紧密关联的实体）生成摘要。

当用户问一个需要全局理解的问题时，系统返回的不是碎片化的文档片段，而是社区摘要 + 相关关系。这让 LLM 能看到"森林"而不只是"树木"。

打个比方：传统 RAG 像是一个帮你从图书馆找书的管理员。GraphRAG 像是一个读过所有书之后给你写读书笔记的研究助理。

我自己做了一个小规模测试：

传统 RAG 准确率：53%。GraphRAG：87%。

差距最大的场景是"这个系统的服务间调用关系是怎样的？"——GraphRAG 直接从图结构中推导，不需要检索。

GraphRAG 不是免费午餐： - 构建成本：200 页文档用了约 50 万 token 做实体提取和社区摘要 - 延迟：双层检索比纯向量检索慢 2-3 倍 - 运维：图数据库（Neo4j 或类似）增加了复杂度

GraphRAG 和传统 RAG 不是替代关系，是互补关系。80% 的用户 query 用传统 RAG 就够了。但那 20% 需要跨文档推理的问题——正是最能体现 AI 价值的场景。

如果你在做的是一个真正要理解组织知识体系的系统（而不是 FAQ 客服机器人），GraphRAG 值得认真考虑。四个月前它是论文，现在它是可用的工程方案。

有时候技术的进步不是"更快更好"，而是"能做以前做不了的事"。GraphRAG 属于这一类。

参考来源：