ロジャー・クリュース・カスタン、ゲイリー・ブレイダウェイ、ローレンツ・ウルフ、マックスウェル・リン、オクターヴィン・N・メーボｰパーカー、マットリュー・ジェイムズ・サージェント

アブストラクト

我々は、検証可能な報酬（Verifiable Rewards）を用いた大規模言語モデル（LLM）の事前トレーニング後の強化学習において、集団ベースの非対称的セルフプレイフレームワーク「PopuLoRA」を導入する。

---

日付

2026 年 5 月 20 日

アフィリエーション

Vmax

---

検証可能な報酬（RLVR）を用いた強化学習は、事前トレーニングだけでは確実に獲得できない複雑な推論行動を大規模言語モデル（以降「モデル」と呼ぶ）に発現させる手段を提供します。具体的には、その解答が自動的に確認可能なタスクに対して反復的に試行を行い、解答が正しければモデルはその試行を強化されるという仕組みです。モデルによって生成された解答の正否が検証可能であれば、報酬は特にクリーンな性質を持ちます：例えば、単位テストをパスするコードを記述する、ターゲット出力と一致する入力を発見する、確認可能な解答で数学的問題を解決する、あるいは任意の決定論的検証器において成功するなどです。

RLVR は、スケールレベルで安定した検証可能なタスクの供給を必要とします。これらのタスクは、その解答を検証することができ、難易度がモデルの到達範囲付近に保たれ、かつ学習に有用であり続けるために十分な網羅性を持つ必要があります。現時点において、多くのシステムはまだトレーニング開始前に選択された固定された手作業によるキュレーション（人為的選定）タスク分布に依存しています。こうした分布は、時間の経過とともに難易度が低下しすぎたり、領域が狭すぎたり、適応が遅れたりする可能性があります。

検証可能な RLVR タスクは手書きのジェネレーターによって生成することができ、これは既に検証可能なトレーニングデータをスケールさせるための一般的な方法です。しかしながら、固定されたジェネレーターでは、カリキュラム（学習課程）の多くが事前に定義されてしまいます。一方、セルフプレイによるアプローチはより適応的な道筋を提供します：モデル自身がタスクを生成し、試行し、トレーニングが進むにつれて検証器からのフィードバックを受け取ることができます。本研究はこの方向性を発展させ、タスク生成がモデルの学習に合わせてオンラインのカリキュラムとなり得るかを問いかけます。

PopuLoRA はその方向的な第一歩です。これは、教師（Teacher）および学生（Student）LLM のアダプターからなる共進化する集団をトレーニングします。教師は検証可能なタスクを生成し、学生はそれらを解決しようと試み、検証器が報酬を提供します。学生が進化するにつれ、教師はより困難で多様なタスクを検索する必要に迫られ、一方で教師が多様化すると、学生が見るカリキュラムも共に進歩していくことになります。

セルフプレイとその失敗モード

データを適応的に生成する有効な手段の一つが、単一エージェントによるセルフプレイです：一つのモデルが自分に針對してタスクを提案し、その後それらを解決しようと試みます。本研究で取り扱うコード推論の文脈において、モデルは以下の 3 つ種類のタスクを生成します。

code_o

はプログラムの出力を予測するタスク、

code_i

は特定の出力を生成する入力を発見するタスク、そして

code_f

は入力と出力の例から欠落している関数を補完するタスクです。サンドボックス化された Python 実行環境では、パースされ、実行可能であり、かつ決定論的に動作するプログラムのみを受け入れます。

実装上において、単一エージェントによるセルフプレイは自己較正（Self-calibration）を起こすことが観察されます：タスク生成はそのモデル自身のソルバーが既に処理できる有効なタスクに向かって収束し、解決率が 100% へと急上昇し、カリキュラムはより単純なプログラムへと崩壊します。報酬曲線は健全に見えますが、トレーニング分布はモデルを押し上げておらず、停滞しています。

この崩壊現象は生成されたプログラムにおいて明瞭に現れます。単一エージェントのベースラインでは、AST の深さ、シクロマティック複素性（環状複素性）、コード行数、変数の数がすべて減少傾向にあります。一方、PopuLoRA は逆の方向に動きます：トレーニング進行に伴い、生成されたタスクはより長くなり、より深く、かつ構造的に多様化していきます。

PopuLoRA

