上个月读到一篇在 Hacker News 上引发热议的文章——《The RAG Obituary: Killed by Agents, Buried by Context Windows》。作者 Nicolas Bustamante 是金融科技公司 Fintool 的创始人他在文中抛出了一个颇具争议的观点RAG检索增强生成正在走向死亡。作为一个折腾过各种 AI 应用的人这篇文章让我深有共鸣。今天想把原文的核心观点翻译分享同时聊聊我自己的实践和看法。一、RAG 的诞生一个时代的妥协把时间拨回 2022 年底。ChatGPT 横空出世但人们很快发现了一个致命问题GPT-3.5 的上下文窗口只有 4096 个 token大约是 6 页纸的内容。而现实世界的文档呢一份 SEC 的 10-K 年度报告大约 51,000 token130 多页。这意味着即便用上当时最先进的 GPT-48K 上下文你也只能看到不到 16% 的内容。RAG 应运而生。它的思路很直观既然读不完那就先搜索把最相关的片段找出来喂给模型。这个模式借鉴了搜索引擎——就像 Google 给你 10 个蓝色链接RAG 也检索最相关的文档片段让 LLM 来总结。本质上是把大语言模型变成了「高级搜索结果摘要器」。二、RAG 的层层困境作者在文中详细剖析了 RAG 的复杂性每一个环节都暗藏陷阱。1. 分块切下去的每一刀都是伤害文档必须被切成 400-1000 token 的小块。问题是这不是简单的「每 500 字一刀切」。想象一下一份财报的结构Item 1: 业务概述10-15 页Item 1A: 风险因素20-30 页Item 7: 管理层讨论30-40 页Item 8: 财务报表40-50 页一刀切下去收入确认政策被切成 3 段风险因素的解释断在半句表格的标题和数据分离管理层讨论和数字脱节。2. 向量搜索相似不等于相关把文本变成 1536 维的向量用余弦相似度找最接近的——理论上很优雅实践中很头疼。作者举了一个真实案例查询「公司的诉讼敞口有多大」RAG 返回了 50 个包含「litigation」的片段告诉你诉讼敞口是 $500M。但实际上$500M 在诉讼程序章节$700M 在或有事项附注里标注「单独看不重要」$1B 是后续事件中的新集体诉讼$800M 是赔偿义务在不同章节$2B 在脚注里的「可能损失」关键词是 probable 而非 litigation实际敞口是 $5.1BRAG 只找到了 1/10。3. 混合搜索与重排序复杂度爆炸为了弥补向量的不足大家开始用「混合搜索」——BM25 关键词搜索 向量语义搜索再用 RRF倒数排名融合合并结果。这还没完还得加个「重排序」模型把 Top 100 的结果再排一遍选出最相关的 10 个给 LLM。每个环节都在增加延迟、成本和故障点。作者称之为「级联故障问题」分块可能失败切坏表格Embedding 可能失败相似度不准BM25 可能失败术语不匹配融合可能失败权重调错重排序可能失败优先级错误错误层层叠加最后的结果离真相越来越远。三、转折Claude Code 的启示真正让作者意识到 RAG 可能不是唯一解的是 Anthropic 去年发布的 Claude Code。Claude Code 是一个在终端运行的 AI 编程助手。它没有 RAG却比 Cursor当时最优秀的 RAG 驱动产品更快、更好。它用什么grep、glob和文件系统工具。GrepRipgrep毫秒级正则搜索无需索引Glob按文件名模式发现文件Task Agents自主多步探索按需加载文件Claude Code 不检索而是调查并行运行多个搜索从宽泛到精确跟随引用和依赖自然地构建理解。作者贴出了一个令人震惊的对比一个简单的 TXT 文件URL 描述在代码理解任务上打败了复杂的 RAG 系统。LLMs 把 RAG 脚手架当早餐吃掉了。四、上下文窗口的革命这一切之所以可能是因为上下文窗口的爆炸式增长年份模型上下文2022-2024GPT-48K (~12页)2025Claude Sonnet 4200K (~700页)2025Gemini 2.51M (~3000页)2025Grok 4-fast2M (~6000页)2M token 可以装下一家公司一整年的 SEC 财报。Sam Altman 暗示未来可能达到十亿级上下文。当 LLM 能装下整个代码库、整个文档库时搜索就变成了导航不需要检索片段直接加载完整文件不需要相似度匹配用精确命中不需要重排序跟随逻辑路径不需要 Embedding直接访问原始内容五、我的实践用 grep 替代向量库读到这篇文章时我正在用 OpenClaw 搭一个轻量级知识问答系统。场景很简单把教材和题库放在本地用户提问时实时检索相关内容拼到 prompt 里让模型回答。按传统思路这事应该用 RAG——分块、建向量库、存数据库。但半年前大家还在讨论 RAG 不要自己建直接用服务即可。这和我想要的「本地优先」背道而驰。所以我换了个思路效仿 Claude Code直接用 pdfgrep 搜索 PDF 文件。没有向量库没有分片没有数据库甚至没有预处理步骤。这看起来很「土」但它像人找东西一样翻文件、CtrlF、看上下文不搞复杂索引。低成本、快速验证几个小时就能跑起来。后来我在 Hacker News 上看到那篇《RAG 的墓志铭》恍然大悟原来大家在讨论同一件事。六、两种方案的对比我把两种方案放在一起对比差异一目了然维度Agent grep 式检索传统 RAG 向量库前置工程量几乎为零分块、Embedding、数据库部署自建速度几小时可用数天到数周Token 消耗高命中段落整段塞 prompt低只返回相关片段检索精度依赖关键词命中模糊匹配弱语义相似度匹配召回率高响应延迟全文搜索文件越大越慢索引查询毫秒级返回维护成本无额外依赖文件更新即生效需维护向量库、重建索引本地友好度天然本地零外部服务通常依赖数据库或云服务七、RAG 真的死了吗说「RAG 已死」当然是一句夸张的墓志铭。现实是工程化还在只是被迫和 Agent 模式重新分工。每个激进的观点都可能在博眼球世界或许正在变革但这终究是一个 trade-off。RAG 给了我们在「不值得建向量库」的场景里用最朴素方式解决问题的选择。而 Agent 给了我们「当上下文足够时直接读全文」的选择。未来的 AI 搜索系统可能不再是单一的检索管道而是灵活的工具箱小规模、探索性任务 → grep 式导航大规模、高频查询 → 传统 RAG 索引复杂推理 → Agent 自主调查检索没有死只是被降级了。它从唯一的解决方案变成了众多工具中的一个。写在最后作为开发者我喜欢这种变化。它意味着我们可以根据场景选择最合适的方案而不是被某种「最佳实践」绑架。当 GPT-3.5 只有 4K 上下文时RAG 是必须的。但当 Claude 能装下 200K、Gemini 能装下 1M 时问题变成了我们真的需要那么复杂的检索管道吗也许有时候最朴素的方案就是最好的方案。本文部分观点翻译自 Nicolas Bustamante 的《The RAG Obituary》原文链接https://www.nicolasbustamante.com/p/the-rag-obituary-killed-by-agents如果这篇文章对你有启发欢迎点赞、在看、转发三连你的支持是我持续写作的动力。我们下期再见 这里给大家精心整理了一份全面的AI大模型学习资源包括AI大模型全套学习路线图从入门到实战、精品AI大模型学习书籍手册、视频教程、实战学习、面试题等资料免费分享扫码免费领取全部内容1. 成长路线图学习规划要学习一门新的技术作为新手一定要先学习成长路线图方向不对努力白费。这里我们为新手和想要进一步提升的专业人士准备了一份详细的学习成长路线图和规划。可以说是最科学最系统的学习成长路线。2. 大模型经典PDF书籍书籍和学习文档资料是学习大模型过程中必不可少的我们精选了一系列深入探讨大模型技术的书籍和学习文档它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。书籍含电子版PDF3. 大模型视频教程对于很多自学或者没有基础的同学来说书籍这些纯文字类的学习教材会觉得比较晦涩难以理解因此我们提供了丰富的大模型视频教程以动态、形象的方式展示技术概念帮助你更快、更轻松地掌握核心知识。4. 2026行业报告行业分析主要包括对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。5. 大模型项目实战学以致用当你的理论知识积累到一定程度就需要通过项目实战在实际操作中检验和巩固你所学到的知识同时为你找工作和职业发展打下坚实的基础。6. 大模型面试题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我们将提供精心整理的大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。7. 资料领取全套内容免费抱走学 AI 不用再找第二份不管你是 0 基础想入门 AI 大模型还是有基础想冲刺大厂、了解行业趋势这份资料都能满足你现在只需按照提示操作就能免费领取扫码免费领取全部内容