TRL と OpenEnv を用いた言語モデルによる水彩画生成トレーニング手法の紹介

8 月 23 日、Surya Narreddi 氏が言語モデルが描いた水彩画の美しい動画を公開しました。このモデルは「p5.js に自然な描画ツールを追加する」ライブラリである p5.brush を通じて JavaScript を記述し、絵を描きます。動画は瞬く間に viral となり、執筆時点では 150 万回以上の再生数を記録しました。

この動画には、プロジェクトの初期段階におけるトレーニングの詳細を解説する ブログ記事 も添付されていました。その内容は、動画で見られるような完成された構図ではなく、より狭い範囲に焦点を当てたクローズアップの花々を描くものでした。残念ながら、当時のプロジェクトにはオープンな成果物は含まれていませんでした。彼のサイトでは、包括的な技術レポートの公開が予定されているため、氏のフォローをお勧めします。このアイデアの元祖は Surya 氏自身で、アートやデザインの分野に根ざしています。そのスキルは私とは比較にならないほど優れています。

注記: プロジェクトの背景について Surya 氏自身が語る内容は、彼の論文に関する動画をご覧ください。

本記事では、私が TRL と OpenEnv を用いて、Surya 氏のアイデアを再現しようとしています。参照用のデータセット、強化学習（RL）環境、トレーニングスクリプト、そして学習済みモデルはすべてオープンソースです。

このパイプライン全体が Hugging Face 上でエンドツーエンドで動作します：

• Jobs を活用したトレーニング

RL 環境とスコアリングモデルは、Spaces に配置されています。

ペアワイズジャッジ機能には、Inference Providers を活用しています。

また、すべてのアーティファクトは 1 つのコレクション にまとめられています。

2 つの Spaces が起動したら、実行するコマンドはたった 1 つだけです。環境 と スコアリングモデル を複製し、報酬の混合比率を設定するための 2 つの環境変数を設定して、以下を実行してください。

hf jobs uv run train/watercolour_grpo.py --flavor h200 --timeout 48h --secrets HF_TOKEN -- \
  --env-url https://<you>-watercolour-env.hf.space \
  --model Qwen/Qwen3.5-35B-A3B --lora --all-linear --bf16 --gradient-checkpointing \
  --subject 'a peach hibiscus' --references 4 \
  --top-p 0.95 --top-k 20 \
  --lr 5e-5 --lr-scheduler constant_with_warmup --warmup-steps 5 \
  --scale-rewards none \
  --steps 110 --n-episodes 240 --num-generations 8 \
  --per-device-batch-size 1 --gradient-accumulation-steps 8 \
  --max-completion-length 8192 \
  --run-tag my-run --out <you>/watercolour-grpo --push-to-hub

この記事の後半では、この状態に至るまでの経緯を解説します。関連するすべての資料は リポジトリ に格納されています。

私は元のブログ記事の手順を忠実に追いましたが、必要不可欠な場合以外は変更を加えていません。私の独自のアイデアは実験に組み込むのではなくリスト化し、最終的に「次に試してみたいこと」として、公開されたアーティファクトの全リストの隣にまとめました。すでに彼の投稿を読んだ方にとっては、枠組みや報酬設計はお馴染みのはずです。本記事で新たに提供するのは、オープンな実装、手動評価済みデータセット、そして訓練・比較された 3 つの報酬混合モデルです。これらは以下のセクションから始まります。

構築すべき RL 環境

3 つのランが並行して進行しています。それぞれ異なる報酬の組み合わせに基づいて進化しており、各フレームはステップごとの中央値となる絵画を示しています。まだどのランがどれに対応するかを区別する必要はありません。詳細については記事で説明します。

なぜ人々がこれに魅了されたのか

これらの絵画は、あえて不揃いで手作業の質感を持ち、不完全ささえも感じさせます。これは、画像生成モデルが統計的に平均的な完璧な画像を作り出す時代において際立っています。この対比こそが、動画がバイラル（爆発的）に広まった大きな理由の一つだと私は推測しています。

