ToolFailBench

ToolFailBench是一个诊断基准，用于测量大型语言模型代理在金融、医学、法律、网络安全和房地产等领域的1,000个任务中的工具使用失败情况。该数据集通过设计需要工具的任务和控制任务，强制模型依赖工具输出，并标注了工具跳过、结果忽略、输出捏造和不必要工具使用四种失败模式，以评估模型是否准确使用工具输出并避免不必要的工具调用。ToolFailBench is a diagnostic benchmark for measuring tool use failures of large language model (LLM) agents across 1,000 tasks in domains such as finance, medicine, law, cybersecurity, and real estate. This dataset includes task designs that necessitate tool usage and controlled tasks that compel models to rely on tool outputs, while annotating four failure modes: tool skipping, result ignoring, output fabrication, and unnecessary tool invocation, to assess whether models can accurately utilize tool outputs and refrain from unnecessary tool calls.

原始信息汇总

数据集概述

ToolFailBench 是一个用于诊断大语言模型（LLM）智能体工具调用失败的基准测试，由加州大学伯克利分校的 Harsh Soni 构建。

核心目标与设计

• 诊断失败模式：旨在揭示模型在工具调用中的具体失败方式，而非仅依赖最终任务准确率。
• 任务构成：包含 1,000 个任务，覆盖五个领域：金融、医疗、法律、网络安全、房地产。
• 任务类型：
  • 工具必需任务（Tool-required tasks）：模型必须调用工具才能正确回答，工具返回模型无法猜测的数值。
  • 控制任务（Control tasks）：模型应直接回答，无需调用工具。
• 失败模式分类：通过确定性规则分类器和两个独立的 LLM 裁判（使用多数投票法）为每个轨迹标注以下四种失败模式之一：

失败模式	含义
工具跳过（Tool-Skip, TS）	需要工具时，模型未进行有效的工具调用（如依赖记忆、拒绝回答或发出未执行的工具调用文本）。
结果忽略（Result-Ignore, RI）	需要工具时，模型调用了工具并获得了正确答案，但最终回答与工具返回值矛盾（通常回退到训练数据记忆）。
输出捏造（Output-Fabrication, OF）	需要工具时，模型调用了工具，但最终回答中包含了工具返回值中不存在的结构化数据、日期、标识符或数字。
不必要工具使用（Unnecessary-Tool-Use, UTU）	控制任务（不需要工具）中，模型仍然调用了工具（「总是调用」病理模式）。

关键发现

• 忠实工具使用尚未饱和：最佳模型 Grok-4.3 的干净工具使用率 (Clean Tool-Use Rate, CTUR) 仅为 86.33%。
• 高分不等于频繁调用：顶级模型通过适中的工具跳过率和较低的结果忽略率及输出捏造率取得成功，并非最激进的调用者。
• 聚合分数掩盖失败特征：多数模型为低不必要工具使用率的「自律型（Disciplined）」，而 Llama-3.1 系列模型则表现为高不必要工具使用率的「总是调用型（Always-Call）」。
• 规模不解决工具自律问题：同等规模的 Llama-3.1-70B 和 Qwen2.5-72B，在控制任务准确率上相差 89 个百分点。
• 双裁判集成鲁棒：三人裁判间的 Fleiss κ 为 0.693。
• 结果忠实度因领域而异：在「自律型」模型中，金融领域的中位规则结果忽略率（RIR）为 12.24%，而网络安全领域仅为 0.68%，证实了跨领域设计的必要性。

排行榜（Top 19 模型，按集成干净工具使用率排序）

