DeepSeek-R1を読む：推論RLは何を変え、何を約束しないか

R1の重要さは、長く考える文を見せたことだけではない

DeepSeek-R1論文は2025-01-22公開で、言語モデルの推論能力を強化学習で引き出す流れを広く意識させた。表面だけを見ると、モデルが長い推論文を出し、数学やコードの問題で強いという話に見える。しかし設計者にとっての論点は、正解を検査できる問題へ報酬を置いた時、モデルがどんな探索行動を学び、どの副作用を持つかにある。長い回答そのものを目的にすると、費用も誤解も増える。

1. 1検証可能な問題
2. 2複数rollout
3. 3正誤/形式の報酬
4. 4方策更新

1. 1推論行動の変化
2. 2評価セット
3. 3蒸留または本番の予算制御

論文はまずDeepSeek-R1-Zeroとして、cold-startの教師付き微調整なしに大規模RLを適用する経路を扱う。数学の最終解やコードのテストのように、答えをプログラムで照合できるタスクは報酬を作りやすい。モデルは一問に複数の解法を出し、正しかった出力の相対的な優位を手掛かりに更新される。人が「よい推論文」を一文ずつラベル付けしなくても、探索、自己検証、やり直しのような挙動が現れ得る。ここが変化である。

ただしZero経路には読みにくい文章、言語の混在、形式の不安定さがあり得ると論文は報告する。そこでR1は、少数のcold-start data、reasoning-oriented RL、拒否や形式のための段階を組み合わせる。これは「RLだけで万能に賢くなる」という主張ではない。検査できる結果、初期分布、報酬ハッキングを抑える構成、生成物の読みやすさが一緒に働く設計である。

仕組みを三つに分ける

第一に、結果報酬がある。数式の最終値やunit testで正解を判定できれば、説明のもっともらしさではなく結果を採点できる。第二に、group内の相対評価がある。同じ問題で複数サンプルを取り、平均との差を用いて更新する方法は、価値関数を別途学習する複雑さを抑える狙いを持つ。第三に、形式・言語・安全の制約がある。結果だけに報酬を与えると、パーサを欺く文字列、不要な冗長性、読者に説明できない出力へ逃げる余地が残る。

1. 1問題
2. 2N個の回答
3. 3verifier
4. 4reward群

1. 1reward群
2. 2相対的advantage
3. 3更新

1. 1正答でも形式違反
2. 2format reward/validator
3. 3不合格

この構図で「推論を見せる」ことと「推論が正しい」ことを混同しない。可視の説明は、正答の原因を完全に表す証拠ではない。利用者に必要なのは、根拠資料、計算の検算、ツール結果、再実行可能な手順であり、もっともらしい長文ではない。業務でR1系の出力を使うなら、答えの採点器と、利用者に見せる説明の検査器を別に持つ。

蒸留が示す実装上の選択

論文は大きなR1の推論出力を小型モデルへ蒸留する経路も報告する。これは高価な教師モデルの挙動を、そのまま小型環境へ写せるという保証ではない。教師が作るトレースには正答に寄与しないtokenや、教師固有のtemplateが混じる。生徒はトレースを暗記するより、最終解の検証と短い反例を含むデータで評価されるべきだ。

公式GitHubリポジトリは関連するモデル・利用資料を確認する入口になる。コード、重み、論文、派生checkpointはそれぞれライセンスとrevisionを読む。リポジトリ名を見ただけで、任意の派生重みが同じ条件で配布されるとは結論しない。

再現設計：大規模RLをいきなり回さない

1. まず50問程度の検証可能な小セットを作る。算数なら最終値、コードならsandbox内のtest、構造化抽出ならschemaと参照値で採点する。実データを外部へ送らない。
2. base modelで一問あたり複数sampleを取り、pass@1、pass@k、平均token、format失敗率を記録する。temperature、seed、最大tokenを固定する。
3. RLを再現する前に、正解sampleの再利用、rejection sampling、短いSFTを比較する。小さな改善でも、どの処理が寄与したか判別できる。
4. RLを行うなら、rollout、verifier、advantage、更新、checkpointを別々に計測する。rewardが常にゼロまたは最大になる時は学習を進めない。
5. 同じ問題分布だけで選ばず、言い換え、誤誘導、長い入力、形式制約で失敗を探す。報酬関数を攻略しているだけの改善を除く。

トレードオフと失敗

検証可能な報酬は強いが、検証器の穴も強化する。コードを実行するtestが不完全なら、テストだけを通すパッチが増える。数学の最終値だけを採点すれば、偶然の正答や不正な形式を区別しにくい。複数sampleは精度を上げても、待ち時間と費用を増やす。長い推論は利用者の理解を助ける場合がある一方、秘密の入力を繰り返したり、誤った途中式に信頼を与えたりする。

R1から得るべき教訓は、RLを採用することではない。正解を機械検証できる狭い仕事を見つけ、生成、採点、更新、利用者表示の責任を分けることだ。その順で進めば、論文の数値を借りずに自分の問題で価値を測れる。

反証として残すべき結果

追試でR1型の手法が改善しなかった時、失敗を一行で捨てない。verifierが誤っていた、base modelが既に飽和していた、sample数が不足した、長い生成がcontextを圧迫した、領域外問題だった、という仮説を残す。特にrewardの改善と人手品質の悪化が同時に出た場合は、学習を止めて出力を読む。RLは曲線を上げるためでなく、実際の誤りを減らすために使う。

見えるtraceと検証可能な結果を分ける

2025年のR1 distillへのReddit反応には、出力が長いことや指示追従の不安定さという報告があった。これは比較測定ではない。ただし評価を二つへ分ける契機になる。task verifierでfinal answerを採点し、format compliance、latency、token use、harmfulまたはunsupported claimを別に採点する。使えない待ち時間の後に来る正解は、短く検証済みの回答と同じではない。

local reproductionではmodel revisionとserving stackを固定する。sampling、max tokens、prompt templateの一つだけをrunごとに変え、異なるprompt集合の平均ではなくpaired taskを比べる。

DeepSeekMath（2024）は、後のR1型reasoningの議論より前に、domain-targeted continued pretrainingとGRPOを組み合わせた。この系譜はtraining componentについての仮説であり、後のmodelの挙動が一つのalgorithmに由来する証明ではない。RL単独にgainを帰属する前にdata mixtureとevaluation setを固定する。

2026-09-30投稿のSpecScaleは、fine-grained verificationをtest-time search spaceをpruneする方法として扱う。実証結果は論文著者の結果にとどまる。運用上の教訓は「branchを増やす」と「検証済みprogressを増やす」を分けることにある。candidate、verifier decision、deduplication event、deferを記録し、同等candidateや検証不能な主張だけを増やすbudget増は拒否する。