多工具检索评测以完整集合命中和成本揭示单工具排名反转

当工具检索器忽略其中任何一个时，必须调用多个工具来满足请求的代理就会失败，但工具检索器大多是在需要单个工具的查询上构建和评估的。我们比较了两个多工具测试台上六种检索结构的代表（扁平的词法检索与稠密检索、LLM 查询分解、LLM 导航层次结构、先服务器、后工具的匹配、依赖图和经过训练的集合级检索器）：带有专家依赖标签的 345 个 AppWorld 查询和 257 个 MCP 工具上的 103 个 MCP-Bench 任务。我们测量完整性@k，即整个所需工具集出现在前 k 中的查询的份额，以及每个结构在检索时产生的 LLM 调用次数、token 数量与延迟。对全部 7,961 个 ToolRet 查询开展的先导分析表明，聚合完整性混合了两种情况：单目标查询的 completeness@10 为 0.58—0.67，具有四个或更多目标的查询的完整性为 0.08 到 0.17，并且单目标查询上检索器的顺序在多目标查询上相反。在两个测试平台的比较中，对于未在该平台数据上训练、且每个查询最多调用一次 LLM 的结构，没有任何一种在 k=16 时能完整覆盖超过 10% 的 AppWorld 查询所需工具。表现更好的两种结构会产生不同的成本：经过 75 到 90 个域内查询训练的集合级检索器在 AppWorld 上达到 0.33，在 MCP-Bench 上达到 0.58，且无需 LLM 调用，而 LLM 导航的层次结构达到 0.30 和 0.40，中位数为 31 到 38 个 LLM 调用，每个查询大约需要 5 分钟。它们的故障模式也不同：经过训练的检索器大多将缺失的工具排在截断位置稍后，而层次结构找到目标 API 并在收集其先决条件之前停止。在与官方 AppWorld 代理进行的下游检查中，具有完整检索集的任务在 21 次中成功了 21 次，而不完整的任务在 39 次中成功了 2 次。