[翻譯] Microsoft Jarvis Paper

使用 chatGPT 3.5，內文有些圖表的部分就不進行翻譯，只做純文字翻譯

source

https://arxiv.org/pdf/2303.17580.pdf

內容

Abstract

解決跨領域和跨模式的複雜人工智慧任務是邁向先進人工智慧的重要一步。儘管有豐富的人工智慧模型適用於不同領域和模式，但它們無法處理複雜的人工智慧任務。考慮到大型語言模型 (LLMs) 在語言理解、生成、交互和推理方面展示了卓越能力，我們主張 LLMs 可以作為控制器來管理現有的人工智慧模型來解決複雜的人工智慧任務，並且語言可以是一種通用界面來實現這一目的。基於這種哲學，我們提出了 HuggingGPT 框架，利用 LLMs (例如 ChatGPT) 來連接機器學習社區 (例如 Hugging Face) 中的各種人工智慧模型來解決人工智慧任務。具體而言，當接收到用戶請求時，我們使用 ChatGPT 進行任務規劃，根據 Hugging Face 中提供的功能描述選擇模型，執行每個子任務，並根據執行結果總結回應。通過利用 ChatGPT 的強大語言能力和 Hugging Face 中豐富的人工智慧模型，HuggingGPT 能夠涵蓋不同模式和領域中的許多複雜的人工智慧任務，在語言、視覺、語音和其他具有挑戰性的任務方面取得了令人印象深刻的成果，為實現先進的人工智慧開辟了新的道路。

1. Introduction

大型語言模型（LLMs）[1、2、3、4、5、6]，如ChatGPT，因其在各種自然語言處理（NLP）任務上的卓越表現而引起了學術界和工業界的廣泛關注。基於大規模預訓練的海量文本語料庫和來自人類反饋的強化學習（RLHF），LLMs可以產生卓越的語言理解、生成、交互和推理能力。LLMs的強大能力也推動了許多新興的研究主題（例如上下文學習[1、7、8]、指令學習[9、10、11、12]和思路連貫提示[13、14、15、16]）進一步探索LLMs的巨大潛力，為我們構建先進的人工智慧系統帶來了無限可能性。

儘管大語言模型（LLMs）已經取得了巨大的成功，但目前的技術仍然存在缺陷，並面臨著建立先進人工智能系統的一些緊迫挑戰。我們從以下幾個方面進行討論：

由於現有LLMs只能處理文本生成的輸入和輸出形式，因此它們缺乏處理複雜信息（例如視覺和語音）的能力，儘管它們在自然語言處理（NLP）任務方面取得了顯著成就。
在現實世界的情況下，一些複雜任務通常由多個子任務組成，因此需要多個模型的調度和協作，這也超出了語言模型的能力範圍。
對於一些具有挑戰性的任務，LLMs在零樣本或少樣本情況下表現出色，但它們仍然比某些專家（例如微調模型）弱。如何解決這些問題可能是LLMs邁向更先進人工智能系統的第一步，也是關鍵的一步。

本論文指出，為了處理複雜的 AI 任務，LLM 應該能夠與外部模型協調，以利用其能力。因此，關鍵問題在於如何選擇適合的中介軟體，以建立 LLM 和 AI 模型之間的連接。為了解決這個問題，我們注意到每個 AI 模型可以通過總結其模型功能來表示為一種語言形式。因此，我們提出了一個概念：語言是 LLM 與 AI 模型連接的通用接口。換句話說，通過將這些模型描述納入提示中，LLM 可以被視為管理 AI 模型（如計劃、排程和協作）的大腦。因此，這種策略使得 LLM 可以調用外部模型來解決 AI 任務。但是，如果我們要將多個 AI 模型整合到 LLM 中，另一個挑戰就會出現：解決眾多 AI 任務需要收集大量高質量的模型描述，這需要大量的提示工程。巧合的是，我們注意到一些公共的 ML 社區通常提供各種適用於解決特定 AI 任務的模型，這些模型具有明確的模型描述，例如語言、視覺和語音。這些觀察為我們帶來了一些啟示：我們是否可以通過基於語言的接口將 LLM（例如 ChatGPT）與公共的 ML 社區（例如 GitHub、Hugging Face、Azure 等）連接起來，以解決複雜的 AI 任務？

