2024年下半年开始一个微妙的趋势在AI工程圈蔓延RAG这个词的出镜率在断崖式下降。技术会议上 keynote 从如何构建RAG流水线转向了Agent、长上下文、工具调用。Hacker News和Twitter上每隔几周就会出现一个RAG已死的帖子获赞上千。一些2023年以RAG为核心卖点的创业公司悄悄把首页标语换成了AI Knowledge Platform或Context Engine。但数字讲了一个截然不同的故事。MarkAICode在2026年初的一篇行业分析中引用了一组数据2025年企业级RAG部署量增长了280%而且这些新增部署主要来自SP 500级别的企业——法律、金融、客服、研发场景而非小团队的概念验证。$TRAE_REFRAG没有消失。它经历了一场安静的物种演化而多数人还在用旧的分类框架观察它。长上下文杀了哪种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这个思路后来被正式命名为CAGCache-Augmented Generation并在2026年初迅速落地。Google NotebookLM不chunk不检索直接加载你的源文件Anthropic的Claude Projects同理——上传文件模型全程持有没有embedding步骤没有检索延迟。$TRAE_REFDataXPower在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_REFRAG没有死它分裂了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_REFRAG的未来不是RAG如果非要对RAG的前途做一个判断我会说RAG这个词本身正在失去它的指涉精度。当一个概念从特指某一种流水线泛化为涵盖CAG、GraphRAG、Agentic RAG、混合检索、语义缓存等一系列相关但不同的架构时它作为一个技术标签的效用就在衰减。就像Web 2.0这个词——曾经精确地描述了一种从静态页面向动态交互的转变后来什么都往里装最后变成了一个没人再用的标签。RAG正在经历同样的过程。它的核心洞察——模型参数之外的知识需要被外部获取而非全部压缩进权重——这一判断至今正确而且比2020年Facebook AI团队提出它时更加正确。但实现这个洞察的具体方式已经从单一的检索流水线分化为一条从直接缓存到超图推理的光谱。检索没有死。它只是不再被一个名字统辖了。而那些还在争论RAG是死是活的人争论的可能是一个已经不存在的对象。