RAG 没有过时：它只是进化成了你认不出的样子

摘要：长上下文窗口出现时，"RAG 已死"的论调一度甚嚣尘上。两年过去，RAG 不仅活着，还活成了企业 AI 应用的标配——只是它的形态已经从"向量检索 + 拼提示词"进化成了"规划、检索、评估、再检索"的智能体系统。本文梳理 RAG 进化的四条路径与一套落地方法论。

一、"RAG 已死"是怎么喊起来的

2025 年，百万 Token 级上下文窗口陆续落地，一种流行的论断开始传播：既然模型能一次读完整本书，中间再放一个检索系统就是脱裤子放屁——RAG 已死。

两年后回头看，这个判断错得离谱，但它错得很有价值：它逼着从业者想清楚了 RAG 的本质到底是什么。

如果 RAG 的本质只是"上下文装不下，所以要先检索"，那长上下文确实杀死了它。但 RAG 的本质从来不是补丁，而是一条知识供给原则：**在正确的时间，把正确的知识，放进模型的上下文。**只要模型不是全知的、企业知识不是静止的、账单不是无限的，这条原则就死不了。

先看长上下文为什么杀不死它，一笔账就明白了。

二、长上下文 vs RAG：一道选择题，不是是非题

最后一条最致命：把全部知识塞进上下文，等于把保险柜改成开放式货架。**企业的知识有权限边界，而权限过滤只能在检索层做。**这一条就决定了 RAG 在企业场景的不可替代。

但反过来说，长上下文也不是无用——小规模、个人级、临时性的任务，直接塞上下文就是最优解。正确的关系是互补，不是替代。下面进入正题：RAG 到底进化成了什么样。

三、回望起点：经典 RAG 的三段式与三大痛点

经典 RAG 的流水线朴素得像说明书：**文档切块 → 向量化入库 → 按相似度检索 → 拼进提示词生成答案。**它有效，但上线过的团队都知道那三大经典痛点：

1. 切块切断了语义：一个完整的论证过程被从中间剁开，两半各自 semantic，检索到哪一半都答不对；
2. 相似不等于相关：向量检索找的是"字面上像"的文本，用户问"退货要几天到账"，检索回来一堆讲"物流时效"的段落；
3. 噪声拖垮生成：TOP-5 里三条不相关，模型要么被带偏，要么开始编。

接下来的三条进化路径，本质上都是对这三大痛点的围剿。

四、进化一：检索质量的军备竞赛

这是投入产出比最高的一条路径，四件武器按性价比排序：

查询改写：用户的问题往往不适合直接检索——多轮对话里有指代（“那它多少钱？”，"它"是谁？）、口语里有省略。在检索前加一步轻量改写：指代消解、口语转书面、一个复杂问题拆成多个子问题。这一步的收益经常超过后面所有花活。

混合检索：向量检索（语义相似）与 BM25（关键词精确匹配）双路召回再融合。产品型号、人名、错误码这类"必须一字不差"的查询，关键词检索远比向量可靠；而换一种说法的问法，又是向量的主场。两者互补，几乎零成本。

重排（Rerank）：召回阶段用轻量模型宽进（TOP-50），再用一个更重的交叉编码器精排出 TOP-5。粗排求全，精排求准——这是搜索领域验证了二十年的架构，直接平移到 RAG。

语义切块与父子块：按语义边界（标题、段落、论证单元）而不是固定字数切块；更进一步用"父子块"策略——用小块做检索（定位准），把它所属的大块喂给模型（上下文全）。检索粒度和生成粒度解耦，第一痛点和第三痛点一起缓解。

五、进化二：GraphRAG——补上向量检索的盲区

向量检索有一个结构性盲区：多跳问题。“A 公司的 CEO 毕业于哪所大学？”——这个答案不存在于任何单个文档段落里，它散落在"A 公司 CEO 是张三"和"张三毕业于 X 大学"两个地方。向量相似度对这种需要"关联推理"的查询无能为力。

GraphRAG 的解法是离线构建知识图谱：用模型从文档中抽取实体与关系（人物、组织、事件及其关联），形成图结构，并对图做社区聚类与摘要。检索时沿图游走、多跳汇聚，把散落的碎片拼成完整证据链。

适用性要泼一盆冷水：图谱构建成本高（全量抽取、更新维护），它只适合多跳问题密集、知识结构稳定的场景——风控关联分析、合规审查、复杂技术文档问答。如果你的用户只是问"怎么退货"，向量加混合检索完全够用，上图纯属高射炮打蚊子。先分析问题分布，再决定要不要上图谱。

