El 3 de septiembre, Hugging Face publicó un registro de entrenamiento completo: tomar un modelo pensado para escribir código y entrenarlo hasta que supiera pintar acuarelas. En toda la cadena no hay ningún modelo de difusión ni componente de generación de imágenes. El modelo genera un fragmento de JavaScript que llama a la librería de pinceles p5.brush; al ejecutarlo, queda una acuarela en el lienzo.
El autor es Sergio Paniego, y la idea original vino de Surya Narreddi. El modelo base elegido es Qwen3.5-35B-A3B, entrenado con el GRPO de TRL, con LoRA aplicado a todas las capas lineales, una tasa de aprendizaje de 5e-5 y un programador constant_with_warmup. La ejecución del código, el renderizado y el cálculo de la puntuación están encapsulados en un entorno OpenEnv: el modelo genera el código, el entorno lo ejecuta, toma una captura de pantalla y se la entrega al sistema de puntuación.
En la recompensa no hay correcto ni incorrecto, solo un fondo de referencias
En los últimos dos años, los escenarios donde el aprendizaje por refuerzo ha funcionado bien en grandes modelos casi siempre tienen un punto en común: un criterio automático de correcto o incorrecto, una respuesta modelo para las matemáticas, pruebas unitarias para el código. Una acuarela no tiene nada de eso. La solución de este registro consiste en descomponer "qué tan bonito es" en dos señales que sí se pueden puntuar.
La función de recompensa tiene cuatro componentes. Que el código se ejecute sin errores cuenta un 0,05, y la longitud del código otro 0,05, y el noventa por ciento restante se reparte entre dos señales estéticas: un modelo-juez que hace comparaciones por pares y un sistema de puntuación de preferencias humanas llamado HPSv3. El peso de estos dos componentes se intercambia según el experimento: en el grupo "judge-led" el juez pesa 0,60 y HPSv3 0,30; en el grupo "hps-led" es al revés.
El criterio del juez procede de un fondo de referencia puntuado a mano, 178 imágenes en total. Cada imagen que genera el modelo se compara con una obra tomada de ese fondo. Ese mismo fondo también define qué cuenta como "variado"; el texto original del blog dice: "The pool decides what counts as variety, the same way it decides what counts as quality". En la práctica, esas 178 imágenes marcan el techo de todo el objetivo de entrenamiento.
Tres tandas, tres curvas
El autor ejecutó tres experimentos comparativos. El grupo puntuado solo con HPSv3 corrió 60 pasos, con la recompensa media subiendo de 0,58 a 0,71; el grupo judge-led corrió 110 pasos, de 0,45 a 0,72; el grupo hps-led, también 110 pasos, subió de 0,57 a 0,82, el punto de partida y de llegada más altos de los tres.
El mayor incremento fue el del grupo judge-led, con +0,27, aunque también partía del punto más bajo. El grupo hps-led subió 0,24 pero terminó en 0,82: poner el sistema de preferencias humanas en el papel principal y el modelo-juez como apoyo resultó más estable que al revés. El grupo que solo usa el sistema de puntuación, sin juez, apenas subió 0,13, el menor incremento de los tres. La capa de comparación por pares sí aporta una señal adicional, no es un adorno prescindible.
Una sola GPU, 34 horas, un par de cientos de dólares
El apartado de hardware es sencillo. Todo el proceso corrió en una sola H200: 18 horas para los 60 pasos, 34 horas para los 110 pasos. El renderizado se hizo en un Space con especificación de CPU, y el sistema de puntuación HPSv3 en un Space a100-large.
Calculando con el precio actual en la nube de la H200, entre 3 y 4 dólares por hora, un entrenamiento completo de 110 pasos queda entre 100 y 140 dólares; sumando el gasto del sistema de puntuación y el renderizado, la factura total de cómputo del proyecto ronda unos cientos de dólares. Para un equipo que solo quiere comprobar si una preferencia estética puede servir como recompensa, el umbral de entrada es lo bastante bajo como para probarlo sin pensarlo mucho.
Lo que se ha publicado en abierto es bastante completo: la receta de entrenamiento y los scripts están en GitHub, junto con el conjunto de datos de las 178 imágenes de referencia, un Space del entorno de RL que se puede duplicar directamente, el Space del sistema de puntuación HPSv3, los tres adaptadores LoRA junto con sus respectivos conjuntos de datos de rollout, y una galería para recorrer todos los resultados generados. Quien quiera reproducirlo no necesita montar su propio entorno: basta con duplicar el Space y ajustar los pesos de la recompensa para empezar.
Siguiendo este camino, hay bastantes escenarios a los que se podría trasladar. El aspecto de un componente de interfaz, la densidad de la maquetación de un póster, si los colores de un gráfico son adecuados: tareas donde no está claro qué es correcto, pero que una persona distingue a simple vista, y que hasta ahora eran difíciles de traducir en una función de recompensa para RL. El método actual es reunir primero un fondo de referencia de unos cientos de elementos, encontrar un sistema de puntuación de preferencias que sea suficientemente bueno, y dejar el resto al GRPO. El problema sigue estando en el fondo de referencia: si está sesgado, el modelo se sesga con él, y además de forma muy consistente.
Fuentes: blog oficial de Hugging Face, documentación de los proyectos TRL y OpenEnv, CocoLoop; el número de pasos, el rango de recompensa y la duración por GPU de los tres experimentos se verificaron uno a uno según el registro de entrenamiento del blog, y el coste de cómputo es una estimación a partir de los precios públicos.