推理网博客 智能体搜索 --- Inference.net Blog Agentic Search - 知识铺

RAG 已经触及了天花板，而 RL 训练的智能体刚刚超越了它。

一段时间内，我们只需通过更好的嵌入和重新排序器就能持续改进检索。当时的最佳实践相对简单：通常你会进行稀疏搜索（BM25/SPLADE），密集嵌入搜索，然后使用 RRF（互逆排名融合） 或交叉编码器进行重新排序。这已经足够将搜索质量提升到相当高的水平。

2025 年初检索/RAG 的 SOTA

当然，如果我们使用更复杂的流程，特别是如果你有用户偏好数据的话，我们可以做得更好。但仅仅上述方法就能带来非常显著的效果。

然后发生了一件有趣的事情：工程师发现，当你给一个 LLM 提供工具，将其运行在循环中（即代理的定义），并要求它进行检索时，它通常会优于一个精心调校的单步搜索流程_即使代理所获得的搜索工具很一般_ 。这种代理方法显示出潜力——但它既昂贵又缓慢。

新的 SOTA

表面上，这没有什么新意——LLM 连续进行多次搜索的想法已经被某种程度上探索过，被称为多跳检索（参见 Baleen）。虽然很有希望，但它是一种昂贵且缓慢的优化，可以提高搜索质量，但并不一定是革命性的。

仔细观察后，搜索领域正在酝酿着某种变化。代理现在可以使用多种工具，包括 grep、嵌入搜索，并以复杂的方式探索结构化数据。LLMs 现在足够强大，可以巧妙地解决复杂搜索任务中出现的障碍，并且已经达到了熟练使用多种工具的水平，这解锁了一种全新的搜索能力。这部分的提升部分归因于强化学习（RL）现在已成为训练基础模型的标准步骤，并且模型因擅长使用广泛的工具而获得奖励。

仍然，每个搜索系统都是不同的。搜索代码库与搜索研究论文在本质上不同，这与搜索个人/公司也不同。虽然一个智能体可以熟练地使用工具，但它没有像长期使用特定搜索引擎并知道如何有效使用它的人那样的经验。

使用智能体进行搜索也是昂贵的——上下文会迅速膨胀，大型且昂贵的 LLMs 通常会比小型 LLMs 表现更好，但代价是显著的延迟和货币成本。

强化学习将搜索智能体提升到了新的水平。没有强化学习，智能体搜索功能强大但速度慢；你通常需要昂贵的前沿模型才能获得最佳结果。有了强化学习，它变得更加可行。

近期的研究证实了这一模式：强化学习（RL）显著提升了搜索系统。DeepRetrieval，仅拥有 30 亿参数，报告称在 11/13 个数据集上优于 GPT-4o 和 Claude-3.5-Sonnet，包括如 HotpotQA 等基准数据集，用于查询增强和证据检索。尽管在某些基准上，相对于基础检索器（BGE-base-en-v1.5）的提升微乎其微，但这可能反映了数据污染——基础检索器明确训练了这些相同的基准，人为地提高了其性能。

DeepRetrieval Benchmarks

Search-R1 显示，强化学习可以显著提升代理检索能力。通过强化学习，Qwen-2.5 3B 和 7B 学习发出多轮网络搜索查询，对结果进行推理，并决定何时再次搜索。在七个问答数据集上，论文报告了 3B 相对于强大的 RAG 基线相对增益约为 21%，7B 为 26%。与传统的 RAG 不同，该模型被训练成主动调查：需要时进行搜索，有足够证据时停止，可以在推理和搜索之间交替。

这个原则不仅适用于网络搜索。你可以训练一个小型 LLM 来操作整个工具包——关键词搜索、语义搜索、grep、SQL——并通过强化学习，它学会明智地使用它们。奖励函数塑造了行为：惩罚幻觉，奖励正确的检索，惩罚过度调用工具。结果是，模型不仅在查找信息方面超越人类，而且在知道何时使用哪种工具以及将找到的信息综合成连贯答案方面也超越了人类。