因此，在本文中，我們提出一種名為HuggingGPT的系統，以連接LLMs（即ChatGPT）和機器學習社區（即Hugging Face），該系統可以處理來自不同模態的輸入並解決許多複雜的AI任務。更具體地說，對於Hugging Face中的每個AI模型，我們從庫中使用其對應的模型描述並將其融入提示中，以建立與ChatGPT的連接。之後，在我們的系統中，LLMs（即ChatGPT）將充當大腦來確定用戶問題的答案。正如圖1所示，HuggingGPT的整個過程可以分為四個階段：

任務規劃：使用 ChatGPT 分析用戶的請求，理解其意圖，並通過提示將其分解為可能的可解決任務。
模型選擇：為了解決計劃中的任務，ChatGPT根據模型描述，從Hugging Face中選擇專家模型。
任務執行：調用和執行每個選定的模型，並將結果返回給ChatGPT。
響應生成：最後，使用ChatGPT集成所有模型的預測，為用戶生成答案。

得益於這樣的設計，HuggingGPT 能夠使用外部模型，因此能夠整合多模態知覺能力，並處理多個複雜的 AI 任務。此外，這個流程還允許 HuggingGPT 繼續吸收來自特定任務專家的能力，實現可成長和可擴展的 AI 功能。

截至目前，我們的 HuggingGPT 在 Hugging Face 上已經整合了數百個模型，圍繞 ChatGPT 而建，涵蓋了24個任務，如文本分類、物體檢測、語義分割、圖像生成、問答、文本轉語音和文本轉視頻等。實驗結果顯示了 HuggingGPT 處理多模態信息和複雜 AI 任務的能力。

總之，我們的貢獻如下：

為了補充大型語言模型和專家模型的優點，我們提出了模型間協作協議。大型語言模型充當計劃和決策的大腦，而小型模型充當每個特定任務的執行者，為設計通用AI模型提供了新的方法。
我們建立了HuggingGPT，通過在ChatGPT周圍整合400多個特定任務的模型和Hugging Face平台，解決了通用AI任務。通過模型的開放協作，HuggingGPT為用戶提供了多模態和可靠的對話服務。
在語言、視覺、語音和跨模態等多個具有挑戰性的AI任務上進行了廣泛實驗，證明了HuggingGPT在理解和解決多個模態和領域的複雜任務方面的能力。

2-1. Large Language Models

近年來，大型語言模型（LLMs）[1, 2, 3, 4, 5, 6]的出現革命了自然語言處理（NLP）領域，例如GPT-3 [1]，PaLM [3]和LLaMa [6]等模型。由於其大量的語料庫和強大的訓練計算能力，LLMs在 zero-shot 和 few-shot 任務中展示了令人印象深刻的能力，以及更複雜的任務，如數學問題解決和常識推理。

一些關於LLMs的研究領域包括思路鏈激勵（CoT）[13, 14, 15, 16]和指令調整[9, 10, 11, 12]。思路鏈激勵，由[13]提出，通過設置幾個案例示例，促使大模型生成問題解決過程，從而顯著提高模型的推理能力。[14]將這種方法擴展到 zero-shot 思路鏈，並發現大模型仍然可以通過使用簡單的提示，如讓我們一步一步思考，表現良好。相反，[15]將程序語言與自然語言分開，使大型語言模型能夠生成代碼邏輯以解決推理問題。指令調整是大型語言模型應用的另一種方法。[10]，[11]和[9]等研究工作收集並轉換傳統的NLP任務數據集為指令，並在指令數據集上對大型模型進行微調，以提高對未知任務的泛化能力。在指令調整方面，Flan-T5 [12]和Flan-UL2僅使用100B參數就在650B的PaLM [3]模型上表現出色。另一方面，InstrutGPT和ChatGPT使用人類反饋的強化學習技術將語言模型與指令對齊，從而產生了出色的語言理解和生成能力。

