DAPOを読む：LLM強化学習をアルゴリズムだけで見ない

RLの改善は、式一行では本番へ移らない

DAPOは2025-03-18公開の論文で、LLM向け強化学習を大規模に成立させるには、目的関数だけでなく、データ、報酬、rollout、学習のシステム設計が一緒に要ることを扱う。論文の題名にあるopen-source systemという言葉は、再現可能な入口を作る価値を示す。ただし公開コードがあることと、同じGPU規模・データ・環境で同じ曲線が出ることは別である。

1. 1prompt群
2. 2rollout群
3. 3verifier/reward
4. 4advantage

1. 1advantage
2. 2learner更新
3. 3新しいpolicy

1. 1rollout遅延・長さ偏り・報酬穴
2. 2計測
3. 3設計変更

LLMのRLでは、policyが答えを生成し、外部検証器またはルールがrewardを返し、その結果からpolicyを更新する。一般的な説明ではここで終わるが、実際には生成が遅い、回答長がばらつく、すべて正解または不正解のgroupでは学習信号が弱い、古いpolicyのsampleが混ざる、といった問題が出る。DAPOはこうした問題をまとめて扱う設計を提示する。自分の実装で重要なのは、各技法の名前をなぞることではなく、どの症状に効く仕組みかを対応させることだ。

報酬が均一なgroupは、何も教えない

同一promptに複数のrolloutを出し、その相対結果から更新する設計では、全回答が正解または全回答が不正解なら、平均との差が小さくなりやすい。DAPOが扱うdynamic samplingは、学習信号のあるgroupを得るための発想として読むことができる。だが難しいpromptばかりを残すと、実際の利用分布から離れ、簡単な形式遵守を忘れる危険がある。sample選別は性能改善の魔法ではなく、データ分布を変更する操作である。

回答長も報酬を歪める。長い出力はより多くの探索を含められるが、単に冗長な時もある。長さで正規化する、overlongを罰する、といった設計は、モデルがtokenを増やしてrewardを稼ぐ経路を抑える狙いを持つ。一方で、複雑な証明やコードの説明まで短く切るなら正答を失う。長さは独立のKPIにせず、正答・検証・利用者の待ち時間と同じ表で見る。

1. 1全正解/全不正解
2. 2advantageが弱い
3. 3prompt/sample戦略を見直す

1. 1長すぎる回答
2. 2length分布を確認
3. 3reward/最大budgetを調整

1. 1短すぎる誤答
2. 2verifier失敗
3. 3早期停止を緩める

システムの遅れは統計の問題にもなる

大量rolloutでは、生成器と学習器を並行に動かしたくなる。ところが、生成時のpolicyと更新済みpolicyが離れるほど、古いsampleで新しいpolicyを更新する問題が強くなる。DAPOが触れるasynchronous trainingの価値はGPUを遊ばせないことだけではない。どのsampleがどのpolicy versionから来たか、遅れをどこまで許容するかを管理する必要がある。

この問題は小規模な単一GPU実験にもある。checkpointを跨いだrewardログを混ぜる、verifierを更新したのに以前のscoreと比較する、学習途中にprompt templateを変える、といった変更があれば曲線の原因が読めなくなる。run ID、policy checkpoint、verifier version、dataset revision、seedをすべてのrolloutに付ける。

再現設計

1. 公式DAPO repoのLICENSE、requirements、データ取得、対応hardwareを確認する。実行していない段階では、repoの説明を自分の実測として書かない。
2. まず固定prompt 100件程度でrolloutを保存し、verifierの正誤と形式エラーを人手で抜き取って確認する。rewardが正しいことを学習前に確かめる。
3. 同期的な小さなtraining loopで、reward平均だけでなく全正解group率、全不正解group率、回答長分布、verifier例外、rollout時間を出す。
4. 一度に一要素だけ変える。sampling、length制御、clip設定、生成並列数を同時に変えると、失敗原因を分離できない。
5. 最後に未使用のprompt、言い換え、検証器の境界例で測る。training reward上昇と外部正答上昇を同じ意味にしない。

失敗と運用境界

RLはreward functionの穴を最適化する。JSONがparseできればよい報酬なら内容を空にするかもしれない。テストが通ればよい報酬なら未テストの仕様を壊すかもしれない。安全な操作を学ばせたい時は、危険なツールを訓練環境へ出さず、サンドボックス、allowlist、人による確認を先に置く。報酬モデルの判定をそのまま業務上の許可にしない。

DAPOの教訓は、強化学習を大きく回すことではない。生成、検証、更新、実行資源という四つのボトルネックを観測し、どの改善がどの失敗を減らしたかを示すことだ。それができなければ、上がった曲線は次の環境で再現できない。

小さな運用実験への翻訳

本番でrewardを更新し続ける必要はない。まずは失敗ログを分類し、validatorで判定できる一種類の誤りだけを選ぶ。例えば必須フィールド欠落なら、prompt、schema制約、再試行のどれが最も低コストかを比較する。RLは最後の候補である。verifierが信頼でき、データ分布が固定され、rollbackと人手確認が可能になって初めて、小さなoffline実験を検討する。

offline実験でも、報酬が上がったcheckpointを直ちに採用しない。前のcheckpointと新しいcheckpointを同じholdout、同じ最大生成長、同じverifierで比べる。改善が一部のpromptだけなら、そのpromptの重複や難度偏りを確認する。学習が不安定なら、GPU数を増やす前に、reward例外、データ欠損、policy versionの混在を疑う。システムの記録がなければ、アルゴリズムの改善は検証できない。

replay delayは測定可能なpolicy mismatchである

各rolloutについて生成したpolicy version、消費したlearner version、queue delay、sequence length、reward component、reject reasonを記録する。rewardとpass rateをage bucketごとに切る。古いrolloutがpromptの違いだけで良く見えるなら、asynchronous throughputは学習を改善したのではなくdata distributionを変えている。

scale前に小さなablationを行う。queueを固定し、maximum rollout ageだけを変える。verifier revisionを固定し、高reward outputを層化抽出してparser exploitやcopied answer patternを人が点検する。

DeepSeekMath（2024）は数学reasoningの設定でGRPOを導入し、policy optimizationのmemory useを重視した。これはDAPOのsystem workの前史として有用である。比較ごとにrollout数、sequence length、active sample、accelerator memoryを保存する。再現可能なresource envelopeを持たない高いrewardは不完全な結果である。

2026-09-23投稿のPTTSはplannerを固定executorから分け、あるvariantではbranch-level successに対してplannerを学習する。これはDAPOとの有用な対比である。policyを学習することとinference branchを配分することは別の介入である。両者の報告結果を結合しない。ローカルstudyではexecutorを固定し、planner versionとtruncated rollout budgetを記録し、一つの固定cost上限でdiversityと検証済みsuccessを比べる。