ToolHop: A Query-Driven Benchmark for Evaluating Large Language Models in Multi-Hop Tool Use¶

会议: ACL 2025
arXiv: 2501.02506
代码: https://huggingface.co/datasets/bytedance-research/ToolHop
领域: LLM Agent
关键词: 工具使用, 多跳推理, 基准测试, function calling, LLM评测

一句话总结¶

提出 ToolHop——一个包含 995 个多跳查询和 3912 个本地可执行工具的基准数据集，通过"查询驱动"的数据构建方式（先有查询再造工具）确保工具间有真实依赖关系和可验证答案，评测 14 个 LLM 发现最强的 GPT-4o 准确率仅 49%，揭示了不同模型家族在工具使用上的显著策略差异。

研究背景与动机¶

领域现状：LLM 的工具使用（tool use/function calling）是迈向通用智能的关键能力。现有评测数据集大多采用"工具驱动"方法——先收集工具，再为工具生成查询。
现有痛点：(a) 工具驱动方法无法保证工具间有真实的依赖关系，生成的查询往往不涉及真正的多跳推理；(b) 现有数据集缺乏可验证的标准答案，只能用 GPT-4 等模型做过程评估，引入模型偏差；(c) 很多工具依赖外部 API，无法免费/稳定地执行；(d) 工具反馈不够详细，模型出错后缺乏有效的纠错信号。
核心矛盾：多跳工具使用要求模型具备查询分解、工具选择、参数传递、结果链式依赖处理等综合能力，但现有评测无法可靠地分离和度量这些能力。
本文要解决什么？ 构建一个高质量的多跳工具使用评测基准，确保：查询多样性、工具间真实依赖、本地可执行、详细反馈、答案可验证。
切入角度：反转数据构建流程——从多跳查询出发，为每个原子子查询定制工具（包括文档和代码），自然保证工具间的依赖关系。
核心idea一句话：用"查询驱动"替代"工具驱动"的数据构建范式，从多跳问题出发逆向生成工具文档和可执行代码，确保评测的真实性和可验证性。

方法详解¶

整体框架¶

输入：一个多跳查询 \(q\)（来自 MoreHopQA 数据集），可分解为原子子查询 \(q_1, q_2, ..., q_l\)。输出：一组工具文档 \(\text{doc}_{1..l}\) + 代码实现 \(\text{fun}_{1..l}\) + 标准答案 \(a\)。构建流程分三阶段：工具创建、文档精炼、代码生成。

关键设计¶

查询驱动的工具创建（Tool Creation）:
做什么：将多跳查询分解为原子子查询序列，为每个子查询生成初步工具文档
核心思路：每个子查询 \(q_i\) 依赖前一步的结果 \(a_{i-1}\)，自然形成链式依赖。为每个 \(q_i\) 创建的工具不仅能解决该特定查询，还被设计为可泛化到类似查询
设计动机：现有工具驱动方法从独立收集的工具出发，工具间没有天然依赖关系，只能人造依赖。查询驱动方法从问题结构出发，依赖关系是与生俱来的
文档精炼（Document Refinement）:
做什么：将初步工具文档扩展为更复杂、更贴近真实场景的完整文档
核心思路：两个方向扩展——(a) 功能扩展：增加结果过滤、可定制格式等功能；(b) 参数复杂化：将简单 string 参数替换为 array、object 等结构化类型。精炼后平均参数数从 3.49 增至 5.91，string 参数占比下降 12%
设计动机：简单工具无法测试模型对复杂参数结构的理解能力。真实 API 通常有可选参数、嵌套结构，精炼后的工具更接近实际使用场景
代码生成（Code Generation）:
做什么：为每个工具文档生成本地可执行的 Python 函数
核心思路：函数名映射自工具名，参数签名来自文档规范。关键是将原子查询 \(q_i\) 和答案 \(a_i\) 作为输入约束，确保函数在正确调用时返回正确答案。同时加入异常处理机制，对错误输入返回详细错误信息
设计动机：(a) 本地执行零成本，不依赖外部 API；(b) 详细错误反馈帮助评估模型的纠错能力；(c) 预定义答案使评估可自动化验证
评测维度设计:
答案正确性：三种场景——直接回答（无工具）、强制使用工具、自由选择
调用错误分析：工具幻觉（调用不存在的工具）、参数幻觉（使用未定义参数）、参数遗漏（缺少必需参数）

