Toolformer: Language Models Can Teach Themselves to Use Tools
https://arxiv.org/abs/2302.04761

Abstract

語言模型（LM）表現(xiàn)出驚人的能力，可以僅憑幾個示例或文本說明解決新任務(wù)，尤其是在規(guī)模方面。然而，它們在基本功能方面卻表現(xiàn)出矛盾，例如算術(shù)或事實查找，在這些問題上功能更簡單、更小的模型反而表現(xiàn)更出色。在本文中，我們展示了LM可以通過簡單的API自學(xué)使用外部工具，并實現(xiàn)最佳效果。我們介紹了Toolformer，這是一個模型，它通過訓(xùn)練來決定調(diào)用哪些API、何時調(diào)用它們、傳遞什么參數(shù)以及如何最好地將結(jié)果合并到未來的token預(yù)測中。這是以自監(jiān)督的方式完成的，每個API僅需要少量演示即可。我們整合了一系列工具，包括計算器、問答系統(tǒng)、搜索引擎、翻譯系統(tǒng)和日歷。Toolformer在各種下游任務(wù)中實現(xiàn)了顯著改進的零-shot性能，通?？梢耘c更大的模型競爭，而不會犧牲其核心語言建模能力。

1. 引言

大型語言模型在各種自然語言處理任務(wù)上取得了令人印象深刻的零-shot和少-shot結(jié)果（Brown等，2020; Chowdhery等，2022，等），并展示了幾個新興的能力（Wei等，2022）。然而，所有這些模型都有幾個固有的限制，最多只能通過進一步擴展來部分地解決這些限制。這些限制包括無法訪問有關(guān)最近事件的最新信息（Komeili等，2022）以及相關(guān)的虛構(gòu)事實的傾向（Maynez等，2020; Ji等，2022），難以理解低資源語言（Lin等，2021），缺乏進行精確計算的數(shù)學(xué)技能（Patel等，2021）以及對時間進展的無意識（Dhingra等，2022）。
克服當(dāng)今語言模型的這些限制的簡單方法是賦予它們使用外部工具的能力，例如搜索引擎、計算器或日歷。然而，現(xiàn)有的方法要么依賴大量的人工注釋（Komeili等人，2022；Thoppilan等人，2022），要么僅將工具使用限制在特定任務(wù)設(shè)置中（例如，Gao等人，2022；Parisi等人，2022），這阻礙了工具在語言模型中更廣泛的應(yīng)用。因此，我們提出了 Toolformer，這是一種以新穎的方式學(xué)習(xí)使用工具的模型，它滿足以下期望：
? 工具的使用應(yīng)該以自我監(jiān)督的方式學(xué)習(xí)，而不需要大量的人工注釋。這是重要的，不僅因為這種標(biāo)注的成本，而且因為人類發(fā)現(xiàn)有用的東西可能與模型發(fā)現(xiàn)有用的東西不同。
? 語言模型不應(yīng)失去其普適性，應(yīng)能夠自行決定何時以及如何使用哪個工具。與現(xiàn)有方法相比，這使得可以更全面地使用工具，而不是與特定任務(wù)相關(guān)聯(lián)。

我們實現(xiàn)這些目標(biāo)的方法基于最近提出的使用具有上下文學(xué)習(xí)（Brown等人，2020）的大型語言模型來從頭生成整個數(shù)據(jù)集（Schick和Schütze，2021b; Honovich等人，2022; Wang等人，2022）的想法：只需幾個人類編寫的示例，說明API如何使用，我們就可以讓語言模型注釋具有潛在API調(diào)用的大量語言建模數(shù)據(jù)集。然后，我們使用自我監(jiān)督的損失來確定哪些API調(diào)用實際上有助于模型預(yù)測未來的 tokens。最后，我們在語言模型自己認(rèn)為有用的API調(diào)用上進行微調(diào)。如圖1所示，通過這種簡單的方法，語言模型可以學(xué)習(xí)控制各種工具，并自行選擇何時以及如何使用哪個工具。

圖1：Toolformer的示例預(yù)測。該模型自主決定調(diào)用不同的API（從上到下：問答系統(tǒng)、計算器、機器翻譯系統(tǒng)和維基百科搜索引擎），以獲取完成一段文本所需的有用信息

我們的方法并不依賴于使用的數(shù)據(jù)集，因此我們可以將其應(yīng)用于首次預(yù)訓(xùn)練模型所使用的完全相同的數(shù)據(jù)集。這確保了模型不會失去其一般性和語言建模能力。我們在各種不同的下游任務(wù)上進行了實驗，證明了在學(xué)習(xí)使用工具之后，基于預(yù)訓(xùn)練的GPT-J模型（Wang和Komat- suzaki，2021），該模型具有67億個參數(shù)的Toolformer，實現(xiàn)了更強的零-shot結(jié)果，在各種任務(wù)上明顯優(yōu)于更大的GPT-3模型（Brown等，2020）和其他幾個基線模型。