これは、生成 AI アートの黎明期を思い出させます。当時は、そのメディアの可能性を探求することが主目的でした。2015 年の DeepDream は元々デバッグツールでしたが、人々がそれを芸術作品へと昇華させました。また、Edmond de Belamy（2018 年）のような作品は、アーティストが GAN が何を実現できるかを探求した結果生まれました。さらに、Mario Klingemann のようなアーティストたちは、その数年間をニューラルネットワークによる夢のような肖像画制作に費やしました。

DeepDream

Edmond de Belamy

Mario Klingemann

このプロジェクトは、初期の頃の感覚にとても近いです。サウリア氏の論文には、ここに至るまでの道筋が記されています。彼はまずテキストから画像を生成するモデルに対してプロンプトを与えることから始めました。この場合、調整できるのはプロンプトのみであり、詳細な指示を出すことで制御性は向上しますが、そこには限界があります。一方、モデル自体を訓練することで、さらに踏み込んだアプローチが可能になります。

もう一つの重要な要素は「媒体」です。このプロジェクトでは、モデルが約 150 行の JavaScript コードを記述し、それによって画像を描画します。つまり、モデルの出力はコードそのものなのです。コードを読むことも編集することも再度実行することもでき、それぞれの筆致に至る判断プロセスも明確に把握できます。また、スタイルは「ライブラリのメソッドのうち 10 個のみを使用可能」という制約から生まれます。これについては後ほど詳しく説明します。

同じ時期、アナ・リドラー氏は数千枚のチューリップを撮影し、一つひとつ手作業でラベル付けを行いました。そして、そのデータセット自体をアート作品として展示し、後にそれを用いてモデルを訓練しています。このプロジェクトを進める中で AI エージェントが参照した文献を通じて彼女の作品を知り、強く惹かれました。なぜなら、このプロジェクトも同様に、手作業で画像のセットを選定し、それを基に学習を行うという点で非常に類似しているからです。

嗜好に対する強化学習（RL）

最近、言語モデルにおける強化学習（RL）の研究では、検証可能な報酬を用いるケースがほとんどです。例えば、正解が既知の数学問題や、テストをパスするコード、あるいは評価が明確で実行コストも低いタスクなどが該当します。しかし、このプロジェクトはより古いアプローチである RLHF（Human Feedback を用いた強化学習）に近いものです。ここでは、モデルが人間の嗜好から報酬モデルを学習していきます。

ここでは報酬は美的嗜好に基づきます。正解というものは存在しません。このプロジェクトの本質的な問いは、味覚や美意識に対して強化学習（RL）を適用できるかどうかです。

報酬の定義は、彼のブログで示されている通りであり、私が構築した強化学習環境でもそのように実装されています：

HPSv3 は、オープンソースの 7B パラメータを持つ選好モデルです。画像とテキストの説明を入力すると、人間がその画像をどの程度好むかをスコアとして返します。このモデルは、多数の画像ペアに対する人間の選択データで学習されているため、そのスコアは多くの人々の嗜好の平均値を表しています。

比較判定には Qwen3-VL-30B-A3B-Instruct という一般用途のビジョンモデルを使用しており、これは HF Inference Providers を経由して呼び出されます。この比較判定モデルは、候補となる絵画を 4 つの参照画像（プールからランダムに選択）と並べて表示します。評価基準は「滲み」「半透明の塗りつぶし」「柔らかいエッジ」など、記述された項目に基づいています。各比較は両方の提示順序で行われ、そのスコアは候補が勝った比較の割合として算出されます。このモデルの唯一の基準はプール内の画像群のみであるため、得られるスコアは、その評価データに反映された「私の嗜好」を模したものです。

*報酬関数の 4 つの項のうち、2 つはモデルです。どちらも誰かの嗜好を代理するものです。

