採用中ポジション一覧カジュアル面談
採用中ポジション一覧カジュアル面談

2026-07-14 機械学習勉強会

※ [paper] [blog] など何に関するTOPICなのかパッと見で分かるようにしましょう。
技術的に学びのあるトピックを解説する時間にできると🙆（AIツール紹介等はslack channelでの共有など別機会にて推奨）
出典を埋め込みURLにしましょう。
@Naoto Shimakoshi

[paper] LLM-as-a-Verifier: A General-Purpose Verification Framework

💡
  • OpenAIモデルでの実現可能性: 手法の要件は「スコアトークン位置での上位20件のlogprobsが取得できること」。OpenAI Chat Completions APIは/を対応していれば同じ実装がそのまま使える。一方、論文Appendix B.6はGPT-5.5やClaude Opus 4.7のような一部のクローズドフラグシップモデルはlogprobsを公開APIで返さないと指摘しており、その場合は自由記述推論を別のlogprobs対応モデルに渡す、2段階パイプラインで回避可能（+5.2pt改善、タイ率ゼロ化）
  • 実装コード（fine_grained_reward.py、logprobsからの期待値抽出部分）:
数字ではなく文字（A～T）を使うのは、数字トークンは桁数が異なり（"1","10","20"）logprob抽出が難しいため、単一文字トークンで粒度をスケールする実装上の工夫
  • Structured Output（Enum）での実装方法: EnumでA～Tを強制するだけでは不十分。Enum制約はmax確率の1値だけを返すため、それはまさに論文が批判する離散judgeと同じ状態になってしまう。正しくは：①Enum/Structured Outputで出力をA～T（単一トークン）に固定し、②同じ呼び出しでlogprobs（top_logprobs）も同時に取得し、③確定値ではなくそのポジションの確率分布から期待値を計算する、という組み合わせが必要。論文自体はStructured Outputではなくプレーンテキスト補完+カスタムタグ（）でスコア位置を一意に特定しlogprobsを抽出している。Structured Output利用時は、JSON文字列化（クオート）によるトークン分割や、プロバイダによってStructured Output+logprobsの両立可否が異なる点に要注意。取得できなければ論文方式（プレーンテキスト+カスタムタグ）にフォールバックするのが安全
💡
  • SNR（信号対雑音比）: 正解軌跡と不正解軌跡のスコア差の平均 ÷ そのバラつき。SNR(G) = E[s_c - s_i] / sqrt(Var(s_c - s_i))。高いほど正解・不正解を安定して見分けられていることを意味する。
@Shun Ito