2-2. Advances in LLM Capability

為了擴大大型語言模型（LLMs）超越文本生成的範圍，當代研究探索了兩種主要方法。首先，一些研究開發了統一的多模態語言模型，例如利用Q-former調和語言和視覺語義的BLIP-2 [17]和將視覺輸入納入文本序列以融合語言和視覺輸入的Kosmos-1 [18]。其次，其他研究專注於整合外部工具或模型。先驅性的Toolformer [19]在文本序列中引入外部API標籤，便於LLMs訪問外部工具。因此，許多研究擴展了LLMs以涵蓋視覺模態。Visual ChatGPT [20]將視覺基礎模型（如BLIP [21]和ControlNet [22]）與LLMs融合。Visual Programming [23]和ViperGPT [20]通過使用編程語言將視覺查詢解析為表達為Python代碼的可解釋步驟，從而將LLMs應用於視覺對象。此外，研究人員致力於使這些LLMs適應專門的視覺任務。例如，Prophet [24]和ChatCaptioner [25]分別將LLMs納入視覺問答和圖像字幕任務中。

不同於其他方法，我們提出的 HuggingGPT 以以下方式推進更為通用的人工智慧能力：

HuggingGPT 將大型語言模型作為介面，將用戶請求路由到專家模型，有效結合大型語言模型的語言理解能力和其他專家模型的專業知識。
HuggingGPT 不僅限於視覺感知任務，還可以通過大型語言模型組織模型之間的協作，從而處理任何模態或領域的任務。通過大型語言模型的規劃，可以有效地指定任務流程並解決更複雜的問題。
HuggingGPT 採用更加開放的方法，基於模型描述分配和組織任務。僅提供模型描述，HuggingGPT 就可以連續方便地整合不同的專家模型，而無需更改任何結構或提示設置。這種開放和連續的方式使我們更接近實現更先進的人工智慧。

3. Hugging GPT

HuggingGPT是一個協作系統，由一個大型語言模型(LLM)作為控制器，和多個專家模型作為協作執行者。HuggingGPT的工作流程包括四個階段：任務規劃、模型選擇、任務執行和響應生成，如圖2所示。1)首先，一個LLM (例如ChatGPT) 解析用戶請求，將其分解為多個任務，根據其知識規劃任務順序和依賴關係; 2) LLM根據Hugging Face中的模型描述將解析的任務分配給專家模型; 3)專家模型在推論端點上執行分配的任務，並將執行信息和推論結果記錄到LLM; 4)最後，LLM總結執行過程日誌和推論結果，並將摘要返回給用戶。

3-1. Task Planning

在 HuggingGPT 的第一個階段中，大型語言模型接收來自使用者的請求，將其解析成一系列結構化任務。複雜的請求通常涉及多個任務，而大型語言模型需要確定這些任務的依賴關係和執行順序。為了引導大型語言模型進行有效的任務規劃，HuggingGPT 的提示設計採用了基於規格的指令和基於演示的解析。以下段落介紹詳細內容。

基於規範的指令方式，任務規範提供了任務的統一模板，並允許大型語言模型通過槽填充進行任務解析。HuggingGPT為任務解析設計了四個槽位，分別是任務類型、任務ID、任務依賴和任務參數：

任務ID
- 提供任務規劃的唯一標識，用於參考依賴任務及其生成的資源。
任務類型
- 涵蓋語言、視覺、視頻、音頻等不同任務。 HuggingGPT目前支持的任務列表顯示在表1、2、3和4中。
任務依賴
- 定義了執行所需的先決任務。只有當所有的先決任務完成後，任務才會啟動。
任務引數
- 包含執行任務所需的引數列表。根據任務類型，它包含三個子項，分別填充為文本、圖像和音頻資源。它們從用戶的請求或依賴任務生成的資源解析而來。不同任務類型的相應引數類型顯示在表1、2、3和4中。

