今回の論文
今回取り上げるのは、Junlin Wang、Jue Wang、Ben Athiwaratkun、Ce Zhang、James Zou による論文「Mixture-of-Agents Enhances Large Language Model Capabilities」です。2024年6月7日に arXiv で公開されたプレプリントで、公開元は arXiv、研究分野は LLM の推論設計、マルチエージェント協調、モデルアグリゲーションです。URL は https://arxiv.org/abs/2406.04692 です。
この論文を選んだ理由は、モデルを再学習せずに、既存の複数 LLM をどう組み合わせれば回答品質を底上げできるかをかなり実装寄りに示しているからです。RAG、AI エージェント、社内アシスタント、開発支援のどれにも応用しやすく、「複数モデルをつなぐだけで何が改善するのか」を考える材料になります。
どんな技術か
Mixture-of-Agents は、複数の LLM を並べて使うだけではなく、あるモデルの回答を別のモデルに読ませて段階的に統合する推論方式です。
たとえば、最初の層で複数のモデルに同じ質問へ別々に答えさせます。次の層では、それらの回答をまとめて別のモデルに渡し、「この中身を吟味しながら、より良い1つの回答を作ってください」と依頼します。これをさらに何段か繰り返し、最終的に1つの高品質な回答へまとめます。
ポイントは、単に多数決をするのではなく、提案する役と統合する役を分けていることです。論文では、前者を proposer、後者を aggregator と呼んでいます。異なるモデルの得意分野を持ち寄り、その上で別のモデルに批判的に統合させることで、単体モデルでは取りこぼす観点を拾いやすくする狙いがあります。
課題
この技術が解決しようとしている課題は、単一の LLM にすべてを任せると、どうしても回答の視点や得意分野が偏りやすいことです。
何が難しいのかというと、LLM は大きくても万能ではないからです。あるモデルは指示追従が強く、別のモデルはコードや論理整合性が強い、といった差があります。ところが実際のプロダクトでは、通常は1つのモデルに1回問い合わせて終わりにしてしまうため、そのモデルの癖や見落としがそのまま最終出力になります。
既存の方法にも限界があります。たとえば best-of-N のように同じモデルから複数候補を出して選ぶ方法は、同一モデルの多様性には期待できますが、モデル間の補完関係までは使い切れません。逆に、単純に複数モデルの回答を並べるだけでは、結局どれを採用するかを人や別ロジックが判断しなければならず、自動化しづらいです。
なぜこの課題を解く必要があるのかというと、実際の AI システムでは「そこそこ正しい」だけでなく、「抜け漏れが少なく、説明としてまとまっている」ことが重要だからです。社内ナレッジ検索、提案文生成、調査エージェント、コード支援のような用途では、単発回答の弱点がそのままユーザー体験に響きます。
とくにエージェント型システムでは、最初の認識違いが後続のツール実行や計画全体を崩すことがあります。そのため、最終回答の前に複数の視点をまとめ直す仕組みは、単なる品質改善以上に、処理の安定化にも効く可能性があります。
用語解説
- Proposer
- 最初の回答候補を出す役です。この論文では、単体で最強のモデルである必要はなく、別モデルが統合するときに役立つ観点や多様性を出せることが重要です。
- Aggregator
- 複数の候補回答を読み込み、矛盾や弱点を見ながら1つにまとめる役です。Mixture-of-Agents の性能は、この統合役が「情報を足し合わせる」だけでなく「誤りを捨てられるか」に大きく依存します。
- LC Win Rate
- AlpacaEval 2.0 で使われる Length-Controlled Win Rate です。回答の長さによる有利不利を減らし、人間の好みに近い比較をしやすくします。この論文では主要な評価指標です。
- Single Proposer / Multi Proposer
- 同じモデルを複数回サンプリングして候補を集める構成が Single Proposer、異なるモデル群を候補生成に使う構成が Multi Proposer です。多様性とコストのバランスを見るうえで重要です。
- Aggregate-and-Synthesize Prompt
- 複数モデルの出力を与えられた統合役モデルへ、「そのまま繰り返すのではなく、偏りや誤りを見抜きつつ、より良い回答を作る」よう促す統合用プロンプトです。Mixture-of-Agents は重み更新ではなく、このプロンプト設計で連携を作ります。
技術の仕組み
Mixture-of-Agents は、モデルの内部構造を変える研究ではありません。既存の LLM を推論時にどう並べるかを設計した研究です。実装上は API ベースでも再現しやすいのが特徴です。
基本アイデア
基本発想はシンプルです。1つの質問に対して複数モデルが独立に回答し、その結果を別のモデルが統合します。そして、統合結果をさらに次の層の入力にしてもう一段統合をかけます。
論文では、この繰り返しの中に LLM の「協調性」があると見ています。つまり、あるモデルは単独ではそれほど高得点でなくても、他モデルの回答を読ませると、より良い最終回答を作る助けになるという考え方です。
層構造
MoA は l 層の構造を持ち、各層に n 個のエージェントを置きます。1層目では、各エージェントが元の質問に対して独立に回答します。2層目以降では、前の層の回答群をまとめて読み込み、それを踏まえて新しい回答を生成します。
最終層だけは複数エージェントを使わず、1つの統合役だけを置けば十分です。実際の最終出力は、この最後の aggregator が返す1本の回答になります。
proposer と aggregator の役割分担
この論文の面白い点は、「よいモデル」と一括りにせず、役割を分けて考えているところです。
proposer は多様な材料を出す
proposer は、最終回答をそのまま任される役ではありません。むしろ、後段のモデルが統合しやすいように、別視点や別解法、追加根拠を出せることが価値になります。
そのため、単体性能が少し劣るモデルでも、補助情報としては有効なケースがあります。これは実務でも重要で、安いモデルを「粗い候補生成専用」に置く設計を正当化しやすくなります。
aggregator は批判的統合を担う
aggregator は、渡された回答を単純に連結するのではなく、内容を比較しながら統一された1回答へ再構成します。論文の統合プロンプトでも、「与えられた回答には誤りやバイアスがありうる」と明示し、そのまま複製せず改善するよう求めています。
この役割は、RAG で複数文書から答えをまとめる処理や、エージェントで複数ツール結果を統合する処理にかなり近いです。MoA の本質は、複数情報源の間にもう1段の推論を挟むことだと言えます。
学習は不要で、推論オーケストレーションで実現する
論文の大きな利点は、追加学習を前提にしていないことです。各モデルの重みを変更せず、プロンプトと呼び出し順だけで構成されています。
つまり、必要なのは以下のような推論フローです。
処理の流れ
- ユーザー入力を1層目の複数 LLM に配る
- 各 LLM が独立に候補回答を返す
- それらを一覧化して aggregator に渡す
- aggregator が候補を比較し、より高品質な中間回答を作る
- 必要なら、その中間回答群を次層へ回して再統合する
- 最終層の出力を最終回答として返す
この構造は、Mixture-of-Experts の「複数の専門家を組み合わせる」という考え方に似ています。ただし MoE が1つのモデル内部で活性化を分岐させるのに対し、MoA はモデル単位で専門家を並べるのが違いです。
single proposer と multi proposer
論文では、同じモデルを複数回サンプリングする single proposer と、異なるモデルを並べる multi proposer を比較しています。
single proposer は実装が単純で、同じ API だけで回せます。一方で、出力の多様性は温度サンプリング頼みになります。multi proposer はモデルごとの視点差を取り込みやすい反面、コスト管理や運用構成は複雑になります。
この比較は、実務上かなり重要です。最初から多数の外部モデルを組み合わせなくても、単一モデルの多段サンプリングと統合でどこまで近づけるかを考える材料になるからです。
重要な工夫
論文全体で重要なのは、単なる「多モデル化」ではなく、以下の3点です。
1. 出力を次のモデルの思考材料にする
候補の中から選ぶだけではなく、候補そのものを次の推論の入力へ回しています。これにより、後段のモデルは他モデルの良い部分を取り込みつつ、誤りを捨てる余地を持てます。
2. 多様性と性能の両方を見る
著者らは、次層に載せるモデル選びで、単体性能だけでなく出力多様性も重視しています。似たモデルばかり集めると、情報の幅が広がらず、統合メリットが頭打ちになりやすいからです。
3. 最終層は強い aggregator に寄せる
論文の設定では、最終 aggregator に強いモデルを置くと性能がさらに伸びます。これは、前段で安く広く候補を集め、最後だけ高品質モデルに判断させる設計が有効であることを示しています。
実験と結果
論文では、Mixture-of-Agents が本当に単体モデルより有効か、またコストに見合うかを複数ベンチマークで検証しています。
何を検証したのか
主な検証対象は3つです。1つ目は、MoA が AlpacaEval 2.0、MT-Bench、FLASK でどの程度性能を上げるか。2つ目は、何層にすると改善が大きいか、また proposer と aggregator の役割差がどの程度あるか。3つ目は、品質向上に対してコストや推論量が見合うかです。
どんなデータセットや評価指標を使ったのか
AlpacaEval 2.0 は実用寄りの 805 命令から成り、主指標は LC Win Rate です。これは回答長の偏りを抑えた比較指標で、人間評価との相関も高いとされています。
MT-Bench は GPT-4 による対話品質評価ベンチマークで、1ターン目と2ターン目を含む平均点を見ています。FLASK は 12 種類のスキル軸で細かく評価するベンチマークで、単なる総合点だけでなく、どの能力が伸びたかを見やすいのが特徴です。
AlpacaEval 2.0 では open-source 構成でも強かった
論文の主要結果として、open-source モデルだけで構成した 3 層の MoA は AlpacaEval 2.0 で LC win rate 65.1% を記録しました。比較対象として挙げられている GPT-4 Omni は 57.5%、GPT-4 Turbo は 55.0% です。
つまり、この設定では「単一の強いモデルを1回呼ぶ」よりも、「複数モデルを段階的に統合する」ほうが好ましい回答を返せたということです。最終 aggregator に GPT-4o を使った構成では 65.7% まで上がっており、最後の統合役の重要性も見えます。
MT-Bench でも上位だった
MT-Bench では、MoA w/ GPT-4o が 9.40、open-source ベースの MoA でも 9.25 を記録しています。GPT-4 Omni は 9.19、GPT-4 Turbo は 9.31 なので、対話品質でも十分競争力がある結果です。
この結果から、MoA は単に文章を長くして評価を稼いでいるわけではなく、対話文脈でも一定の改善があると読み取れます。
FLASK では細かなスキルでも優位性が見られた
論文本文では、FLASK でも open-source モデルだけの MoA が GPT-4o を上回ると報告しています。FLASK はスキル別の観点を持つため、単純な総合スコアよりも、「複数モデルの視点統合」が本当に回答品質に効いているかを見やすい評価です。
これは、MoA が単なるランキング上の裏技ではなく、複数の評価軸で改善が出る可能性を示しています。
コスト効率の分析も重要
論文では予算分析も行っており、一部の MoA 構成は GPT-4 Turbo と同程度の性能を、約 2 倍のコスト効率で実現できると述べています。
ここが実務上かなり重要です。最高性能だけを狙うなら大きいモデル1本でもよいですが、API 費用やレイテンシを含めて最適化するなら、「安い proposer を何本か走らせて、最後だけ強い aggregator に寄せる」設計が選択肢になります。
役割の向き不向きも見えた
論文では、すべてのモデルが proposer と aggregator の両方に向くわけではないとも報告しています。GPT-4o、Qwen、LLaMA-3 は両役で比較的強く、WizardLM は proposer としては有効だが aggregator としては弱い傾向が見られました。
この結果は、モデル選定を「ベンチマーク総合点」だけで決めないほうがよいことを示しています。候補生成が得意なモデルと、統合作業が得意なモデルは必ずしも同じではありません。
何に使える？
Mixture-of-Agents の発想は、研究の中だけでなく、実運用の AI アプリにもかなり持ち込みやすいです。
複雑な問い合わせを扱う社内アシスタント
社内規程、運用ルール、技術文書を横断して答えるアシスタントでは、1回の回答で論点を落としやすいです。そこで、最初に複数の検索戦略や説明スタイルで候補を作り、最後に統合モデルが答えをまとめる設計が使えます。
これにより、取りこぼしと冗長さの両方を減らしやすくなります。特に「違う文書にまたがる答え」を返す用途で相性が良いです。
RAG の最終回答生成
RAG では検索品質ばかり注目されがちですが、実際には「複数の根拠をどうまとめるか」も大きな難所です。MoA の aggregator 発想は、複数文書要約や矛盾解消にそのまま応用できます。
たとえば、同じ質問に対して検索条件を変えた複数回答を用意し、それらを最後に統合する形です。単一の retrieval 結果へ直接答えさせるより、より頑健な最終回答を作りやすくなります。
コード生成とレビュー支援
コード支援では、別モデルが出した実装案、テスト案、レビュー観点を統合する形が考えられます。1モデルが実装を出し、別モデルが境界条件やセキュリティ観点を補い、最後に aggregator が統一した修正版を返す流れです。
これは、単一モデルの一発回答よりも、抜け漏れを減らせる可能性があります。とくに設計比較やリファクタ案の整理に向いています。
エージェントの計画立案
AI エージェントでは、最初の計画が悪いと以後のツール呼び出しが無駄になりがちです。ここで MoA の考え方を使い、複数計画案を作ってから1つに統合すれば、初手の安定性を上げられます。
単純な多数決ではなく、統合役が各案の良し悪しを説明つきで整理する形にすると、デバッグ性も高まります。
開発や事業へのヒント
この論文から得られるヒントは、「より高性能な1モデルを選ぶ」だけが改善手段ではないということです。モデルの組み合わせ方そのものがプロダクト設計になると捉えると、打ち手が増えます。
高価なモデルを最後だけ使う設計が考えやすい
自分で AI アプリを作るなら、最初から全工程で高価なモデルを使う必要はありません。候補生成は安価なモデルに任せ、最終判断だけ高性能モデルに任せる構成は、MoA の実験結果と相性が良い考え方です。
これは、問い合わせ件数が多い SaaS や社内ツールで特に効きます。品質を維持しつつ原価を下げやすいからです。
モデル評価を役割別に行う
既存サービスの改善でも、モデルを1つ選んで終わりにせず、「候補生成役として強いか」「統合役として強いか」で評価軸を分けると、構成最適化の余地が出ます。
たとえば、単体ベンチマークでは2番手のモデルが、候補生成では最も有益ということは十分ありえます。論文の proposer / aggregator の分離は、その見方を与えてくれます。
小規模プロダクトでも段階的に試せる
この研究は大掛かりに見えますが、最小構成なら小規模プロダクトでも試せます。まずは同一モデルの best-of-3 を作り、それを同じモデルか別モデルに統合させるだけでも、MoA に近い設計になります。
ここで改善が出るなら、次に multi proposer 化や RAG との組み合わせを考えれば十分です。いきなり複雑なエージェント基盤を作る必要はありません。
重要なのは統合の質
今後注目すべき方向性としては、「複数候補をどう集めるか」だけでなく、「どう統合すると誤りを減らせるか」です。MoA はこの統合作業を LLM に任せていますが、将来的には verifier、外部評価器、ツール結果を混ぜたハイブリッド構成も考えられます。
つまり、アプリの価値は単なるモデル接続数ではなく、統合ロジックの設計力に移っていく可能性があります。
限界
まず、この手法は推論回数が増えるので、単発推論よりコストもトークン消費も大きくなります。論文でもコスト効率の改善は示されていますが、それは設計を工夫した場合の話であり、無条件に安くなるわけではありません。
次に、Time to First Token が長くなりやすい点は明確な弱点です。論文でも、最後の層に到達するまで最終回答の生成が始まらないため、初回応答が遅くなりうると述べています。チャット UI では体感品質に直結するため、実運用では層数を抑える判断が必要です。
また、候補が増えれば常に良くなるわけでもありません。似たモデルばかりを並べると多様性が不足しますし、逆に質の低い候補が多すぎると aggregator 側の負担が増えます。モデルの組み合わせ方が悪いと、期待した改善が出ない可能性があります。
さらに、評価結果の中心は AlpacaEval 2.0、MT-Bench、FLASK であり、ツール使用を伴う長い業務フローや、強い制約付きタスクでどこまで同じ効果が出るかは追加検証が必要です。とくに API 連携や厳密な構造化出力では、統合時に形式が崩れるリスクもあります。
最後に、この論文は arXiv プレプリントであり、手法は実務的に面白い一方で、どのモデル群でも必ず同じ改善幅が出るとは限りません。導入時は、自分のタスクで A/B テストする前提で見るのが安全です。
よくある質問
Q. Mixture-of-Agents は単なる多数決と何が違うのですか？
A. 多数決は候補の中から1つを選ぶ発想ですが、Mixture-of-Agents は別の LLM に候補群を読ませて、新しい統合回答を作らせます。つまり、選別ではなく再推論が入るのが大きな違いです。
Q. 同じモデルを複数回呼ぶだけでも効果はありますか？
A. あります。論文でも同一モデルを複数回サンプリングする single proposer 構成を扱っています。ただし、異なるモデルを混ぜる multi proposer のほうが、視点の多様性を取り込みやすい場面があります。
Q. どんなタスクで特に向いていますか？
A. 1回の回答で論点を落としやすいタスクに向いています。たとえば複数文書の統合要約、調査レポート、複数案の比較、コードレビュー支援、計画立案などです。逆に、超低遅延が必須の用途では慎重に使うべきです。
Q. すべての候補モデルを高性能にする必要はありますか？
A. 必ずしも必要ありません。この論文の重要な示唆は、候補生成役と統合役で必要な能力が違うことです。安価なモデルを候補生成に使い、最後の統合だけ強いモデルに寄せる設計でも十分意味があります。
Q. RAG やエージェントに取り入れるなら、最初にどこから試すべきですか？
A. 最初は最終回答の統合部分から試すのが現実的です。複数検索結果や複数計画案をそのまま返すのではなく、最後に統合専用の1ステップを追加するだけでも、MoA の発想を取り入れられます。
今日の学び
この論文は、単一の LLM だけでは回答の視点や得意分野が偏りやすいという課題を扱いました。
それに対して、複数の LLM を proposer と aggregator に分け、段階的に回答を統合する Mixture-of-Agents という推論設計で解こうとしました。
そこから得られるヒントは、AI プロダクトの改善余地はモデル選定だけでなく、モデル同士の協調設計にもあるということです。とくに RAG やエージェントでは、「どの情報を集めるか」と同じくらい「どう統合するか」が価値になりそうです。