[paper] Scalable Visual Pretraining for Language Intelligence

  • 背景
    • 現在の大規模言語モデル(LLM)の事前学習は、「テキスト化してから学習する」が基本。
    • Webページやドキュメント、あるいはPDFであっても、HTML/LaTeXソースをパースするか、Nougatのような文書パースモデルでテキストに変換してから、モデルは純粋なテキストトークン列として学習する。
    • 近年のマルチモーダル基盤モデルは画像を扱えるが、多くは画像を「テキスト生成のための条件付け入力」として使うだけで、視覚情報そのものを予測対象にはしていない。つまり、視覚モダリティはモデルの中核的な学習目的(次のトークンを当てる)には組み込まれていない。
  • 提案手法: Visual Pretraining (VP)
    • あるページに「A∩(B∪C) = (A∩B)∪(A∩C)」という集合の等式と、それを図解するベン図が載っているとする。
        1. 画像として読み込む。ページをテキスト化せず、そのままレンダリングした画像として扱う。
        1. フリーズViTで特徴化。あらかじめ学習済みで重みを固定したViTエンコーダ φ_ViT が、ページをパッチ格子に分解し、各パッチの特徴ベクトルを出す(式: Y = φ_ViT(I))。ベン図の輪郭パッチも、数式の文字パッチも、それぞれ別々の特徴ベクトルになる。
        1. 隣接パッチをまとめる(spatial merger)。近傍のパッチ特徴をグループ化し、より粗い粒度の特徴列 Z = (z1, ..., zN) にする。
        1. 前景だけを残す。各パッチの画素分散と明るさを見て、余白(マージン)のパッチを「背景」として除去する。ベン図と数式のあるパッチだけが「前景」として残り、疎な特徴列 U = (u1, ..., uL) になる(L は元のパッチ数よりずっと少ない)。
        1. LLMの空間へ射影。学習可能な線形写像 W_in で、残った各特徴を LLM の隠れ状態と同じ次元に変換する(x_i = W_in・u_i)。位置番号は、除去後の並び順(ラスタ順)で振り直す。
        1. 因果マスク付きでLLMに入力。テキストトークンを処理するのと同じ自己回帰LLMに、画像位置に対する因果的な注意マスクをかけて入力する。位置 i の隠れ状態 h_i は、それ以前の視覚トークンだけから計算される。
        1. 次の視覚潜在を予測。軽量なMLP予測ヘッド ψ が、h_i から「次のパッチの特徴」の予測値 û_{i+1} を出す。ベン図のある部分のパッチを見た後、次に来るのが数式の文字パッチなのか、別の図形パーツなのかを予測することに相当する。
        1. 対照損失で採点。予測 û_{i+1} と、バッチ内の全ての正解候補(他のページの他のパッチも含む)とのコサイン類似度を計算し、正解の次パッチだけが高いスコアになるように学習する。
      💡
      VPは「テキストの次単語予測」と全く同じ形式を、視覚特徴の対照学習という形で視覚モダリティに拡張したものである。ピクセル再構成ではなく、フリーズしたViTの特徴空間で次を当てさせることで、計算コストを抑えつつ視覚情報を学習信号に組み込んでいる。
  • 実験
    • VPはTPより少ないトークンで上回る
        • MMLU-ProとHLEはpass@1、GPQAはpass@8、AIMEは32回平均スコア
        MMLU-ProとHLEはpass@1、GPQAはpass@8、AIMEは32回平均スコア
      • 同じPDFコーパスに対して、TPはMinerU2.5でパースした約80Bのテキストトークンを使うのに対し、VPは画像を前景フィルタリングした約20Bの視覚トークンしか使わない。つまりVPは4分の1のトークン予算で、TPと同等以上の性能を達成している。これは、文書の視覚表現がテキスト表現よりもずっとコンパクトに情報を圧縮できていることを示唆する。
        • 💡
        すべての文書で同じようにVPが効くわけではない。評価対象を図・表・数式の多さ(視覚構造密度)で低・中・高に分類すると、低密度(ほぼ文章だけ)のページではVPとTPの差はほぼゼロ(-0.15)、中密度で+2.86、高密度で+3.80とゲインが拡大する(原論文Figure 2c)。つまりVPの恩恵は、実際に視覚情報が意味を運んでいる文書に集中している。
    • マルチモーダル能力もimage-textペアなしで向上
      • VPは画像とキャプションのペアを一度も見ていないにもかかわらず、画像とテキストの表現がどれだけ近いかを表す指標(重心間距離・コサイン類似度・線形CKA・相互k近傍重複率)が軒並み改善
 
@Hiromu Nakamura (pon)

[paper] RISE: Towards Retrieving Interaction Spaces for Agentic Search

 

課題

  • スニペット検索（Snippet Retrieval）: 検索結果として短い断片のみをLLMのコンテキストウィンドウに提供する。これにより、エージェントは文書全体を俯瞰できず、情報の断片化が起こる。
  • 直接コーパス対話（Direct Corpus Interaction, DCI）: grepなどのシェルツールを用いてrawコーパス全体を探索する。しかし、コーパスが大規模化すると、スキャンコストの増大やレイテンシの悪化によりスケーラビリティが損なわれる。

提案手法：RISE (Retrieving Interaction SpacE)