PopuLoRA は、タスク生成とタスク解決を分離します。単一のセルフプレイするモデルという代わりに、我々は特化したタスク生成器（以降「教師 T」と呼ぶ）およびソルバー（以降「学生 S」と呼ぶ）からなる共進化する集団をトレーニングします。各ステップにおいて、教師が生徒に割り当てられます：教師がタスクを提案し、ペアになった学生が検証器の下でそれらを解決しようとします。教師は、割り当てられた学生が解決できない有効なタスクに対して報酬を得るため、難易度は教師自身の能力に対する相対値ではなく、別のモデルに対する相対値として測定されます。

これにより、難易度は集団間シグナルとなります。教師と学生は異なるモデルであり、両方のサブ集団もトレーニング中に変化し続けます。その結果得られるのは、単一モデルの局所的なタスク難易度の概念によってではなく、相互評価によって駆動される自己カリキュラムです。

これらの集団は、共有されたフrozen ベースモデル上に LoRA アダプターとして実装されています。各メンバーはフルサイズのモデルコピーを学習するのではなく、小さくランク分解された更新（Low-rank update）のみ进行学习します。また、主要なベースモデルの計算は教師と学生を通じて共有されるため、これが集団トレーニングを単一マシン上で実現可能にしています：メモリ使用量はアダプター重みの総和に比例し、マルチ LoRA 推論ではバッチ処理されたリクエストを正しいアダプターへルーティングするため、ベースモデルをメモリから出入りさせる必要がありません。また、4T+4S の設定においては、8 つのアダプターをトレーニングしながらも、実時間オーバーヘッドはわずか 1.31 倍です。

トレーニングループ

各 PopuLoRA ステップは 5 つのフェーズから構成されます。第一に、優先順位付き仮想セルフプレイと TrueSkill レーティングを使用して教師と学生をマッチングし、トレーニングをどちら側も優位にならない均衡に近い対戦に集中させます。次に、各教師がバッチ単位で

code_i

,

code_o

, および

code_f

タスクを生成します。Python 検証器は、学生がそれらを見る前に、無効または非決定論的なプログラムをフィルタリングし除去します。割り当てられた学生は複数の確率的ロールアウトを用いて有効なタスクを試行し、検証器は各タスクの解決割合を記録します。

その後、教師と学生は同時に政策勾配 RL を用いて更新されます。学生は正しく格式揃いの解答を生成することに検証器報酬を得ます。一方、教師は割り当てられた学生にとって困難な有効なタスクに対してのみ報酬を受け取り、ロールアウトで解決されないタスクについてはゼロ報酬のフロアが設けられます。このフロアが重要です：それは不可能または退化したタスクに対して教師に報酬を与えることを防ぎます。したがって、教師の目的関数は、学習可能なものの難易度が高いという争奪的な中間領域を好むことになります。

核心として、教師の報酬は割り当てられた学生の解決率と紐付いています：

$$ R_{\text{teacher}}(p) = \begin{cases} -1 & \text{if } p \text{ fails to parse, execute, or is non-deterministic}, \ 0 & \text{if } \rho(t, s, p) = 0, \ 1 - \rho(t, s, p) & \text{otherwise}, \end{cases} $$

ここで、$\rho(t, s, p)$ は、教師 $t$ から与えられたタスク $p$ を学生 $s$ がロールアウト試行の中で解決した割合を表します。小文字の $t$ と $s$ は具体的なマッチングされた教師と学生を示し、大文字の $T$ と $S$ は教師および学生の役割または個体数を指します。

数回の更新ステップごとに、教師サブ集団および学生サブ集団内で最も弱いメンバーが LoRA 重み空間進化を通じて置き換えられます。

重み空間での進化

PopuLoRA は、集団ベーストレーニングにおける置換ステップとして進化を使用します。置換演算子は直接的に LoRA テンソル上にて作用します。突然変異は親アダプターの一つを撹乱し、組換え（Crossover）は二つの親アダプターを子へと結合させます。一部の演算子は固有値を撹乱したり低ランク部分空間を回転させたりする一方、他の演算子は親間でのレイヤモジュールスロットの交換を行います。これらの演算子が低ランク LoRA テンソル上にて作用するため、新たな集団メンバーは数秒で生成され、直ちに勾配トレーニングに再投入できます。

