GraphRAG、RAFT、Agent RAG——程序员转型AI，到底该先学哪个？

这是「程序员的 RAG 修炼手册」系列第三篇。第一篇聊了 RAG 是什么，第二篇聊了怎么优化，这一篇聊聊怎么选。

最近半年，我的技术收藏夹里积压了一堆没消化完的文章。

今天 GraphRAG 发了新论文，明天 RAFT 刷屏，后天某个大厂开源了一个 RAG Agent 框架，大后天又有人说“RAG 已死，长上下文才是未来”。每一篇都写得头头是道，每一篇都让你觉得“这个我得学”。

然后呢？收藏之，压箱底。或者看了个开头，觉得“等我把基础打好再来看这个”。再然后，基础还没打完，新的东西又出来了。

这种焦虑我太熟悉了。它和当年做技术选型时的感觉一模一样——Spring 还是 Django？MySQL 还是 MongoDB？微服务还是单体？每个选择背后都有很多人在布道，每个方案都有成功案例，但一个人的时间精力是有限的。

选错可能不会有多夸张严重的后果，但可能会浪费三个月时间。而三个月对于一个想抓住某些例如 AI 的窗口期的程序员来说，大概是个奢侈品。

所以今天我想做一件事：把目前主流的 RAG 进阶方案摆在一起，用产品思维里“场景匹配”的逻辑，帮你做一次技术选型。不是告诉你哪个最好——没有最好的技术，只有最匹配的技术。

先搞清楚：基线 RAG 的能力边界在哪

在聊进阶方案之前，得先搞清楚一个问题：基线 RAG（就是上两篇文章里聊的那套标准流程）到底在哪些场景下会力不从心？

因为如果基线 RAG 够用，你根本不需要折腾进阶方案。过度工程化和技术不足一样，都是病。

基线 RAG 的核心逻辑是：用向量相似度找到最相关的几个文本片段，拼给大模型回答。这套逻辑在处理“单点问题”时表现很好——用户问一个具体的事实性问题，知识库里有对应的段落，检索到了就能答好。

但它有两个明显的短板：

第一，连接各个要点的能力弱。如果回答一个问题需要把散落在不同文档、不同段落里的信息串起来，基线 RAG 很容易只检索到其中一部分，给出一个不完整的答案。因为它是按相似度独立打分的，不理解信息之间的关联关系。

第二，全局理解能力弱。如果你问的是一个需要对整个知识库有宏观理解的问题——比如“这批研究报告的整体趋势是什么”“这个项目的所有风险点有哪些”——基线 RAG 会很吃力。因为它只能检索到局部片段，无法形成全局视角。

搞清楚了这两个短板，后面的进阶方案就好理解了——它们各自在解决不同的问题。

GraphRAG：当你需要“全局理解”和“关联推理”

GraphRAG 是微软提出的一种结构化 RAG 方法。它和基线 RAG 最大的区别是：不再把知识库当作一堆独立的文本片段来检索，而是先把文本转化成一张知识图谱，再基于图谱的结构来回答问题。

它到底做了什么

GraphRAG 的处理流程分两大阶段：

索引阶段（离线处理，提前做好）：

首先，把文档切成文本单元（TextUnits），这一步和基线 RAG 类似。

然后，用大模型从每个文本单元中提取实体（人、地点、组织、概念等）和它们之间的关系。比如从一段文字里提取出“张三-就职于-A 公司”“A 公司-位于-北京”这样的结构化信息。

接着，把所有实体和关系构建成一张知识图谱。用 Leiden 算法对图谱做层次聚类——简单说就是把关系紧密的实体归为一个“社区”，社区之间再形成更大的社区，层层嵌套。

最后，为每个社区生成摘要。这些摘要描述了“这个社区里有哪些实体、它们之间是什么关系、整体在讲什么事”。

查询阶段（在线处理，用户提问时）：

GraphRAG 提供两种查询模式：

全局查询（Global Query）：用于回答宏观问题。它不是去检索具体的文本片段，而是利用社区摘要来回答。具体实现类似 Map-Reduce——把社区报告分成若干块，每块生成中间响应并打分，然后从中挑选最重要的点汇聚成最终答案。越宏观的问题，用越高层级的社区摘要来回答。

本地查询（Local Query）：用于回答具体问题。先从知识图谱中找到和问题语义相关的实体，然后沿着这些实体的关联关系，把相关的文本单元、社区报告、关系描述都拉出来，组装成上下文给大模型。

什么时候该用它

用产品思维的“场景匹配”来判断：

适合用 GraphRAG 的场景：