2. 方法

我們的目標(biāo)是讓一個語言模型M通過API調(diào)用獲得使用不同工具的能力。我們要求每個API的輸入和輸出都可以表示為文本序列。這允許使用特殊token將API調(diào)用無縫插入到任何給定的文本中，標(biāo)記每個API調(diào)用的開始和結(jié)束。

，其中ac是API的名稱，ic是對應(yīng)的輸入。給定一個帶有相應(yīng)結(jié)果r的API調(diào)用c，我們將不包括其結(jié)果和包括其結(jié)果的API調(diào)用的線性序列分別表示為：

image.png

其中，“<API>”，“</API>”和“→”是特殊token。圖1展示了插入文本序列中的線性API調(diào)用的一些示例。

實際上，我們使用token序列“ [”，“]”和“->”來表示“<API>”，“</API>”和“→”，以便我們的方法在不修改現(xiàn)有LM詞匯的情況下工作。出于可讀性的原因，我們?nèi)匀辉诒竟?jié)中將其稱為“<API>”，“</API>”和“→”。

，我們首先將該數(shù)據(jù)集轉(zhuǎn)換為一個帶有API調(diào)用的增強數(shù)據(jù)集C*。這是通過三個步驟完成的，如圖2所示：首先，利用M的 in-context learning 能力，我們采樣了大量潛在的API調(diào)用。然后我們執(zhí)行這些API調(diào)用，最后檢查獲得的響應(yīng)是否有助于預(yù)測未來的token。這被用作過濾標(biāo)準(zhǔn)。經(jīng)過過濾，我們合并了不同工具的API調(diào)用，得到了增強的數(shù)據(jù)集C*，并在此數(shù)據(jù)集上微調(diào)M本身。下面將更詳細(xì)地描述每個步驟。

圖2：我們方法的關(guān)鍵步驟，以問答工具為例進行說明：給定一個輸入文本 x，我們首先采樣一個位置 i 和相應(yīng)的 API 調(diào)用候選項 c1 i，c2 i，......，ck i。然后我們執(zhí)行這些 API 調(diào)用并過濾掉不減小下一個token的損失 Li 的所有調(diào)用。所有剩余的 API 調(diào)用與原始文本交錯，生成一個新的文本 x?

Sampling API Calls

對于每個API，我們編寫一個提示P(x)，鼓勵LM使用API調(diào)用注釋一個示例x = x1，...，xn。圖3是問題回答工具的一個提示示例；所有使用的提示都在附錄A.2中。

圖3：用于生成問題回答工具API調(diào)用的示例提示P（x）

對于每個位置i ∈ I，我們從M中獲得最多m個API調(diào)用c1i，...，cmi，通過以序列[P (x)，x1，...，xi?1，<API>]作為前綴，并將</API>作為序列結(jié)束 token 來從M中進行抽樣。

我們舍棄所有M沒有生成</API> token的示例。

Executing API Calls

作為下一步，我們執(zhí)行由M生成的所有API調(diào)用以獲取相應(yīng)的結(jié)果。如何執(zhí)行取決于API本身-例如，它可以涉及調(diào)用另一個神經(jīng)網(wǎng)絡(luò)，執(zhí)行Python腳本或使用檢索系統(tǒng)在大型語料庫上執(zhí)行搜索。每個API調(diào)用ci的響應(yīng)需要是單個文本序列ri。

Filtering API Calls

假設(shè)API調(diào)用ci在序列x = x1，…，xn中的位置為i，ri是API的響應(yīng)。此外，給定一個權(quán)重序列(wi | i ∈ N)，讓

image.png

成為如果在模型的前綴中加入z，則M在標(biāo)記xi，...，xn上的加權(quán)交叉熵?fù)p失。我們比較兩種不同的損失函數(shù)實例化：

image.png

其中ε表示空序列。如果將API調(diào)用及其結(jié)果作為前綴提供給M，則前者是對所有標(biāo)記xi, . . . , xn的加權(quán)損失。

我們提供e(ci, ri)作為前綴，而不是插入到位置i，因為M尚未對包含API調(diào)用的任何示例進行微調(diào)，因此將其插入到x的中間會中斷流程，并且不與預(yù)訓(xùn)練語料庫中的模式對齊，從而損害困惑度。