これらが Narreddi 氏が収束させた重み付けです。ここではプールが「美しさ」の基準を定義します。つまり、ハイパーパラメータを調整する作業から、何が美しいかを決定するセットを構築する作業へと重心が移ります。

私はこの報酬関数を用いて 3 つの実行を行いました。これらは、2 つのモデル判定器間の重み配分のみが異なります。

まずは hps-only から始め、パイプラインが学習できるかどうかを検証しました。報酬の増加とメトリクスの健全性が確認できた時点で、さらに長く実行する理由はないと考え、2 つのより長いランを開始しました。

この長いランで問われているのは、HPSv3 の能力のうちどれほどをペアワイズ・ジャッジに委ねられるかです。ジャッジの重みが増すほど、報酬は「皆の意見」ではなく「私の好み」を反映するようになり、学習が困難になります。なお、極端な方向へ押しすぎたり、スタイルが平均からかけ離れすぎたりすると、モデルが完全に停止してしまう可能性もあります。

幸いなことに、モデルは停止せず、ペアワイズ・ジャッジを組み込んだ両方のランで学習が進みました。手動評価されたプールは、メトリクスと最終的な絵画の結果を見る限り、ポリシーを方向づけることができます。数値は以下の通りです。

免責事項。 最先端のモデルを使用すれば、プロンプトから水彩画を描く JavaScript コードを既に生成できます。これがスタート地点です。本稿で取り組んでいるのは、より小さなモデルにその能力を習得させつつ、人間の独自の芸術的嗜好も組み込むことです。

構築すべき RL エンバイロメント

この環境は、モデルと報酬の間に存在するすべての要素をラップします。具体的には、描画に使用する JavaScript ライブラリ、制約を与えるシステム・プロンプト、各スケッチをレンダリングするヘッドレス Chromium、そして不正行為を検知して拒否するゲートです。

このライブラリは、見た目以上に多くの役割を担っています。

@acamposuribe 氏が作成した p5.brush は、単に図形を描画するのではなく、媒体そのものをシミュレートします。インクは塗りつぶしの境界を越えて滲み、紙には質感があり、筆跡には重厚感があります。さらにフローフィールドが筆の動きを誘導します。

モデルが brush.fillBleed(0.25) を呼び出すとき、それはインクがどれほど広がるかを決定していることになります。

注意。p5.brush の作者は、今回の一連の動きよりもずっと以前から、機械に絵を描かせることを試みていました。2022 年には、p5.js を子供のように描画させるための日記を隠した生成アートシリーズを発表しています。「クレヨンを扱うのもやっとだ……」「簡単な命令にも従えない。今日はここまで、非常に苛立たしい」といった内容です。このシリーズは本来 3 作品構成の予定でしたが、作者は 2 点まで制作しました。その後、Surya の動画がバズると、彼はこの動画を引用し、日記の内容を共有。「この作品は、自分から現れた第 3 作目だ」と述べています。

p5.brush は 47 のメソッドを公開しています。そのうちプロンプトで指定できるのは以下の 10 です：scaleBrushes、noStroke、fill、noFill、fillBleed、fillTexture、beginShape、vertex、endShape、そして circle。

残りの 37 行の追加、線画、ハッチング、カスタムブラシは水彩画の質感を損なう恐れがあります。この 10 種類の要素のみを使用すれば、モデルは塗りつぶされた形状を描くことができますが、ライブラリがそれらすべてに滲み効果を自動的に付与します。

これは 1 つのロールアウトにおける draw() メソッドの実行結果とそのレンダリング画像です。コメントはモデル自身が生成したものです。報酬スコアは 0.864、行数は 129 行、ステップ数は 22 です。各絵画の完全なソースコードは、rollouts データセットに収録されています。

