「RAG 已死」是一个范畴错误

有一个标题，每次上下文窗口变大时都会像时钟一样准时回来：「RAG 已死。」 百万 token 的窗口出来了，所以你肯定可以把所有东西都塞进 prompt，然后删掉你的检索管线。这是个干净利落的 故事，每隔几个月就上一次热门，而且每一次都错了。值得搞清楚 为什么 错——因为这个错误是一种思维模式， 而不是关于 RAG 的事实。

技术 vs. 问题

「RAG 已死」把一种技术和它所解决的问题搞混了。RAG——检索增强生成（retrieval-augmented generation）——是一种实现。它底下那个问题是永恒的：把正确的上下文放到模型面前，既便宜又可追溯。 这个问题不会因为窗口变大就消失。如果有什么变化，那就是它变得更难了，因为现在你 可以 把所有东西都 倒进去——而模型会悄悄忽略中间的部分，同时你的账单在飙升。

光是经济账就足以杀死「用长上下文就行了」这个计划：对于典型工作负载，检索据报道比塞进一个长上下文便宜 8–82 倍，而且延迟更好。为了在每次调用时 把 40 万 token 推过模型、好让它从唯一重要的那一段旁边掠过，这可不是比取回那一段更好的升级。

真正死掉的东西

确实 有 东西死了——但不是检索。幼稚的 RAG 死了：把所有东西切块、做嵌入、top-k 余弦相似度，然后 祈祷。那个具体的配方一直都很脆弱，取代它的是更聪明的检索，而不是没有检索。正在形成的共识是「幼稚的 RAG 已死，精巧的 RAG 正在蓬勃发展」： 混合搜索、把检索当成模型在需要时主动选择的一个 agentic 动作、grep 和结构化查询与向量并行、高召回的 抓取加上模型做最终过滤。技术进化了。需求一寸都没挪动。

「X 已死」几乎总是有人把当下的实现误当成了那个永恒的问题。 管道一直在换。管道所服务的那个东西，几乎从不改变。

关键在于这个模式

这值得超越 RAG 去内化，因为你每个季度都会听到关于某样东西的「X 已死」：prompt engineering、微调、agent、 RAG，或者下一个是什么。每次都用同一个过滤器过一遍：

• 把需求和工具分开。 这项技术当初在解决什么永恒的问题？检索：把正确的上下文放进去。那个需求不在 弃用名单上。
• 问一问具体是什么坏了。 通常坏掉的是幼稚版本，而所谓的「死亡」其实是一次进化。「幼稚的 X 已死， 好的 X 正在蓬勃发展」十有八九才是那个诚实的标题。
• 跟着经济账和失败模式走。 更便宜、更可追溯、更好调试的方案会在生产中胜出，不管什么在流行。长上下文 输在了成本上，也输在了中间是一片墓地上，而不是输在能力上。
• 对「全都塞进去就行」保持警惕。 任何以「你再也不需要那份纪律了」结尾的推销，通常卖给你的是一个更大的 桶，而不是一个更好的答案。

对我来说，这直接连到 grounding：把正确、可验证的上下文放到模型面前 就是全部的游戏，而检索就是你做到这一点的方式。那个要求没有在死去——满足它的工具只是在不断变好，而这 恰恰是「死」的反面。

底线

「RAG 已死」在每次窗口变大时都会回来，也每次都没抓住重点：它杀死一种技术，然后宣布问题已解决，而那个 问题——正确的上下文，便宜，可追溯——恰恰和以往一样活着。

当实现在更替时，别把需求也一起退休了。当你听到「X 已死」，问一问 X 当初解决了什么问题——以及那个问题 是不是真的去了哪里。通常它哪儿也没去。