「変な学習ログ」からGRPOの研究が生まれるまで

Last updated at 2026-07-24Posted at 2026-07-24

GRPOの研究について

GRPOに関する論文を書いたので、今回はその中で一番気に入っているMO-GRPOについて、手法の解説というより「どうやってこの研究ができたのか」を振り返ります。
論文だけを読むと、問題を分析して、手法を考えて、理論を作り、最後に実験したように見えるかもしれません。実際の順番はほぼ逆でした。

なぜこの記事を書くのか

GRPOの仕組みや実装を説明する記事は、すでにたくさんあります。一方で、実際にGRPOを研究した人が、テーマをどう選び、何につまずき、どのログを見て、どう論文まで持っていったのかを書いた記事は、あまり見かけませんでした。

自分も推論時手法（inference method）の研究からfine-tuning手法の研究へ移ったとき、完成した論文だけでは見えない試行錯誤を知りたいと思っていました。きれいな数式が最初にあったのか、最初の実験はどのくらい小さかったのか、学習が動かなかったときに何を疑ったのか。そういう話です。

そこでこの記事では、MO-GRPOの完成形だけではなく、絵文字のチュートリアルから始まり、広告文生成の「変な学習ログ」を経て、最終的に手法と理論へつながるまでを、実際に研究した順番で書きます。

この記事で書くこと

推論時手法とfine-tuning手法で、研究のテンポがどう違うか (自分の主観です。。。)
GRPOとMO-GRPOは、数式のどこが違うのか
広告文生成の実験からAW-GRPO、MO-GRPOへつながった経緯
「変な学習ログ」を追って実装を見直したら、研究テーマになった話
論文に書かれる順番と、実際に研究した順番の違い

推論時手法とfine-tuningは、研究のテンポがかなり違う

自分は推論時手法とfine-tuning手法の両方を研究しましたが、アイデアを思いついてから結果が出るまでのテンポはかなり違いました。

推論時手法は、机で考えたアイデアを比較的すぐ実装できます。まず小さなデータセットで試し、うまくいきそうなら大きなデータセットへスケールする。最初のアイデアが良いか悪いかを、早い段階で確認できます。

一方、fine-tuning手法は、アイデアを評価する前にまず学習が必要です。ここですでに時間がかかります。ハイパーパラメータを決め、学習がちゃんと動くかを確認し、学習が終わったら評価する。論文にするなら、比較手法も同じ条件で学習しなければいけません。

自分の手法がようやく動いたと思ったら、既存手法のほうが普通に強かった、ということもあります。

違いを研究工程ごとに整理すると、次のようになります。もちろんタスクや計算環境によりますが、自分が両方を研究したときの実感です。

観点	推論時手法（Inference）	Fine-tuning手法
最初の検証	小さなデータセットに実装を適用し、アイデアの良し悪しをすぐ確かめやすい	アイデアを評価する前に、まず学習を最後まで動かす必要がある
1回の試行	比較的短く、失敗も早い段階で分かる	学習と評価の両方に時間がかかり、失敗が分かるまで長い
主な調整項目	候補数、スコア関数、探索・枝刈りなど	学習率、batch size、KL係数、rollout数、epoch数など
スケールアップ	小規模で傾向を確認してから、大きなデータセットへ移しやすい	モデルやデータの規模を変えると、学習条件の再調整が必要になりやすい
比較実験	同じモデル出力に複数の手法を適用できる場合が多い	比較手法ごとにモデルを学習し直すことが多い
よくある落ち込み	試したが、アイデア自体が効かなかった	学習が動かない。動いても、既存手法に負ける

感情の流れだけを一行で書くなら、推論時手法は「思いつく → すぐ試す → 勝つか負けるか分かる」です。Fine-tuningは「思いつく → まず学習が動かない → やっと動く → 既存手法に負ける」まであり、喜びと結果の間が長いです (精神的負担が大きいです)。

今ならCodexのようなツールがあるので、実装やデバッグは以前より楽なのかもしれません。ただ、GPUで学習を待つ時間や、比較手法まできちんと回す大変さは残ります。

このため当時は、最初から新しいfine-tuning手法一本で勝負するより、まず確実に動く応用タスクから始めたいと思っていました。

DPOではなくGRPOを選んだ

最初はDPOを研究したい時期もありました。

ただ、当時すでにDPOの派生手法は、たけのこのように増えていました（たぶん今はもっとすごい）。注目されているテーマだった一方で、今から参入しても重箱の隅をつつくような差分しか出せず、しかもあまり見てもらえないのでは、という心配がありました。

そこで、もう少し研究の余地がありそうに見えたGRPOをやってみることにしました。

もう一つ大きかったのは、当時CyberAgent AI Labの強化学習チームでインターンをしていたことです。メンターや計算環境を含めて、国内でGRPOの実験をするにはかなり恵まれた場所にいたと思います。

