“RAG已死”并非危言耸听：真正取代它的是Agentic Retrieval

当社交媒体在刷“RAG is dead”时，大多数人以为这只是又一次技术口嗨。但在这场由 Turbopuffer 工程师 Kuba Rogut 分享的演讲里，一个更扎心的事实浮出水面：不是 RAG 失效了，而是它已经跟不上真正严肃的 AI 搜索需求了。

一句“RAG已死”，为什么能点燃整个AI圈

“RAG is dead”之所以刺耳，是因为它戳中了很多团队的现实：系统能跑，但不好用。Kuba 一开场就点破一个反差——社交媒体在唱衰 RAG，但过去两年里，RAG 的搜索热度并没有下降。这意味着什么？不是大家不用了，而是大家都在用，却越来越不满意。

问题不在于检索增强生成（RAG）这个方向错了，而在于我们把 RAG 简化成了“向量搜索 + 一次性把结果塞给 LLM”。在 Demo 里看起来很聪明，在真实世界却经常翻车：检索结果不稳定、上下文浪费、模型一旦理解偏了就全盘皆输。所谓“RAG 已死”，其实是这种幼儿园版本的 RAG 已经不够用了。

RAG vs Agentic Search：差的不是一点点

Kuba 在演讲中做了一个关键澄清：很多人口中的 RAG，本质只是一次性的向量检索；而 Agentic Search，则是把“找资料”这件事交给一个会思考、会试错的 Agent。

在 Agentic Search 里，检索不再是单次调用，而是一个循环：模型先拿到部分上下文，判断是否足够，不够就继续找、换策略、换工具，再回来推理。这种模式听起来复杂，但它解决了一个老大难问题——你不需要一开始就把“所有正确答案”一次性塞进上下文窗口。

Kuba 用一句话总结得很狠：“You don’t need a trillion tokens at once.” 真正高效的系统，是在推理过程中逐步逼近答案，而不是指望第一次检索就命中一切。

Cursor的例子：为什么重投入反而更省钱

为了证明这不是理论游戏，Kuba 拿 Cursor 做了一个拆解。Cursor 会对整个代码库做 embedding，并配合类似加密哈希树的结构，来精准理解代码之间的关系。这听上去成本极高——确实也是。

但有意思的是，对比另一种“每个会话临时 RAG 一把”的方式，Cursor 这种前期重投入的策略，在实际使用中表现更稳定。演讲中提到的 AB 测试显示，语义搜索和更复杂的检索策略，哪怕在数值上提升看起来不夸张，但在真实用户体验中差异非常明显。

更关键的是，很多团队在试过这种模式后，开始从传统 RAG 方案迁移过来。原因很现实：一次性 RAG 的“便宜”，会在无数次失败对话中被加倍偿还。

从“检索增强生成”到“检索即推理”的转折点

在演讲后半段，Kuba 把话题从 RAG 拉到了一个更大的趋势：Agentic Retrieval 正在成为默认选项。对更成熟的客户来说，检索已经不再是管道的一环，而是推理本身的一部分。

这意味着架构思路的变化：你不再设计一个“先找再答”的流程，而是设计一个会不断提问自己的系统。什么时候该扩大搜索范围？什么时候该换关键词？什么时候该停下来开始回答？这些判断，交给 Agent。

RAG 并没有消失，它被拆解、被吸收，成为 Agent 工具箱里的一个基础能力。真正“死掉”的，是把 RAG 当成银弹的幻想。

总结

这场演讲真正有价值的地方，不在于它喊了一句“RAG 已死”，而在于它提醒了一个更现实的判断标准：你的检索系统，是否真的在帮模型思考？如果你还在纠结向量模型选哪个、top‑k 调多少，可能已经落后一个范式了。接下来值得尝试的，是把检索设计成一个可迭代的过程，而不是一次性决策。思考一个问题：如果你的 AI 可以自己决定“接下来该去哪找信息”，你的系统架构，会不会完全不一样？

关键词： RAG， Agentic Search， AI搜索， 向量数据库， Cursor

事实核查备注： 需要核查：1）Kuba Rogut 的职位与公司名称拼写（Turbopuffer）；2）演讲中提到的 AB 测试是否给出具体数值；3）Cursor 使用的具体数据结构描述是否在其官方博客中明确说明；4）Google 搜索趋势的时间范围表述。