Tool Learning -- 数据集与评估

2025-11-17

导读： “You get what you measure.” 评估 Tool Learning 的难点在于它是一个交互式环境下的多步决策过程。本讲义选取了 6 个具有代表性的 Benchmark，揭示了该领域评估标准从单一的“成功率”向“过程正确性”、“环境稳定性”及“复杂推理能力”演进的轨迹。

1. 基础与规模化 (Foundation & Scale)

1.1 ToolBench (Qin et al., 2023)

The “ImageNet” moment for Tool Learning.

🎯 核心目的 建立大规模、多样化的真实 API 调用基准，旨在揭示开源模型（Open-source LLMs）与闭源模型（如 GPT-4）在工具使用上的差距。
📊 数据架构
- 输入：自然语言指令 $I$ (e.g., “Find weather in X and email it”).
- 工具库： $\mathcal{T}_{all} \approx 16,464$ 个真实 RESTful APIs (来源于 RapidAPI)，覆盖 49 个类别。
- 输出：API 调用链 (Chain of API calls) + 最终响应。
🧪 评估指标
- Pass Rate (PR)：成功完成任务的比例。
- Win Rate (WR)：相对于基线（如 ChatGPT-ReAct）的胜率（通常由 GPT-4 判定）。
💡 深度解析 (Deep Dive)
- 历史地位：它是第一个大规模指令微调（Instruction Tuning）工具数据集，证明了通过 DFSDT (Depth First Search-based Decision Tree) 数据增强，开源模型可以获得工具能力。
- 局限性：
  1. 环境不稳定性：依赖真实网络 API，导致 “API Rot”（失效）和网络波动，无法公平对比不同时间点的模型。
  2. 偏科：主要关注单步或简单多步调用，对于复杂的参数逻辑覆盖不足。

2. 环境稳定性与复现性 (Reliability & Reproducibility)

1.2 StableToolBench (Guo et al., 2024)

Solving the “API Rot” problem.

🎯 核心目的 针对 ToolBench 存在的真实 API 状态不可控、不可复现问题，构建一个确定性的评测环境。
🛠️ 技术方案
- 虚拟化层：引入 Virtual API Server + Caching System。
- 机制：记录真实 API 的输入输出对 $(x, y)$ 并缓存。在评测时，模型不再访问互联网，而是访问模拟器。
📊 关键发现
- 稳定性：消除了网络延迟和 API 变更带来的随机误差。
- 性能校准：研究表明，在真实环境中模型表现的波动可能掩盖了算法的真实改进。
💡 深度解析 (Deep Dive)
- 价值：这是 Tool Learning 走向工业级评测标准的关键一步。没有 Reproducibility，就没有 SOTA。
- 代价：虚拟环境牺牲了部分“动态性”。真实世界的 API 可能会发生参数定义漂移，这种“适应变化”的能力在 Cache 系统中无法被评估。

3. 决策意识与判别 (Decision Making / Necessity)

1.3 WTU-EVAL (Ning et al., 2024)

To use, or not to use? That is the question.

🎯 核心目的 评估模型的 Tool Awareness（工具意识）。针对模型常见的 “Hammer-and-Nail” 偏见（手里有锤子，看什么都是钉子），即不分场合地滥用工具。
📐 数学本质 评估模型对策略函数 $\pi_{\text{use}}(q)$ 的拟合能力：

$\text{Label} = \mathbb{I}(\text{Task requires external info})$
📊 数据组成
- Positive Set (6 datasets): 必须使用工具才能解决的问题（如实时天气、复杂数学）。
- Negative Set (5 datasets): 常识或逻辑问题，工具调用反而引入噪声或冗余。
💡 深度解析 (Deep Dive)
- 发现：许多经过 Tool-finetuning 的模型会出现严重的 Over-reliance（过度依赖），导致通用对话能力下降。
- 改进：证明了在训练数据中混入 “Negative Samples”（不需要工具的样本）可以将错误调用率降低 ~16.8%。
- 缺憾：仅关注“是否调用”（Binary Classification），未覆盖“调哪个”和“怎么调”。

