Resumo Técnico: Modelos de Fundação como Oráculos para Detecção de Correção de Refatoração

1. Declaração do Problema

Ferramentas de refatoração automatizada em Ambientes de Desenvolvimento Integrado (IDEs) são essenciais para manter a qualidade do código, mas permanecem imperfeitas. Apesar de décadas de pesquisa, essas ferramentas podem introduzir mudanças comportamentais indesejadas ou erros de compilação, minando a confiança do desenvolvedor. Mecanismos de detecção tradicionais dependem de precondições feitas à mão, análise estática e testes dinâmicos (ex: SafeRefactor). No entanto, essas abordagens enfrentam limitações significativas:

• Adaptabilidade: Definir precondições íntegras e completas para a explosão combinatória de construtos de linguagem e casos extremos é desafiador.
• Manutenção: Implementar novas análises para tipos de refatoração ou recursos de linguagem emergentes exige um esforço de engenharia substancial.
• Cobertura: Suítes de teste existentes são frequentemente insuficientes para revelar desvios comportamentais sutis, e análises estáticas podem perder interações complexas.

O artigo postula que modelos de fundação (modelos de propósito geral treinados em dados amplos) podem servir como componentes complementares, do tipo oráculo, para detectar esses bugs. Diferente de sistemas baseados em regras, os modelos de fundação podem raciocinar através de diversos cenosários sem treinamento específico para a tarefa, potencialmente identificando mudanças semânticas sutis que as ferramentas tradicionais perdem.

2. Metodologia

Os autores conduziram um estudo empírico avaliando a capacidade de modelos de fundação para detectar bugs de refatoração em programas Java.

2.1 Construção do Dataset

O estudo utilizou um dataset de 226 bugs de refatoração do mundo real coletados ao longo de mais de uma década de três principais IDEs Java: IntelliJ-IDEA, Eclipse e NetBeans.

• Composição: O dataset inclui 185 erros de compilação (CE) e 41 mudanças comportamentais (BC).
• Escopo: Abrange 47 tipos distintos de refatoração, sendo os mais frequentes Move Method, Inline Method e Pull Up Method.
• Verdade Fundamental (Ground Truth): Os autores reconstruíram programas Java executáveis para cada relatório de bug. Para instâncias de BC, eles geraram casos de teste JUnit específicos que passam no programa original, mas falham na versão refatorada, fornecendo evidência executável da desviação comportamental.

2.2 Configuração Experimental

• Modelos Avaliados:
  • Peso Aberto (Open-Weight): GPT-OSS-20B (execução local), Llama-3.2-3B, Phi-4-14B, Gemma-4-31B e Qwen-3.6-35B.
  • Proprietários: GPT-5.4, Gemini-3.1-Pro-Preview e Claude-4.6-Sonnet.
• Estratégia de Prompting: O estudo empregou prompting zero-shot sem fine-tuning específico para a tarefa. Os modelos foram solicitados a analisar o código original (code1) e o código refatorado (code2) para determinar se a transformação introduziu um erro de compilação ou uma mudança comportamental.
• Requisitos de Saída: Os modelos foram obrigados a retornar um JSON estruturado contendo um veredito (YES, NO - COMPILATION ERROR, ou NO - BEHAVIOR CHANGE), uma breve explicação e, se aplicável, um teste JUnit gerado para provar a diferença de comportamento.
• Métricas de Avaliação:
  • Acurácia: Acurácia média e pass@k (sucesso dentro de $k$ tentativas).
  • Estabilidade: Dispersão de acurácia, Taxa de Acordo Total (tar@k) e Acurácia de Consenso (cons@k).
  • Robustez: Testes metamórficos foram aplicados para avaliar a estabilidade sob perturbações que preservam o comportamento (ex: adicionar comentários, campos não utilizados ou imports) para mensurar a sensibilidade à contaminação de dados ou memorização.

2.3 Viabilidade em Grandes Projetos

Um estudo de viabilidade secundário avaliou os modelos em 44 diffs de refatoração do mundo real de grandes projetos de código aberto usando um prompt apenas de diff. Neste cenário, os modelos careciam de contexto total do projeto e tinham permissão para retornar um veredito UNKNOWN se o diff carecesse de informações suficientes.

3. Resultados Principais

3.1 Acurácia de Detecção

• Modelos Proprietários: Gemini-3.1-Pro-Preview alcançou a maior acurácia geral (99,6%), classificando corretamente 225 de 226 instâncias. GPT-5.4 e Claude-4.6-Sonnet seguiram com 93,8% e 94,7% de acurácia, respectivamente.
• Modelos de Peso Aberto: Gemma-4-31B superou outros modelos abertos com 96,5% de acurácia, superando o desempenho de primeira execução do GPT-5.4. GPT-OSS-20B alcançou 80,5% de acurácia.
• Tipos de Erro:
  • Erros de Compilação (CE): Modelos proprietários geralmente se destacaram aqui. O Gemini-3.1-Pro-Preview alcançou 100% de acurácia em CE. O GPT-OSS-20B teve mais dificuldades com CE (77,8%), frequentemente classificando erroneamente código não compilável como preservação de comportamento ou mudança de comportamento.
  • Mudanças Comportamentais (BC): Todos os principais modelos tiveram bom desempenho (92,7%–97,6%). Um modo de falha comum foi a incapacidade de gerar um teste JUnit válido que compilasse com sucesso e expusesse a diferença.

