CMU副教授：在多智慧體流行的當下，不要忽視單智慧體系統
机器之心發表於2024-10-10
最近，「多智慧體系統」是人工智慧領域最熱門的流行詞之一，也是開源框架 MetaGPT 、 Autogen 等研究的焦點。近日，來自卡內基梅隆大學的副教授 Graham Neubig 在文章《Don't Sleep on Single-agent Systems》中強調了單智慧體系統也不可忽視。- 當代 AI 智慧體發展的元素，包括大語言模型、提示以及動作空間；
- 如何從使用多個專門的智慧體過渡到一個強大的智慧體，以及一些需要解決的問題。
CMU 機器學習和計算機系助理教授陳天奇對這項研究進行了轉發並評論：「這是一篇關於如何讓單智慧體系統更強大的深刻見解，對機器學習系統也有很好的啟示。提示字首快取將成為與其他一般推理最佳化技術相互作用的一項關鍵技術」。大多數智慧體都是基於大語言模型構建的，如 Anthropic 的 Claude 或 OpenAI 的語言模型。但語言模型不足以構建一個出色的智慧體，構建一個智慧體至少需要三個元件：- 提示：可以是用於指定模型一般行為的系統提示，或者從智慧體周圍環境中提取的資訊型別；
- 動作空間：上述兩項是研究者提供給 LLM 的輔助工具，以便智慧體在真實世界中產生動作。
一般來說，當涉及多智慧體系統時，至少要改變這三個組成部分中的其中一個。假設你正在構建一名 AI 軟體開發助手，這裡作者以 CodeR 為例，這是一個用於 AI 軟體開發的多智慧體框架。它包括多個智慧體，所有智慧體都使用相同的底層 LM，但提示和動作空間各不相同：- 管理器（Manager）：該智慧體的提示指定它應該為其他智慧體編寫一個規劃來執行，以及輸出規劃的動作空間；
- 復現器（reproducer）：該智慧體有一個提示，告訴它重現該問題，以及一個將程式碼寫入重現錯誤檔案 reduce.py 的動作空間；
- 故障定位器（Fault Localizer）：該智慧體有一個提示，告訴它找到導致錯誤的檔案，以及一個使用軟體工程工具進行故障定位和列出檔案以供以後使用的動作空間；
- 編輯器（Editor）：該智慧體有一個提示，用於接收復現器和故障定位器的結果，並有一個動作空間，允許它對檔案進行編輯；
- 驗證器（Verifier）：此智慧體具有提示，可接收其他智慧體的結果，以及輸出問題是否已解決的動作空間。
這是構建一個系統時所需要的結構，但是在構建這樣的系統時存在一些困難。在構建多智慧體系統時，你可能會遇到許多問題，比如：獲得正確的結構：多智慧體系統透過新增結構來解決問題。當智慧體面臨的問題與指定的結構完全匹配時，效果會很好，但問題是如果不匹配怎麼辦？上下文資訊的傳遞：多智慧體系統通常在多個智慧體之間傳遞資訊，但這可能是資訊丟失的原因。例如，如果故障定位器僅將其摘要資訊傳遞給其他智慧體，則通常會導致重要的上下文資訊丟失，而這些資訊可能對下游智慧體有用。可維護性：最後，這些智慧體通常都有自己獨立的程式碼庫，或者至少有獨立的提示。因此，多智慧體系統可能擁有更大、更復雜的程式碼庫。有趣的是，很多這些挑戰也適用於人類組織！我們都有過這樣的經歷：團隊組織混亂，溝通不暢，或者當某個成員離開時，無法維持必要的技能。人們為什麼要打造多智慧體系統？一個需要說明的重要原因是：專用於特定任務的智慧體的表現通常很好，只要有合適的結構和工具，它們就能很好地完成相應的任務。可能比我們預想的還更容易一些，作者表示這裡已經有一個很好的原型：https://github.com/All-Hands-AI/OpenHands/tree/main/agenthub/codeact_agent下面我們就來看看，要打造出優秀的單 LLM、單動作空間和單提示工程技術，需要些什麼。單 LLM：這是相對比較容易的部分。近段時間已經出現了一些表現出色的通用 LLM，包括 Claude 和 GPT-4o 等閉源模型以及 Llama 和 Qwen 等開源模型。雖說這些模型也不是萬能的，但它們也確實能完成多種多樣的任務。就算它們缺乏某個功能，也可以透過持續訓練來增添，同時不會對其它功能產生太大影響。單動作空間：這也不難。如果我們有多個使用不同工具的智慧體，那麼我們可以 (1) 為模型提供相對通用的工具，以幫助它們解決問題；(2) 如果不同的智慧體有不同的工具組合，則可以將他們連線起來。比如，在 OpenHands 中，可以向智慧體提供寫程式碼、執行程式碼和執行網路瀏覽的工具。這樣的通用方法可讓模型使用為人類開發者開發的軟體工具，從而增多它們的功能，做到其它多智慧體能做到的事。單提示工程技術：這是比較困難的地方！我們需要確保智慧體在如何解決任務上獲得正確的指示，同時從其環境中獲得正確的資訊。- 將所有提示詞連線起來使用：如果我們有一個多智慧體系統，要使用 10 個不同的提示詞，那麼為什麼不將它們連線組合到一起呢？近期的長下文模型已經有能力處理多達幾十萬 token 了，比如 Cluade 能處理 20 萬 token，而 Llama 是 12.8 萬。OpenHands 也使用了此方法。但這種方法也有一些缺點。首先是成本，更長的提示詞需要更多金錢和時間，不過現在有一些技術（比如 Anthropic 的提示詞快取技術）可以降低其成本。這種方法的另一個缺點是，如果提示詞太多，則 LLM 可能無法關注到重點，但隨著模型能力提升，LLM 在確定長上下文中的重要資訊方面越來越強了。
- 檢索增強式提示：另一種可能的選擇是使用檢索。如同檢索增強式生成（RAG）系統一樣，可以出於效率或準確度的目的對長上下文進行裁剪。在選擇提供 LLM 的示例方面，這裡有一些研究進展：https://arxiv.org/abs/2209.11755
本文並不是說多智慧體就沒有用武之地了。比如在一個智慧體可以訪問專有資訊，而另一個智慧體則代表了另一個人的情況下，多智慧體系統肯定大有作為！本文的目的是批判性地思考讓系統更加複雜這一趨勢。有時候簡單就是最好的 —— 有強大的模型、強大的工具和多種多樣的提示詞就足夠了。參考連結：https://www.all-hands.dev/blog/dont-sleep-on-single-agent-systems