そもそもGRPOとは

GRPO（Group Relative Policy Optimization）は、同じ入力から複数の応答を生成し、そのグループ内で相対的に良い応答を強化する手法です。

大まかには、次の流れで学習します。

一つの入力から複数の応答を生成する
各応答を報酬関数で評価する
グループ内で報酬を正規化し、相対的なアドバンテージを計算する
良い応答の確率が上がるようにモデルを更新する

PPOのように別の価値モデルを学習しなくてよい点が扱いやすく、LLMのfine-tuningでも使われるようになりました。

最初に動かしたのは、絵文字のチュートリアルだった

もちろん、最初から新しい手法があったわけではありません。

まずは当時のGRPO Trainerのチュートリアルを動かしました。たしか「特定の絵文字が出たら1点」のような、かなり単純な報酬だったはずです。

とりあえずそれを動かして、本当に報酬に合わせてモデルの出力が変わることを確認しました。

ただ、この時点でいきなりGRPOの改良手法を考えるのは怖いと思っていました。先ほど書いたように、fine-tuningはアイデアが正しいかどうかを確認するだけでも重いからです。

まずは広告文生成をやることにした

そこで、いったん応用寄りのテーマにしました。

CyberAgentの広告文をGRPOで生成して、うまくいったら国際会議へ投稿しましょう、とメンターと話していました。

ところが、広告文を作るのは思っていたより難しい問題でした。文章の品質、多様性、文字数、表現上の制約など、6〜7個ほどの報酬や制約を同時に扱う必要があります。

実際に学習してみると、ある報酬はかなり早く改善するのに、別の報酬はなかなか改善しませんでした。

ただ、実験ログを見ているうちに、別の疑問が出てきました。

「同じくらい難しいのに、なぜ学習速度が違うのか」

報酬ごとの難易度が明らかに違うなら、学習速度が違っても不思議ではありません。

しかし、ログを見る限り、そこまで難易度が違うようには思えませんでした。

これ、なんで学習速度がこんなに違うんですかね。

メンターとそんな話を何度もしました。いろいろ考えたあと、「一回、実装を見直してみよう」ということになりました。

GRPOのアドバンテージ計算を追うと、複数の報酬を先に足し、その合計をまとめて正規化していました。つまり、報酬ごとにアドバンテージが分かれていませんでした。

ここがGRPOとMO-GRPOの違いの中心なので、数式で整理します。

一つの入力（prompt）を $q$、そこから生成した $G$ 個の出力を $o_1,\ldots,o_G$ とします。複数の目的を評価する $K$ 個の報酬関数は $R_1,\ldots,R_K$ です。

以下の $\operatorname{mean}_{\mathbf{o}}$ と $\operatorname{std}_{\mathbf{o}}$ は、それぞれ $G$ 個の出力について計算した平均と標準偏差を表します。

標準GRPO：足してから正規化する

標準GRPOでは、まず各出力の報酬をすべて足します。

R_{\mathrm{sum}}(q,o_g)
=
\sum_{i=1}^{K} R_i(q,o_g)

その合計報酬を、同じ入力から生成した出力グループ内で正規化します。

A_g^{\mathrm{GRPO}}
=
\frac{
R_{\mathrm{sum}}(q,o_g)
-
\operatorname{mean}_{\mathbf{o}}
\left(R_{\mathrm{sum}}(q,\mathbf{o})\right)
}{
\operatorname{std}_{\mathbf{o}}
\left(R_{\mathrm{sum}}(q,\mathbf{o})\right)
}

$A_g$ が正なら、その出力の確率を上げる方向に学習し、負なら下げる方向に学習します。

問題は、分散の大きい報酬が、足し算の時点で合計報酬を支配しやすいことです。最後に合計を正規化しても、どの報酬が合計値を大きく動かしたかまでは補正されません。

MO-GRPO：報酬ごとに正規化してから足す

MO-GRPOでは、各報酬を別々にグループ内で正規化し、その後でアドバンテージを足します。

A_g^{\mathrm{MO}}
=
\sum_{i=1}^{K}
\frac{
R_i(q,o_g)
-
\operatorname{mean}_{\mathbf{o}}
\left(R_i(q,\mathbf{o})\right)
}{
\operatorname{std}_{\mathbf{o}}
\left(R_i(q,\mathbf{o})\right)
}

式は長く見えますが、違いは「足す」と「正規化する」の順番だけです。

GRPO: 複数の報酬を足す → 合計を正規化する
MO-GRPO: 報酬ごとに正規化する → 正規化後の値を足す

例えば、報酬Aの標準偏差が10、報酬Bの標準偏差が1だとします。ある出力が平均より「Aは10、Bは1」だけ高い場合、どちらもそれぞれの尺度では同じ +1標準偏差 です。

