Toolformer：自监督工具使用及其在金融 AI 中的局限性

Toolformer (Schick 等人, 2023, Meta AI) 是通过自监督训练教会语言模型调用外部 API 的奠基性论文。我一直没仔细读它，是因为“工具使用”（tool use）已经变成了一个极其泛滥的概念，导致最初的观点被模糊了。在设计任何调用账本工具的“回写代理”（write-back agent）之前，我需要理解 Toolformer 到底证明了什么，以及它在哪里悄悄失效了。

论文回顾

Timo Schick 和 Meta AI 的七位合著者提出了一种训练语言模型的方法，使其能够决定何时调用外部 API、传递哪些参数，以及如何将结果整合到自身的预测中——且不需要为每个工具手动标注训练数据。这种方法是自监督的：模型在文本中合理的位置生成候选 API 调用，执行这些调用，并仅保留那些 API 结果真正降低了模型对周围 token 困惑度（perplexity）的示例。随后，使用这个过滤后的数据集进行微调。测试的工具包括计算器、两个搜索引擎（BM25 检索和维基百科搜索）、一个问答模型、一个翻译器和一个日历。

训练后的模型是一个基于 GPT-J、拥有 6.7B 参数的模型，他们称之为 Toolformer。该论文被 NeurIPS 2023 接收。

核心观点

• 在数学应用题（SVAMP）上，Toolformer 6.7B 获得了 29.4% 的分数——相比之下，GPT-J 基准为 5.2%，OPT 66B 为 4.9%，GPT-3 175B 为 10.0%。工具的使用有效地打破了算术任务中通常的参数规模限制曲线。
• 在 ASDiv 数学测试中，Toolformer 达到 40.4%，而 GPT-J 为 7.5%，GPT-3 为 14.0%；在 MAWPS 上，Toolformer 为 44.0%，GPT-J 为 9.9%，GPT-3 为 19.8%。
• 在事实性问答（QA）任务中，情况发生了逆转：尽管 Toolformer 使用了搜索工具，但 GPT-3 在三个 QA 基准测试（TriviaQA、WebQuestions、Natural Questions）中的表现仍然优于 Toolformer。Toolformer TriviaQA 得分为 53.5%，优于 GPT-J 基准的 31.9%，但仍低于不带工具的 GPT-3。
• 自监督数据生成流水线产生的训练示例让模型学会了在工具无益时“不调用 API”——过滤步骤使用困惑度的降低作为“这次工具调用是否真的有帮助”的信号。
• 工具使用能力只有在达到一定规模时才会显现：参数低于约 775M 的模型即使获得相同的训练信号，也无法可靠地学会何时调用工具。
• 在时间推理任务中，日历工具仅被调用了 0.2%；模型更倾向于将时间相关问题路由到维基百科搜索工具。

哪些结论站得住脚，哪些站不住脚

核心洞察是经得起推敲的：基于困惑度的过滤技巧非常优雅，因为它不需要人工标注，也不需要预知正确答案的“先知”（oracle）——它只需要判断插入的 API 结果是否让周围的文本变得更可预测。这是一个真正的贡献，且数学方面的结果非常惊人。一个 6.7B 模型在 ASDiv 上击败 GPT-3 并不是评估上的取巧；它清晰地证明了在算术任务上，正确的工具调用其价值相当于约 26 倍的参数量。

我觉得不太有说服力的是 QA 的部分。论文将 Toolformer 描述为广泛提升了性能，但 QA 结果显示它并没有击败 GPT-3——一个没用任何工具的巨型模型。作者承认了这一点，但叙事框架（“通常能与更大的模型竞争”）掩盖了这种胜利的局限性：该模型在可以清晰分解为单个计算器或查询调用的任务上胜出，但在需要对检索内容进行深度推理的任务上则失败或仅能打平。

更深层的理论问题在于，自监督流水线假设模型在接受训练之前，就已经具备了生成合理 API 调用的能力。这是一个自举（bootstrapping）问题。对于输入格式清晰的计算器等结构化工具，它是有效的。但对于具有更复杂参数模式的工具——正是你想要用于现实世界账本回写 API 的那种——采样调用的质量会迅速下降。

此外，论文是对每个工具进行独立评估，而非组合评估。它没有展示多步流水线，例如将搜索结果输入计算器。作者将其列为一个局限性，但这确实是一个显著的局限：真实的会计工作流几乎总是需要链式工具调用。

最后，评估是零样本（zero-shot）的。它没有与通过 Prompt 实现少样本（few-shot）学习的 GPT-3 或 GPT-4 进行对比，而后者在论文发表后的几个月内就成为了工具调用的主流范式。NeurIPS 2023 的发布日期意味着实验早于函数调用（function-calling）API 的广泛普及，使得对比基准在发表时显得有些过时。

为什么这对金融 AI 很重要

Toolformer 论文回答了我对 Bean Labs 关注的一个问题：模型能否可靠地学会调用回写 API，成本是多少？数学测试给出的答案是“可以，前提是工具接口简洁且任务可分解为单次调用”。然而，它的失效模式直接对应了账本问题中最困难的部分。

Beancount 的回写操作——交易分类、推断账户映射、生成分录——并不是简单的计算器调用。它们涉及检索上下文（历史条目、会计科目表）、应用规则（过账规则、货币限制），并生成必须符合语法规范的结构化输出。这至少需要三个链式工具调用，而 Toolformer 的架构明确表示不支持链式调用。基于困惑度的训练信号也很难应用于此：当输出是结构化的 .beancount 文件而非自然语言续写时，目前还不清楚“降低周围账本语言的困惑度”意味着什么。

Toolformer 给我们带来的更有用的教训是其“反面启示”：一个回写代理不能仅仅是一个记住了何时调用账本 API 的微调语言模型。它需要一个显式的推理层（ReAct 或类似架构），能够在提交写入之前进行规划、执行并检查中间结果。Toolformer 证明了工具调用是可行的；但它没有证明在具有副作用的结构化操作中，它是安全的。

延伸阅读

• ReAct: Synergizing Reasoning and Acting in Language Models (arXiv:2210.03629) —— 增加了与工具调用交替进行的显式思维链推理步骤；该架构解决了 Toolformer 的链式调用限制，是大多数现代代理（Agent）的基础。
• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) —— 通过 ToolBench 数据集将工具调用扩展到超过 16,000 个真实的 API；这是对真实会计代理可能面临的复杂度水平最接近的压力测试。
• FinMaster (arXiv:2505.13533) —— 基准测试了端到端的会计工作流，包括分录录入和对账；它将展示 Toolformer 在算术上表现出的优势，是否能推广到对 Beancount 至关的多步、受模式限制的任务中。