RAG讣告：被智能体终结，被上下文窗口埋葬

为什么检索增强生成无法在上下文革命中幸存，以及我们所知的分块、嵌入和重排器的终结

我在AI和搜索领域工作了十年。先是建立了Doctrine，欧洲最大的法律搜索引擎，现在正在构建Fintool，一个AI驱动的金融研究平台，帮助机构投资者分析公司、筛选股票并做出投资决策。经过三年使用检索增强生成(RAG)系统构建、优化和扩展LLMs后，我相信我们正在见证基于RAG架构的黄昏。随着上下文窗口的爆炸式增长和基于智能体的架构成熟，我的争议性观点是：我们花费大量时间构建和优化的当前RAG基础设施正在衰落。

检索增强生成的崛起

2022年末，ChatGPT席卷全球。人们开始无休止的对话，委托关键工作，结果发现底层模型GPT-3.5只能处理4,096个token…大约六页文本！

AI世界面临一个基本问题：如何让智能系统处理比它一次能读取的知识库大几个数量级的知识？

答案变成了检索增强生成(RAG)，这种架构模式将在未来三年主导AI。

早期LLMs的数学现实

GPT-3.5可以处理4,096个token，下一个模型GPT-4将其翻倍至8,192个token，大约十二页。这不仅不方便；在架构上是毁灭性的。考虑这些数字：单个SEC 10-K文件包含大约51,000个token（130+页）。

使用8,192个token，你只能看到10-K文件的不到16%。这就像通过钥匙孔阅读财务报告！

RAG架构：技术深度剖析

RAG作为直接从搜索引擎借鉴的优雅解决方案出现。就像Google为你的查询显示10个带有相关片段的蓝色链接一样，RAG检索最相关的文档片段并将其馈送给LLM进行合成。

核心思想非常简洁：如果你不能把所有内容都放入上下文，就找到最相关的部分并使用这些部分。它将LLMs变成了复杂的搜索结果摘要器。

基本上，LLMs不能阅读整本书，但它们可以知道谁在最后死了；方便！

分块挑战

长文档需要被分块，问题就从这里开始。这些可消化的块通常每个400-1,000个token，基本上是300-750个单词。

问题？这不像每500个单词切割那么简单。

考虑分块一个典型的SEC 10-K年度报告。文档具有复杂的分层结构：

• 项目1：业务概述（10-15页）
• 项目1A：风险因素（20-30页）
• 项目7：管理层讨论与分析（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搜索"诉讼"并返回50个块：

• 块1-10：样板风险因素中各种提及"诉讼"
• 块11-20：2019年的历史案例（已解决）
• 块21-30：前瞻性安全港声明
• 块31-40：来自不同部分的重复描述
• 块41-50：通用"我们可能面临诉讼"警告

RAG报告：5亿美元的诉讼（来自法律程序部分） 实际存在的内容：

• 5亿美元在法律程序中（项目3）
• 7亿美元在或有事项注释中（“单独不重要”）
• 10亿美元新集体诉讼在后续事件中
• 8亿美元赔偿义务（不同部分）
• 20亿美元可能损失在脚注中（关键词"可能"不是"诉讼"）

实际风险敞口是51亿美元。是RAG发现的10倍。哎呀！

到2023年末，大多数构建者意识到纯向量搜索不够。

混合搜索：实际有效的复杂性

进入混合搜索：将语义搜索（嵌入）与传统关键词搜索（BM25）结合。这就是事情变得有趣的地方。

BM25（最佳匹配25）是一个概率检索模型，擅长精确术语匹配。与嵌入不同，BM25：

• 奖励精确匹配：当你搜索"EBITDA"时，你得到包含"EBITDA"的文档，而不是"营业收入"或"收益"
• 更好地处理罕见术语：金融行话如"CECL"（当前预期信用损失）或"ASC 606"得到适当权重
• 文档长度归一化：不惩罚较长文档
• 术语频率饱和：“收入"的多次提及不会掩盖其他重要术语

在Fintool，我们构建了一个复杂的混合搜索系统：

