英文名稱: ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs
中文名稱: TOOLLLM：幫助大語言模型掌握16000多個真實世界的API
文章: http://arxiv.org/abs/2307.16789
代碼: https://github.com/OpenBMB/ToolBench
作者: Yujia Qin
日期: 2023-07-31

1 讀后感

論文致力于讓大模型學(xué)習(xí)使用工具，以實現(xiàn)復(fù)雜的任務(wù)。目前使用工具能力最強的還是 ChatGPT，但不清楚它是如何實現(xiàn)的。文中提出的 ToolLLM 主要用于構(gòu)建針對 引導(dǎo)調(diào)優(yōu)（instruction-tuning）的訓(xùn)練數(shù)據(jù)集 ToolBench ，最終通過數(shù)據(jù)對開源的LLaMA調(diào)優(yōu)，訓(xùn)練的模型ToolLLaMA，對工具的使用能力與 ChatGPT 相當(dāng)。

為了使路徑搜索過程更加高效，提出了基于深度優(yōu)先搜索的決策樹（depth-first search-based decision tree：DFSDT）；訓(xùn)練了 API 檢索器來為每條指令推薦適當(dāng)?shù)?API。

最終發(fā)布了用于評價的工具 ToolEval，以及使用 ToolBench 調(diào)優(yōu)的模型 ToolLLaMA，可支持復(fù)雜的引導(dǎo)和沒見過的 API。優(yōu)化了通過大模型與調(diào)用 API 的協(xié)作，生成最終答案的功能。

2 介紹

對于大模型和工具協(xié)作問題，之前工具有以下的局限性：

• 使用有限的非真實或少量的 API 訓(xùn)練
• 受限的場景：只涉及單個工具，未考慮到工具交互關(guān)系
• 計劃和歸因效果差，只使用提示方式，難以處理復(fù)雜的指令
• 開源的大模型效果不好
  表-1對比了 ToolBench 和之前的數(shù)據(jù)集：

圖-1 展示了整體架構(gòu)設(shè)計，左側(cè)為訓(xùn)練，右側(cè)為推理（使用模型預(yù)測）。
在訓(xùn)練階段，首先從 RapidAPI 收集 API，然后利用ChatGPT，一方面生成引導(dǎo)數(shù)據(jù)，用于訓(xùn)練神經(jīng)網(wǎng)絡(luò)的 API Retriever（API 檢索器），另一方面實現(xiàn)路徑標(biāo)注，生成引導(dǎo)學(xué)習(xí)的數(shù)據(jù) ToolBench，將數(shù)據(jù)代入 LLaMA 精調(diào)模型生成 ToolLLaMA。
在推理階段，用戶輸入指令 Instruction，利用 API Retriever 檢索可能調(diào)用的 API，然后將這些 API 輸入ToolLLaMA模型，ToolLLaMA 執(zhí)行多輪 API 調(diào)用以得出最終答案，最后再由 ToolEval 對結(jié)果進行評價。

通過評測，得到以下結(jié)論：

• ToolLLaMA 具有處理單工具和復(fù)雜多工具指令的能力。它對以前未見過的 API 具有泛化能力，只需要 API 文檔即可有效地適應(yīng)新的 API。ToolLLaMA 在工具使用方面與 ChatGPT 性能相當(dāng)。
• DFSDT 方法考慮多條路徑，可作為增強 LLM 推理能力的通用決策策略。比 ReACT 性能更好。
• 訓(xùn)練 API 檢索器神經(jīng)網(wǎng)絡(luò)表現(xiàn)出卓越的檢索精度，返回的 API 與真實情況密切相關(guān)。

3 構(gòu)造數(shù)據(jù)

構(gòu)造 ToolBench 分為以下三個階段：

3.1 收集API

RapidAPI Hub 是一個 API 市場，提供數(shù)千個現(xiàn)實世界的 API，涵蓋 49 個不同的類別 categories，如體育、金融和天氣等；每個類別又含子類 collections，如中文API、人工智能API、數(shù)據(jù)庫API；總共上萬個API。對于每個API，收集其描述、所需參數(shù)、API調(diào)用的代碼片段等。訓(xùn)練 LLM 理解API與文本描述的關(guān)系，以便泛化到未見過的API。

在實現(xiàn)過程中需要對 API 進行篩選，丟棄無法實現(xiàn)功能及返回延時過長的 API，最終保留了 3451 個高質(zhì)量工具，共 16464 個 API。

