Toolformer 论文翻译

Abstract

语言模型（LM）表现出惊人的能力，可以仅凭几个示例或文本说明解决新任务，尤其是在规模方面。然而，它们在基本功能方面却表现出矛盾，例如算术或事实查找，在这些问题上功能更简单、更小的模型反而表现更出色。在本文中，我们展示了LM可以通过简单的API自学使用外部工具，并实现最佳效果。我们介绍了Toolformer，这是一个模型，它通过训练来决定调用哪些API、何时调用它们、传递什么参数以及如何最好地将结果合并到未来的token预测中。这是以自监督的方式完成的，每个API仅需要少量演示即可。我们整合了一系列工具，包括计算器、问答系统、搜索引擎、翻译系统和日历。Toolformer在各种下游任务中实现了显著改进的零-shot性能，通常可以与更大的模型竞争，而不会牺牲其核心语言建模能力。

1. 引言

大型语言模型在各种自然语言处理任务上取得了令人印象深刻的零-shot和少-shot结果（Brown等，2020; Chowdhery等，2022，等），并展示了几个新兴的能力（Wei等，2022）。然而，所有这些模型都有几个固有的限制，最多只能通过进一步扩展来部分地解决这些限制。这些限制包括无法访问有关最近事件的最新信息（Komeili等，2022）以及相关的虚构事实的倾向（Maynez等，2020; Ji等，2022），难以理解低资源语言（Lin等，2021），缺乏进行精确计算的数学技能（Patel等，2021）以及对时间进展的无意识（Dhingra等，2022）。
克服当今语言模型的这些限制的简单方法是赋予它们使用外部工具的能力，例如搜索引擎、计算器或日历。然而，现有的方法要么依赖大量的人工注释（Komeili等人，2022；Thoppilan等人，2022），要么仅将工具使用限制在特定任务设置中（例如，Gao等人，2022；Parisi等人，2022），这阻碍了工具在语言模型中更广泛的应用。因此，我们提出了 Toolformer，这是一种以新颖的方式学习使用工具的模型，它满足以下期望：
• 工具的使用应该以自我监督的方式学习，而不需要大量的人工注释。这是重要的，不仅因为这种标注的成本，而且因为人类发现有用的东西可能与模型发现有用的东西不同。
• 语言模型不应失去其普适性，应能够自行决定何时以及如何使用哪个工具。与现有方法相比，这使得可以更全面地使用工具，而不是与特定任务相关联。

我们实现这些目标的方法基于最近提出的使用具有上下文学习（Brown等人，2020）的大型语言模型来从头生成整个数据集（Schick和Schütze，2021b; Honovich等人，2022; Wang等人，2022）的想法：只需几个人类编写的示例，说明API如何使用，我们就可以让语言模型注释具有潜在API调用的大量语言建模数据集。然后，我们使用自我监督的损失来确定哪些API调用实际上有助于模型预测未来的 tokens。最后，我们在语言模型自己认为有用的API调用上进行微调。如图1所示，通过这种简单的方法，语言模型可以学习控制各种工具，并自行选择何时以及如何使用哪个工具。

图1：Toolformer的示例预测。该模型自主决定调用不同的API（从上到下：问答系统、计算器、机器翻译系统和维基百科搜索引擎），以获取完成一段文本所需的有用信息

我们的方法并不依赖于使用的数据集，因此我们可以将其应用于首次预训练模型所使用的完全相同的数据集。这确保了模型不会失去其一般性和语言建模能力。我们在各种不同的下游任务上进行了实验，证明了在学习使用工具之后，基于预训练的GPT-J模型（Wang和Komat- suzaki，2021），该模型具有67亿个参数的Toolformer，实现了更强的零-shot结果，在各种任务上明显优于更大的GPT-3模型（Brown等，2020）和其他几个基线模型。

2. 方法

我们的目标是让一个语言模型M通过API调用获得使用不同工具的能力。我们要求每个API的输入和输出都可以表示为文本序列。这允许使用特殊token将API调用无缝插入到任何给定的文本中，标记每个API调用的开始和结束。

我们将每个API调用表示为一个元组

，其中ac是API的名称，ic是对应的输入。给定一个带有相应结果r的API调用c，我们将不包括其结果和包括其结果的API调用的线性序列分别表示为：

image.png

其中，“<API>”，“</API>”和“→”是特殊token。图1展示了插入文本序列中的线性API调用的一些示例。

实际上，我们使用token序列“ [”，“]”和“->”来表示“<API>”，“</API>”和“→”，以便我们的方法在不修改现有LM词汇的情况下工作。出于可读性的原因，我们仍然在本节中将其称为“<API>”，“</API>”和“→”。

给定一个普通文本数据集

