2026 年初，一场关于 RAG 的争论在技术圈炸开了锅。导火索是斯坦福一个团队的研究——他们发现，用合成数据微调的小模型，在垂直领域的问答准确率上反超了 RAG 方案，而且成本更低。一时间，“RAG 神话破灭”"检索增强已死"的标题铺满了公众号。

但在另一边，企业级 AI 应用的落地现实却是另一幅图景：Dify 的 RAG 流水线被嵌入了成千上万的生产系统，Microsoft 的 GraphRAG 在 GitHub 上收获了数万 Star，Agentic RAG 成为 2026 年 AI Agent 技术栈中最热门的关键词之一。

这两种叙事之间的矛盾，说明了一件事：喊"RAG 死了"的人，和正在用 RAG 赚钱的人，讨论的不是同一种 RAG。前者脑子里是 2023 年的那套"切块-嵌入-检索-拼接-生成"的标准流程。后者在实践中发现，那套东西确实有天花板——所以他们改进了它、重构了它、甚至重新发明了它。

这篇文章想做的，就是把这套"改进-重构-重新发明"的进化路线画清楚：每一代 RAG 到底改了什么、为什么必须改、以及改完之后又引入了什么新问题。

01 "RAG 死了"的论调，到底在说什么

先理清批评者的核心论点，否则后面的进化论就变成了空中楼阁。

批评 RAG 的声音主要有三个层面：

第一层：检索质量的不可靠性。这是最老也最真实的问题。你把文档切成固定大小的块，用通用 Embedding 模型编码成向量，然后做语义相似度检索——这个流水线里每一步都可能导致信息丢失或错配。关键段落被切断了，查询的语义和文档的语义不在同一个空间里，最重要的段落因为向量相似度算法的一点点偏差被排到了第二页。

第二层：上下文窗口的浪费。即使检索到的内容确实是相关的，你一股脑把所有检索结果拼进 Prompt，效果往往不如精心挑选少数几段。因为模型不是越多的上下文就表现越好——过多的信息会导致注意力分散，关键信息被淹没在噪音里。这就是所谓的"Lost in the Middle"效应。

第三层：缺乏推理能力。基础 RAG 的本质是"找到相关信息，交给模型直接回答"。但很多真实问题不是"找到信息就能回答"的——它们需要多步推理。"A 公司和 B 公司过去三年的营收差距变化趋势是怎样的？"这个问题需要先分别找到两家公司每年的营收数据，然后计算差值，然后分析趋势。基础 RAG 做不了这个，因为它只有一次检索、一次生成。

这三个批评都是真实的。但它们批评的是一个特定版本的 RAG——2023 年版的 Naive RAG。而产业界在过去两年里做的事情，恰好就是逐一解决这三个问题。

02 三代进化：从 Naive 到 Advanced 到 Agentic

RAG 技术的进化不是线性的替代关系，而是一层一层地叠加。每一代在前一代的基础上增加新的能力维度，同时也增加新的复杂度。

2.1 Naive RAG：一个朴素但脆弱的起点

Naive RAG 的流程可以概括为五个字：切、存、搜、拼、答。

文档 → 固定大小切块 → Embedding → 存入向量库 查询 → Embedding → 向量相似度检索 → 取 Top-K → 拼接进 Prompt → LLM 生成回答

这套流程的优点是一句话说清楚的——任何人都能在半小时内架起来。缺点是它也就能跑半小时的水平——一旦你开始用真实数据、真实查询、真实用户去考验它，每个环节都会出问题。

切块阶段的问题：固定分块（比如每 500 个 token 一刀切下去）对叙事性较强的文档（技术博客、产品文档）还行，但对结构化数据（API 文档、法律条文、财报表格）则是灾难。一个函数的定义可能被切成两块，上半截在 chunk 7，下半截在 chunk 8，搜到 chunk 7 的检索结果完全不可用。

搜索阶段的问题：通用 Embedding 模型（比如 text-embedding-ada-002 或者早期的 BGE）是在通用语料上训练的。它们在"这段文本大概在讲什么"的层面做得不错，但在"这段文本精确回答了用户的哪个问题"的层面经常翻车。用户的查询是"怎么解决数据库连接池耗尽"，模型找到的是"数据库连接池的配置参数详解"——语义相关，但不是答案。

拼接阶段的问题：Top-K 搜索结果一个接一个地拼进 Prompt，不做任何排序、过滤或压缩。结果就是前面提到的"Lost in the Middle"——模型对 Prompt 开头和结尾的内容关注度高，对中间的内容关注度低，而刚好你需要的那段信息被排在第三位。

2.2 Advanced RAG：一套不断膨胀的工程补丁

Advanced RAG 不是一个新的架构范式，而是针对 Naive RAG 每个环节的问题打上的一系列补丁。这些补丁各自独立但相互配合，把 RAG 从一个"玩具级方案"提升到"能用的方案"。

