Toolformer: Language Models Can Teach Themselves to Use Tools 论文汇报

1. 论文基本信息

• 论文标题：Toolformer: Language Models Can Teach Themselves to Use Tools
• 作者：Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Eric Hambro, Luke Zettlemoyer, Nicola Cancedda, Thomas Scialom
• 机构：FAIR, Meta；Universitat Pompeu Fabra
• 会议：NeurIPS 2023

本文提出 Toolformer：一种让语言模型通过自监督方式学习使用外部工具的方法。论文的核心主张是，语言模型不必依赖大量人工标注，也不必针对每个下游任务单独设计 few-shot tool-use prompt；只需要为每个 API 提供少量示例，模型就可以在普通语言建模语料中自动生成候选 API call，执行工具，并用 loss-based filtering 筛选真正有助于预测后续文本的调用样本，最后通过普通语言模型微调获得主动调用工具的能力。

这篇论文的重要性不在于使用了计算器、搜索、翻译或日历这些具体工具，而在于提出了一个可自动构造工具调用训练数据的框架。它把“工具调用是否有用”转化为一个可计算的语言建模信号：如果加入工具返回结果后，模型预测后续 token 的 loss 明显下降，那么这个 API call 就被视为有用。

2. 背景与问题定义

2.1 为什么语言模型需要外部工具

Toolformer 的出发点是：大语言模型虽然在零样本和少样本任务上很强，但仍然有一些不是靠继续增大参数就能稳定解决的短板。

第一，模型的参数知识有时效性问题。训练后发生的新事件、当前日期、实时天气、数据库最新状态等信息不会自然进入模型；即使是训练中见过的事实，模型也可能记错或在生成时幻觉。

第二，模型不擅长精确计算。它能生成看似合理的推理文本，但在四则运算、比例换算、日期推算等问题上容易出错。对这类任务，一个简单计算器往往比一个更大的语言模型可靠。

第三，通用 LM 不一定在所有专门技能上优于专用系统。问答系统、检索系统、机器翻译系统、数据库执行器等外部模块，可能在各自子任务上更稳定、更便宜，也更容易更新。

因此，本文的基本思想是：不要要求语言模型把所有能力都存进参数里，而是让它在需要时调用外部工具，由工具提供事实、计算、翻译或时间信息，语言模型负责判断何时调用、如何组织调用以及如何继续生成。

2.2 既有工具使用方法的缺口

在 Toolformer 之前，让 LM 使用工具主要有两类做法。

第一类是人工标注。人类标出某个位置应该调用哪个工具、参数是什么、返回结果如何纳入答案。这种方法清楚但成本高，很难扩展到大量工具和大规模语料。

第二类是任务特定 prompting。例如在数学题 prompt 里示范如何调用计算器，在问答任务 prompt 里示范如何搜索。这种方式不需要大规模标注，但它把工具使用能力绑定在具体任务上：用户必须预先知道该任务需要什么工具，并且为每个任务设计示例。

这两类方法都没有真正解决一个更一般的问题：模型能否从普通语言建模数据中，自动学会一种跨任务的工具调用行为。

2.3 本文要解决的问题

Toolformer 要解决的问题可以概括为：

给定一组已经存在的外部工具，如何只用少量工具示例，让语言模型自动构造工具调用训练数据，并学会在未知下游任务中自主决定何时调用工具、调用哪个工具、传什么参数以及如何使用工具返回结果。

这个问题包含四个子能力：

论文提出两个约束：工具使用应尽量自监督学习，不能依赖大规模人工 tool-use 标注；同时，模型学会工具调用后，不能明显损害原本的通用语言建模能力。

3. 核心方法 / 模型

3.1 一句话概括方法

Toolformer 的方法一句话是：

先让原始语言模型在普通文本中采样可能有用的 API call，执行这些调用，再用“工具结果是否降低后续 token 的预测 loss”来筛选样本，最后用筛出的带 API call 文本微调模型。