RISEは、検索とエージェントのシェル操作を統合する新しい枠組みであり、以下の二つの設計指針を提示する。
インタラクション空間の構築（境界の提供）: 検索エンジン（BM25）を用いて、コーパスの一部を「対話用ディレクトリ」として切り出す。これはコンテキストウィンドウ外の永続的な作業空間として機能する。これにより、エージェントは検索結果に対して繰り返しシェル操作（rg, catなど）が可能となり、コーパス全体を探索することなく、かつ十分な情報を確保できる。
対話可能なオブジェクトへの処理（構造化メタデータ）: 文書をrawテキストとして置くのではなく、インデックス時に構造化する。具体的には、LLMを用いて文書内のセクションを特定し、行番号付きの目次（Table of Contents, TOC）とアンカー文字列を挿入する。これにより、エージェントは文書の全行を読み込むことなく、readツールを用いて該当箇所に直接ジャンプすることが可能となる。

メソドロジー

  • BM25によるバウンディング: クエリに基づいて上位 K 件の文書をハードリンクし、作業空間を構築する。
  • オフライン処理: gpt-5.4-nano等のモデルで文書構造を解析し、行範囲を指定したTOCを付与する。これにより、エージェントは「目次で当たりをつけ、特定の行範囲をピンポイントで読み、本文で事実確認を行う」という効率的な探索が可能になる。

実験結果

BrowseComp-Plusベンチマークを用いた実験により、以下の点が実証された。
  • コスト効率と精度の両立: RISEは、DCIベースラインと比較して、同等の精度（78%）を維持しながら、クエリあたりのコストを約1/4に削減した。
  • スケーラビリティ: 100k件から1M件の文書へとコーパスを10倍に拡大しても、RISE-BM25の精度は安定している。一方、DCIは大規模化に伴い、壁時計時間（wall-clock time）の制限による失敗が多発した。
  • モデル能力の引き出し: 高性能なモデル（gpt-5.4）と組み合わせることで、RISEは高い検索精度と根拠抽出能力を発揮する（精度82%）。
@Kyohei Uto(kuto)

[blog]Building Fast & Accurate Agents with Prime-RL Post Training

概要

  • rampがスプレッドシート検索に利用する検索サブエージェントをRLで改善した話
  • Qwen3.5-35B-A3Bを合成データセットでRLすることでhaiku 4.5と同等のレイテンシでopus 4.6より高精度を実現している

背景

  • Ramp Sheetsでは、全ツール呼び出しの17.8%がシート探索・データ取得に使われていた。このうち約75%は直後に再度読み込みが発生しており、探索が非効率だった
  • そこで、メインエージェントから検索処理を切り出し、専用サブエージェント「Fast Ask」を開発
  • Fast Askの役割は、シートを編集することではなく、必要なセルを探し、計算して、簡潔な回答をメインエージェントへ返すこと

手法

  • ベースモデルはQwen3.5-35B-A3B
    • Haikuクラスの応答速度を実現できるが学習前の性能は低め
  • 学習には財務業務を模した合成データセットを使用
    • 売上集計、請求書照合、支出分析、期間検索など14種類のタスクを用意
  • エージェントが使えるのは以下の3ツールのみ
    • シートのメタデータ取得
    • 指定セル範囲の読み込み（1回1,000セルまで）
    • Pythonによる計算処理
  • 学習
    • 報酬
      • 最終回答が正しいかを基にツール利用方法を学習させている
      • correct = 正確性
      • efficiency = 少ない探索
      • concise = 簡潔な回答
      • 学習条件
        • 1タスク最大15ターンに制限
        • 100ステップを約26時間で学習
        • Prime Intellectの非同期RL基盤
          • ‣
       

実験

  • haiku 4.5と同等のレイテンシでopus 4.6より高精度を実現している
      •  
    • 1ターンで読み込むセル数は増加している(左下)が、1タスクで読み込むセル数は変わらない(右下)
    • つまりセルの総読み込み量はほぼ同じでも、不要な探索を避け、必要な範囲へ集中することで精度と速度に貢献している
 