补丁一：智能分块。

固定分块被语义感知分块取代。不再是按 token 数一刀切，而是根据文档的自然边界——段落、章节、代码块、表格——来切。理想情况下，每个 chunk 是一个完整的语义单元。

# Naive 分块：按固定窗口，不管语义边界chunks=[doc[i:i+500]foriinrange(0,len(doc),500)]# 语义分块：按段落/章节边界chunks=[]current_chunk=""forparagraphindoc.paragraphs:iflen(current_chunk)+len(paragraph)>max_chunk_size:chunks.append(current_chunk)current_chunk=paragraphelse:current_chunk+="\n"+paragraph

更进一步的做法是递归分块——先用大的语义单元（章节）切，如果某个单元太大，再递归地用小的单元（段落、句子）切。还有滑动窗口分块——相邻 chunk 之间有重叠，确保边界附近的上下文不会丢失。

补丁二：查询重写。

原始用户的查询可能很短、很模糊、或者用词和文档不一致。查询重写在检索之前先"优化"查询，缩小查询和文档之间的语义鸿沟。

• HyDE（假设性文档嵌入）：先让 LLM 根据查询生成一个假想的答案文档，再用这个假想文档的向量去检索。原理是：假想答案和真实相关文档的语义空间更接近，比直接用原始查询检索效果好。
• 多查询生成：让 LLM 把用户的一个查询拆成多个不同角度的子查询，对每个子查询分别检索，合并结果。比如"如何优化 RAG 系统"变成"RAG 分块策略优化"“RAG 检索精度提升”“RAG 上下文压缩方案”。
• 退一步提示（Step-back Prompting）：把具体问题抽象成更宽泛的"背景问题"来检索。用户问"2024 年 Q3 特斯拉毛利率为什么下降"，退一步检索"影响汽车行业毛利率的关键因素"。

补丁三：混合检索与重排序。

单一检索策略的可靠性在一些论文中被证明不足 60%。混合检索把多种策略的结果合并：稠密检索（向量语义相似度，擅长大意匹配）+稀疏检索（BM25 关键词匹配，擅长精确术语查找）。两者各有所长，结合起来覆盖面更广。

检索结果的最后一步是重排序（Re-ranking）。用比 Embedding 模型更精确（但也更慢）的排序模型（如 cross-encoder），对 Top-K 候选段落做精细化的相关性打分，把无关结果踢掉，把最相关的结果排到前面。

# 混合检索 + 重排序的简化示意dense_results=vector_db.search(query_embedding,top_k=50)sparse_results=bm25_index.search(query_text,top_k=50)merged=merge_and_deduplicate(dense_results,sparse_results)reranked=cross_encoder.rerank(query,merged)[:top_k]

补丁四：上下文压缩与重排。

即使检索结果都是相关的，直接拼接也浪费 token。LLMLingua 这类压缩技术可以在保留关键信息的前提下把检索结果压缩 2-5 倍。更简单的做法是"选择性注入"——不是把所有段落都塞进 Prompt，而是根据相关性分数只取最 Top 的几条，把省下的 token 留给模型的推理。

Advanced RAG 的这四层补丁解决了很多问题，但它们带来的新问题是系统复杂度非线性膨胀。你本来只想搭一个简单的问答系统，现在你需要管理分块策略、Embedding 模型的版本、BM25 索引、重排序模型、查询重写的 Prompt 模板、压缩算法的参数——每加一层补丁，系统的维护负担就加一份。而且，即使加了这么多补丁，它仍然解决不了第三层批评：缺乏推理能力。

这就是 Agentic RAG 登场的背景。

2.3 Agentic RAG：让检索具备思考和行动能力

Agentic RAG 的核心思想是：RAG 不应该是一个"检索一次、生成一次"的单向流水线，而应该是一个"检索-评估-决策-再检索"的自主循环。

一个 Agentic RAG 系统在面对用户查询时，不会立刻做一次检索然后生成答案，而是先做一个简短的"检索计划"——这个问题需要从哪些角度获取信息？优先查什么？如果第一次检索不够怎么办？

这个流程中有两个关键的新组件：规划模块（决定怎么检索）和判断模块（评估检索质量、决定是否需要再检索）。

规划模块本质上是一个轻量级的 LLM 调用，输入用户的原始问题，输出一个检索计划——包含拆解后的子问题、每个子问题的检索策略（向量检索、关键词检索还是查数据库）、以及子问题之间的依赖关系。

判断模块则做两件事：充分性检查——"目前收集到的信息是否足以回答用户的问题？"以及准确性校验——"不同来源的信息是否一致？有没有明显的矛盾？“如果判断结果为"不充分"或"有矛盾”，Agent 会触发新一轮检索，可能调整检索策略（换关键词、放宽范围、切换数据源）。

