ACEBench — 中英双语 tool-use 评测 (EMNLP 2025 Findings)

§1 ACEBench 是什么 — 与 ToolACE / BFCL 的关系

1.1 paper 自我定位 (verbatim)

ACEBench v1 标题是 "Who Wins the Match Point in Tool Learning?",v8 / EMNLP camera-ready 改名为 "A Comprehensive Evaluation of LLM Tool Usage"。两个标题之间 8 个版本(2025-01-22 至 2025-11-20),paper 完成了从 "tool learning" 概念到 "tool usage" 评测的语义收敛。EMNLP Findings 版本是事实定稿,bibtex 如下:

@inproceedings{chen-etal-2025-acebench,
    title = "{ACEB}ench: A Comprehensive Evaluation of {LLM} Tool Usage",
    author = "Chen, Chen and Hao, Xinlong and Liu, Weiwen and Huang, Xu and
              Zeng, Xingshan and Yu, Shuai and Li, Dexun and Huang, Yuefeng and
              Liu, Xiangcheng and Xinzhi, Wang and Liu, Wu",
    booktitle = "Findings of the Association for Computational Linguistics: EMNLP 2025",
    month = nov, year = "2025",
    address = "Suzhou, China",
    publisher = "Association for Computational Linguistics",
    pages = "12970--12998",
    doi = "10.18653/v1/2025.findings-emnlp.697"
}

paper 给出的三个动机(对现有 benchmark 的不满,从 EMNLP 版抽取,有微删):

"existing benchmarks for evaluating LLMs' tool usage face several limitations:
(1) limited evaluation scenarios, often lacking assessments in real multi-turn dialogue contexts;
(2) narrow evaluation dimensions, with insufficient detailed assessments of how LLMs use tools;
(3) reliance on LLMs or real API executions for evaluation, which introduces significant overhead."

三点直击 BFCL V1 / V2(单轮 schema)和 ToolBench / API-Bank(LLM judge / 真 API)的弱点。所以 ACEBench 给出的解法是: (a) 双语 / 多轮场景 / Special 异常输入 / Agent 多 agent 模拟全覆盖, (b) AST + 规则 + 沙盒 simulator 三档,不用 LLM judge。

1.2 团队 + 学术血统

1.3 ACE-Bench vs ToolACE — 同源但完全不是一件事

这是写本笔记必须澄清的一点。读者会很容易把两个项目混在一起,因为名字像、组也像。实际上它们是 评测 vs 数据集 的关系:

结论: ToolACE 是训练 fuel,ACEBench 是OOD 测尺。同一华为诺亚团队不是巧合 — ToolACE 用 LLM agent 合成数据训出 ToolACE-8B 后,他们意识到当时所有 benchmark(尤其 BFCL V1)都偏 schema 单轮且只有英文,无法刻画真正的中文工业落地场景,于是花一年时间另起 ACEBench。这是"自己造数据→发现没好尺→造尺"的典型反馈循环。

§2 任务设计 — Normal / Special / Agent 三大类八子类

下面是 ACEBench 的任务类别 SVG 图(全自绘,verbatim 来自 v8 paper 章节 3 + EMNLP camera-ready 重述):

2.1 Normal 五子类 — 常规调用

Multi-Turn 的 v8 verbatim 描述: 对话轮次范围 "The number of dialogue turns ranges from 1 to 8"。这比 BFCL V3 multi-turn 平均 2-3 轮要深,但不到 MCP-Universe / MCPMark 那种 10-50 轮。

2.2 Special 三子类 — 异常输入

这是 ACEBench 比 BFCL 更精细的地方 — 显式把"识别问题、拒答"列为独立任务类。

评测: binary (1 = 正确识别异常, 0 = 错调函数)。这点与 BFCL V1 irrelevance + V3 multi_turn_miss_param + multi_turn_miss_func 性质相同,但ACEBench 把三类异常拆得更细且独立计分。

2.3 Agent 两子类 — 多智能体模拟

这是 ACEBench 与 BFCL multi-turn 真正的方法学分歧: Agent 任务用 multi-agent 模拟来产生 user 输入,而不是单一 user prompt。两个子类:

2.4 数据规模和分布

论文 v8 verbatim: "The final dataset comprises 2,000 annotated entries." 双语各 2,000(经 v8 "two linguistically parallel versions… ensuring equal distribution of data types")。但 paper 没有给出每个子类的精确样本数 — Figure 3 用饼图可视化但无数字标注。这是阅读 ACEBench paper 时最大的不便处之一 — 想精确知道 "Single-Turn 多少条? Similar API 多少条?" 必须自己去 data_all/possible_answer_zh/data_*.json 数 entry。