演算子にとって不可欠な要件は「能力保持」です。置換された子は frozen ベース状態に戻らず、現行のフロンティアに近い状態でトレーニングを再開するために十分な親の行動特性を保持する必要があります。我々の保持性テストでは、ライブ集団で使用する演算子は、再投入後の約 10〜20 の更新ステップ以内に、親レベルの報酬まで回復することが確認されています。

組換えは特に重要であり、補完的な特化能力を結合できるためです。異なる軌跡に沿ってトレーニングされた親からなる子が生成され、両方から有用な行動特性を保持することで、集団が単に撹乱するだけでなく発見を再結合する手段を得ることになります。

軍拡競争的なダイナミクス（アームスレース）

トレーニングダイナミクスは、この分離为何故重要なのかを示します。単一エージェントのベースラインでは、解決率が急速に飽和してほぼ完全な性能に達します。これは強力なカリキュラムの証拠ではありませんが、提案者が自分のソルバーで確実に解決できるタスクを見つけたことを意味します。

一方、PopuLoRA では解決率は単調増加するのではなく振動します。教師がより困難なタスクを生成すると学生はより頻繁に失敗し、学生が改善するにつれ再び教師は難易度を上げる圧力を受けます。カリキュラムはモデルと共に進化し、固定点の周りに収束しません。

TrueSkill は集団レベルにおいてこのアームスレースを可視化します。個別のアダプターは同じ事前評価からスタートしますが、トレーニングが進むにつれて分化していきます：より強く弱い教師が現れ、より強く弱い学生が現れ、異なるメンバーは異なる軌跡に沿って特化してしまいます。TrueSkill のプロットにおいて、線は集団平均を示し、阴影領域は集団メンバー間の標準偏差を示します。

生成されたプログラムも同じパターンを直接示しています。単一エージェントのベースラインは、自分のソルバーが処理できる種類の短く平坦で単純なプログラムを生産するように学習します。PopuLoRA は正反対を行います。教師の報酬が割り当てられた学生の失敗に依存するため、報酬を受け続けるためには現在の学生を押し上げる有効なタスクを継続的に見つけるしかありません。カリキュラムは単に難しくなるだけでなく、プログラムの空間内でより広大で多様な領域へと拡大していきます。

下流タスクでの結果

トレーニング後、PopuLoRA は HumanEval+, MBPP+, および LiveCodeBench の標準コードベンチマークにおいて、アダプター計算量にマッチした単一エージェントベースラインを上回ります。また、トレーニング中に生成されたコードタスクのみを使用し、数学検証器ではなく Python エグテクターを用いたにもかかわらず、数学ベンチマークにおいても改善が見られます。我々はこれらの結果を暗示的な転移（Transfer）と捉え、集団自体がドメイン外汎化を引き起こすという直接的な証拠とはしていません。AIME, AMC, MATH-500, GSM8K, および OlympiadBench での得点は、より困難で多様なコードカリキュラムがより広範な推論を助けることと一致しますが、どの部分が方法論の責任を負っているかは孤立していません。

これらの利得も集団全体に及びます。4T+4S 集団内で最も弱いメンバーであっても、集計指標においてベースラインを上回るため、この効果は単一の幸運な専門家によるものではありません。共進化は集団全体を引き上げます。

結論

PopuLoRA は、システム自身がトレーニングのフロンティアの一部を生成するシステムへの初期段階です。もし同一モデルがタスクを提案し、その難易度を見積もるのであれば、セルフプレイはモデルが既に解決方法を熟知しているタスクへと自己較正してしまいます。タスク生成器とソルバーを分離することで圧力構造が変化します：教師は現在の学生の能力の限界を検索し、学生が改善するにつれ、教師集団も再び検索する必要に迫られます。

実用的な要素も重要です。非対称的な役割が圧力を供給し、集団が多様性を供給し、LoRA が集団を安価にし、オンラインでの重み空間進化が弱い系譜が静止するのを防ぎます。これらが組み合わさることで、セルフプレイは舒适圏学習へと崩壊するループから、トレーニング全体を通じて拡大を続ける自己生成のカリキュラムへと転換します。

将来に向けた見通しとして、PopuLoRA はセルフプレイおよび自己改善システムにおける実用的な道筋を示唆しています：生成、評価、置換を変化する集団に分散させることで、システムが自身と共に変化している相手に対して適応せざるを得ないようにします。