HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face

Status: Reading
Author: Dongsheng Li, Kaitao Song, Weiming Lu, Xu Tan, Yongliang Shen, Yueting Zhuang
Institution: 微軟亞洲研究院（Microsoft Research Asia）, 浙江大學（Zhejiang University）
Publisher: NeurIPS
Publishing/Release Date: December 3, 2023
Summary: 解決不同領域和多種模態的復雜任務是通往AGI的關鍵，盡管現在有各種各樣的AI模型，但是它們沒有辦法自主地處理復雜任務，而LLMs恰好可以作為管理者控制現有的AI模型來完成任務。本文提出的HuggingGPT就是一個基于ChatGPT的Agent，可以利用HuggingFace上各種各樣的AI模型來完成任務。首先通過ChatGPT根據用戶的請求制定任務計劃，然后根據HuggingFace上模型的功能描述選擇可用的AI模型，之后通過這些模型來執行子任務，最后總結執行結果并給出響應。HuggingGPT可以解決跨領域跨模態的各種AI任務，在語言、視覺、語音等任務中都取得很好的效果。
Type: Paper
鏈接: https://arxiv.org/abs/2303.17580
代碼是否開源: 開源
代碼鏈接: https://github.com/microsoft/JARVIS

---

讀前先問

帶著問題讀論文，邊讀邊回答。

1. 大方向的任務是什么？Task

Agent

1. 這個方向有什么問題？是什么類型的問題？Type

雖然AI模型眾多，但是不能互相配合。

1. 為什么會有這個問題？Why

沒有一個大腦作為指揮。

1. 作者是怎么解決這個問題的？How

將ChatGPT作為大腦來指揮各種AI模型。

1. 怎么驗證解決方案是否有效？

2. 實驗結果怎么樣？What（重點關注有沒有解決問題，而不是效果有多好）

---

論文精讀

引言

目前的LLM技術尚不完善，在構建先進的AI系統的道路上面臨著一些緊迫的挑戰：

1. 受限于文本生成的輸入輸出形式，目前的LLM缺乏處理視覺、語音等復雜信息的能力；
2. 在現實場景中，一些復雜的任務通常由多個子任務組成，因此需要多個模型的調度和協作，這也超出了語言模型的能力；
3. 對于一些具有挑戰性的任務，LLM在Zero-Shot或Few-Shot設置中表現出出色的結果，但仍然弱于一些專家。

作者認為，為了處理復雜的AI任務，LLM應該能夠與外部模型協調以利用它們的力量。關鍵問題是如何選擇合適的中間件來橋接LLM和AI模型之間的聯系，LLM恰好可以完成這個工作。將各種AI模型的描述融入到提示詞中，LLM可以作為管理規劃、調度、合作等這些AI模型的大腦。

在這篇論文中，作者提出了一種名為 HuggingGPT 的由 LLM 驅動的 Agent，可以自主處理各種復雜的 AI 任務，它連接了 LLM（即 ChatGPT）和 ML 社區（即 Hugging Face），并且可以處理來自不同模式的輸入。更具體地說，LLM充當大腦：一方面根據用戶請求拆解任務，另一方面根據模型描述為任務分配合適的模型。通過執行模型并將結果集成到計劃任務中，HuggingGPT 可以自主滿足復雜的用戶請求。

HuggingGPT 的工作流如下圖所示，可以分為四個階段：

1. 任務規劃：使用ChatGPT分析用戶的請求，了解他們的意圖，并將其分解為可能的可解決的任務。
2. 模型選擇：ChatGPT 根據模型描述選擇托管在 Hugging Face 上的專家模型。
3. 任務執行：調用并執行每個選定的模型，并將結果返回給ChatGPT。
4. 響應生成：ChatGPT 集成所有模型的預測結果并為用戶生成響應。

HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face