你的知识库涉及大量实体之间的复杂关系（比如企业组织架构、人物关系网络、技术架构依赖关系）
用户经常问需要跨文档汇总的宏观问题（“这个领域的整体趋势是什么”“所有相关的风险因素有哪些”）
你需要对一个大型知识库形成结构化的全局理解

不需要 GraphRAG 的场景：

单文档问答，问题都是针对具体段落的事实性查询
知识库规模不大，基线 RAG 的召回率已经够用
对实时性要求高——GraphRAG 的索引构建需要大量 LLM 调用，成本和时间都不低

一句话总结：如果你的问题需要“连点成线”或者“鸟瞰全局”，GraphRAG 值得投入；如果只是“找到那个点”，基线 RAG 够了。

RAFT：当你需要在特定领域做到极致准确

RAFT 的全称是 Retrieval Augmented Fine Tuning——检索增强微调。它不是一种独立的 RAG 方案，而是把 RAG 和微调结合起来的训练方法。

它在解决什么问题

用一个考试的类比来理解：

基线 RAG 相当于开卷考试——考试的时候允许你翻书（检索知识库），但你之前从来没有练过“怎么在一堆资料里快速找到正确答案”这件事。资料摆在面前，你可能翻半天找不到重点，或者被无关信息干扰。

RAFT 相当于在开卷考试之前，用真题反复训练过。而且训练的时候，题目里故意混入了干扰项——有些参考资料是相关的，有些是故意放进来迷惑你的。训练的目标是让你学会：在一堆资料中快速识别哪些有用、哪些是噪音，只关注和引用真正相关的内容。

具体来说，RAFT 的训练方式是：给模型一个问题，同时给它一组文档，其中包含正确答案所在的文档（正面文档）和若干干扰文档。让模型学会在这种“有噪音的开卷”环境下，依然能准确找到答案并给出引用。

成本现实

说完原理，得说说现实。

RAFT 本质上是一种微调方法，意味着你需要：训练数据（通常需要大量高质量的问答对）、算力资源（参考数据：90万数据集，8张 H800显卡，单个 epoch 训练32小时，完整训练4-6个 epoch 需要约7天）、以及工程能力（数据准备、训练流程、效果评估）。

这不是一个周末能搞定的事情，也不是个人开发者随便就能玩的。90万的训练数据通常是从真实业务场景的全量数据（可能有900万条）中筛选出来的优质样本。

什么时候该考虑它

适合 RAFT 的场景：

你有一个特定的垂直领域，对回答准确性要求极高（比如医疗、法律、金融）
你有足够的领域数据可以用来构建训练集
你的团队有微调的工程能力和算力资源
基线 RAG 在你的场景下效果已经到了瓶颈，常规优化手段用尽了

不适合 RAFT 的场景：

知识库更新频繁（每次更新都要重新训练，成本太高）
数据量不够大，构建不了高质量训练集
个人开发者或小团队，算力和工程资源有限
基线 RAG+优化还有很大提升空间没挖掘

但即使你暂时用不上 RAFT，理解它的思路也有价值。它告诉我们一个重要的设计理念：RAG 不只是推理时的检索策略，也可以在训练阶段就把“如何利用检索结果”这个能力内化到模型里。这个思路对你设计 RAG 系统的整体架构是有启发的。

Qwen-Agent 的三级 RAG：从检索到推理的渐进式方案

前面两个方案一个偏重结构化理解（GraphRAG），一个偏重训练增强（RAFT），都有一定的门槛。Qwen-Agent 提供了一个更工程化、更容易上手的渐进式方案。

它的核心思想是：RAG 不是一个固定的方案，而是可以按问题复杂度分级的工程策略。简单问题用简单方案，复杂问题才上复杂架构。

三个复杂度级别

Level 1：纯检索

最朴素的方式。把长文档切成不超过512字的块，用关键词检索（BM25）找到最相关的块，塞进8K 的上下文窗口里回答。

Qwen-Agent 在这一层做了一个有意思的优化：不是直接拿用户的原始问题去检索，而是先让模型把问题中的“指令部分”和“信息部分”分开，然后从信息部分推导出多语言关键词，再用这些关键词去做 BM25检索。

这一步虽然简单，但解决了一个实际问题：用户的提问往往混杂着指令（“帮我总结一下”“用表格形式列出来”）和真正需要检索的信息，分开处理后检索精度会提升。

Level 2：分块阅读

Level 1的问题是：关键词检索依赖于用户问题和文档内容的词汇重叠。如果相关内容用了完全不同的表述，关键词检索就会失效。向量检索理论上能缓解这个问题，但实际效果有限。

