【Toolformer: Language Models Can Teach Themselves to Use Tools 论文略读】

Information

标题： Toolformer：语言模型可以自学使用工具
时间： 2023/02/09
会议： Computation and Language(CL)
作者： Timo Schick Jane Dwivedi-Yu Roberto Dessì†Roberta Raileanu Maria Lomeli Luke Zettlemoyer Nicola Cancedda Thomas Scialom
单位： Meta AI Research †Universitat Pompeu Fabra
链接： https://arxiv.org/pdf/2302.04761.pdf

Abstract

Q：语言模型(LMs)显示出从几个例子或文本指令解决新任务的卓越能力，特别是在规模上。矛盾的是，它们在基本功能方面也遇到了困难，比如算术或事实查找，在这些方面，更简单、更小的模型表现更好。 在本文中，R：我们展示了语言模型可以通过简单的api自学使用外部工具，并实现这两个世界的最佳效果。我们引入了Toolformer，这是一个经过训练的模型，用于决定调用哪些api、何时调用它们、传递哪些参数，以及如何最好地将结果合并到未来的令牌预测中。这是以一种自我监督的方式完成的，对每个API只需要少量的演示。我们整合了一系列工具，包括计算器、问答系统、搜索引擎、翻译系统和日历。在不牺牲其核心语言建模能力的情况下，Toolformer在各种下游任务中实现了显著改进的zero-shot性能，通常与更大的模型竞争。

1 Introduction

大型语言模型在各种自然语言处理任务上实现了令人印象深刻的zero-shot和few-shot的结果(Brown等人，2020;Chowdhery等人，2022年，即)，并展示了几种应急能力(Wei等人，2022年)。然而，所有这些模型都有一些固有的限制，这些限制最多只能通过进一步扩展来部分解决。这些限制包括无法获取最近事件的最新信息(Komeili等人，2022年)以及相关的幻觉事实倾向(Maynez等人，2020年;Ji等人，2022)、理解低资源语言的困难(Lin等人，2021)、执行精确计算的数学技能的缺乏(Patel等人，2021)以及对时间进程的不了解(dhinggra等人，2022)。

要克服当今语言模型的这些限制，一个简单的方法就是让它们能够使用外部工具，比如搜索引擎、计算器或日历。然而，现有的方法要么依赖于大量的人工注释(Komeili等人，2022年;Thoppilan等人，2022年)或将工具的使用限制为仅针对特定任务的设置(例如，Gao等人，2022年;Parisi等人，2022)，阻碍了在lm中更广泛地采用工具使用。因此，我们提出了Toolformer，一个以一种新的方式学习使用工具的模型，它满足以下要求：

• 应该以一种自我监督的方式学习工具的使用，而不需要大量的人工注释。这一点很重要，不仅因为与此类注释相关的成本，还因为人类认为有用的东西可能与模型认为有用的东西不同。
• LM不应该失去任何一般性，并且应该能够自己决定何时以及如何使用哪个工具。与现有的方法相比，这可以更全面地使用不绑定到特定任务的工具。

我们实现这些目标的方法是基于最近的想法，即使用大型lm与上下文学习(Brown et al.， 2020)从头生成整个数据集(Schick和Schütze, 2021b;Honovich等人，2022年;Wang et al.， 2022):给出了几个关于如何使用API的人类编写的例子，我们让LM注释一个具有潜在API调用的巨大语言建模数据集。然后，我们使用一个自我监督的损失来确定这些API调用中哪些实际上有助于模型预测未来的令牌。最后，我们对LM本身认为有用的API调用进行微调。如图1所示，通过这种简单的方法，lm可以学会控制各种工具，并为自己选择何时以及如何使用哪种工具。

图1：Toolformer的典型预测。该模型自动决定调用不同的api(从上到下:一个问答系统、一个计算器、一个机器翻译系统和一个维基百科搜索引擎)，以获得对完成一段文本有用的信息。

由于我们的方法与所使用的数据集无关，所以我们可以将其应用于最初用于预训练模型的相同数据集。这确保了模型不会失去任何通用性和语言建模能力。我们对各种不同的下游任务进行了实验，证明在学习使用工具后，基于预训练的GPT-J模型(Wang和Komatsuzaki, 2021)的参数为67 b的Toolformer可以获得更强的zero-shot结果，明显优于更大的GPT-3模型(Brown等人，2020)和其他几个不同任务的基线。

2 Approach

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

我们将每个API调用表示为一个元组c = (ac, ic)，其中ac是API的名称，ic是相应的输入。给定API调用c，其结果r对应，我们分别表示不包含结果和包含结果的API调用的线性化序列为：