3.2 Estabilidade e Robustez

• Amostragem Repetida: Para o GPT-OSS-20B, a amostragem repetida (até 5 tentativas) aumentou a cobertura cumulativa de 80,5% para 92,9%. O GPT-5.4 mostrou alta estabilidade, com ganhos marginais de tentativas repetidas (93,8% para 97,3%).
• Testes Metamórficos: Tanto o GPT-OSS-20B quanto o GPT-5.4 mostraram alta estabilidade sob perturbações de código fonte que preservam o comportamento (ex: adicionar comentários ou variáveis não utilizadas), com mudanças de acurácia inferiores a 1%. No entanto, os autores observam que isso indica robustez a perturbações específicas, não necessariamente imunidade à contaminação de dados.
• Sensibilidade de Temperatura: O GPT-OSS-20B mostrou sensibilidade variável às configurações de temperatura; temperaturas baixas (0.1–0.5) favoreceram a detecção de mudança de comportamento, enquanto temperaturas altas (0.8) favoreceram a detecção de erro de compilação. A detecção de mudança de comportamento do GPT-5.4 caiu significativamente sob decodificação determinística ($T=0$).

3.3 Viabilidade de Diff-Only

Na avaliação de apenas diff, 40,9% dos casos foram classificados como UNKNOWN pelo GPT-5.4. Os autores atribuem isso ao contexto insuficiente no diff (ex: referências ausentes a métodos ou campos movidos em outras partes do codebase), destacando uma limitação no uso de modelos de fundação como oráculos autônomos para projetos de grande escala sem contexto total.

3.4 Comparação com Baselines Tradicionais

• SafeRefactor: Alcançou 97,8% de acurácia no dataset, mas falhou em 5 casos devido a incompatibilidades de versão (a ferramenta depende de Java 8, enquanto o dataset inclui recursos de Java mais recentes).
• Modelos de Fundação: O modelo de fundação mais forte (Gemini-3.1-Pro-Preview) igualou ou superou ligeiramente a acurácia do SafeRefactor (99,6%) enquanto lidava nativamente com novos recursos do Java.
• Compromisso (Trade-off): Ferramentas tradicionais fornecem evidência determinística e executável. Modelos de fundação fornecem avaliações probabilísticas com justificativas em linguagem natural, mas carecem de garantias formais.

4. Principais Contribuições

1. Avaliação Empírica: O primeiro estudo abrangente avaliando modelos de fundação como oráculos zero-shot para detecção de bugs de refatoração em cenários reais de IDE.
2. Curadoria de Dataset: A extensão e reconstrução de um dataset de 226 bugs de refatoração em artefatos executáveis, incluindo testes JUnit específicos para mudanças comportamentais.
3. Análise de Robustez Metamórfica: Uma avaliação da estabilidade do modelo sob perturbações de código fonte que preservam o comportamento para avaliar a robustez contra vazamento de dados.
4. Análise de Custo e Latência: Uma análise comparativa do custo monetário e tempo de execução de modelos locais de peso aberto versus modelos proprietários via API, destacando compromissos para implantação.
5. Estudo de Viabilidade de Diff-Only: Uma investigação das limitações do uso de modelos de fundação para validação de refatoração em grandes projetos onde o contexto total não está disponível.

5. Significância e Alegações

O artigo afirma que os modelos de fundação são ferramentas complementares promissoras para a detecção de correção de refatoração, em vez de substitutos para técnicas de verificação tradicionais.

• Papel Complementar: Os autores argumentam que os modelos de fundação podem sinalizar transformações suspeitas e fornecer justificativas explicativas, auxiliando a inspeção do desenvolvedor. Eles são particularmente úteis em cenários onde ferramentas tradicionais são incompletas, custosas ou difíceis de configurar para novos recursos de linguagem.
• Adaptabilidade: Diferente de sistemas baseados em regras que exigem atualizações manuais para novos construtos de linguagem, os modelos de fundação demonstraram a capacidade de analisar refatorações envolvendo novos recursos do Java (ex: var, expressões de switch) sem treinamento específico.
• Limitações: O artigo conclui modestamente que os modelos de fundação não fornecem garantias formais. Sua eficácia depende do design do prompt, disponibilidade de contexto e configurações de decodificação. O estudo enfatiza que a supervisão humana continua crucial, especialmente quando as explicações do modelo são plausíveis, mas insuficientemente fundamentadas.
• Direção Futura: Os autores sugerem fluxos de trabalho híbridos onde ferramentas determinísticas lidam com verificações de compilação e modelos de fundação auxiliam na avaliação de equivalência semântica e triagem, particularmente em IDEs aumentadas por IA.

O estudo não alega que os modelos de fundação resolveram o problema da correção de refatoração; em vez disso, fornece evidências de que eles podem servir como oráculos eficazes e de alta acurácia que complementam as práticas de engenharia existentes.