学び

  • 大型モデルに全部やらせず判断や複雑な推論を任せ、検索・集計は小型モデルに分担する
  • 金額・日付・請求書IDなど、完全一致で採点できる処理はRL向き。最終結果のみ定義できればプロセスは学習してくれる
  • 成否を分けたのは、適切なタスク、3つに絞ったツール、明確な制限、実運用に沿った報酬設計
  • 本番のボトルネックから学習対象を選ぶ。今回は実運用ログから、ツール呼び出しの17.8%を占める検索処理を特定して切り出した
 
@Ryuhei Kawabata

[blog] Rewriting Bun in Rust

Bun が Zig 535,496行を Rust に11日間で全面移植した話。「LLMで大規模移行ができた」こと自体より、どういうパイプラインと制約設計で回したかに価値があるので、そこをまとめる。

移行パイプライン全体像

段階移行ではなく一括移行。フェーズごとに「1実装者 + 2敵対的レビュアー + 1適用役」という同じエージェント構成を使い回している。
フェーズやったこと
0. 事前設計人間と3時間議論して PORTING.md（Zig→Rust の対応パターン集）と LIFETIMES.tsv（全構造体フィールドのライフタイム分析）を作成
1. 試験ポートまず3ファイルだけ移植して手法を確立、その後に全体展開
2. 一斉ポート4つの git worktree × 各16プロセス = 64並列 Claude で全1,448ファイルを移植。ピーク時695コミット/分・1,300行/分
3. コンパイルエラー修正 でエラー収集→ファイル単位に分類→クレートごとに修正ループ。計約16,000エラー
4. スモークテスト や などサブコマンド単位で起動確認、スタックトレースをファイル保存して修正
5. テスト合格化既存の TypeScript 製テストスイート（60,000+テスト、スキップ・削除は0件）を全プラットフォームで100%通過させる。972→23失敗まで2日、全6プラットフォーム緑化まで3.5日

工夫1: 実装より先に「移植の設計図」を作らせた

  • PORTING.md は Zig と Rust の罠になる差分を対応表にしたもの。例えば Zig の は全ビルドで実行されるが Rust の はリリースで消えるため、副作用を入れると挙動が変わる。
  • LIFETIMES.tsv は全構造体フィールドについて「制御フローをトレース→Rust で表現可能なライフタイムを提案→2つのレビューエージェントが検証」した結果の表。手作業では割に合わない規模の事前分析を、実装開始前に LLM に済ませておくのがポイント。
  • 機械的な1対1対応を保つ方針（例: → 、 引数 → const generics）にしたことで、Zig を知る人がレビューでき、リファクタは移行後（v1.4以降）に分離できた。

工夫2: 敵対的レビューの「文脈の分離」

レビューの効き目は、実装者とレビュアーに渡す情報を非対称にする設計から来ている。
役割渡す文脈前提
実装 Claude元の .zig ファイル、移植計画、自分の推論正しく移植しようとする
レビュー Claudediff のみ「このコードは間違っている」と仮定して欠陥を探す
実装者の推論を見せないことで「実装者の説明に納得してしまう」ことを防ぐ。実際に捕捉したバグの例:
  • libuv の非同期 close 中に が drop されて use-after-free（ で修正）
  • 負の時刻で が0方向に丸めて が負になる（ に修正）
  • が第2引数を先に評価してパニック（ に修正）
コンパイルが通るかと、Zig と意味的に同じかを別の審査として扱っているのも特徴。「コンパイルエラーを消すためにスタブ関数化する」逃げを検出したら、「コード品質を下げない」というレビュアー指示を追加して塞いだ。

工夫3: 64並列を破綻させないための運用制約