1. 并行处理：我们同时运行语义和关键词搜索
2. 动态加权：我们的系统根据查询特征调整权重：
   • 特定财务指标？BM25获得70%权重
   • 概念性问题？嵌入获得60%权重
   • 混合查询？50/50分割并进行结果分析
3. 分数归一化：使用以下方法归一化不同的评分尺度：
   • BM25分数的最小-最大缩放
   • 嵌入的余弦相似度已经归一化
   • 用于异常值处理的Z分数归一化

所以最后，嵌入搜索和关键词搜索检索块，搜索引擎使用互惠排名融合合并它们。RRF合并排名，使得在各个系统中始终出现在顶部附近的项浮得更高，即使没有系统将它们放在第1位！

所以现在你认为完成了吗？但地狱不！

重排瓶颈：RAG的肮脏秘密

这是没人谈论的：即使完成所有检索工作，你还没完成。你需要再次重排块以获得良好的检索，这并不容易。重排器是ML模型，它们获取搜索结果并根据与你的特定查询的相关性重新排序，限制发送到LLM的块数量。

LLM不仅上下文贫乏，而且在处理过多信息时也很困难。减少发送到LLM进行最终答案的块数量至关重要。

重排管道：

1. 使用嵌入+关键词的初始搜索检索获得100-200个块
2. 重排器对前10个进行排名
3. 前10个被馈送到LLM以回答问题

重排的挑战：

• 延迟爆炸：重排为每个查询增加300-2000毫秒。哎哟。
• 成本倍增：它为每个查询增加显著的额外成本。例如，Cohere Rerank 3.5每1,000个搜索单元花费2.00美元，使得重排昂贵。
• 上下文限制：重排器通常处理少量块（Cohere Rerank仅支持4096个token），所以如果你需要重排超过这个数量，你必须将其分割成不同的并行API调用并合并它们！
• 另一个要管理的模型：又一个API，又一个故障点

重排是复杂管道中的又一个步骤。

传统RAG的基础设施负担

我发现RAG困难的是我称之为"级联故障问题"的东西。

1. 分块可能失败（分割表格）或太慢（特别是当你必须实时摄取和分块千兆字节数据时）
2. 嵌入可能失败（错误相似性）
3. BM25可能失败（术语不匹配）
4. 混合融合可能失败（错误权重）
5. 重排可能失败（错误优先级）

每个阶段都会加剧前一个阶段的错误。除了混合搜索本身的复杂性之外，还有一个很少讨论的基础设施负担。

运行生产Elasticsearch并不容易。你需要维护TB+的索引数据以获得全面的文档覆盖，这需要至少128-256GB RAM才能获得体面性能。真正的噩梦来自重新索引。每个模式更改都会强制完全重新索引，对于大型数据集需要48-72小时。除此之外，你还要不断处理集群管理、分片策略、索引优化、缓存调优、备份和灾难恢复，以及经常包含破坏性更改的版本升级。

RAG对复杂文档的基本限制

以下是一些结构性限制：

1. 上下文碎片化

   • 长文档是互连的网络，不是独立的段落
   • 单个问题可能需要来自20+文档的信息
   • 分块永久破坏这些关系

2. 语义搜索在数字上失败

   • “$45.2M"和”$45,200,000"有不同的嵌入
   • “收入增加10%“和"收入增长十分之一"排名不同
   • 充满数字的表格具有较差的语义表示

3. 无因果理解

   • RAG无法跟随"参见注释12”→注释12→附表K
   • 无法理解终止经营影响持续经营
   • 无法追踪一个财务项目如何影响另一个

4. 词汇不匹配问题

   • 公司对同一概念使用不同术语
   • “调整后EBITDA"与"特殊项目前营业收入”
   • RAG基于术语检索，而不是概念

5. 时间盲目性

   • 无法可靠区分2024年第三季度和2023年第三季度
   • 混合当前期间与前期比较
   • 不理解财年边界

这些不是小问题。它们是检索范式的基本限制。

三个月前，我偶然发现了一个让我震惊的检索创新。

智能体搜索的出现 - 新范式

2025年5月，Anthropic发布了Claude Code，一个在终端中工作的AI编码智能体。起初，我对形式因素感到惊讶。一个终端？我们回到1980年了吗？没有用户界面？