Status: Reading
Author: Dongsheng Li, Kaitao Song, Weiming Lu, Xu Tan, Yongliang Shen, Yueting Zhuang
Institution: 微軟亞洲研究院（Microsoft Research Asia）, 浙江大學（Zhejiang University）
Publisher: NeurIPS
Publishing/Release Date: December 3, 2023
Summary: 解決不同領域和多種模態的復雜任務是通往AGI的關鍵，盡管現在有各種各樣的AI模型，但是它們沒有辦法自主地處理復雜任務，而LLMs恰好可以作為管理者控制現有的AI模型來完成任務。本文提出的HuggingGPT就是一個基于ChatGPT的Agent，可以利用HuggingFace上各種各樣的AI模型來完成任務。首先通過ChatGPT根據用戶的請求制定任務計劃，然后根據HuggingFace上模型的功能描述選擇可用的AI模型，之后通過這些模型來執行子任務，最后總結執行結果并給出響應。HuggingGPT可以解決跨領域跨模態的各種AI任務，在語言、視覺、語音等任務中都取得很好的效果。
Type: Paper
鏈接: https://arxiv.org/abs/2303.17580
代碼是否開源: 開源
代碼鏈接: https://github.com/microsoft/JARVIS

---

讀前先問

帶著問題讀論文，邊讀邊回答。

1. 大方向的任務是什么？Task

Agent

1. 這個方向有什么問題？是什么類型的問題？Type

雖然AI模型眾多，但是不能互相配合。

1. 為什么會有這個問題？Why

沒有一個大腦作為指揮。

1. 作者是怎么解決這個問題的？How

將ChatGPT作為大腦來指揮各種AI模型。

1. 怎么驗證解決方案是否有效？

2. 實驗結果怎么樣？What（重點關注有沒有解決問題，而不是效果有多好）

---

論文精讀

引言

目前的LLM技術尚不完善，在構建先進的AI系統的道路上面臨著一些緊迫的挑戰：

1. 受限于文本生成的輸入輸出形式，目前的LLM缺乏處理視覺、語音等復雜信息的能力；
2. 在現實場景中，一些復雜的任務通常由多個子任務組成，因此需要多個模型的調度和協作，這也超出了語言模型的能力；
3. 對于一些具有挑戰性的任務，LLM在Zero-Shot或Few-Shot設置中表現出出色的結果，但仍然弱于一些專家。

作者認為，為了處理復雜的AI任務，LLM應該能夠與外部模型協調以利用它們的力量。關鍵問題是如何選擇合適的中間件來橋接LLM和AI模型之間的聯系，LLM恰好可以完成這個工作。將各種AI模型的描述融入到提示詞中，LLM可以作為管理規劃、調度、合作等這些AI模型的大腦。

在這篇論文中，作者提出了一種名為 HuggingGPT 的由 LLM 驅動的 Agent，可以自主處理各種復雜的 AI 任務，它連接了 LLM（即 ChatGPT）和 ML 社區（即 Hugging Face），并且可以處理來自不同模式的輸入。更具體地說，LLM充當大腦：一方面根據用戶請求拆解任務，另一方面根據模型描述為任務分配合適的模型。通過執行模型并將結果集成到計劃任務中，HuggingGPT 可以自主滿足復雜的用戶請求。

HuggingGPT 的工作流如下圖所示，可以分為四個階段：

1. 任務規劃：使用ChatGPT分析用戶的請求，了解他們的意圖，并將其分解為可能的可解決的任務。
2. 模型選擇：ChatGPT 根據模型描述選擇托管在 Hugging Face 上的專家模型。
3. 任務執行：調用并執行每個選定的模型，并將結果返回給ChatGPT。
4. 響應生成：ChatGPT 集成所有模型的預測結果并為用戶生成響應。

主要貢獻：

1. 提出HuggingGPT，結合LLM和專家模型，通過模型間合作協議，提供設計通用AI解決方案的新方法。
2. 將Hugging Face平臺的任務特定模型與ChatGPT集成，處理多模態、多領域的廣義AI任務，提供可靠的多模態對話服務。
3. 強調任務規劃和模型選擇的重要性，并提出評估LLMs在這方面能力的實驗方法。
4. 大量跨模態和領域的實驗表明，HuggingGPT在理解和解決復雜任務方面具有強大能力和巨大潛力。

方法

任務規劃

任務規劃模塊旨在使用LLM分析用戶請求，然后將其分解為結構化任務的集合，還要要求LLM確定這些分解任務的依賴關系和執行順序，以建立它們的連接。