损失函数 / 训练策略¶

数据构建使用 GPT-4o 辅助处理。数据集规模：995 个多跳查询，3912 个工具，覆盖 47 个领域。每个查询需要 3-7 个工具（即 3-7 跳）。

实验关键数据¶

主实验¶

评测 14 个 LLM（5 个家族：LLaMA3.1, Qwen2.5, Gemini1.5, Claude3.5, GPT）。

模型	直接回答↑	强制工具↑	自由选择↑	查询错误率↓	实例错误率↓
GPT-4o	23.12	49.04	47.74	9.45	4.31
GPT-4-Turbo	18.59	47.94	46.83	10.95	4.97
Claude3.5-Haiku	36.08	38.09	44.72	23.48	15.81
Qwen2.5-72B	17.89	45.43	38.29	13.27	4.93
LLaMA3.1-70B	18.79	19.10	12.76	35.08	14.24
14模型平均	19.83	32.12	32.84	18.72	8.68

消融实验（GPT 家族反馈分析）¶

GPT 版本	有详细反馈↑	无详细反馈↑	正确→错误	错误→正确
GPT-4o	47.87	24.47	25.53	2.13
GPT-4o-mini	38.53	11.93	29.36	2.75
GPT-3.5-Turbo	36.75	21.37	20.51	5.13

关键发现¶

工具使用大幅提升但远未饱和：使用工具平均提升 12.29% 准确率，GPT 家族提升 23.59%，但最好的 GPT-4o 仅 49%，说明多跳工具使用仍极具挑战
模型家族策略差异显著：Qwen2.5 过度依赖并行调用（14B 版本 70.1% 查询使用并行调用），导致参数幻觉；Claude3.5 即使不用工具也表现突出（CoT 推理优势）；LLaMA3.1 不支持同时输出文本和工具调用，限制了 CoT 推理
详细反馈至关重要：GPT-4o 在有详细反馈时 47.87% 准确率，只给简单错误提示时降至 24.47%（降 23.4%），说明详细工具反馈对模型纠错能力至关重要
并行调用的双刃剑：Qwen2.5-72B 将并行调用比例降至 3.82% 后性能显著提升，说明在多跳场景下串行调用更可靠
Scaling Law 适用：同一家族中更大模型一般表现更好，调用错误更少

亮点与洞察¶

查询驱动的逆向构建：从问题出发设计工具而非从工具出发设计问题，这种逆向思维确保了评测的真实性。该范式可迁移到任何需要构建有依赖关系的评测数据的场景
本地可执行 + 可验证：3912 个工具全部本地可执行，无需外部 API，且有预定义答案可自动验证。这是工具使用评测的标杆做法
模型家族横向对比洞察深刻：发现不同家族的工具使用"性格"差异（Qwen 爱并行、Claude 爱自己想、GPT 依赖反馈），这些洞察对模型开发者非常有价值

局限性 / 可改进方向¶

只有评测没有提升方案：论文承认缺乏直接提升多跳工具使用能力的策略，数据集可用于训练但未验证
工具功能限于计算型：由于是代码实现的本地工具，无法覆盖需要真实网络交互的工具使用场景（如调用搜索引擎、数据库）
基于 MoreHopQA 的查询可能不够多样：源数据集的查询分布可能偏向特定知识领域
文档精炼由 GPT-4o 执行：引入了模型偏差，可能生成的工具文档风格过于一致

评分¶

新颖性: ⭐⭐⭐⭐ 查询驱动的逆向构建思路新颖，数据集设计全面
实验充分度: ⭐⭐⭐⭐⭐ 14个模型5个家族，多维度评测，深入的家族差异分析
写作质量: ⭐⭐⭐⭐ 结构清晰，图表丰富，分析深入
价值: ⭐⭐⭐⭐⭐ 填补了多跳工具使用评测的空白，对模型开发有直接指导意义