，我们首先将该数据集转换为一个带有API调用的增强数据集C*。这是通过三个步骤完成的，如图2所示：首先，利用M的 in-context learning 能力，我们采样了大量潜在的API调用。然后我们执行这些API调用，最后检查获得的响应是否有助于预测未来的token。这被用作过滤标准。经过过滤，我们合并了不同工具的API调用，得到了增强的数据集C*，并在此数据集上微调M本身。下面将更详细地描述每个步骤。

图2：我们方法的关键步骤，以问答工具为例进行说明：给定一个输入文本 x，我们首先采样一个位置 i 和相应的 API 调用候选项 c1 i，c2 i，......，ck i。然后我们执行这些 API 调用并过滤掉不减小下一个token的损失 Li 的所有调用。所有剩余的 API 调用与原始文本交错，生成一个新的文本 x∗

Sampling API Calls

对于每个API，我们编写一个提示P(x)，鼓励LM使用API调用注释一个示例x = x1，...，xn。图3是问题回答工具的一个提示示例；所有使用的提示都在附录A.2中。

图3：用于生成问题回答工具API调用的示例提示P（x）
让pM(zn+1 | z1，...，zn)是M分配给令牌zn+1作为序列z1，...，zn的继续的概率。我们首先通过计算每个i ∈ {1, . . . , n}的概率
，来抽样最多k个候选API调用位置。其中，pi是M分配给在位置i开始API调用的概率。给定一个抽样阈值τs，我们保留所有位置I = {i | pi > τs}；如果有超过k个这样的位置，我们只保留前k个。

对于每个位置i ∈ I，我们从M中获得最多m个API调用c1i，...，cmi，通过以序列[P (x)，x1，...，xi−1，<API>]作为前缀，并将</API>作为序列结束 token 来从M中进行抽样。

我们舍弃所有M没有生成</API> token的示例。

Executing API Calls

作为下一步，我们执行由M生成的所有API调用以获取相应的结果。如何执行取决于API本身-例如，它可以涉及调用另一个神经网络，执行Python脚本或使用检索系统在大型语料库上执行搜索。每个API调用ci的响应需要是单个文本序列ri。

Filtering API Calls

假设API调用ci在序列x = x1，…，xn中的位置为i，ri是API的响应。此外，给定一个权重序列(wi | i ∈ N)，让

image.png

成为如果在模型的前缀中加入z，则M在标记xi，...，xn上的加权交叉熵损失。我们比较两种不同的损失函数实例化：

image.png

其中ε表示空序列。如果将API调用及其结果作为前缀提供给M，则前者是对所有标记xi, . . . , xn的加权损失。

我们提供e(ci, ri)作为前缀，而不是插入到位置i，因为M尚未对包含API调用的任何示例进行微调，因此将其插入到x的中间会中断流程，并且不与预训练语料库中的模式对齐，从而损害困惑度。

后者是在（i）根本不进行API调用和（ii）进行API调用但不提供响应的情况下获得的损失的最小值。直观地说，如果将API调用及其输入和输出提供给M，使得模型预测未来标记变得更容易，与根本不接收API调用或仅接收其输入相比，API调用对于M是有帮助的。因此，给定筛选阈值τf，我们仅保留以下条件成立的API调用：

image.png

也就是说，添加API调用及其结果相对于不进行任何API调用或不从中获得任何结果，可以将损失降低至少τf。

Model Finetuning

在对所有API调用进行抽样和过滤后，我们最终合并剩余的API调用并将其与原始输入交错。也就是说，对于具有相应API调用和结果(ci, ri)的输入文本x = x1，...，xn在位置i，我们构造新序列x * =

；对于具有多个API调用的文本，我们以类似的方式进行。对于所有x∈C这样做会得到新数据集C∗，其中包含了增强的API调用。我们使用这个新数据集来微调M，使用标准的语言建模目标。重要的是，除了插入的API调用之外，增强的数据集C∗与原始数据集C完全相同。因此，在C∗上微调M会使其接触到与在C上微调相同的内容。此外，由于API调用恰好插入那些位置并带有恰好那些输入，这些位置和输入有助于M预测未来的 token，因此在C∗上微调使得语言模型可以纯粹基于自身的反馈来决定何时以及如何使用哪种工具。

Inference

在使用我们的方法微调M后生成文本时，我们执行常规解码，直到M生成“→”标记，表示它接下来期望API调用的响应。此时，我们中断解码过程，调用适当的API以获取响应，并在插入响应和</API>标记后继续解码过程。

3. Tools