1. 特定格式的指令：為了更好地表示用戶請求并且在后續階段使用，我們希望LLM能夠輸出特定格式（例如JSON）的內容，方便解析。一個任務則是由任務名稱、任務ID、依賴任務和參數四部分組成。
2. 為了更好地理解任務規劃的意圖和標準，HuggingGPT 在提示詞中融入了多個例子。

任務規劃階段的提示詞如下圖所示，為了支持更復雜的場景（例如，多輪對話），作者在提示詞中還包含了聊天日志。

任務規劃的模板

[{"task": task, "id", task_id, "dep": dependency_task_ids, "args": {"text": text, "image": URL, "audio": URL, "video": URL}
}]

名稱	定義
task	代表解析任務的類型，涵蓋了語言、視覺、視頻、音頻等不同的任務。
id	任務計劃的唯一標識符，用于引用相關任務及其生成的資源。
dep	定義了執行所需的先決任務，僅當所有先決依賴任務完成后才會啟動該任務。
args	包含任務執行所需參數的列表，三個子字段，根據任務類型填充文本、圖像和音頻資源。它們是根據用戶的請求或依賴任務生成的資源來解析的。

支持的任務列表

模型選擇

HuggingGPT 繼續將任務與模型進行匹配的任務，即為解析的任務列表中的每個任務選擇最合適的模型。作者使用模型描述作為連接每個模型的語言接口，從 ML 社區（例如 Hugging Face）收集專家模型的描述，然后采用動態上下文任務模型分配機制來為任務選擇模型。

模型選擇階段的提示詞如下圖所示，將模型選擇制定為單選問題，其中可用模型在給定上下文中作為選項呈現。由于最大上下文長度的限制，提示詞中無法包含所有相關模型的信息。為了緩解這個問題，作者首先根據任務類型過濾模型，然后根據 Hugging Face 上的下載量對模型進行排名，選擇前 K 個模型作為候選模型。

任務執行

HuggingGPT 會自動將任務參數輸入到模型中，執行這些模型以獲得推理結果，然后將其發送回 LLM。

由于先決任務的輸出是動態生成的，HuggingGPT 還需要在啟動任務之前動態指定任務的依賴資源。因此，任務執行階段的重點是建立具有資源依賴性的任務之間的連接。

作者使用了一個唯一符號“”來維護資源依賴性。具體來說，HuggingGPT 將先決任務生成的資源標識為 -task_id，其中 task_id 是先決任務的 id。在任務規劃階段，如果某些任務依賴于先前執行的任務的輸出（例如，task_id），HuggingGPT 會將此符號（即 -task_id）設置為參數中相應的資源子字段。然后在任務執行階段，HuggingGPT 動態地用先決任務生成的資源替換該符號。

其余沒有任何資源依賴的任務直接并行執行，進一步提高推理效率。也就是說，如果多個任務滿足先決條件依賴關系，則可以同時執行多個任務。

響應生成

HuggingGPT 在本階段將前三個階段（任務規劃、模型選擇和任務執行）的所有信息整合為一個簡潔的摘要，包括規劃的任務列表、任務選擇的模型以及模型的推理結果。

其中最重要的是推理結果，這是HuggingGPT做出最終決策的關鍵點。HuggingGPT 允許LLM接收結構化的推理結果作為輸入，并以友好的人類語言形式生成響應。此外，LLM 不是簡單地匯總結果，而是生成積極響應用戶請求的響應，從而提供具有置信度的可靠決策。

實驗

采用 GPT 模型的 gpt-3.5-turbo、text-davinci-003 和 gpt-4 變體作為主要 LLM，可通過 OpenAI API 公開訪問，set the decoding temperature to 0，set the logit_bias to 0.2 on the format constraints (e.g., “{” and “}”)。

定性分析

下圖中，用戶的請求包括三個任務：檢測示例圖像中人的姿勢，根據該姿勢和指定文本生成新圖像，以及創建描述該圖像的語音。 HuggingGPT 將這些任務解析為六個任務，包括姿勢檢測、基于姿勢的文生圖、目標檢測、圖像分類、圖像字幕和TTS。可以觀察到 HuggingGPT 可以正確編排任務之間的執行順序和資源依賴關系。例如，基于姿勢的文生圖任務必須遵循姿勢檢測并使用其輸出作為輸入。之后，HuggingGPT 為每個任務選擇合適的模型，并將模型執行的結果綜合為最終響應。

