最近在折腾 RAG 相关的东西，发现一个挺有意思的现象——传统 RAG 在处理某些问题时简直就是"智商掉线"。
举个具体的例子。我拿《三体》第一部做了个测试（注：选第一部是因为它够短、人物关系也相对简单，方便验证想法，不想被后面那两部复杂的剧情搞晕）：
问它"叶文洁是怎么联系上三体文明的？"，传统 RAG 毫无压力，直接就给你翻到"红岸基地"、"发射信号"这些段落。
但换个问法："ETO 组织到底是怎么搞起来的？里面的人都是什么关系？"，它就抓瞎了。
为啥会这样？说白了，传统 RAG 就像个只会"关键词搜索"的愣头青，它能找到单独的段落，但把这些段落拼不起来。它看不到 A 段落里的叶文洁和 B 段落里的伊文斯其实是一伙的，更理解不了这帮人怎么就搞出了一个全球性的地下组织。
这就是所谓的"见木不见林"。
一、GraphRAG 怎么解决这事儿？
2024 年初，微软研究院扔出来一篇论文《From Local to Global: A Graph RAG Approach to Query-Focused Summarization》，提出了一个叫 GraphRAG 的方案。
核心思想其实挺直白：不用向量相似度去找"相似的片段"，而是先把文档里的实体和关系都抽出来，建成一个知识图谱。然后呢，用 Leiden 算法在这个图谱上找"社区"——就是那些关系特别紧密的一群节点。最后，给每个社区生成一份摘要，让查询的时候能既看到细节又看到全局。
还是那句老话：传统 RAG 是在"翻书找词"，GraphRAG 是在"织网捕鱼"。
二、传统 RAG 到底输在哪？
先看看传统 RAG 是怎么干活的，代码层面其实就那几步：
1. 文档切成小块，500-1000 字一个 chunk 2. 用 Embedding 模型把 chunk 变成向量 3. 向量存数据库 4. 查询时把问题也转成向量，找最相似的几个 chunk 5. 扔给 LLM 生成答案
这套流程有个致命伤：它根本不理解"关系"。
你问"叶文洁和汪淼有啥关系？"，它大概率会给你两段独立的内容——一段讲叶文洁是谁，一段讲汪淼是谁。但实际上这俩人的关系是通过 ETO 事件串联起来的，这个信息可能分散在好几个不同的章节里，向量检索根本抓不住。
更别提那些跨越整个故事线的问题了，比如"ETO 是怎么从红岸基地的一个小项目变成全球组织的？"——这种问题需要你理解时间线、人物关系、事件因果，传统 RAG 完全搞不定。
三、GraphRAG 的三板斧
GraphRAG 的做法不太一样，它分三个阶段：
第一斧：把文本变成图谱
这个阶段不是简单切 chunk，而是让 LLM 把每个内容块都嚼碎了，提取出两样东西：
• 实体：人物、地点、组织、事件这些关键节点 • 关系：这些节点之间怎么连着的
比如原文是"叶文洁收到红岸基地的信号后，向三体世界发射了回复信号"，提取完就变成了：
• (叶文洁) --[收到信号]--> (红岸基地) • (叶文洁) --[发射信号]--> (三体世界)
整个文档跑一遍，你就得到一个完整的知识图谱。拿《三体》第一部来说，最后能出来几十个节点、上百条关系边。
第二斧：用算法找社区
图谱建好了，接下来就该 Leiden 算法登场了。它的作用是在这个关系网里自动发现"社区"——那些关系特别紧密的一群节点。
在《三体》第一部里，Leiden 算法可能会找到这么几个社区：
• 红岸基地那帮人（叶文洁、雷志成、杨卫宁） • ETO 核心层（叶文洁、伊文斯、申玉菲） • 被卷进来的科学家（汪淼、史强、丁仪） • 三体游戏里的角色（汪淼、周文王、牛顿、墨子）
最关键的是，LLM 会给每个社区生成一份"摘要"。这玩意儿特别有用，相当于把整个关系网络压缩成了几个可理解的知识单元。比如红岸基地社区的摘要可能是"以叶文洁为核心，包括雷志成、杨卫宁等人，是发现外星文明信号的起点"。
第三斧：两种查询模式
有了社区摘要，GraphRAG 就能玩出两种查询方式：
局部模式：从问题里的实体出发，顺藤摸瓜。适合问"叶文洁和伊文斯怎么认识的？"这种具体的关系。
全局模式：把所有相关的社区摘要都捞出来，拼在一起看全局。适合问"ETO 的最终目标是什么？"这种宏观问题。
这个设计挺巧妙的——既保留了微观的细节追踪能力，又有了宏观的全局视角。
四、技术角度对比一下
一句话总结：向量检索是"找相似的"，图谱检索是"找关联的"。
五、实战用 RAGFlow 跑个 GraphRAG
理论扯完了，来点实际的。市面上支持 GraphRAG 的工具不少，我用 RAGFlow 演示一下，主要是它有可视化界面，上手快。
RAGFlow 是个开源的 RAG 引擎，从文档解析到知识检索全流程都覆盖到了。最新版本里已经内置了 GraphRAG 组件，配置起来也不复杂。
假设你手头有《三体》第一部的文本文件，想搞个知识库来回答那些复杂问题，大概流程是这样的：
上传文档
先在 RAGFlow 里建个知识库，把文本文件传上去（注：我还是用第一部，篇幅适中、人物关系清晰，方便验证效果）。
配置 GraphRAG
在工作流里加个 GraphRAG 组件，主要配置几项：
• 用哪个 LLM 做实体提取（GPT-4、DeepSeek 都行） • 关系提取关注哪些类型（人物关系、组织关系、事件关系） • 社区检测用 Leiden 算法，社区规模阈值设多大 • 每个社区的摘要写多长
跑构建
点运行，RAGFlow 会自动完成：
1. 用 LLM 抽取所有实体和关系 2. 构建知识图谱 3. Leiden 算法找社区 4. 给每个社区生成摘要
这个过程耗时不好说，取决于文档大小和 LLM 的速度。
测试一下
构建完成后，试试这几个问题：
问"叶文洁和伊文斯是什么关系？"
GraphRAG 会定位到"叶文洁"这个节点，然后顺着关系网络摸过去——ETO 组织、他们的相遇过程、共同创立组织的历史。最终给出的答案大概是这样的：两人通过"审判日"邮件列表认识，一起搞了个地球三体组织（ETO），伊文斯出钱，叶文洁出与三体文明的关系。
问"ETO 的最终目标是什么？"
GraphRAG 会把红岸基地社区、ETO 核心社区的摘要都捞出来，整合分析一下。答案大概是这样的：ETO 的目标是帮三体文明占领地球、消灭人类文明，他们认为人类自己解决不了环境问题。
拿同样的问题问传统 RAG，它可能找到一些片段，但很难拼出这么完整的逻辑链。
六、几个主流工具对比
微软官方 GraphRAG
微软发论文的时候顺便开源了 Python 实现 microsoft/graphrag。
优点是开箱即用、文档齐全，支持局部和全局两种查询模式，内置了各种 LLM 的接口。装起来也简单，一行 pip install graphrag 搞定。
LlamaIndex
LlamaIndex 有个 KnowledgeGraphIndex，可以比较轻量地集成到现有 RAG 流程里。支持多种图数据库后端，和现有流程结合起来比较顺滑。
LangChain
LangChain 通过 GraphCypherQA 这些组件，可以和 Neo4j 之类的图数据库集成。架构设计比较灵活，支持多种图数据库，Cypher 查询也很方便。
RAGFlow
RAGFlow 是国产化的方案，内置了 GraphRAG 支持。优势在于可视化工作流配置，零代码/低代码就能用，部署起来也比较简单。
七、代价和取舍
没啥技术是银弹，GraphRAG 也不例外。上这个技术之前，得先算算账。
成本这块
Token 消耗会明显增加。构建索引的时候，得用 LLM 把所有文档都理解一遍，把实体和关系都抽出来。Token 消耗大概是普通 RAG 的 20-50 倍。
拿《三体》第一部（大概 20 万字）来说：
• 传统 RAG：20 万 tokens 左右用于嵌入 • GraphRAG：400-1000 万 tokens（包括提取和摘要）
计算资源方面，LLM 调用成本肯定要高不少。Leiden 算法倒是不怎么耗 GPU，但图谱得存在内存里。
性能考量
构建时间差距挺大：
• 传统 RAG：几分钟到几十分钟（看文档大小） • GraphRAG：几小时到几十小时（得等 LLM 慢慢处理）
查询速度：
• 传统 RAG：几百毫秒 • GraphRAG 局部模式：几百毫秒 • GraphRAG 全局模式：几秒钟（得整合社区摘要）
准确性这块，简单问题（事实检索）两者差不多，但复杂问题（关系分析、全局总结）GraphRAG 明显更强。
啥时候用 GraphRAG
适合用的场景：
• 复杂关系分析（人物关系、组织结构、事件脉络） • 全局性总结（财报风险分析、竞争格局分析） • 需要多跳推理的查询 • 知识库本身关系密集（小说、法律文书这种）
不适合用的场景：
• 简单客服问答（查快递、查政策） • 文档量很小（直接上 LLM 就够了） • 预算有限、对延迟敏感 • 知识库关系稀疏（技术文档）
一句话建议：真需要"全局理解"的时候再上 GraphRAG，别拿牛刀杀鸡。
八、总结
GraphRAG 算是 RAG 技术演进里挺重要的一步——它让 AI 从"翻书找词"进化到了"全知视角"。通过知识图谱、社区发现、全局摘要这些手段，它能回答传统 RAG 搞不定的宏观问题。
但这个能力是有代价的——成本更高、构建更慢。关键在于选对场景，当你的问题真的需要"既见木又见林"的时候，GraphRAG 才值得投入。
未来几个方向挺值得关注：更高效的实体提取（减少 LLM 调用）、增量更新（动态更新知识图谱）、和智能体结合（GraphRAG + Agentic RAG）、多模态扩展（从文本到图像视频的关系理解）。