並列 Claude はそのままだと互いの作業を壊すため、失敗のたびにワークフローの指示を書き換えて制約を足していった。
起きた問題対策
複数 Claude が / を実行して worktree が競合git 操作を「個別ファイルのコミット＆プッシュ」だけに制限
大規模リポジトリ×4 worktree でディスク枯渇、マシンが数回クラッシュ明示的な制約と監視を追加
EC2 の IOPS ( I/O Operations Per Second) 不足で が数分フリーズインスタンスの IOPS を人間が増強
メモリリークテストやストレステストが環境を壊す の cgroup 隔離（メモリ/CPU 制限）でテストごとに分離
人間（エンジニア1人）が書いたコードはほぼ0行で、仕事は「事前設計の議論」「11日間ワークフロー出力を読み続ける」「失敗パターンを見つけて指示を書き換える」「マージ前の手動検証」。人間の介入点をコードからフィードバックループの編集に移している。

成果（要点だけ）

  • 既知バグ128件修正、LeakSanitizer で計測可能なリークを全て解消、バイナリ18〜20%縮小、実行速度2.2〜4.7%向上。
  • 回帰は既知19件で全て修正済み。下は回帰の実例（ハイパーリンクの色付けが壊れて "oxfmt" が "oxfmtr" に見える）で、 フォーマット文字列の移植漏れが原因。
bun update -i の表示回帰の例
bun update -i の表示回帰の例
  • 本番投入の実証は Claude Code v2.1.181。Linux p50 起動時間が517ms→464msで10%短縮。
Claude Code の起動時間: v2.1.179 (Zig) 517ms → v2.1.181 (Rust) 464ms
Claude Code の起動時間: v2.1.179 (Zig) 517ms → v2.1.181 (Rust) 464ms

規模の参考値

オリジナル記事より
オリジナル記事より
指標値
期間11日間、6,502コミット、追加1,009,272行
トークン入力59億 + キャッシュ720億、出力6.9億
API 費用約$165,000
並列数最大64 Claude（Claude Fable 5 プリリリース版）

持ち帰り

  • 効いているのは LLM の性能そのものより、事前設計（PORTING.md / LIFETIMES.tsv）→非対称な敵対的レビュー→失敗駆動での制約追加、というハーネス設計。
  • ただしこのやり方は「スキップ0件の厚いテストスイートが既にある」ことが前提で、正解判定を全部テストに委ねられたから並列化できた。テストが薄いコードベースで真似ると回帰を検知できない。

メインTOPIC

Maximum Likelihood Reinforcement Learning

ICML2026(Oral)・Best Paper Award at ICLR 2026 SPOT Workshop

まず何なのか

GRPO に変わるシンプルで効率的な強化学習手法

論よりコード

差分はシンプル

シンプルだけど学習効率がよい

Qwen3-4Bでの結果。MaxRLは全ベンチマークでGRPOをパレート支配しており、Pass@1は同等以上、かつPass@Kを大幅に改善している。これはテスト時スケーリング効率において7.9倍〜19.2倍の向上に相当する。

なぜ効果があるのか

背景

  • 従来の機械学習（例：画像分類）は「最尤推定」という考え方で訓練する。これは「正解ラベルが出る確率をできるだけ高くする」というシンプルな目標で、モデルを大きくしたりデータを増やしたりすれば素直に性能が上がる、扱いやすい目的関数。

問題設定

  • ところがコード生成や数学の問題を解くタスクでは事情が違う。
    • 「生成過程が微分不可能」：モデルが単語（トークン）を1個ずつサンプリングして文章やコードを組み立てる過程は、途中に「サンプリングする」という不連続な操作が入るため、通常の勾配法（微分してパラメータを更新する方法）がそのままは使えない。
    • 「二値的な正解概念」：出力されたコードや答えは「合っている／間違っている」の0か1でしか評価されない（部分点のような滑らかな評価がしにくい）。
  • そこで、入力 に対してモデルが正解 を出す確率を と書く。これは「モデルが暗黙のうちに持っている、正解に対する尤度」とみなせる。