API pool 规模(verbatim): 4,538 APIs · 8 major domains · 68 sub-domains。 8 个 domain: technology / finance / entertainment / society / health / culture / environment(以及其他)。这与 BFCL Live 不一样 — BFCL Live 是用户贡献,domain 偏程序员日常;ACEBench 是人工精心设计的 domain ontology,因此 finance / health / culture 这种类别均衡覆盖,更适合做工业评估。

§3 评测方法 — AST + Binary + State-based 三段

三类任务对应三种评测方法(verbatim 自 v8 §4):

3.1 Normal 评测 — AST 三步

v8 verbatim: "The evaluation uses AST parsing, beginning with matching the function name to the target function name, then matching parameter types to verify consistency, and finally comparing parameter values to confirm accuracy."

这是纯 schema 级评测 — 不真去执行 API,因此没有 BFCL Executable 类的"weather API 今天挂了"那种不稳定问题。三步匹配的 dispatch 在 ACEBench repo eval_main.py 实现。

3.2 Special 评测 — Binary 1/0

异常类没有需要被调对的 ground-truth function call。它只问 "模型在面对 incomplete / error / irrelevant 时, 有没有避免错调"。这是 binary 二分类问题。

3.3 Agent 评测 — EA(End-to-End)+ PA(Process)

两个指标在 paper §4 Agent Evaluation 给出:

EA 借鉴 BFCL V3 state-based evaluation; PA 是 ACEBench 独有的过程评分 — 即使最终 state 不完全对, 走对了大半流程也部分得分。这一点比 BFCL V3 "all-or-nothing per turn" 更宽容,适合反映"模型其实差最后一步"的真实表现。

3.4 overall accuracy 加权公式

v8 paper 给的总分加权 — 这个公式比 BFCL V4 用硬编码 10/10/30/40/10 更"统计 fair":

√n 加权的好处: 抑制大类支配 — Normal 子类很多(5 子类),Agent 只有 2 子类。如果用线性 n 加权,Agent 的权重会被冲低到 ~10% 以下;用 √n 加权,Agent 大约还能拿 25-30% 权重。这是个比 BFCL V4 "硬编码 40% Agentic" 更自洽的选择。

§4 🔍 开源现状 — repo / dataset / license / 自托管

4.1 三步自托管(README verbatim)

# 1. 装环境
git clone https://github.com/ACEBench/ACEBench
cd ACEBench
pip install -r requirements.txt

# 2. inference — 闭源 API(以 qwen-max 中文为例)
python generate.py --model qwen-max --category test_all --language zh

# 2b. inference — 本地模型(model name 加 "-local" 后缀)
python generate.py --model Qwen2.5-3B-Instruct-local \
                   --model-path /path/to/model \
                   --category test_all --language zh

# 3. evaluate
python eval_main.py --model Qwen2.5-3B-Instruct-local --category test_all --language zh

关键参数:

• --category: 可选 test_all 或具体子类(data_normal / data_special / data_agent / 等)
• --language: zh 中文 / en 英文 — 必须显式指定一种,无 "both" 选项
• --model-path: 本地模型 ckpt 目录(仅 -local 后缀 model 用)

4.2 模型 handler 注册流程

跟 BFCL 类似,加新模型需要 (1) 在 model_inference/inference_map.py 加 mapping, (2) 实现对应 APIModelInference 或 CommonInference 子类。但比 BFCL 简单 — ACEBench 只有 inference + eval 两个入口,没有 BFCL 那么大的 model_handler 模块。

§5 leaderboard — 原 paper Table 2 + Kimi K2 + EnvTuning OOD

5.1 paper 原始 leaderboard (v8 Table 2 — 双语 combined Overall)

来自 v8 paper Table 2(combined 中英文 overall acc, 由 √n 加权): 前 21 个 model,按 Overall 排序。verbatim 自 paper:

SOTA 分组(paper 原报数, 2025-01 至 2025-11 周期):

5.2 Agent 子集详细 (paper Table 4 — Multi-Turn / Multi-Step 分开)

这是 ACEBench 最有诊断价值的子表 — 拆分 Multi-Turn 和 Multi-Step,每边给 EA/PA 双指标:

诊断信号:

