从 Naive RAG 到 Agentic RAG一文读懂 RAG 范式的三代演进引言很多人第一次接触 RAG检索增强生成Retrieval-Augmented Generation记住的往往只有检索 生成这五个字。但真正把 RAG 落地到生产环境之后就会发现事情远没有把知识库接到大模型上这么简单同一个问题为什么有的系统一次检索就能答对有的系统却只能胡说八道为什么有些问题根本不需要检索系统却非要查一遍知识库为什么知识库里明明没有答案系统还要硬编一个出来这些问题的背后其实指向同一个东西——RAG 的范式在演进。从 2023 年到 2026 年RAG 从一个简单的三段式流程长成了融合图结构、自反思、智能体决策的复杂系统。理解这条演进脉络比记住一堆名词更重要每种范式都在解决一个特定的痛点而痛点的递进就是演进的主线。什么是 RAG 范式范式这个词听起来很学术其实它就是指从用户提问到生成答案这条链路上各个环节的组织方式和工作逻辑。最朴素的 RAG 范式是这样的用户提问 → 向量检索 → 拼接 prompt → LLM 生成答案这套流程一两天就能跑起来大多数教程演示的都是这个形态。但一旦进入真实业务场景问题就接踵而来而不同的 RAG 范式本质上就是在回答同一个问题在检索和生成之间系统应该怎么协调、怎么决策、怎么处理各种异常情况。三代演进从打补丁到重新设计RAG 的演进大致经历了三代每一代都在上一代的痛点上演进但演进的方式越来越系统化。第一代Naive RAG。它的逻辑非常直白就是向量索引 → 近似检索 → 生成答案的三段式。但它什么都没优化检索召回什么就送什么用户提问写得差就找得差找到的内容有没有用也不管全部一股脑塞给 LLM。结果就是检索偏差比如换新误检成回收、信息碎片化甚至把相互矛盾的内容直接拼进答案。这一代的准确率大约只有 60%。第二代Advanced RAG。意识到问题之后思路是在检索前和检索后各加一道工序检索前做 Query 改写和扩展把口语化的提问打磨成更容易命中知识库的形式检索后加 Rerank 精排和内容压缩把召回内容里最相关的几条筛出来过滤掉噪音。这套方案不用改框架工程改动小、效果提升明显准确率能提到 80%因此成为目前大多数生产系统的默认形态。第三代Modular RAG。但 Advanced RAG 有一个隐含假设——流程是固定的不管用户问什么都走检索前优化 → 检索 → 检索后优化 → 生成这套流程。真实场景中不同问题需要不同策略。Modular RAG 的思路于是从打补丁转向重新架构把 RAG 的各个环节拆成可独立替换的模块像乐高一样按需组合。检索模块可以选向量检索、BM25 或图检索改写模块可以选 HyDE、Step-back 或多 Query 扩展生成模块可以是普通输出也可以是带引用的结构化输出。它具备可组合、可配置、可路由三大特性LlamaIndex 的 Workflow 和 LangGraph 都是这个设计思路的具体实现。为什么还需要高级范式很多人以为 Advanced RAG 就是终点了。其实不是。朴素 RAG 有三个更深层的痛点是流程固定这一假设本身造成的而高级范式正是针对它们给出系统性的解法检索质量参差不齐系统不区分检索结果好坏一律喂给 LLM低质量上下文直接导致幻觉。所有问题走同一套流程有些问题如11 等于几根本不需要检索强行查库毫无意义有些复杂问题又需要多轮检索才能拼出完整答案。知识库覆盖有盲区知识库里永远不可能有所有答案找不到相关内容时朴素 RAG 要么让 LLM 编造要么返回一个风马牛不相及的答案。Advanced RAG 的手段能缓解这些问题但它们有个共同假设流程是固定的只是每个环节做得更好。而复杂场景需要的是流程本身能根据情况调整——什么时候该检索、检索结果不行怎么办、需不需要再检索一次这些决策得让系统自己做。这就是 Self-RAG、CRAG、GraphRAG、Agentic RAG 登场的背景。四大高级范式Self-RAG让 LLM 自己决定要不要检索它解决的是不是所有问题都需要检索这个痛点。Self-RAG 训练了一个特殊的 LLM通过四种反射 tokenreflection token自主决策当前问题需不需要检索Retrieval token、检索结果相不相关Relevance token、生成的答案有没有幻觉Support token、最终答案质量够不够好Utility token。它的执行流程是先判断是否需要检索常识性问题直接生成→ 检索并对每个 chunk 独立评估相关性 → 基于相关 chunk 生成候选答案 → 对每个候选答案评估有没有文档支撑和对用户有没有用 → 选出最优答案。需要特别注意的前提是这四种 token 不是现成 LLM 自带的需要在专门构造的数据集上做监督微调把它们作为新词表的一部分训练进去。换句话说Self-RAG 不能拿一个通用 GPT-4 直接套用。CRAGCorrective RAG检索质量差时自动纠错降级Self-RAG 解决要不要检索CRAG 解决检索了但结果很差怎么办。它在检索之后加了一个质量评估环节做三级路由决策评估为相关直接用本地结果生成评估为不相关说明知识库没覆盖这个问题丢弃本地结果、降级走网络搜索评估为模糊把本地结果和网络搜索结果合并使用。CRAG 的核心价值在于兜底知识库覆盖不到的问题不会乱答而是自动去网上找答案。它打破了RAG 只能用本地知识库的限制把知识库当主力、网络搜索当备胎大幅提升系统健壮性。相比之下它不需要特殊微调可以在通用 LLM 上直接跑工程复杂度中等。GraphRAG用知识图谱补上全局理解的短板Self-RAG 和 CRAG 解决的都是检索策略层面的问题但还有一种瓶颈来自检索方式本身。向量检索本质上是在做一对一匹配擅长找到和问题直接相关的局部片段却无法理解整个知识库的宏观结构和跨文档的关联关系。像这批文档的核心主题是什么A 公司和 B 公司之间有什么关联这类全局性问题纯向量检索力不从心。GraphRAG 是微软在 2024 年 7 月发布的方案核心价值在于系统化组合而非单点发明预处理阶段先用 LLM 抽取实体和关系构建知识图谱再用 Leiden 等社区发现算法把紧密关联的实体聚类成社区对每个社区生成一份 LLM 摘要形成多层次的摘要结构检索阶段则支持局部查询实体查找、关系遍历和全局查询基于社区摘要做 Map-Reduce。代价是构建图谱和摘要需要大量 LLM 调用预处理成本较高。Agentic RAG把 RAG 做成 Agent前面几种范式虽然各有创新但流程步骤仍是预先定义好的最多按条件做分支。可有些问题复杂到连需要检索几次、每次检索什么都无法预先定义。Agentic RAG 把 RAG 嵌入 Agent 循环让 LLM 在运行时自主决定要不要再检索一次、用什么关键词检索、检索结果是否足够、什么时候可以生成最终答案。它的执行流程是接收问题进入决策循环 → LLM 判断信息够了吗不够就搜什么 → 执行检索并累积上下文 → 重复判断直到信息充分 → 生成最终答案用最大迭代次数兜底防死循环。这套机制特别适合需要多步推理的复杂问题比如分析某公司近三年财报找出营收增速放缓的根本原因。如果说 Self-RAG 是加了一个要不要检索的开关CRAG 是加了一个检索不好怎么办的兜底那 Agentic RAG 就是把整个检索流程变成一个可以不断循环、不断调整的智能体。一张表看懂范式对比与选型范式核心机制解决痛点适合场景工程复杂度Naive RAG检索一次 生成一次—起点演示、原型极低Advanced RAGQuery 改写 Rerank检索质量低大多数生产场景低Modular RAG模块化可组合流程固定死板多业务、需灵活编排中Self-RAG反射 token 自主决策不该检索也检索问题类型多样高需特殊微调CRAG质量评估 降级搜索知识库覆盖不全覆盖有盲区的客服/问答中GraphRAG社区发现 层次摘要全局理解与跨文档关联实体关系复杂的领域高图构建成本大Agentic RAGAgent 多轮动态检索复杂多步问题深度研究、多跳推理中Agent 框架选型的关键不是追求最新最复杂而是看你要解决的是哪类问题。大多数场景用 Advanced RAG 就够了知识库覆盖不全就上 CRAG问题类型混杂、部分无需检索再考虑 Self-RAG涉及大量实体关系与全局归纳时才值得付 GraphRAG 的预处理成本而只有当问题本身需要多步、跨源、动态探索时Agentic RAG 的价值才会真正体现出来。结语回到最初的问题RAG 为什么一直在演进因为检索和生成之间有太多需要系统自己拿主意的时刻——要不要检索、检索得靠不靠谱、需不需要再查一次、散落的知识怎么串起来。Naive RAG 把这一切交给了写死的流程而后来的每一种范式都是在把其中一环的决策权交还给系统。理解了这一点再看那些层出不穷的名词就不再是背题而是看清了一连串问题与解法的对应关系。 从 Naive RAG 到 Agentic RAG：一文读懂 RAG 范式的三代演进
从 Naive RAG 到 Agentic RAG一文读懂 RAG 范式的三代演进引言很多人第一次接触 RAG检索增强生成Retrieval-Augmented Generation记住的往往只有检索 生成这五个字。但真正把 RAG 落地到生产环境之后就会发现事情远没有把知识库接到大模型上这么简单同一个问题为什么有的系统一次检索就能答对有的系统却只能胡说八道为什么有些问题根本不需要检索系统却非要查一遍知识库为什么知识库里明明没有答案系统还要硬编一个出来这些问题的背后其实指向同一个东西——RAG 的范式在演进。从 2023 年到 2026 年RAG 从一个简单的三段式流程长成了融合图结构、自反思、智能体决策的复杂系统。理解这条演进脉络比记住一堆名词更重要每种范式都在解决一个特定的痛点而痛点的递进就是演进的主线。什么是 RAG 范式范式这个词听起来很学术其实它就是指从用户提问到生成答案这条链路上各个环节的组织方式和工作逻辑。最朴素的 RAG 范式是这样的用户提问 → 向量检索 → 拼接 prompt → LLM 生成答案这套流程一两天就能跑起来大多数教程演示的都是这个形态。但一旦进入真实业务场景问题就接踵而来而不同的 RAG 范式本质上就是在回答同一个问题在检索和生成之间系统应该怎么协调、怎么决策、怎么处理各种异常情况。三代演进从打补丁到重新设计RAG 的演进大致经历了三代每一代都在上一代的痛点上演进但演进的方式越来越系统化。第一代Naive RAG。它的逻辑非常直白就是向量索引 → 近似检索 → 生成答案的三段式。但它什么都没优化检索召回什么就送什么用户提问写得差就找得差找到的内容有没有用也不管全部一股脑塞给 LLM。结果就是检索偏差比如换新误检成回收、信息碎片化甚至把相互矛盾的内容直接拼进答案。这一代的准确率大约只有 60%。第二代Advanced RAG。意识到问题之后思路是在检索前和检索后各加一道工序检索前做 Query 改写和扩展把口语化的提问打磨成更容易命中知识库的形式检索后加 Rerank 精排和内容压缩把召回内容里最相关的几条筛出来过滤掉噪音。这套方案不用改框架工程改动小、效果提升明显准确率能提到 80%因此成为目前大多数生产系统的默认形态。第三代Modular RAG。但 Advanced RAG 有一个隐含假设——流程是固定的不管用户问什么都走检索前优化 → 检索 → 检索后优化 → 生成这套流程。真实场景中不同问题需要不同策略。Modular RAG 的思路于是从打补丁转向重新架构把 RAG 的各个环节拆成可独立替换的模块像乐高一样按需组合。检索模块可以选向量检索、BM25 或图检索改写模块可以选 HyDE、Step-back 或多 Query 扩展生成模块可以是普通输出也可以是带引用的结构化输出。它具备可组合、可配置、可路由三大特性LlamaIndex 的 Workflow 和 LangGraph 都是这个设计思路的具体实现。为什么还需要高级范式很多人以为 Advanced RAG 就是终点了。其实不是。朴素 RAG 有三个更深层的痛点是流程固定这一假设本身造成的而高级范式正是针对它们给出系统性的解法检索质量参差不齐系统不区分检索结果好坏一律喂给 LLM低质量上下文直接导致幻觉。所有问题走同一套流程有些问题如11 等于几根本不需要检索强行查库毫无意义有些复杂问题又需要多轮检索才能拼出完整答案。知识库覆盖有盲区知识库里永远不可能有所有答案找不到相关内容时朴素 RAG 要么让 LLM 编造要么返回一个风马牛不相及的答案。Advanced RAG 的手段能缓解这些问题但它们有个共同假设流程是固定的只是每个环节做得更好。而复杂场景需要的是流程本身能根据情况调整——什么时候该检索、检索结果不行怎么办、需不需要再检索一次这些决策得让系统自己做。这就是 Self-RAG、CRAG、GraphRAG、Agentic RAG 登场的背景。四大高级范式Self-RAG让 LLM 自己决定要不要检索它解决的是不是所有问题都需要检索这个痛点。Self-RAG 训练了一个特殊的 LLM通过四种反射 tokenreflection token自主决策当前问题需不需要检索Retrieval token、检索结果相不相关Relevance token、生成的答案有没有幻觉Support token、最终答案质量够不够好Utility token。它的执行流程是先判断是否需要检索常识性问题直接生成→ 检索并对每个 chunk 独立评估相关性 → 基于相关 chunk 生成候选答案 → 对每个候选答案评估有没有文档支撑和对用户有没有用 → 选出最优答案。需要特别注意的前提是这四种 token 不是现成 LLM 自带的需要在专门构造的数据集上做监督微调把它们作为新词表的一部分训练进去。换句话说Self-RAG 不能拿一个通用 GPT-4 直接套用。CRAGCorrective RAG检索质量差时自动纠错降级Self-RAG 解决要不要检索CRAG 解决检索了但结果很差怎么办。它在检索之后加了一个质量评估环节做三级路由决策评估为相关直接用本地结果生成评估为不相关说明知识库没覆盖这个问题丢弃本地结果、降级走网络搜索评估为模糊把本地结果和网络搜索结果合并使用。CRAG 的核心价值在于兜底知识库覆盖不到的问题不会乱答而是自动去网上找答案。它打破了RAG 只能用本地知识库的限制把知识库当主力、网络搜索当备胎大幅提升系统健壮性。相比之下它不需要特殊微调可以在通用 LLM 上直接跑工程复杂度中等。GraphRAG用知识图谱补上全局理解的短板Self-RAG 和 CRAG 解决的都是检索策略层面的问题但还有一种瓶颈来自检索方式本身。向量检索本质上是在做一对一匹配擅长找到和问题直接相关的局部片段却无法理解整个知识库的宏观结构和跨文档的关联关系。像这批文档的核心主题是什么A 公司和 B 公司之间有什么关联这类全局性问题纯向量检索力不从心。GraphRAG 是微软在 2024 年 7 月发布的方案核心价值在于系统化组合而非单点发明预处理阶段先用 LLM 抽取实体和关系构建知识图谱再用 Leiden 等社区发现算法把紧密关联的实体聚类成社区对每个社区生成一份 LLM 摘要形成多层次的摘要结构检索阶段则支持局部查询实体查找、关系遍历和全局查询基于社区摘要做 Map-Reduce。代价是构建图谱和摘要需要大量 LLM 调用预处理成本较高。Agentic RAG把 RAG 做成 Agent前面几种范式虽然各有创新但流程步骤仍是预先定义好的最多按条件做分支。可有些问题复杂到连需要检索几次、每次检索什么都无法预先定义。Agentic RAG 把 RAG 嵌入 Agent 循环让 LLM 在运行时自主决定要不要再检索一次、用什么关键词检索、检索结果是否足够、什么时候可以生成最终答案。它的执行流程是接收问题进入决策循环 → LLM 判断信息够了吗不够就搜什么 → 执行检索并累积上下文 → 重复判断直到信息充分 → 生成最终答案用最大迭代次数兜底防死循环。这套机制特别适合需要多步推理的复杂问题比如分析某公司近三年财报找出营收增速放缓的根本原因。如果说 Self-RAG 是加了一个要不要检索的开关CRAG 是加了一个检索不好怎么办的兜底那 Agentic RAG 就是把整个检索流程变成一个可以不断循环、不断调整的智能体。一张表看懂范式对比与选型范式核心机制解决痛点适合场景工程复杂度Naive RAG检索一次 生成一次—起点演示、原型极低Advanced RAGQuery 改写 Rerank检索质量低大多数生产场景低Modular RAG模块化可组合流程固定死板多业务、需灵活编排中Self-RAG反射 token 自主决策不该检索也检索问题类型多样高需特殊微调CRAG质量评估 降级搜索知识库覆盖不全覆盖有盲区的客服/问答中GraphRAG社区发现 层次摘要全局理解与跨文档关联实体关系复杂的领域高图构建成本大Agentic RAGAgent 多轮动态检索复杂多步问题深度研究、多跳推理中Agent 框架选型的关键不是追求最新最复杂而是看你要解决的是哪类问题。大多数场景用 Advanced RAG 就够了知识库覆盖不全就上 CRAG问题类型混杂、部分无需检索再考虑 Self-RAG涉及大量实体关系与全局归纳时才值得付 GraphRAG 的预处理成本而只有当问题本身需要多步、跨源、动态探索时Agentic RAG 的价值才会真正体现出来。结语回到最初的问题RAG 为什么一直在演进因为检索和生成之间有太多需要系统自己拿主意的时刻——要不要检索、检索得靠不靠谱、需不需要再查一次、散落的知识怎么串起来。Naive RAG 把这一切交给了写死的流程而后来的每一种范式都是在把其中一环的决策权交还给系统。理解了这一点再看那些层出不穷的名词就不再是背题而是看清了一连串问题与解法的对应关系。