2024年下半年开始，一个微妙的趋势在AI工程圈蔓延：RAG这个词的出镜率在断崖式下降。

技术会议上， keynote 从"如何构建RAG流水线"转向了Agent、长上下文、工具调用。Hacker News和Twitter上，每隔几周就会出现一个"RAG已死"的帖子，获赞上千。一些2023年以RAG为核心卖点的创业公司，悄悄把首页标语换成了"AI Knowledge Platform"或"Context Engine"。

但数字讲了一个截然不同的故事。MarkAICode在2026年初的一篇行业分析中引用了一组数据：2025年企业级RAG部署量增长了280%，而且这些新增部署主要来自S&P 500级别的企业——法律、金融、客服、研发场景，而非小团队的概念验证。$TRAE_REF

RAG没有消失。它经历了一场安静的物种演化，而多数人还在用旧的分类框架观察它。

长上下文杀了哪种RAG

先说清楚：确实有一种RAG正在死去，而且应该死去。

2023年的标准RAG流水线长这样：把文档切成固定长度的chunk，用embedding模型向量化，存入向量数据库，查询时检索top-k个chunk，拼进prompt，交给模型生成。这套流水线之所以流行，有一个非常具体的历史原因——当时主流模型的上下文窗口只有4K到8K token，你根本没有别的选择。

当Gemini 1.5 Pro提供百万token上下文、Claude支持20万token、Llama 4 Scout宣称1000万token时，那个历史前提被动摇了。

2025年2月，Chan等人发表了一篇标题很挑衅的论文：Don’t Do RAG: When Cache-Augmented Generation Is All You Need。核心结论简洁有力：如果你的知识库能放进上下文窗口，并且更新频率不高，那么直接预加载全文到prompt缓存中，在准确率上比检索高15-20%，延迟更低，架构更简单。$TRAE_REF

这个思路后来被正式命名为CAG（Cache-Augmented Generation），并在2026年初迅速落地。Google NotebookLM不chunk不检索，直接加载你的源文件；Anthropic的Claude Projects同理——上传文件，模型全程持有，没有embedding步骤，没有检索延迟。$TRAE_REF

DataXPower在2025年底的回顾中给出了更精确的边界：长上下文真正取代RAG的，是三类场景——单文档推理（一份合同、一本手册）、小型慢变知识库（HR手册、产品文档）、以及评估调试流程。$TRAE_REF

这些场景有一个共同特征：知识总量可控，内容相对稳定，查询不具备高度不可预测性。在这个范围内，CAG确实是更优解。向量数据库、embedding流水线、分块策略——一整套基础设施变成了不必要的开销。

为什么RAG还在，而且比以前更重要

CAG的阈值很明确：大约100万token以下、更新频率不高于每日、不需要行级权限控制。$TRAE_REF

问题是，真实的企业知识管理几乎不可能同时满足这三个条件。

一家中型银行的合规文档库通常以TB计，远远超出任何上下文窗口。一次跨时间段的合规查询——“2023年和2024年的反洗钱政策有哪些关键差异？”——需要综合来自不同时期、不同文档类型的片段，这种多跳推理在长上下文里表现并不好。Cambridge的一项研究发现，在HotpotQA这类多跳推理任务上，RAG的幻觉率（10.3%）反而低于纯长上下文方案（12.3%）。$TRAE_REF

更关键的约束来自四个非功能性需求，它们在CAG的框架下几乎无解：

规模。大多数生产级知识库的数据量在数亿token级别，远超当前任何上下文窗口。通过检索筛选相关子集再送入模型，成本比全量塞入低几个数量级。Elastic的基准测试显示，RAG查询的平均成本是纯长上下文方案的1/1250。$TRAE_REF

时效性。如果答案取决于昨天写入的文档——工单、PR、事故报告、监管文件——持续更新的检索索引永远胜过静态prompt。长上下文无法追赶持续变化的知识库。

