长上下文窗口、Agent崛起，RAG已死？（

1.上下文模式

在技术飞速更新迭代的今天，每隔一段时间就会出现「XX 已死」的论调「搜索已死」、「Prompt 已死」的余音未散，如今矛头又直指 RAG向量数据库 Chroma 创始人兼 CEO Jeff Huber 在播客与访谈中抛出「RAG 已死，上下文工程当立」的表述，主张以上下文工程框架取代对「RAG」这一术语的狭义依赖。

2.显示上下文菜单

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

3.上下文间距

其核心逻辑如同搜索引擎：将庞大文档切分成小块，通过向量嵌入和相似度搜索，找到与用户问题最相关的片段，再喂给 LLM 生成答案作为近几年最炙手可热的 LLM 应用范式之一，RAG 似乎正在经历一场生存危机。

4.上下文容器

长上下文窗口的崛起和 Agent 能力的进化，正在动摇着它的核心地位那么，RAG 真的过时了吗？我们从三篇代表性文章中，梳理了业界对 RAG「生死问题」的不同回答RAG 未死，它在进化为「智能体检索」博客文章

5.上下文数据

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

6.和上下文之间空一行

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

7.上下文切换会发生在哪些时间

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

8.页面上下文对象

作者以 LlamaCloud 的检索服务为例，系统性地展示了如何从基础的 RAG 逐步构建一个能够智能查询多个知识库的、完全由 agent 驱动的高级检索系统第一阶段：基础的「Top-k」检索这是 RAG 技术的起点。

9.常见的上下文选项卡

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

10.上下文选项卡有哪些

作者还提及，在 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