我们探索了各种工具来解决常规语言模型的不足之处。我们对这些工具唯一的限制是它们的输入和输出都可以表示为文本序列，并且我们可以获得它们预期使用的一些演示。具体而言，我们探索了以下五个工具：问答系统、维基百科搜索引擎、计算器、日历和机器翻译系统。每个工具相关的API的潜在调用和返回字符串的一些示例显示在表1中。

我们在下面简要讨论所有工具；更多细节可以在附录A中找到。

问答系统

我们的第一个工具是一个基于另一个语言模型的问答系统，可以回答简单的事实问题。具体而言，我们使用Atlas（Izacard等人，2022），这是一个在自然问题（Kwiatkowski等人，2019）上微调的检索增强语言模型。

Calculator

作为第二个工具，我们使用一个计算器，可以执行简单的数字计算；我们仅支持四种基本算术运算。结果始终舍入到小数点后两位。

Wikipedia Search

我们的第三个工具是一个搜索引擎，给定一个搜索词，它可以从维基百科返回简短的文本片段。与我们的问答工具相比，这种搜索使模型能够获取更全面的关于某个主题的信息，但需要它自己提取相关部分。我们使用BM25检索器（Robertson等人，1995; Baeza-Yates等人，1999）作为我们的搜索引擎，它从KILT（Petroni等人，2021）索引维基百科转储。

Machine Translation System

机器翻译系统是我们的第四个工具，基于一个语言模型，可以将任何语言的短语翻译成英语。更具体地说，我们使用了600M参数的NLLB（Costa-jussà等人，2022）作为我们的多语言机器翻译模型，可以适用于200种语言（包括低资源语言）。使用fastText分类器（Joulin等人，2016）自动检测源语言，而目标语言始终设置为英语。

Calendar

我们的最后一个工具是一个日历API，当查询时，返回当前日期而不需要任何输入。这为需要时间意识的预测提供了时间上下文。

4. Experiments

我们研究了我们的方法是否使模型能够在没有进一步监督的情况下使用工具，并决定何时以及如何调用可用的工具。为了测试这一点，我们选择了各种下游任务，其中我们假设至少考虑到的一种工具是有用的，并在零样本设置下评估性能（第4.2节）。除此之外，我们还确保我们的方法不会损害模型的核心语言建模能力；我们通过查看两个语言建模数据集上的困惑度来验证这一点（第4.3节）。最后，我们研究了模型大小如何影响使用工具学习的能力（第4.4节）。

4.1 实验设置

数据集生成

在所有实验中，我们使用CCNet (Wenzek et al.，2020)的一个子集作为我们的语言建模数据集C，使用GPT-J (Wang and Komatsuzaki, 2021)作为我们的语言模型M。为了降低用API调用注释C的计算成本，我们为一些API定义了启发式方法，以获取一个子集C，其中API调用比平均文本更有帮助。例如，如果文本包含至少三个数字，我们仅考虑计算器工具的文本。使用的启发式方法的详细信息在附录A中给出。为了从C获取C∗，我们执行第2节中描述的所有步骤，并在过滤步骤中过滤掉所有API调用被消除的示例。至于权重函数，我们使用

image.png

以确保API调用发生在“API提供的信息对模型有帮助”的地方附近。阈值τs和τf针对每个工具单独选择，以确保具有足够的示例数。有关详细信息，请参见附录A。表2显示了我们最终数据集的相关统计信息，其中包括API调用。

image.png

模型微调

我们使用批大小为128和学习率为

对M在C∗上进行微调，其中前10%的训练进行线性预热。我们的微调过程的详细信息在附录B中给出。

基准模型

在本节的剩余部分，我们主要比较以下模型：
• GPT-J：没有任何微调的常规GPT-J模型。
• GPT-J + CC：对C进行微调的GPT-J，我们的CCNet子集，没有任何API调用。
• Toolformer：在C∗上进行微调的GPT-J，我们的CCNet子集，增加了API调用。
• Toolformer（禁用）：与Toolformer相同的模型，但在解码期间禁用API调用。
对于大多数任务，我们还将其与OPT (66B) (Zhang et al.，2022)和GPT-36 (175B) (Brown et al.，2020)进行比较，这两个模型的大小分别比我们其他基准模型大约10倍和25倍。

4.2 下游任务

