LLM的多代理架構(multi-agent system)是否真實可行? 從GenAI實習生的視角出發
multi-agent是否過於不可靠? 或者LLM他就只能夠達成他「擅長」的任務呢
(以下文摘自於threads)
那些拿LLM當agent來用的人後來都發生什麼事了？ LLM很容易卡在一個它們無法解決的問題上面，想出一大堆沒有用的解法，永遠無法停止，拿來當agent會陷入無窮迴圈現在的LLM只擅長做LLM擅長的事情，例如語言翻譯和summary。
我的貼文內容：
TLDR: 在有限的選擇和適當的引領下，LLM agent還是相當有效的策略，我不認為LLM agent是不可行的解決方案。 另外，隨者技術發展，我們設置的限制和條件可以慢慢鬆綁，讓其更有彈性、更有機會emerge出新的features。 — 簡單來說，LLM agent就是讓大語言模型有自己規劃、解決複雜問題的能力，讓LLM的行為和人的行為相近。LLM可以使用自身的能力，或是外界給予的工具，達成複雜的工作。舉例來說，如果請真人做台灣近十年GDP成長率的視覺化圖表，那麼第一件事情就會是到網路上找資源，找到好的資料之後，就去開python或excel把這些資料轉換成圖表，審視結果後輸出。我們希望LLM agent做的，就是當我詢問「請幫我畫出近十年台灣GDP成長率折線圖」時，做到我剛剛說的那些事情：先請LLM想好他應該怎麼做，再一步一步達成，這就是plan and execute的概念但是就算LLM agent的plan-and-execute性能再好，還是會遇到很多阻礙，例如他在網路上找不到足夠好的資料，或者它一直無法畫出圖，這時候LLM就無法產出令人滿意的答案。
這時候要怎麼解決呢? 有許多可以嘗試的方法。 第一個通用的方法就是增加時間/自我對話次數限制，舉例來說，如果1分鐘內(或10次自我交談、規劃內) 沒有辦法得到令LLM滿意的結論，就直接把半成品整理後輸出，或者回答我不知道。(補充：LLM可以自己決定要怎麼規劃和執行功能，也可以自己決定自己的結果是否已經足夠滿足用戶的需求。)第二種是增加額外的自省機制，可以想像成LLM定時額外做一次自我反思的動作(可以是同一個大腦，也可以請其他大腦來檢視)，如果兩次的思考內容間沒有顯著的成長的話，就將半成品輸出或回答我不知道。自省機制最簡單的方式就是額外下prompt，把目前思考的階段丟給LLM，問他說目前這些結果是否符合用戶的需求，然後回答yes or no，針對結果走不同的道路。第三種叫做human-in-the-loop，簡單來說就是讓人加入LLM思考的過程中，指引LLM方向，舉例來說，當LLM需要到網路上撈資料時，為了避免他撈到的資料都是依託答辯，我們可以在LLM撈完資料之後檢視內容是否符合人們的需求，符合的話就繼續讓LLM思考，不行的話就請他重撈一次，或者給他正確的內容或方向，或者放棄。
第四種方案(嗎?)是用langgraph之類的方式來限制LLM思考的workflow，對我來說就是把plan and execute的能力從填充題限縮為選擇題。前面的例子都是我假設LLM他本身又會自己查資料又會執行code又會做一大堆五花八門的事情，但是如果沒有進行指示的話，就會淪落到梧鼠五技而窮的局面。(我覺得我應該在前面先講langgraph的，我前面打的內容已經是基於langgraph架構來寫的了，現在才提到有點怪)ok，舉例來說，前述的問題有很大一部分是我們授權給LLM的權限太大了，它可以做很多的事情，但是可能每一件都做不好。但是如果我們可以採用多代理(multi-agent)的架構來共同合作輸出的話，或許會好一點(但是實際操作上還是有困難但我懶得展開)我可以假設有兩個agent來共同協作，其中一個agent他只會網路搜尋資料，另外一個agent他只會寫code(和使用code executor確定這個code能不能跑)，這樣的話，當一個問題進來時，搜尋網路資料的agent A可以做三件事情：
- 覺得目前資料還不OK，整理好要google search的內容並且進行網路搜尋
- 覺得目前資料已經OK了，所以我把目前有的東西都丟給agent B(負責寫code的那位仁兄)
- 覺得現在的final output已經完全OK/完全不OK了，輸出最終結果(要馬有完整答案，要馬回答我不知道)
如果每次agent得到結果並整理完後，都只有這三條路能夠選擇，那麼我們就【比較能】預期這整體架構未來的行為，並且【比較可以】預期這些agent的單體能力有所加強(因為這些agent可以專心做他們擅長的任務，而決策過程較為簡單)雖然實際上，要在上述1,2,3中選一個最適合的來做，也可能會遇到無窮迴圈或不可控制等問題，但配合剛剛提到的前三招，以及合適的prompt與工具描述，我們可以盡可能地增強LLM system的可靠度。最後扣回對LLM的基本認知：我可以合理預期目前agent的基本問題可以在不久的將來解決，不管是算力更強的model，或者是更適合agent架構的architecture，都可以為我們自己的系統增添能力，到時候我們可以做出更簡單的架構，讓LLM本身發揮更強大的能力
另外，我們所追求的RAG系統不再是「只能找出參考資料，並且看者參考資料回答」，而是追求「得到這些參考資料以及參考資料的小抄」(GraphRAG)、增強參考資料的有用程度(advance rag)，取得更正確的參考資料內容(multi-ways retrieve/recall)，還有得到這些參考資料之後，LLM會怎麼運用這些資料，得到更讓使用者信服的回答，所以藉由來進行tool calling / (plan and execute)仍然是重要的一環，舉例來說，我可以合理的預期LLM可以幫我算我目前的房貸規劃，這樣除了要去用RAG的資料取得相關的規範文件外，我也希望可以去網路上找最新發布的新聞or目前現行的房貸利率，並且用python的code-execution(如計算工具numpy、生成計算時間間距的datetime，還有更多)，幫我整合出專屬於我的房貸規劃。這是我目前在處理的事情，也期待有穩定的結果出來後可以和其他大老交流。
補充：
如何讓 RAG 從無用的搜索系統 -> 通用研究助手 — Llamaindex 創始人 Jerry Liu ＆新架構是否能完成 equity research任務（思考實驗）？RAG ( Retrieval-Augmented Generatio）現狀：
a.原先想讓LLM 減少幻覺，具備內部知識的智能助理
b. 目前只是美化的搜索系統，只能回答簡單問題
c. 不具備深度的上下文理解、推論能力
未來方向：
a. 具備更強的上下文理解能力，處理解決更複雜問題
b. 具備推理、決策能力，在變化的環境自主使用工具回答準確答案（Agent）
c. 多模態及個性化：整合各種數據來源（文字、圖片、影音…），並根據用戶進行調整
3. 利用多個Agen解決小任務，完成複雜任務
a. 仿照軟體開發微服務( microservice）模式，有數個agent分別完成任務（自然語言 or 數據分析等）
b. orchestration 模塊接收任務，利用message queue分發任務到不同agent
朋友，以上討論只是中上Answer<-->LLM討論中的一小部分。祝順!