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-is-dead-long-live-agentic-retrieval

来自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分类，判断查询与哪个或哪些知识库（子索引）最相关，并将查询分发下去。

例如，当查询“2024年第四季度财报中的收入增长情况如何？”时，顶层agent会识别出“财报”关键词，并将查询路由至financial_index。

• 子索引层agent（自动路由模式）：当特定子索引接收到查询后，其内部auto_routed模式agent会启动，分析查询具体意图，并决定在该索引内部使用最合适检索方法（是按区块、按文件名还是按内容检索）。

例如，对于上述查询，子索引agent可能会判断这是针对特定信息问题，从而选择chunk模式进行精确区块检索。

通过这种分层agent方法，系统能以高度动态和智能化方式响应复杂多样用户查询，在正确时间、从正确知识库、用正确方式获取最精准上下文。

作者总结道，简单RAG已经过时，智能体驱动检索才是未来。高级检索服务通过这种分层、智能能力，充当着高级AI智能体不可或缺“知识骨干”。

别说RAG已死，它正成为一门严肃的工程学科

• 博客文章：Stop Saying RAG Is Dead
• 博客地址：https://hamel.dev/notes/llm/rag/not_dead.html

这篇博客主要作者是资深机器学习工程师、曾就职于GitHub和Airbnb等知名企业的Hamel Husain。

文章包含6个部分，作者邀请多位专家共同系统性探讨为什么RAG不仅没死，反而正以前所未有重要性，进化为构建可靠、高效AI应用的核心工程学科。

Part 1 & 2: 重新定义RAG与评估范式

Ben Clavié（RAGatouille作者）和Nandan Thakur（BEIR、FreshStack基准测试设计者）首先澄清核心误解。

Clavié指出，将所有信息塞入长上下文窗口在经济和效率上都不切实际。RAG本质（为语言模型提供其训练时未见外部知识）是永恒需求。

我们告别只是幼稚单向量语义搜索，正如用CSS升级HTML，我们正用更先进检索技术升级RAG。

Thakur则颠覆传统评估体系。他认为，像BEIR这类为传统搜索引擎设计基准，其目标是“找到排名第一正确答案”，这与RAG目标不符。

RAG系统检索目标应该是：

• 覆盖率：是否找到了生成答案所需所有事实证据？
• 多样性：是否避免了信息冗余，高效提供了不同方面信息？
• 相关性：检索到的信息是否切题？

为此，他设计FreshStack基准，为衡量现代RAG系统真实性能提供新标尺。

Part 3 & 4: 新一代检索模型：会推理、无损压缩

Orion Weller（约翰霍普金斯大学）和Antoine Chaffin（LightOn）介绍两种突破性检索模型范式，它们让检索器本身具备“思考”能力。

Weller研究将大模型指令遵循和推理能力直接嵌入检索过程。他展示两个模型：

• Promptriever：一个“指令感知”bi-encoder模型，能够理解并执行复杂指令，如“用隐喻寻找关于数据隐私文档”，从而发现传统模型无法触及结果。
• Rank1：一个能生成明确推理链reranker模型，它通过“思考过程”判断相关性，不仅提升准确率，还发现许多被以往基准测试忽略有效文档。

Chaffin则直指单向量检索核心缺陷——信息压缩损失。他介绍“延迟交互”模型（如ColBERT），这种模型不将整个文档压缩成一个向量，而是保留每个token向量表示。

这使得一个仅有150M参数小模型，在推理密集型任务上表现甚至超过7B参数大模型。同时，PyLate等开源库出现，正让这种强大技术变得前所未有易于使用。

Part 5 & 6: 架构的进化：从单一地图到智能路由与上下文工程

最后两部分由Bryan Bischof和Ayush Chaurasia，以及Chroma公司Kelly Hong，将视角从模型本身拉升到系统架构和工程实践。

Bischof和Chaurasia提出，我们不应再寻找那个“完美”嵌入模型或表示方法。正确做法是，为同一份数据创建多种表示，就像为同一个地方准备多张不同功能地图（如地形图、交通图）。

然后，利用一个智能“路由器”（通常是一个LLM Agent）来理解用户意图，并将其导向最合适“地图”进行查询。他们“语义点彩艺术”应用生动展示这种架构灵活性和强大效果。

Kelly Hong研究则为“长上下文万能论”敲响警钟。她提出“上下文腐烂”现象：随着输入上下文增长，尤其在存在模糊信息和“干扰项”时，大模型性能会显著下降，甚至在简单任务上也变得不可靠。这证明精巧上下文工程和精准检索比简单粗暴填充上下文窗口更为重要。

RAG的讣告：被Agent杀死，被长上下文掩埋

