コロンビア大学の博士課程で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本の論文を実装した最大の学びは、個々の手法がまったく別々のアルゴリズムなのではなく、少数の基本パターンを異なる形で組み合わせたものだということでした。
実装はこちらで公開しています。