HammerBench: Fine-Grained Function-Calling Evaluation in Real Mobile Device Scenarios
研究问题
现有 function-calling benchmark 往往更偏向单轮调用、理想化指令或静态工具选择，难以覆盖移动助手中的真实多轮交互。论文关注的核心问题是：
- 用户指令常常不完整，很多请求只给出部分参数。
- 对话推进过程中，用户的回答路径并不稳定，可能多答、少答，或者改变问题与参数。
- 用户会通过代词或外部个人信息间接表达参数值，而不是直接说出 slot 内容。
- 如果只看整段对话是否成功，难以定位模型究竟是败在函数选择、参数补全，还是多轮更新。
因此，本文试图构建一个更接近真实手机助手使用方式的评测基准，用来分析模型在多轮 slot filling 与 function calling 中的具体失误模式。
基准设计
1. 三个设计原则
HammerBench 以三个原则组织评测设计：
- 真实性：工具原型来自真实移动应用功能，查询模式参考匿名化用户日志。
- 多样性：不仅覆盖工具和意图的多样性，也覆盖真实用户在多轮交互中的行为差异。
- 细粒度：把完整对话拆成多个 function-calling snapshot，分别评估不同轮次与不同状态下的能力。
这一定义与很多只评估最终成功率的 benchmark 不同，真实系统里的失败往往发生在中间轮次，而不是最后一步才暴露出来。
2. 覆盖的交互难点
HammerBench 不只测“能不能调对函数”，而是有意识地纳入以下场景：
Perfect / Imperfect：用户是否完整提供参数。Irrelevant：候选工具里存在干扰项。Diverse Q&A Trajectories：问答轨迹不固定，代理提出的问题与用户回应长度可能不匹配。Intent Shifts：用户中途改变目标。Argument Shifts / Slot Overriding：用户多次修改同一参数值。External Individual Information：用户通过代词或外部个人信息间接表达参数。
相对于 BFCL、NoisyToolBench、ToolSandBox 一类已有基准，HammerBench 的重点在于把这些更接近真实移动助手的扰动系统化纳入同一评测框架。
数据与评测构造
1. 数据来源与生成流程
论文说明，HammerBench 的工具原型主要基于真实移动应用功能构造，并结合匿名化用户日志分析得到典型请求模式。数据扩展阶段使用开源模型生成，并加入 LLM 校验与人工复核，以控制成本同时保证质量。
本文特别提到两点：
- 匿名日志分析显示，
76%的用户查询少于10个 token，说明现实中的很多请求天然是不完整或含糊的。 - 细粒度多轮数据并不是简单拼接现成对话，而是通过基础数据生成、问答轨迹合并、意图/参数改写以及外部信息注入等方式构造出来。
2. 数据规模
根据论文 HTML 正文可确认，HammerBench 包含：
60个功能类别1,063个工具6,531条查询
其中单轮数据分为 Perfect、Imperfect、External 三类；多轮部分基于基础对话继续构造。论文还提到：
sQsA多轮对话有1,098条- 其中超过
1轮追问的对话约有404条
Hugging Face 数据卡进一步说明，数据同时提供英文与中文版本，并以 ShareGPT 风格组织消息与函数调用记录。
3. 细粒度 snapshot 评测
这篇论文最值得复用的设计，不是单纯“再做一个 benchmark”，而是把多轮交互拆成 snapshot 评测单元。本文希望借此区分模型在不同时刻的能力，例如：
- 是否识别出缺失参数
- 是否知道该继续追问还是结束对话并调用函数
- 是否能在用户改口后正确覆盖旧参数
- 是否能从代词或外部信息中恢复正确参数
这类拆解让评测从“整段是否成功”转向“失败具体发生在哪个交互环节”。
主要发现
1. 参数名错误是高频失败来源
论文最核心的经验结论是：在多种交互场景下，parameter name errors 是函数调用失败的重要来源。也就是说，模型并不一定完全不懂任务，而是经常在参数对齐、参数覆盖或参数语义映射上出错。
这点很重要，因为它把问题从“模型不会调用工具”进一步细化为“模型对参数 schema 的鲁棒理解不足”。
2. 多轮扰动会显著放大错误
从正文分析可以确认，以下情况都会显著拉低表现：
- 多问单答或多答单问等不规则问答轨迹，容易诱发参数幻觉。
- 用户中途修改 intent 或参数值，要求模型动态更新已有状态。
- 外部个人信息或代词引用会显著干扰 slot filling。
- 不完整指令会诱使模型用内部世界知识去脑补缺失参数。
本文认为，真实世界中的 function calling 不是单纯的结构化抽取问题，而是高度依赖对话状态维护与语义更新的问题。
3. 更强模型也并非稳定可靠
论文实验表明，GPT-4o 在 intent shift、argument shift 这类场景中更稳健，但仍会在某些多轮情境里表现出较高的工具拒识倾向。开放模型整体还有明显提升空间，特别是在：
- 处理不规则问答轨迹
- 正确覆盖旧参数
- 理解代词指代与外部个人信息
也就是说，领先模型可以缓解问题，但远没有解决问题。
与相关文档的对照理解
结合知识库中另外 3 篇相近文档，可以更清楚地定位 HammerBench 的价值：
Hammer关注训练侧鲁棒性，试图减少函数名和参数名带来的误导；HammerBench 则从评测侧证明，参数相关错误确实是现实多轮调用里的关键失败源，两者在问题定义上互相支撑。MobileUse关注移动 GUI agent 的长程执行、反思与恢复能力；HammerBench 处理的是更底层的多轮 function-calling 评测，因此更像“调用层能力诊断工具”，而不是完整代理系统。KnowU-Bench关注个性化、主动性与用户同意机制；相比之下，HammerBench 更聚焦 slot filling 和函数调用本身，不覆盖“何时主动打断、何时征求许可”这类上层决策问题。
如果把这几篇工作放在同一条技术链上看，HammerBench 更适合承担“评估多轮工具调用鲁棒性”的角色，而不是直接评估完整个人助理的整体可信性。
可复用启发
- 如果目标系统运行在移动助手或个人助理场景，评测必须覆盖不完整指令、改口、代词引用与问答轨迹波动，不能只做单轮 slot filling。
- 多轮 function-calling 的评测应尽量拆到 snapshot 级别，否则很难定位错误发生在函数选择、缺参判断还是参数更新。
- 参数名和参数语义的鲁棒对齐，是 function-calling 系统中应单独优化的薄弱点。
- 真实世界 benchmark 不一定要求全部纯人工构造，但必须有明确的质量控制链路，否则扩展出来的复杂对话很容易失真。
局限与边界
- 本笔记依据 arXiv 摘要页、arXiv HTML 正文与公开数据卡整理，未逐项核对 PDF 附录中的全部表格和提示词细节。
- 论文重点是 benchmark 设计与误差分析，不提供一个完整的移动代理系统方案。
- 某些实验趋势可以从正文明确确认，但若涉及附录中的全部数据切分、提示模板和错误示例，当前材料仍不足以完整复原。
结论
HammerBench 的关键贡献，不只是提出了一个新的 mobile assistant benchmark，而是把真实多轮 function-calling 中最常见、最难自动评估的扰动系统化了，并通过 snapshot 机制把失败定位到具体交互阶段。对于构建移动助手、端侧代理或工具使用模型的人来说，这篇工作最有价值的地方在于：它把“多轮工具调用到底难在哪”从模糊印象变成了可拆解、可测量、可对比的问题。
来源：[[HammerBench_ Fine-Grained Function-Calling Evaluation in Real Mobile Device Scenarios]]