其中" "， " "和"→"是特殊的标记。¹ 一些线性化的API调用插入到文本序列的例子如图1所示。
1注：在实践中，我们使用标记序列"["，"]“和” -> “分别表示” "， " “和"→”。这使得我们的方法可以在不修改现有LM词汇表的情况下工作。出于可读性的考虑，在本节中，我们仍然将它们称为“”、“”和“→”。

给定一个数据集C = {x1，…， x|C|}的纯文本，我们首先将该数据集转换为使用API调用进行扩充的数据集C∗。这分三个步骤完成，如图2所示:首先，我们利用M的上下文学习能力对大量潜在的API调用进行采样。然后我们执行这些API调用，最后检查获得的响应是否有助于预测未来的令牌;这被用作过滤条件。在过滤之后，我们合并不同工具的API调用，从而在这个数据集上生成增强的数据集C∗和finetun M本身。下面将更详细地描述每一个步骤。

图2：给定一个输入文本x，我们首先对位置i和相应的API调用候选c1 i, c2 i，…， ck I。然后我们执行这些API调用，过滤掉所有不会减少Li在下一个令牌损失的调用。所有剩余的API调用都与原始文本交错，产生一个新的文本x∗。

抽样API调用 对于每个API，我们写一个提示符P(x)，鼓励LM注释一个例子x = x1，…， xn与API调用。图3显示了这样一个问题回答工具的提示示例;所有使用的提示如附录A.2所示。设pM(zn+1 | z1，…。， zn)是M赋给令牌zn+1作为序列z1的延续的概率，…， zn。我们首先通过计算，对每个i∈{1，…， n}，表示概率

给定一个采样阈值τs，则保留所有位置i = {i | pi > τs};如果有超过k个这样的位置，我们只保留顶部的k个。

对于每个位置i∈i，我们可以得到最多m个API调用c1 i，…， cm i由给定序列[P(x)， x1，…， xi−1，]作为前缀，作为序列结束令牌。

图3:用于为回答问题的工具生成API调用的示例提示P(x)

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

过滤API调用 设i是API调用ci在序列x = x1中的位置，…， xn, ri是API的响应。进一步，给定一个权值序列(wi | i∈N)，令

是M在符号xi上的加权交叉熵损失，…如果模型以z为前缀，则为xn。我们比较了这一损失的两个不同实例:

其中，ε表示空序列。前者是所有代币xi的加权损失，…3后者是(i)完全不调用API和(ii)进行API调用但不提供响应所获得的损失的最小值。直观地说，如果向M提供此调用的输入和输出，使模型更容易预测未来的令牌，那么API调用对M是有帮助的，这与完全不接收API调用或只接收其输入相比。给定一个过滤阈值τf，因此我们只保留对其的API调用

持有，即，增加API调用和它的结果减少损失至少τf，相比不做任何API调用或从它没有得到任何结果。

模型微调 在对所有API的调用进行采样和过滤之后，我们最终合并了剩余的API调用，并将它们与原始输入交叉使用。也就是说，对于输入文本x = x1，…， xn和相应的API调用并在位置i处得到结果(ci, ri)，我们构造新的序列x∗= x1:i−1,e(ci, ri)， xi:n;我们类似地处理具有多个API调用的文本。对所有x∈C这样做会导致新的数据集C∗增加了API调用。我们使用这个新的数据集来微调M，使用一个标准语言建模目标。至关重要的是，除了插入的API调用外，增强的数据集C∗包含与原始数据集C完全相同的文本。因此，在C上对M进行微调将其暴露在与在C上进行微调相同的内容中。此外，由于API调用恰好插入到那些位置，并与那些帮助M预测未来标记的输入一起，因此在C∗上进行微调使语言模型能够纯粹基于自己的反馈，决定何时以及如何使用哪个工具。

注：2我们放弃所有M不生成令牌的例子。
3我们提供e(ci, ri)作为前缀，而不是将其插入到i位置，因为M在任何包含API调用的示例上还没有进行微调，所以将其插入到x的中间会中断流，并且与预训练语料库中的模式不对齐，从而减少困惑。

当用我们的方法微调后用M生成文本时，我们执行常规解码，直到M生成“→”令牌，这表明它接下来期望API调用的响应。此时，我们中断解码过程，调用适当的API以获得响应，并在插入响应和令牌之后继续解码过程。

3 Tools

