Como um modelo de código aprendeu a pintar aquarelas: a reprodução aberta do projeto viral com TRL e OpenEnv

O projeto viral e a reprodução aberta

Em 23 de agosto de 2026, o pesquisador Surya Narreddi publicou um vídeo que ultrapassou 1,5 milhão de visualizações em poucos dias. O conteúdo? Aquarelas pintadas por um modelo de linguagem. Em vez de gerar imagens pixel a pixel, o modelo escreve um programa de cerca de 150 linhas de JavaScript usando a biblioteca p5.brush — que adiciona “ferramentas de desenho natural” ao p5.js — e o código, quando executado, pinta a imagem. Cada pincelada é uma decisão visível e legível no código.

O vídeo veio acompanhado de um post explicando o treinamento de uma etapa anterior do projeto, mas sem os artefatos abertos. Agora, o engenheiro Sergio Paniego, do Hugging Face, fez o que a comunidade de código aberto faz de melhor: reproduziu a receita inteira com todos os recursos publicados. A implementação usa TRL (Transformer Reinforcement Learning) e OpenEnv, uma ferramenta de ambientes de RL lançada recentemente, e roda de ponta a ponta na infraestrutura do Hugging Face — do treinamento em Jobs à galeria interativa de todas as pinturas.

O que é “RL sobre gosto”

A maior parte do aprendizado por reforço (RL) recente em modelos de linguagem usa recompensas verificáveis: problemas de matemática com resposta conhecida, código que passa em testes, avaliadores objetivos e baratos. Este projeto segue o caminho oposto — e mais antigo — do RLHF, em que o modelo aprende uma função de recompensa a partir das preferências humanas.

Aqui, a recompensa é preferência estética. Não existe resposta correta. A pergunta central do projeto é justamente: dá para fazer RL sobre “gosto”? A resposta, demonstrada nos resultados, é sim — ao menos até onde as métricas e as pinturas finais mostram.

Um ponto importante, destacado pelo próprio autor: um modelo de fronteira já consegue gerar o código JavaScript que pinta aquarelas a partir de um prompt. Esse é o ponto de partida. O trabalho aqui é ensinar um modelo menor a fazer isso combinado com as preferências artísticas de uma pessoa específica.

A função de recompensa

A recompensa é uma soma ponderada de quatro termos. Dois deles são modelos de IA que funcionam como proxies do “gosto”:

O HPSv3 é um modelo aberto de preferência com 7 bilhões de parâmetros: recebe uma imagem e uma descrição e devolve uma nota do quanto uma pessoa preferiria aquela imagem. Já o juiz pareado é um modelo de visão geral (Qwen3-VL-30B-A3B-Instruct) chamado pelos Inference Providers do Hugging Face. Ele vê a pintura candidata ao lado de quatro referências sorteadas do pool, guiado por uma descrição do que avaliar (sangramentos, aguadas translúcidas, bordas suaves), e sua nota é a proporção de comparações vencidas.

O pool é a função de recompensa

O pool é um conjunto de 178 pinturas dividido em dois níveis de preferência pessoal do autor — “love” e “okay”. Todas foram geradas por modelos. Quatro modelos abertos escreveram esboços em p5.brush, cada um partindo de uma foto real e licenciada de um hibisco do iNaturalist:

Um modelo de visão deu feedback escrito sobre cada esboço ao longo de três rodadas de refinamento, e o autor avaliou cada renderização final uma a uma. A ideia central é poderosa: o modelo vai aprender a imitar o que o pool contém. Se você apontar o ambiente para um conjunto de dados diferente, a recompensa muda automaticamente — sem tocar em uma linha de código.

Há uma limitação honesta registrada no artigo: nenhuma pintura feita por humanos está no pool. O p5.brush é uma biblioteca de nicho, e o trabalho humano acessível com código é escasso demais para um corpus de treinamento.

Os três experimentos e seus resultados

O autor treinou três execuções que diferem apenas na divisão de peso entre os dois juízes:

Os resultados confirmaram a hipótese. Quanto mais peso o juiz pareado carrega, mais a recompensa representa o gosto do autor — e mais difícil deve ser subir. A recompensa média do grupo saltou +0,13 na hps-only, +0,27 na judge-led e +0,24 na hps-led. O próprio termo do juiz pareado subiu nas duas execuções que o usaram: o modelo passou a vencer mais comparações contra o pool conforme o treinamento avançava.

Antes de qualquer coisa funcionar, houve uma longa sequência de curvas de recompensa achatadas. A saída veio de quatro mudanças na configuração do GRPOTrainer do TRL: aumentar a taxa de aprendizado de 2e-5 para 5e-5, trocar o agendador linear por constant_with_warmup, desativar o scale_rewards (uma rejeição do gate encolhia todas as outras vantagens do grupo) e — o mais sutil — trocar target_modules por all-linear. O modelo-base é um mixture-of-experts que nomeia a maioria de suas projeções de forma diferente do esperado, então o adaptador LoRA estava treinando apenas 10 das 40 camadas.

O que o modelo realmente aprendeu

Em todas as execuções, a primeira coisa que o modelo aprendeu foi parar de produzir pinturas ruins — telas quase em branco e aguadas disformes que pontuavam abaixo de 0,3. Na judge-led, os rollouts abaixo de 0,3 caíram de 99 para 16; na hps-led, de 37 para 4. O aprendizado aparece no meio da distribuição, não na melhor pintura de cada passo.

O juiz pareado muda o topo. Na hps-only, as pinturas ficaram mais confiáveis sem ficar melhores; o HPSv3, uma vez que via pétalas ao redor de um centro e um caule, parava de pedir mais pigmento. Com o juiz ligado, “melhor” passou a significar “mais próximo do pool”, a cobertura de tinta dobrou, e a melhor pintura de cada passo também subiu.

Um achado curioso: o modelo ignora uma instrução explícita — e está certo em fazer isso. O prompt pede de 15 a 30 formas preenchidas, mas a média real fica entre 7 e 9, e o número de formas quase não se correlaciona com a recompensa. A política não é recompensada por obedecer essa frase, então não obedece.

Infraestrutura é o maior desafio

O autor é direto: “este projeto é principalmente infraestrutura”. Uma execução precisa de um treinador, dois Spaces, um roteador de inferência e um websocket saudáveis por horas seguidas — e cada peça que falha silenciosamente vira um número errado em outro lugar. Falhas de infraestrutura entravam na recompensa como zeros: uma renderização que estourava o tempo ou um avaliador que não respondia pontuava o mesmo que uma pintura ruim. Isso era cerca de 1,5% dos rollouts (chegando a 5,2% na pior execução), treinando o modelo em ruído.

Também foi encontrado e corrigido um bug no próprio OpenEnv — o cliente mantém um websocket persistente e um socket fechado pelo outro lado ficava em cache, fazendo chamadas posteriores falharem mesmo com o ambiente saudável. A correção foi enviada para o projeto original.

Quanto custa

Um passo tem oito rollouts e leva de 15 a 18 minutos, dos quais 70% a 80% são renderização. Uma única renderização demora de 69 a 96 segundos, perto do limite de 90 — o Space não tem GPU, então o Chromium renderiza a tela WebGL por software.

Por que isso importa

Este trabalho marca um contraste raro. Enquanto os modelos de imagem produzem imagens “perfeitas” (estatisticamente médias), as aquarelas parecem soltas, imperfeitas e artesanais. É uma volta aos primeiros dias da arte generativa — DeepDream em 2015, Edmond de Belamy em 2018 — quando o objetivo era explorar o meio, não otimizar para a média.

Mas há uma lição mais profunda, e ela vale para qualquer pessoa que trabalhe com IA: por trás do número da recompensa existe um trabalho profundamente humano — decidir o que pertence ao conjunto de referência. Como resume o artigo, a IA deslocou o gargalo “de fazer para notar”. O pool é o gargalo, e é a parte do pipeline sem resposta baseada em princípios.

Tudo está publicado: a receita, o pool com todos os esboços-fonte, o ambiente, o avaliador HPSv3, os três adaptadores treinados, os rollouts completos e uma galeria com todas as pinturas navegáveis. Para quem quiser reproduzir ou adaptar a receita a outros assuntos — animais, animações, qualquer coisa — o caminho está aberto.