定量分析

任務規劃在整個工作流程中起著至關重要的作用，因為它決定了后續流程中將執行哪些任務。因此，我們認為任務規劃的質量可以用來衡量LLM作為HuggingGPT控制器的能力。

作者通過僅考慮任務類型來簡化評估，不考慮其關聯的參數。為了更好地對任務規劃進行評估，作者將任務分為三個不同的類別并為它們制定不同的指標：

1. 單任務：僅涉及一項任務的請求。當且僅當任務名稱和預測標簽完全相同時，才認為計劃是正確的。在這種情況下使用 F1 和準確性作為評估指標。
2. 順序任務：用戶的請求可以分解為多個子任務的序列。在這種情況下采用 F1 和歸一化編輯距離作為評估指標。
3. 圖任務：用戶請求可以分解為有向無環圖。圖任務中可能存在多種規劃拓撲，僅依靠F1分數不足以反映LLM在規劃方面的能力。為了解決這個問題，作者采用 GPT-4 作為批評者來評估規劃的正確性。準確率是通過評估GPT-4的判斷力得到的，簡稱GPT-4 Score。

數據集

作者創建兩個數據集用于評估任務規劃，收集了 3497 個不同的用戶請求

1. 邀請一些標注者提交一些用戶請求作為評估數據集，用 GPT-4 生成任務規劃作為偽標簽，涵蓋單任務（1450個）、順序任務（1917個）和圖任務（130個）。
2. 邀請一些專家標注者將一些復雜請求（46 個示例，24個順序任務+22個圖任務）的任務規劃標記為高質量的人工注釋數據集。

性能

單任務評估結果：

順序任務評估結果：

圖任務評估結果：

復雜任務評估結果：

消融實驗

任務規劃階段，提示詞中不同任務示例的多樣性對結果的影響。多樣性指的是提示詞中涉及的不同任務類型的數量。增加示例的多樣性可以適度提高LLM在任務規劃方面的表現。

提示詞中不同任務示例的數量對結果的影響。添加一些示例可以稍微提高模型性能，但當示例數量超過 4 個時，這種改進將受到限制。

人工評測

作者收集了 130 個不同的請求來評估 HuggingGPT 在各個階段的性能，包括任務規劃、模型選擇和最終響應生成，設計了三個評價指標，即通過率、合理性、成功率。

限制

一些限制或改進空間：

1. HuggingGPT 中的規劃很大程度上依賴于 LLM 的能力，而我們無法確保生成的計劃始終可行且最優。因此，探索優化LLM的途徑，提升其規劃能力至關重要；
2. 效率是一個最大的挑戰，要構建這樣一個具有任務自動化功能的協作系統（即 HuggingGPT），它在很大程度上依賴于強大的控制器（例如 ChatGPT）。然而，HuggingGPT 在整個工作流程中需要與LLM進行多次交互，從而增加了生成響應的時間成本；
3. 令牌長度是使用 LLM 時的另一個常見問題，因為最大令牌長度始終受到限制，如何簡潔有效地總結模型描述也是值得探索的；
4. 不穩定主要是因為LLM通常不可控，在推理過程中可能不符合指令或給出錯誤答案，從而導致程序工作流程出現異常。在設計系統時應該考慮如何減少推理過程中的這些不確定性。

---

速覽筆記

Motivation

作者為什么做這件事？之前存在什么問題？

AI模型很多，但是大部分都是領域專家模型，沒有一個控制器將它們都聯合起來。

ChatGPT出來之后，展現出了強大的理解和推理能力，正好可以作為一個復雜AI系統的大腦。

Novelty

1. 創建點在哪里？為什么要提出來這個？要解決什么問題？

創新點包括：將ChatGPT作為控制器和規劃器，解構復雜的任務，調用HuggingFace上的模型完成子任務，最后再匯總。

其實它也解決LLM只是一個純語言模型，不能聽、說和看的問題。

1. 怎么才能想出來這個創新點？想問題的思路是什么？

推測作者的想法

站在當時的情境下，ChatGPT爆火，隨之而來的就是AGI和Agent的概念。當時也有一些項目，像是AutoGPT、AgentGPT和BabyAGI等等，都是非常新的東西。