我们探索了各种各样的工具来解决常规lm的不同缺点。我们对这些工具施加的唯一限制是(i)它们的输入和输出都可以表示为文本序列，(ii)我们可以获得它们预期用途的一些演示。具体来说，我们将探索以下五个工具:一个问答系统，一个维基百科搜索引擎，一个计算器，一个日历，和一个机器翻译系统。与这些工具相关联的api的一些潜在调用和返回字符串示例如表1所示。我们将在下面简要讨论所有工具;详情见附录A。

问题回答 我们的第一个工具是一个基于另一个LM的问答系统，它可以回答简单的事实问题。具体来说，我们使用了Atlas (Izacard等人，2022年)，这是一种检索增强的LM，对自然问题进行了微调(Kwiatkowski等人，2019年)。

计算器 作为第二个工具，我们使用一个可以执行简单数值计算的计算器;我们只支持四种基本的算术运算。结果总是四舍五入到小数点后两位。

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

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

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

4 Experiments

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

4.1 Experimental Setup

数据生成 在我们所有的实验中，我们使用CCNet的一个子集(Wenzek等人，2020年)作为我们的语言建模数据集C，使用GPTJ (Wang和Komatsuzaki, 2021年)作为我们的语言模型m。为了减少用API调用标注C的计算成本，我们为一些API定义启发法，以获得一个API调用比一般文本更有帮助的C子集。例如，我们只考虑计算器工具中包含至少三个数字的文本。附录a中给出了使用的启发法的细节。为了从C获取C∗，我们执行第2节中描述的所有步骤，另外过滤掉所有在过滤步骤中删除了所有API调用的示例。4对于加权函数，我们使用

确保API调用发生在API提供的信息对模型实际有用的地方。每个工具分别选择τs和τf的阈值，以确保样本数量足够多;详见附录A。表2显示了我们最终的API调用扩充后的数据集的相关统计信息。

模型微调 我们使用128个批量和1·10−5的学习速率在前10%的训练中进行线性热身，在C上对M进行微调。我们的微调程序的细节在附录B中给出。

基线模型 在本节的其余部分中，我们主要比较以下模型：

• GPT-J:没有任何微调的普通GPT-J模型
• GPT-J + CC: GPT-J在C上微调过，我们的CCNet子集没有任何API调用。
• 工具生成:GPT-J在C∗上微调过，这是我们用API调用扩充的CCNet子集。
• Toolformer(禁用):与Toolformer模型相同，但在解码过程中禁用API调用

对于大多数任务，我们还比较了OPT (66B) (Zhang et al.， 2022)和GPT-36 (175B) (Brown et al.， 2020)，这两个模型分别比我们的其他基线模型大10倍和25倍。

4.2 Downstream Tasks

我们在各种下游任务上评估所有模型。在所有情况下，我们考虑一个提示的零射击设置-即，模型被指示以自然语言解决每个任务，但我们没有提供任何上下文示例。这与之前关于工具使用的研究形成对比(例如，Gao等人，2022年;Parisi等人，2022)，其中模型提供了数据集特定的例子，说明如何使用工具解决具体任务。我们选择更具挑战性的零射击设置，因为我们感兴趣的是，在用户没有预先指定应该以何种方式使用哪些工具来解决特定问题的情况下，Toolformer是否能够准确地工作。

我们使用标准的贪婪解码，但对Toolformer有一个修改:我们让模型不仅在是最有可能的令牌时启动API调用，而且在它是k个最有可能的令牌之一时启动API调用。对于k = 1，这对应于常规的贪婪解码;相反，我们使用k = 10来增加模型的配置，以利用它可以访问的api。与此同时，我们最多只能对每个输入调用一个API，以确保模型不会陷入循环，即不断调用API而不产生任何实际输出。这些修改的影响将在第5节中讨论。

4.2.1 LAMA

我们在LAMA基准的SQuAD、GoogleRE和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)，尽管这两种型号都要大得多。之所以能够做到这一点，是因为在几乎所有情况下，模型都独立地决定向问题回答工具询问所需的信息(98.1%);只有很少几个例子使用了不同的工具(0.7%)或根本没有工具(1.2%)。

4.2.2 Math Datasets

我们在ASDiv (Miao et al.， 2020)、SVAMP (Patel et al.， 2021)和MAWPS基准(Koncel-Kedziorski et al.， 2016)上测试数学推理能力。我们再次解释了这样一个事实，即我们通过使用一个更宽松的评估标准在零镜头设置中测试所有模型:由于所需的输出总是一个数字，我们只需检查模型预测的第一个数字

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

4.2.3 Question Answering

