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

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調用的開始和結束。

，其中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）

對于每個位置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調用的文本，我們以類似的方式進行。對于所有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

模型微調

對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模型。