• 博客文章：The RAG Obituary: Killed by Agents, Buried by Context Windows
• 博客地址：https://www.nicolasbustamante.com/p/the-rag-obituary-killed-by-agents

这篇文章作者是Fintool创始人Nicolas Bustamante，他拥有十年法律和金融搜索平台构建经验，直言整个RAG架构正成为不必要、臃肿历史包袱。

作者指出RAG架构从根基上就存在难以克服“原罪”：

• 切分的困境：RAG第一步“切块”就是灾难开始。以复杂SEC 10-K财报为例，强制按固定长度切分，会将表格标题与数据分离，风险因素解释被拦腰斩断，管理层讨论与相关财务数据脱钩。作者所在公司Fintool虽开发出保留层级结构、表格完整性、交叉引用等高级切分策略，但这依然是“在碎片上跳舞”，无法解决上下文被物理割裂根本问题。
• 检索的噩梦：纯粹向量搜索在专业领域常常失灵。嵌入模型难以区分“收入确认”（会计政策）和“收入增长”（业务表现）这类术语细微差别。文章举生动例子：当查询“公司诉讼风险”时，RAG可能只找到明确提及“诉讼”字眼段落，从而报告5亿美元风险；而实际上，加上或有负债、后续事项、赔偿义务等其他部分，真实风险高达51亿美元，相差十倍。
• 无尽的“补丁”：为弥补向量搜索不足，业界引入混合搜索，结合关键词匹配（如BM25）与向量语义，并通过RRF等算法融合结果。但这还不够，为提升最终喂给LLM内容质量，还需增加“重排序”环节。每增加一个环节，都意味着延迟飙升、成本叠加以及系统复杂性指数级增长。作者将其形容为“级联失败问题”，任何一环失误都会被层层放大。
• 沉重的基础设施负担：维护生产级Elasticsearch集群本身就是艰巨任务，涉及TB级索引数据、高昂内存成本、耗时数天重建索引以及持续版本管理和优化。

作者认为，智能体（Agent）和LLM长上下文窗口这两项技术进步将直接“杀死”RAG。

作者“顿悟时刻”来源于Anthropic发布Claude Code。他发现这个编码助手在没有使用任何RAG情况下，表现远超传统方法。

其秘诀在于放弃复杂索引管道，回归最原始但极其高效工具：grep（文本搜索）和glob（文件模式匹配）。

这种“智能体搜索”范式工作方式是“调查”而非“检索”：

• 直接访问，而非索引：Agent可以直接在文件系统上运行grep，实时、高速查找信息，无需预处理和索引，也就不存在索引延迟。
• 完整加载，而非碎片：随着Claude Sonnet 4达到200K、Gemini 2.5达到1M、甚至Grok 4-fast达到2M tokens上下文窗口，LLM现在可以直接“读入”整份财报、整个代码库。当你可以阅读全书时，为什么还要满足于几张书签呢？
• 逻辑导航，而非相似度匹配：Agent能够像人类分析师一样，在完整文档中进行逻辑跳转。例如，在财报中看到“参见附注12”，它会直接导航到附注12，再根据附注内容跳转到其他相关章节，从而构建完整理解链条。

作者结论并非要彻底消灭RAG，而是将其“降级”。在新范式下，RAG不再是系统核心架构，而仅仅是Agent工具箱中一个选项。

在面对海量文档需要初步筛选时，Agent可能会先用混合搜索（RAG核心）进行一次粗筛，然后将排名靠前几份完整文档加载到上下文中，进行深度分析和推理。

结语

综合这三种观点，我们可以得出清晰结论：初级、朴素RAG（Naive RAG）确实已经“死亡”。那种简单“切块-向量化-相似度搜索”流程，已无法满足日益复杂AI应用需求。

然而，RAG本身所代表核心思想——为LLM提供精准、可靠外部知识——需求是永恒的。

未来图景更可能是：

• RAG角色转变：RAG不再是所有应用默认核心架构，而是被“降级”为Agent工具箱中一个强大组件。它将与代码解释器、API调用、文件系统操作等工具平起平坐。
• 场景决定架构：对于需要从海量、非结构化数据中快速筛选信息场景（如智能客服、企业知识库初筛），由Agent驱动、高度工程化高级RAG系统仍是最佳选择。
• 长上下文的统治力：对于需要对少量、结构复杂文档进行深度推理和分析场景（如财报分析、法律合同审查），“长上下文窗口 + Agent调查”范式将展现出碾压性优势。

对于开发者，关键在于理解不同技术范式优劣，并根据具体应用场景，灵活将它们组合成最高效、最可靠解决方案。

更多细节请参看原博客。