RAG 没有死

梯形图转SCL | 博途AI辅助编程文档 | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

在过去几年中，基于私有知识库构建AI系统遵循了一个几乎可预测的配方：文档变成块，块变成嵌入，嵌入进入向量数据库，top-k检索馈送给模型。这是检索增强生成（RAG）的默认架构，而且有充分的理由——语言是混乱的。用户询问一件事，而相关文档使用完全不同的词汇，嵌入允许系统通过含义而不是确切关键词来检索。

但将此作为每个用例的默认设置隐藏了一个强烈的假设：

系统必须在模型开始推理问题之前决定什么是相关的。

一旦LLM本身可以搜索、检查、完善、跟踪引用并判断何时拥有足够的信息，这个假设就变得摇摇欲坠。一种不同的架构正在出现——称之为代理搜索、代理即检索器或即时上下文加载。名称不如转变重要：

与其构建一个馈送代理的检索器，不如让代理成为检索器。

1、检索过去发生在推理之前

在经典RAG中，LLM从不真正搜索知识库，一个单独的检索系统代表模型搜索它。这划定了一个硬边界：检索器决定模型看到什么，模型在其被传递的任何内容上进行推理。当检索问题被很好理解时，这是有效的。当问题需要探索时，它就变得有限制。

2、代码是最清晰的例子

问一个编码代理："为什么结账有时会创建重复支付？"答案可能不在一个文档中。代理可能需要找到支付处理器，检查事务逻辑，跟踪导入的服务，定位重试处理，检查数据库约束，搜索幂等键，查看测试，并浏览最近的提交。

这不是"找到前5个相似块"的问题，这是一个调查，而调查是迭代的。代理搜索，学习一些东西，这改变了它接下来搜索的内容。它跟踪一个引用，发现另一个文件，更新其假设，最终决定它有足够的信息。

3、核心思想：给模型工具，而不是检索器

与其使用单个检索函数将查询映射到top-k文档，不如给模型工具——glob、grep、read、find、git log、bash——并让它决定如何调查。循环看起来像：计划、搜索、读取结果、更新假设、再次搜索、跟踪引用，并在有足够的信息时停止。

这种变化是微妙但重要的：检索不再是一个单独的管道。它成为代理推理的一部分。

4、为什么这非常适合代码

代码已经携带结构。如果你想知道像process_payment()这样的函数位于何处，精确搜索几乎是完美的，不需要跨数千个块计算语义相似性。从那一个命中开始，代理可以遍历存储库：process_payment()导致PaymentService，它导致TransactionManager，然后是retry_transaction()，然后是幂等键。这与检索五个语义相似的块并希望正确的链在其中非常不同。

5、Claude Code示例

一个更引人注目的例子来自Claude Code。据其创造者称，早期版本尝试了RAG和本地向量数据库，但团队发现使用普通搜索工具的代理在编码任务上表现得更好。教训不是简单的"grep胜过嵌入"。它更深层：

一个足够强大的模型可以使用廉价的搜索原语来动态执行检索。

这带来了三个具体优势。

新鲜度——使用嵌入，每次更改都意味着检测、重新分块、重新嵌入和更新索引。使用直接文件系统搜索，代理只需读取当前文件；没有索引需要同步，因为源是真实来源。对于每秒更改一次的存储库，这很重要。

精确标识符——"calculate_tax()在哪里实现？"这不是语义查询；它是标识符查找。代码充满高度可搜索的符号——函数和类名、导入、文件路径、配置键、API路由、数据库表、环境变量——词法搜索在此大放异彩。

完善——这是最重要的。第一次搜索返回payment_service.py；代理读取它并找到TransactionManager的导入；它搜索那个，落在transaction_manager.py中，发现retry_transaction()，然后再次搜索。搜索、观察、更新、再次搜索，这是一个静态top-k步骤自然没有的反馈循环。

6、检索成为策略