しかし、標準GRPOが先に足すと、合計値への寄与はAが10、Bが1になり、Aの影響が強くなります。MO-GRPOは先に割り算をするので、AもBも $+1$ として扱えます。

また、報酬を $R_i' = aR_i+b\ (a>0)$ のように正の定数倍・平行移動しても、正規化後の値は変わりません。このためMO-GRPOでは、報酬モデルごとに異なるスケールを手作業でそろえる必要がありません。

※ 実装では標準偏差が0に近い場合のゼロ除算を避けるため、小さな $\varepsilon$ を分母に加えます。ここでは違いを見やすくするため省略しています。

「では、報酬ごとに分けて正規化したらどうなるのか」と実装を変えて試したところ、これがうまくいきました。

かなりあっさりうまくいってしまったので、最初はむしろ「本当にこれが原因なのか」と少し疑いました。

MO-GRPOは、最初にきれいな数式を思いついて始めた研究ではありません。

ログを見て「なんか変だな」と思い、実装を読み、試しに分けてみたらうまくいった、という順番でした。

「動いた」を研究にする

ただし、「実装を変えたらうまくいきました」だけでは論文になりません。

次に、標準GRPOが一つの報酬だけを過度に最適化し、ほかの報酬を悪化させる設定を探しました。その設定で、標準GRPOではreward hackingが起きる一方、提案手法では複数の報酬をより安定して学習できることを検証しました。

こうして形になったのがMO-GRPO（TACL 2026）です。

MO-GRPOは、各報酬の分散を使って目的ごとの寄与を自動調整します。また、各報酬内の選好順序を保ちながら、すべての報酬を損失関数へ均等に寄与させられることを理論的に示しました。

複数の報酬をまとめて正規化するGRPOと、報酬ごとに正規化するMO-GRPOの比較。

論文では、次の4領域で評価しています。

多腕バンディット
Mo-Gymnasiumを用いた多目的制御
WMTの英日・英中機械翻訳
指示追従

制御問題だけでなく、機械翻訳や指示追従でも同じ考え方が機能したことで、単一のタスクに固有の現象ではないことを確認しました。

後日談：数学推論でも近い考え方が機能した

その後に発表されたGDPO (全く同じアイデアなのにGDPOは結構注目されていて (引用もされてないので)、少し悲しいです。。)は、各報酬を個別に正規化してからアドバンテージを統合するという、MO-GRPOと近い設計を独立に検討しています。

GDPOでは、tool calling、数学推論、コード推論で標準GRPOと比較し、すべての設定で改善を報告しています。数学推論では、正解率と応答長という複数の目的を同時に扱っています。

GDPOには追加のbatch-wise normalizationがあり、MO-GRPOの直接的な再現実験ではありません。ただ、報酬ごとに正規化するという中核的な考え方が、数学推論でも有効であることを示す追加の実験的証拠だと考えています。

論文に書かれている順番と、研究した順番は違う

論文だけを読むと、次の順番で研究したように見えると思います。

問題を分析する
手法を考える
理論を作る
実験する

実際はほぼ逆でした。

従来手法を動かす
よく分からないログが出る
実装を読む
少し変えたらうまくいく
なぜうまくいくのかを後から整理する
理論と再現可能な実験を追加する

この研究がうまくいった理由を一つ挙げるなら、最初から一般的なアルゴリズムを作ろうとしなかったことだと思います。

報酬も制約も多い広告文生成を先に触ったからこそ、変な挙動を実際のログとして観察できました。また、結果が悪いときにハイパーパラメータだけを回し続けず、メンターと話しながら実装まで戻ったことも大きかったです。

まとめ

この研究を振り返って、fine-tuning手法の研究で重要だったと思うことは次の3点です。

まず実際のタスクを動かす。 面倒な応用問題ほど、手法の弱点が見えやすい
ログの違和感を無視しない。 「なぜこの報酬だけ遅いのか」が研究の出発点になった
実装まで戻る。 新しい数式より、既存実装の素朴な確認が効くこともある

その後は、MBR decodingの計算を学習時に移すC-GRPOにも取り組みました。AW-GRPO、MO-GRPO、C-GRPOはそれぞれ異なる研究ですが、どれも最初にあったのは「実際に動かすと、ここが困る」という感覚でした。

Fine-tuningの研究では、新しい損失関数を思いつくことより、目の前のログがなぜそうなっているのかをしつこく追うことのほうが大事な場合もあるのだと思います。

少なくともMO-GRPOは、理論から始まった研究ではなく、「なんでこれだけ学習が遅いんだろう」という素朴な疑問から始まった研究でした。

質問など

Yuki.Ichihara@mbzuai.ac.ae

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up