尽管 LLMs 可以通过强化学习在检索和生成方面都表现出色，我们可能会看到专门的中小型模型负责检索，而前沿模型专注于生成。这种分工是有道理的：检索是强化学习最能发挥作用的领域，也是瓶颈——慢、昂贵且具有领域特定性。前沿模型在最终生成步骤（编码、长篇写作）方面表现出色，但它们在高效、领域感知的检索方面存在困难。这种低效正是摧毁利润并增加初创公司构建代理搜索系统延迟的原因。

您最近对这一演变的体验可能是 Grok Code（xAI 的编码代理），它展示了当您将强化学习应用于代理搜索时会发生什么。虽然其他前沿的 LLMs 在编码方面缓慢且昂贵，但 Grok Code“非常快”。根据 xAI 对 grok-code-fast-1 的更新，xAI 仔细强化了只从您的代码库中检索相关上下文并执行正确操作，而不浪费周期。

Grok Code 之所以在代理编码方面表现得如此出色，一个重要原因在于它是一个训练来处理整个工作流程的单个模型：寻找相关代码、执行命令、进行编辑、对错误做出反应，所有这些都在一个集成的循环中完成。当您在 Cursor 中积极编码时，您需要这个统一的代理，因为每个动作都会影响下一个。一个失败的测试可能需要检查日志，这揭示了需要编辑的不同文件，从而触发另一次搜索。一个经过 RL 训练的单个模型在这里表现出色，因为它能够适应这个可能必要行动的整个宇宙。

但许多工作流程并不需要这种实时适应性。大多数 RAG 系统分为两个不同的阶段：首先，收集所有相关上下文（对于一个代码审查机器人，这可能包括哪些文件已更改、它们连接到什么以及相关的文档）；其次，将那些信息综合成一个判断或总结。这些阶段有不同的要求。检索需要快速且全面，而综合则需要深思熟虑且准确。为检索阶段训练一个小型专业模型，然后将其交给前沿模型进行综合，通常比强迫一个模型同时完成两者效果更好。这与我们过去微调嵌入或重新排序器时的原则相同：在关键地方进行专业化。

初创公司已经在构建代理搜索，但显然有迹象表明强化学习可以带来易得的胜利。《偶然性》——一个针对你联系人的搜索引擎——是一个很好的例子。搜索代理感觉神奇，能够即时创建复杂的过滤器。但截至本文写作时，搜索速度太慢——这是没有强化学习优化的代理搜索的典型症状。这正是强化学习将其从“神奇但不实用”转变为“神奇且可用”的地方，很可能会实现我们在其他微调中看到的2-3倍以上的速度提升。

偶然性搜索查询示例

Clado，另一家 Y Combinator 初创公司，使用 LLM 作为裁判的强化学习循环来改进他们的人脉搜索产品。

强化学习驱动的代理搜索正在成为主流。纯代理搜索向我们展示了可能实现的事情；强化学习使其变得可行。它可能感觉与之前的主流——训练嵌入模型和选择正确的重排器——不同，而且肯定不那么直接，但巨大的收益使其值得。基本原理没有改变：你仍然需要评估和训练数据，尽管由于现在用于奖励函数而不是直接监督，你可能需要更少的数据。

进展正在变得清晰：传统的 RAG 遇到了天花板，代理搜索突破了它，但代价高昂，现在 RL 使代理搜索既优越又高效。

虽然 RL 和代理搜索的结合非常强大，你仍然需要处理数据，找到合适的例子，并有效地部署。这是一项需要真正专业知识的专门 ML 工作。

这就是我们在 inference.net 所做的事情。我们为您的特定用例训练定制模型，无论是 RL 驱动的代理搜索、数据提取还是实时聊天。我们的团队负责一切：构建评估、设计奖励函数、集成工具、训练模型和大规模部署。大多数创始人都在努力寻找产品市场匹配，而不是成为 ML 专家。我们处理模型基础设施，而您则构建您的业务。

上述论文链接（方便起见）： • SPLADE • RRF • Baleen • DeepRetrieval • Search-R1 • HotpotQA • BGE-base-en-v1.5