技術的サマリー：UnityMAS-O

問題定義

現在の大規模言語モデル（LLM）に基づくマルチエージェントシステムは、複雑なタスクを相互作用する役割（例：プランナー、リtriever、コーダー）に分解するが、プロンプト、ツール、制御ルールによって定義された手動オーケストレーションワークフローに依存している。これらのシステムは推論においては効果的であるが、エージェント自体は統一的な強化学習（RL）インターフェースを通じて最適化されることは稀である。既存の RL 事後学習フレームワーク（例：TRL、OpenRLHF、verl）は、主に単一ポリシーの最適化を目的としている。構造化された相互作用、役割固有のクレジット割り当て、および設定可能なパラメータ共有を必要とする任意のユーザー定義マルチエージェントシステムを最適化するために必要な抽象化が欠如している。その結果、マルチエージェントパイプラインのトレーニングは、異なるパラメータ共有方式を容易に比較できず、ワークフロー間でインフラを再利用できないタスク固有の実装につながることが多い。

手法：UnityMAS-O

UnityMAS-O は、単一の応答やポリシー軌跡ではなく、完全なマルチエージェントワークフローを最適化の単位として扱うように設計された汎用 RL 最適化フレームワークである。Ray ベースのスタートポロジーランタイムを verl フレームワークに拡張して構築され、論理エージェント設計と物理モデルパラメータを分離する 4 つのファーストクラス抽象化を導入する：

1. 論理エージェント役割：ユーザーは、特定のプロンプト、I/O スキーマ、およびツールアクセスを備えた役割（例：プランナー、検証者）を定義する。これらは固有のパラメータセットに紐付かないワークフローレベルのオブジェクトである。
2. エージェント–モデルマッピング（$\phi$）：論理役割から物理 LLM インスタンスへの設定可能なマッピング。これは 3 つの方式をサポートする：
   • 完全共有：すべての役割が単一のモデルにマッピングされる。
   • 完全分離：各役割が独立したモデルにマッピングされる。
   • 部分共有：関連する役割のグループがパラメータを共有し、他の役割は個別のモデルを使用する。
3. ワークフローグラフ（$G$）：実行フロー（逐次、並列、反復、またはハイブリッド）を表す有向計算グラフ。実行は、状態、アクション、制御依存関係を含む構造化された軌跡を生成する。
4. 役割固有の報酬関数：報酬はノード、ターン、および軌跡レベルで定義される。このフレームワークは遅延報酬および限界改善シグナル（例：$\Delta$F1 または $\Delta$score）をサポートし、中間状態または最終結果に責任がある特定のエージェントにクレジットを割り当てる。

システムアーキテクチャ：
システムは、中央コントローラーとモデルローカルワーカーグループを採用する。

• 中央コントローラー：ユーザー定義ワークフローを実行し、$\phi$ に基づいて論理エージェントの呼び出しを適切なワーカーグループにルーティングし、構造化された軌跡を記録し、報酬を構成する。
• ワーカーグループ：特定の物理 LLM インスタンスに関連付けられ、非同期推論、バッファリングされたロールアウトテンソル（対数確率、値）、アドバンテージの計算、および分散 PPO スタイルのポリシー更新を処理する。
• データ分離：ワークフロー制御メタデータは「薄く」中央に保持され、重いトレーニングテンソルは「太く」ワーカーグループにローカルに保持され、通信オーバーヘッドを最小化する。

主要な貢献

本論文は以下の貢献を提示する：

• 統合抽象化：ユーザー定義ワークフローグラフ、論理エージェント役割、エージェントからモデルへのマッピング、および構造化されたマルチエージェント軌跡を共同で表現するフレームワーク。
• 設定可能なパラメータ共有：完全共有、完全分離、および部分共有をネイティブにサポートし、トレーニングパイプラインを書き換えることなく、専門化、リソースコスト、および最適化動作の制御された研究を可能にする。
• 分散ランタイム：中央ワークフロー制御、非同期ロールアウト、モデルローカルバッファリング、およびモデルごとのポリシー更新を特徴とする Ray + verl ベースのアーキテクチャ。
• 汎用最適化インターフェース：基盤となる最適化インフラを変更することなく、多様なシステムに対してワークフロー、エージェント、モデルマッピング、および報酬を定義できるインターフェース。
• オープンソース実装：フレームワークを https://github.com/chenyiqun/UnityMAS-O で公開。

実験結果

著者は、検証可能なタスクの 2 つのファミリー、すなわち検索拡張型質問応答（QA）およびリフレクティブなコード生成において UnityMAS-O を具体化した。

QA およびエージェント的検索：
自然質問（NQ）および HotpotQA において、並列検索から反復検索ループ（M-ASK）までのワークフローを用いて実験を行った。

• 性能向上：マルチエージェント RL（MARL）トレーニングにより、評価されたすべてのワークフローおよびモデルスケール（0.5B から 14B）で性能が向上した。
• 小規模モデルへの影響： gains は特に小規模モデルで顕著であった（例：NQ における 0.5B エージェントは F1 が約 0.02 から約 0.44 に改善）。これは、MARL が役割特化型エージェントがワークフロープロトコルを満たし、効果的に協調することを助けることを示唆している。
• パラメータ共有：共有モデルと独立モデルを比較する実験（例：共有 3B 対 独立 4x3B）は、共有モデルはわずかに遅く収束するが、同様の最終性能レベルに到達することを示し、共有物理パラメータを用いた論理マルチエージェントワークフローのトレーニングの実現可能性を実証した。

リフレクティブなコード生成：
保持されたコードタスクにおいて、3 ラウンドの計画–コード–検証–リフレクションワークフローをテストした。

• 厳密な指標：厳密な「すべて合格」指標の下で、3xQwen3-4B ワークフローは 0.255 から 0.686 に、3xQwen3-8B は 0.290 から 0.738 に改善した。
• 効率性：MARL トレーニングは、問題を解決するために必要な検証ターン数の平均を減少させた（約 2.5 から約 1.7）。これは、内部停止動作および実行効率の向上を示している。

意義と主張

本論文は、多くの LM ベースのマルチエージェントシステムにおける主要なボトルネックは、ワークフロー自体の設計ではなく、設計後のワークフローに対する原理的な最適化インターフェースの欠如であると主張する。UnityMAS-O は、手動で指定されたマルチエージェントシステムをトレーニング可能なマルチエージェントポリシーに変換することで、これを解決する。

著者は、UnityMAS-O を以下のことを可能にする再利用可能な最適化基盤として位置づけている：

1. 体系的な最適化：明示的なクレジット割り当てを備えたトレーニング可能な RL システムへの多様なワークフローの変換。
2. 柔軟性：設定可能なパラメータ共有を通じて、専門化とリソース効率の間のトレードオフの研究。
3. 効率性：最終的な正しさだけでなく、マルチエージェント相互作用の協調および実行効率の向上。

この研究は、特定タスクのベンチマークツールではなく、複雑なマルチエージェントシステムのトレーニングのための実用的なシステム基盤、およびそのようなシステムにおける協調、専門化、およびスケーラビリティの研究プラットフォームとして提示されている。著者は、フレームワークの一般性をさらに検証するために、具現化エージェントおよびソフトウェアエンジニアリングにおける継続的な実験が進行中であると述べている。