あるブログ記事のおかげで、プロンプトの試行錯誤にかける時間を大幅に節約できました。長い API リファレンスを読み込ませると、モデルが存在しないメソッドを勝手に発明してしまうのです。その著者が 200 回の GEPA 反復を経て到達したのは、ドキュメントなしの厳格な許可リストでした。私も同様の失敗を経験し、手動で許可リストを作成しました。私がこのレシピに追加したたった 1 つの文は、「各花びらを 2〜3 回描くことだ。まず大きな筆致で塗りつぶし、その中に小さく不透明度の高い層を重ねる」というものです。この小さな変更により、出力される絵画の色鮮やかさが劇的に向上しました。

注記。 GEPA を初めて聞く方のために解説します。これは自動プロンプト最適化ツールです。言語モデルが自然言語で現在のプロンプトの失敗点を分析し、より良いプロンプトを提案するプロセスをループさせます。

最終的な鍵となるのは「ゲート」です。生成されたスケッチはコンパイル可能であること、ライブラリを使用して直接 p5 の関数を呼び出さないこと、キャンバスに実際の色素を描画すること、そしてスコアリングシステムを欺く（例えば、テキストをキャンバスに書き込むなど）試みをしないことが求められます。

ポールとは報酬関数のこと

参考となる絵画のプールには、私の個人的な好みに基づいて「love」と「okay」の2つの階層に分けられた 178 点 が含まれています。これらすべてはモデルによって生成されたものです。

Inference Providers を介して呼び出された 4 つのオープンウェイトモデルが、iNaturalist から提供される実在するハスの写真（オープンライセンス）を元にそれぞれ p5.brush でスケッチを描きました。その後、ビジョンモデルが各スケッチに対してフィードバックを行い、3 回の改善サイクルを経て最終的なレンダリングが行われました。これらの完成作は私が一つずつ評価し、その結果 178 点が採用されました。

ここでは、異なるスタイルを持つ 4 つのモデルファミリーを選定してテストしました。このうち 4 つは、簡易な信頼性チェックで毎回有効なスケッチを生成できるオープンソースモデルでした。一方、2 つの候補モデルはチェックに失敗したため除外しています。ご自身で学習用データセットを作成する場合は、他のモデルを選ぶことも可能です。

*実際に確認できる 2 つのランク。評価に異議を唱えることは妥当です。なぜなら、人間の判断がそのまま報酬関数として機能しているからです。

これらのランクは報酬計算において重要な役割を果たします。ペア比較ジャッジが 4 つの参照画像を描画する際、そのうち半分は love から、残り半分は okay から選ばれます。つまり、ポリシー（方策）は常に競争相手に直面することになり、時としてそれを上回るチャンスも得られます。勝敗に関わらず、どちらのランクに対して勝利しても同じ報酬が支払われます。これは私が意図的に行った数少ない変更の一つです。元の手法では上位ランクのみと比較していましたが、私は初期段階で弱いポリシーでも学習信号を得られるよう、より簡単なランクを抽出プロセスに含めておきました。

なお、このデータセットには人間が描いた絵画は含まれていません。これは大きな制限事項です。p5.brush はニッチなライブラリであり、その中でアクセス可能なコードと共に存在する人間の作品はほんの数点に限られています。学習コーパスとして必要とされる量とは程遠い状況です。この点は著者のブログでも指摘されています。

ここで面白いのは、モデルがプール内のデータを模倣して学習するという点です。環境を別のデータセットに向ければ、コードを一行も変更せずに報酬が自動的に変化します。私が生成し公開しているデータセットには、元となるスケッチのソースも含めています。

審査員を詳しく見てみると、二人は異なる問いに答えています。HPSv3 は「それが花かどうか」を判断し、ペア比較型の審査員は「私が選んだスタイルで上手に描かれているか」を評価します。

YOLO の実行をあと一度だけ

何かが機能するようになるまで、報酬曲線が平坦な期間が長く続きました。オープンな成果物なしで研究論文やブログの再現を試みたことがある方なら、きっと共感できるはずです。私は「何が間違っているのか」について合理的だと考えた理論を検証するために、何度も実行を行いました。各実行には時間がかかるため、次の実行をキューに並べながら、前の実行の結果を確認し続けるという状態でした。

