Plan 还是 Retrieve 先行？工具发现架构的规模研究

作者Mingfei Zhang, Amit Surana, Ziauddin Majid, Chenxi Wang, Michael Xu

工具增强的 LLM 智能体在执行规划之前会从大型注册表中发现相关 API，但有限的上下文窗口使得无法将所有工具定义注入单个提示中。主流方法——我们称之为“先检索后规划”（Retrieve-then-Plan，RtP）——会嵌入用户查询并通过近似最近邻搜索检索相似工具。我们研究了一种替代方案“先规划后检索”（Plan-then-Retrieve，PtR）范式，其中 LLM 首先生成抽象工具桩（Abstract Tool Stubs，即描述所需能力的假设函数签名），然后将其作为针对注册表的检索查询。在 ToolBench（46,984 个唯一 API 端点，50 个类别）上，针对单工具（G1）、同类别多工具（G2）和跨类别多工具（G3）查询子集进行评估，我们发现了一个明显的复杂度相关交叉现象：RtP 在单工具查询上优于 PtR，而 PtR 在多工具查询上优于 RtP。这一交叉现象在每个检索预算（k=1 到 20）下都成立，在从 1k 到 47k API 的注册表规模下都稳健，并且在模型系列（Gemini 2.5 Flash 和 gpt-oss-120b）之间保持一致。我们刻画了一种桩幻觉失败模式（LLM 编造出看似合理但并不存在的 API 名称），它是一把双刃剑：在简单查询上，PtR 的桩会抽象掉 RtP 直接匹配的专有名词信号，但在复杂查询上，同样的机制会将多方面的意图分解为功能性子需求。我们进一步分析了 token 开销，并表明 PtR 额外的发现调用大约使推理成本翻倍，这在多工具查询上值得，但在单工具查询上则不利，从而推动了复杂度自适应路由作为一个实用方向——它可以由流水线中已经存在的零成本信号（RtP 的 top-1 检索分数）来驱动。

相关阅读和更新。

大型语言模型（LLM）越来越多地被用于复杂的多步规划任务，其中工具检索（TR）步骤对于取得成功的成果至关重要。两种常见的 TR 方法是单步检索（利用完整查询）和使用任务分解（TD）的顺序检索（将完整查询分割为离散的原子子任务）。虽然单步检索缺乏处理……的灵活性

阅读更多

本文被 EACL 2024 的 UncertaiNLP 研讨会接收。

大型语言模型（LLM）具有仅用少量示例就能解决新任务的非凡能力，但它们需要访问正确的工具。检索增强生成（RAG）通过为给定任务检索相关工具列表来解决这个问题。然而，RAG 的工具检索步骤要求所有必需信息都明确存在于查询中。这是一个……

阅读更多