ToolMind Technical Report: A Large-Scale, Reasoning-Enhanced Tool-Use Dataset

1 · Motivation — "trajectory 级过滤会漏掉 turn 级错误"

ToolMind 的 motivation 段落几乎可以一句话总结: "现有 multi-turn 合成数据只验整条 trajectory,turn 内的错误会随训练放大"。原文 abstract 第二句直接点名:

"Most existing works on multi-turn dialogue synthesis validate correctness only at the trajectory level, which may overlook turn-level errors that can propagate during training and degrade model performance." — abstract

这一立场和 #22 TOUCAN 形成直接对比: TOUCAN 用 6 维 Likert (difficulty / uniqueness / quality / realism / verifiable / stability) 在 trajectory 级别过滤,然后整条 trajectory 要么全留要么全丢。ToolMind 提出的反例是: 一条 trajectory 总体上 coherent、目标达成,但中间可能有 1-2 个 turn 出现:

1. 失败中间尝试 (failed intermediate attempts) — assistant 调错工具,被 tool agent 返回错误,然后改正。这种 self-correction 是宝贵信号还是噪声?ToolMind 的答案是: 看具体 turn — 错误 turn 应当 mask 掉,纠正 turn 留下。
2. 基于错误假设的 tool call (tool calls based on incorrect assumptions) — assistant 在 user intent 没说清楚的时候硬填参数。这种 hallucination 一旦被训进模型就是"过早 commit"的坏习惯。
3. 角色漂移 (role drift in user/tool messages) — user agent 偶尔会跳出来给建议,tool agent 偶尔会用自然语言回复而不是 JSON。这种角色一致性破坏无法在 trajectory 级用 "整体连贯吗" 这种 coarse 问题筛掉,但 turn-level judge 能精确指认是哪一条 message 出问题。

论文 §3.3.2 原文:

"Since trajectory-level filtering operates at a coarse granularity, it cannot effectively isolate erroneous turns within otherwise coherent trajectories. Trajectories may still contain erroneous or misaligned turns—such as failed intermediate attempts, tool calls based on incorrect assumptions, or role drift in user/tool messages. To further improve data quality, we address these remaining issues by applying a separate LLM-based judge to each turn. The model then masks invalid or role-inconsistent steps and retains only correct procedural actions, ensuring the final training data targets effective problem solving and precise tool use." — §3.3.2

注意 abstract 里特意加的一句"while preserving self-corrective reasoning signals essential for robust tool-use learning" —— 这是对"全丢"路线的 implicit 批评: 如果用 TOUCAN 风格直接丢掉含错 trajectory,你也丢掉了"错完之后恢复"这个最宝贵的 RLHF-like 信号。turn-level mask 让"恢复 turn 留下"成为可能,而"错 turn 不计 loss"避免训出 hallucinate 习惯。这是论文方法论的核心 selling point。

2 · Function Graph 构造 — random walk 采 function chain

这是论文 §3.1 的内容,也是合成数据 diversity 的源头。整个思路用一张图说清楚:

2.1 函数集合与预处理

函数池不来自 MCP,而是从三个 open-source dataset 抠出 schema:

• xLAM-function-calling-60k (Salesforce, CC-BY-4.0)
• Glaive-function-calling-v2 (GlaiveAI, Apache-2.0)
• ToolACE (华为,Apache-2.0;校订 2026-05-18: 早期标 NC 是错误,实测 HF cardData.license=apache-2.0,见 #35 ToolACE)

对每个函数 f_i: X_i → Y_i,如果输入 / 输出参数缺 description 或 type,就用 LM 推断补全(论文 Appendix A.1 给了完整 prompt: "Return only one result in JSON format with two fields: input description and input structure...")。

2.2 参数级 embedding + 边构造

对每个参数 r ∈ X_i ∪ Y_i,用统一 embedding model 编码:

然后对每对函数 (f_i, f_j),计算最大输出-输入 cosine:

超过阈值 τ 的就建一条有向边 i → j,再用 LM 当 validator(论文 Appendix A.1 又给了一段 prompt: "Please determine whether ... the output result of source_function is suitable as the input parameter of target_function. ... assign a score from 0 to 9 for the following aspects: field transitivity, coherence of potential user intent paths.")二次过滤边的可靠性。最后再注入一点随机性"to introduce randomness into edge construction" — 防止 graph 退化成只连超热门 hub。

2.3 random walk 采 chain

从 graph 上做长度 5-20 的有 per-node visit limit 的 random walk:

per-node visit limit 防止"oversampling specific nodes"。每条 walk 就是一个 function chain,后面被 user-agent 翻译成"我是仓库管理员,先做 X 再做 Y 最后做 Z" 这种 user intent。

3 · Multi-Agent Synthesis Framework — user / assistant / tool 三角色

这一节(论文 §3.2)是方法论上"小创新但工程实在"的部分。注意一点: tools 不可执行。原文:

"Since the tools are not executable in our setup, we employ a simulation framework to generate responses." — §3.2

因此整个 trajectory 由三个 LM agent 协同演出:

三个 agent 在 loop 里走: user → assistant (可能 tool_call) → tool → assistant → … 直到 user agent 判定 intent 达成,输出 ###STOP###(注意 prompt 严格规定 "Do not output '###STOP###' in the first turn, regardless of the conversation!!" — 防止过早收尾)。

3.1 关键设计取舍

1. "intent ≠ query" — user agent 拿到的是 underlying intent,不是直白 query。论文原话: "A user intent represents the underlying goal that a user aims to achieve, rather than the exact query they pose. This distinction provides greater flexibility in modeling user behavior, as users often express the same intent in diverse ways." 这给了 user agent 重新措辞的空间,产 dialog 更自然。
2. incremental disclosure — user 不一次性把 intent 全说完,被 prompt 强制"show uncertainty when appropriate"。这是 ToolMind motivation 1.5 那段说的"user requests are often under-specified"对应解法。所以训练数据里会有大量 assistant 主动 clarify 的 turn — 这是 BFCL-v4 multi-turn / agentic 子项的 critical 能力。
3. tool agent 故意会模拟 error — prompt 明确说 "If the function call is invalid (...), return a JSON error message"。这是论文有意让"error handling + recovery"信号进入数据。
4. 具体哪些 LM 当 agent 论文没写 — Appendix B 给了一条完整 trajectory 示例(15 页 PDF 的最后 3 页),从 thinking style 看像是 Qwen 系。未在公开来源确认

function chain: getStockLocations → checkInventory → checkIpAddress

User intent: "I'm a warehouse manager for an eCommerce company. First, I need to check
where our inventory is stored by retrieving the stock locations. Then, I want to verify
the availability of product 'XYZ789' specifically at 'warehouse C' to plan restocking.
Finally, I need to ensure our system's security by checking if the IP address
192.168.1.100 is safe."

user: Can you retrieve the current stock locations for me?
assistant: <think>Okay, the user is asking to retrieve the current stock locations. ...
The user didn't specify a limit, so I don't need to include that. Since the function
doesn't require any parameters, I can call it without any arguments. ...</think>
<tool_call>{"name":"getStockLocations","arguments":"{}"}</tool_call>
tool: {"stock_locations":[{"id":1,"name":"Warehouse A",...},{"id":3,"name":"Distribution
Center C","address":"789 Pine Rd, Countryside","capacity":10000}],"pagination":{...}}
assistant: <think>... I should present this information clearly. ... </think>
Here are the current stock locations retrieved: 1. **Warehouse A** ... 2. **Store B** ...
3. **Distribution Center C** - Address: 789 Pine Rd, Countryside - Capacity: 10,000 units
...
user: Can you check the availability of product XYZ789 at Distribution Center C?
assistant: <tool_call>{"name":"checkInventory","arguments":{"product_code":"XYZ789"}}</tool_call>
tool: {"product_code":"XYZ789","location":"Distribution Center C","available_quantity":150,
       "last_updated":"2023-10-05T14:30:00Z"}
...
user: ###STOP###

4 · Turn-Level Filtering — 论文核心 novelty

论文 §3.3 把过滤分成两个 stage,prompt 也在 Appendix A.3 列出来了。这两个 prompt 长得几乎一样,但判定单位不同 —— 这正是论文的 key insight。

4.1 Trajectory-level filtering (Stage 1)

给完整 multi-turn 对话,LM 二元判 0/1:

"Please strictly evaluate the quality of the following multi-turn dialogue data based on the following criteria: contextual coherence, role consistency, logical soundness, and accuracy of tool usage. Your task is to make a binary judgment — if the dialogue is of good quality, output 1; otherwise, output 0." — Appendix A.3.1

另外还有第一道检验: "the user agent first judges whether the task is completed or not during the process of multi-turn interaction" — user agent 自己判定 intent 达成,达成才进 stage 1。论文原话:

"Given the predefined user intents, the user agent first judges whether the task is completed or not during the process of multi-turn interaction. Then, a second LLM evaluates goal coverage, coherence, and cross-turn relevance. Only trajectories that both align with the intent and exhibit a coherent flow are retained, while the rest are discarded." — §3.3.1

4.2 Turn-level filtering (Stage 2 — 核心 novelty)

给完整 conversation history + 最后一条 response,LM 二元判 0/1:

"Please strictly evaluate the quality of the last response in the following dialogue data, based on contextual coherence, logical consistency, and accuracy of tool usage. Determine whether the response is semantically aligned with the previous dialogue, logically sound without contradictions, and employs the mentioned tools correctly according to their definitions and argument structures. If the response is of good quality, output 1; otherwise, output 0." — Appendix A.3.2

不同于 trajectory filter 的丢弃行为,turn filter 走的是 mask 路线: 标记为 0 的 turn 不参与 loss(论文 §3.3.2 末尾的"masks invalid or role-inconsistent steps")。然后再做按 turn 切样本: §4.1 原话 "each multi-turn conversation is split at each assistant message into multiple samples. For each splitted sample, we retain the full prior context up to (and including) the anchor assistant message and discard all subsequent turns. ... During training, we compute loss only on the tokens of the anchored assistant response."

所以一条 N-turn trajectory 最终会变成 N 个样本(每条样本 anchor 在不同的 assistant turn 上),但只有 turn-level filter 判 1 的那些 anchor 会进入最终训练集。这就是 §3.4 那段:

"We split each trajectory into multiple samples using the turns that passed the turn-level quality filter and analyze both trajectories (orange) and post-split samples (blue)." — §3.4

4.3 为什么这么做 — Table 4 消融

论文 Table 4 给了直接证据 — 用 Qwen3-8B 做消融:

关键差: (a) − (b) 才是"turn-level filter 净效应":

• τ-bench: +7.00 pp (42.31 vs 35.31) — 这是论文 turn-level 的最强证据
• τ²-bench: −2.88 pp (38.85 vs 41.73) — 反方向,turn-level 反而轻微伤
• BFCL-v4: +2.76 pp (46.87 vs 44.11)

5 · Dataset Composition — 360K 的内部精确拆分

论文 Table 1 给了非常清楚的拆分。注意名字虽然叫 "160K + 200K" (= ~360K),但实际 process 后的精确数字是:

5.1 Synthesized 部分: 40,161 → 163,180

一条 raw trajectory 平均切成 ~4.06 个 anchor sample。考虑到论文规定 L (function chain 长度) ∼ Uniform{5..20},每条 chain 演出来的对话至少 5 轮 user-assistant 来回,所以平均 ~4 anchor sample 是合理的(每条 chain 平均剩下 ~4 个通过 turn-level filter 的 assistant turn)。

5.2 函数总量 = "20K+"

论文 abstract / §1 反复说 "20k functions from open-source datasets"。这个总量是 xLAM-60K (~60K query 但只覆盖 ~3K function) + Glaive-v2 + ToolACE 三个并集去重后的 ~20,000 个独立 function schema(具体精确数字论文没给)。未在公开来源确认 — HF dataset card 也只是说"20k tools"概数。

5.3 Domain 分布

论文 Figure 4 给了 user intent 的 domain 饼图。前两大类是:

• data analysis — 占比最大
• entertainment — 第二大
• 其它(finance / weather / e-commerce / travel / health / tech / sports / education / ...) — "relatively balanced"

论文原话: "the data analysis and entertainment domains are the most prevalent, while the remaining domains are relatively balanced." — 这是来源数据集分布的直接反映(xLAM 大量是 data analysis,Glaive 大量是 entertainment / lifestyle)。

5.4 Turn / tool-call 统计

论文 Figure 3 用 orange (trajectory level) 和 blue (post-split sample level) 两套直方图展示。论文 §3.4 给的定性观察:

• trajectory-level 长度分布大致 uniform("relatively uniform"),user 参与度强(每条 trajectory 里都有 user message 反复出现)
• post-split sample 分布右偏(短样本多)("the distribution skews toward shorter instances") — 这是 split anchor 后必然的
• "sizable fraction of turns proceed without any tool calls" — 这是 user agent 被 prompt "incremental disclosure"逼出来的副产品: 很多 assistant turn 是 clarify-asking 而不是 tool-calling
• 论文自己承认: "current tasks leave room for greater complexity, motivating future work on more demanding tool-use scenarios" — 承认当前 trajectory 偏简单(5-20 步 chain 不等于 5-20 个 tool call;真正 tool call 数远小于此)

6 · Training + Evaluation

6.1 训练配置 (§4.1)

6.2 评测 (§4.2)

三个 benchmark,各自定位:

• BFCL-v4(2025-07-17 发布的最新版) — 用 BFCL 官方 Qwen3 setup,leaderboard 截止 2025-10
• τ-bench (arXiv:2406.12045, NeurIPS 2024) — Sierra Research,retail + airline 两域
• τ²-bench (arXiv:2506.07982) — τ 的 dual-control 扩展,加 telecom 域;用 GPT-4o 当 user simulator

6.3 BFCL-v4 主结果 (Table 2)

论文 Table 2 同时报了 leaderboard 上的大模型(上半部分)和 ToolMind 自己 SFT 的 8B/14B(下半部分):

读法:

• Multi-Turn 和 Agentic Search 涨幅最大 — 14B 在 Agentic Search 上 +23.00 pp,这是 ToolMind 设计的方向 (multi-turn dialogue + tool use)。
• Single-Turn 几乎不动(8B Non-Live AST 反退 -0.21 pp, 14B 退 -1.10 pp) — 因为 baseline Qwen3 在 Single-Turn 已经接近天花板(88-90),SFT 没空间。
• Agentic Memory 14B 反退 -3.44 pp — ToolMind 没专门覆盖 memory_kv / vector / rec_sum 那几个 V4 子项,这是个明显的暴露面。
• 14B + ToolMind 50.54 超过 DeepSeek-V3 (45.20)、DeepSeek-R1 (48.97)、GPT-4o (50.27),但仍输 Qwen3-235 (54.37) 和 GPT-5 (59.22) — 数据增强的效果显著但封顶在 ~50 左右。

6.4 τ-bench + τ²-bench (Table 3)

读法:

• τ-bench retail 域 14B 60.00, 8B 57.39 — 这是 ToolMind 最强的成绩点。retail 域和 ToolMind 大量 data-analysis / e-commerce intent 直接 distribution match。
• τ²-bench airline 域 14B +20.00 pp(28.00 → 46.00 不对,应是 36.00 → 56.00,这是 14B 那行,从 baseline 36.00 涨到 56.00)— 涨幅惊人。
• τ²-bench telecom 14B 反退 −1.75 pp — 和 #22 TOUCAN 一样的弱项,telecom 域涉及 dual-control 的特殊指令,纯 SFT 数据合成路线很难覆盖。

6.5 Ablation (Table 4 — 已在 §4 引用)

已经在 §4.3 里展开。这里只回顾结论:

1. 开源 augmented 数据贡献最大(τ/τ² 涨幅大),graph-based synthesized 数据贡献集中在 BFCL-v4
2. turn-level filtering 在 τ-bench (+7.00) 和 BFCL-v4 (+2.76) 上稳定 +,在 τ²-bench 上 −2.88(反例,需注意)
3. full ToolMind 几乎在所有指标上 ≥ 单组件,验证组合有效

7 · 与已有笔记的横向对比

7.1 与 #22 TOUCAN 的对比 — 最重要的一张表

7.2 与其它已有笔记的关系

8 · 开源现状清点

9 · Critical analysis — 局限 / 个人 take

9.1 论文自报的局限

论文 §3.4 末尾自己承认: "these findings indicate that current tasks leave room for greater complexity, motivating future work on more demanding tool-use scenarios." — 承认当前 trajectory 偏简单。后续 ToolMind-Web-3B 的 RL 训也是对这个的响应。

9.2 我观察到的几个 untouched 问题

1. turn-level judge 自己是用什么 LM 跑的,论文没说。 未在公开来源确认
   • 如果是 self-judge(用 base Qwen3 自己判),那就有 self-reward bias: judge LM 喜欢的 turn 不一定是真好的,只是合 judge 自己的偏好,SFT 后等于把 judge 偏好烙进 student。
   • 如果是更强的 LM(GPT-4o / Kimi-K2)判,那需要额外明示;Appendix A.3 的 prompt 是 LM-agnostic 的,看不出来。
   • 论文 Table 2 列了 GPT-4o-2024-11-20 作为 baseline 对比,且 τ²-bench 评测里用 GPT-4o 当 user simulator — 一个合理猜测是判 turn 也用 GPT-4o。但论文从没说出来。
2. turn-level binary judge 是 0/1,信息量很低。这和 trajectory level 用 6 维 Likert 的 TOUCAN 对比:
   • binary 简单,但任何"不完美但有价值"的 turn 一刀切,这正是 §4.3 提到的 τ²-bench 反例可能成因。
   • 更精细的设计应该是 per-turn weight ∈ [0,1] 或者 per-turn label among {good / recoverable / bad},但 ToolMind 没做。
3. tool 是 LM 模拟的,不是真服务。这是和 TOUCAN 的根本 philosophy 差异:
   • 优点: 不依赖外部 server,合成可大规模并行,无 rate-limit。
   • 缺点: tool agent 模拟 error 的 distribution 是 LM 想象的 error,真 server 的 error mode(timeout / partial response / silent data corruption / cross-call state inconsistency)无法演出。
   • 这导致 ToolMind 训出来的模型在真 MCP server 上的 OOD 行为没保证。论文也没在 MCP-Universe / MCPMark / MCP-Atlas 任何一个真 server 评测上跑。
4. "20K tools" 实际是 schema 不是 callable endpoint。这件事 ToolMind 的描述方式("over 20k tools")容易让读者误以为是 MCP-Universe 那种真 callable 数量。纠正: 这里的 "tools" 等价于 "function schemas drawn from xLAM/Glaive/ToolACE"。
5. license — 早期判断已撤销 (2026-05-18 校订)。
   • 之前担心 ToolACE 是 CC-BY-NC → ToolMind 继承 NC,但实测 Team-ACE/ToolACE HF cardData = Apache-2.0(见 #35)。整个 ToolMind 来源链 license 干净。
   • HF dataset 标 Apache-2.0 是准确的。
   • 对比 TOUCAN: 两者 license 同档,选择应基于方法学差异(turn-level vs trajectory-level)而非合规。
6. 没发 paper 主线 ckpt 是个反常信号。Nanbeige 后来发了 ToolMind-Web-3B 这种转向 deep-search 的衍生品,但论文里训出来的 Qwen3-8B-ToolMind / Qwen3-14B-ToolMind 至今没在 HF 上出现。可能原因:
   • (a) 内部产品集成了,不方便单独发(BOSS 直聘业务相关)
   • (b) license 问题(混了 NC 数据训出来的 ckpt 发不发涉及合规)
   • (c) 团队转向了新方向,旧 ckpt 维护成本高
   • 对比 TOUCAN 27 个 ckpt 全发,ToolMind 的开源 commitment 在数据层是好的,在模型层缺位。
7. 没评 Agentic Memory 的几个 V4 子项(memory_kv / vector / rec_sum)— Qwen3-14B + ToolMind 在 Agentic Memory 上反退 −3.44 pp 是个明显告警:ToolMind 数据没有覆盖 long-term memory / KV-store 操作场景,SFT 后反而干扰了原模型的 memory 处理能力(catastrophic forgetting 的一种)。这是个具体可改进方向。

9.3 我会给的实操建议

9.4 一句话总结

ToolMind 是 "工具数据集应该 turn-by-turn 过滤而不是 trajectory-by-trajectory 过滤" 这个 small-but-real method insight 的扎实实现,加上一个清楚的 function-graph 多样性源头,产生一个 ~360K 规模 Apache-2.0(名义上)的 dataset,在 Qwen3-8B/14B 上分别 +4.69 / +5.40 BFCL-v4 Overall pp、+10.87 / +14.22 τ-bench pp。规模上输 TOUCAN,真实度上输真 MCP 路线,但方法论 (turn-level mask) 是有 transferable insight 的 — 任何后续 tool-agentic 数据集都应该考虑加这一层。