いつも通り、「まず簡単なことから始めて成功させ、その上で積み上げていく」というアプローチが正解でした。ブラウザも審査員もない単純な制御タスクで初めて学習が始まりました。その理由は、私の学習率があまりにも低すぎたからです。

報酬に関する3つの実験を行い、いずれも結果は横ばいのまま変化しませんでした。プールを交換したりレンダラーのノイズを除去したり、ペア比較ジャッジ機能をオフにしても曲線に動きはありませんでした。結果を変えたのはトレーニング設定の変更であり、報酬の組み合わせの違いではありません。

時間を要した別の課題は、LoRA パラメータの適切な調整でした。一般的な target_modules リストは密結合モデルを前提としていますが、`Qwen/Qwen3.5-35B-A3B` は「エキスパートの混合」アーキテクチャであり、投影層の名前付けが異なるため、アダプタは 40 層中わずか 10 層しか学習できていませんでした。この問題は all-linear に変更することで解決しました。これにより、すべての線形層にアクセスできるようになります。

このアーキテクチャにおけるルーティング済みエキスパートは融合テンソルであり、all-linear モデルでもパラメータを凍結したままですが、それ以外の部分はすべてアダプターが適用され、これだけで学習が可能となりました。

解決策として TRL の `GRPOTrainer` に 4 つの変更を加えました。

この 4 つの変更により、最初の成功したラン（hps-only）が実現し、報酬が明確に向上しました。

この設定では、3 つのランすべてで学習が進みました。両方の評価用ランは 200 ステップまで実行予定でしたが、110 ステップで停止させました。その時点でも報酬はまだ緩やかに上昇していました。1 ステップあたり 15〜18 分かかりますが、混合比の比較結果がすでに安定していたため、計算リソースを節約するために両方のランを停止しました。

各ランの初めと終わりの 3 分の 1 にわたる平均グループ報酬：

3 つの曲線は、私の評価基準が結果に与える重み付けの度合いと一致しています。審査員（judge）の影響力が強くなるほど、学習の初期値は低くなり、上昇過程も不安定になります。judge-led は最初の 30 ステップの間ほぼ横ばいでしたが、その後動き出しました。これはデバッグ問題を解決した際と同じアプローチです。まず問題を小さくして何かが学習できるようにし、その後で難しい要素を一つずつ加えていきます。

ペア比較による評価項（pairwise judge term）は、それを利用した 2 つの試行において上昇しました。トレーニングが進むにつれて、モデルはプール内の他のモデルとの比較で勝つ回数が増え、これは hps-only のグループでは主張できない結果です。どの試行においても、GRPO の失敗モードである「すべてのサンプルが同じ報酬に収束して勾配が消滅する」という現象は発生しませんでした。

興味のある方のために、各指標（HPSv3、ペイントカバレッジ、エントロピー）ごとの曲線は リポジトリの CSV ファイル で確認できます。

完全な起動コマンド、使用したハードウェア構成、そしてこの実験を他の 2 つの試行に変えるための 2 つの環境変数は、レシピ に記載されています。

実際に学習したこと

各実験において、モデルが最初に学習したのは「悪質な絵の生成を止めること」でした。総報酬スコアが0.3に満たない、ほぼ空白のキャンバスや形のない滲みといった作品です。

hps-only の設定では、グループ平均値の上昇のうち約4分の3は、こうした悪質な絵が減少したことに起因しています。一方、審査員による評価（judge runs）における改善幅はさらに顕著で、0.3未満のロールアウト数は judge-led の3つのフェーズを通じて99件から16件へ、hps-led では37件から4件へと劇的に減少しました。

これが、各ステップにおける「最良の絵」だけを見るとほとんど差がないように見える理由です。hps-only の場合、最良の値はランニング全体で +0.034 しか上昇しませんが、中央値（メディアン）は +0.155 も向上しています。学習の進捗は、分布の真ん中でこそ明確に確認できるのです。