这句话对应三个关键设计：候选调用由模型自己生成，工具调用会被真实执行，保留与否由 loss-based filtering 自动决定。

3.2 模型最终要学会什么样的工具调用

论文希望模型学到的不是一个独立的外部 planner，而是在自然语言生成过程中插入工具调用。Figure 1 展示了这种目标行为。

这张图里有四类典型调用：

• QA(...) 用来补事实答案，例如查询期刊出版方；
• Calculator(...) 用来做精确比例计算，例如 400 / 1400 -> 0.29；
• MT(...) 用来翻译外语短语，例如 tortuga -> turtle；
• WikiSearch(...) 用来检索背景知识片段，例如 Brown Act 的解释。

注意 API call 被插在答案附近，而不是作为最终答案之外的附录。例如计算器返回 0.29 后，模型继续生成 29%。这说明 Toolformer 的工具使用是“生成过程中的中间信息补充”，不是传统意义上先规划、再执行、最后写报告的 agent 流程。

3.3 API call 的表示方式

论文把一个 API call 表示为：

c = (a_c, i_c)

其中 a_c 是 API 名称，i_c 是输入参数。例如：

QA("Who is the publisher of The New England Journal of Medicine?")
Calculator("400 / 1400")
MT("tortuga")
WikiSearch("Brown Act")
Calendar()

API call 在文本中有两种线性化形式：

e(c)    = <API> API_NAME(input) </API>
e(c,r)  = <API> API_NAME(input) -> result </API>

实际实现中，作者没有改模型词表，而是用普通 token 序列近似这些特殊标记。例如论文中展示为：

[Calculator(400 / 1400) -> 0.29]

这里的 Calculator(...) 是模型生成的一段特殊文本。外部系统识别到 API 名称后，执行对应工具并填入返回结果。

3.4 使用了哪些工具

论文使用五类工具：

这里的 API 是广义接口，不等同于真实线上服务 API。工具可以是本地程序、检索器、另一个神经模型或简单函数。论文实验主要在可控工具环境中验证训练思想，没有系统处理真实 API 的认证、权限、失败重试和安全问题。

3.5 训练数据构造总流程

Toolformer 的核心不是直接让模型在测试时看工具说明，而是先自动构造一批带 API call 的训练文本。整体流程见 Figure 2。

流程可以分成五步：

普通文本语料 C
  -> 为每个工具用 few-shot prompt 采样候选 API call
  -> 执行这些 API call，得到工具返回结果
  -> 用 loss-based filtering 筛选有用调用
  -> 把保留的调用插回原文，得到 C*
  -> 用 C* 微调语言模型

Figure 2 的例子是 Pittsburgh is also known as the Steel City.。模型在 the Steel City 前生成两个候选问题：一个问 Pittsburgh 的别名，另一个问 Pittsburgh 属于哪个国家。两个问题都能被执行，但只有返回 Steel City 的调用能帮助预测后文，因此被保留；返回 United States 的调用虽然事实正确，却对当前文本没有帮助，因此被过滤掉。

这说明 Toolformer 的筛选标准不是“工具调用是否事实正确”，而是“工具结果是否帮助当前位置之后的文本预测”。

3.6 第一步：Sampling API Calls

这一步解决的是：在没有人工标注的普通文本中，模型如何提出候选工具调用。

对每个 API，作者写一个 few-shot prompt P(x)，诱导模型在文本 x = x_1, ..., x_n 中插入该工具的调用。正文完整展示了 QA 工具的 prompt，也就是 Figure 3。

Figure 3 展示了训练数据生成时的真实提示词结构。它先说明任务：给一段文本添加 Question Answering API call；再规定调用格式：可以写 [QA(question)]；然后给两个示例：Joe Biden 的出生地和 Coca-Cola 的别名/制造商；最后给待处理输入 x，让模型继续生成带 QA 调用的版本。

这个 prompt 的作用不是让模型回答 QA 任务，而是让模型学会“在原文答案出现之前插入一个能获得该答案的问题”。例如示例中，QA("Where was Joe Biden born?") 被插在 Scranton 前面，因为这个工具返回值可以帮助预测后面的 Scranton。