排名	模型	集成干净工具使用率 (Ens. CTUR)	集成工具跳过率 (Ens. TSR)	集成结果忽略率 (Ens. RIR)	集成输出捏造率 (Ens. OFR)	集成不必要工具使用率 (Ens. UTR)	集成控制任务准确率 (Ens. CTRL-Acc)
1	Grok-4.3	86.33	11.80	1.74	0.13	0.81	97.18
2	Grok-4-1-Fast-Reasoning	84.11	14.15	1.60	0.13	0.40	99.60
3	Qwen2.5-32B-Instruct	82.68	12.08	4.43	0.81	0.80	95.58
4	Qwen3.6-27B	79.33	19.87	0.67	0.13	0.00	98.79
5	Claude-Sonnet-4.5	79.28	15.64	4.41	0.67	0.00	100.00
6	GPT-5.4-Mini	79.14	14.17	5.48	1.20	0.00	97.20
7	QwQ-32B	79.04	16.02	3.07	1.87	1.61	95.98
8	Qwen2.5-72B-Instruct	79.00	18.57	2.02	0.40	0.00	98.00
9	Qwen3.6-35B-A3B	78.47	18.98	2.15	0.40	0.00	99.60
10	Gemma-4-31B	78.12	19.06	2.68	0.13	0.00	98.39
11	Qwen3.5-27B	77.38	21.55	0.67	0.40	0.00	99.60
12	Claude-Haiku-4.5	76.47	18.85	2.81	1.87	0.00	100.00
13	DeepSeek-V4-Flash	75.84	17.45	4.30	2.42	1.20	98.39
14	Gemma-4-27B-A4B	73.49	24.10	1.74	0.67	0.00	99.20
15	GLM-4.7-Flash	71.49	24.90	3.21	0.40	0.00	99.19
16	Qwen3.5-9B	70.03	26.48	2.82	0.67	0.00	99.60
17	Qwen2.5-7B-Instruct	65.28	28.53	5.11	1.08	0.00	95.16
18	Llama-3.1-70B	62.58	24.23	11.17	2.02	77.73	8.91
19	Llama-3.1-8B	47.32	20.64	30.43	1.61	98.39	0.00

环境设置与使用

• 安装：通过 git clone、./setup.sh 及激活虚拟环境完成。
• 运行评估：使用 python scripts/run_eval.py --model <模型名称> 命令，支持闭源 API 模型和本地开源模型（需要 vLLM 服务器）。
• 集成裁判：通过 make judge EVAL=<结果文件> 命令运行双 LLM 裁判集成（Qwen3.5-397B-A17B-FP8 和 GLM-4.7-FP8）及规则分类器。
• 数据与轨迹：完整评估轨迹发布在 HuggingFace 数据集 SoHarshh/toolfailbench-traces。

数据集结构与格式

• 任务目录：tasks_v5/ 包含五个领域的子目录，每个子目录下包含 tasks.json 和 tools.json。
• 系统提示：system_prompts/v5/ 为每个领域提供共享系统提示。
• 模型配置：models/configs/ 下每个模型有一个 YAML 配置文件。
• 许可证：Apache License 2.0。

搜集汇总

数据集介绍

构建方式

在大语言模型智能体工具调用的评估领域，传统聚合指标往往掩盖了工具使用的真实缺陷。ToolFailBench数据集精心构建了涵盖金融、医学、法律、网络安全和房地产五个领域的1000个任务，以诊断模型在工具调用中的失败模式。数据集采用双任务设计：工具必需任务要求模型调用工具获取其无法预知的值，而控制任务则附加相同工具但要求直接作答。每个任务轨迹通过确定性规则分类器与两个独立的大型语言模型裁判（Qwen3.5-397B-A17B-FP8和GLM-4.7-FP8）进行多数投票标注，划分出工具跳过（Tool-Skip）、结果忽略（Result-Ignore）、输出捏造（Output-Fabrication）和不必要工具使用（Unnecessary-Tool-Use）四种失效模式。

使用方法

使用ToolFailBench时，研究者可通过git克隆项目并运行setup.sh完成环境配置。评估流程分为两步：首先使用python scripts/run_eval.py指定模型名称执行推理，输出结果存储为JSON格式轨迹文件；随后运行make judge EVAL=结果路径调取双裁判集成系统进行失效模式标注。项目支持闭源API模型与开源权重模型两种模式，后者需通过vLLM本地部署服务。所有模型评估结果和裁判标注数据已作为HuggingFace数据集公开发布，用户可通过hf download命令获取完整日志，并利用evaluation/validate_results.py脚本重现排行榜。配置文件的修改允许灵活调整推理参数与模型注册，使该方法易于扩展至新的智能体系统。

背景与挑战

背景概述

ToolFailBench是由加州大学伯克利分校的Harsh Soni于2026年提出的诊断性基准测试，旨在系统评估大语言模型智能体在工具调用过程中的失败模式。随着语言模型代理在金融、医疗、法律、网络安全和房地产等关键领域广泛应用，工具调用的可靠性成为核心研究问题。该基准通过1000个精心设计的任务，涵盖五种领域，并构建了包含工具跳过、结果忽略、输出捏造与不必要工具调用四类失败模式的分类体系。不同于传统聚合指标，ToolFailBench揭示了模型在相似准确率下截然不同的失败特征，推动了对工具使用行为更精细的理解，对提升代理系统的鲁棒性和可信度具有重要影响力。