这是一个更清晰的方式来框定差异。传统RAG问："哪些文档与此查询相似？"代理检索问："接下来应该搜索什么？"这是一个根本不同的问题，因为检索系统现在有一个决策策略，检索过程本身包含推理。决定搜索什么、使用哪个工具、结果是否有用以及何时停止，是一个比固定检索器连接到LLM更通用的架构。

这也是为什么"代理即检索器"比"无向量RAG"更好的标签。真正的问题从来不是向量与无向量，而是谁控制检索。

7、即时上下文加载

Anthropic描述了一个密切相关的想法：不要将所有可能相关的内容都塞进上下文窗口。给代理轻量级引用，并让它仅在实际需要时加载信息。与其预先将100,000个文件预处理成分块，不如暴露轻量级引用，让代理决定，加载它需要的特定部分，进行推理，并在必要时加载更多。

这将检索直接与上下文工程联系起来。目标不是最大化进入上下文的信息量，而是最大化信噪比。

因为更多上下文并不自动更好。如果检索返回20个块，只有5个有用，模型仍然接收所有20个，烧毁上下文、注意力和令牌，并让无关文本干扰有用文本。代理系统增量构建上下文：搜索，读取一个文件，再次搜索，再读取两个，忽略其余部分。这更接近人类工程师实际工作的方式。

但这不是更昂贵吗？

是的，这是炒作需要反驳的地方。向量数据库非常便宜地回答查询。代理可能需要搜索、读取、搜索、读取、推理，然后在回答之前再次读取，每一步都消耗令牌和延迟。诚实的权衡如下：

向量RAG为您提供预计算的检索和低的、可预测的成本和延迟。它需要索引和持续同步以保持新鲜，它在语义相似性方面很强大，并且可以很好地扩展到非常大的语料库。

代理检索为您提供动态检索，通常没有索引维护，自然新鲜的结果，以及在精确标识符和多步探索方面的真正优势。代价是更高的令牌成本和延迟，在大型语料库上可能变得昂贵。

向量搜索没有死。它正在成为几种检索原语之一。

8、混合未来更有趣

最强大的架构可能不是向量或代理，而是一个可以访问词法、语义和结构化搜索以及数据库、文档和git历史记录的代理，并为每个问题选择正确的工具。"process_payment()在哪里定义？"需要grep。"找到此接口的所有实现"需要结构化或AST搜索。"系统对重试策略说了什么？"需要语义加关键字搜索。"上个月支付流程中发生了什么变化？"需要git历史记录。代理成为检索的编排者。

9、结构化搜索：缺失的中间层

关键字搜索和嵌入之间有一个有用的层次。问："找到每个调用fetch()然后用.then()处理结果的函数。"普通grep查找文本；嵌入查找概念；但两者都不真正理解程序结构，AST感知工具可以。这给出了一个清晰的光谱：词法回答"什么包含这个确切符号？"，语义回答"什么谈论这个概念？"，结构回答"什么具有这个确切代码模式？"一个有能力的代理决定使用哪个层次。

10、MCP将检索转变为工具层

模型上下文协议添加了另一部分。与其将检索视为"向量数据库"，不如将其视为工具——文件系统、数据库、GitHub、Sentry、Slack、CRM、文档、可观察性——每个都暴露代理可以调用的能力。关键抽象：

代理不需要每个数据源看起来都像向量数据库。它只需要每个数据源的有用接口。

这是最大的架构后果：检索层正在成为工具层。在旧堆栈中，应用程序位于RAG管道上，位于嵌入模型上，位于向量数据库上，位于文档上。在新兴堆栈中，应用程序位于一个代理上，该代理在搜索、数据库和API之间进行选择，决定如何获取信息而不是接收其固定切片。

11、代理检索有真正的失败模式

我们不应该用一种教条换取另一种。代理搜索有真正的弱点。

令牌成本——多个工具调用意味着更多推理。如果用户针对稳定的10,000文档知识库问"我们的退款政策是什么？"，一个好的向量索引可以便宜地回答它，而自主调查是多余的。