权限与审计。检索层天然支持在模型看到内容之前执行ACL过滤，并为每条生成结果提供到源文档片段的溯源链。这对金融、医疗、法律等受监管行业不是可选项。长上下文既不能按用户权限过滤内容，也无法提供chunk级别的归因。

可调试性。检索流水线给工程团队提供了两个独立的调优旋钮——检索质量和生成质量——以及两条独立的评估回路。把它们压缩成一个prompt，意味着每次回归都更难定位，每轮质量调查都更慢。

这四个约束解释了为什么"RAG已死"的讨论主要发生在社交媒体上，而真正在企业数据上部署AI的团队从未放弃检索。正如Turing Post的一期播客中一位从业者所说：“没有哪个认真在企业数据上部署AI的人会说RAG死了。也许一些记者和分析师会这么说。”$TRAE_REF

RAG没有死，它分裂了

MMNTM在2026年初提出的一个框架很好地描述了当前的局面：RAG正在分化为两条截然不同的路径，而中间地带正在成为死区。$TRAE_REF

路径A是CAG——上文已经讨论过，适合小型静态知识库，用缓存取代检索。

路径B则走向了完全相反的方向：不是减少检索，而是让检索变得更智能、更有结构。这条路径上有三个标志性技术方向。

GraphRAG与HyperGraphRAG。传统RAG把文档当作chunk的集合，忽略了实体之间的关系。GraphRAG在语料上构建知识图谱——实体是节点，关系是边——让多跳查询（“台湾供应商的延迟如何影响了Q3收入指引？”）可以通过图谱遍历来回答，而不是指望top-5 chunk恰好包含所有相关片段。2025年10月，Luo等人提出HyperGraphRAG，用超边（hyperedge）替代二元关系，一次连接多个实体，更适合法律、医疗等真实世界的复杂事件建模。$TRAE_REF Microsoft GraphRAG已经在Copilot for M365中落地，Palantir AIP则沿着 Ontology 方向走得更深。