六、进化三：Agentic RAG——从"流水线"到"会自己查资料的员工"

这是最深的一次形态变化：RAG 从一条固定流水线，变成了智能体工具箱里最常用的那把扳手。

经典 RAG 是开环的：检索一次，无论结果好坏都往下走。Agentic RAG 是闭环的——模型自己决定查不查、查什么、查几轮、结果够不够好、够好了再作答：

def agentic_rag(question, max_rounds=3):
    context = []
    for _ in range(max_rounds):
        query = rewriter.rewrite(question, context)   # 结合已有发现改写查询
        docs = retrieve(query, top_k=50)
        docs = rerank(query, docs, top_k=5)
        context += docs
        if judge.sufficient(question, context):       # 自评估：证据够了吗
            break
        # 不够 → 换个角度再查，或拆出子问题分头查
    return generate(question, compress(context))

三个新角色值得注意：

• 查询规划器：把"对比 A 方案和 B 方案的成本与风险"拆成四个独立子查询，分头检索再汇总；
• 证据评估器：检索结果回来后先自问"这些材料足以回答吗"，不够就改写换角度再来一轮——这是从开环到闭环的分水岭；
• 融合生成器：多轮多路的证据去重、冲突消解后再生成，而不是把一摞原文直接糊给模型。

代价也很直白：一轮 Agentic RAG 的 Token 消耗和延迟是经典 RAG 的数倍。所以它适合经典 RAG 答不好的硬问题，而不是全量替换——简单问题走单轮检索的快车道，复杂问题才进智能体的慢车道，和上一篇讲推理优化时的"分级路由"是同一个思想。

七、进化四：多模态 RAG——图纸上也有知识

企业知识很大一块根本不是纯文本：图纸、扫描合同、财务报表截图、设备操作手册里的示意图。传统 RAG 对它们无能为力——OCR 提出来的纯文本丢失了版面、表格结构和图内标注。

多模态 RAG 的技术栈正在成型：文档解析层（版面分析 + 表格结构还原，把 PDF 还原成带结构的语义单元）、多模态向量化（文本和图像进同一个语义空间，用"设备故障示意图"能直接搜到那张图）、多模态重排与生成（模型直接看图作答，而不是看图的 OCR 残渣）。对制造业、金融、医疗这类"知识长在图里"的行业，这是未来两年 RAG 落地的主要增量。

八、落地清单：把 RAG 做好的一张检查表

**第一原则：先建评测集，再动手优化。**RAG 评测看三层指标——检索层（该找的文档找到了没）、上下文层（送进模型的内容相关吗）、生成层（答案忠实于材料吗，编了没有）。从真实业务抽 100~200 个问题，标注标准答案出处，之后每一次优化都跑一遍回归。

**第二原则：分层归因。**答案不对时，先看检索回来的内容再怪模型——实践中大部分"模型笨"其实是"检索喂错了料"。顺序永远是：先查检索命中，再查上下文裁剪，最后才怀疑生成。

**第三原则：数据质量大于算法花活。**知识库里重复的、过期的、互相矛盾的文档，是任何检索算法都救不了的负资产。上线前的知识清洗——去重、标注生效时间、废弃旧版文档——收益高于任何模型升级。

第四，权限过滤在检索层实现，按岗位、按部门建索引分区，别指望靠提示词"叮嘱"模型不要泄露。

第五，常见问题缓存：高频问题的查询与答案做语义缓存，企业场景的前 20% 问题往往覆盖 60% 以上的流量。

九、结语

两年前人们说"长上下文杀死了 RAG"，两年后的事实是：长上下文没有杀死 RAG，反而把 RAG 里"堆料"的部分淘汰了，逼它进化成了更聪明的形态。

检索还在，但检索器学会了改写与多轮；生成还在，但生成器学会了评估证据是否充分。RAG 与 Agent 的边界正在消失——或者说，它们本来就是同一件事：让模型在正确的时间，拿到正确的知识。

对企业来说，这恰恰是个好消息：你在向量库、数据治理、知识清洗上积累的每一分资产，都不会因为模型升级而过时。模型是租来的，知识是自己的——这就是 RAG 不会被杀死的终极原因。

本文是"前沿 AI 技术"系列第四篇，前三篇为《从"会聊天"到"会干活"：2026 年前沿 AI 的五条技术主线》《把算力花在刀刃上：大模型推理优化深度解析》《从 Demo 到生产：AI 智能体工程化实战指南》。欢迎在评论区交流你所在行业的知识库建设经验。