随着大语言模型（LLM）的上下文窗口急剧扩大和代理（Agent）架构的成熟，以检索增强生成（RAG）为核心的AI搜索模式正走向终结。RAG通过将长文档分块并检索相关片段来弥补早期模型上下文窗口小的缺陷，但这种方法存在分块错误、语义搜索不准、缺乏因果理解和维护成本高等固有局限。一种新的范式正在兴起：代理系统利用其巨大的上下文容量，直接使用如 Grep 等简单的文件系统工具进行导航和调查，而非依赖复杂的RAG流程。这种代理式搜索能更好地理解文档结构、进行跨文档分析，提供更精确的答案，并显著降低基础设施成本。最终，RAG将从核心架构降级为代理工具箱中的一个选项，未来的AI搜索将属于能够端到端阅读和推理的代理系统。
RAG的诞生：一个聪明的变通方案
早期的LLM，如GPT-3.5，上下文窗口极小，仅能处理约4096个令牌（token），相当于几页文本。这对于分析动辄上百页的知识库（如一份SEC 10-K财务报告约有51,000个令牌）来说是完全不够的。
这就像通过一个钥匙孔来阅读一份财务报告！
为了解决这个问题，检索增强生成（RAG） 应运而生。其核心思想很简单：如果不能一次性读完所有内容，那就找出最相关的片段，然后让LLM对这些片段进行总结和合成。RAG本质上是把LLM变成了一个复杂的搜索结果摘要器。
RAG的固有缺陷：从理论到实践的噩梦
尽管RAG在理论上很优雅，但在实际应用中却充满了问题，每一步都可能引入错误。
1. 文档分块（Chunking）的难题
将长文档切分成小块是RAG流程的第一步，也是问题的开始。简单的按字数切割会破坏文档的结构和语义完整性。
- 信息分散： 关键信息，如收入确认政策，可能被分割到多个不相连的块中。
- 结构破坏： 财务报表的表头可能与其数据分离。
- 上下文丢失： 管理层讨论的叙述与其引用的财务数据脱节。
即使采用更智能的分块策略，保留文档的层级结构和交叉引用，也无法解决根本问题：我们始终在处理信息的碎片，而不是完整的文档。
2. 语义搜索的不可靠性
RAG通常使用向量嵌入（Embeddings）来进行语义搜索。它将文本块和用户查询都转换为向量，然后在向量空间中寻找相似性。然而，这种方法存在严重缺陷：
- 术语混淆： 嵌入模型难以区分专业术语，例如“收入确认”（会计政策）和“收入增长”（业务表现）。
- 数字不敏感： “$45.2M” 和 “$45,200,000” 的嵌入向量可能完全不同。
- 因果关系缺失： 它无法理解“参见注释12”这类交叉引用，也无法追踪不同财务项目之间的因果联系。
一个典型的失败案例是，当查询“公司的诉讼风险”时，RAG可能只找到明确提及“诉讼”一词的片段，从而报告5亿美元的风险；而实际上，加上或有负债、后续事件和脚注中提到的内容，真实风险高达51亿美元，是RAG结果的10倍。
3. 混合搜索与重排（Reranking）的复杂性
为了弥补纯向量搜索的不足，业界引入了结合关键词搜索（如BM25）的混合搜索。这虽然提高了准确性，但也让系统变得更加复杂。更糟糕的是，检索出的上百个候选块还需要通过一个重排模型（Reranker） 进行二次筛选，以选出最相关的10个交给LLM。
这个额外的重排步骤带来了新的问题：
- 高延迟： 每次查询增加数百甚至数千毫秒的延迟。
- 高成本： 重排服务（如Cohere Rerank）价格不菲，显著增加了每次查询的成本。
- 新的故障点： 增加了一个需要管理和维护的模型，使整个系统更加脆弱。
4. 连锁失败与高昂的基础设施成本
RAG是一个脆弱的系统，其中任何一个环节的失败都会影响最终结果，这就是“连锁失败问题”。
- 分块可能失败。
- 嵌入搜索可能失败。
- 关键词搜索可能失败。
- 混合排序可能失败。
- 重排可能失败。
此外，运行生产级的RAG系统（如Elasticsearch集群）需要巨大的基础设施投入，包括TB级的索引数据、大内存服务器，并且每次模式更改都可能触发耗时数天的重新索引。
新范式：基于代理的调查
随着LLM上下文窗口的爆炸式增长，一种全新的、更简单的范式正在出现。
- 2022-2025 (上下文贫乏时代): GPT-4 (8K令牌), GPT-4-32k (32K令牌)
- 2025及以后 (上下文革命): Claude Sonnet 4 (200K令牌), Gemini 2.5 (1M令牌), Grok 4-fast (2M令牌)
拥有200万令牌的上下文窗口意味着LLM可以一次性读入一家公司全年的SEC文件。这从根本上改变了游戏规则。
Claude Code的启示：搜索即导航
Anthropic发布的Claude Code是一个在终端中工作的AI编码代理。它之所以表现出色，并非因为它有更好的RAG，而是因为它根本没有使用RAG。
取而代之，它使用非常基础但极其高效的文件系统工具：
- Grep (Ripgrep): 极其快速的正则表达式文本搜索工具，无需索引，直接在实时文件上操作。
- Glob: 通过文件名模式快速发现文件，零开销。
- 任务代理: 能够自主地进行多步探索，结合多种搜索策略，并根据发现进行自我修正。
它不进行“检索”，而是进行“调查”。
这种代理式方法证明，当上下文窗口足够大时，AI可以直接加载和阅读完整文件，实时追踪交叉引用，并理解整个文档的结构和关系。
代理如何解决问题
让我们回到之前的财务分析案例。一个代理系统会像人类分析师一样工作：
- 在主要财务报表中搜索“租赁”，发现“参见注释12”。
- 导航到注释12，发现“不包括已终止经营业务（注释23）”。
- 检查注释23，发现额外的20亿美元债务。
- 交叉引用管理层讨论部分，找到管理层的解释。
- 搜索“后续事件”，发现一笔5亿美元的租赁终止。
- 最终答案： 50亿（持续经营）+ 20亿（已终止）- 5亿（已终止）= 65亿美元。
这个过程没有分块，没有嵌入，没有重排。只有基于完整上下文的智能导航。
RAG的谢幕：从核心到工具
RAG就像一个记忆力完美但没有理解力的研究助理。 它只能给你提供提及某个词的段落，但无法告诉你事件的前因后果或隐藏的关联。
代理式搜索则像一个法务会计师。 它系统地追踪信息，理解关系，发现缺失的部分，并在不同文件和时间段之间建立联系。
现代分析需求已经超越了RAG的能力范围：
- 高精度要求： 准确信息比相似内容更重要。
- 跨文档理解： 需要连接多个来源的信息，建立累积性理解。
- 实时性： 信息需要即时处理，没有时间等待索引更新。
RAG是上下文贫乏时代的一个聪明变通方案。它帮助我们渡过了难关，但它始终是一个创可贴。
未来的AI搜索将属于那些能够端到端阅读和推理的系统。赢家不是拥有最大向量数据库的人，而是设计出最聪明的代理来遍历海量上下文并连接其中意义的人。
检索并没有死——它只是被降级了。 RAG将从核心架构变为代理工具箱中的一个选项，而不再是唯一的解决方案。我们正在进入后检索时代。