延迟——向量查询返回很快；几个连续的代理操作则不会。当用户期望接近即时响应时，这很重要。

大型语料库——动态搜索数百万文档并非免费。在大规模上，预计算索引对于在代理开始之前缩小空间是无价的。

语义查询——如果文档说"服务使用指数退避自动重试失败的请求"，用户问"当API调用失败时系统如何恢复？"，可能存在零词汇重叠。语义检索弥合了词汇差距；代理可以通过多次搜索来补偿，但这成本更高。

12、你应该实际构建什么？

停止问"我应该使用RAG吗？"开始问"我有什么样的检索问题？"

当语料库大且稳定、语义相似性重要、查询独立、延迟重要且检索必须便宜时使用向量搜索。

当数据频繁更改、精确标识符重要、源之间的关系重要、工作需要多个步骤或维护索引在操作上昂贵时使用代理检索。

当您使用源代码并且语法、定义和关系重要时使用结构检索。

当语料库很大且查询变化时使用混合检索——有些是词法的，有些是语义的，有些是调查性的。对于大多数严重的生产系统，混合是实际答案。

13、层的转变：从检索到搜索策略

一旦检索成为工具调用，您就可以训练模型更好地执行此操作。这就是为什么Search-R1等研究很有趣：不是提示"必要时搜索"，而是教模型何时搜索、发出什么查询、运行多少搜索、何时完善以及何时停止。检索成为一种学习策略。更好的嵌入模型全局改进检索；更好的检索策略可以根据实际任务调整其行为。

它反映了人类工程师调试大型代码库的方式。他们不是从要求十个最接近的代码块开始，而是形成假设，搜索，检查，修改，跟踪引用，查看测试，查看历史，并在证据足够时停止。代理检索赋予模型同样主动的信息收集能力，不是因为模型神奇地理解一切，而是因为系统允许它与信息交互，而不是接收静态切片。

14、RAG的真正演变

未来不是"RAG已死"。这是一个进展：RAG，然后是代理RAG，然后是工具驱动的检索，然后是混合检索，最终是学习的检索策略。向量数据库不会消失；它的角色改变了。它不再是检索系统，而是成为检索系统可用的工具之一，AI代理在中心选择词法搜索、向量搜索、AST搜索、数据库、API、git历史记录和内存。代理不再位于检索管道的末端。它控制它。

15、这对2026年的AI工程师意味着什么

不要因为每个RAG教程都是这样开始的，就条件反射地使用嵌入、向量数据库和top-k。首先问：数据是什么——代码、文档、日志、事务、结构化记录？它多久更改一次——秒、小时、月？用户会问什么——精确的、语义的、多跳的、调查性的？检索可以有多昂贵——毫秒、秒、分钟？代理需要探索吗？如果是，给它工具。如果没有，更简单的检索器可能更好。

要点不是"不要使用向量数据库"。它更简单：

不要让检索比问题要求的更静态。

如果问题是静态的，使用静态检索器。如果是动态的，让检索是动态的。如果是结构化的，使用结构搜索。如果是语义的，使用语义搜索。如果需要调查，赋予代理调查的能力。

多年来，我们将检索视为发生在智能之前的事情：系统搜索，然后模型推理。代理搜索颠覆了这一点，模型推理它需要什么，检索它，检查结果，调整其策略，并继续直到它有足够的证据。这不会使向量数据库过时。它使它们不那么神圣，这是AI工程更健康的方向。

未来不是向量RAG与代理搜索的对立。它是一个代理，具有适合问题的正确检索工具——有时是grep，有时是向量数据库，有时是AST解析器，有时是SQL，有时是web搜索。有趣的部分不再是您选择了哪种检索技术。而是您的代理知道何时使用每一种。

检索不必是管道。它可以是一种能力。

原文链接：RAG Is Not Dead. Retrieval Is Becoming Agentic.

汇智网翻译整理，转载请标明出处