複数の LLM と PbRL

マルチエージェント PbRL は、共同応答間の選好に基づいて、協力する LLM エージェントを学習します。 CoMLRL は、タスクアイテムから選好データを構築し、以下のいずれかのアルゴリズムを使用して学習します: MARLHF は共同報酬モデルを適合させ、RL を使用してポリシーを学習し、MADPO は選好からポリシーを直接最適化します。 MARLHFTrainer、MADPOTrainer、およびそれらの反復的なバリエーション MARLHFIterTrainer および MADPOIterTrainer は、comlrl.trainers.preference から入手可能です。

trainers の4つすべては、num_turns=1 と整合性の取れた共同応答 (joint_mode="aligned") を必要とします。trainers の反復は、データ収集とトレーニングのラウンドであり、対話のターンではありません。

選好データ#

各エージェント \( i\in\mathcal{I}=\{1,\ldots,n\} \) は、ローカル履歴から \( a_{i,t}\sim\pi_{\theta_i}(\cdot\mid h_{i,t}) \) をサンプリングし、応答が共同行動 \( \mathbf{a}_t=\{a_{1,t},\ldots,a_{n,t}\} \) と共同履歴 \( \mathbf{h}_t \) を形成します。単一ターン (\( H=1 \)) では、\( h_{i,0} \) はエージェント \( i \) のプロンプトであり、\( \mathbf{a}_0 \) は共同応答です。

ユーザーはタスクアイテムを提供し、選好データではありません。trainers は共同応答をサンプリングし、オラクル関数で評価し、評価値を選好ペアに変換します。

オラクル関数#

オラクル関数は、各共同応答を単一の値で評価します。デフォルトでは、これはタスク報酬 reward_func であり、オプションの reward_processor の後に使用されます。また、ルールに従ったり、Training Initialization で説明されている LLM 報酬モデルを呼び出すこともできます。両方のアルゴリズムは、どの共同応答が勝ったかのみから学習するため、スコアの値はペアの選択にのみ影響します。MARLHFIterTrainer では、preference_scoring_reward="reward_model" は、新しい比較のために最も最近適合した報酬モデルをオラクルとして使用し、存在しない場合はタスク報酬を使用します。

選好基準#

各タスクアイテムに対し、各エージェントは自身のプロンプトに対する preference_num_candidates の応答をサンプリングし、同じ候補インデックスを持つ応答は共同応答を形成します。異なるスコアを持つ任意の2つの共同応答のうち、より高いスコアを持つものが優先されます: それは勝者 \( w \) であり、もう一つは敗者 \( l \) です。引き分けは破棄されます。pair_selection と preference_pairs_per_sample は、各タスクに保持するペアを決定します。反復的なトレーニングでは、各比較は現在のエージェントの共同応答と、同じ候補インデックスにある 比較器 の共同応答との間で行われます。どちらの側でも勝利できます。

データ形式#

ペア \( (\mathbf{h}_H^{w},\mathbf{h}_H^{l}) \) は、1 つのタスクの 2 つの共同履歴を含みます。各ペアは、リスト内の各エージェントのエントリを含む、次の形式のレコードです:

{
  "prompts": ["<agent 1 prompt>", "<agent 2 prompt>"],
  "winner_completions": ["<agent 1 response>", "<agent 2 response>"],
  "loser_completions": ["<agent 1 response>", "<agent 2 response>"],
  "winner_reward": 0.92,
  "loser_reward": 0.41,
  "candidate_reward_mean": 0.63,
  "raw_rewards": [0.92, 0.41],
  "target_raw_reward": 0.92,
  "comparator_raw_reward": 0.41
}

winner_reward と loser_reward は、2 つの共同応答のオラクルスコアであり、candidate_reward_mean はタスクの比較された候補の平均スコアです。最後の 3 つのフィールドは反復的なトレーニングから来ています: raw_rewards は、reward_processor の勝者と敗者のスコアを保持し、target_raw_reward と comparator_raw_reward は現在のエージェントのサンプルと比較器のサンプルのスコアを保持します。反復的な trainers は、iteration_0001.json、iteration_0002.json などの各ラウンドのペアを preference_replay_dir の下で書き込みます。{"iteration": 1, "num_pairs": ..., "pairs": [...]}。

トレーニングパイプライン#

LLM に基づく協調マルチエージェントシステムをトレーニングするには、PbRL は、現在のエージェントから選好データを収集し、MARLHF または MADPO で学習を繰り返します。

• ベース trainers (MARLHFTrainer, MADPOTrainer) はペアを 1 回収集し、それらでトレーニングします。タスクがタイのないペアを生成しない場合、トレーニングはポリシーの更新なしで終了します。
• 反復 trainers (MARLHFIterTrainer, MADPOIterTrainer) サイクルを繰り返す num_iterations ラウンド。ラウンド \( \nu \) 現在のエージェントを 比較器, 新しいペアを 再プレイバッファ \( \mathcal{D}^{(\nu)} \), から選択し、トレーニング から選択し、これらを使用してトレーニング \( \mathcal{B}^{(\nu)} \) ラウンドごとに. MADPO 実行 num_train_epochs ごとに. MARLHF 新しい初期化された報酬モデルを適合させ、その後ポリシー学習.