那时，我正在使用Cursor，一个擅长传统RAG的产品。我给它访问我的代码库以嵌入我的文件，Cursor在回答我的查询之前在我的代码库中运行搜索。生活很好。但在测试Claude Code时，有一件事很突出：

它更好更快，不是因为它们的RAG更好，而是因为没有RAG。

Claude Code搜索如何工作

代替分块、嵌入和搜索的复杂管道，Claude Code使用直接文件系统工具：

1. Grep（Ripgrep）- 通过文件内容进行闪电般快速的正则表达式搜索

   • 不需要索引。它即时搜索实时文件
   • 完整的正则表达式支持，用于精确模式匹配
   • 可以按文件类型过滤或使用glob模式
   • 返回带有上下文行的精确匹配

2. Glob - 通过名称模式直接文件发现

   • 即时找到像**/*.py或src/**/*.ts这样的文件
   • 返回按修改时间排序的文件（最近性偏差）
   • 零开销——只是文件系统遍历

3. 任务智能体

   • 自主多步探索
   • 处理需要调查的复杂查询
   • 自适应地结合多种搜索策略
   • 逐步构建理解
   • 基于发现自我纠正

顺便说一句，Grep发明于1973年。它如此…原始。而这正是它的天才之处。

Claude Code不检索。它调查：

• 并行运行多个搜索（Grep + Glob同时）
• 从广泛开始，然后根据发现缩小范围
• 自然地跟随引用和依赖关系
• 没有嵌入，没有相似性分数，没有重排

它简单、快速，并且基于一个新的假设：LLMs将从上下文贫乏变为上下文丰富。

Claude Code证明，只要有足够的上下文和智能导航，你根本不需要RAG。智能体可以：

• 直接加载整个文件或模块
• 实时跟随交叉引用
• 理解结构和关系
• 在整个调查过程中维护完整上下文

这不仅比RAG更好——它是一个根本不同的范式。对代码有效的东西也可以对任何非代码文件的长文档有效。

上下文革命：从稀缺到丰富

上下文窗口爆炸使Claude Code成为可能：

2022-2025年上下文贫乏时代：

• GPT-4：8K token（~12页）
• GPT-4-32k：32K token（~50页）

2025年及以后上下文革命：

• Claude Sonnet 4：200k token（~700页）
• Gemini 2.5：1M token（~3,000页）
• Grok 4-fast：2M token（~6,000页）

在2M token时，你可以容纳大多数公司一整年的SEC文件。

轨迹甚至更戏剧性：我们很可能在2027年前走向10M+上下文窗口，Sam Altman暗示未来有数十亿上下文token。这代表了AI系统处理信息方式的根本转变。同样重要的是，注意力机制正在迅速改进——LLMs在跨越巨大上下文窗口时变得更好，能够保持连贯性和焦点，而不会在噪音中"迷失”。

Claude Code洞察：为什么上下文改变一切

Claude Code证明，只要有足够的上下文，搜索就变成了导航：

• 当你可以加载完整文件时，不需要检索片段
• 当你可以使用精确匹配时，不需要相似性
• 当你跟随逻辑路径时，不需要重排
• 当你有直接访问时，不需要嵌入

这令人震惊。LLMs在智能体行为方面变得非常出色，意味着它们可以将工作组织成任务以完成目标。

以下是像ripgrep这样的工具为搜索表带来的东西：

• 无需设置：没有索引。没有开销。只需指向并搜索。
• 即时可用性：新文档在命中文件系统的瞬间即可搜索（无索引延迟！）
• 零维护：没有集群要管理，没有索引要优化，没有RAM要配置
• 极快：对于100K行代码库，Elasticsearch需要几分钟索引。Ripgrep在零准备的情况下在毫秒内搜索它。
• 成本：0美元基础设施成本 vs Elasticsearch的大量$$$

所以回到我们之前关于SEC文件的例子。智能体可以本质上理解SEC文件结构：