RL との違い

  • こうした「微分不可能＋二値正解」の状況では、代わりに強化学習（RL、特に方策勾配法など）がよく使われる。「正解を出せたら報酬1、外れたら報酬0」として、報酬を最大化するようにモデルを訓練するイメージ。
  • ただし論文の主張は「最尤推定とRLは、似ているようで実は最適化している目的関数が根本的に違う」という点。つまり「正解確率 を素直に上げる」ことと「RLで報酬期待値を上げる」ことは、数式的に同じゴールに見えて実際には異なる振る舞いをする、というのがこの後の議論（MaxRL）につながる問題提起。
要は「テストの点数（0か100点）しか分からない問題を、微分可能な普通の学習法で解けないので、みんなRLを使ってきた。でもRLと最尤推定は実は目指しているものが違うよね」という目的。

Maximum likelihood(最尤)とReinforce Learning の目的関数の違い

最尤推定と強化学習の両方が、微分可能性に関わらずあるタスクに適用できると仮定しよう。この2つの目的関数は、以下で説明するように著しく異なる最適化の振る舞いを引き起こす。この違いを正確にするため、それぞれの枠組みが暗に持つ母集団レベルの目的関数を比較する。
を、パラメータ を持つモデルが入力 に対して正しい出力を生成する確率とする。対応する強化学習の勾配 と最尤推定の勾配 は、それぞれ次の形を取る：
最尤推定によってもたらされる逆確率による重み付け（inverse-probability reweighting）は、成功確率が低い（難しい）入力により大きな重みを置く。これにより、本論文で実証的に示す通り、著しく異なる最適化のダイナミクスが生じる。

MaxRL は pass@k を最適化し, 従来の RL は pass@1 を最適化している

MaxRLは、サンプリングベースのタスクにおいて、計算量を増やすほど最尤推定目的関数へのより良い近似を得られるようにするフレームワークである。最尤推定は, 成功確率 の対数をとって と定義でき、以下の式変形により
の勾配を取ると以下の式変形により
一方で従来の強化学習の目的関数は
の展開まとめ

0. 出発点（定義）

  • ：モデルが正解を出す確率
  • （最尤推定の目的関数は対数尤度として定義される）

1. 等比級数

のとき：
証明の流れ
  • とおく
  • 引き算すると中間項が消え、
  • なら n→∞ で
  • よって

2. log(1−q) の展開

  • 微分：（合成関数の微分）
  • 1で示した式を代入：
  • 両辺を積分（
  • を代入すると両辺0になるので
  • 添字を k+1 → k とずらして整理：

3. を代入

  • なので
  • 代入すると：

4. と気づく

  • 1回サンプルして失敗する確率 =
  • k回独立サンプルして全部失敗する確率 = （独立試行の掛け算）
  • これが fail@k(x) の定義そのもの

5. 最終形

最尤推定の目的関数は、「k回試して全滅する確率（fail@k）」を無限に足し合わせたものとして書き直せる。
から pass@k の勾配へ
出発点:
  1. 両辺をθで微分（Σと微分は項ごとに交換してよい）
  1. を代入して微分
=
=
（定数1の微分は0, fail@kが増えるとpass@kが減る関係なので符号が反転するのは自然）
  1. ステップ1に代入（マイナス×マイナス＝プラス）
=
結論 の勾配は、pass@k の勾配を 1/k の重みで無限に足し合わせたものに一致する。
なぜRLはpass@1しか最適化していないのか
REINFORCEの目的関数
  • 標準的なRL：1回サンプリングして正解なら報酬1、不正解なら報酬0
  • 期待報酬:
  • p は「1回サンプルして成功する確率」＝ の定義そのもの
勾配の比較
  • RLの方策勾配：
  • 最尤推定の無限和: のうち k=1 の項だけ取り出すと：
  • 両者は数式上完全に一致する
結論
  • RLは無限和のうち の項だけを最適化している
  • の項（何度か試してようやく成功するレアケースの情報）はRLの勾配に一切含まれない
  • MaxRLはこの欠けている高次項を近似で補うことを狙う