这里要注意：Figure 3 只是 QA 工具的 prompt。论文方法是每个工具各自写一个 prompt，分别为 QA、Calculator、WikiSearch、MT、Calendar 生成候选调用。之后再通过统一的执行和过滤机制，把通过筛选的调用合并进最终训练语料。

形式上，给定 prompt 和文本前缀，作者在每个位置 i 计算模型开始 API call 的概率：

p_i = P_M(<API> | P(x), x_1:i-1)

如果 p_i 超过采样阈值 tau_s，该位置就被视为候选调用位置。每个位置再采样若干 API call 候选。这一步只负责生成候选，不保证正确。

例如：

Pittsburgh is also known as the Steel City.

模型可能在 the Steel City 前生成两个候选：

QA("What other name is Pittsburgh known by?")
QA("Which country is Pittsburgh in?")

两者看起来都像合理问题，但只有第一个对后续文本真正有帮助。

3.7 第二步：Executing API Calls

候选 API call 会被真正执行，得到工具返回结果：

QA("What other name is Pittsburgh known by?") -> Steel City
QA("Which country is Pittsburgh in?") -> United States
Calculator("400 / 1400") -> 0.29
MT("tortuga") -> turtle
Calendar() -> Today is Monday, January 30, 2023.

这一步使 Toolformer 不只是普通 self-training。模型生成的候选不是直接当作伪标签使用，而是必须通过外部工具得到实际返回结果。

3.8 第三步：Filtering API Calls

这是论文最核心的技术设计。作者用语言建模 loss 判断一个工具调用是否有用。

设 API call 位于文本位置 i，工具返回结果为 r_i。作者定义：

L_i(z) = - sum_j w_{j-i} log P_M(x_j | z, x_1:j-1)

含义是：给模型额外提供信息 z 后，看它预测位置 i 之后文本的加权 cross entropy loss 有多低。权重 w 让靠近 API call 的后续 token 更重要，因为工具结果通常应当帮助预测紧接着出现的信息。

论文比较三种情况：

不提供 API call
只提供 API call，不提供结果
提供 API call + 工具返回结果

形式上：

L_i^+ = L_i(e(c_i, r_i))
L_i^- = min(L_i(empty), L_i(e(c_i, empty)))

如果满足：

L_i^- - L_i^+ >= tau_f

就保留这个 API call。

这条规则的含义是：只有当“API 调用 + 工具返回结果”比“什么都不给”或“只给 API 调用”明显更能帮助模型预测后续文本时，该调用才被认为有用。

这个设计排除了两类无效样本。第一类是工具结果本身没帮助的调用，例如 Calculator("400 + 1400") -> 1800 对预测 29% 没有帮助。第二类是 API 调用文本本身泄露了答案，但工具返回结果没有额外贡献的调用。作者用 min(L_i(empty), L_i(e(c_i, empty))) 做 baseline，就是为了避免把这类调用误判为有效。

3.9 第四步：Model Finetuning

过滤后，作者把保留下来的 API call 插回原始文本，形成增强语料 C*：

Pittsburgh is also known as
[QA("What other name is Pittsburgh known by?") -> Steel City]
the Steel City.

然后用标准语言模型目标微调原模型。这里不是训练一个单独的工具选择器，也不是训练一个显式 router。模型直接学习在文本生成过程中产生 API 名称、参数和结果占位模式。

论文强调，除插入 API call 外，C* 的原文内容与 C 相同。因此作者希望模型获得工具调用能力的同时，不损害普通语言建模能力。这个假设后面通过 perplexity 实验检查。

3.10 第五步：Inference

推理时，模型正常生成文本。一旦生成到表示工具结果即将出现的符号，系统暂停解码，执行对应 API，再把结果插入上下文。例如：