• 分层意识：知道项目1A（风险因素）与项目7（MD&A）相关
• 交叉引用跟随：自动跟踪"参见注释12"引用
• 多文档协调：连接10-K、10-Q、8-K和代理声明
• 时间分析：系统地比较逐年变化

对于跨越数千家公司或数十年文件的搜索，它可能仍然使用混合搜索，但现在作为智能体的工具：

• 使用混合检索进行初始广泛搜索
• 智能体为顶部结果加载完整文档
• 在完整上下文中进行深度分析
• 基于发现进行迭代优化

我的猜测是，传统RAG现在只是众多搜索工具之一，智能体总是更喜欢grep和阅读整个文件，因为它们是上下文丰富的，并且可以处理长时间运行的任务。

考虑我们65亿美元租赁义务问题的例子： 步骤1：在主财务报表中找到"租赁” → 发现"参见注释12" 步骤2：导航到注释12 → 找到"不包括终止经营（注释23）" 步骤3：检查注释23 → 发现20亿美元额外义务 步骤4：与MD&A交叉引用 → 识别管理层的解释和调整 步骤5：搜索"后续事件" → 找到资产负债表后5亿美元租赁终止 最终答案：50亿美元持续 + 20亿美元终止 - 5亿美元终止 = 65亿美元

智能体像人类分析师一样跟随引用。没有块。没有嵌入。没有重排。只是智能导航。

基本上，RAG就像一个具有完美记忆但没有理解的研究助理：

• “这里有50段提到债务”
• 无法告诉你债务是否在增加或为什么
• 无法将债务与战略变化联系起来
• 无法识别隐藏义务
• 只是检索文本，不理解关系

智能体搜索就像一个法务会计师：

• 系统地跟踪资金
• 理解会计关系（资产 = 负债 + 权益）
• 识别缺失或隐藏的内容
• 跨时间段和文档连接点
• 用数据挑战管理层断言

为什么智能体搜索代表未来

1. 增加文档复杂性

   • 文档变得越来越长，互连性越来越强
   • 交叉引用和外部链接正在激增
   • 需要一起理解多个相关文档
   • 系统必须跟随复杂的信息轨迹

2. 结构化数据集成

   • 更多文档结合结构化和非结构化数据
   • 必须一起理解表格、叙述和元数据
   • 关系比孤立的事实更重要
   • 上下文决定意义

3. 实时要求

   • 信息需要即时处理
   • 没有时间重新索引或嵌入更新
   • 动态文档结构需要自适应方法
   • 实时数据需要实时搜索

4. 跨文档理解 现代分析需要连接多个来源：

• 主要文档
• 支持材料
• 历史版本
• 相关文件

RAG独立处理每个文档。智能体搜索构建累积理解。

5. 精确性优于相似性

• 精确信息比相似内容更重要
• 跟随引用胜过找到相关文本
• 结构和层次结构提供关键上下文
• 导航胜过检索

证据正变得清晰。虽然RAG在上下文贫乏时代为我们服务得很好，但智能体搜索代表了一个根本的演变。智能体搜索的潜在好处是引人注目的：

• 消除因缺失上下文而产生的幻觉
• 完整答案而不是片段
• 通过并行探索获得更快的洞察
• 通过系统导航获得更高的准确性
• 大幅降低基础设施成本
• 零索引维护开销

关键洞察？复杂文档分析——无论是代码、财务文件还是法律合同——都不是关于找到相似文本。它是关于理解关系、跟随引用和保持精确性。大上下文窗口和智能导航的结合提供了检索单独永远无法提供的东西。

RAG是上下文贫乏时代的聪明变通方法。它帮助我们弥合了小窗口和巨大文档之间的差距，但它始终是一个创可贴。未来不会是关于将文档分割成片段和 juggling 嵌入。它将关于可以导航、推理并在工作内存中保存整个语料库的智能体。

我们正在进入后检索时代。赢家不会是那些维护最大向量数据库的人，而是那些设计最聪明智能体以遍历丰富上下文并跨文档连接意义的人。事后看来，RAG将看起来像训练轮。有用，必要，但临时。

AI搜索的下一个十年将属于端到端阅读和推理的系统。检索没有死——它只是被降级了。