由於受益於指令調整 [9] 和從人類反饋中進行的強化學習 [2]，大型語言模型具有遵循指令的能力。HuggingGPT將這些任務規格提供給大型語言模型作為高級指令，用於分析用戶的請求並相應地解析任務。

HuggingGPT 引入了上下文學習，以提高任務解析和規劃的效率。通過在提示中注入多個示範，HuggingGPT 可使大型語言模型更好地理解任務規劃的意圖和標準。每個示範都是一組任務規劃的輸入和輸出 - 用戶的請求和要解析出的預期任務序列。此外，這些示範包含了從用戶請求解析出的任務依賴關係，有助於 HuggingGPT 理解任務之間的邏輯關係，並確定執行順序和資源依賴關係。此外，對話的上下文管理對於聊天機器人至關重要，因為它提供聊天日誌，以幫助理解用戶的請求。為了在任務規劃階段加入聊天上下文，我們在提示中添加了以下段落：聊天日誌被記錄為 {{ Chat Logs }}。您可以從聊天記錄中找到任務規劃所需的歷史資源，其中 {{ Chat Logs }} 是 HuggingGPT 和用戶之間的聊天日誌。

3-2. Model Selection

在解析任務列表後，HuggingGPT 接下來需要匹配任務和模型，也就是為任務列表中的每個任務選擇適當的模型。為此，我們首先從 Hugging Face Hub 獲取專家模型的描述，然後通過上下文任務-模型分配機制為任務動態選擇模型。這種做法允許增量模型訪問（僅提供專家模型的描述），更具開放性和靈活性。

Model Descriptions
Hugging Face Hub 上的專家模型附帶有全面的模型描述，通常由開發人員提供。這些描述包含模型的功能、架構、支援的語言和領域、授權等信息。這些信息有效地支持 HuggingGPT 根據用戶請求和模型描述的相關性選擇適合的模型來完成任務。

In-Context Task-Model Assignment
我們將任務和模型的分配視為單選問題，在給定的上下文中將潛在模型作為選項呈現。通過在提示中包含用戶查詢和解析的任務，HuggingGPT可以為手頭的任務選擇最合適的模型。但是，由於上下文長度的限制，不總是可能在提示中包含所有相關的模型信息。為解決此問題，我們根據任務類型過濾模型，只保留與當前任務類型匹配的模型。剩下的模型根據它們在Hugging Face上收到的下載數進行排名，因為我們認為這個數字在一定程度上反映了模型的質量。然後，我們基於這個排名選擇前K個模型作為HuggingGPT選擇的候選模型。

3-3 Task Execution

當一個任務被指派給特定模型時，下一步就是執行任務，即進行模型推論。為了加速並確保計算穩定性，HuggingGPT 在混合推論端點上運行這些模型。通過將任務參數作為輸入，模型計算推論結果，然後將其發送回大型語言模型。為了進一步提高推論效率，沒有資源依賴的模型可以進行並行處理。這意味著可以同時開始多個滿足先決依賴關係的任務。

Hybrid Endpoint
在理想情況下，我們只使用 Hugging Face 上的推論端點。然而，在某些情況下，我們需要部署本地推論端點，例如某些模型的推論端點不存在、推論時間很長，或是網絡訪問受限。為了保持系統的穩定性和效率，HuggingGPT 會在本地拉取和運行一些常用或耗時的模型。本地推論端點速度快，但涵蓋的模型較少，而 Hugging Face 的推論端點則相反。因此，本地端點的優先級高於 Hugging Face 的推論端點。只有在匹配的模型未在本地部署時，HuggingGPT 才會在 Hugging Face 的推論端點上運行該模型。