后者是在（i）根本不進行API調(diào)用和（ii）進行API調(diào)用但不提供響應(yīng)的情況下獲得的損失的最小值。直觀地說，如果將API調(diào)用及其輸入和輸出提供給M，使得模型預(yù)測未來標(biāo)記變得更容易，與根本不接收API調(diào)用或僅接收其輸入相比，API調(diào)用對于M是有幫助的。因此，給定篩選閾值τf，我們僅保留以下條件成立的API調(diào)用：

image.png

也就是說，添加API調(diào)用及其結(jié)果相對于不進行任何API調(diào)用或不從中獲得任何結(jié)果，可以將損失降低至少τf。

Model Finetuning

；對于具有多個API調(diào)用的文本，我們以類似的方式進行。對于所有x∈C這樣做會得到新數(shù)據(jù)集C?，其中包含了增強的API調(diào)用。我們使用這個新數(shù)據(jù)集來微調(diào)M，使用標(biāo)準(zhǔn)的語言建模目標(biāo)。重要的是，除了插入的API調(diào)用之外，增強的數(shù)據(jù)集C?與原始數(shù)據(jù)集C完全相同。因此，在C?上微調(diào)M會使其接觸到與在C上微調(diào)相同的內(nèi)容。此外，由于API調(diào)用恰好插入那些位置并帶有恰好那些輸入，這些位置和輸入有助于M預(yù)測未來的 token，因此在C?上微調(diào)使得語言模型可以純粹基于自身的反饋來決定何時以及如何使用哪種工具。

Inference

在使用我們的方法微調(diào)M后生成文本時，我們執(zhí)行常規(guī)解碼，直到M生成“→”標(biāo)記，表示它接下來期望API調(diào)用的響應(yīng)。此時，我們中斷解碼過程，調(diào)用適當(dāng)?shù)腁PI以獲取響應(yīng)，并在插入響應(yīng)和</API>標(biāo)記后繼續(xù)解碼過程。

3. Tools

我們探索了各種工具來解決常規(guī)語言模型的不足之處。我們對這些工具唯一的限制是它們的輸入和輸出都可以表示為文本序列，并且我們可以獲得它們預(yù)期使用的一些演示。具體而言，我們探索了以下五個工具：問答系統(tǒng)、維基百科搜索引擎、計算器、日歷和機器翻譯系統(tǒng)。每個工具相關(guān)的API的潛在調(diào)用和返回字符串的一些示例顯示在表1中。

我們在下面簡要討論所有工具；更多細(xì)節(jié)可以在附錄A中找到。

問答系統(tǒng)

我們的第一個工具是一個基于另一個語言模型的問答系統(tǒng)，可以回答簡單的事實問題。具體而言，我們使用Atlas（Izacard等人，2022），這是一個在自然問題（Kwiatkowski等人，2019）上微調(diào)的檢索增強語言模型。

Calculator

作為第二個工具，我們使用一個計算器，可以執(zhí)行簡單的數(shù)字計算；我們僅支持四種基本算術(shù)運算。結(jié)果始終舍入到小數(shù)點后兩位。

Wikipedia Search

我們的第三個工具是一個搜索引擎，給定一個搜索詞，它可以從維基百科返回簡短的文本片段。與我們的問答工具相比，這種搜索使模型能夠獲取更全面的關(guān)于某個主題的信息，但需要它自己提取相關(guān)部分。我們使用BM25檢索器（Robertson等人，1995; Baeza-Yates等人，1999）作為我們的搜索引擎，它從KILT（Petroni等人，2021）索引維基百科轉(zhuǎn)儲。

Machine Translation System

機器翻譯系統(tǒng)是我們的第四個工具，基于一個語言模型，可以將任何語言的短語翻譯成英語。更具體地說，我們使用了600M參數(shù)的NLLB（Costa-jussà等人，2022）作為我們的多語言機器翻譯模型，可以適用于200種語言（包括低資源語言）。使用fastText分類器（Joulin等人，2016）自動檢測源語言，而目標(biāo)語言始終設(shè)置為英語。

Calendar

我們的最后一個工具是一個日歷API，當(dāng)查詢時，返回當(dāng)前日期而不需要任何輸入。這為需要時間意識的預(yù)測提供了時間上下文。

4. Experiments

我們研究了我們的方法是否使模型能夠在沒有進一步監(jiān)督的情況下使用工具，并決定何時以及如何調(diào)用可用的工具。為了測試這一點，我們選擇了各種下游任務(wù)，其中我們假設(shè)至少考慮到的一種工具是有用的，并在零樣本設(shè)置下評估性能（第4.2節(jié)）。除此之外，我們還確保我們的方法不會損害模型的核心語言建模能力；我們通過查看兩個語言建模數(shù)據(jù)集上的困惑度來驗證這一點（第4.3節(jié)）。最后，我們研究了模型大小如何影響使用工具學(xué)習(xí)的能力（第4.4節(jié)）。

