大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



 
  
    
     
上个月读到一篇在 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 token（130 多页）。这意味着，即便用上当时最先进的 GPT-4（8K 上下文），你也只能看到不到 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.1B，RAG 只找到了 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，和文件系统工具。

• Grep（Ripgrep）：毫秒级正则搜索，无需索引
• Glob：按文件名模式发现文件
• Task Agents：自主多步探索，按需加载文件

Claude Code 不检索，而是调查：并行运行多个搜索，从宽泛到精确，跟随引用和依赖，自然地构建理解。

作者贴出了一个令人震惊的对比：一个简单的 TXT 文件（URL + 描述）在代码理解任务上，打败了复杂的 RAG 系统。

LLMs 把 RAG 脚手架当早餐吃掉了。

四、上下文窗口的革命

---

这一切之所以可能，是因为上下文窗口的爆炸式增长：

2M token 可以装下一家公司一整年的 SEC 财报。Sam Altman 暗示未来可能达到十亿级上下文。

当 LLM 能装下整个代码库、整个文档库时，搜索就变成了导航：

• 不需要检索片段，直接加载完整文件
• 不需要相似度匹配，用精确命中
• 不需要重排序，跟随逻辑路径
• 不需要 Embedding，直接访问原始内容

五、我的实践：用 grep 替代向量库

---

读到这篇文章时，我正在用 OpenClaw 搭一个轻量级知识问答系统。

场景很简单：把教材和题库放在本地，用户提问时实时检索相关内容，拼到 prompt 里让模型回答。

按传统思路，这事应该用 RAG——分块、建向量库、存数据库。但半年前大家还在讨论 RAG 不要自己建，直接用服务即可。这和我想要的「本地优先」背道而驰。

所以我换了个思路：效仿 Claude Code，直接用 pdfgrep 搜索 PDF 文件。

没有向量库，没有分片，没有数据库，甚至没有预处理步骤。

这看起来很「土」，但它像人找东西一样：翻文件、Ctrl+F、看上下文，不搞复杂索引。低成本、快速验证，几个小时就能跑起来。

后来我在 Hacker News 上看到那篇《RAG 的墓志铭》，恍然大悟：原来大家在讨论同一件事。

六、两种方案的对比

---

我把两种方案放在一起对比，差异一目了然：

七、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大模型学习书籍手册、视频教程、实战学习、面试题等，资料免费分享！

扫码免费领取全部内容

要学习一门新的技术，作为新手一定要先学习成长路线图，方向不对，努力白费。

书籍和学习文档资料是学习大模型过程中必不可少的，我们精选了一系列深入探讨大模型技术的书籍和学习文档，它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。（书籍含电子版PDF）

对于很多自学或者没有基础的同学来说，书籍这些纯文字类的学习教材会觉得比较晦涩难以理解，因此，我们提供了丰富的大模型视频教程，以动态、形象的方式展示技术概念，帮助你更快、更轻松地掌握核心知识。

行业分析主要包括对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

学以致用 ，当你的理论知识积累到一定程度，就需要通过项目实战，在实际操作中检验和巩固你所学到的知识，同时为你找工作和职业发展打下坚实的基础。

面试不仅是技术的较量，更需要充分的准备。

在你已经掌握了大模型技术之后，就需要开始准备面试，我们将提供精心整理的大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

👇👇扫码免费领取全部内容👇👇