GRPOでReddit投稿要約タスクにQwen2.5-0.5B-Instructのbf16モデルを学習した

Reddit r/LocalLLaMA / 2026/4/13

💬 オピニオンIdeas & Deep AnalysisTools & Practical UsageModels & Research

共有:

要点

Redditの投稿者が、smoltldr（Reddit投稿の要約データ2k行）を用いてQwen2.5-0.5B-Instructのbf16小型モデルをGRPO（RLVR）で学習したと報告している。
MAX_LENGTHを「64 tokens」と思って設定したが「64 characters」を意図せず使ってしまい、平均生成長が10〜15トークン付近で飽和する挙動になった。
報酬設計は長さペナルティ（目標長からの乖離を罰則）と品質報酬（要約のROUGE-L）を併用し、品質報酬なしでは報酬を“稼ぐ”ような異常出力が出たが、併用では崩れが抑えられた。
次の検証として、GRPOが他の報酬ゲームを試さない理由の調査、ROUGE-L以外の評価指標の検討、LLM-as-a-judgeによる定量化、別条件（MAX_LENGTH変更やプロンプト内で報酬仕様を明示）などの計画を挙げている。

さて、数日前に、smoltldr（2k件の行からなるReddit投稿の要約データセット）でごく小さなQwen2.5-0.5B-Instructモデルを学習し、GRPOを使ったRLVRで最大長64程度の要約を出力するようにした、という投稿を共有しました。

しかし、落とし穴がありました！

平均応答長のwandbチャートが下がっていって、平均で10〜15トークンあたりで頭打ちになっていました。これは、文字数とトークン数の勘違いをしていたのが原因です。本当は64トークンにしたかったのに、うっかり64文字にしてしまったのです！

その結果、チャートは急激に低下し、応答長が「オン/オフで」だいたい15トークンに収束するように見えました。

私が使った報酬は2つでした：

length_penalty：基本的には、-abs(response_length - MAX_LENGTH)
quality_reward：ROUGE-Lです。これは、上記データセットの一部として用意していた正解の要約に対するLCS（最長共通部分列）みたいなもので、生成される応答全体にある程度の構造が保たれるようにし、劣化を最小限にすることを狙っています。

（OOMになる前に）バッチサイズ2、最大1エポック分だけ学習した結果は、前回と同じでしたが、重要な違いが1つありました：

前回の実験ではquality_rewardがないと、システムが報酬をごまかす方向に寄ってしまい、「-------*20」のようなものを出しておしまい！みたいな出力になっていました。
しかし今回は違いました。両方（length_penaltyとquality_reward）を入れた場合と、length_penaltyだけの場合で報酬がほぼ同じ結果になったのに加え、1エポック分学習後のロールアウトで劣化も見られなかったため、なぜなのか気になっています。

とにかく次は：