我们研究了Web问题(Berant et al.， 2013)、自然问题(Kwiatkowski et al.， 2019)和TriviaQA (Joshi et al.， 2017)， Brown et al.(2020)考虑的三个问题回答数据集。为了进行评估，我们检查模型预测的前20个单词是否包含正确的答案，而不是要求精确匹配。对于Toolformer，我们禁用了问题回答工具，因为这将使解决任务变得琐碎，特别是考虑到底层的QA系统已经在Natural Questions上进行了微调。

结果如表5所示。再一次，Toolformer明显优于所有其他基于GPT-J的模型，这一次主要依靠Wikipedia搜索API(99.3%)来查找相关信息。然而，Toolformer仍然落后于更大的GPT-3 (175B)模型。这可能是由于我们的搜索引擎的简单性(在许多情况下，它返回的结果显然与给定的查询不匹配)和Toolformer无法与之交互的原因，例如，如果结果没有帮助，则通过重新构造查询或通过浏览多个最热门的结果。我们相信添加这个功能是未来工作的一个令人兴奋的方向。

4.2.4 Multilingual Question Answering

我们在MLQA上评估Toolformer和所有基线模型(Lewis等人，2019年)，这是一个多语言问答基准。每个问题的上下文段落以英语提供，而问题可以是阿拉伯语，德语，西班牙语，印度语，越南语，或简体中文。为了解决该任务，该模型需要同时理解段落和问题，因此将问题翻译成英语可能会对模型有好处。我们的评估指标是模型生成的次数的百分比，上限为10个单词，包含正确的答案。

结果如表6所示。使用API调用不断地提高了Toolformer对所有语言的性能，这表明它已经学会了使用机器翻译工具。根据不同的语言，所有示例中63.8%到94.9%都使用了这个工具;唯一的例外是印地语，只有7.3%的情况下使用机器翻译工具。然而，Tool former并不总是优于普通的GPT-J。这主要是因为对于某些语言，CCNet上的微调会降低性能;这可能是由于与GPT-J的原始训练前数据相比，分布发生了变化。

OPT和GPT-3在所有语言中都表现得非常弱，这主要是因为它们不能用英语提供答案，尽管被要求这样做。GPT-J没有遇到这个问题的一个潜在原因是，它比OPT和GPT-3都训练了更多的多语言数据，包括EuroParl语料库(Koehn, 2005;高等人，2020)。作为上界，我们还在MLQA的一个变体上评估GPT-J和GPT-3，其中上下文和问题都是用英语提供的。在这个设置中，GPT-3的性能优于所有其他模型，这支持了我们的假设，即它在MLQA上的低水平性能是由于任务的多语言方面造成的。

4.2.5时态数据集

为了研究日历API的实用程序，我们评估TEMPLAMA (dhinggra等人，2022)上的所有模型和一个我们称为DATESET的新数据集。TEMPLAMA是一个从Wikidata构建的数据集，包含关于随着时间变化的事实(例如，“c罗为___踢球”)的完形填空查询，以及2010年到2020年的正确答案。附录D中描述的DATESET也通过一系列模板生成，但是使用随机日期/持续时间的组合来填充(例如，“30天前是星期几?”)。关键的是，要回答这些问题，就必须知道当前的日期。对于这两个任务，我们使用与原始LAMA数据集相同的评估。

表7中显示的结果说明Toolformer优于TEMPLAMA和DATESET的所有基线。然而，更仔细的观察表明，TEMPLAMA的改进不能归功于日历工具，它只在所有示例中使用了0.2%，但主要归功于维基百科搜索和问题回答工具，这是Toolformer调用最多的工具。这是有道理的，因为TEMPLAMA中的命名实体通常是非常具体和罕见的，即使知道确切的日期也没什么帮助。对于这个数据集，最好的操作方法是——首先查询日历API以获得当前日期，然后用该日期查询问答系统——这不仅受到每个示例最多使用一个API调用的限制，而且由于Toolformer的训练数据中的所有API调用都是独立采样的，因此很难学习。

另一方面，对于DATESET来说，与其他模型相比，Toolformer的显著改进可以完全体现在日历工具上，它使用了54.8%的示例。

4.3 Language Modeling