4.1 實驗設(shè)置

數(shù)據(jù)集生成

在所有實驗中，我們使用CCNet (Wenzek et al.，2020)的一個子集作為我們的語言建模數(shù)據(jù)集C，使用GPT-J (Wang and Komatsuzaki, 2021)作為我們的語言模型M。為了降低用API調(diào)用注釋C的計算成本，我們?yōu)橐恍〢PI定義了啟發(fā)式方法，以獲取一個子集C，其中API調(diào)用比平均文本更有幫助。例如，如果文本包含至少三個數(shù)字，我們僅考慮計算器工具的文本。使用的啟發(fā)式方法的詳細(xì)信息在附錄A中給出。為了從C獲取C?，我們執(zhí)行第2節(jié)中描述的所有步驟，并在過濾步驟中過濾掉所有API調(diào)用被消除的示例。至于權(quán)重函數(shù)，我們使用

image.png

以確保API調(diào)用發(fā)生在“API提供的信息對模型有幫助”的地方附近。閾值τs和τf針對每個工具單獨選擇，以確保具有足夠的示例數(shù)。有關(guān)詳細(xì)信息，請參見附錄A。表2顯示了我們最終數(shù)據(jù)集的相關(guān)統(tǒng)計信息，其中包括API調(diào)用。

image.png

模型微調(diào)

對M在C?上進行微調(diào)，其中前10%的訓(xùn)練進行線性預(yù)熱。我們的微調(diào)過程的詳細(xì)信息在附錄B中給出。

基準(zhǔn)模型

在本節(jié)的剩余部分，我們主要比較以下模型：
? GPT-J：沒有任何微調(diào)的常規(guī)GPT-J模型。
? GPT-J + CC：對C進行微調(diào)的GPT-J，我們的CCNet子集，沒有任何API調(diào)用。
? Toolformer：在C?上進行微調(diào)的GPT-J，我們的CCNet子集，增加了API調(diào)用。
? Toolformer（禁用）：與Toolformer相同的模型，但在解碼期間禁用API調(diào)用。
對于大多數(shù)任務(wù)，我們還將其與OPT (66B) (Zhang et al.，2022)和GPT-36 (175B) (Brown et al.，2020)進行比較，這兩個模型的大小分別比我們其他基準(zhǔn)模型大約10倍和25倍。

4.2 下游任務(wù)

我們在各種下游任務(wù)上評估所有模型。在所有情況下，我們考慮提示的零樣本設(shè)置——即，模型被指示用自然語言解決每個任務(wù)，但我們不提供任何上下文示例。這與以前有關(guān)工具使用的研究不同（例如，Gao等人，2022年；Parisi等人，2022年），在這些研究中，模型提供了特定于數(shù)據(jù)集的示例，說明如何使用工具來解決具體任務(wù)。我們選擇更具挑戰(zhàn)性的零樣本設(shè)置，因為我們有興趣看到Toolformer是否能夠在用戶沒有事先指定哪些工具應(yīng)該如何使用來解決特定問題的情況下正常工作。
我們使用標(biāo)準(zhǔn)的貪婪解碼，但對于Toolformer，我們進行了一項修改：我們不僅讓模型在 <API> 是最可能的標(biāo)記時開始進行 API 調(diào)用，而且每當(dāng)它是最可能的 k 個標(biāo)記之一時都進行 API 調(diào)用。對于 k = 1，這相當(dāng)于常規(guī)的貪婪解碼；我們使用 k = 10 來增加我們的模型使用其可以訪問的 API 的傾向。同時，我們最多只對每個輸入進行一次 API 調(diào)用，以確保模型不會陷入一個循環(huán)中，不斷調(diào)用 API 而不產(chǎn)生任何實際輸出。這些修改的效果在第5節(jié)中進行了探討。

4.2.1 LAMA

我們在LAMA基準(zhǔn)測試的SQuAD、Google-RE和T-REx子集上評估我們的模型（Petroni等人，2019）。對于每個子集，任務(wù)是用缺失的事實（例如日期或地點）完成一個簡短的陳述。由于LAMA最初是設(shè)計用于評估掩碼語言模型（例如Devlin等人，2019），因此我們過濾掉掩碼標(biāo)記不是最后一個標(biāo)記的示例，以便剩余的示例可以按從左到右的方式處理。為了考慮到不同的分詞和從不通知模型需要一個單詞的增加復(fù)雜性，我們使用比精確匹配略為寬松的評估標(biāo)準(zhǔn)，只檢查正確單詞是否在模型預(yù)測的前五個單詞中。由于LAMA基于直接從維基百科獲取的陳述，我們防止Toolformer使用維基百科搜索API，以避免給它帶來不公平的優(yōu)勢。
所有模型的結(jié)果都可以在表3中看到。

