RAG进化与革新：智能体检索的未来

在科技迅猛发展的今天，每隔一段时间都会听到「XX已死」的论调。「搜索已死」、「Prompt已死」的余音未了，如今矛头又直指RAG。

向量数据库Chroma创始人兼CEO Jeff Huber在播客与访谈中提出了「RAG已死，上下文工程当立」的观点，主张以上下文工程框架取代对「RAG」这一术语的狭义依赖。

对于众多AI应用开发者而言，RAG并不陌生。自2022年以来，为解决LLM输入长度有限（如GPT-3.5的4K tokens）的问题，RAG作为一种「外挂」知识库的解决方案，迅速成为行业标准。

其核心逻辑如同搜索引擎：将庞大文档切分成小块，通过向量嵌入和相似度搜索，找到与用户问题最相关的片段，再喂给LLM生成答案。

作为近几年最炙手可热的LLM应用范式之一，RAG似乎正在经历一场生存危机。长上下文窗口的崛起和Agent能力的进化，正在动摇着它的核心地位。

那么，RAG真的过时了吗？我们从三篇代表性文章中，梳理了业界对RAG「生死问题」的不同回答。

RAG未死，它在进化为「智能体检索」

• 博客文章：RAG is dead, long live agentic retrieval
• 博客地址：https://www.llamaindex.ai/blog/rag...

来自RAG基础设施巨头LlamaIndex的这篇文章提供了一种演进主义的视角。它不认为RAG正在被替代，而是正在经历一个演进阶段，其中AI智能体成为一种全新的、更强大的RAG架构的核心。

文章指出，RAG技术已经超越了早期「朴素的区块检索」阶段，进入了一个以「Agentic策略」为核心的新时代。现代AI工程师需要掌握一系列复杂的数据检索技术，如混合搜索、CRAG、Self-RAG等。

作者以LlamaCloud的检索服务为例，系统性地展示了如何从基础的RAG逐步构建一个能够智能查询多个知识库的、完全由agent驱动的高级检索系统。

第一阶段：基础的「Top-k」检索

这是RAG技术的起点。其工作原理如下：

• 将文档分割成多个「区块」（Chunks）。
• 将这些区块的嵌入存储在向量数据库中。
• 当用户提出查询时，系统计算查询的嵌入，并从数据库中找出最相似的k个区块作为上下文，提供给LLM以生成答案。

作者还提及，在LlamaCloud的实现中，除了默认的按区块检索（chunk模式），还提供了两种额外的文件级检索模式：

• files_via_metadata：当查询明确提及文件名或路径时（例如，「2024_MSFT_10K.pdf这份文件说了什么？」），此模式直接检索整个文件。
• files_via_content：当查询是关于某个主题的宽泛问题，但需要完整文件作为背景时（例如，「微软的财务前景如何？」），此模式会根据内容相关性检索整个文件。

第二阶段：引入轻量级agent——自动路由模式

在实际应用中，系统通常无法预知用户会提出哪种类型的问题。为了解决这个问题，作者介绍了一种名为「自动路由」（auto_routed）的检索模式。

该模式本质上是一个轻量级的agent系统。它会首先分析用户的查询，然后智能地判断应该采用上述三种模式（chunk、files_via_metadata或files_via_content）中的哪一种来执行检索。这实现了在单一知识库内的检索策略自动化。

第三阶段：扩展至多个知识库——复合检索API

当一个系统需要处理多种不同格式的文档时（如财报PDF、会议PPT、客服记录等），将它们全部放在一个索引中并用相同的解析规则处理是低效的。更优的做法是为每种类型的文档创建独立的、高度优化的索引。

为了能够同时查询这些分散的知识库，作者介绍了「复合检索API」。其核心功能是：

• 整合多个索引：允许将多个独立的索引（例如，「财报索引」和「幻灯片索引」）添加到一个复合检索器中。
• 智能路由：通过为每个子索引提供描述（例如，「用于公司财务报告」），复合检索器利用一个agent层来分析用户查询，并将其路由到一个或多个最相关的子索引。
• 结果重排：从所有被查询的索引中收集结果，并进行重排序，最终返回最相关的top-n个结果。

第四阶段：构建完全由agent驱动的知识系统

作者的最终目标是将上述技术整合，构建一个在每个环节都由agent进行智能决策的、完全自动化的检索系统。这个系统的运作流程形成了一个双层agent架构：

• 顶层agent（复合检索器）：接收到用户查询后，该agent首先进行LLM分类，判断查询与哪个或哪些知识库（子索引）最相关，并将查询分发下去。