評価は常に、現在のポリシーからサンプリングし、タスク報酬 (reward_func および reward_processor) で評価し、学習された報酬モデルで評価しません。

比較器#

反復的な学習において、比較器は各比較の反対側を供給します。現在のエージェントと比較器は同じタスクに反応し、オラクル関数で明確な勝者が存在するすべての同じインデックスの比較はペアとなり、どちらかの側が勝つ

comparator_policy は、比較器のソースを選択します:

• comparator_policy="current" (デフォルト): アクティブな actor の重み、別々の乱数ストリームでサンプリング

• comparator_policy="current_copy": 現在の actor の重み、comparator_devices にコピー、actor デバイスと異なる場合に各コレクションフェーズで

• comparator_policy="model": comparator_model_name または comparator_agents からの明示的なモデル

• comparator_policy="history": actor チェックポイントを comparator_history_k からの反復回数バックから保存; 既存のポリシーまで

• comparator_policy="api": リモートモデルエンドポイント

history のソースは、ポリシーチェックポイントを自動的に保存します。両方の側は異なる数の候補をサンプリングできます; 存在するインデックスのみが比較され、pair_selection="comparator_reward" は比較器が勝つことを前提としません。デフォルトでは、比較器は 1 つの応答を生成します; comparator_generation_mode="centralized" では、1 つの比較器モデルがすべての役割の応答を単一の共同応答に書き込み、その応答は役割の応答に解析され、ペアが構築されます

モデルソースは、モデルリポジトリまたはローカルチェックポイントであり、Training Entities で説明されています

comparator_policy=model
comparator_model_name=/path/to/comparator-checkpoint
comparator_generation_mode=centralized
comparator_centralized_agent_index=0
comparator_devices=cuda:1

API 比較器#

comparator_policy="api" を使用する場合、比較器はリモートモデルをクエリします。 comparator_api_format はリクエスト形式を選択します:

• comparator_api_format="generic" (デフォルト): リクエストには、プロンプト、actor インデックス、タスクアイテム、候補数、および生成設定が含まれます。 完了は comparator_api_response_field から読み取られます。

• comparator_api_format="openai": チャット完了、および DeepSeek のような互換性のあるエンドポイントで使用される。

