コロンビア大学の博士課程で AI・セキュリティの研究をしている Koukyosyumei です。
最近暇なので、マルチエージェント LLM に関する 40 本の論文で提案されているワークフローを再実装してみました。論文で報告されているベンチマーク結果を再現するというよりは、それぞれの手法が、どのようなループを持ち、どのような役割分担を行い、どのようなルールで複数の出力を統合するのかを理解することを目的として再現実装を行い、いろいろな学びがあったので、この記事で共有したいと思います。
結局全部、「ループ構造・プロンプト設計・集約ルール」で説明可能
多くのマルチエージェント手法は、突き詰めると次の 3 つの組み合わせです。
- どのような形で処理を繰り返すか
- 各エージェントにどのような指示を与えるか
- 複数の出力をどのように統合するか
h5i-python という、マルチエージェントのワークフローを Python で定義・実行できるフレームワークを使った実装では、ほぼすべての論文のコアアルゴリズムを 100 行前後で実装できてしまいました。
# コード例
from h5i.orchestra import Conductor
async def main(task):
async with Conductor(repo=".", run="demo-task", launcher="resident") as c:
claude = await c.hire("claude-agent", runtime="claude")
codex = await c.hire("codex-agent", runtime="codex")
# Have both agents implement the task independently and in parallel
claude_work, codex_work = await asyncio.gather(claude.work(task), codex.work(task))
await c.freeze() # Seal the round, ensuring that neither agent influenced the other beforehand
# Have each agent review the other's work
await asyncio.gather(codex.review(claude_work), claude.review(codex_work))
# Verify each submission in a fresh, neutral sandbox
await c.verify(claude_work, ["pytest", "--quiet"])
await c.verify(codex_work, ["pytest", "--quiet"])
verdict = await c.judge() # Select the smallest diff among the submissions that pass all tests
print("winner:", verdict.selected_submission)
asyncio.run(main("implement quicksort in python with unit test"))獨立性是容易被忽略但很重要的要求
Self-Consistency、CodeT、CoVe 之類的方法，隱含前提是多個樣本彼此看不到對方的輸出。也就是說，每個推理或回答都必須獨立生成。
但是，在所有代理都共享同一個對話上下文的框架中，這種獨立性可能會不小心被破壞。當某個樣本的輸出可以被其他樣本參照時，那就不再是獨立產生想法的多代理系統了。h5i-python 讓每個代理在隔離的沙盒中工作，並且只在被允許時才進行通訊，因此較容易實作並確保這種獨立性。
改善迴圈，大致上都一樣
Self-Refine、Reflexion、CRITIC、Self-Debug、Constitutional AI 等等，近年有許多論文提出會自我改善輸出的手法。不過，基本結構幾乎都相同。
- 先生成初始回答或成果物
- 取得某種回饋
- 用回饋改善成果物
- 視需要重複
不同方法的主要差異，在於回饋從哪裡取得：
- 另一個批評代理
- 自我反思
- 外部工具的執行結果
- 自己重新讀取程式碼後的結果
- 明文化的原則或憲法
如果把回饋當作獨立的一級物件來處理，這些方法幾乎都可以實作成同一個函式，只是把「回饋的產生方式」當成參數傳入。
集約規則大約只有 10 行，但本質就在這裡
將多個候選答案或代理的判斷整合起來的規則，多半只要 10 行左右就能實作，但我覺得這一部分常常正是論文新意的核心。
- 多數決
- 依信心度加權投票
- 多個評分者的平均分數
- 計算同意票
- 一對一比較的勝場數
辯論方法的本質是「讓誰看見什麼」
讓多個代理進行辯論的方法也很受歡迎，但歸根究柢，關鍵全在於「誰能看到誰的訊息」這條規則。
- 每個人都能看到所有發言的匯流排型
- 經由中央代理傳遞的星型
- 只有相鄰代理能通訊的環型
- 以階層方式傳遞資訊的樹型
再加上停止條件與投票規則，就能表達辯論方法設計空間的大部分。
結論：40 本論文大致可分為 8 種系統
實作完 40 本之後，我覺得這些方法大致可以分成以下 8 種類型。
- 改善迴圈
- 多樣本生成與投票
- 辯論
- 多評審判定
- 多輸出融合
- 先探索再確定最終方案的方法
- 軟體開發與長文生成中的分階段管線
- 動態團隊編成與管理
如果把這 8 類實作出來，並將角色、通訊結構、回饋來源、投票方法等參數化，就能涵蓋相當大範圍的多代理 LLM 研究。實作這 40 本論文最大的收穫，是我發現個別方法並不是完全不同的演算法，而是少數基本模式用不同方式組合而成。
實作內容已公開在這裡。
原文出處：https://qiita.com/Koukyosyumei/items/e9ee8e26cfdc40a8c2f9
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
