How Many Tries Does It Take? Iterative Self-Repair in LLM Code Generation Across Model Scales and Benchmarks

Resumo Técnico: Auto-Reparo Iterativo em Geração de Código por LLMs

1. O Problema

Os Grandes Modelos de Linguagem (LLMs) frequentemente falham em gerar código funcionalmente correto na primeira tentativa. No entanto, a maioria das benchmarks (como HumanEval e MBPP) avalia esses modelos em um cenário de "tiro único" (single-shot), medindo apenas a taxa de sucesso na primeira tentativa (pass@1). Essa abordagem diverge da prática real de desenvolvimento, onde programadores iteram, executam o código, analisam mensagens de erro e corrigem falhas.

Estudos anteriores (ex: Olausson et al., 2023) sugeriram que o auto-reparo não é uma "bala de prata" e que modelos mais fracos podem até piorar ao tentar corrigir erros sem ajuste fino (fine-tuning). Com o surgimento de uma nova geração de modelos instruídos (2024-2025) e arquiteturas avançadas (como Mixture-of-Experts - MoE), surge a questão: o auto-reparo baseado apenas em prompts funciona universalmente hoje, mesmo em modelos menores, e como diferentes arquiteturas se comportam nesse processo?

2. Metodologia

O estudo realiza uma avaliação sistemática e empírica comparando sete modelos de três famílias (Meta, Alibaba, Google) em dois benchmarks padrão: HumanEval (164 problemas) e MBPP Sanitized (257 problemas).

• Modelos Avaliados:
  • Open-weight (via Groq API): Llama 3.1 8B (Dense), Llama 3.3 70B (Dense), Llama 4 Scout (MoE, 16 experts), Llama 4 Maverick (MoE, 128 experts), Qwen3 32B (Dense).
  • Proprietários (via Vertex AI): Gemini 2.5 Flash, Gemini 2.5 Pro.
• Protocolo de Auto-Reparo:
  • O modelo gera uma solução inicial (R0).
  • Se falhar, o traceback do erro e a mensagem de exceção são enviados de volta ao modelo junto com a especificação original e a tentativa anterior.
  • O modelo é solicitado a gerar uma versão corrigida.
  • O ciclo repete-se por até 4 rodadas de reparo (total de 5 tentativas por problema).
  • Todos os modelos usam decodificação gulosa (greedy decoding, temperatura = 0.0) para garantir reprodutibilidade.
• Análises Adicionais:
  • Classificação de erros (Syntax, Name, Assertion, etc.).
  • Comparação entre reparo iterativo vs. resampling independente (amostragem estocástica).
  • Ablação de prompts (Prompt mínimo vs. Explain-then-fix vs. Chain-of-Thought).

3. Principais Contribuições

1. Eficácia Universal do Auto-Reparo: Demonstra que o auto-reparo baseado em prompts é eficaz em todos os 7 modelos testados, incluindo modelos de pequena escala (8B), atualizando a conclusão anterior de que modelos fracos falham nesse processo sem fine-tuning.
2. Comparação Arquitetural (Dense vs. MoE): Primeira comparação direta de arquiteturas densas e MoE para auto-reparo, revelando padrões distintos de interação e ganhos.
3. Análise de Tipos de Erro: Identifica que a categoria do erro é um preditor forte de sucesso. Erros de Assertion (lógica) são os mais difíceis de corrigir (45%), enquanto erros de Name (variáveis não definidas) têm altas taxas de reparo (77%).
4. Lei dos Rendimentos Decrescentes: Quantifica que a maioria dos ganhos (76-95%) ocorre nas duas primeiras rodadas de reparo.
5. Eficiência de Tokens: Estende a análise de exploration-exploitation (reparo vs. resampling), mostrando que o reparo iterativo é mais eficiente em tokens para modelos capazes.
6. Impacto do Prompting: Mostra que o uso de Chain-of-Thought (CoT) no prompt de reparo pode adicionar até +5.5 pontos percentuais de ganho adicional para modelos maiores.

4. Resultados Chave

• Melhoria Universal: Todos os modelos melhoraram suas taxas de sucesso em ambos os benchmarks.
  • HumanEval: Ganhos de +4.9 a +17.1 pontos percentuais (pp).
  • MBPP: Ganhos de +16.0 a +30.0 pp.
• Desempenho Final:
  • O Gemini 2.5 Flash alcançou as taxas finais mais altas: 96.3% no HumanEval e 93.8% no MBPP.
  • O Gemini 2.5 Pro teve o maior ganho absoluto no HumanEval (+17.1 pp), mas uma taxa inicial mais baixa devido ao overhead de seu raciocínio nativo interferir na extração de código.
• Arquiteturas:
  • O Llama 4 Scout (MoE) obteve o maior ganho entre modelos open-weight no HumanEval (+14.0 pp).
  • O Llama 3.3 70B (Dense) competiu de perto com modelos MoE maiores, sugerindo que modelos densos grandes são altamente competitivos.
• Análise de Erros:
  • Erros de Assertion (lógica incorreta) são a principal barreira, com taxas de reparo de apenas ~45%.
  • Erros de Syntax e Name são corrigidos com muito mais facilidade.
• Reparo vs. Resampling:
  • Para modelos capazes (≥32B), o auto-reparo (guloso) supera ou iguala o pass@5 de amostragem estocástica, utilizando menos da metade dos tokens.
  • Para o modelo mais fraco (8B), o resampling ainda foi ligeiramente superior, indicando que a diversidade de amostras compensa a baixa compreensão de erros.
• Prompting: O uso de Chain-of-Thought (CoT) no prompt de reparo foi superior ao prompt mínimo para todos os modelos testados na ablação, especialmente para o Llama 3.3 70B.

5. Significado e Implicações Práticas

• Mudança de Paradigma: O auto-reparo não requer mais fine-tuning específico para modelos modernos instruídos; funciona nativamente com prompts. Isso torna a técnica acessível e escalável.
• Guia de Implantação:
  • Duas rodadas são suficientes: Para a maioria das aplicações, realizar apenas duas rodadas de reparo captura a maior parte do benefício, otimizando custos computacionais.
  • Seleção de Modelo: Para máxima precisão final, modelos como Gemini 2.5 Flash ou Llama 4 Maverick são superiores. Para eficiência de custo (ganho por token), o Gemini 2.5 Pro e Llama 3.3 70B são ideais.
  • Estratégia Híbrida: Para erros de lógica (assertion), que são difíceis de reparar, pode ser mais eficiente combinar reparo com amostragem de múltiplas soluções independentes.
• Limitações e Futuro: O estudo foca em benchmarks relativamente fáceis (HumanEval/MBPP). Embora testes preliminares no LiveCodeBench mostrem eficácia em problemas mais difíceis, a avaliação em benchmarks de nível competitivo e o uso de decodificação estocástica para reparo são direções futuras necessárias.

Em suma, o artigo estabelece que o auto-reparo iterativo é uma técnica prática, sem necessidade de treinamento, que melhora universalmente a geração de código em LLMs modernos, com ganhos significativos concentrados nas primeiras tentativas e dependência crítica da capacidade do modelo em compreender mensagens de erro.