RAG没有死：2026年检索增强生成的进化路线图

2026 年初一场关于 RAG 的争论在技术圈炸开了锅。导火索是斯坦福一个团队的研究——他们发现用合成数据微调的小模型在垂直领域的问答准确率上反超了 RAG 方案而且成本更低。一时间“RAG 神话破灭”检索增强已死的标题铺满了公众号。但在另一边企业级 AI 应用的落地现实却是另一幅图景Dify 的 RAG 流水线被嵌入了成千上万的生产系统Microsoft 的 GraphRAG 在 GitHub 上收获了数万 StarAgentic 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 到 AgenticRAG 技术的进化不是线性的替代关系而是一层一层地叠加。每一代在前一代的基础上增加新的能力维度同时也增加新的复杂度。 分块优化 检索策略 重排序 上下文压缩 自主决策 多轮迭代 工具调用Naive RAG2023检索 拼接Advanced RAG2024工程化补丁Agentic RAG2025-2026推理 行动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:i500]foriinrange(0,len(doc),500)]# 语义分块按段落/章节边界chunks[]current_chunkforparagraphindoc.paragraphs:iflen(current_chunk)len(paragraph)max_chunk_size:chunks.append(current_chunk)current_chunkparagraphelse:current_chunk\nparagraph更进一步的做法是递归分块——先用大的语义单元章节切如果某个单元太大再递归地用小的单元段落、句子切。还有滑动窗口分块——相邻 chunk 之间有重叠确保边界附近的上下文不会丢失。补丁二查询重写。原始用户的查询可能很短、很模糊、或者用词和文档不一致。查询重写在检索之前先优化查询缩小查询和文档之间的语义鸿沟。HyDE假设性文档嵌入先让 LLM 根据查询生成一个假想的答案文档再用这个假想文档的向量去检索。原理是假想答案和真实相关文档的语义空间更接近比直接用原始查询检索效果好。多查询生成让 LLM 把用户的一个查询拆成多个不同角度的子查询对每个子查询分别检索合并结果。比如如何优化 RAG 系统变成RAG 分块策略优化“RAG 检索精度提升”“RAG 上下文压缩方案”。退一步提示Step-back Prompting把具体问题抽象成更宽泛的背景问题来检索。用户问2024 年 Q3 特斯拉毛利率为什么下降退一步检索影响汽车行业毛利率的关键因素。补丁三混合检索与重排序。单一检索策略的可靠性在一些论文中被证明不足 60%。混合检索把多种策略的结果合并稠密检索向量语义相似度擅长大意匹配稀疏检索BM25 关键词匹配擅长精确术语查找。两者各有所长结合起来覆盖面更广。检索结果的最后一步是重排序Re-ranking。用比 Embedding 模型更精确但也更慢的排序模型如 cross-encoder对 Top-K 候选段落做精细化的相关性打分把无关结果踢掉把最相关的结果排到前面。# 混合检索 重排序的简化示意dense_resultsvector_db.search(query_embedding,top_k50)sparse_resultsbm25_index.search(query_text,top_k50)mergedmerge_and_deduplicate(dense_results,sparse_results)rerankedcross_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判断模块检索器RAG Agent用户查询LLM判断模块检索器RAG Agent用户查询A和B两家公司过去三年营收对比制定检索计划分两个子问题子问题1A公司2024-2026年营收数据[检索结果1]子问题2B公司2024-2026年营收数据[检索结果2]评估检索到的数据是否完整、来源是否可靠数据足够可以开始分析将两次检索的结构化数据 分析指令 一起交给模型对比分析结果含计算过程最终回答这个流程中有两个关键的新组件规划模块决定怎么检索和判断模块评估检索质量、决定是否需要再检索。规划模块本质上是一个轻量级的 LLM 调用输入用户的原始问题输出一个检索计划——包含拆解后的子问题、每个子问题的检索策略向量检索、关键词检索还是查数据库、以及子问题之间的依赖关系。判断模块则做两件事充分性检查——目前收集到的信息是否足以回答用户的问题以及准确性校验——不同来源的信息是否一致有没有明显的矛盾“如果判断结果为不充分或有矛盾”Agent 会触发新一轮检索可能调整检索策略换关键词、放宽范围、切换数据源。Agentic RAG 的进化不在检索算法本身而在于给检索加了一个大脑——让系统自己决定搜什么、搜到的东西够不够用、不够用该怎么办。Agentic RAG 还天然地可以与工具调用结合。检索不只是向量搜索——可以是 SQL 查询查结构化数据库、API 调用查实时数据、网页抓取查公开信息。这种多工具 RAG的思路和 MCP 协议的设计不谋而合——每个数据源作为一个 MCP ServerRAG 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 倍。而且图谱需要维护——文档更新了图也得更新否则信息会过时。GraphRAG 流程原始文档实体与关系抽取构建知识图谱社区检测与摘要图谱 摘要存储用户查询向量检索 图遍历LLM 综合生成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 什么时候用什么方案不需要一口气把所有技术都堆进去。根据你的场景选择合适的层次场景推荐方案核心组件内部技术文档 QAAdvanced RAG语义分块 混合检索 重排序财报/研报分析GraphRAG Advanced RAG知识图谱 向量检索全局模式精确匹配互补客服系统Advanced RAG Agentic 路由简单问题走快速通道复杂问题升级研究辅助系统Agentic RAG多轮检索 充分性判断 多工具调用多格式企业知识库多模态 RAG Advanced RAGColPali 混合检索覆盖文字图表4.3 评估不要只看检索的分数RAG 系统最容易被忽略的部分是评估。很多团队把优化方向放在检索准确率RecallK、MRR上但检索准确率提升并不总意味着端到端回答质量的提升。有时候你把 Recall 从 85% 提到了 92%但用户感受到的改善微乎其微——因为那 7% 的增量信息在 LLM 生成回答时被忽略掉了。一个更务实的评估框架包含三个层次第一层检索质量。RecallK、PrecisionK、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 死了的时候你听到的其实是一个人停下了脚步的声音——而路还在往前延伸。