Agentic RAG。这是2025到2026年最重要的架构变化。检索从应用层面的确定性预处理，变成了Agent自主调用的工具。Agent自己决定是否检索、用什么query检索、检索几轮、何时停止——有时会根据中间结果发起后续检索来修正或扩展先前的发现。T R A E R E F ] ( h t t p s : / / w w w . d a t a x p o w e r . c o m / b l o g / r a g − i n − 2026 − w h a t − s t i l l − w o r k s ) L i g h t O n 在 2025 年底的一篇文章中精准地概括了这种转变： R A G 没有死，它成熟了——从 2023 年那个朴素的流水线，变成了 A g e n t 系统内部有条件的注意力策略。 [ TRAE_REF](https://www.dataxpower.com/blog/rag-in-2026-what-still-works) LightOn在2025年底的一篇文章中精准地概括了这种转变：RAG没有死，它成熟了——从2023年那个朴素的流水线，变成了Agent系统内部有条件的注意力策略。[TRAER​EF](https://www.dataxpower.com/blog/rag−in−2026−what−still−works)LightOn在2025年底的一篇文章中精准地概括了这种转变：RAG没有死，它成熟了——从2023年那个朴素的流水线，变成了Agent系统内部有条件的注意力策略。[TRAE_REF

检索栈的全面升级。即使是传统意义上的检索，其内部组件也经历了彻底的迭代。Contextual Retrieval在embedding之前先用LLM为每个chunk生成上下文摘要作为前缀，将检索失败率降低了35-50%。T R A E R E F ] ( h t t p s : / / w w w . d a t a x p o w e r . c o m / b l o g / r a g − i n − 2026 − w h a t − s t i l l − w o r k s ) 混合检索（ B M 25 + 稠密向量 + 交叉编码器重排序）已成为生产环境的基线配置。 R A G O 论文甚至提出把 R A G 请求当作数据库查询来优化——查询规划、缓存命中、并行检索——实现了 55 TRAE_REF](https://www.dataxpower.com/blog/rag-in-2026-what-still-works) 混合检索（BM25 + 稠密向量 + 交叉编码器重排序）已成为生产环境的基线配置。RAGO论文甚至提出把RAG请求当作数据库查询来优化——查询规划、缓存命中、并行检索——实现了55%的延迟降低和2倍的吞吐量提升。[TRAER​EF](https://www.dataxpower.com/blog/rag−in−2026−what−still−works)混合检索（BM25+稠密向量+交叉编码器重排序）已成为生产环境的基线配置。RAGO论文甚至提出把RAG请求当作数据库查询来优化——查询规划、缓存命中、并行检索——实现了55TRAE_REF

这三条路径有一个共同特征：它们都比2023年的标准RAG更复杂，但也更有能力。RAG没有退场，它正在从"一个周末项目"变成"一个正经的工程系统"。

"RAG已死"叙事为什么有市场

理解这个叙事的流行，需要看到它背后的心理机制和商业动机。

从心理层面看，技术社区天然偏好"颠覆"叙事。"某技术已死"比"某技术在缓慢进化"更容易传播，也更容易带来观点持有者的智力优越感。每次上下文窗口扩大，都会触发一轮"RAG已死"的断言，仿佛这个论断不需要考虑知识库规模、权限控制、审计需求这些工程现实。

从商业层面看，这个叙事服务于特定利益方。模型厂商（Google、Anthropic）有动力淡化检索的重要性——它们的商业模型建立在token消耗上，长上下文意味着更多token、更多收入。如果一个客户把所有文档塞进上下文而不是通过检索精选相关片段，API调用费用会指数级上升。Redis在对比分析中给过一个直观的数字：GPT-4.1处理10万token请求的输入成本是0.20美元，每月一万次调用就是2000美元，而RAG方案的每次查询成本仅为0.00008美元。$TRAE_REF

这不是说模型厂商在故意误导。长上下文确实是真实的技术进步。但如果你的决策框架只考虑"能不能塞进去"，不考虑"塞进去之后每查询成本是多少"以及"有没有权限和审计需求"，那你得到的是一个不完整的答案。

2026年的决策框架

回到工程实践，MMNTM提出的两问过滤器至今仍然是最实用的决策起点。$TRAE_REF

第一个问题：放得下吗？知识库在100万token以内，更新不频繁，不需要行级权限控制？用CAG，跳过所有检索基础设施。这是一个工程复杂度大幅降低的选择。

第二个问题：结构重要吗？知识库超过阈值，或者查询涉及多跳推理、实体关系、跨文档综合？那就不是"要不要RAG"的问题，而是"该用哪种RAG"的问题。标准chunk-and-retrieve已经是遗产架构，你应该考虑的是GraphRAG、Agentic RAG，或至少是混合检索加重排序的现代化流水线。

中间地带——文档总量不太大也不太小，查询不太复杂也不太简单，权限要求若即若离——恰恰是标准RAG曾经最活跃的区域，也是现在最尴尬的区域。DataXPower把这种局面称为"The Death of the Middle"：比CAG复杂，比GraphRAG弱，在一个4K上下文的世界里它是最优解，但在百万token的世界里它两头不靠。$TRAE_REF

RAG的未来不是RAG

如果非要对RAG的前途做一个判断，我会说：RAG这个词本身正在失去它的指涉精度。

当一个概念从特指某一种流水线，泛化为涵盖CAG、GraphRAG、Agentic RAG、混合检索、语义缓存等一系列相关但不同的架构时，它作为一个技术标签的效用就在衰减。就像"Web 2.0"这个词——曾经精确地描述了一种从静态页面向动态交互的转变，后来什么都往里装，最后变成了一个没人再用的标签。

RAG正在经历同样的过程。它的核心洞察——模型参数之外的知识需要被外部获取，而非全部压缩进权重——这一判断至今正确，而且比2020年Facebook AI团队提出它时更加正确。但实现这个洞察的具体方式，已经从单一的检索流水线，分化为一条从"直接缓存"到"超图推理"的光谱。

检索没有死。它只是不再被一个名字统辖了。而那些还在争论"RAG是死是活"的人，争论的可能是一个已经不存在的对象。