• comparator_api_format="anthropic": Anthropic メッセージ API (https://api.anthropic.com/v1/messages, ANTHROPIC_API_KEY)。

• comparator_api_format="openai_responses" (別名 responses または codex): OpenAI の応答 API (https://api.openai.com/v1/responses, OPENAI_API_KEY)。

Anthropic と Responses の形式には n パラメータは含まれていないため、各候補に対して 1 つのリクエストのみを送信します。リクエストには、標準的な集中型または分散型比較プロンプトを使用します。

comparator_policy=api
comparator_api_format=anthropic
comparator_api_url=https://api.anthropic.com/v1/messages
comparator_api_model=claude-sonnet-4-20250514
comparator_api_key_env=ANTHROPIC_API_KEY

Replay バッファ#

Replay バッファは、各ラウンドで使用される保存されたペアを選択します。現在のラウンドのデータセットが最初に保存されるため、以前のラウンドと並行して使用可能です。preference_replay_mode で、どのラウンドが使用可能かを設定します:

• preference_replay_mode="current" (デフォルト): 現在のラウンドのすべてのペア、歴史的なサンプリングなし

• preference_replay_mode="nearest_k": 最新の preference_replay_k 空ではないラウンドデータセット、現在のものを含む

• preference_replay_mode="all_history": 現在の trainer 実行のすべての空でないラウンドデータセット

• preference_replay_mode="lambda_decay": 同じ履歴、最近のラウンドに重点を置く

図の各行は、モードが利用できるラウンドデータセットと、それぞれの重みを表示し、最新のラウンドが右側に表示されます

nearest_k は、最近のラウンドを意味し、近傍検索ではありません。nearest_k および all_history では、有効なデータセットはサイズに関係なく、同じ重みでサンプリングされます。再トークン化されたペアは、保存されたラウンドファイルから再取得されます。preference_replay_dir を以前の実行に設定するだけでは、そのファイルのインポートは行われず、トレーニングチェックポイント は再プレイインデックスと、そのデータを復元します。

Lambda Decay#

\( a=0 \)、最新の \( K \) および preference_replay_lambda (\( \lambda \)) のデータセットの選択重みを決定します。

\( \lambda=0 \) は最新のデータセットのみを保持し、小さい値は最近のラウンドを優先し、\( \lambda=1 \) はすべてのデータセットを同じ重みで扱います。

サンプリング#

歴史的モードでは、各 preference_replay_sample_size の抽出を、重みに基づいてデータセットに割り当て、次に各データセット内でペアをサンプリングします。 割り当てられた数がデータセットサイズを超えない場合、サンプリングは繰り返しが行われません。 より大きな数は、シャッフルされたコピーを循環させます。 組み合わせたサンプルはシャッフルされます。 デフォルトのサンプルサイズは、現在のラウンドのペア数、または現在のラウンドが空の場合、最新の非空データセットのサイズです。

current は preference_replay_sample_size および preference_replay_lambda を拒否し、preference_replay_k のみを None または 1 として受け入れます。 次の構成では、すべてのラウンドから 256 個のペアをサンプリングし、最近のものに重み付けします:

from comlrl.trainers.preference import MADPOIterConfig

args = MADPOIterConfig(
    num_agents=2,
    preference_replay_mode="lambda_decay",
    preference_replay_lambda=0.8,
    preference_replay_sample_size=256,
)

MARLHFIterConfig は同じオプションを受け入れます。 最新のラウンドのみを再利用するには、ユーザーは preference_replay_mode="nearest_k" とラウンド数を preference_replay_k で設定できます。

MARLHF#

人間からのフィードバックを用いたマルチエージェント強化学習 (MARLHF) は、選好ペアに共同報酬モデルを適合させ、その後、RL を用いて学習された報酬に基づいてポリシーを訓練します。報酬モデルはチーム全体の応答を評価するため、別々の actors は共有された報酬から学習します。

報酬学習#

The JointRewardModel \( \widetilde{R}_{\psi}(\mathbf{h}_t,\mathbf{a}_t) \) すべてのエージェントのプロンプトと応答を1つのテキストとして読み取り、それにスカラーヘッドを適用する-LM backbone’最終的なパディングでない最後の隠れ状態 token. トレーニングペアに対して、ブラッドリー–テリーの損失を最小化する \( \mathcal{B} \):

ここで、\( \sigma \) はシグモイド関数です。損失は、勝者のスコアを敗者のスコアと比較します。タスク報酬に戻ることはありません。トレーニング対象 は、報酬モデルのロード方法を説明しています。

ポリシー学習#

報酬学習の後、\( \widetilde{R}_{\psi} \) は固定され、タスク報酬の代わりに使用されます。ポリシーは、各タスクに対して新しい共同応答をサンプリングし、\( \widetilde{R}_{\psi} \) は勾配なしで評価し、MARL のバックエンドは、学習されたリターンを最大化するために各エージェントのポリシーを更新します。

rl_algorithm はバックエンドを選択します:

• rl_algorithm="magrpo" (デフォルト): MAGRPO、グループ平均ベースを使用。

• rl_algorithm="mareinforce": MAREINFORCE、生の報酬を使用。

• rl_algorithm="marloo": MARLOO、leave-one-out ベースを使用。

• rl_algorithm="maremax": MAReMax、グループ最大ベースを使用。

• rl_algorithm="maac": MAAC、中心化された critic との連携。

• rl_algorithm="iac": IAC, 1つまたは添付された actor, critics, value heads を使用。

マルチエージェント REINFORCE および マルチエージェント Actor-Critic がこれらの更新内容を記述し、\( \widetilde{R}_{\psi}(\mathbf{h}_t,\mathbf{a}_t) \) が reward \( r_t \) の代わりに使用されます。オプションの固定参照 KL 正則化 (reference_kl_enabled, reference_kl_coef, reference_devices) は、ポリシー学習にのみ適用されます。各エージェントのサンプリングされた KL 推定値を、reference_kl_coef でスケーリングしたものが、報酬信号から差し引かれます。

reward_model_name は、actors がモデルオブジェクトであり、モデル識別子を持たない場合に必要です。MAAC および別個の critic、IAC も、明示的な critic ソースまたは使用可能な critic モデル識別子が必要です。

MADPO#

Multi-Agent Direct Preference Optimization (MADPO) は、報酬モデルや RL を使用せずに、ペアごとの選好から直接ポリシーを学習させる。その損失関数は、すべてのエージェントの選好 margins を統合しており、各ポリシーはチームの結果に基づいて学習する。

各エージェントの margin は、その勝つ応答と負ける応答の対数確率の差であり、共同応答 margin は、エージェント間でこれらの合計を計算します：

MADPO は最小化

\( \eta>0 \) が dpo_beta (デフォルト 0.1) である場合。タスクの報酬は各ペアのみを評価し、損失関数はポリシーの対数確率を使用します。エージェント \( i \) の勾配は

重み \( \sigma(-\eta\,\Delta_{\boldsymbol{\theta}}) \) はチームの共同 margin に依存し、勾配はエージェント \( i \) の独自の margin を通してのみ流れます。各バッチで、trainer は勾配なしで、すべての margins を一度計算し、その後、各エージェントは自身の微分可能な margin と他のエージェントの分離された margins で更新します。

目的は参照なし: 継承された reference_kl_enabled、reference_kl_coef、reference_devices の設定は、MADPO の損失に参照項を追加しません。トレーニング指標 turn_1/reward_mean と turn_1/expected_return は、ペアが収集された際に記録された候補報酬の平均であり、更新されたポリシーを反映していません。

分散型スコアは、パディングのトリミング後に最後の完了 token を除外するため、各エージェントの margin はその token の対数確率を省略します。中央集約型スコアは、完全な共同完了をカバーします。