Resumo Técnico: SWE-Refactor

Declaração do Problema

Embora os Grandes Modelos de Linguagem (LLMs) tenham demonstrado uma capacidade significativa na geração de código, a refatoração de código apresenta desafios distintos. A refatoração exige edições precisas que preservem a semântica, melhorando a estrutura do programa sem alterar o comportamento. Esta tarefa exige raciocínio ao nível de repositório, compreensão de dependências complexas e verificação iterativa — capacidades que são difíceis de avaliar e que muitas vezes estão além do alcance dos modelos atuais.

Os benchmarks existentes para refatoração de código sofrem de quatro deficiências críticas:

1. Cobertura Limitada de Cenários: Eles focam predominantemente em tipos de refatoração atômicos (transformações únicas) em vez de refatorações compostas (múltiplas transformações coordenadas) comuns no desenvolvimento real.
2. Falta de Construção Automatizada: Muitos benchmarks dependem de curadoria manual ou de verdade fundamental (ground truth) gerada por LLMs, introduzindo viés e problemas de escalabilidade.
3. Contexto Insuficiente ao Nível de Repositório: Os conjuntos de dados existentes frequentemente carecem da informação estrutural (ex: hierarquias de classes, relações chamador/chamado) necessária para uma avaliação realista.
4. Dados Ruidosos: Muitos benchmarks incluem commits "impuros" onde a refatoração é misturada com correções de bugs ou adições de funcionalidades, tornando difícil isolar e avaliar as capacidades de refatoração do modelo.

Além disso, o campo sofre com a falta de diversidade em linguagens de programação, com a maioria dos benchmarks recentes focando exclusivamente em Python, apesar de o Java ser uma linguagem dominante em sistemas corporativos.

Metodologia: SWE-Refactor

Para abordar essas lacunas, os autores introduzem o SWE-Refactor, um benchmark ao nível de repositório construído a partir de projetos Java do mundo real. O benchmark é construído usando um pipeline totalmente automatizado de quatro etapas:

1. Mineração via Análise Estática: Os autores utilizam o RefactoringMiner, uma ferramenta baseada em AST, para extrair commits contendo refatorações de 18 projetos Java amplamente utilizados.
2. Curadoria de Refatorações Puras: Usando o PurityChecker (uma extensão do RefactoringMiner), o pipeline filtra mudanças impuras (ex: correções de bugs) para reter apenas refatorações "puras". Os autores verificaram manualmente uma amostra aleatória de 200 instâncias para confirmar a confiabilidade dos detectores.
3. Enriquecimento com Informação de Múltiplos Níveis: Para suportar o raciocínio ao nível de repositório, o pipeline utiliza o Eclipse JDT para extrair um contexto abrangente, incluindo estrutura do projeto, corpos de classe completos, chamadores/chamados de métodos e configurações de build.
4. Verificação: O pipeline garante a correção funcional compilando o projeto com a versão apropriada do JDK e executando a suíte de testes completa (usando JaCoCo) para verificar que a refatoração preserva o comportamento.

Composição do Conjunto de Dados:

• Escala: 1.099 refatorações escritas por desenvolvedores e que preservam o comportamento.
• Fontes: 18 projetos Java diversos.
• Tipos: Inclui 922 instâncias atômicas e 177 instâncias compostas.
• Tipos de Refatoração: Cobre três tipos atômicos (Extract Method, Move Method, Inline Method) e três tipos compostos (Extract and Move, Move and Inline, Move and Rename).

Métricas de Avaliação:
O benchmark avalia o desempenho de LLMs em duas dimensões:

1. Correção Funcional: Medida pelo sucesso da compilação, taxas de passagem de testes e Verificação de Refatoração Baseada em AST (usando RefactoringMiner para garantir que a transformação pretendida ocorreu sem efeitos colaterais indesejados).
2. Semelhança com Humanos (Human-Likeness): Medida usando CodeBLEU para avaliar a similaridade com a verdade fundamental escrita pelo desenvolvedor.

Contribuições Principais

1. Benchmark SWE-Refactor: Um novo conjunto de dados de alta qualidade com 1.099 refatorações puras de 18 projetos Java, cobrindo tanto transformações atômicas quanto compostas. É o primeiro a fornecer contexto abrangente ao nível de repositório e verificação automatizada para Java.
2. Pipeline de Construção Automatizado: Um pipeline reproduzível de quatro etapas que extrai refatorações do mundo real, filtra pela pureza, enriquece dados estruturais e verifica a correção sem necessidade de anotação manual ou ground truth gerado por LLM.
3. Avaliação Abrangente: Uma avaliação extensa de 9 LLMs amplamente utilizados (incluindo GPT-4o-mini, DeepSeek-V3 e várias variantes de CodeLLaMa/Qwen) através de diferentes tipos de refatoração e estratégias de prompting (Prompt Simples, RAG e fluxos de trabalho Multi-Agente).

Resultados Experimentais

Os autores avaliaram 9 LLMs nos 1.099 casos. As principais descobertas incluem:

• Desempenho Geral: Modelos de propósito geral superaram modelos específicos de código de código aberto. O DeepSeek-V3 alcançou a maior taxa de sucesso (41,58%), seguido pelo GPT-4o-mini (39,85%). Modelos de código aberto como o CodeLLaMa-7B alcançaram apenas 1,10% de sucesso.
• Atômico vs. Composto: Os modelos tiveram um desempenho significativamente melhor em refatorações atômicas (edições locais) do que em refatorações compostas (transformações entre arquivos e de múltiplos passos).
  • O DeepSeek-V3 destacou-se em Extract Method (301 sucessos).
  • O GPT-4o-mini mostrou uma generalização mais ampla em tarefas entre arquivos, como Move Method (92 sucessos).
  • Modelos de código aberto lutaram quase inteiramente com tipos compostos.
• Impacto de Técnicas Avançadas:
  • Fluxos de Trabalho Multi-Agente: Um fluxo de trabalho utilizando um Agente Desenvolvedor e um Agente Revisor (usando GPT-4o-mini) alcançou o maior sucesso geral (579 instâncias), superando significativamente o prompting simples e a Geração Aumentada por Recuperação (RAG), particularmente em refatorações compostas complexas.
  • Estrutura Agêntica (OpenAI Codex): Mesmo um agente poderoso (GPT-5.1-Codex) alcançou apenas 39,4% de taxa de sucesso em instâncias compostas, comparado a 82,6% em instâncias atômicas, destacando a dificuldade persistente de transformações de múltiplos passos e altamente restritas.

Significância e Alegações

O artigo posiciona o SWE-Refactor como uma evolução necessária nos benchmarks de engenharia de software. Sua significância reside em:

• Realismo: Ao usar commits escritos por desenvolvedores de projetos reais, evita os vieses e alucinações associados a benchmarks sintéticos ou gerados por LLM.
• Complexidade: Visa explicitamente a lacuna entre refatorações atômicas e compostas, fornecendo um teste rigoroso para capacidades de raciocínio ao nível de repositório.
• Diversidade de Linguagem: Aborda o viés centrado em Python na literatura atual ao fornecer um benchmark robusto de Java, refletendo as linguagens usadas em sistemas corporativos de grande escala.
• Confiabilidade: O pipeline automatizado garante que a verdade fundamental preserve o comportamento e seja estruturalmente correta, oferecendo um padrão confiável para pesquisas futuras.

Os autores concluem que, embora os LLMs mostrem promessa na geração de código, eles permanecem significativamente desafiados por tarefas de refatoração compostas e complexas, sugerindo que os atuais frameworks agênticos ainda não são confiáveis para manutenção de software de múltiplos passos sem supervisão humana.