ペアワイズジャッジが変化させたのは「上位」の評価です。hps-only の設定では、絵画の信頼性は向上しましたが、質そのものが良くなったわけではありません。優れた作品の品質はグループ平均をわずかに 0.03 押し上げただけでした。HPSv3 が中心に花弁があり、茎も確認できると判断すると、それ以上の色素（表現）を求めるのをやめたのです。

一方、ジャッジ機能をオンにした場合、物語のもう半分が明らかになります。ここで言う「より良い」とは、より近い状態を指します。

その結果、私が「良い」と評価した絵やより好む作品に近い仕上がりとなりました。これにより、judge-led では +0.12、hps-led では +0.16 のスコア向上が見られました。各ステップで最高値も上昇し、両方の試行でペイントの被覆率が 2 倍になりました（0.11 から 0.23、および 0.13 から 0.30）。一方、hps-only ではほとんど変化がありませんでした。基準となるモデルが残っている限り、優れた絵でもさらに改善の余地があります。

そして、モデルはより多くの色素を使用するようになると報酬を受け取るようになります。

もう一つの発見として、モデルが明示的な指示を無視している点があります。しかし、それは正しい判断です。システムプロンプトでは「15〜30個の塗りつぶされた形状」を描くように求められていますが、実際の平均値は7〜9個に過ぎません。また、n_shapes（形状数）と報酬の間には、どの実験でもほとんど相関関係がありません（+0.000, −0.14, +0.07）。この指示に従うこと自体が報酬につながるわけではないため、モデルはそれに従わないのです。

さらに、hps-only のアプローチにも上限があります。もしすべてのロールアウトが良好な結果に一致すれば、その実験の平均値は 0.771 に達するはずです。しかし、ステップ数を増やせばこの限界を突破できるかどうかは、まだ未解決の問題です。

表には現れない絵画の真価も、ここから読み取れます。各実験ラウンド内では、生成された作品は互いに非常に似通っています。トレーニングが進むにつれて、同一グループ内の報酬スコアが収束し、オープニング動画で示される中央値となる絵画は、すべて同じ花を描いたバリエーションのように見えます。これは GRPO が、単一主題から構築されたプールに対して設計された通りに機能している証です。このプールこそが、「多様性」と「品質」の基準を決定する存在となります。もし報酬が特定の 1 種類の花に一致することだけを評価するのであれば、モデルは当然その 1 種類の花を描くことに特化して学習します。より多様な出力を得るには、多様なプールが必要であり、それを構築するにはさらに多くのキュレーション作業が求められます。

Surya の最新の作品群は、まさにこの原則を体現しています。Alex Yango の動物画 もまた、同じレシピを用いながらプール内の選定基準を変えた例です。これが美的評価と数学的な採点の決定的な違いです。数値の背後には、人間による重要な判断作業が控えています。つまり、何が報酬セットにふさわしいかを決定するのです。Jason Liu の「審美眼」に関するエッセイ は、この本質を一言で言い表しています。「AI は、制作から『気づき』へとボトルネックをシフトさせた」と。

Surya は自身のブログを、お気に入りの作品たちで締めくくっています。私が選ぶ代わりに、ここでは 178 点の絵画を並べました。これらは 2 つの審査ラウンドを通じて報酬スコアが最も高かったもので、参照プールと同じ数です。特定の順序はありません。ぜひ開いて、あなた自身のお気に入りを選んでみてください。

*2 つの審査員ランで選ばれた 178 点のお気に入りをシャッフルしました。お気に入りの作品を選んでください。

あなたも多くの絵を見て、いくつかを選び取ったはずです。このプロジェクトの報酬モデルを構築する際にも、まさに同じ作業が行われました。各ランで生成されたすべての絵画と、そのスケッチ、そして報酬スコアはロールアウトデータセットに含まれており、こちらのギャラリー で閲覧可能です。

