Resumo Técnico: Mage – Avaliação Multieixo de Cenas de Jogo Executáveis Geradas por LLM

Declaração do Problema

Os padrões de avaliação atuais para geração de código por Modelos de Linguagem de Grande Escala (LLM) dependem fortemente de taxas de aprovação na compilação e do sucesso em testes unitários (por exemplo, pass@k em funções independentes). Os autores argumentam que, para artefatos multi-componentes e específicos de domínio — especificamente cenas de jogo executáveis no Unity —, essa métrica é ativamente enganosa. Um script gerado pode compilar com sucesso enquanto falha ao instanciar uma cena funcional, renderizar conteúdo visível sem acionar condições de vitória ou implementar lógica que nunca é executada. Benchmarks existentes falham em capturar a divergência entre correção sintática (compilação) e correção funcional (fidelidade de domínio). Além disso, tentativas anteriores de condicionamento em Representação Intermediária (IR) em nível semântico resultaram em taxas de compilação de 0%, deixando em aberto a questão de qual nível de fundamentação estrutural é suficiente para a geração de código executável.

Metodologia

O artigo apresenta o Mage, um benchmark e protocolo de avaliação projetados para avaliar cenas de jogo Unity 2022 geradas por LLMs em quatro eixos distintos.

1. Construção do Benchmark

• Conjunto de Dados: 26 mini-jogos 2D do Unity criados manualmente, derivados do corpus Goal Playable Concept (GPC), cobrindo padrões de objetivo diversos (por exemplo, coleta de recursos, furtividade, jogo competitivo).
• Verdade Terrena: Cada padrão é realizado como uma cena Unity completa e achatada (prefabs expandidos para GameObjects) com uma representação JSON sem perdas do grafo da cena.
• Extração de IR: Um pipeline automatizado extrai Representações Intermediárias (IRs) em dois níveis de granularidade:
  • Apenas Comportamento: Lógica de script, corpos de métodos, valores de campos do inspector, configurações de física e cadeias de condições de vitória/derrota.
  • Cena Completa: Dados de apenas comportamento mais objetos físicos passivos, configuração de câmera, limites e componentes de renderização para todos os GameObjects.
