Contexte et objectifs

Surya Narreddi a démontré qu’un modèle de langage pouvait générer du JavaScript via la bibliothèque p5.brush pour créer des aquarelles numériques. Le projet reproduit cette idée en combinant TRL (Transformer Reinforcement Learning) et OpenEnv, afin de permettre à un modèle plus petit d’apprendre les préférences esthétiques d’un jeu de références humaines. Le cœur du problème est de réaliser du RLHF où la récompense n’est pas une réponse exacte mais un jugement de goût.

Architecture du pipeline

Le flux complet s’exécute sur Hugging Face : les jobs d’entraînement sont lancés via hf jobs uv run, l’environnement de renforcement et le modèle de notation sont déployés comme Spaces, et le juge par paires est appelé via les Inference Providers. Le modèle cible est Qwen/Qwen3.5-35B-A3B, adapté avec LoRA, bf16 et le gradient checkpointing pour réduire la consommation mémoire. Deux juges composent la fonction de récompense : le modèle de préférence HPSv3 (7 B paramètres) qui attribue un score à partir d’une image et d’une description, et le juge par paires Qwen3‑VL‑30B‑A3B‑Instruct qui compare la peinture générée à quatre références tirées d’un pool annoté manuellement.

Entraînement et paramètres

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

Les hyper‑paramètres clés – taux d’apprentissage 5e-5, constant_with_warmup avec 5 pas d’échauffement, 110 étapes d’optimisation et 240 épisodes – garantissent une progression stable du score de récompense. Trois expériences ont été menées : une première avec uniquement HPSv3, puis deux variantes où le poids du juge par paires augmente progressivement. Les métriques de récompense montrent une hausse continue, indiquant que le modèle apprend à aligner son code JavaScript (environ 150 lignes, limité à dix méthodes de p5.brush) avec les préférences du pool.

Évaluation et limites

Les peintures générées conservent un aspect « loose » et « hand‑made », contrastant avec les images synthétiques ultra‑lisses produites par les modèles de diffusion. Cette texture provient du double filtrage : le code produit par le modèle impose des contraintes de tracé, et le juge par paires pénalise les écarts par rapport aux références humaines. Cependant, la dépendance au pool annoté signifie que le goût appris reflète uniquement les jugements du petit groupe de curateurs ; un changement de pool entraînerait une réorientation complète du modèle. De plus, l’utilisation d’un modèle de préférence pré‑entraîné (HPSv3) introduit un biais vers la moyenne des préférences humaines, limitant la capacité du système à explorer des styles très divergents. Enfin, le coût computationnel reste élevé : même avec LoRA et le gradient checkpointing, chaque run nécessite 48h sur un GPU h200, ce qui restreint la reproductibilité à des environnements cloud disposant de ressources similaires.