所有沒有使用工具的GPT-J模型表現(xiàn)相似。關(guān)鍵是，Toolformer明顯優(yōu)于這些基準(zhǔn)模型，在最佳基準(zhǔn)模型的基礎(chǔ)上分別提高11.7、5.2和18.6個點。盡管OPT（66B）和GPT-3（175B）都更大，但它們的表現(xiàn)仍然明顯不如Toolformer。這是因為在幾乎所有情況下（98.1%），該模型獨立決定向問題回答工具詢問所需信息；只有極少數(shù)情況下（0.7%），它使用不同的工具，或者根本不使用工具（1.2%）。

4.2.2 數(shù)學(xué)數(shù)據(jù)集

我們在ASDiv（Miao等人，2020）、SVAMP（Patel等人，2021）和MAWPS基準(zhǔn)測試（Koncel-Kedziorski等人，2016）上測試數(shù)學(xué)推理能力。我們再次考慮到我們以零-shot設(shè)置測試所有模型，通過使用更寬松的評估標(biāo)準(zhǔn)來考慮這一點：由于所需的輸出總是一個數(shù)字，因此我們只檢查模型預(yù)測的第一個數(shù)字。
表4顯示了所有基準(zhǔn)測試的結(jié)果。

盡管GPT-J和GPT-J + CC表現(xiàn)大致相同，但Toolformer在禁用API調(diào)用時仍然實現(xiàn)了更強的結(jié)果。我們推測這是因為該模型針對許多API調(diào)用和其結(jié)果進行了微調(diào)，提高了其自身的數(shù)學(xué)能力。盡管如此，允許模型進行API調(diào)用將所有任務(wù)的性能提高了一倍以上，而且明顯優(yōu)于更大的OPT和GPT-3模型。這是因為在所有基準(zhǔn)測試中，對于97.9%的所有示例，模型決定向計算器工具尋求幫助。

4.2.3 Question Answering

// TODO

5. Analysis

// TODO

6. Related Work

// TODO

7. 限制

雖然我們的方法使語言模型能夠自我學(xué)習(xí)如何使用各種工具，但目前的方法也存在一些明顯的限制。其中一個限制是Toolformer無法在工具之間進行鏈接（即使用一個工具的輸出作為另一個工具的輸入）。這是因為每個工具的API調(diào)用是獨立生成的；因此，在微調(diào)數(shù)據(jù)集中沒有鏈接工具使用的示例。我們當(dāng)前的方法也不允許語言模型以交互方式使用工具，特別是像搜索引擎這樣的工具，可能返回數(shù)百個不同的結(jié)果，使得語言模型可以瀏覽這些結(jié)果或者像中野等人（2021）那樣細(xì)化其搜索查詢，在某些應(yīng)用中這非常關(guān)鍵。除此之外，我們發(fā)現(xiàn)使用Toolformer訓(xùn)練的模型通常對其輸入的確切措辭非常敏感，這也許并不奇怪，因為已知在 zero-
and few-shot settings 中，LM對其提供的提示非常敏感（Jiang等人，2020；Schick和Schütze，2021a）。根據(jù)工具的不同，我們的方法也非常低效，例如，處理超過一百萬個文檔只能得到幾千個有用的計算器API調(diào)用的示例。解決這個問題的潛在方法可能是迭代應(yīng)用我們的方法，類似于相關(guān)的引導(dǎo)方法（Schick和Schütze，2021a；Izacard和Grave，2021；Parisi等人，2022）。最后，Toolformer在決定是否進行API調(diào)用時，目前不考慮由API調(diào)用產(chǎn)生的工具相關(guān)的計算成本。

8. 結(jié)論

我們介紹了Toolformer，一種語言模型，它通過簡單的API調(diào)用以自監(jiān)督的方式學(xué)習(xí)如何使用不同的工具，如搜索引擎、計算器和翻譯系統(tǒng)。這是通過微調(diào)大量樣本API調(diào)用來實現(xiàn)的，這些調(diào)用是基于它們是否減少未來 token 的困惑度進行過濾的。Toolformer顯著提高了一個6.7B參數(shù)的GPT-J模型的零-shot性能，使其能夠在不同的下游任務(wù)上甚至勝過一個更大的GPT-3模型。