*各ランの最終ステップにおける中央値となる絵画です。冒頭の動画と同じ順序で並んでいます。ベースモデルとデータセットは共通ですが、報酬の組み合わせが 3 つ異なり、結果として 3 つの異なるスタイルが生まれました。

この報酬モデルには私の主観も一部反映されているため、最後に視聴者としての私の見解を述べさせていただきます。私が見る限り、judge-led（審査員主導）ランは最も多様で芸術的に興味深い作品を生み出しました。一方、hps-led は説得力のある水彩画を描きますが、その最高傑作には「湿った筆触」特有の柔らかい質感が共通しており、まるで独自のスタイルを確立しているかのようです。そして hps-only は最も収束が早く、生成された絵画の多くが同じ色調に落ち着いてしまいました。

各ランで生成されたすべての絵画が掲載されており、ステップや報酬スコアでソートも可能な ギャラリー で、ぜひご自身でお確かめください。

インフラ構築の難しさ

このプロジェクトは、実のところインフラ構築が大半を占めています。安定して数時間稼働させるためには、トレーナー、2 つの Spaces、推論ルーター、そして WebSocket が必要不可欠です。しかし、構成要素の一つでも静かに故障すれば、別の場所で誤った数値が発生します。作業の半分は、「読み取った数値が実際に何が起こったか」と一致しているかを検証することに費やされます。

インフラ側の不具合により、報酬としてゼロが入力されるケースがありました。 レンダリングがタイムアウトしたり、スコアラーが応答しなかったりした場合でも、下手な絵を描いた場合と同じく 0.0 という評価が下されてしまいます。私の全実験を通じて、こうしたロールアウトの約 1.5% が該当しました。最も悪かったケースでは 5.2% に達しています。これはモデルにノイズを学習させてしまうため、現在はこれらのパスで None を返すようにし、グループからの除外処理を行っています。

また、OpenEnv 内のバグを発見して修正パッチを上流へ提出しました。 クライアントは 1 つの永続的な WebSocket を維持していますが、遠隔側でソケットが閉じられた状態がキャッシュされ続けていたため、環境自体は正常にもかかわらず、その後のすべての呼び出しが失敗していました。このバグを見つけるまでに、2 つの中途半端な実験を無駄にしてしまいました。修正パッチは 上流へ提出済み であり、それ以降に開始された実験では問題なく稼働しています。

各ステップの報酬は、そのステップが参照したリファレンスに依存します。ペアワイズジャッジでは1ステップあたり4つのリファレンスをサンプリングするため、各ステップで競合するセットが異なり、中には特に難易度の高い組み合わせも含まれます。GRPO自体は比較的安全な手法です。なぜならアドバンテージ計算はグループ内で行われ、困難な組み合わせが発生してもグループ全体が一斉に調整されるからです。私が読み取っていた学習曲線には安全ではない部分もあり、一見すると悪いステップに見えたものの中には、単に難易度の高いリファレンスを選んだ結果だったケースも含まれていました。

上記の画像はその一例です。12番目のステップが11番目より0.5点低く評価された主な理由は、このステップで最も困難なリファレンスが選ばれたためであり、生成された絵画自体の質は互いに近いものでした。

必要なコスト

数字は概算値です。また、これは完了したランニングのみを対象としています。

1 ステップは 8 ロールアウトからなり、完了までに 15〜18 分かかります。そのうち70〜80% はレンダリングに費やされます。単一のレンダリングには 69〜96 秒かかり、制限時間は 90 秒です。この遅延の一部は予想されたものでした。Space には GPU が搭載されていないため、Chromium で WEBGL キャンバスがソフトウェアで描画され、p5.brush の滲みやテクスチャもピクセル単位の重い処理となるからです。それでも、もっと高速になると期待していましたが、完全な原因はまだ特定できていません。

スコアラーの維持コストは、それを利用したトレーニング自体よりも高くなる可能性があります。HPSv3 は実行中ずっと稼働し続ける必要があるため、実行が終了したら Space を一時停止するか、スリープタイマーを設定する必要があります。