当前挑战

当前挑战集中于解决语言模型代理在工具使用中的根本性缺陷：工具跳过导致模型依赖记忆而非工具结果，结果忽略使模型忽视工具返回的正确信息，输出捏造则产生基于训练数据的虚假答案，而不必要工具调用（始终调用模式）破坏了任务简洁性。构建过程中面临设计无法猜测的依赖工具任务与控制任务的平衡难题，需确保工具返回值的唯一正确性。此外，跨域差异显著，金融域结果忽略率中位数达12.24%而网络安全域仅0.68%，揭示了领域特异性对工具信任的影响。同时，分类器间一致性评估要求多裁判集成，计算成本较高。

常用场景

经典使用场景

在大型语言模型（LLM）智能体领域，工具调用（Tool-Use）能力是实现复杂任务执行的核心支柱。ToolFailBench数据集作为一个专门诊断工具调用失败模式的基准测试，其经典使用场景在于对LLM智能体进行细粒度的失败模式剖析。该数据集精心设计了涵盖金融、医学、法律、网络安全和房地产五大领域的1000个任务，其中工具必需任务迫使模型必须依赖工具返回值才能作答，而控制任务则要求模型直接回答以避免不必要的工具调用。研究者通过这种双轨制任务结构，能够系统性地触发并捕获四种典型的工具调用失败模式：工具跳过（Tool-Skip）、结果忽视（Result-Ignore）、输出捏造（Output-Fabrication）以及不必要的工具使用（Unnecessary-Tool-Use）。这一设计使得ToolFailBench成为评估LLM智能体在工具调用忠实度方面的黄金标准诊断工具。

解决学术问题

当前LLM智能体领域的学术研究中，一个关键问题在于聚合性的基准测试得分往往掩盖了工具调用失败的深层本质。ToolFailBench的核心贡献在于解决了这一痼疾——它揭示了即使在最终任务准确率相近的模型之间，其失败模式组合也可能截然不同。例如，研究显示Llama-3.1系列模型表现出典型的“总是调用”（Always-Call）病理模式，在控制任务上准确率几乎为零，而同等参数规模的Qwen2.5-72B却达到98%控制任务准确率，二者相差高达89个百分点。更深刻的是，该数据集证明了工具调用忠实度远未饱和，最强模型Grok-4.3的干净工具使用率（Clean Tool-Use Rate）仅为86.33%，远低于天花板。这一发现对学术界产生了深远影响，促使研究者意识到工具使用评估不应仅测量智能体是否调用工具，更应关注它们是否正确使用工具输出并在无需工具时避免调用。

实际应用

在实际应用层面，ToolFailBench数据集为构建可靠、可信的LLM智能体系统提供了至关重要的质量保障框架。在金融风控场景中，模型若忽视工具返回的实时汇率或市场数据而依赖训练数据记忆，可能导致重大经济损失；在医疗诊断系统中，输出捏造（Output-Fabrication）失败模式可能产生不存在的病历编号或检查结果，直接危及患者安全。该数据集揭示的域间差异性尤为具有实际价值——金融领域的中间位结果忽视率（RIR）中位数高达12.24%，而网络安全领域仅为0.68%，这意味着不同领域的工具调用可靠性需求存在显著差异。企业可以根据ToolFailBench的诊断报告，针对性地优化模型在不同业务域中的工具使用行为，例如对金融类应用加强结果忠实度检测，对控制类任务则需重点防范不必要的工具调用倾向，从而在模型部署前实现精确的风险预判与治理。

数据集最近研究

最新研究方向

在大型语言模型代理（LLM Agents）工具调用能力评估的前沿探索中，ToolFailBench 的推出标志着领域内评估范式从宏观准确率向微观失败模式诊断的重要转变。当前研究前沿聚焦于揭示并分类代理在工具使用过程中的四种核心失败机制——工具跳过、结果忽略、输出捏造与多余工具调用，并发现即使最强模型如 Grok-4.3 的干净工具使用率也仅达 86.33%，表明工具忠实执行远未饱和。值得注意的是，该基准揭示了聚合高分掩盖下的异质失败分布，如 Llama-3.1 系列呈现显著的“始终调用”病理模式，而在相同参数规模下，不同模型在控制任务上的准确率竟相差 89 个百分点。这一发现深刻推动了对代理工具使用可靠性的细粒度理解，为构建更鲁棒、可信的 LLM 代理系统提供了关键诊断依据与标准化评估框架。