Toolformer: Language Models Can Teach Themselves to Use Tools
Toolformer: Language Models Can Teach Themselves to Use Tools - 中文验证版
英文原始依据卡片：toolformer_2023.md
状态：已翻译。
元数据
- 阅读状态： read complete
- 年份： 2023
- 计算范式： 推理阶段计算与后训练 (
inference_time_compute_post_training) - PDF： 2023-toolformer_2023.pdf
- 抽取文本： 2023-toolformer_2023.txt
- PDF URL： https://arxiv.org/pdf/2302.04761.pdf
- OpenAlex：
- 引用计数来源/日期：
- 引用计数：
- 阅读卡创建日期： 2026-06-15
计算设置
论文明确陈述了其训练硬件和若干内存选择。Toolformer 基于 GPT-J 6.7B 参数。附录 B 说明作者每个 API 使用最多 25k 示例，最大序列长度 1,024，有效 batch size 128，DeepSpeed ZeRO-3，8 个 NVIDIA A100 40GB GPU，BF16，训练最多 2,000 步。他们每隔 500 步在 1,000 示例 CCNet 开发集上评估困惑度，并选择最佳检查点。
该设置是一个紧凑的多 GPU 微调任务，而非前沿模型预训练。ZeRO-3 跨设备分片优化器状态、梯度和参数，这是使 6.7B 模型适配 8 个 40GB A100s 配合 batch 128 和 1,024 token 序列的关键内存适配。BF16 相对于 FP32 减少了内存和带宽，同时保留动态范围。来源未给出 wall-clock 时间或下游评估的推理硬件。
瓶颈
瓶颈是在没有人工标注每个 API 调用的情况下生成有用的工具使用监督。工具调用是稀疏的：大多数文本位置不需要计算器、日历、QA 系统、翻译系统或 Wikipedia 搜索。天真地在每个采样调用上进行微调将浪费上下文、教授坏习惯并降低普通语言建模质量。但执行和过滤候选调用本身是昂贵的，因为系统必须采样可能的插入点、生成候选 API 调用、执行 API，并评分结果是否降低了未来 token 的损失。
在推理时，瓶颈变为分支和延迟。一个可以调用工具的模型也可以过度调用工具、陷入循环，或在 API 成本高于预期收益时调用工具。论文通过每次输入最多允许一个 API 调用，并在 API token 处于 top-k 下一个 tokens 之一（而非仅最可能的一个）时触发 API 调用来控制这一点。这改善了工具使用，但使计算预算成为一个解码超参数。
方法适配
Toolformer 通过使用语言模型自身的损失作为监督过滤器来适配。对于每个 API，作者编写少量演示，提示 GPT-J 将调用插入普通文本中。他们采样模型对 API 标记分配足够概率的候选位置，每个位置采样最多五个 API 调用，执行每个调用，并比较有和没有 API 结果的未来 token 交叉熵。仅当响应将损失降低至少过滤阈值时才保留该调用。保留的调用随后被插入原始 CCNet 文本，产生一个保留普通语言数据并添加有帮助调用位置的增强语料。
工具被选择为文本输入/文本输出，以便适配普通 LM 上下文：一个问答模型、一个简单算术计算器、一个基于 KILT Wikipedia 的 BM25 Wikipedia 搜索引擎、一个基于 NLLB 的翻译系统和一个日历 API。在推理时，模型生成 API 调用，外部系统返回文本结果，模型继续生成。因此该方法在一次微调中花费 GPU 计算来教授调用位置，仅在模型决定调用工具时才花费工具/API 延迟。
证据
过滤过程产生了非常不同数量的工具监督。在过滤阈值 1.0 下，表 2 报告 18,526 个问答示例、60,974 个 Wikipedia 搜索示例、994 个计算器示例、20,587 个日历示例和 1,034 个机器翻译示例。这是采样效率瓶颈的直接迹象：处理许多文档仅产生少量有用的计算器调用。
下游结果显示了使用调用时的收益。在 LAMA 上，Toolformer 在 SQuAD 上达到 33.8，在 Google-RE 上为 11.5，在 T-REx 上为 53.5，相比 Toolformer-disabled 为 22.1、6.3 和 34.9。尽管基于 GPT-J 6.7B，它还在这些报告的 LAMA 子集上超过了 OPT 66B 和 GPT-3 175B。在数学基准上，启用计算器调用将 Toolformer 从 ASDiv 的 14.8 提升到 40.4，SVAMP 从 6.3 到 29.4，MAWPS 从 15.0 到 44.0；论文指出模型在这些基准的 97.9% 的示例上请求计算器帮助。
语言建模成本在报告指标中很小。表 8 给出 Toolformer-disabled 的 WikiText 困惑度为 10.3，与 GPT-J+CC 相同，CCNet 困惑度两者均为 10.5。在 DATESET 上，Toolformer 达到 27.3，而禁用 API 调用为 5.9，GPT-3 175B 为 0.8，显示日历 API 可以在不引起广泛困惑度退化的情况下获取任务性能。表 9 还显示了推理计算旋钮：对于 T-REx，从 k=0 移至 k=10 将 API 调用从 0% 增加到 98.1%，并将总分从 34.9 提高到 53.5。
历史影响
Toolformer 使工具使用看起来像一种学得的语言模型行为，而非特定于 prompt 的包装器。其贡献不仅在于模型可以使用计算器或搜索引擎，还在于一个 6.7B 模型可以在普通文本上创建、过滤并从自己的工具调用轨迹中学习。在计算历史层面，它是一个从仅推理 prompting 到将何时花费外部计算的决策内化的后训练的桥梁。
局限
局限也是计算结构性的。Toolformer 不能链接工具，因为每个工具的 API 调用是独立生成的，因此微调数据中不包含一个工具的输出成为另一个工具输入的示例。它不能交互式地浏览许多搜索结果，或在面对坏输出时细化查询。模型在决定是否调用 API 时对输入措辞敏感，论文明确指出它未考虑 API 调用的工具依赖计算成本。最后，自监督过滤过程对某些工具来说是采样低效的，因此从少量 API 转向大型工具生态将倍增预处理和执行成本。
链接
- 计算范式：
history/compute_regimes/inference_time_compute_post_training/README.md - 来源 PDF 和抽取文本见上方元数据。
- Queue 状态：
read_complete。 - 方法索引：tool_use
- 对照更新：compute bottlenecks