首個大規模使用工具的大模型來了：伯克利發布Gorilla
大型語言模型性能強大，但為了更好地用于解決實際問題，各式各樣的 API 是必不可少的。
近日，加利福尼亞大學伯克利分校和微軟研究院造出了一只「大猩猩」Gorilla，該模型能根據用戶輸入的自然語言為用戶選擇合適的 API 來執行對應任務。理論上講，這個模型可以根據用戶需求調用其它各種 AI 模型，因此 Gorilla 有望成為一個統御其它 AI 的 AI 模型。該項目的代碼、模型、數據和演示都已發布。
- 網站：gorilla.cs.berkeley.edu
- 論文：arxiv.org/abs/2305.15334
- GitHub：https://github.com/ShishirPatil/gorilla/
- Gorilla Spotlight Waitlist：https://t.co/rvmk13Mhrx
- Discord Community：https://discord.gg/pWeBheVY7n
大型語言模型（LLM）近來出盡風頭，在自然對話、數學推理和程序合成等任務上都取得了顯著進展。盡管進步非凡，但 LLM 依然從根本上受限于它們在一個固定的權重集內可存儲的信息以及它們可使用一個靜態的計算圖（computation graph）和有限上下文所能計算的東西。此外，當世界變化時，還需要重新訓練 LLM，以更新它們的知識和推理能力。
通過讓 LLM 具備使用工具的能力，我們可以讓其有能力訪問更大范圍的和不斷變化的知識庫，進而完成復雜的計算任務。具體來說，如果為 LLM 提供搜索技術和數據庫，研究表明 LLM 的能力可得到強化，從而可以應對大得多的且更加動態多變的知識空間。而當為 LLM 提供計算工具時，LLM 就能完成復雜的計算任務。因此，引領市場的 LLM 提供商已經開始提供各種插件，讓 LLM 可通過 API 來調用外部工具。
這樣一來，LLM 的能力范圍就從少量人工編碼的工具轉變成了大量不斷變化的云 API，這讓 LLM 可成為用戶訪問計算基礎設施和網絡的主要交互界面。舉個例子，如果 LLM 可訪問航班、租車、酒店、餐飲和娛樂行業的網絡 API，那么從預定整個假期行程的各種票證到舉辦一場會議，只需簡單地與 LLM 對話就能完成。但是，在為 LLM 集成各式工具方面，之前的研究考慮的都是可輕松注入到 prompt 中的少量 API，并且這些 API 基本都有很好的文檔描述。
如果想要支持整個網絡上數以百萬計且不斷變化的 API，我們就需要重新思考集成工具的方法。這種情況下，在單一的上下文中描述所有 API 的集合是不可能的。并且許多 API 功能重疊卻又有細微不同的局限性和約束條件。新的情況還需要新的評估基準。
這篇論文中，研究者對這個方向進行了探索。
他們使用自指示微調（self-instruct fine-tuning）和檢索（retrieval），讓 LLM 可根據 API 和 API 文檔準確地從大量重疊且多變的工具中做出選擇。他們構建了 APIBench，這是一個大型 API 語料庫，是從公開模型 Hub 中抓取的機器學習 API（模型），它們的功能很復雜且通常存在重疊。
為了構建這個數據集，研究者選取了三個主要的模型 Hub：TorchHub、TensorHub 和 HuggingFace。他們詳盡地囊括了 TorchHub（94 個 API 調用）和 TensorHub（696 個 API 調用）中的所有 API 調用；而對于 HuggingFace，由于模型數量龐大且許多模型都沒有規格數據，因此他們就從每個任務類別選取了下載次數最多的 20 個模型（共 925 個）。研究者使用自指示為每個 API 生成了 10 個合成的用戶提問 prompt。這樣，該數據集中的每一項都變成了一組配對的「指示」和「參照 API」。
研究者采用了常用的 AST 子樹匹配技術來評估所生成的 API 的功能正確性。首先，所生成的代碼被解碼成一個 AST 樹，然后找到一個子樹且其根節點是我們關心的 API 調用（比如 torch.hub.load），然后使用它來索引數據集。研究者評估了 LLM 的功能正確性和幻覺問題并報告了相應的準確度。
然后他們通過微調得到了 Gorilla，這是一個基于 LLaMA-7B 的模型，并且其能通過新構建數據集索引文檔。通過實驗，研究者發現在 API 功能準確性以及降低幻覺錯誤方面，Gorilla 均顯著優于 GPT-4。圖 1 給出了一個輸出示例。此外，研究者為 Gorilla 采用的檢索感知型訓練法（retrieval-aware training）還讓模型可適應 API 文檔的變化。最后，Gorilla 在理解和推理局限性方面的能力也得到了展示。
方法
圖 1：API 調用示例
給定一個 prompt，從左至右分別為 GPT-4、Claude、Gorilla 生成的示例 API 調用。在這個例子中，GPT-4 給出了一個根本不存在的模型，Claude 則選取了一個錯誤的軟件庫。對比之下，Gorilla 模型能夠正確辨別任務并建議了一個完全合格的 API 調用。
數據集收集
為了收集數據集，研究者精心記錄了 HuggingFace 的 The Model Hub、PyTorch Hub 以及 TensorFlow Hub Models 的所有在線模型卡片。后面為了方便描述，以上三個 Hub 將被分別簡稱為 HuggingFace、Torch Hub 和 TensorFlow Hub。
API 文檔：HuggingFace 平臺托管了大約 203681 個模型。但是，其中大部分都存在文檔問題，比如描述很差、缺乏依賴描述或模型卡片中沒有信息等。為了濾除這些模型，研究者從每個域都僅選取了前 20 個模型。其中多模態數據方面 7 個域、計算機視覺方面 8 個、NLP 方面 12 個、音頻方面 5 個、表格式數據方面 2 個、強化學習方面 2 個。
過濾后，從 HuggingFace 共獲得 925 個模型。TensorFlow Hub 的版本分為 v1 和 v2。最新的 v2 版本共有 801 個模型，它們全部被納入考慮。濾除信息很少和無信息的模型卡片后，剩余 626 個模型。類似地，研究者從 Torch Hub 得到了 95 個模型。最終得到 1645 個 API 調用。然后，他們將其中每一個的模型卡片都轉換成一個 json 對象，其有以下字段：{域，框架，功能，api_名稱，api_調用，api_參數，環境要求，示例代碼，性能，描述}. 下方給出了一個例子。選取這些字段的目的是將這些機器學習域的 API 調用泛化到其它域，包括 RESTful API 調用。
指示生成：研究者使用自指示范式來引導 GPT-4 生成合成的指令數據。他們提供了三個基于上下文的示例以及一個參照 API 文檔，給模型的任務是生成調用該 API 的真實世界用例。研究者特別指示模型在創建指令時避免使用任何 API 名稱或提示。對于三個模型 Hub 中的每一個，研究者都構建了六個示例（指令 - API 對）。這 18 個數據點是僅有的人工生成或人工修改的數據。對于那 1645 個 API 數據點中的每一個，研究者采用的方法是從 6 個對應的指令示例中采樣出 3 個，用以生成總計 10 對「指令 - API」，如圖 3 所示。
研究者重點指出，這些指令只需使用 GPT-4 就能生成，當然也可使用其它開源的替代工具，比如 LLaMA 和 Alpaca 等。
Gorilla
研究者構建的 Gorilla 模型是一種檢索感知型的 LLaMA-7B 模型，并特別針對 API 調用任務進行了微調。如圖 3 所示，研究者使用了自指示來生成 {指令，API} 對。為了微調 LLaMA，需要將其轉換成用戶與智能體聊天形式的對話數據，其中每個數據點都是一輪對話，即用戶和智能體各說話一次。然后再在基礎 LLaMA-7B 模型上執行標準的指令微調。在實驗中，研究者訓練 Gorilla 時使用了兩種方案：使用檢索器及不使用檢索器。
圖 3：Gorilla：一個讓 LLM 與 API 交互的系統
圖中，上半部分是訓練過程。研究者表示這是目前最詳盡的機器學習 API 數據集。下半部分是推理過程；Gorilla 支持兩種模式：使用檢索和零樣本（無檢索）。在這個具體示例中，用戶查詢的是基于自然語言生成圖像，模型能夠建議出合適的 API。
帶有局限條件的 API 調用：API 調用往往自帶局限性。這些局限性要求 LLM 不僅要能理解 API 調用的功能，還要能根據不同的限制參數對 API 調用進行分類。這個要求會為整個過程引入額外的復雜性，這要求對 LLM 有更加精細的理解。
具體來說，對機器學習 API 而言，常見的限制因素有兩個：參數數量和準確度下限。來看個例子，如果有以下 prompt：「調用一個參數數量少于一千萬的圖像分類模型，但保持 ImageNet 準確度至少為 70%?！惯@樣的 prompt 極具挑戰性，讓 LLM 難以準確解讀和響應。LLM 不僅必須理解用戶描述的功能，還需要推理用戶請求中嵌入的各種約束條件。這一挑戰突出表明：現實世界 API 調用對 LLM 的要求是非常錯綜復雜的。模型只理解 API 調用的基本功能是不夠的；模型還必須理解伴隨這些調用而來的復雜約束條件并做出適當響應。這些觀察結果表明：針對 API 調用任務對 LLM 進行微調是必需的。
檢索感知型訓練：當使用檢索器（根據指令微調過的數據集）訓練時，還要在用戶 prompt 后面附帶一句「Use this API documentation for reference: 」。研究者表示，這么做的目的是讓 LLM 學會通過解析問題的后半部分來回答前半部分。研究結果表明，這樣做能夠 a) 讓 LLM 適應測試時 API 文檔中的變化，b) 基于上下文學習提升性能表現，c) 減少幻覺錯誤。
不過研究者也發現了一個讓人驚訝的現象：當使用檢索器來提升 LLM 的能力時，其性能并不一定總是會提升，有時候還會降低。
Gorilla 推理：推理階段，用戶提供自然語言表達的 prompt。類似于訓練階段，Gorilla 在推理時也有兩種模式：零樣本和使用檢索。使用零樣本模式時，prompt（沒有進一步的 prompt 微調）會被饋送給 Gorilla LLM 模型，然后模型返回有助于完成任務和 / 或目標的 API 調用。使用檢索模式時，檢索器（BM25 或 GPT-Index）首先會檢索 API 數據庫中存儲的最新的 API 文檔。然后再在用戶 prompt 后面添加一個消息：Use this API documentation for reference:，之后再饋送給 Gorilla。Gorilla 的輸出是要調用的 API。除了這個附加消息之外，該系統不會再添加更多 prompt 微調。
驗證 API
歸納式程序合成是指合成滿足測試用例的程序，這類技術已經取得了不少成功。但是，在評估 API 調用性能時，測試用例卻不夠用，因為驗證代碼的語義正確性往往非常困難。以圖像分類任務為例，有 40 多種模型都可用于該任務。即使將選擇范圍收縮至單一的 Densenet 系列，也有 4 種不同的配置可能性。
因此，一個任務可能存在多個正確答案，而且很難通過單元測試判斷使用的 API 在功能上是否等價于參照 API。因此，為了評估新模型的性能，研究者使用他們收集的數據集對功能等價性進行了比較。為了追蹤數據集中的哪個 API 是 LLM 調用，研究者采用了 AST 樹匹配策略。在這項研究中，由于只考慮一個 API 調用，因此為了揭示正在使用數據集中的哪個 API，可以檢查候選 API 調用的 AST 是否是參照 API 調用的子樹。
識別乃至定義幻覺可能非常困難。對此，研究者采用的方法是 AST 匹配。他們將幻覺定義為不屬于數據庫中任意 API 的子樹的 API 調用，即調用了一個完全想象出來的工具。這種形式的調用不同于調用了錯誤的 API（這種情況被定義為錯誤）。
AST 子樹匹配：AST 子樹匹配可識別數據庫中的哪個 API 是 LLM 調用的 API。由于每次 API 調用可能有許多參數，因此就需要對每個參數進行匹配。更進一步，由于 Python 允許默認參數，因此對于每個 API 都需定義要用哪些參數去匹配數據庫。舉個例子，在函數調用中可以檢查 repo_or_dir 和模型參數。通過這種方式，可以輕松地檢查參數是否與參照 API 匹配。
圖 4 給出了更多細節。在這個例子中，Gorilla 返回了一個 torch API 調用。首先構建這個樹，然后驗證它與數據庫中的子樹匹配，即沿節點 torch.hub.load、pytorch/vision 和 densenet121 的子樹。但是，這里沒有檢查沿葉節點 pretrained = True 的匹配情況，因為這個參數是可選的。
圖 4：用于評估 API 調用的 AST 子樹匹配
圖中左側是 Gorilla 返回的一個 API 調用。首先構建相關的 API 樹。然后將其與構建的數據集比較，看該 API 數據集是否有匹配的子樹。圖中用棕色框標記了匹配的子樹，這說明這個 API 調用是正確的。Pretrained=True 是一個可選參數。
評估
圖 5：使用 GPT 檢索器時的準確度
很顯然，Gorilla 的表現優于 Torch Hub 和 HuggingFace，與 Tensorflow Hub 的表現相當。
表 1：在 Torch Hub、HuggingFace 和 Tensorflow Hub API 上評估 LLM。
表 1 表明經過輕度微調的 Gorilla 取得了優于其它所有模型的當前最佳表現。此外，還可以發現在沒有檢索器時進行微調以及在評估時使用 ground truth 檢索器對性能幾乎沒有幫助。
表 2：檢索技術的比較
可以看出，檢索器更好時，使用檢索器進行微調仍然是更好的方法，而在另一種情況下，如果沒有好的檢索器，零樣本微調可能是更優選擇。
表 3：在感知約束條件的 API 調用任務上評估 LLM
可以看出，當使用檢索器（BM25 或 GPTIndex）時，Gorilla 的表現接近最優秀的 GPT-3.5，而在不使用檢索器時，Gorilla 的準確度最高。