Agentic RAG 的进化不在检索算法本身，而在于给检索加了一个"大脑"——让系统自己决定搜什么、搜到的东西够不够用、不够用该怎么办。

Agentic RAG 还天然地可以与工具调用结合。检索不只是向量搜索——可以是 SQL 查询（查结构化数据库）、API 调用（查实时数据）、网页抓取（查公开信息）。这种"多工具 RAG"的思路和 MCP 协议的设计不谋而合——每个数据源作为一个 MCP Server，RAG Agent 通过标准协议调用，检索策略由 Agent 自主决策。

03 分支路线：GraphRAG 与多模态 RAG

在 Naive → Advanced → Agentic 这条主线上，还有两条重要的分支路线值得单独讨论。它们解决的问题和主线不同，但最终会和主线融合。

3.1 GraphRAG：用知识图谱对抗碎片化

Microsoft 在 2024 年开源的 GraphRAG，解决的是一个 Naive RAG 几乎完全忽略的问题：文档之间的结构和关系。

Naive RAG 把知识库当作一堆独立碎片的集合。“A 公司收购了 B 公司"和"B 公司之前是 C 公司的子公司"这两条信息可能分布在不同的 chunk 里，RAG 检索可能两条都找不到——因为用户的查询是"A 公司和 C 公司有什么关系”。

GraphRAG 的做法是在检索之前，先用 LLM 从文档中抽取实体和关系，构建一张知识图谱。然后，用社区发现算法（如 Leiden 算法）把图谱中的实体分组，为每个"社区"生成一份摘要。当用户查询时，系统不只是做向量检索，还从图谱中找到相关的实体和社区摘要，一并提供给 LLM。

GraphRAG 擅长的不是"找出包含答案的那段文字"，而是**“理解多个信息点之间的全局关系和整体模式”**。它在以下场景中优势明显：总结一个主题的整体论述（“这份财报的核心主题是什么”）、发现跨文档的模式和趋势（“行业里哪些公司在裁员”）、以及多跳推理（“影响 X 事件的间接因素有哪些”）。

但 GraphRAG 的代价也很明确：构建成本高。实体抽取和关系构建需要大量的 LLM 调用，对大型文档库来说，这个成本可能是向量索引的 10-50 倍。而且图谱需要维护——文档更新了，图也得更新，否则信息会过时。

3.2 多模态 RAG：文档不只是文字

大多数企业的知识库不只是文字——PDF 里有图表、有表格、有流程图、有截图。传统的 RAG 流程在做 Embedding 时把这些非文字元素全部丢掉了。

多模态 RAG 试图解决这个问题。目前有两个主要的技术路线：

路线一：后期融合。分别对文字和图片做 Embedding（文字用文本模型，图片用视觉模型如 CLIP 或 ColPali），检索时同时搜索两个向量空间，结果层做融合。这种方法实现简单，但融合策略（加权平均？交叉排序？）对结果质量影响很大，且缺乏统一的标准做法。

路线二：统一视觉语言 Embedding。用 ColPali、ColQwen 这类模型，直接对文档页面的截图做 Embedding。不再区分"这段是文字"和"这张是图片"，而是把整个页面当作一个视觉整体来处理。这种方法在包含复杂排版的文档（学术论文、财报、技术手册）上效果更好，但 Embedding 模型的体量和推理成本也更大。

多模态 RAG 目前还处于比较早期的阶段，主要是工程复杂度远大于纯文本 RAG——你需要同时管理文本向量库和视觉向量库、处理不同模态之间的对齐问题、以及让 LLM 在生成回答时正确引用图片和表格中的信息。

04 生产级 RAG：一个可落地、可演进的架构设计

前面三章讨论了技术进化路线，这一章把它们串起来，给一个能直接参考的架构设计。

4.1 分层架构

一个生产级 RAG 系统应该分为四层，每一层独立演进、独立替换：

┌────────────────────────────────────────────────────────┐ │ 接入层（Routing Layer） │ │ ┌──────────┐ ┌──────────────┐ ┌──────────────────┐ │ │ │ 查询分类 │ │ 复杂度评估 │ │ 策略分配 │ │ │ │ 简单/复杂 │ │ 单跳/多跳 │ │ 用哪种 RAG 方案 │ │ │ └──────────┘ └──────────────┘ └──────────────────┘ │ ├────────────────────────────────────────────────────────┤ │ 检索层（Retrieval Layer） │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────┐ │ │ │ 向量检索 │ │ 关键词检索│ │ SQL查询 │ │ API调用 │ │ │ └──────────┘ └──────────┘ └──────────┘ └────────┘ │ ├────────────────────────────────────────────────────────┤ │ 融合层（Fusion Layer） │ │ ┌──────────┐ ┌──────────┐ ┌──────────────────────┐ │ │ │ 去重合并 │ │ 重排序 │ │ 上下文压缩与结构化 │ │ │ └──────────┘ └──────────┘ └──────────────────────┘ │ ├────────────────────────────────────────────────────────┤ │ 推理层（Reasoning Layer） │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ 充分性判断 │ │ 多轮补全 │ │ 答案生成 │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ └────────────────────────────────────────────────────────┘

