作者: Nicolas Bustamante
原文: https://www.nicolasbustamante.com/p/the-rag-obituary-killed-by-agents
引言
为什么"检索增强生成"（RAG）无法在"上下文革命"中存活，以及我们所知的切块、嵌入与重排器的终结。
我在 AI 与搜索领域工作了十年。先是创建了 Doctrine，欧洲最大的法律搜索引擎，如今在打造 Fintool，一款面向机构投资者的 AI 金融研究平台，帮助分析公司、筛选股票并做出投资决策。
在花了三年时间构建、优化并扩展基于 RAG 的 LLM 系统之后，我相信我们正目睹 RAG 架构的黄昏。随着上下文窗口的爆炸式增长与基于智能体（agent）的架构成熟，我这个颇具争议的观点是：我们花大量时间打造与优化的现有 RAG 基础设施正在走下坡路。
RAG 的崛起
2022 年末，ChatGPT 席卷全球。人们开始无休止地对话，把关键工作交给它，结果才发现底层模型 GPT-3.5 只能处理 4,096 个 token……大约六页文本！
AI 世界面临一个根本问题：如何让一个智能系统处理比它一次能读的内容大几个数量级的知识库？
答案就是检索增强生成（RAG），这是一种架构范式并在接下来的三年主导了 AI。
早期 LLM 的数学现实
GPT-3.5 能处理 4,096 个 token，下一代 GPT-4 将其翻倍到 8,192 个 token，大约 12 页。这不仅是不便，更是架构层面的灾难。
看一组数字：一份 SEC 10-K 年报大约包含 51,000 个 token（130 多页）。
在 8,192 个 token 下，你最多能看到一份 10-K 的不到 16%。这就像通过钥匙孔读财报！
RAG 架构：技术深潜
RAG 作为一个优雅的解决方案，直接借鉴搜索引擎。就像谷歌会为你的查询展示 10 个相关摘要的蓝色链接，RAG 则检索与你问题最相关的文档片段并喂给 LLM 用于综合。
核心思想很简单：如果你装不下全部上下文，就找最相关的部分来用。它把 LLM 变成了复杂的搜索结果总结器。
本质上，LLM 读不完整本书，却能知道最后谁死了；很方便！
切块的挑战
长文档需要被切成片段，这时问题就开始了。这些可消化的片段通常是 400–1,000 个 token，也就是大约 300–750 个词。
问题在于？并不是每 500 个词切一下就完事。
以一份典型的 SEC 10-K 为例，文档有复杂的层次结构：
- 项目 1：业务概览（10–15 页）
- 项目 1A：风险因素（20–30 页）
- 项目 7：管理层讨论与分析（MD&A，30–40 页）
- 项目 8：财务报表（40–50 页）
如果你每 500 token 机械切块，关键信息就会被打散：
- 收入确认政策被分到 3 个块
- 风险因素解释被切在半句
- 财务表头与数据被拆开
- MD&A 的叙述与其讨论的数字分离
当你搜索"收入增长驱动因素"，可能拿到一个提到增长的块，但错过另一个块里的具体数字，或 MD&A 里第三个块的战略背景！
在 Fintool，我们开发了比简单分割更高级的切块策略：
- 层级结构保留：从项目 1（业务）到更细的子章节（如地域分部），维护树状表示
- 表格完整性：财务表决不拆——利润表、资产负债表、现金流量表与其表头及数据保持原子性
- 跨引用保留：维护叙述部分与相应财务数据之间的链接，保留"参见注释 X"等关系
- 时序连贯性：同比/多期分析保持为单一块
- 脚注关联：通过元数据把脚注与其引用项保持连接
每个块在 Fintool 都被大量元数据丰富：
- 申报类型（10-K、10-Q、8-K）
- 财报期间与报告日期
- 章节层级（项目 7 > 流动性 > 现金头寸）
- 表格标识与类型
- 跨引用映射
- 公司标识（CIK、股票代码）
- 行业分类代码
这能带来更准确的检索，但即便智能切块也无法解决根本问题：我们仍在处理文档碎片，而非完整文档！
一旦有了块，你还需要一种搜索方式。一个方法是对块做嵌入。
嵌入与检索流水线
每个块会被转成一个高维向量（多数嵌入模型是 1,536 维）。这些向量生活在一个空间里，理论上相近概念彼此靠近。
当用户提问时，问题也会被转成向量。系统通过余弦相似度找到最接近问题向量的块。
理论上优雅，实践中则是边角案例的噩梦。
嵌入模型在通用文本上训练，难以处理特定术语。它们能找相似，但分不清"收入确认"（会计政策）和"收入增长"（业务表现）。
例如：查询："公司的诉讼风险敞口是多少？"
RAG 搜索"litigation（诉讼）"并返回 50 个块：
- 1–10：风险因素的套话里各种“诉讼”提及
- 11–20：2019 年的历史案件（已结）
- 21–30：前瞻性“安全港”声明
- 31–40：不同章节的重复描述
- 41–50：通用“我们可能面临诉讼”的警告
RAG 报告：诉讼 5 亿美元（来自“法律程序”章节）
而事实是：
- 法律程序项 5 亿美元（项目 3）
- 或有事项注释 7 亿美元（“单项不重大”）
- 后续事项中新发生 10 亿美元集体诉讼
- 其他章节的 8 亿美元赔偿义务
- 脚注中 20 亿美元“很可能发生的损失”（关键词是“probable”，不是“litigation”）
实际敞口是 51 亿美元。是 RAG 找到的 10 倍。噢不！到 2023 年底，多数构建者都意识到仅靠向量搜索不够。
混合搜索：复杂但有效
于是有了混合搜索：把语义搜索（嵌入）与传统关键词搜索（BM25）结合起来。这就有意思了。
BM25 是一种擅长精确词项匹配的概率检索模型。不同于嵌入，BM25：
- 奖励精确匹配：搜“EBITDA”，就给“EBITDA”，不是“operating income”或“earnings”
- 罕见术语处理更佳：如“CECL”“ASC 606”等财金术语得到合适权重
- 文档长度归一化：不会惩罚长文档
- 词频饱和：多次出现“revenue”不会淹没其他重要词
混合搜索的实现
在 Fintool，我们构建了复杂的混合搜索系统：
- 并行处理：语义与关键词搜索同时运行
- 动态加权：基于查询特征调整权重：
- 特定财务指标？BM25 占 70%
- 概念性问题？嵌入占 60%
- 混合问题？50/50，并对结果分析
- 评分归一化：不同评分尺度归一：
- BM25 用 min-max
- 嵌入余弦相似度本就归一
- 用 Z-score 处理异常值
最终，嵌入与关键词检索的结果通过“倒数名次融合（RRF）”合并。RRF 会让在多个系统中排名靠前的项整体浮到更高，即便没有任何一个系统把它排第 1！
到这就结束了？并没有！
重排瓶颈：RAG 隐秘的痛
没人愿意提的是：在所有检索工作之后，你还没完。你需要再对这些块做一轮重排，才能得到好的检索结果并限制喂给 LLM 的块数，这并不容易。重排器是机器学习模型，会根据你的具体查询对搜索结果重新排序。
LLM 不仅上下文贫，还会在信息过多时表现变差。把送入 LLM 的块数降到最少至关重要。
重排流水线：
- 嵌入 + 关键词初检得 100–200 个块
- 重排器挑出 top 10
- 把这 10 个块喂给 LLM 回答问题
重排的挑战：
- 延迟飙升：每次查询增加 300–2000ms。疼。
- 成本倍增：每次查询都有显著额外成本。例如 Cohere Rerank 3.5 每 1,000 搜索单元 2 美元，价格不菲。
- 上下文限制：重排器通常能处理的块很少（如 Cohere Rerank 仅支持 4096 token），若要重排更多，就得并行多次 API 调用后再合并！
- 又多一个要管的模型：多一个 API，多一个故障点
重排只是复杂管线中的又一环。
传统 RAG 的基础设施负担
我觉得 RAG 的难点在于所谓"级联失败问题"：
- 切块会出错（拆表）或过慢（尤其要实时导入与切分 GB 级数据）
- 嵌入会出错（相似度错配）
- BM25 会出错（词项不匹配）
- 混合融合会出错（权重不佳）
- 重排会出错（优先级错误）
每个阶段都会放大前一阶段的错误。除了混合搜索本身的复杂性，还有常被忽视的基础设施负担。
在生产中运行 Elasticsearch 并不轻松。若要覆盖全面文档，你需要 TB 级索引数据，至少 128–256GB 内存才有不错性能。真正的噩梦是重建索引。每次模式变更都要全量重建，数据大时需要 48–72 小时。此外还要持续处理集群管理、分片策略、索引优化、缓存调优、备份和灾备，以及版本升级中常见的破坏性变更。
RAG 在复杂文档上的根本限制
一些结构性限制：
1. 上下文碎片化
- 长文档是相互交织的网络，不是彼此独立的段落
- 一个问题可能需要 20+ 份文档的信息
- 切块会永久破坏这些关系
2. 语义搜索在数字上失灵
- “$45.2M” 与 “$45,200,000” 的嵌入不同
- “收入增加 10%” 与 “收入增长了十分之一” 排名不同
- 充满数字的表格语义表征很差
3. 缺乏因果理解
- RAG 不会沿“参见注释 12 → 注释 12 → 附表 K”去跟踪
- 不理解“终止经营”会影响“持续经营”
- 不能追踪一个财务项目如何影响另一个
4. 词汇不匹配
- 不同公司用不同术语描述相同概念
- “调整后 EBITDA” vs “扣除特殊项目前的营业利润”
5. 时间盲
- 难以可靠区分 2024Q3 与 2023Q3
- 混淆当期与上期比较
- 不理解财年边界
这不是小问题，而是检索范式的根本局限。
三个月前，我偶然看到一种检索的创新，令我大开眼界。
智能体式搜索的出现：新的范式
2025 年 5 月，Anthropic 发布了 Claude Code，一个在终端里工作的 AI 编码智能体。起初我对这个形态很惊讶。终端？回到 1980 年？没 UI？
那时我在用 Cursor，这是一款擅长传统 RAG 的产品。我给它访问我的代码库做嵌入，Cursor 在回答前会在代码库里搜索。体验不错。但测试 Claude Code 时，有件事让我印象深刻：
它更好更快，原因不是它的 RAG 更好，而是它根本没有 RAG。
Claude Code 的搜索如何工作
它没有使用复杂的切块、嵌入和搜索管线，而是使用直接的文件系统工具：
1. Grep（更准确说 ripgrep）
- 闪电般的正则全文搜索
- 无需索引，直接对实时文件搜索
- 完整 regex 支持，精准匹配
- 可按文件类型/通配模式过滤
- 返回精确匹配及上下文行
2. Glob
- 通过名称模式直接发现文件
- 例如 "/*.py" 或 "src//*.ts"
- 可按修改时间排序（偏向新近）
- 零开销，仅文件系统遍历
3. 任务智能体
- 自主的多步探索
- 处理需要调查的复杂查询
- 自适应组合多种搜索策略
- 逐步构建理解
- 基于发现自我校正
顺带说一句，Grep 发明于 1973 年。如此"原始"。这恰恰是它的妙处。
Claude Code 的调查方法
Claude Code 不做"检索"，而是"调查"：
- 并行运行多种搜索（Grep + Glob）
- 先广后窄，基于发现逐步收敛
- 自然地跟随引用与依赖
- 无嵌入、无相似度分数、无重排
它很简单，很快，而且基于一个新假设：LLM 正从"上下文贫"迈向"上下文富"。
Claude Code 的优势
Claude Code 证明：当上下文足够、导航智能时，你根本不需要 RAG。智能体可以：
- 直接加载整个文件或模块
- 实时跟随交叉引用
- 理解结构与关系
- 在调查过程中保持完整上下文
如这项基准所示，一份包含 URL+描述的简单 TXT 文件胜过复杂 RAG。扎心。这是范式转变；LLM 把 RAG 脚手架当早餐吃掉。
这不仅"优于 RAG"，而是完全不同的范式。对代码有效的方法，同样适用于任何非代码的长文档。
上下文革命：从稀缺到富足
上下文窗口的爆炸让 Claude Code 成为可能：
上下文贫时代（2022–2025）
- GPT-4：8K tokens（约 12 页）
- GPT-4-32k：32K tokens（约 50 页）
上下文革命（2025 及以后）
- Claude Sonnet 4：200k tokens（约 700 页）
- Gemini 2.5：1M tokens（约 3,000 页）
- Grok 4-fast：2M tokens（约 6,000 页）
在 200 万 token 下，你可以装下多数公司一整年的 SEC 申报。
趋势更激进：到 2027 年我们可能迈向 1,000 万+ 的上下文窗口，Sam Altman 甚至暗示未来会有"数十亿"上下文 token。这代表了 AI 系统处理信息方式的根本转变。同样重要的是，注意力机制快速进步——LLM 在巨量上下文中保持连贯与聚焦的能力迅速提升，不再容易被"噪声"搞丢。
Claude Code 的启示：为何上下文改变一切
Claude Code 展示：当上下文足够时，搜索变成“导航”：
- 当你能加载完整文件，就不必检索碎片
- 当你能做精确匹配，就不必做相似度
- 当你能沿逻辑路径前进，就不必重排
- 当你能直接访问，就不必嵌入
令人震撼。LLM 的智能体行为在快速变强，也就是能把工作组织成若干任务以完成目标。
像 ripgrep 这样的工具给“搜索”带来了：
-
无需设置：无索引、无开销，指哪搜哪
-
即时可用：新文档一落盘即可搜索（零索引延迟）
-
零维护：无集群、无索引优化、无内存配置
-
极速：对 10 万行代码，Elasticsearch 建索引要几分钟；ripgrep 毫秒级就能搜，且零准备
-
成本：$0 基础设施 vs Elasticsearch 的不菲成本
回到 SEC 申报的例子。一个智能体可以内在地理解结构：
- 层级意识：知道项目 1A（风险因素）与项目 7（MD&A）的关系
- 跟随交叉引用：“参见注释 12”自动追踪
- 多文档协同：连通 10-K、10-Q、8-K 与委托书
- 时序分析：系统性比较年度变化 当需要跨成千上万家公司或跨数十年申报做搜索时，它也许仍会用混合搜索，但只是作为智能体的工具：
- 先用混合检索做广泛初筛
- 智能体加载 top 结果的完整文档
- 在完整上下文中深入分析
- 基于发现迭代细化 我猜传统 RAG 现在只是诸多搜索工具之一，而智能体会更倾向用 grep 并直接读完整文件，因为它们“上下文富”，还能处理长流程任务。 以“我们 65 亿美元的租赁义务”问题为例： 步骤 1：在主财务报表中查“lease（租赁）” → 发现“参见注释 12” 步骤 2：跳转注释 12 → 发现“剔除终止经营（注释 23）” 步骤 3：查看注释 23 → 发现额外 20 亿美元义务 步骤 4：交叉核对 MD&A → 确认管理层解释与调整 步骤 5：搜索“后续事项” → 发现资产负债表日后 5 亿美元租赁终止 最终答案：持续经营 50 亿 + 终止经营 20 亿 − 终止 5 亿 = 65 亿
智能体像人类分析师那样沿引用线索前进。无切块、无嵌入、无重排，只有智能导航。
RAG vs 智能体式搜索的本质区别
本质上，RAG 像一个记忆完美却不理解的研究助理：
- "这是 50 段提到债务的片段"
- 却不能告诉你债务是否在上升、为何上升
- 不能把债务与战略变化关联起来
- 不能识别隐藏义务
- 只会"取文本"，不懂"关系"
而智能体式搜索像一位法务会计师：
- 系统性地"跟钱走"
- 理解会计关系（资产 = 负债 + 所有者权益）
- 识别缺失或隐藏内容
- 跨时段与跨文档串联线索
- 用数据挑战管理层表述
为何智能体式搜索代表未来
- 文档复杂度上升
- 文档更长、更互联
- 跨引用与外部链接激增
- 需要同时理解多份相关文档
- 系统必须能沿复杂信息路径前进
- 结构化数据融合
- 越来越多文档结合结构化与非结构化内容
- 表格、叙述、元数据需要联动理解
- 关系比孤立事实更重要
- 语境决定意义
- 实时性要求
- 信息需要即时处理
- 无暇等待重建索引或更新嵌入
- 动态文档结构需要自适应方法
- 实时数据要求实时搜索
- 跨文档理解
现代分析需要连接多种来源：
- 主文档
- 支撑材料
- 历史版本
- 相关申报
RAG 将每份文档视为独立。智能体式搜索构建累积性理解。
- 精准胜于相似
- 精确信息比相似内容更重要
- 沿引用线索前进胜于找相关文字
- 结构与层级提供关键上下文
- 导航胜于检索
证据越来越清晰。RAG 在"上下文贫"时代立下汗马功劳，而智能体式搜索是根本性的进化。其潜在收益包括：
- 因缺少上下文导致的幻觉被消除
- 给出完整答案而非碎片
- 通过并行探索更快获得洞见
- 通过系统性导航获得更高准确性
- 大幅降低基础设施成本
- 零索引维护开销
结论：进入"后检索时代"
关键洞见？复杂文档分析——无论代码、财报或法律合同——并不在于寻找"相似文本"，而在于理解"关系"、跟随"引用"，并保持"精确"。大型上下文窗口与智能导航的结合，带来了检索单独一项永远无法实现的能力。
RAG 是"上下文贫"时代的巧妙权宜之计。它帮助我们在微小窗口与海量文档之间搭桥，但始终只是创可贴。未来不会再是把文档切成碎片、 juggling 嵌入向量；而是让能导航、能推理、能把整个语料装进"工作记忆"的智能体来完成。
我们正进入"后检索时代"。胜者不再是拥有最大向量数据库的人，而是能设计出最聪明的智能体，去穿梭于丰富上下文、在文档之间建立意义连接的人。回头看，RAG 将像辅助轮：有用、必要，但终究是过渡。
下一个十年的 AI 搜索将属于能端到端阅读与推理的系统。检索并未死——它只是被降级了。