FactorSmith: Agentic Simulation Generation via Markov Decision Process Decomposition with Planner-Designer-Critic Refinement

O artigo apresenta o FactorSmith, um framework que gera simulações de jogos executáveis a partir de descrições em linguagem natural, combinando a decomposição de POMDPs fatorados para reduzir o contexto e um fluxo de trabalho agênico hierárquico (planejador, designer e crítico) para refinar iterativamente a qualidade do código.

O essencial

Imagine que você pediu para um gênio da programação (uma Inteligência Artificial) criar um jogo de vídeo game completo, apenas descrevendo-o em palavras. O problema é que, se você pedir para esse gênio criar o jogo inteiro de uma só vez, ele fica sobrecarregado. Ele começa a alucinar, inventar funções que não existem ou esquecer partes importantes do jogo.

É aí que entra o FactorSmith. O papel descreve uma nova "fábrica de jogos" que usa uma equipe de especialistas para transformar suas ideias em código funcional, sem cometer os erros comuns das IAs atuais.

Aqui está como funciona, explicado de forma simples:

1. O Problema: O "Gênio" Sobrecarregado

Pense em um arquiteto tentando desenhar um arranha-céu inteiro em uma única folha de papel. É impossível ver todos os detalhes sem errar. Da mesma forma, quando uma IA tenta escrever um jogo inteiro de uma vez, ela perde o foco. Ela esquece como a gravidade funciona no nível 1 enquanto tenta desenhar o inimigo do nível 5.

2. A Solução: A "Fábrica de Blocos" (Decomposição)

O FactorSmith resolve isso dividindo o trabalho em pequenos blocos, como montar um quebra-cabeça ou construir com LEGO.

• Em vez de pedir o jogo inteiro, o sistema divide sua descrição em etapas pequenas e independentes (ex: "crie a bola", "faça a bola cair", "faça a bola quicar na parede").
• Para cada etapa, a IA só olha para as peças necessárias naquele momento. É como se o arquiteto só olhasse para o desenho do telhado enquanto o pedreiro constrói o telhado, sem se preocupar com a fundação que já foi feita. Isso evita que a IA se confunda com informações desnecessárias.

3. O Segredo: A "Equipe de Três" (Agente Planejador, Designer e Crítico)

Aqui está a inovação principal. Em vez de uma única IA fazer o trabalho e torcer para dar certo, o FactorSmith usa uma equipe de três especialistas para cada pequeno bloco:

1. O Planejador (O Maestro): Ele é o chefe. Ele organiza o fluxo de trabalho e decide quando o trabalho está bom o suficiente para avançar ou quando é preciso recuar.
2. O Designer (O Artista): Ele pega a ideia e escreve o código. Ele é criativo e tenta fazer a melhor parte possível.
3. O Crítico (O Fiscal de Qualidade): Ele é o mais importante. Ele não cria nada; ele apenas examina o trabalho do Designer. Ele usa uma "lista de verificação" rigorosa para dar uma nota de 0 a 10. Se o código tiver um erro, ele diz: "Isso não está certo, note 6. Melhore isso".

4. O Processo de Refinamento: "Tentar, Avaliar, Corrigir"

A mágica acontece no loop de revisão:

• O Designer cria uma versão do código.
• O Critic avalia e dá uma nota.
• Se a nota for baixa, o Planejador manda o Designer tentar de novo, usando o feedback do Crítico.
• Eles fazem isso várias vezes até que a nota seja perfeita.
• O Truque de Segurança: Se em alguma tentativa o código ficar pior do que a versão anterior, o Planejador tem um "botão de desfazer" (rollback) e volta para a versão boa anterior. Nada é salvo se estiver ruim.

5. A Analogia Final: A Cozinha de um Restaurante Estrelado

Imagine que você quer um prato complexo.

• Método Antigo (IA Sozinha): Um único cozinheiro tenta fazer o prato inteiro de uma vez. Ele queima a carne enquanto tenta cortar a salada e esquece o tempero. O prato sai ruim.
• Método FactorSmith:
  • O Chefe (Planejador) divide o menu em etapas: cortar, cozinhar, temperar.
  • O Cozinheiro (Designer) prepara o corte de carne.
  • O Degustador (Critic) prova a carne. Se estiver salgada demais, ele avisa: "Tempero errado, tente de novo".
  • O Cozinheiro ajusta. O Degustador prova de novo. Só quando a nota for 10/10, o prato passa para a próxima etapa.
  • Se o Cozinheiro tentar algo novo e estragar o prato, o Chefe joga fora e volta para a versão que estava boa.

Por que isso é importante?

Os testes mostraram que essa abordagem cria jogos com menos erros, código mais limpo e que funcionam muito melhor do que os métodos antigos. O FactorSmith não é apenas "mais inteligente", é mais organizado e cuidadoso. Ele transforma a criação de simulações complexas de um ato de "tentativa e erro" caótico em um processo de engenharia precisa e confiável.

Em resumo: FactorSmith é a diferença entre pedir para uma pessoa fazer tudo sozinha e ter uma equipe organizada, com um fiscal de qualidade, trabalhando em pequenas tarefas para garantir que o resultado final seja perfeito.

Resumo técnico

1. O Problema

A geração de simulações executáveis (código) a partir de especificações em linguagem natural é um desafio significativo para os Grandes Modelos de Linguagem (LLMs). As principais dificuldades identificadas são:

• Capacidade de Raciocínio Limitada: LLMs lutam para lidar com grandes bases de código interconectadas, tendendo a alucinar funções inexistentes, ignorar partes da especificação ou modificar código irrelevante.
• Falta de Mecanismos de Auto-correção: Abordagens anteriores, como o FactorSim, decomponham o problema em etapas modulares, mas dependiam de geração "única" (single-shot) em cada etapa. Se o LLM produzisse um erro, não havia um mecanismo robusto de refinamento além de tentativas de retry cegas.
• Compromisso entre Contexto e Qualidade: Abordagens multi-agente (como o SceneSmith) melhoram a qualidade através de refinamento iterativo, mas não otimizam a seleção de contexto, resultando em janelas de contexto excessivamente grandes e ineficientes.

2. Metodologia: FactorSmith

O FactorSmith propõe uma unificação de duas linhas de pesquisa complementares: a decomposição de POMDPs fatorados (para redução de contexto) e um fluxo de trabalho agênico hierárquico (para refinamento de qualidade).

Arquitetura Geral

O sistema opera em três fases principais:

1. Decomposição de Alto Nível: A especificação em linguagem natural é dividida em uma sequência de etapas modulares ($q_1, ..., q_K$) usando Chain-of-Thought. Cada etapa é restrita a um módulo autocontido (ex: adicionar uma bola que cai), seguindo o padrão MVC (Model-View-Controller).
2. Execução de Etapas Fatoradas com Refinamento Agênico: Para cada etapa, o sistema executa sub-etapas (atualização de estado, decomposição, lógica de entrada, transição de estado, renderização). A inovação central é que cada sub-etapa não é gerada por uma única chamada ao LLM, mas sim por um trio de agentes:
   • Planejador (Planner): Orquestra o fluxo, toma decisões de aceite, rejeição ou rollback (reversão) e gerencia checkpoints.
   • Designer: Propõe modificações ou gera artefatos de código (funções) baseados apenas no contexto escopado.
   • Crítico (Critic): Avalia a proposta do Designer contra critérios estruturados (correção, completude, uso de estado, qualidade de código), gerando pontuações numéricas e feedback em linguagem natural.
3. Montagem e Validação: As funções e variáveis geradas são reunidas em uma simulação executável completa, passando por verificações de compilação e correção básica.

Mecanismos Chave

• Decomposição de POMDP Fatorado: O espaço de estado da simulação é decomposto em subconjuntos ($Z_k$). Em cada passo, o LLM recebe apenas as variáveis de estado relevantes para aquela tarefa específica, reduzindo drasticamente a janela de contexto necessária.
• Refinamento Iterativo com Rollback: O agente Crítico atribui pontuações estruturadas. Se a pontuação não atingir um limiar ($\tau$), o Planejador solicita uma revisão ao Designer. Se a pontuação cair em relação ao checkpoint anterior, o sistema executa um rollback para a versão anterior, garantindo que a qualidade não regresse.
• Avaliação Estruturada: Diferente de sistemas que geram casos de teste (que podem ser falhos), o FactorSmith usa rubricas de pontuação estruturadas (ex: "Correção: 6 $\to$ 8 (+2)") para decisões objetivas.

3. Principais Contribuições

1. Framework Unificado: Formalização de um pipeline que embute um fluxo de trabalho agênico (Planejador-Designer-Critic) dentro de cada etapa de um pipeline de geração de POMDP fatorado.
2. Fundamentação Matemática: Análise teórica de como o refinamento agênico se compõe com a seleção de contexto fatorado, demonstrando a monotonicidade da qualidade (a pontuação total aceita não diminui ao longo das iterações).
3. Implementação Open-Source: Um sistema construído sobre o OpenAI Agents SDK com gerenciamento de sessão baseado em SQLite, permitindo persistência de estado e snapshots para rollbacks.
4. Validação Empírica: Resultados experimentais mostrando superioridade sobre baselines não-agênticas e não-fatoradas.

4. Resultados Experimentais

Os testes foram realizados no benchmark PyGame Learning Environment (PLE), com 8 jogos 2D (ex: Flappy Bird, Snake, Pong).

• Desempenho Geral: O FactorSmith superou todas as baselines, incluindo o FactorSim (sem agentes) e o AgentCoder (multi-agente sem fatoração).
• Taxa de Aprovação de Testes: Houve ganhos consistentes. Por exemplo, no jogo Catcher, a taxa de aprovação aumentou de 66% (FactorSim) para 74% (FactorSmith). Em jogos com interações complexas de estado, os ganhos foram ainda maiores.
• Estudo de Ablação:
  • Remover o Crítico reduziu o desempenho em 7 pontos percentuais, confirmando que a avaliação iterativa é crucial.
  • Remover o Rollback causou degradação, indicando que o mecanismo de segurança é valioso.
  • Remover a Fatoração (usando contexto completo com agentes) causou a maior degradação (-12 pontos), provando que a redução de contexto é a técnica mais impactante.
• Eficiência de Tokens: Embora o refinamento multi-round use mais tokens que o FactorSim puro, é mais eficiente que o CoT + Self-Debug devido ao contexto menor por chamada e à terminação precoce baseada em pontuação estruturada. O custo adicional é de aproximadamente 1,7x o uso de tokens do FactorSim, em troca de qualidade superior.

5. Significado e Conclusão

O FactorSmith demonstra que a decomposição estrutural (redução de contexto) e o refinamento agênico (iteração e avaliação) são complementares e não excludentes.

• A decomposição impede que o LLM seja sobrecarregado pelo contexto, evitando alucinações em grande escala.
• O trio agênico captura erros locais sutis (como erros de "off-by-one" ou referências incorretas de variáveis) que passariam despercebidos em uma geração única, mesmo com contexto reduzido.

O trabalho estabelece um novo paradigma para a geração de código complexo, onde a estrutura do domínio (padrão MVC e POMDP) guia a arquitetura dos agentes, permitindo a criação de simulações executáveis de alta qualidade a partir de descrições textuais. Futuras direções incluem o uso de feedback de execução real como sinal de crítica e a extensão para simulações 3D em robótica.