Level 2的解法比较“暴力”但有效：对每个512字的块，让模型判断它和用户问题是否相关。如果不相关，输出“无”；如果相关，输出相关的句子。所有块并行处理，不用等。

然后，把那些非“无”的输出（即相关句子）作为新的搜索词，再用 BM25检索一轮，最终结果控制在8K 上下文内，生成答案。

这相当于让模型先“通读”了一遍所有内容，标记出相关的部分，再基于标记结果做精准检索。代价是调用次数多（每个块都要调一次），但因为可以并发，总耗时可控。

Level 3：逐步推理

Level 2能处理大多数问题，但对于需要多跳推理的问题（答案需要从 A 推到 B 再推到 C），单次检索+生成不够用。

Level 3的做法是：把 Level 2的能力封装成一个“工具”，然后用一个具备规划能力的 Agent 来调用它。Agent 的工作流程是：

收到用户的原始问题
判断自己能不能直接回答
如果不能，拆解出一个子问题，调用 Level 2去回答
把子问题的答案存入记忆
基于已有记忆，判断能不能回答原始问题
如果还不能，继续拆解下一个子问题，循环往复
直到能够回答原始问题为止

这就是经典的 ReAct Agent 模式——规划、执行、观察、再规划。只不过这里执行的“工具”是一个 RAG 检索系统。

为什么这个设计思路值得学

Qwen-Agent 的三级设计给了我一个很重要的启发：不要一上来就用最复杂的方案。

Level 1能解决的问题，就不要上 Level 2；Level 2能解决的问题，就不要上 Level 3。每升一级，复杂度和成本都在增加。工程化的核心不是用最先进的技术，而是用最匹配的技术。

这和我们做后端架构的原则一样——能用单机解决的不要上分布式，能用缓存解决的不要改数据库，能用简单方案解决的不要过度设计。

另外，Qwen-Agent 作为一个开箱即用的框架，对于想快速验证 RAG 效果的开发者来说是个不错的选择。它内置了多种召回方式，做过工程优化，不需要你从零搭建整套检索链路。

我的选型建议：先看场景，再选方案

说了这么多，最后给一个实操的选型参考。

单文件简单问答：基线 RAG 就够了，甚至直接用 DeepSeek 等大模型的长上下文能力提问就行。不需要额外搭建什么系统。

多文件交互、需要跨文档检索：Qwen-Agent 是一个好的起点，它帮你处理了很多工程细节。或者自己用向量数据库（比如 Faiss）+ 检索链路搭建，灵活度更高但工作量也更大。

跨文档关联推理、需要全局理解：GraphRAG。当你的知识库里实体关系复杂、用户问题经常需要“连点成线”时，图谱的结构化优势会显现出来。

垂直领域、对准确性要求极高：RAFT + RAG。前提是你有足够的数据和算力。如果暂时不具备条件，先把基线 RAG 的优化做到极致（参考上一篇文章），效果也不会差。

不确定该用哪个：从基线 RAG 开始，遇到具体的瓶颈再升级。不要预设复杂度。

用一句话总结这整篇文章的核心观点：先明确你的场景，再选技术方案。别被技术名词绑架。

写在最后

RAG 不是一种技术，是一棵技术树。

树干是“检索+生成”的基本范式——这个在第一篇文章里已经讲清楚了。树枝是各种针对不同场景的优化方案——第二篇讲了怎么把每根树枝修剪得更好。今天这篇讲的是：这棵树上有哪些主要的分叉，应该沿着哪根枝干往上爬。

不需要爬遍每根树枝。只需要找到通往你业务场景的那一根，然后深扎下去。

作为程序员，我们的核心能力从来不是“什么都会”，而是“在复杂系统中做正确的技术选型”。AI 时代这个能力没有变，只是选型的对象从 Web 框架变成了模型，从关系型数据库变成了向量库，从设计模式变成了 RAG 策略。

底层能力是通用的。变的只是应用的领域。

所以我的最终建议是：选一个方向，花两周时间深入进去，搭一个能跑的东西出来。这比泛泛了解十种方案、收藏一百篇文章更有用。

学完就用，用了就有反馈，有反馈就知道下一步该学什么。这个循环一旦转起来，焦虑自然就消失了。

这是「程序员的 RAG 修炼手册」系列第三篇（完结）。

第一篇：我学RAG踩的第一个坑，可能你也在踩——RAG 是什么、解决什么问题

第二篇：RAG效果差？一张优化全景图，从demo到生产级的完整路径——怎么把 RAG 做好

第三篇：本篇——进阶方案怎么选

文章目录