Resource Dependency
雖然 HuggingGPT 可以透過任務規劃來發展任務順序，但在任務執行階段仍然可能很難有效地管理任務之間的資源依賴關係。這是因為 HuggingGPT 在任務規劃階段無法指定未來生成的任務資源。為解決這個問題，我們使用一個獨特的符號 “<resource>” 來管理資源依賴關係。具體而言，HuggingGPT 將前置任務生成的資源識別為 <resource>-task_id，其中 task_id 是前置任務的任務 ID。在任務規劃階段，如果有任務依賴於 task_id 所生成的資源，HuggingGPT 將這個符號設置為任務參數中相應的資源子欄位。然後在任務執行階段，HuggingGPT 動態地將這個符號替換為前置任務生成的資源。這種策略使 HuggingGPT 能夠有效地處理任務執行期間的資源依賴關係。

3-4. Response Generation

在所有任務執行完成後，HuggingGPT 進入回應生成階段。在這個階段，HuggingGPT 將前三個階段（任務規劃、模型選擇和任務執行）的所有資訊整合成簡潔的摘要，包括計畫任務列表、任務所選擇的模型，以及模型的推論結果。

其中最重要的是推論結果，它們是 HuggingGPT 作出最終決策的依據。這些推論結果以結構化格式出現，例如物體檢測模型中帶有檢測概率的邊界框，問答模型中的答案分布等。HuggingGPT 允許 LLM 將這些結構化推論結果作為輸入，並以友好的人類語言生成回答。此外，LLM 不僅僅是將結果聚合起來，還能主動回應用戶的請求，提供具有置信度的可靠決策。

4. Experiments

4-1. Setting

在我們的實驗中，我們採用了GPT模型的 gpt-3.5-turbo 和 text-davinci-003 變體作為大型語言模型，這些模型可通過OpenAI API 4公開訪問。為了使LLM的輸出更穩定，我們將解碼溫度設置為0。此外，為了使LLM的輸出符合預期格式，我們在格式約束上設置了0.2的logit_bias。我們在表5中提供了針對任務規劃、模型選擇和響應生成階段設計的詳細提示，其中{{variable}}表示該插槽需要在將提示餵入LLM之前填充相應的文本。

4-2. Qualitative Results

在圖3、4和5中，我們展示了幾個對話示範。在每個示範中，用戶輸入了一個可能包含多個任務或多模態資源的請求。然後，HuggingGPT依靠LLM組織多個專家模型的協作，向用戶生成回應。為了清晰展示HuggingGPT的工作流程，我們提供了任務規劃和任務執行階段的結果。

圖3展示了HuggingGPT在任務之間存在資源依賴的情況下的工作過程。在這種情況下，HuggingGPT可以根據用戶的抽象請求解析出具體的任務，包括姿勢檢測、圖像標題和姿勢條件圖像生成任務。此外，HuggingGPT成功地識別了任務＃3與任務＃1和＃2之間的依賴關係，在依賴任務完成後，將任務＃1和＃2的推斷結果注入任務＃3的輸入參數中。

圖 4 展示了 HuggingGPT 在音頻和視頻模式上的對話能力。在兩個案例中，它展示了 HuggingGPT 分別通過專家模型完成用戶請求的文本轉音頻和文本轉視頻任務。在頂部案例中，這兩個模型是並行執行的（同時生成音頻和生成視頻），而在底部案例中，這兩個模型是串行執行的（先從圖像生成文本，然後根據文本生成音頻）。這進一步驗證了 HuggingGPT 可以組織模型之間的協作和任務之間的資源依賴關係。

圖5展示了HuggingGPT整合多個使用者輸入資源來進行簡單推理的能力。我們可以發現，即使有多個資源，HuggingGPT也能將主要任務分解為多個基本任務，最終整合多個模型的多次推論結果，以獲得正確的答案。

4-3. Case Study on Simple Tasks