接入层是系统的入口和调度器。它的核心职责是判断"这个问题应该走哪条检索路径"。一个简单的事实类问题——“公司去年的营收是多少”——走基础 RAG 就够了，不需要 GraphRAG 的多跳推理，也不需要 Agentic RAG 的多轮迭代。一个复杂的分析类问题——“分析公司营收下降的原因，结合行业趋势给出建议”——则需要启动 Agentic RAG，做多轮检索、交叉验证和结构化分析。

这层可以用一个轻量级 LLM（成本低、延迟小）来做查询分类，也可以用规则引擎（关键词匹配 + 问题类型模板）实现。

检索层包含多种检索能力，每种能力对应一种数据源。向量检索对应非结构化文档，关键词检索对应精确匹配场景，SQL 查询对应结构化数据库，API 调用对应实时外部数据。这一层的关键设计原则是"每种数据源都有最适合它的检索方式，不要试图用一把锤子敲所有的钉子"。

融合层负责把来自不同检索路径的结果整合成"模型能理解、不浪费 token"的上下文。核心操作有三个：去重（不同检索路径可能返回相同的内容）、重排序（判断哪些结果更相关）、压缩与结构化（把结果整理成清晰的结构，而不是一锅乱炖）。

推理层是 Agentic RAG 的大脑。它判断检索结果是否充分（不够就触发补全）、做多轮迭代（回检索层再次检索）、以及最终生成回答。

4.2 什么时候用什么方案

不需要一口气把所有技术都堆进去。根据你的场景选择合适的层次：

4.3 评估：不要只看检索的分数

RAG 系统最容易被忽略的部分是评估。很多团队把优化方向放在检索准确率（Recall@K、MRR）上，但检索准确率提升并不总意味着端到端回答质量的提升。有时候你把 Recall 从 85% 提到了 92%，但用户感受到的改善微乎其微——因为那 7% 的增量信息在 LLM 生成回答时被忽略掉了。

一个更务实的评估框架包含三个层次：

第一层：检索质量。Recall@K、Precision@K、MRR。这些是必要条件，不是充分条件。如果检索质量很差，后面的环节再强也没用。但检索质量一旦超过某个阈值（通常在 80-85% 左右），继续优化的边际收益递减。

第二层：上下文利用率。检索到的内容是否被模型在生成回答时有效使用了？可以通过"引用覆盖率"来衡量——模型的回答中有多少事实性陈述能找到对应的检索来源。这个指标比检索准确率更能反映端到端的质量。

第三层：回答质量。正确性（回答的事实是否准确）、完整性（是否回答了问题的所有方面）、有用性（用户是否真的解决了问题）。这一层目前主要靠人工评估或 LLM-as-Judge，自动化程度有限，但它是最接近真实用户体验的一层。

05 总结

RAG 没有死。死的是那个不加改进、不修 bug、拿 2023 年的标准方案直接往生产环境里扔的幼稚做法。而活下来的，是经历了分块策略优化、检索策略升级、自主推理增强、知识图谱补充、多模态覆盖这一整套进化之后的新一代 RAG。

几个核心要点：

• RAG 的进化是补丁驱动的，不是架构重写。从 Naive 到 Advanced 到 Agentic，每一层增量都是在解决前一层的具体痛点，而不是推倒重来。你现在搭建的 Advanced RAG 系统，未来升级到 Agentic 时不需要重构底层。
• GraphRAG 不是 RAG 的替代品，而是互补品。它解决的是"全局关系理解"问题，RAG 解决的是"精确信息检索"问题。两者在产品中的角色不同，合并使用才是正确姿势。
• Agentic RAG 的核心价值不在"多轮检索"，而在"自主判断"。让系统自己决定搜没搜够、搜得对不对——这个决策环才是质的飞跃。
• 评估问题是当前最大的工程空白。检索质量、上下文利用率、端到端回答质量这三层指标体系远未成熟，大部分团队还停留在"拍脑袋觉得效果还行"的阶段。
• 生产级 RAG 需要分层演进。不是所有查询都需要 Agentic RAG 的复杂度。接入层的路由能力——根据问题类型选择匹配的检索方案——是被普遍低估但性价比极高的优化点。

RAG 领域正在发生的事，和其他成熟技术的演进路径如出一辙：它从"一个 idea"变成"一套工程方案"，再从"一套工程方案"变成一个"生态"。当你听到有人说"RAG 死了"的时候，你听到的其实是一个人停下了脚步的声音——而路还在往前延伸。