苹果研究：工具发现该先规划还是先检索？Plan-then-Retrieve 与 Retrieve-then-Plan 的规模对比

作者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 的工具检索步骤要求所有必需信息都显式存在于查询中。这是一个……

阅读更多