4. 复杂推理与组合 (Complexity & Compositionality)

1.4 ToolHop (Ye et al., 2025)

Multi-hop Reasoning over Tools.

🎯 核心目的 打破“单步查询”的桎梏，专注于 Multi-hop Tool Use（多跳工具使用）。任务之间存在信息依赖：前一个工具的输出是后一个工具的输入。

$y_1 = T_1(q), \quad y_2 = T_2(y_1), \quad \dots$
⚙️ 环境设置
- Local Execution：为了避免网络问题，工具库由 3,912 个可本地执行的 Python 函数组成。
- Hard Constraint：工具之间的依赖关系是刚性的，不能跳过。
📊 评估效果
- SOTA 瓶颈：即便是 GPT-4o，准确率也仅约 49.04%。
- 失败模式：模型常在传递参数时丢失信息，或者无法推断出正确的工具执行顺序。
💡 深度解析 (Deep Dive)
- 价值：区分了“简单的 API 检索”和“真正的规划能力”。这是目前区分大模型智商高低的分水岭。
- 门槛：由于采用本地代码环境，对评测框架的配置要求较高。

5. 个性化与知识融合 (Personalization & Context)

1.5 FamilyTool (Wang et al., 2025)

Tool Learning meets Knowledge Graphs.

🎯 核心目的 考察模型在高上下文 (High-context) 环境下的表现。模型不仅要会用工具，还要理解用户的背景、偏好以及家庭成员关系。
🧠 任务形式
- 输入：Query + User Profile (Knowledge Graph)。
- 推理：需要先在 KG 上进行多跳推理（如：“我舅舅喜欢的那个歌手的最新专辑是什么？”），解析出实体，再调用工具。
- 泛化：Inductive Setting（测试未见过的用户/偏好）。
💡 深度解析 (Deep Dive)
- 创新点：引入了 Relationship Reasoning（关系推理）作为工具调用的前置条件。
- 应用场景：极具现实意义，主要针对智能家居、个人助理 (Personal Agent) 场景。
- 挑战：随着推理跳数 (Hops) 增加，性能呈指数级下降，说明 LLM 在结合“内部逻辑推理”和“外部动作执行”时仍存在巨大的对齐鸿沟。

6. 过程监督与诊断 (Process Supervision)

1.6 TRAJECT-Bench (He et al., 2025)

Evaluate the journey, not just the destination.

🎯 核心目的 从 Outcome-based（只看结果）转向 Trajectory-based（关注轨迹）评估。解决传统 Benchmark “Right answer for the wrong reason”（结果对了但过程错了）的问题。
🔍 细粒度指标 (Granular Metrics) 不再单一给出一个 Pass/Fail，而是分解为：
- $Acc_{sel}$ : 工具选择准确率。
- $Acc_{arg}$ : 参数填充准确率。
- $Acc_{seq}$ : 顺序依赖满足率。
📊 关键发现
- 长尾失效：模型在短轨迹（1-2步）表现尚可，但在长轨迹（3-10+步）中，参数错误和上下文丢失成为主要瓶颈。
💡 深度解析 (Deep Dive)
- 诊断价值：它不仅告诉我们要提升模型，还指出了哪里需要提升（是检索错了？还是参数填错了？）。这对开发者优化 Agent 架构极具指导意义。

总结：Benchmark 的演进图谱

Benchmark	核心关注点 (Key Focus)	数学/逻辑映射	适用场景
ToolBench	广度 (Breadth)	$\max \sum	{T_i}
WTU-EVAL	判别 (Necessity)	$\pi_{\text{need}}(q)$	避免模型幻觉与滥用
StableToolBench	稳定性 (Stability)	$\text{Var}(\text{Score}) \to 0$	算法迭代对比、复现
ToolHop	深度 (Depth)	$T_n(\dots T_1(q))$	复杂规划 Agent
FamilyTool	上下文 (Context)	$f(q, \text{UserKG}, \text{Tools})$	个性化助手、智能家居
TRAJECT-Bench	过程 (Process)	$P(\tau_{correct} \mid q)$	细粒度归因分析

主题：工具学习, agent