除了在各种下游任务上验证改进的性能之外，我们还希望确保Toolformer的语言建模性能不会因为我们对API调用进行微调而降低。为此，我们在两个语言建模数据集上评估我们的模型:WikiText (Merity et al.， 2017)和一个从CCNet随机选择的10,000个文档子集(Wenzek et al.， 2020)，这些文档在训练过程中没有使用。各模型的困惑如表8所示。正如人们所预料的那样，CCNet上的微调会略微提高不同CCNet子集上的性能，但它会略微降低WikiText上的性能，这大概是因为GPT-J的原始训练前数据比我们随机选择的CCNet子集更类似于WikiText。然而，最重要的是，当API调用在推理时被禁用时，使用C∗(我们的带有API调用注释的数据集)进行训练与使用C进行训练相比，不会导致困惑的增加

4.4 Scaling Laws

我们研究了当我们改变LM的大小时，向外部工具寻求帮助的能力如何影响性能。为此，我们不仅将我们的方法应用于GPT-J模型，而且还应用于GPT-2家族的四个较小的模型(Radford et al.， 2019)，它们分别具有124M、355M、775M和1.6B参数。我们只使用三个工具的一个子集:问答系统、计算器和维基百科搜索引擎。除此之外，我们遵循第4.1节中描述的实验设置。

图4显示，只有在大约775M参数时，才能够利用所提供的工具:使用和不使用工具时，较小的模型都能实现类似的性能。一个例外是Wikipedia搜索引擎主要用于QA基准测试;我们假设这是因为API比较容易使用。随着模型规模的增长，它们在解决没有API调用的任务时变得更好，同时它们充分利用所提供的API的能力也得到了提高。因此，即使对于我们最大的模型，有API调用和没有API调用的预测之间仍然存在很大的差距。

5 Analysis

我们研究了4.2节中引入的修改后的解码策略的效果，在这里，我们不是总是生成最可能的令牌，而是生成令牌，如果它是k个最可能的令牌之一。表9显示了不同k值在LAMA的T-REx子集和WebQS上的性能。正如预期的那样，k值的增加会导致模型进行更多的API调用——从k = 1时的40.3%和8.5%(即常规贪婪解码)到k = 10时的98.1%和100%。而对于T-REx来说，贪婪解码已经在性能上有了明显的改善，而在WebQS上，当我们稍微增加k时，我们的模型才开始进行大量的API调用。有趣的是，当k = 1时，模型在一定程度上进行了校准:它决定在不调用API的情况下调用那些性能特别差的例子。这可以从一个例子中看出，当它决定不进行API调用(44.3和19.9)时的性能要高于完全不进行API调用(34.9和18.9)时的平均性能。然而，当k值较高时，这种校正就会丢失。

我们定性地分析了用我们的方法为不同的API生成的一些API调用。表10显示了一些来自CCNet的带有API调用的文本示例，以及相应的L - i - L+ i得分(用作过滤标准)，以及模型所做的API调用在给定上下文中是否直观有用。可以看到，L - i - L+ i的高值通常对应有用的API调用，而低值对应的API调用不提供任何有用的信息，以预测未来的令牌。也有一些例外，例如，第四个例子中对“Fast train success”的API调用没有提供任何相关信息，但仍然减少了困惑。然而，API调用中一些没有过滤的噪声实际上是有用的，因为它迫使在C∗上进行微调的模型不总是盲目地遵循它所做的每个调用的结果。

6 Related Work

…

7 Limitations

虽然我们的方法使lm能够以一种自我监督的方式学习如何使用各种工具，但是在以当前形式使用我们的方法可以实现什么方面有一些明显的限制。其中一个限制是Toolformer不能使用链中的工具(例如，使用一个工具的输出作为另一个工具的输入)。这是因为每个工具的API调用都是独立生成的;因此，在细调数据集中没有使用链式工具的例子。我们目前的方法也不允许LM以交互的方式使用工具，特别是对于搜索引擎这样的工具，这些工具可能会返回数百个不同的结果，使LM能够浏览这些结果，或者像Nakano等人(2021)那样改进其搜索查询。对于某些应用程序来说，这是至关重要的。除此之外，我们发现使用Toolformer训练的模型在决定是否调用API时，往往对输入的准确措辞很敏感;这也许并不令人惊讶，因为lm被认为在零镜头和少镜头设置中都对提示非常敏感(Jiang等人，2020;Schick和Schütze, 2021a)。根据工具的不同，我们的方法也是非常低效的;例如，处理100多万个文档只会产生几千个对计算器API有用的调用示例。这个问题的一个潜在解决方案可能是迭代地应用我们的方法，类似于相关的引导方法(Schick和Schütze, 2021a;伊扎卡和格雷夫，2021年;Parisi等人，2022年)。最后，在决定是否进行API调用时，Toolformer目前没有考虑进行API调用所产生的依赖于工具的计算成本。

8 Conclusion

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