另外，描述信息可能過長，包含一些冗余信息，這里使用 ChatGPT 對其進行精減，通過輸入為工具的文檔描述以及所需輸出格式的示例，以此將文檔壓縮在 2048 tokens 之內(nèi)。

3.2 指令生成

生成高質(zhì)量的指令需要關(guān)注兩個關(guān)鍵點：支持工具多樣性和多工具協(xié)同解決復(fù)雜任務(wù)。具體方法是從整個集合中采樣 API，然后提示 ChatGPT 為這些 API 生成不同的指令。

具體方法是：
為所有 API 及其組合生成指令，將 API 的總集定義為 SAPI，每次從 SAPI 中采樣一些 API：Ssub N = {API1, · · ·, APIN}；通過提示讓 ChatGPT 了解這些 API 的功能及其相互作用，然后生成涉及 Ssub N 中 API 的可能指令 (Inst*)，以及每個指令的相關(guān) API (Srel * ? Ssub N ) (Inst*)，即{[Srel 1 , Inst1],···,[Srel N′ , InstN′ ]}，其中N′表示每次生成實例的數(shù)量。用這些指令和相關(guān) API 對訓(xùn)練 API 檢索器。

與 ChatGPT 對話時，提示由以下部分組成：

• 指令對應(yīng)的任務(wù)的描述
• Ssub N 中每個 API 的綜合文檔，
• 三個種子示例，每個種子示例都是由人類專家編寫的理想指令。以規(guī)范 ChatGPT 的行為。為單工具/多工具分別編寫了 12 / 36 個不同的種子示例，每次隨機采樣三個示例。

簡言之，就是通過 API 描述和種子，生成可能的 API集合S/指令I(lǐng)nst 對。

API組合非常多，由常識可知，多數(shù)工具不會組合在一起使用，對于這種稀疏問題，通過 RapidAPI 中的層次過濾出更有效的組合，具體方法是：從同一類別/集合中選擇 2-5 個工具，并從每個工具中采樣最多 3 個 API 以生成指令。最后又去掉了一些幻覺產(chǎn)生的API，生成數(shù)據(jù)對：單個工具相關(guān)87413個、同類別工具84815個 ，同子類別工具25251個。

3.3 路徑標(biāo)注

路徑指的是工具和模型交互的過程，這里涉及多輪與 ChatGPT 的對話。給定指令 Inst，提示 ChatGPT 搜索有效的操作序列：{a1, ···, aN}。在每個時間步 t，模型根據(jù)之前的交互生成一個動作 at，即 ChatGPT(at|{a1, r1, · · · , at?1, rt?1}, Inst)，其中 r* 表示真實的 API 響應(yīng)。at 的格式如下：“想法：···，API 名稱：···，參數(shù)：····”。

對于每條指令，將所有采樣的 API Ssub N 作為可用函數(shù)提供給 ChatGPT，而不是僅將其相關(guān)的 API Srel* 提供給 ChatGPT。以訪問更廣泛的 API 并擴展操作空間。另外，還定義了兩個附加函數(shù)，即“完成最終答案”和“完成放棄”。

DFSDT
傳統(tǒng)的CoT 或 ReACT 對于決策有固有的局限性：（1）錯誤傳播：一步錯步步錯；（2）有限的探索：CoT或ReACT只探索一種可能的方向，導(dǎo)致對整個動作空間的探索有限，如圖所示。因此，即使是 GPT-4 也常常無法找到有效的解決方案路徑。

本文提出：基于深度優(yōu)先搜索的決策樹 DFSDT，具體如：圖-4所示。

當(dāng)對于某一條路徑搜索失敗時，退回上一個節(jié)點的其它路徑繼續(xù)搜索。

具體方法使用深度優(yōu)先搜索（DFS）而不是廣度優(yōu)先搜索（BFS），因為只要找到一條有效路徑就可以完成注釋，這樣花費更少的 token 調(diào)用成本。最終，生成 12657 個指令-解決方案對，用于訓(xùn)練 ToolLLaMA。實驗證明這個量集的實例已實現(xiàn)了滿意的泛化的需要。

4 實驗

4.1 TOOLEVAL

評測工具 TOOLEVAL 涉及兩個評測標(biāo)準(zhǔn)。

