- 報酬関数を9項目から4項目へ簡素化し、訓練がプラトーを突破
- 絶対スコアをやめ、手動評価済みの参照作品とペア比較する報酬に変更
- 400行のAPIリファレンスは幻覚を招き、8メソッドのallowlistで改善
プロンプトだけでは編集できない問題
このプロジェクトは、画像生成AIに対し「プロンプトで指示する以外に参加手段がない」という不満から始まった。生成された画像を直接編集できず、少し変えたい場合も再びプロンプトを打ち直す必要がある。そこで著者らは、言語モデルにコードを書かせて画像を生成する方式を採用した。コード自体が生成物なので、プロンプトに戻らずに細部を編集できるという利点がある。
具体的には、モデルがp5.brushという水彩画向けのJavaScriptライブラリでスケッチを書く。そのコードをPuppeteer（ヘッドレスブラウザ環境）で描画し、PNG画像を得る。そして画像を審査して報酬を返し、GRPOという強化学習アルゴリズムでモデルを更新する。このループを訓練中に何千回も繰り返す仕組みだ。
9項目の報酬はどれも同じことを測っていた
最初の報酬関数は9つのシグナルで構成されていた。コンパイルが通るか、p5.brushを使っているか、コード長が約3,000トークンに近づくか、HPSv3という人間の好みを模したスコア、GPT-5.4とGeminiによるプロンプト忠実度の判定、さらに認識可能性・美学・技法・深さの4つの品質評価である。
しかし訓練は報酬0.65付近で頭打ちになった。生成物はどれも同じような平たい花のクリップアートで、報酬は上がり続けるのに能力は改善しなかった。副報酬を個別に調べると、4つの品質評価とプロンプト忠実度は互いに0.85〜0.95の相関があり、同じものを5回測っていた。コード長は訓練ステップ30で飽和し、その後は勾配を生まなかった。実質的に分散のあったHPSv3の重みはわずか0.10だった。
ペア比較と参照プールへの転換
対策は2つある。1つ目は絶対評価をやめ、ペア比較に切り替えることだ。旧方式は生成画像を0〜10点で評価させていたが、スコアが0近くに圧縮されてしまった。新方式では、生成画像と参照プールから選んだ2枚の画像を審査モデルに並べ、「どちらが良い水彩画か」を選ばせる。勝った割合を報酬にするため、評価のダイナミックレンジが広がる。
2つ目は、手動評価済みの参照プールを構築することだ。1,664枚の生成画像を1枚ずつ「love」「okay」「nope」に分類し、love判定の117枚を比較プールの核とした。以降の出力は、著者が良いと判断した作品群と比較される。次のステップとして、この評価データで小さな報酬モデルを訓練する本格的なRLHFが考えられるが、今回はそこまで至っていない。
シンプルな報酬で性能が向上
新しい報酬関数は、コンパイルとブラシ使用の2値チェック（0.05）、コード長の2値チェック（0.05）、HPSv3（0.30）、参照プールとのペア比較（0.60）の4要素に整理された。ベースモデルも訓練データも同じまま、この報酬で再訓練すると、以前のプラトーに3倍速で到達し、その先も改善を続けた。
生成コードも、それまでの約13,500トークンから2,000トークン未満に圧縮された。長いコードを書けば良いわけではなく、勝てる構図は簡潔なコードで表現できることをモデルが学習したとみられる。旧報酬ではコード長を約3,000トークンに近づけるランプが報酬の約3分の1を占めており、これが冗長なコードを助長していた可能性がある。
システムプロンプトの設計も重要
報酬設計だけでなく、システムプロンプトも試行錯誤の対象だった。初期のプロンプトには400行のp5.brush APIリファレンスが含まれていたが、モデルは存在しないAPIを自信満々に作り出してしまった。そこでGEPAというプロンプト最適化ライブラリを使い、味覚を基準にした7ショット判定で200回の反復を行った。
最適化の結果、APIリファレンスを完全に捨て、8つのブラシメソッドだけを許可する厳格なallowlistを持つプロンプトに収束した。3回中3回の生成でハイビスカスの形が視認できるようになったのは、そのプロンプトを採用してからだ。長いAPIドキュメントは幻覚を招き、短く断定的なallowlistの方が出力を制約できるという知見が得られた。
| 項目 | 旧報酬関数 | 新報酬関数 |
|---|---|---|
| 信号数 | 9項目 | 4項目 |
| 評価方法 | 0〜10点の絶対評価 | 参照プールとのペア比較 |
| HPSv3の重み | 0.10 | 0.30 |
| コード長の扱い | 約3,000トークンへのランプ | 2値チェック |
| 参照プール | なし | 手動評価済み117枚 |
Reinforcement learning needs a verifiable reward. A math problem is right or wrong. A game is won or lost. Aesthetic preference is neither.
強化学習には検証可能な報酬が必要だ。数学の問題は正しいか間違いかで判断でき、ゲームは勝ちか負けかで判断できる。美的嗜好はどちらでもない。
今後の見通し
プロジェクトは最終訓練ランが進行中とみられる。今後、手動評価データを使った小さな報酬モデルの訓練（本格的なRLHF）に進めば、参照プールとの毎回の比較を介さずに美的判断を適用できる可能性がある。また、この報酬設計の考え方が他の主観的タスク（デザイン、音楽、文章など）へ応用できるかが次の論点になると考えられる。ただし、現時点では公開情報が限られており、最終結果や再現性の評価には追加の情報が必要だ。
日本の開発者・IT企業にとっての意味
日本のIT企業にとって、この事例は主観的品質を扱うAI製品の開発に直接関係する。報酬関数を設計する際、複数の品質指標を足すだけでは互いに相関した指標を重複して評価し、モデルの学習を停滞させることがある。相対比較と参照プールを使う方法は、文章の要約や画像生成、UIデザインなど『正解がない』タスクでも応用できる。また、システムプロンプトに長いAPIドキュメントを入れるとモデルが存在しないAPIを幻覚するという結果は、コード生成AIを社内ツールに組み込む際のプロンプト設計にも示唆を与える。生成物をコードとして編集可能にする考え方は、デザインワークフローを変える可能性があるが、生産性への影響はまだ未知数だ。
気になる点
- 従来の画像生成モデルより優れているのか？
- 著者は「これがより良い画像生成方法だとは思わない。実際、ずっと遅い」と述べており、実用面では従来型のモデルに劣るとみられる。価値は、生成物がコードとして編集でき、プロンプト以外の参加手段を提供する点にある。
- 参照プールはどのように作ったのか？
- モデル自身が生成した1,664枚を手動で「love」「okay」「nope」に分け、loveの117枚を比較プールの核にした。p5.brushがニッチなライブラリで人間の制作例を十分に集められなかったため、プールはすべてモデル出力で構成されている。
- 同じ手法を自社のプロジェクトで再現できるか？
- 必要な技術要素（p5.brush、GRPO、GEPAなど）は示されているが、訓練コードやデータセットの公開有無、必要な計算資源はこの記事からは不明。手動評価1,664枚などの工数をかければ再現の可能性はあるが、追加情報なしに判断するのは難しい。
用語解説
- p5.brush
- 水彩画を描くためのコードベースの描画ライブラリ。p5.jsの拡張としてJavaScriptで利用され、今回のモデルにコード出力させる対象。
- GRPO
- 強化学習のアルゴリズムの一種。複数の出力をサンプリングし、その相対的な報酬からモデルを更新する手法。
- HPSv3
- 人間の画像の好みを予測するように訓練されたスコアリングモデル。生成画像の品質評価に使われた。
- GEPA
- プロンプトを進化的に最適化するライブラリ。スコア関数に対してプロンプトを反復改良する。
- RLHF
- 人間のフィードバックから報酬モデルを学習し、強化学習に使う手法。参照プールの評価データを使って行うことが想定されていた。
出典
Training AI to Paint with Code
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する