我们在各种下游任务上评估所有模型。在所有情况下，我们考虑提示的零样本设置——即，模型被指示用自然语言解决每个任务，但我们不提供任何上下文示例。这与以前有关工具使用的研究不同（例如，Gao等人，2022年；Parisi等人，2022年），在这些研究中，模型提供了特定于数据集的示例，说明如何使用工具来解决具体任务。我们选择更具挑战性的零样本设置，因为我们有兴趣看到Toolformer是否能够在用户没有事先指定哪些工具应该如何使用来解决特定问题的情况下正常工作。
我们使用标准的贪婪解码，但对于Toolformer，我们进行了一项修改：我们不仅让模型在 <API> 是最可能的标记时开始进行 API 调用，而且每当它是最可能的 k 个标记之一时都进行 API 调用。对于 k = 1，这相当于常规的贪婪解码；我们使用 k = 10 来增加我们的模型使用其可以访问的 API 的倾向。同时，我们最多只对每个输入进行一次 API 调用，以确保模型不会陷入一个循环中，不断调用 API 而不产生任何实际输出。这些修改的效果在第5节中进行了探讨。

4.2.1 LAMA

我们在LAMA基准测试的SQuAD、Google-RE和T-REx子集上评估我们的模型（Petroni等人，2019）。对于每个子集，任务是用缺失的事实（例如日期或地点）完成一个简短的陈述。由于LAMA最初是设计用于评估掩码语言模型（例如Devlin等人，2019），因此我们过滤掉掩码标记不是最后一个标记的示例，以便剩余的示例可以按从左到右的方式处理。为了考虑到不同的分词和从不通知模型需要一个单词的增加复杂性，我们使用比精确匹配略为宽松的评估标准，只检查正确单词是否在模型预测的前五个单词中。由于LAMA基于直接从维基百科获取的陈述，我们防止Toolformer使用维基百科搜索API，以避免给它带来不公平的优势。
所有模型的结果都可以在表3中看到。

所有没有使用工具的GPT-J模型表现相似。关键是，Toolformer明显优于这些基准模型，在最佳基准模型的基础上分别提高11.7、5.2和18.6个点。尽管OPT（66B）和GPT-3（175B）都更大，但它们的表现仍然明显不如Toolformer。这是因为在几乎所有情况下（98.1%），该模型独立决定向问题回答工具询问所需信息；只有极少数情况下（0.7%），它使用不同的工具，或者根本不使用工具（1.2%）。

4.2.2 数学数据集

我们在ASDiv（Miao等人，2020）、SVAMP（Patel等人，2021）和MAWPS基准测试（Koncel-Kedziorski等人，2016）上测试数学推理能力。我们再次考虑到我们以零-shot设置测试所有模型，通过使用更宽松的评估标准来考虑这一点：由于所需的输出总是一个数字，因此我们只检查模型预测的第一个数字。
表4显示了所有基准测试的结果。

尽管GPT-J和GPT-J + CC表现大致相同，但Toolformer在禁用API调用时仍然实现了更强的结果。我们推测这是因为该模型针对许多API调用和其结果进行了微调，提高了其自身的数学能力。尽管如此，允许模型进行API调用将所有任务的性能提高了一倍以上，而且明显优于更大的OPT和GPT-3模型。这是因为在所有基准测试中，对于97.9%的所有示例，模型决定向计算器工具寻求帮助。

4.2.3 Question Answering

// TODO

5. Analysis

// TODO

6. Related Work

// TODO

7. 限制

虽然我们的方法使语言模型能够自我学习如何使用各种工具，但目前的方法也存在一些明显的限制。其中一个限制是Toolformer无法在工具之间进行链接（即使用一个工具的输出作为另一个工具的输入）。这是因为每个工具的API调用是独立生成的；因此，在微调数据集中没有链接工具使用的示例。我们当前的方法也不允许语言模型以交互方式使用工具，特别是像搜索引擎这样的工具，可能返回数百个不同的结果，使得语言模型可以浏览这些结果或者像中野等人（2021）那样细化其搜索查询，在某些应用中这非常关键。除此之外，我们发现使用Toolformer训练的模型通常对其输入的确切措辞非常敏感，这也许并不奇怪，因为已知在 zero-
and few-shot settings 中，LM对其提供的提示非常敏感（Jiang等人，2020；Schick和Schütze，2021a）。根据工具的不同，我们的方法也非常低效，例如，处理超过一百万个文档只能得到几千个有用的计算器API调用的示例。解决这个问题的潜在方法可能是迭代应用我们的方法，类似于相关的引导方法（Schick和Schütze，2021a；Izacard和Grave，2021；Parisi等人，2022）。最后，Toolformer在决定是否进行API调用时，目前不考虑由API调用产生的工具相关的计算成本。

8. 结论

我们介绍了Toolformer，一种语言模型，它通过简单的API调用以自监督的方式学习如何使用不同的工具，如搜索引擎、计算器和翻译系统。这是通过微调大量样本API调用来实现的，这些调用是基于它们是否减少未来 token 的困惑度进行过滤的。Toolformer显著提高了一个6.7B参数的GPT-J模型的零-shot性能，使其能够在不同的下游任务上甚至胜过一个更大的GPT-3模型。