长上下文窗口，代理升级，RAG 死了吗？

机器之心报道 机器之心编辑部 在技术快速更新迭代的当今世界，“○○已死”的论调时常出现。 “搜索已死”和“提示已死”的声音依然存在，而现在指责的矛头直指 RAG。矢量数据库 Chroma 的创始人兼首席执行官 Jeff Huber 在播客和采访中表示，“RAG 已死，上下文工程将继续存在”，并主张用上下文工程框架取代对“RAG”一词的密切依赖。 RAG 并不是许多 AI 应用程序开发人员所熟悉的东西。自 2022 年以来，RAG 作为“附加”知识库解决方案迅速成为行业标准，解决了 LLM 输入长度有限的问题（例如 GPT-3.5 中的 4K 令牌）。它的中心逻辑就像搜索引擎的中心逻辑。它将巨大的文档分成更小的部分，使用向量嵌入和相似性搜索找到与用户问题最相关的部分，并将它们发送给法学硕士以生成答案。 RAG作为近年来最流行的LLM申请范式之一，似乎面临着生存危机。它的中心地位受到长上下文窗口的兴起和代理能力的演变的挑战。那么RAG真的已经过时了吗？我们从三篇具有代表性的文章中整理了业界对RAG“生死问题”的各种回应。 RAG 已死，代理恢复万岁博客文章：RAG 已死，代理恢复万岁博客地址：https://www.llamaindex.ai/blog/rag-is-dead-long-live-agentic-retrieval 基础设施巨头 RAG LlamaIndex 的这篇文章提供了一个进化的视角。我们认为 RAG 不会被取代。相反，我们相信人工智能代理正在经历一个进化阶段，它们将成为一个新的、更强大的 RAG 架构的核心。现代人工智能工程师必须掌握许多复杂的数据检索技术，包括混合搜索、CRAG 和 Self-R股份公司。作者以 LlamaCloud 搜索服务为例，系统地演示了如何逐步构建一个完全由代理驱动的高级搜索系统，该系统可以从基本的 RAG 智能地查询多个知识库。第一阶段：基本搜索“Top-k” 这是RAG技术的起点。它的工作原理是这样的：文档被分成几个“片段”（fragments）。这些块的嵌入存储在向量数据库中。当用户执行查询时，系统会计算查询嵌入并在数据库中找到最相似的查询。 k 个块用作上下文并提供给 LLM 以生成响应。作者还指出，除了默认的逐块恢复（块模式）之外，LlamaCloud 实现还提供了两种额外的文件级恢复模式： files_via_metadata：如果在查询中明确提及文件名或路径（例如，“文件 2024_MSFT_10K.pdf 说了什么？”），此模式将检索 ent直接 ire 文件。 files_via_content：当查询是关于某个主题的广泛问题，但需要整个文档作为上下文时（例如，“微软的财务未来是什么？”），此模式根据内容的相关性检索整个文档。第二阶段：部署轻量级代理——自动路由模式 在实际应用中，系统通常无法预测用户会问什么类型的问题。为了解决这个问题，作者引入了一种名为“auto_routed”的搜索模式。这种模式本质上是一个轻量级的代理系统。我们首先分析用户查询，然后在三种模式之间进行选择：片段，智能确定是否使用files_via_metadata或files_via_content进行恢复）。这使您可以在单个知识库中自动执行搜索策略。第三阶段：扩展到多个知识库：复杂的搜索API 当系统需要处理多种不同格式的文档时（财务报告的PDF、会议的PPT、客户的需求）服务记录等），将它们全部放在一个索引中并使用相同的分析规则进行处理是低效的。更好的方法是为每种文档类型创建单独的、高度优化的索引。为了允许同时查询这些分布式知识库，作者引入了“合并搜索 API”。其主要特点是： 多索引集成：您可以将多个独立索引（例如“财务报告索引”或“滚动索引”）添加到复合跟踪器中。智能路由：通过为每个子索引提供描述（例如，“对于公司财务报告”），复合搜索功能利用代理层来分析用户的查询并将其路由到最相关的子索引。结果排序：收集所有查询索引的结果并排序，最终返回n个最相关的结果。第四阶段：构建完全智能体驱动的知识体系。最终目标作者的目标是将以上技术整合起来构建一个完全自动化的搜索系统，代理在每个链接上做出智能决策。该系统的工作流程形成了两层Agent架构。顶级代理（复合搜索引擎）：代理收到用户的查询后，首先执行LLM分类以确定查询与哪个知识库（子索引）最相关，然后下发查询。例如，如果你看“2024年”，第四季度财报的收入增长是多少？然后，顶级代理将识别关键字“财务报告”并将查询更改为financial_index.patha。下标层代理（自动路由模式）：当特定下标收到查询时，会以自动路由模式启动内部代理，该代理会分析查询的具体意图。查询并决定在索引内使用最合适的检索方法（无论是按块检索、按文件名检索还是按内容检索）。例如，给定上面的查询，下标代理可以判断这是一个关于具体信息的问题，选择片段模式以准确检索片段。通过这种分层代理方法，系统可以以高度动态和智能的方式响应复杂多样的用户查询，在正确的时间、从正确的知识库以正确的方式检索最准确的上下文。作者的结论是，简单的 RAG 已经过时，代理驱动的搜索才是未来。这样，具有分层智能能力的高级搜索服务就成为高级人工智能代理必不可少的“知识支柱”。别再说 RAG 是 muerto 博客文章：别再说 RAG 已死 博客地址：https://hamel.dev/notes/llm/rag/not_dead.html 该博客的主要作者是 Hamel Husain，他是一位高级机器学习工程师，曾在 GitHub 等知名公司工作。还有爱彼迎。本文由六个部分组成。作者邀请了几位专家系统地讨论了为什么RAGs不仅不被设计广告，但正在以前所未有的重要性发展成为创建可靠和高效的人工智能应用程序的核心工程学科。第 1 部分 2：重新定义 RAG 和评估范式 Ben Clavié（RAGatouille 的作者）和 Nandan Thakur（BEIR，FreshStack 的参考架构师）首先澄清了基本的误解。 Clavié 认为，将所有信息放在一个长上下文窗口中既不经济也不高效，这是不切实际的。他指出，这不切实际。 RAG（为模型学提供训练期间不可见的外部知识）的本质是持续的需求。我们正在告别简单的单向量语义搜索，并使用更高级的搜索技术更新 RAG，就像我们使用 CSS 更新 HTML 一样。塔库尔颠覆了传统的评价体系。他认为，BEIR等为传统搜索引擎设计的基准测试的目标是“找到最佳答案”，这与传统搜索引擎不相容。RAG 的目标。 RAG 系统的搜索目标应该是： 覆盖范围：我们是否找到了生成答案所需的所有事实证据？多样性：是否避免了信息重复，是否有效地提供了不同方面的信息？相关性：获得的信息是否相关？为此，它设计了 FreshStack 基准测试，为衡量现代 RAG 系统的实际性能提供了新标准。第 3 部分 4：新一代搜索模型：推理、无损压缩 Orion Weller（约翰霍普金斯大学）和 Antoine Chaffin（LightOn）介绍了两种创新的搜索模型范例，使搜索者能够独立“思考”。韦勒的研究将大规模模型的推理和指令跟踪能力直接融入到搜索过程中。他展示了两个模型。 Prompttriever：一种“命令感知”双编码器模型，可以理解和执行复杂的指令，例如“搜索d”这可以让你发现传统模型无法达到的结果。Rank1：可以生成显式推理链的Reranker模型。使用“思维过程”来确定相关性，不仅提高了准确性，而且还发现了许多以前被基准测试忽略的有效文档。Chaffin指出了单向量搜索的主要缺陷：信息压缩的损失。它没有将整个文档压缩为 向量，而是使用“惰性”交互模型（例如 ColBERT）。这使得只有 1.5 亿个参数的小型模型在推理密集型任务上的性能优于具有 70 亿个参数的大型模型。与此同时，PyLate 等开源库的到来使得这项强大的技术比以往任何时候都更容易使用。第 5 部分 6：架构演变：从单一地图到智能路由和上下文工程 在最后两部分中， 布莱恩·比绍夫 (Bryan Bischof) 和阿尤什·乔拉西亚 (Ayush Chaurasia)，以及Chroma 的 Kelly Hon 将镜头从模型本身提升到系统架构和工程实践。 Bischof 和 Chaurasia 认为我们不应该再寻找模型或“完美”的嵌入表示。正确的方法是创建相同数据的多种表示形式，就像您拥有同一位置的多个具有不同特征的地图（地形图、交通地图等）一样。然后，它使用智能“路由器”（通常是 LLM 代理）来了解用户的意图，并将他们引导至查询的最佳“地图”。他对“语义点画法”的应用生动地展示了这种架构的灵活性和力量。凯莉·洪（Kelly Hong）的研究警告人们不要“长语境的万能”。他提出了“情境腐败”现象。随着输入上下文的增加，特别是在存在模糊信息或“干扰因素”的情况下，大型模型的性能明显变差，即使对于简单的任务也变得不可靠。这表明高级上下文工程和精确搜索比简单地填充上下文窗口更重要。 RAG 讣告：BYAgent 被杀，被长上下文埋葬 博客文章：RAG 讣告：被代理杀死，被上下文埋葬 Windows 博客地址：https://www.nicolasbustamante.com/p/the-rag-obituary-killed-by-agents 本文作者是 Fintool 创始人 Nicolás Bustamante，拥有 10 年构建法律和金融搜索平台的经验。他直言不讳地宣称，RAG 的整个架构正在变得不必要且臃肿的历史包袱。作者指出，RAG架构的根源是一个难以逾越的“原罪”：切片困境。 “切断”RAG 的第一步就是灾难的开始。以复杂的 SEC 10-K 财务报告为例。强制固定长度分割将表标题与数据分开，删除对风险因素的解释，并分离差异。管理相关财务数据问题。尽管作者的公司Fintool开发了保留层次结构、表完整性和交叉引用等先进的分段策略，但这仍然是“在碎片上跳舞”，无法解决物理上下文碎片的根本问题。搜索噩梦：纯矢量搜索在专业领域经常失败。综合模型很难区分“收入确认”（会计政策）和“收入增长”（绩效）等术语的细微差别。这篇文章提供了生动的例子。如果您查询“公司诉讼风险”，RAG 可能只会找到专门提及“诉讼”一词的段落，并报告风险为 5 亿美元。事实上，如果算上或有负债、监控事项和赔偿义务等其他部分，实际风险达51亿美元，相差10倍。无限“补丁”：为了弥补矢量搜索的缺点，业界推出了ced 混合搜索。它将关键字匹配（例如 BM25）与向量语义相结合，并使用 RRF 等算法融合结果。但这还不够。为了提高提交给LLM的最终内容的质量，您应该添加“评级”链接。每增加一条链路都意味着延迟增加、成本增加、系统复杂性呈指数级增加。作者将此描述为“级联故障问题”。链路中的错误逐层增长。基础设施压力巨大：维护生产级 Elasticsearch 集群本身就是一项艰巨的任务，涉及 TB 级索引数据、高昂的内存成本、持续数天的索引重建以及持续的版本控制和优化。作者创造了两项技术进步将直接“杀死”RAG：代理和长 LLM 上下文窗口。 Anthropic 出版的《Claude Code》让作者恍然大悟。他表示，这款编码助手在不使用 RAG 的情况下远远超出了传统方法。秘密就是放弃复杂的索引过程，回归最原始但高效的工具：grep（文本搜索）和glob（文件模式匹配）。这种“代理搜索”范式的工作方式是“探索”而不是“获取”。直接访问而不是索引。 Agent可以直接在文件系统上运行grep来实时、高速地获取信息，无需任何预处理或索引，因此不存在索引延迟。满载而不是碎片：随着 Claude Sonnet 4 的上下文窗口达到 200,000 个，Gemini 2.5 达到 100 万个，Grok 4 代币达到 200 万个，LLM 现在可以直接“读取”整个财务报告和代码库。当您可以阅读整本书时，为什么要满足于几个书签呢？逻辑导航，无相似性匹配：代理可以像人类分析师一样逻辑地导航整个文档。例如，如果一份财务报告写着“参见附注12”，则直接跳至附注12，并根据否的内容跳转至其他相关章节。te，创建一个完整的理解链。作者的结论不是彻底消灭RAG，而是对其进行“降级”。新范式下，RAG将不再是系统的核心架构；它只是代理工具箱中的一个选项。当面对大量需要预选的文档时，智能体首先使用混合搜索（RAG 的核心）进行浅层选择，然后对上下文中最好分类的完整文档进行进一步的分析和推理。结论 这三种观点的结合使我们能够得出明确的结论。这意味着主力Naive RAG实际上已经“死了”。简单的“拆分、向量化、寻找相似点”流程已经无法满足日益复杂的人工智能应用的需求。然而，RAG 本身所代表的中心思想——需要为法学硕士提供准确可靠的外部知识——是永恒的。未来的情况将如下。 RAG 角色变更：RAGs将不再是所有应用程序的默认核心架构，并将“降级”成为代理工具箱的强大组件。这相当于代码解释器、API 调用和文件系统操作等工具。阶段决定架构：即使对于需要从大量非结构化数据中快速评估信息的stageios（例如智能客户服务、企业知识库预评估等），先进的代理驱动和高度工程化的RAG系统也是最佳选择。长上下文优势：在需要对少量结构复杂的文档进行详细推理和分析的场景（例如财务报告分析、法律合同审查），“长上下文窗口+代理检查”范式显示出压倒性的优势。重要的是开发人员了解不同技术范式的优缺点，并能够灵活地将它们组合成最高效可行的方案。根据具体应用场景提出解决方案。一个可靠的解决方案。有关更多详细信息，请参阅原始博客。
特别说明：以上内容（包括图片、视频，如有）均由自有媒体平台“网易号”用户上传发布。本平台仅提供信息存储服务。
注：以上内容（包括图片和视频，如有）由网易号用户上传发布，网易号是一个仅提供信息存储服务的社交媒体平台。