模型生成：[Calculator(400 / 1400) ->
系统执行：Calculator("400 / 1400") = 0.29
上下文变为：[Calculator(400 / 1400) -> 0.29]
模型继续生成：29% passed the test.

实验中还有两个重要工程设置：

• 当 <API> 位于 top-10 候选 token 中时，就允许模型开始 API call，而不是必须让 <API> 成为 top-1；
• 每个输入最多允许一次 API call，避免模型陷入不断调用工具的循环。

这说明 Toolformer 并不是完全无约束的自主工具系统。它的推理行为仍然依赖解码规则辅助，并且被限制为单次工具调用。

3.11 为什么模型能区分不同工具

Toolformer 没有显式工具路由器。模型区分工具主要依赖三点。

第一，不同工具有不同函数名和输入格式：

QA("question")
WikiSearch("search term")
Calculator("expression")
MT("foreign phrase")
Calendar()

第二，每个工具单独用 few-shot prompt 生成候选调用，再执行、过滤。也就是说，训练数据生成阶段不是把所有工具混在一个 prompt 里让模型自由选，而是为每个 API 分别生成可能样本。

第三，过滤后的样本会自然形成模式：事实补全附近常出现 QA，知识解释附近常出现 WikiSearch，数字比例或算术附近常出现 Calculator，外语短语附近常出现 MT，日期相关文本附近常出现 Calendar。微调后，模型通过这些分布模式隐式学会在不同场景选择不同工具。

这种设计简单有效，但也带来限制：工具选择不是基于显式 schema 理解，也不是现代 function calling 那种运行时工具列表选择。它高度依赖训练样本分布和 prompt 形式，难以稳定扩展到复杂工具库和多步工具组合。

4. 实验结果与分析

4.1 实验设置

作者使用 GPT-J 6.7B 作为基础模型，在 CCNet 子集上构造带 API call 的训练语料。为降低标注成本，部分工具会先用启发式筛选更可能有用的文本。例如计算器工具只考虑包含至少三个数字的文本。

主要比较对象包括：

• GPT-J：原始 6.7B 模型；
• GPT-J + CC：在普通 CCNet 子集上继续微调，但不插入 API call；
• Toolformer disabled：完成 Toolformer 训练，但推理时禁用 API call；
• Toolformer：允许调用工具；
• OPT 66B 和 GPT-3 175B：更大规模模型。

实验采用 prompted zero-shot 设置：测试时给自然语言任务说明，但不给该数据集的示例，也不告诉模型应该使用哪个工具。这里的 zero-shot 不是指模型没学过工具，而是指没有下游任务特定 demonstrations。

Table 2 显示，不同工具留下的有效样本数量差异很大。WikiSearch 和 QA 的保留样本较多，而 Calculator 和 MT 的样本明显更少。这说明 loss filtering 虽然自动化，但并不高效；某些工具需要处理大量文本才能筛出少量有用调用。

4.2 LAMA 事实补全与数学任务

Table 3 是论文最有说服力的结果之一。

在 LAMA 事实补全任务上，Toolformer 主要使用 QA 工具。结果显示，Toolformer 在 SQuAD、Google-RE 和 T-REx 子集上分别达到 33.8、11.5、53.5，明显高于 GPT-J 的 17.8、4.9、31.9，也高于 GPT-3 175B 的 26.8、7.0、39.8。作者报告，模型在 98.1% 的 LAMA 样本中选择使用 QA 工具。

在数学应用题任务上，Toolformer 主要使用 Calculator。ASDiv、SVAMP、MAWPS 上，Toolformer 分别达到 40.4、29.4、44.0，而 GPT-J 是 7.5、5.2、9.9，GPT-3 是 14.0、10.0、19.8。作者报告，模型在 97.9% 的数学样本中选择调用计算器。

这组结果支持论文最核心的 claim：对于事实补全和精确计算这类任务，外部工具可以让较小模型超过大模型。但评估标准也相对宽松，例如数学任务主要检查模型输出中的第一个数字是否正确；因此不能把这些数字直接等同于完整数学推理能力。

4.3 开放域问答、跨语言问答与时间任务

在 WebQuestions、Natural Questions 和 TriviaQA 上，作者禁用了 QA 工具，否则任务会过于直接，主要测试模型是否能使用 WikiSearch。Toolformer 在 WebQS、NQ、TriviaQA 上得到 26.3、17.7、48.8，显著高于同尺寸 GPT-J，但低于 GPT-3 在 WebQS、NQ 和 TriviaQA 上的 29.0、22.6、65.9。

这个结果说明搜索工具有帮助，但论文中的 WikiSearch 只是 BM25 Wikipedia 检索器，模型不能交互式浏览多个结果，也不能根据失败结果改写 query。因此，在开放域 QA 这种更复杂的信息获取任务上，Toolformer 的收益有限。

在 MLQA 上，Toolformer 会使用 MT 工具把非英文问题翻译成英文。API call 对所有语言都有一定帮助，但整体不稳定，Toolformer 没有稳定超过 GPT-J。论文认为原因之一是继续在 CCNet 上微调损害了部分多语言能力。

时间任务中，Toolformer 在 DATESET 上从 GPT-J 的 3.9 提升到 27.3，Calendar 工具贡献明显。但在 TEMP LAMA 上，提升并不主要来自 Calendar，因为模型几乎不用日历，而更多依赖 QA 和 WikiSearch。这暴露了单次工具调用限制：理想策略可能是先用 Calendar 获取当前日期，再把日期作为条件问 QA，但 Toolformer 训练和推理设置都不支持这种链式工具调用。

4.4 语言建模能力是否退化

作者用 WikiText 和 CCNet held-out subset 检查普通语言建模能力。结果显示，在禁用 API call 的情况下，Toolformer 相比 GPT-J + CC 没有明显增加 perplexity。这支持作者的说法：在插入 API call 的语料上微调，没有显著破坏普通语言建模能力。

不过这个结论也有边界。作者没有评估“允许 API call 时”的 perplexity，因为那需要对所有可能 API call 做边缘化，计算不可行。因此实验只能说明禁用工具时的语言建模能力没有明显坏掉，不能完全说明工具增强生成在所有普通文本场景下都稳定。

4.5 模型规模与工具使用能力

Figure 4 比较了 GPT-2 不同规模和 GPT-J 使用工具后的表现。结果显示，较小模型无法有效利用工具，工具使用能力大约在 775M 参数附近才明显出现。随着模型规模增大，不使用工具的能力会提升，但使用工具带来的增益仍然存在。

这个结果说明 Toolformer 的方法仍然依赖基础模型能力。外部工具不是简单外挂；模型必须先具备足够的语言理解、参数生成和上下文整合能力，才能把工具结果转化为有效输出。

5. 总结

Toolformer 的核心贡献可以概括为三点。

第一，它提出了一种自监督工具调用数据构造方法：用少量工具示例让模型生成候选 API call，再通过执行工具和 loss-based filtering 自动筛选有用调用。

第二，它把工具使用能力整合进语言模型本身。模型不是依赖外部显式 planner 或任务专用 prompt，而是在生成过程中直接产生 API 名称、参数和结果占位，由系统执行工具后继续生成。

第三，它在多个 zero-shot 下游任务上证明，工具使用可以显著增强较小模型，尤其是在事实补全、精确计算和日期相关任务中。

这篇论文真正优秀的地方是方法简洁，且抓住了 tool-use 训练数据昂贵这一核心瓶颈。它没有试图手工定义所有场景下的工具调用规则，而是让“工具结果是否帮助预测后续文本”成为自动过滤标准。

6. 个人思考与展望

6.1 优点

Toolformer 最值得学习的是它的训练信号设计。很多 tool-use 方法的问题是缺数据：不知道哪里该调用工具，也不知道调用是否有用。Toolformer 用语言建模 loss 作为自监督判断标准，把这个问题变成可自动处理的数据构造流程。

第二个优点是工具接口足够统一。无论背后是 QA 模型、BM25 检索、计算器、翻译模型还是日历函数，模型看到的都是文本化 API call。这使方法具有一定通用性。

第三个优点是实验设计有较好的对照。GPT-J + CC 排除了继续预训练本身带来的收益，Toolformer disabled 可以观察训练 API call 但禁用工具时的影响，与 GPT-3 / OPT 的比较则展示了工具对小模型能力边界的补偿效果。

6.2 局限

Toolformer 的核心假设是：有用工具调用会降低局部后续 token 的预测 loss。这个假设对事实补全、比例计算、短语翻译非常合理，但对长链推理、多步搜索、规划执行并不充分。复杂任务中，一个工具调用的价值可能要很多步之后才显现，不能只看局部 token loss。

第二，Toolformer 不支持链式工具调用。论文明确指出，API call 是为每个工具独立生成的，训练数据里没有“用一个工具输出作为另一个工具输入”的样本。因此它无法自然学习 Calendar -> QA 或 Search -> Calculator -> Answer 这样的组合。

第三，它不支持交互式工具使用。WikiSearch 返回不好时，模型不能浏览多个结果、不能重写查询、不能多轮验证。这也是开放域 QA 上低于 GPT-3 的重要原因。

第四，样本效率不高。论文提到，处理超过一百万文档后，计算器工具只得到几千个有用调用样本。自动化不等于高效，尤其当有用调用本身在普通文本中稀疏时。

第五，它没有考虑工具调用成本。不同工具的延迟、费用、失败率和安全风险可能差异很大，但 filtering 和 inference 主要关注预测收益，没有把成本纳入决策。

6.3 对后续研究的启发

Toolformer 的思路可以自然扩展到几个方向。

第一，可以把 loss-based filtering 扩展为任务级 reward filtering。对于复杂 agent 任务，局部 token loss 不够，可以用任务完成率、执行成功、代码测试通过、检索证据一致性等更长期信号筛选工具调用轨迹。

第二，可以构造链式工具调用训练数据。不是独立生成每个 API call，而是允许模型生成多步工具计划，并用执行结果验证整个轨迹是否有用。

第三，可以把工具成本纳入学习目标。一个工具调用不仅有收益，也有延迟、费用和失败风险。更现实的系统应学习何时“不值得调用工具”。

第四，可以结合现代 function calling / tool schema。Toolformer 的工具选择是隐式文本模式学习，后续系统可以把自监督数据构造思想和显式工具 schema、权限控制、错误恢复机制结合起来。

总体来看，Toolformer 是一篇思路清晰、贡献明确的论文。它没有解决真实世界 tool agent 的全部问题，但它很好地回答了一个基础问题：语言模型能否通过自监督方式学会调用外部工具。答案是可以，但主要在局部、单步、工具与任务高度匹配的场景中有效。

6.4 与现代大模型 Agent 工具调用的类比

由 Toolformer 很自然可以联想到今天的大模型 Agent 工具调用。两者的共同出发点是一致的：不要指望语言模型把所有事实、计算、检索和执行能力都固化在参数里，而是把外部系统包装成工具，让模型在需要时发起调用，再把工具返回结果纳入后续推理或生成。

可以把 Toolformer 看作现代 tool-using Agent 的一个训练侧原型。它关心的是：模型如何从普通文本中自动学会“什么时候该调用工具，以及调用结果是否真的有用”。现代 Agent 系统更关心的是：在真实任务中，模型如何基于工具 schema 产生结构化调用，运行时如何执行工具、返回结果、继续规划、处理错误并控制权限和成本。

因此，二者的关系不是“Toolformer 就是现代 Agent”，而是“Toolformer 提前抓住了现代 Agent 的一个核心问题”：语言模型要成为更可靠的任务执行者，必须学会把一部分能力外包给可执行工具。区别在于，Toolformer 主要解决工具调用数据如何自动构造和训练；现代 Agent 则进一步把工具调用放进真实交互循环，强调 schema、运行时、权限、错误处理、长期状态和任务级成功。