但是更多處理的還是文本這一個模態的信息，并不能處理其它像語音、圖像和音頻等模態的信息。

而GPT-4當時應該是還沒有開放視覺能力，如果想要讓ChatGPT擁有多模態的處理能力，就只能借助其它的模型，也就是HuggingFace上的模型。這些模型為了能夠跟ChatGPT進行交互，也只能把輸入輸出都轉換為文本的形式，這樣就能搭建起一個以文本為媒介，ChatGPT為大腦的AI系統。

1. 怎么就能發這個會議或者這個期刊的？

站在審稿人的角度看論文

一方面AGI和Agent這兩點結合的很好，另外一方面，我覺得最重要的是，它提供了一種以文本為媒介的多模態處理方式，還不需要訓練一個多模態模型。

Methods

對照代碼，整理模型整體結構，分析每個模塊的作用以及對性能的提升貢獻（重點，呼應實驗），找到核心模塊（提點最多），以及判斷跟創新點是否匹配

Experiments

訓練集和測試集

用的哪個數據集，規模多少，評價指標是什么

作者自己創建兩個數據集用于評估任務規劃，收集了 3497 個不同的用戶請求

1. 邀請一些標注者提交一些用戶請求作為評估數據集，用 GPT-4 生成任務規劃作為偽標簽，涵蓋單任務（1450個）、順序任務（1917個）和圖任務（130個）。
2. 邀請一些專家標注者將一些復雜請求（46 個示例，24個順序任務+22個圖任務）的任務規劃標記為高質量的人工注釋數據集。

性能如何，好不好復現，是否有Code/Blog/知乎討論

代碼開源，但是數據集不開源，嘗試一下demo可以，復現實驗結果不太好弄。

浙大與微軟發布的 HuggingGPT 在線演示驚艷亮相，可完成多模態復雜任務，將帶來哪些影響？ - 知乎

HuggingGPT - 知乎

浙大與微軟發布的 HuggingGPT 在線演示驚艷亮相，可完成多模態復雜任務，將帶來哪些影響？ - 知乎

每個實驗證明了什么

定量分析都是模型在任務規劃階段的指標。

消融實驗是為了則是評估了提示詞中示例的數量對結果的影響。

人類評估測試主要分了三個方面：通過率、合理性和成功率，我覺得最重要的事合理性。

有沒有哪些實驗沒有做

論文中只對任務規劃模塊進行了定量分析，雖然給出的理由是任務規劃模塊最重要，但是我覺得其它模塊也應該做實驗分析。

1. 任務規劃模塊，只考慮了任務類型的準確性，沒有考慮參數，而且也沒有考慮任務之間的依賴是否準確。對于順序任務和圖任務，我覺得順序也是一個非常重要的因素；
2. 模型選擇這一塊，選擇模型的準確性也需要評估。例如TTS任務，用戶請求是合成的是中文，它會不會選擇一個通用的TTS模型然后合成了英文輸出；
3. 任務執行這一塊倒是沒有什么實驗可以做；
4. 響應生成這一塊，是邀請了人類專家做的評判，但是這一塊我覺得有些評測可以自動化，比如統計圖片中有多少只狗，這個在一些目標檢測的數據集中應該是有標簽的，可以自動評測。

Downsides

哪些提出的模塊是有問題的

好像也沒有什么問題，少一個模塊都不大行。

哪些提出的點對性能提升存疑

暫無。

有沒有能改進的地方

論文中提出的未來改進方向：

1. we plan to improve the quality and quantity of this dataset to further assist in evaluating the LLM’s planning capabilities.
2. we believe that developing technologies to improve the ability of LLMs in task planning is very important, and we leave it as a future research direction.
3. In the future, we will continue to explore more elements that can improve the capability of LLMs at different stages.
4. we think that how to design and deploy systems with better stability for HuggingGPT or other autonomous agents will be very important in the future.

增加反饋機制，如果有哪個流程出現了問題，可以通過ChatGPT進行檢查并反饋。

Thinking

能否遷移應用？（業務應用方向、模型改進、數據生產組織等方面）

超級縫合怪，牛逼o(￣▽￣)ｄ。

不一定要訓練多模態大模型，借助現有的各種領域專家模型也可以。

---