MaxRL(提案手法) での目的関数

  • 無限和 をそのまま計算するのは無理。無限回サンプリングすることになるから。
  • なので で打ち切る。からまでだけ足す、という近似が 。
  • Tは「どれだけ頑張って高次の項まで計算するか」を決めるツマミ。Tを増やすほど計算コスト（サンプリング回数）は増えるが、より本来の最尤推定に近づく。
  • のとき：の項しか残らないので
    • これは前に話した「標準RLの勾配」とまったく同じ形。
    • つまり標準RLは「一番安く済ませたバージョン（T=1）のMaxRL」とみなせる。
  • のとき：元の無限和にどんどん近づいていき、最終的には厳密な最尤推定 と完全に一致する。
  • この節の一番言いたいこと：
    • RL（）と厳密な最尤推定（）は対立する別手法ではなく、同じ枠組みの両端にすぎない
    • Tは自由に選べる「計算量ツマミ」になり、Tを増やす＝計算を増やすほど、稀にしか起きない高次の成功パターンまで学習信号として拾えるようになる
    • これが「MaxRLは計算量をより良い最尤推定の近似に変換するフレームワーク」という冒頭の主張の具体的な中身

MaxRLの実用的な勾配推定量

  • そもそもの問題： の式（pass@kの無限和）は理論的にはきれいだが、実際にpass@1, pass@2, ...を1つずつ推定して足し合わせるのは実用的でない
  • 定理1(↑) が示すこと
    • 実は無限和を計算しなくても、「成功した軌跡だけを見て、そのスコア関数を平均する」だけで最尤推定の勾配と一致する、という驚くほどシンプルな事実
    • スコア関数 は、方策勾配法（REINFORCE）でおなじみの「対数尤度の勾配」そのもの
  • 具体的な推定手順（）
    • まず回サンプリング（ロールアウト）する
    • 成功した数をとする（のものの数）
    • 成功した軌跡だけについて を足し合わせて、 で割る（平均を取る）
    • もし1回も成功しなかったら（）、勾配は0にする
  • ここがREINFORCEとの分かれ道
    • REINFORCEは「全サンプル数N」で割る（成功したかどうかに関わらず全部で平均する）
    • MaxRLは「成功したサンプル数K」で割る（外れたサンプルは無視して、当たったものだけで平均する）
    • この「Nで割るかKで割るか」の違いがすべてを分ける
  • Nを増やす意味が根本的に違う
    • REINFORCEでNを増やしても、狙っている目的関数自体は変わらず、ただ推定のブレ（分散）が小さくなるだけ
    • MaxRLでNを増やすと、狙っている目的関数そのものが の打ち切りMaxRL目的関数へと変わっていき、Tが大きくなるほど本来の最尤推定に近づく
    • つまり「同じ計算を増やす」という行為が、REINFORCEでは精度向上（分散減）にしかならないのに対し、MaxRLでは目的関数そのものの質の向上（バイアスの改善）につながる
  • 定理2(↑) が保証していること
    • この推定量 の期待値が、ちょうど の打ち切りMaxRL目的関数の勾配 に一致する（不偏推定量）
    • 難しいpass@kの推定を陽に行わなくても、「N回サンプリングして成功したものだけ平均する」という素朴な操作だけで、自動的にTレベルの近似が達成される、というのがこの節の一番のポイント

うれしいこと

  • 「難しい問題（正解確率が低いプロンプト）への学習信号がより強く、後半のepochまで解けなかった問題を解けるようになり続ける」 という話。
  • 勾配ノルムの分析：MaxRLは pass rate（正解率）が0に近いプロンプトに対して大きな勾配ノルムを出す → 難しい問題に学習信号を集中させている
  • 解けた問題の割合：MaxRLは学習が進んでも「少なくとも1回は正解できるプロンプトの割合」を高く保ち続ける → 通常のRL（GRPO）だと後半のepochで学習が停滞しがちなところ、MaxRLは学習を継続できる

まとめ

A one-line change in REINFORCE bridges the gap between RL and maximum likelihood, and makes AI math reasoning up to 20× more efficient.
 
Xでポスト