TRLとOpenEnvを使用してコーディングモデルに水彩画を描かせるトレーニング

Hugging Faceは、JavaScriptコードを記述することで水彩画を生成するコーディングモデルをトレーニングするプロジェクトのオープンな再現版を公開しました。TRLとOpenEnvを活用することで、このプロジェクトは、強化学習（RL）が「好み」や美的嗜好に適用可能であることを示しており、モデルが統計的に平均的な画像を超えて、特定の芸術的なスタイルへと移行できることを可能にします。

美的嗜好に対するRL

このプロジェクトの核心的な目的は、RLが検証可能な事実ではなく、美的嗜好の最適化に使用できるかどうかを判断することです。報酬関数は、モデルを特定の水彩画スタイルへと導くために設計された4つのコンポーネントの加重混合で構成されています：

  • Pairwise Judge (60%): ビジョンモデル（Qwen3-VL-30B-A3B-Instruct）が、候補となる絵画を、手作業でキュレーションされたプールからランダムに選択された4つのリファレンスと比較します。これにより、キュレーターの特定の好みがエンコードされます。
  • HPSv3 (30%): オープンな7Bの嗜好モデルであり、テキスト記述に基づいて、一般的な人間がその画像をどの程度好むかをスコア化します。
  • Gate (5%): スケッチがコンパイル可能か、許可されたライブラリを使用しているか、そして「ズル」をせずに（例：キャンバスにテキストを書くなど）実際の顔料を使用しているかを確認するバイナリチェックです。
  • Length (5%): より長いコードスニペットへと向かうソフトな推進力です。

これらの判定基準の影響をテストするために、3つのトレーニングランが実施されました：

Run Pairwise Judge Weight HPSv3 Weight Result
judge-led 0.60 0.30 最も多様で芸術的に興味深い結果。
hps-led 0.30 0.60 一貫した「ウェット・オン・ウェット」の質感を持つ、説得力のある水彩画。
hps-only 0.00 0.90 信頼性は高いが、似たような色やスタイルにすぐに収束してしまう。

技術的な環境と制約

トレーニングパイプラインは、モデルの出力をラップし、それを視覚的なレンダリングに変換する特化型のRL環境に依存しています。

p5.brush ライブラリ

基本的な形状を描画する代わりに、モデルは p5.brush ライブラリを使用します。これは、顔料の滲み、紙の質感、フローフィールドなどの物理的な水彩画の特性をシミュレートします。水彩画の美学を維持するために、モデルはわずか10個のメソッド（例：fillBleed, fillTexture, beginShape）のみに制限された厳格なホワイトリストを使用します。

リファレンス・プール

「好み」は、love と okay のティアに分けられた178枚の絵画のリファレンス・プールによって定義されます。これらの画像は、4つのオープンウェイトモデル（GLM-5.2, Kimi-K3, Qwen3-Coder-Next, および Qwen3.5-122B-A10B）によって生成され、ビジョン・クリティックを通じて洗練され、その後手作業で評価されました。トレーニング中、pairwise judgeは両方のティアからリファレンスを引き出し、ポリシー・デベロップメントの初期の弱い段階でもモデルが信号を受け取れるようにします。

トレーニングの実装と最適化

プロジェクトでは、TRLの GRPOTrainer と Qwen/Qwen3.5-35B-A3B モデルを使用しました。学習を促進するために、いくつかの重要な設定変更が必要でした：

  • Learning Rate: 2e-5 から 5e-5 に増加。
  • Scheduler: 学習率が早すぎる時期に減衰してしまうのを防ぐため、linear から constant_with_warmup に変更。
  • Reward Scaling: 単一のゲート・リジェクションがグループ全体のadvantagesの縮小を招かないよう、scale_rewards を none に設定。
  • LoRA Target Modules: MoEアーキテクチャにおけるアダプターがすべての線形層に到達するように、all-linear に変更。

主な調査結果と学習成果

分布のシフト

すべてのランにおいて、モデルはまず「悪い」絵画（ほぼ空白のキャンバスや形のないウォッシュ）を排除することから学びました。hps-only ランでは、改善は主に分布のメディアン（中央値）に現れました。しかし、judge-led と hps-led ランでは、分布の上位層の品質も向上し、モデルがキュレーションされたプールのスタイルに合わせることで報酬を得るため、塗料のカバー率が2倍になりました。

制約 vs 報酬

モデルは、報酬に結びついていないシステムプロンプト内の明示的な指示を無視することを学びました。例えば、15-30個の塗りつぶされた形状を描くという要求は、形状の数が報酬と相関していないため、7-9個の形状を描くという結果に置き換えられました。

インフラストラクチャとコスト

パイプラインは、Hugging Face上でエンドツーエンドでホストされており、トレーニングには HF Jobs、RL環境と HPSv3 スコアラーには Spaces、pairwise judge には Inference Providers を利用しています。

  • Compute: 110ステップの単一ランは、1枚の H200 GPU で約34時間かかりました。 | Bottleneck: レンダリングは主な時間消費要因であり、ステップ時間の70-80%を占めています。これは、ヘッドレス Chromium が CPUベースの Space で WEBGL canvas をソフトウェア・レンダリングしているためです。

将来の方向性

著者は、将来のイテレーションのためのいくつかの潜在的な改善策を特定しています：

  • Multi-step Feedback: リファレンス・プールが作成された方法と同様に、モデルが自身の絵画を視⁡て、それを洗練させるループを実装すること。

  • 定期的な Scaling: より小さなモデル（例：4B）のテスト。初期実験では、それらが有効なスケッチを生成できることが示唆されています。

  • SFT Pre-training: RLを開始する前に、プールのソースに対して教師あり微調整（Supervised Fine-Tuning）を行うこと。

Sources