• 通過率（能否找到答案）：有限數(shù)量的操作（本文中為 200 個）內(nèi)成功完成指令的比例。計算其百分比視為通過率。另外，還處理了答案是“未找到答案”的"假正例"。
• 優(yōu)勝率（答案好不好）：通過比較兩個解決方案路徑來測量答案質(zhì)量。具體方法是：先讓人注釋人類偏好；對比 ChatGPT 評估器與人類注釋者的相關(guān)性高達 75.8%，因此可將其作為可信評估器。且當(dāng)對同一指令進行多次注釋時，該評估結(jié)果比人類更加一致。

4.2 初步實驗

4.2.1 API 檢索器

API 檢索器通過 Sentence-BERT 實現(xiàn)，模型將指令和 API 文檔分別編碼為兩個嵌入，然后計算兩個嵌入的相關(guān)性，以訓(xùn)練模型。
對比文中方法與 BM25，以及ChatGPT 提供的文本Embedding，文中方法明顯更好（畢竟它是通過有監(jiān)督數(shù)據(jù)訓(xùn)練過的模型），當(dāng)然應(yīng)用時效果也會更好。

4.2.2 對比 DFSDT 和 ReACT

對比 DFSDT 和 ReACT 的通過率，其中還加入了比較多次 ReACT@N 的操作。幾個實驗都證明 DFSDT 更好，尤其在相對復(fù)雜的場景中，DFSDT 對性能改進更明顯。

4.3 主實驗

使用指令-解決方案對 LLaMA 7B 模型進行調(diào)優(yōu)，得到模型 ToolLLaMA。對比其它模型結(jié)果如下：

• 這里表現(xiàn)最好的是 ChatGPT-DFSDT，也就是訓(xùn)練本文中模型的老師模型，這很正常，而且證明了 DFSDT 的有效性；
• 文中模型明顯優(yōu)于其它方法，通過率略低于其老師模型，優(yōu)勝率相似，這證明了可以通過調(diào)優(yōu)本地模型替代 ChatGPT 的可行性。
• Vicuna 和 Alpaca 是 LLaMA 的自然語言精調(diào)版本，實驗證明它無法支持工具預(yù)測。

消融實驗

這里對比文中幾種方法各自對模型的影響：

• 用 API 檢索器推薦的 API 替換真實 API，模型效果略有降低，說明重要的 API 基本都被檢索器識別到了。
• 將推理方法從 DFSDT 降級為 ReACT，效果明顯降低；主實驗也證明了 DFSDT 的重要性。這也說明，使用一些外部的方法也能提升模型性能。
• 使用 LoRA 作為增補模型以替代全模型調(diào)參，效果略有降低。

5 啟發(fā)

5.1 大模型

• 大模型分成：理解力，知識力
• 在調(diào)優(yōu)模型之外，可有很多方法提升模型效果
• 利用工具調(diào)優(yōu)的網(wǎng)絡(luò)，可實現(xiàn)更復(fù)雜的功能
• 目前多數(shù)網(wǎng)絡(luò)學(xué)習(xí)決策能力，外接網(wǎng)絡(luò)，實現(xiàn)分類回歸；文中學(xué)習(xí)生成能力，推薦一系列操作。
• 證明了本地模型替代 ChatGPT 的解決方案，可以泛化到其它定制功能。
• 用 ChatGPT構(gòu)造各種訓(xùn)練數(shù)據(jù)，評測……

5.2 具體工作

• 先用工具自動給Code寫說明文檔
• 學(xué)習(xí)本地 API（不是開放域）：Android的，自己的程序，用 ChatGPT 建立相關(guān)引導(dǎo)
• 不一定每次都調(diào)模型，2/8原則中的大部分功能有穩(wěn)定的路徑，用 Sentence-BERT可能又快又好地解決大部分問題。
• ToolBench 開源了訓(xùn)練數(shù)據(jù)集，可以直接用。
• 至少可以把文中功能作為代碼生成器使用，選擇 API 用。
• 使用工具也有多個層級：使用什么API/組合完成任務(wù)，代碼具體怎么寫。
• API 檢索器 可以做，（機器看有什么工具可以使用），應(yīng)該比普通的 code 生成器好用。
• DFSDT 有效解決了一步錯步步錯的問題。
• 也是一大模型加一小模型的結(jié)構(gòu)，用的是 Sentence-BERT。
• 有效利用了數(shù)據(jù)中的層級，一步一步定位這個方法很好，不是把所有數(shù)據(jù)喂進去。

5.3 其它想法

• 我們要做的是工具/平臺，不是具體代碼，支持后面更多功能插進來。
• 在指令生成部分，反向用 ChatGPT，這個挺有意思的