• Modelos: Quatro LLMs de pesos abertos (7B–30B parâmetros ativos): Qwen3-Coder-30B, Gemma-4-26B, DeepSeek-Coder-V2-Lite e Qwen2.5-Coder-7B.
• Condições: Três estratégias de prompt foram testadas em 858 tentativas de geração (3 sementes por padrão):
  1. Sem-esquema (NL-direto-para-C#): Apenas descrição do padrão em linguagem natural.
  2. IR Apenas Comportamento: JSON derivado da verdade terrena contendo lógica de script.
  3. IR Cena Completa: JSON derivado da verdade terrena contendo a estrutura completa da cena.
• Controle: Todas as condições compartilharam regras de mapeamento de API e modelos de prompt idênticos para isolar o efeito do condicionamento por IR.

2. Protocolo de Avaliação (Mage)

O protocolo avalia a qualidade da geração ao longo de quatro eixos:

1. Sucesso na Compilação: Se o arquivo C# gerado carrega no Unity sem erros (excluindo avisos de referência obsoleta).
2. Sucesso em Tempo de Execução: Se a cena compilada executa GameBuilder.Awake() e sai limpa sem travar.
3. Fidelidade Estrutural: Uma pontuação F1 multidimensional comparando GameObjects, componentes, scripts e tags da cena gerada contra a verdade terrena.
4. Adesão ao Mecanismo: Uma métrica de análise estática medindo a correção do caminho de vitória/derrota (etapas, efeitos e condições) via pontuações F1 fixas.

Principais Resultados

Divergência Correção-Compilação

O estudo revela uma anti-correlação sistemática entre taxas de aprovação na compilação e correção funcional:

• NL-direto-para-C# (Sem-esquema): Alcançou a maior taxa média de aprovação em tempo de execução (43%), com o modelo mais forte (Qwen3) atingindo 80%. No entanto, essas cenas eram estrutural e comportamentalmente vazias. A pontuação F1 de adesão ao mecanismo colapsou para ~0,12 (um piso de linha de base), e a pontuação F1 de tags foi 0,00 em todos os modelos. Os modelos produziram programas pequenos e localmente consistentes que satisfaziam o analisador, mas careciam da estrutura do padrão-alvo.
• Condicionamento por IR: O condicionamento em IR (Apenas Comportamento ou Cena Completa) reduziu significativamente as taxas de aprovação em tempo de execução (Média: 14% e 21%, respectivamente), mas melhorou drasticamente a correção funcional. A adesão ao mecanismo F1 subiu para 0,82–1,00 para os modelos mais fortes, e a fidelidade estrutural melhorou em todas as dimensões.

Saturação de Granularidade

Dentro das configurações condicionadas por IR, não houve diferença estatística entre as granularidades Apenas Comportamento e Cena Completa. Os testes exatos de McNemar resultaram em p = 1,0 em todos os quatro modelos, indicando que, para este benchmark, informações em nível de comportamento são suficientes para saturar o condicionamento em nível de entrada; adicionar geometria de cena passiva (Cena Completa) não gerou ganhos adicionais na correção funcional.

Análise de Erros

As falhas de compilação foram dominadas por erros semânticos (por exemplo, membros inacessíveis, resolução de tipo, conflitos de escopo) em vez de erros de sintaxe.

• Sem-esquema: Erros foram raros; os modelos evitaram estruturas complexas.
• Condicionamento por IR: Os erros deslocaram-se para falhas semânticas específicas introduzidas pelo IR. Por exemplo, CS0246 (tipo/namespace não encontrado) apareceu exclusivamente sob condições de IR (469 ocorrências), indicando falhas no mapeamento de nomes de entidades IR para APIs do Unity. CS0122 (membro inacessível) disparou no IR Apenas Comportamento (862 ocorrências) devido a modelos aplicando incorretamente modificadores de acesso expostos no IR.

Contribuições

1. Metodologia de Avaliação: Um protocolo de quatro eixos (Compilação, Tempo de Execução, Fidelidade Estrutural, Adesão ao Mecanismo) que expõe a divergência sistemática entre taxas de compilação e correção funcional na geração de código específico de domínio.
2. Benchmark e Conjunto de Dados: Uma liberação de 26 padrões de objetivo do Unity, dois níveis de granularidade de IR extraídos automaticamente, 858 saídas de geração e logs completos de reprodução para verificação independente.
3. Caracterização Empírica: Um estudo controlado demonstrando que:
   • As taxas de compilação são anti-correlacionadas com a correção funcional neste domínio.
   • O condicionamento estrutural por IR recupera a estrutura fiel ao domínio às custas das taxas de sucesso em tempo de execução.
   • A saturação de granularidade em nível de entrada ocorre entre IRs Apenas Comportamento e Cena Completa.
4. Decomposição de Três Fatores: Uma lente de enquadramento (Completude de Domínio, Adequação de Mapeamento de API, Fidelidade de Execução do LLM) para interpretar por que a fundamentação estrutural falha em produzir código correto, atribuindo falhas à resolução semântica e tradução de API em vez de sintaxe.

Significado e Alegações

O artigo afirma que a taxa de aprovação na compilação é um sinal inadequado e frequentemente enganoso para avaliar LLMs em artefatos multi-componentes e específicos de domínio. Os autores argumentam que confiar exclusivamente em métricas de compilação leva à falsa conclusão de que os modelos estão performando bem quando, na verdade, estão gerando código "estruturalmente vazio".

O significado do trabalho reside em estabelecer que a avaliação multieixo é necessária para detectar a divergência entre validade sintática e correção funcional. Os autores postulam que, para tarefas envolvendo frameworks pesados específicos de domínio (como motores de jogo), os benchmarks devem relatar pelo menos três eixos: aprovação em nível de analisador, aprovação em nível de tempo de execução e aprovação em fidelidade de domínio. O estudo sugere que, embora o condicionamento estrutural por IR melhore a correção funcional, ele introduz novos modos de falha relacionados ao mapeamento de API e resolução de tipo, destacando a necessidade de melhores mecanismos de tradução entre IRs e APIs de domínio.

O artigo conclui modestamente, notando limitações como o escopo de motor único (Unity), a falta de medição de jogabilidade humana (apenas a execução em tempo de execução foi verificada) e a natureza interpretativa da decomposição de três fatores, que requer investigação causal adicional.