三個Agent頂個GPT-4,基於開源小模型的那種|中大阿里聯合出品
真·“三個臭皮匠,頂個諸葛亮”——
基於開源小模型的三個Agent協作,比肩GPT-4的工具調用效果!
話不多說,直接來看兩個系統執行記錄。
用戶表示自己是一個音樂愛好者,想探索不同的音樂流派以及音樂家。他在指令中指定模型使用Deezer和Shazam的API來搜尋一些音樂曲目以及相應藝術家信息。
之後飾演三個不同的角色的Agent分工協作,在兩步之內完成了任務。
更難一點的,不指定工具,讓模型找一個最受歡迎的風景畫教程視頻以及上傳該視頻的頻道詳情。
在這種情況下,模型通常會遇到工具狀態變化、出現工具被下架或工具所需參數定義變化的問題。
然而使用上述方法,模型在第0步試圖使用video_for_simple_youtube_search來獲取視頻詳細信息,但發現這個API已經被破壞,無法調用。
因此飾演planner角色的Agent轉換思路,告訴飾演caller角色的Agent需要嘗試另外一個API,並最終通過嘗試新的API發現了詳細信息,解決了用戶的任務。
這就是中山大學、阿里通義實驗室聯合提出的一種基於開源小模型的多模型協作Agent框架——α-UMi。
α-UMi通過微調多個開源小模型,實現協同作戰,在工具調用等數據集效果比肩GPT-4。
總的來說,相比於其他的基於閉源API框架,α-UMi的優勢有以下幾點:
目前,基於大模型調用API、function和代碼解釋器的工具學習Agent,例如OpenAI code interpretor、AutoGPT等項目,在工業界和學術界均引起了廣泛關注。
在外部工具的加持下,大模型能夠自主完成例如網頁瀏覽、數據分析、地址導航等更復雜的任務,因此AI Agent也被譽爲大模型落地的一個重要方向。
但上述一些主流項目主要基於閉源ChatGPT、GPT-4大模型,其本身在推理、步驟規劃、調用請求生成和總結回覆等能力上已經足夠強。
相比之下開源小模型,由於模型容量和預訓練能力獲取的限制,單個模型無法在推理和規劃、工具調用、回覆生成等任務上同時獲得比肩大模型等性能。
爲了解決這一問題,本文研究人員提出了α-UMi。
α-UMi包含三個小模型planner、caller和summarizer。
其中planner模型爲系統的核心大腦,負責在某一Agent執行步驟內激活caller或summarizer,並給予對應的推理(rationale)指導;
而caller和summarizer則分別負責接收planner的指導完成該步後續工作,caller負責生成於工具交互的指令,summarizer負責總結最終的回覆反饋給用戶。
這三個模型都是基於開源小模型進行不同類型數據微調實現的。
此外,研究人員提出了全局-局部多階段微調範式——GLPFT。
基於開源小模型,實現多模型協作框架並非一件簡單的事,有兩個作用截然相反的影響因素:
一是生成Rationale,Action和Final Answer三個任務在訓練中可以相互促進的,同時也能增強模型對於Agent任務的全局理解。因此目前大部分工作均訓練單個模型同時生成rationale, action和final answer。
二是模型容量,不同任務的數據配比等也限制了我們很難訓練單個模型同時在三個任務上獲得表現峰值。
下圖中,單模型Agent在各項指標上達到峰值所需的數據量是不同的,很難找到一個在所有指標上達到峰值的數據量和模型檢查點。
而通過多模型協作,可以解決這個問題。
綜合考慮上述兩點,研究人員提出了一種“全局-局部”的多階段訓練方法,目標在於利用充分利用Rationale,Action和Final Answer在訓練中相互促進的優勢,獲得一個較好的單模型初始化,再進行多模型微調,專攻子任務性能的提升。
上圖展示了這種多階段微調的流程,在第一階段中,使用預訓練LLM在完成工具調用Agent任務上微調,獲得一個單模型的Agent LLM初始化。
接着,在第二階段中,研究人員對工具調用Agent任務的訓練數據進行重構,分解成生成rationale,生成工具交互action和生成最終回覆三個子任務,並將第一階段訓練好的Single-LLM Agent底座複製三份,分別在不同子任務上進一步微調。
靜態評估
在靜態評估中,本文將所有對比baseline的輸出結果與標註輸出進行對比,可以看到:
值得一提的是,ToolLLaMA需要8192的輸出長度以獲得令人滿意的結果,而α-UMi只需要4096的輸入長度,得益於多模型框架帶來的更靈活的prompt設計。
真實API調用評估
作者也在ToolBench數據集上引入了一種真實API調用的評估方式,實驗結果如下:
在真實API調用實驗結果中,α-UMi 依然戰勝了ChatGPT和ToolLLaMA,並在成功率上取得了與GPT-4比肩的結果。
模型開銷
看到這可能有人問了,多模型協作會不會引入更多成本?作者也探究了多模型協作框架在訓練、推理及儲存階段的開銷對比:
總體來說,多模型協作框架確實會在訓練和模型參數儲存上引入更高的開銷,但其推理速度與單模型框架相當。
當然,考慮到多模型協作Agent框架使用7B底座的性能遠超13B單模型Agent性能,總開銷也更少。這意味着可以選擇小模型爲底座的多模型協作Agent框架來降低開銷,並超過大模型的單模型Agent框架。
最後研究人員總結道,多智能體協作是未來智能體發展的趨勢,而如何訓練提升開源小模型的多智能體協作能力,是實際落地很關鍵的一環,本文爲基於開源小模型的多智能體協作打開了新思路,並在多個工具調用benchmark上取得了超過單模型Agent baseline,比肩GPT-4的工具調用結果。
後續將會增強planner的泛化性,使其使用於更廣泛的Agent任務場景,進行caller模型的本地私有化,使其專注於本地工具調用任務,以及雲端大模型結合本地小模型的“大-小”模型協同框架。
項目鏈接:[1]https://arxiv.org/abs/2401.07324[2]https://github.com/X-PLUG/Multi-LLM-agent[3]https://modelscope.cn/models/iic/alpha-umi-planner-7b/summary