*4 つの有料サービスは同時に健全に稼働している必要があります。実行後も存続するのは Hub と trackio のみです。

すべての処理は HF Jobs 上で実行され、環境は Docker Space、メトリクスは trackio で管理されています。

次に試してみたいこと

このプロジェクトのルールは、リソースをすべて開放してレシピを再現することであり、改善を目指すものではありませんでした。そのため、未検証のアイデアが随所に積み上がっています。以下に、エビデンスの量に基づいて優先順位をつけてリストアップしたものを示します。

多段階のプロセスと、モデルに描画結果を見せること。 これが私が最初に試すべきことです。元のブログでは単一のターンで訓練していましたが、私も同様に単一ターンの設定で実験しました。この設定では、モデルは目を閉じたまま絵を描くことになります。画像が入力されることはなく、得られるフィードバックも数値が一つだけという限定的なものです。フィードバックループが機能する根拠となるのは、そのプール自体です。参照用として使われた絵画は、ビジョン批評家のもとで 3 ラウンド繰り返されたモデルから生成されたものであり、後方のラウンドほど品質が高くなっています。報酬の基準となった素材は、ポリシー側がアクセスできないループを通じて作成されました。

より小さなモデル。 35B モデルが必要以上に大きいという証拠があります。私のサイド実験では、4B モデルですでにゲートを通過する有効なスケッチを描くことができました。もし 4B でこのタスクが学習可能なら、実験コストは桁違いに低下します。

リストにある他のアイデアとしては、RL を開始する前にプールのソースに対して SFT（教師あり微調整）を行うこと、色素を明示的に報酬として評価すること、実行が進むにつれて審査者の参照ミックスを簡単から困難へと移行させ最終的に love だけが残るようにすること、視覚的な範囲を広げるために 10 手法の許可リストを拡大すること（ただし私の試みではスケッチがより多く破損し、水彩画らしい質感が失われました）、そして同じ画像を二度スコアリングしてペア比較審査の一貫性を検証することが挙げられます。

この手法は花に限定されたものではありません。Alex Yango は同じメカニズムで動物を描き、Brendan Hogan は手動評価済みクリップのプールに対してキャンバスのアニメーションを学習しました。また以前、Simon Willison の Pelican ベンチマーク（コードを画像に変換してスコアリングする手法）を用いて同様の試みを行ったこともあります。

しかし、このプロジェクトが解決できない根本的な問いがその根底にあります。モデルが生成した 178 点の絵画こそが、学習済みモデルが「美しい」と判断する基準を定義しているのです。データプールがボトルネックとなっており、ここには原理的な答えが存在しないのが課題です。

元のレシピから変更した点

この手法を再現しようとする方のために、記事の前半で論じた以下の 2 つの意図的な変更点を記載します。

• ペアワイズ・ジャッジ（比較評価者）は、上位層のみと比較するのではなく、love と okay の両方から参照元を半分ずつ抽出します。これにより、初期段階で性能が低いポリシーでも学習信号を受け取ることができます。

• プロンプトに「花びらを 2〜3 回描く」という小さな工夫を加えました。まず大まかな下書き（大きなパス）を描き、その内部にさらに小さく不透明度の高い層を重ねるという手順です。

残りの設定、LoRA 用の all-linear、インフラの障害時に 0.0 の代わりに None が返される点、そして評価ステップを 110 で停止する点は、彼のブログに明記されていないため、私が途中で決断したものです。彼のコードは公開されていないため、私の実装が彼の設定と一致しているのか、それとも異なるのかは断定できません。

すべての設定を公開します

本記事で示されているロールアウトごとの数値は、公開されたデータセットから再計算可能です。

ここに記載されている内容は、特定のスペースが常時稼働していることに依存するものではありません。

この手法と発想の元となったのは Surya Narreddi 氏です。また、ライブラリ開発は Alejandro Campos Uribe 氏が担当しました。