• Multi-Step 普遍比 Multi-Turn 容易: GPT-4-Turbo Multi-Step 85.0 vs Multi-Turn 50.0(差 35 pp)。这反直觉 — "user 只说一次" 反而比 "user 多次发言" 容易,因为 user repeatedly 引入更多歧义。
• Claude-3-5-Sonnet Multi-Turn 21.5 反常低(比 GPT-4-Turbo 低近一半),但 Multi-Step 57.5 又抢回。这是 Anthropic 模型在 multi-turn schema 上的已知问题(与 #28 BFCL Claude V3 25.3 同源)。
• PA 都比 EA 高 5-15 pp: 这印证了 PA 是 "process-level partial credit", 让"差最后一步的模型"也能拿分。

5.3 Kimi K2 自报(K2 技术报告 Table 3)

Kimi K2 技术报告(Moonshot, 2025-07)Table 3 单独把 ACEBench (En) 列为主报告 metric 之一:

Kimi K2 paper abstract verbatim: "Notably, K2 obtains 66.1 on Tau2-Bench, 76.5 on ACEBench (En), …"。 这是 frontier model 报告里少有的把 ACEBench 当 first-class metric 用的例子。

5.4 EnvTuning OOD(#29)— Agent 子集

EnvTuning(#29)把 ACEBench Agent 当 OOD eval 用 — 训练只用 BFCL V3 400 条,泛化效果由 ACEBench Agent 验证。Table 2 verbatim:

5.5 Tool-N1 + AgentScaler 自报(社区收录)

除上述外, AgentScaler(基于 Qwen3 的 agentic 微调系列)/Tool-N1 (NVIDIA, #28 §11.2)的 paper 也把 ACEBench 列为对比目标之一。但因为 paper 自报数字 + 评测细节(中/英? combined?)各异,本文不再单列。 截至 2026-05,ACEBench 官方 leaderboard 自 2025-07-21 后没有再大批更新, 第三方汇总(llm-stats / airank.dev)收录非常少, 远没到 BFCL 109 model 那个量级。这是 ACEBench 在 "social adoption" 维度的明显短板。

§6 提交流程 — PR-based,无 web portal

ACEBench 仓库 README 没有显式 "How to Submit" 章节,但从 repo 结构可推出标准 PR 流程:

1. fork ACEBench/ACEBench
2. 在 model_inference/inference_map.py 注册新 model + 实现对应 *Inference 子类
3. 本地跑 python generate.py + python eval_main.py 出两份 JSON(en + zh)
4. 更新 docs/ 下的 leaderboard 表(GitHub Pages 渲染)
5. 提 PR — 第一作者 Chen Chen(chenchen0103 即 GitHub Pages 域名)review

§7 与 BFCL / MCP bench 对比 — 何时用 ACEBench

7.1 何时用 ACEBench

• 需要中文 function-call eval: 这是当前唯一在主流会议(EMNLP 2025 Findings)上发表、有中英双语 ground truth、被工业界(Kimi K2, AgentScaler)引用的 benchmark。中文 LLM 厂商训 tool-use 模型,ACEBench 是必跑。
• 需要 fine-grained Special 类: 如果你想测"模型拒答 / 追问能力", ACEBench 把异常输入拆成 3 子类比 BFCL 更细。
• OOD eval(配合 BFCL 训练): 见 #29 EnvTuning 范例 — 用 BFCL V3 训,用 ACEBench Agent 测 OOD。
• 预算紧: 无 SerpAPI / 无 OAuth / 无真 cloud, 跑一次便宜得多。

7.2 何时不用 ACEBench

• 需要真生产 stack: 真要测 OAuth Notion / Stripe / GitHub MCP, 直接上 MCP-Universe / Atlas / MCPMark。
• 需要 109 model 大盘对比: BFCL 官方 CSV 持续更新,ACEBench leaderboard 自 2025-07 静默。
• 需要 V4 agentic 类(web search / memory): 这是 BFCL V4 独有, ACEBench 不评。

§8 frontier model 官方引用情况

结论: ACEBench 的引用模式与 BFCL 完全不同。BFCL 主要被 ≤40B 小模型 SFT recipe(xLAM / Hammer / TOUCAN / 等)和 GPT-5.5 system card 当训练 / 训练源用;ACEBench 主要被中国厂的 frontier 模型(Kimi K2 / AgentScaler / DeepSeek 第三方报)+ 学术 OOD eval(EnvTuning)用。两个 benchmark 的 social topology 不重合 — 这恰恰是 ACEBench 不可替代的原因: "我们要在中国 frontier model 中做对比" 这件事 BFCL 没法满足,只能用 ACEBench。

§9 局限 + 个人 take

9.1 ACEBench 本身局限

1. 没有公开子类样本数: paper "2,000 annotated entries" 是总数,Figure 3 只画饼图无 label。 写 RL reward / curriculum 时不知道每个子类多少条非常不便,只能 clone repo 自己 jq 数。
2. 没有 HF dataset 镜像: 49,556 BFCL 月下载 vs 0 ACEBench HF 月下载。这意味着大多数研究者会"忘了"用 ACEBench。
3. Leaderboard 静默: 2025-07-21 后官方网站没再更新, 第三方收录只有 2 条(llm-stats)。 想看"GPT-5 在 ACEBench 多少"找不到 — 只能去 Kimi K2 paper / EnvTuning paper 抠对比表。
4. Agent 子集是 simulated user, 不是 real user: 比 BFCL multi_turn 多一层"另一个 LLM 演用户", 但仍然不是真用户 — 因此和 MCP-Universe / Atlas 的"真 user query"评测维度仍有差距。
5. 语言不止双语,文化也是 Chinese-context: 中文版 8 domain 里 "society / culture / health" 子类很多是中文语境特有(比如健康咨询的中医词汇)。 这是优点也是局限 — 英语 user 直接跑英文版分数会有 bias。
6. 没有版本演化机制: BFCL 有 V1→V4 演化(每代 changelog 公开), ACEBench v1-v8 全是同一 benchmark 的 paper 修订, 数据/任务集没显著扩张。一旦 GPT-5 把 Normal 类压到 95%+, 整个 benchmark 难以扩容。

9.2 我的 take

1. ACEBench 是 "中文 + Special + Agent 三件套" 的事实标准。 BFCL 是英文 schema 标准,ACEBench 是中英双语 + 异常处理 + 多 agent 模拟标准。两者互补, 不可互替。 训中国厂模型必跑。
2. Agent Multi-Step 子集是 ACEBench 最大的差异化贡献。 BFCL V3 multi_turn 也有"多步", 但没把 "user 只发一次, 模型连续 plan 多 tool" 这个 sub-type 单列。 这恰恰是 production agent 最常见的形态(用户说"帮我搞定")。 ACEBench Multi-Step 单独评 EA + PA 双指标对训练 plan-and-execute 模型有诊断价值。
3. "Special 类显式建模" 是被低估的设计。 现在 frontier model card 都喜欢说 "we improved hallucination", 但很少有 benchmark 把 Incomplete / Error / Irrelevant 拆开看。 ACEBench 把这 3 类拆出 binary 评测, 比 BFCL irrelevance 一锅炖更可解读。
4. "OOD eval" 角色定位最准确。 #29 EnvTuning 的用法是教科书 — 训用 BFCL V3, 测用 ACEBench Agent。 这避免了 BFCL 自我训测一致的 data leakage 风险, 也提供了跨语言泛化信号。 我推荐所有 ≤40B function-call 模型训练管线把 ACEBench Agent 当第二关 gate(第一关: BFCL V3 Overall ≥70%)。
5. 但靠 ACEBench 单独训不可行。 2,000 样本太少, 子类不公开, 不该当训练目标。 应该当泛化测尺用。
6. v8 → EMNLP camera-ready 改标题 = team 的成熟信号。 从 v1 "Who Wins the Match Point" 这种竞赛标题改为 v8 "A Comprehensive Evaluation" 平实标题, 反映团队的目标从"我要发个炸点 paper"变成"我要做一个能用十年的标准"。 这对一个评测项目来说是好信号。 但要真做到 BFCL 那种"十年标准", 必须解决 §9.1 列的 6 个局限 — 尤其 (2) HF 镜像 + (3) 持续 leaderboard 维护。

9.3 一句话推荐

训 ≤40B 中英双语 function-call 模型的标准流程: TOUCAN / xLAM 1.5M SFT 冷启 → BFCL V3 Overall ≥70% gate → ACEBench Agent ≥25% OOD gate(Multi-Step ≥30%) → EnvScaler / SETA / EnvTuning 合成 env RLVR → BFCL V4 Agentic ≥50% gate + ACEBench Multi-Step ≥40% → MCP-Atlas / MCPMark 真测。 ACEBench 是中英双语必经的 第二关 OOD。