Resumo Técnico: O Verificador é o Currículo

Declaração do Problema

Geradores de código pós-treinamento que utilizam juízes aprendidos (por exemplo, LLMs ou modelos multimodais instigados a pontuar saídas) introduzem uma vulnerabilidade estrutural: esses juízes frequentemente dependem de características superficiais que podem ser manipuladas sem melhorar o artefato subjacente. Isso leva ao "reward hacking" (trapaça de recompensa), onde os modelos otimizam os pontos cegos do juiz em vez da correção funcional. No contexto da geração de jogos, um juiz aprendido pode recompensar a presença de ativos visuais mesmo que o código do jogo esteja quebrado ou congelado.

O artigo aborda a questão do que acontece quando o sinal de treinamento é, em vez disso, um filtro determinístico, livre de juízes e impossível de ser enganado. Especificamente, investiga-se se uma verificação de execução estrita — verificar se um projeto gerado inicia limpamente sob um motor headless — pode impulsionar uma autodestilação eficaz e a generalização entre famílias.

Metodologia

O estudo utiliza o GameCraft-Bench, um benchmark que exige que os modelos gerem projetos completos e executáveis do Godot 4 a partir de breves descrições em linguagem natural. A tarefa é inerentemente difícil porque a correção é conjuntiva; um único erro de análise (parse error), um recurso ausente ou um erro de tempo de execução (runtime crash) torna o projeto inteiro não funcional.

A Escada de Verificação

Os autores definem uma hierarquia de sinais de verificação (Figura 1):

1. BUILD (Leniente): Verifica se o projeto abre e fecha sem erros imediatos de análise. É "quase vacante", pois aceita muitos projetos quebrados (taxa de aprovação de 99,9%).
2. Strict-Launch (Portão de Treinamento): Uma verificação determinística que exige que o projeto inicie limpamente sob um motor headless (código de saída 0, sem erros de análise/carregamento/tempo de execução). É impossível de ser enganado e preciso.
3. Aterramento de Execução (Auditoria Dinâmica): Um sinal secundário que impulsiona a SceneTree e mede mudanças no estado de tempo de execução para confirmar substância funcional.
4. Juiz Visual (Enganável): A métrica oficial do benchmark, mostrada como manipulável (por exemplo, trocando ativos enquanto congela o código).

Autodestilação Iterativa

O método central é a autodestilação por amostragem de rejeição filtrada pelo portão strict-launch:

1. Inicialização: Começa com um modelo supervisionado ($M_0$) treinado em 111 projetos de ouro de 10 famílias de jogos.
2. Geração: Para cada breve de família de treinamento, gera $K=8$ projetos candidatos.
3. Filtragem: Materializa os candidatos e executa a verificação strict-launch. Apenas candidatos que iniciam limpamente (e possuem $\ge$ 3 arquivos) são mantidos.
4. Criação de Combustível: Os candidatos mantidos formam o "combustível" ($F_t$) para a próxima rodada.
5. Retreinamento: Um novo adaptador LoRA é treinado no modelo base usando a união do pool original de ouro e o novo combustível ($D_{t+1} = D_t \cup F_t$).
6. Iteração: Este processo se repete por três rodadas ($RFT-r1, r2, r3$).

Controles

Para isolar a causa dos ganhos de desempenho, os autores empregam três controles correspondentes:

• Duplicação de Ouro (CTRL): Adiciona duplicatas exatas de projetos de treinamento de ouro em vez de combustível autogerado.
• Correspondência de Contagem: Troca o gerador (usando $M_1$ em vez de $M_0$) para isolar o efeito da qualidade do combustível versus a quantidade.
• BUILD-Gated: Substitui o filtro strict-launch pelo filtro leniente BUILD, mantendo o gerador e o orçamento idênticos.

Resultados Principais

O estudo foca na generalização entre famílias, avaliando o desempenho em quatro famílias de jogos não vistas (terror, ritmo, puzzle, tiro) compreendendo 25 tarefas retidas.

• Ganhos Compostos: Sob o portão strict-launch, a autodestilação compõe o desempenho significativamente:

  • Taxa de lançamento limpo por candidato: Aumenta de 8,8% (SFT) para 13,6% (r1), 30,9% (r2) e 42,2% (r3).
  • Cobertura Best-of-K: Aumenta de 18/25 (SFT) para 25/25 (r3), atingindo o "teto de ouro" onde cada tarefa retida possui pelo menos um candidato limpo.
  • Todos os melhorias são estatisticamente significativas ($p < 10^{-4}$ para as rodadas posteriores).

• Atribuição de Ganhos:

  • Não é Duplicação de Dados: O controle de Duplicação de Ouro (CTRL) na verdade regrediu o desempenho para 5,6%, provando que mero volume de dados ou repetição é insuficiente e potencialmente prejudicial.
  • A Precisão do Filtro é Causal: O controle BUILD-gated (usando o filtro leniente) apagou todos os ganhos, retornando ao nível basal (8,6%). Isso isola a precisão do verificador como o fator causal, não o otimizador ou o volume de dados.
  • Qualidade vs. Quantidade: A decomposição do salto da rodada 1 para a 2 revela tanto um canal de qualidade (+8,8 pontos percentuais) quanto um canal de quantidade (+8,5 pontos percentuais), com a qualidade sendo o driver dominante.

• Validade Funcional:

  • Auditoria Estática: Projetos limpos de rodadas posteriores são mais ricos (mediana de 473 linhas de GDScript vs. 331 para SFT) e contêm mais arquivos.
  • Aterramento Dinâmico: Um sinal de aterramento de execução independente confirma que os ganhos são funcionais. O número de tarefas com candidatos "aterrados" (funcionalmente ativos) aumenta monotonicamente (10 $\to$ 15/25), e a autodestilação produz muito mais candidatos aterrados do que a duplicação de ouro (16 vs. 5 com orçamento correspondente).

Significância e Alegações

A tese central do artigo é que "O verificador é o currículo".

1. Filtros Determinísticos Permitem Composição: Ao contrário de juízes aprendidos, que podem ser enganados e levar à otimização superficial, uma verificação de execução determinística e não enganável define uma distribuição de treinamento que força o modelo a aprender a correção funcional.
2. A Precisão Impulsiona a Transferência: A capacidade da autodestilação de compor capacidades entre famílias não vistas está diretamente ligada à precisão do filtro de aceitação. Um filtro com alta taxa de falsos positivos (como o BUILD) faz com que o loop componha projetos quebrados, enquanto um filtro preciso compõe projetos funcionais.
3. Substância Funcional: As melhorias não são "infladas por estojos" (projetos que iniciam mas não fazem nada); elas representam aumentos genuínos em complexidade funcional e comportamento de tempo de execução.

Os autores concluem que, em loops de autoaperfeiçoamento, o teto de capacidade é definido pela integridade do verificador, não meramente pelo volume de dados. Embora o estudo seja específico para a geração de jogos como um banco de testes verificável, o princípio sugere que, para qualquer domínio onde exista uma verificação determinística e não enganável, a autodestilação iterativa pode impulsionar uma generalização robusta entre domínios.