Em 3 de setembro, a Hugging Face publicou um relato completo de treinamento: pegar um modelo feito para escrever código e treiná-lo até que soubesse pintar aquarelas. Em toda a cadeia não há nenhum modelo de difusão nem qualquer componente de geração de imagem. O modelo produz um trecho de JavaScript que chama a biblioteca de pincéis p5.brush; ao ser executado, deixa uma aquarela na tela.
O autor é Sergio Paniego, e a ideia original veio de Surya Narreddi. O modelo-base escolhido foi o Qwen3.5-35B-A3B, treinado com o GRPO do TRL, com LoRA aplicado a todas as camadas lineares, taxa de aprendizado de 5e-5 e escalonador constant_with_warmup. A execução do código, a renderização e o cálculo da pontuação ficam encapsulados em um ambiente OpenEnv: o modelo gera o código, o ambiente o executa, tira uma captura de tela e a entrega ao sistema de pontuação.
Na recompensa não há certo ou errado, só um banco de referências
Nos últimos dois anos, os cenários em que o aprendizado por reforço funcionou bem em modelos grandes quase sempre têm algo em comum: um critério automático de certo ou errado — uma resposta padrão para matemática, testes unitários para código. Uma aquarela não tem nada disso. A solução deste relato foi decompor "o quanto é bonito" em dois sinais que dá para pontuar.
A função de recompensa tem quatro componentes. O código rodar sem erro vale 0,05, e o tamanho do código vale 0,05, e os noventa por cento restantes ficam divididos entre dois sinais estéticos: um modelo-juiz que faz comparações em pares e um sistema de pontuação de preferência humana chamado HPSv3. O peso desses dois componentes se inverte conforme o experimento: no grupo "judge-led" o juiz pesa 0,60 e o HPSv3 0,30; no grupo "hps-led" é o contrário.
O critério do juiz vem de um banco de referência avaliado manualmente, 178 imagens ao todo. Cada imagem gerada pelo modelo é comparada com uma obra retirada desse banco. O mesmo banco também define o que conta como "variado" — nas palavras do próprio blog, "The pool decides what counts as variety, the same way it decides what counts as quality". Na prática, essas 178 imagens definem o teto de todo o objetivo de treinamento.
Três rodadas, três curvas
O autor rodou três experimentos comparativos. O grupo pontuado só pelo HPSv3 rodou 60 passos, com a recompensa média subindo de 0,58 para 0,71; o grupo judge-led rodou 110 passos, de 0,45 para 0,72; o grupo hps-led, também 110 passos, subiu de 0,57 para 0,82 — o ponto de partida e de chegada mais altos dos três.
O maior ganho foi do grupo judge-led, com +0,27, mas também partiu do ponto mais baixo. O grupo hps-led subiu 0,24, mas fechou em 0,82: colocar o sistema de preferência humana no papel principal e o modelo-juiz como apoio se mostrou mais estável do que o inverso. O grupo que usa só o sistema de pontuação, sem juiz, subiu apenas 0,13 — o menor ganho dos três. A camada de comparação em pares realmente contribui com um sinal extra, não é um enfeite dispensável.
Uma GPU, 34 horas, cerca de cem dólares
A parte de hardware é simples. Do início ao fim, uma única H200: 18 horas para os 60 passos, 34 horas para os 110 passos. A renderização rodou em um Space com especificação de CPU, e o sistema de pontuação HPSv3, em um Space a100-large.
Pelo preço atual da H200 na nuvem, entre 3 e 4 dólares por hora, um treinamento completo de 110 passos fica entre 100 e 140 dólares; somando o gasto com o sistema de pontuação e a renderização, a conta total de computação do projeto fica na casa de algumas centenas de dólares. Para uma equipe que só quer testar se uma preferência estética pode funcionar como recompensa, o custo de entrada é baixo o suficiente para tentar sem muita cerimônia.
O material aberto é bem completo: a receita de treinamento e os scripts estão no GitHub, junto com o dataset das 178 imagens de referência, um Space do ambiente de RL que pode ser duplicado diretamente, o Space do sistema de pontuação HPSv3, os três adaptadores LoRA com seus respectivos datasets de rollout, e uma galeria para percorrer todos os resultados gerados. Quem quiser reproduzir não precisa montar o próprio ambiente: basta duplicar o Space e ajustar os pesos da recompensa para começar.
Seguindo esse caminho, há bastante coisa que dá para aproveitar. A aparência de um componente de interface, a densidade do layout de um pôster, se as cores de um gráfico ficam adequadas — tarefas em que não dá para dizer certo ou errado, mas que uma pessoa distingue de cara, e que até agora eram difíceis de transformar em função de recompensa para RL. O método agora é primeiro reunir um banco de referência com algumas centenas de itens, achar um sistema de pontuação de preferência que seja bom o suficiente, e deixar o resto por conta do GRPO. O ponto delicado continua sendo o banco de referência: se ele for enviesado, o modelo segue o viés, e de um jeito bem consistente.
Fontes: blog oficial da Hugging Face, documentação dos projetos TRL e OpenEnv, CocoLoop; o número de passos, a faixa de recompensa e a duração por GPU dos três experimentos foram conferidos item a item conforme o relato de treinamento do blog, e o custo de computação é uma estimativa com base nos preços públicos.