HuggingGPT 是一個多模型協作系統，依靠任務規劃和模型選擇為 LLM 提供了更廣泛的能力。我們在廣泛的多模態任務上測試了 HuggingGPT，並在圖 6 和 7 中展示了一些選定的案例。透過大型語言模型和專家模型的協作，HuggingGPT 可以解決廣泛的模態任務，包括語言、圖像、音頻和視頻，涵蓋檢測、生成、分類和問答等各種形式的任務。雖然這些任務看似簡單，但掌握 HuggingGPT 的基本能力是解決複雜任務的先決條件。

4-4. Case Study on Complex Tasks

使用者的請求可能包含多個隱含的任務或需要多方面的信息，這種情況下我們不能只依靠一個專家模型來解決問題。為了克服這個挑戰，HuggingGPT通過任務規劃組織多個模型之間的協作。如圖8、9和10所示，我們進行了測試以評估HuggingGPT在複雜任務情況下的有效性。圖8展示了HuggingGPT在多輪對話場景中應對複雜任務的能力。使用者將一個複雜請求分成多個步驟，通過多輪請求達到最終目標。我們發現HuggingGPT可以通過任務規劃階段的對話上下文管理來跟踪使用者請求的上下文狀態，並能夠很好地處理使用者提到的資源以及任務規劃。圖9顯示，在“簡單”的“盡可能詳細地描述圖像”請求中，HuggingGPT可以將其擴展為五個相關任務，分別是圖像標題、圖像分類、物體檢測、分割和視覺問答任務。HuggingGPT為每個任務分配專家模型，這些模型從LLM的不同方面提供與圖像相關的信息。最後，LLM整合這些信息以進行全面和詳細的描述。圖10顯示，多個任務可能明確包含在用戶請求中。在這些情況下，HuggingGPT可以滿足所有用戶的要求，組織多個專家模型並行協作，然後讓LLM聚合模型推斷結果以回應用戶。總之，HuggingGPT依賴LLM與外部專家模型的協作，在各種形式的複雜任務上表現出有前途的性能。

5. Limitations

HuggingGPT也不可避免地存在一些限制。我們最關注的限制之一是效率。效率的瓶頸在於大型語言模型的推理。對於每一輪用戶請求，HuggingGPT在任務規劃、模型選擇和響應生成階段至少需要與大型語言模型進行一次交互。這些交互大大增加了響應延遲，導致用戶體驗下降。第二個限制是最大上下文長度的限制。受LLM可接受的最大標記數量限制，HuggingGPT在最大上下文長度上也面臨著限制。我們使用對話窗口並僅在任務規劃階段跟踪對話上下文以緩解這種情況。第三個限制是系統穩定性，包括兩個方面。一個是大型語言模型推理過程中發生的反叛。大型語言模型偶爾在推理時不遵循指令，輸出格式可能違反預期，導致程序工作流程異常。第二個是Hugging Face推理端點上的專家模型的不可控狀態。 Hugging Face上的專家模型可能會受到網絡延遲或服務狀態的影響，從而導致任務執行階段出現錯誤。

6. Conclusion

本論文提出了一個名為 HuggingGPT 的系統，以語言作為介面，連接大型語言模型和AI模型，來解決人工智慧任務。我們的系統原則是將大型語言模型視為控制器，用於管理AI模型，並利用像 Hugging Face 這樣的機器學習社區中的模型來解決用戶的不同需求。通過充分利用大型語言模型在理解和推理方面的優勢，HuggingGPT能夠分析用戶意圖，將任務分解成多個子任務。然後，根據專家模型的描述，HuggingGPT能夠為每個任務分配最適合的模型並集成不同模型的結果。通過利用機器學習社區中眾多AI模型的能力，HuggingGPT展示了在解決具有挑戰性的人工智慧任務方面的巨大潛力。

此外，我們還注意到，近期大型語言模型的快速發展對學術界和工業界帶來了巨大的影響。我們也期望我們的模型設計可以啟發整個社區，為大型語言模型走向更先進的人工智慧提供新的途徑。

發佈時間 2023-4-14

#translate