Resumo Técnico: MigrationBench

Declaração do Problema

Embora os Modelos de Linguagem de Grande Escala (LLMs) tenham demonstrado sucesso significativo na geração de código e na resolução de problemas isolados, suas capacidades em migração de código em nível de repositório permanecem subavaliadas. Diferentemente de tarefas focadas em funções ou arquivos únicos, a migração de código exige uma abordagem holística para navegar em questões interconectadas em toda uma base de código, particularmente ao atualizar sistemas legados. Especificamente, há uma falta de conjuntos de dados de referência (benchmarks) de grande escala e alta qualidade projetados para avaliar a migração de repositórios Java 8 para versões modernas de Suporte de Longo Prazo (LTS) (Java 17 e 21). Os benchmarks existentes frequentemente focam na geração de código, tradução entre linguagens ou tarefas de manutenção em pequena escala, falhando em capturar a complexidade e a escala de cenários de migração do mundo real envolvendo milhares de linhas de código e árvores de dependências complexas.

Metodologia

1. Curadoria do Conjunto de Dados (MigrationBench)

Os autores introduzem o MigrationBench, o primeiro benchmark de grande escala para migração de repositórios Java. O processo de curadoria envolveu um pipeline rigoroso de filtragem em múltiplas etapas aplicado a repositórios do GitHub:

• Filtragem Inicial: Os repositórios foram filtrados por licença (MIT/Apache 2.0), qualidade (mínimo de 3 estrelas) e ferramenta de build (Maven).
• Verificação de Compatibilidade: A equipe identificou um "commit base" ($H_b$) para cada repositório onde o código compila com sucesso e passa nos testes sob Java 8. Isso envolveu verificar configurações de pom.xml, garantindo que não houvesse versões Java 8 codificadas manualmente incompatíveis com o alvo, e validando que as versões principais das classes compiladas fossem 52 (Java 8).
• Deduplicação: Os repositórios foram deduplicados com base em correspondências exatas de hashes de arquivos e conteúdo.
• Requisito de Teste: Os repositórios foram particionados em um conjunto de dados Full (5.102 repositórios com testes unitários) e um subconjunto UTG (4.814 repositórios sem testes). O conjunto de dados Full serve como o principal benchmark para avaliação de migração.
• Subconjunto Selecionado: Um subconjunto representativo de 300 repositórios (selected) foi curado a partir do conjunto de dados Full. Este subconjunto enfatiza repositórios maiores e multi-módulo para refletir melhor a diversidade e a intrincação dos desafios de migração do mundo real.

2. Framework de Avaliação

Devido à ausência de repositórios alvo de verdade absoluta (ground-truth), os autores propõem um framework de avaliação automatizado baseado em Equivalência Funcional Aproximada (FE):

• Migração Mínima: Definida por quatro critérios:
  1. Sucesso de Build: mvn clean verify passa sob Java 17.
  2. Validação de Versão: As classes compiladas possuem uma versão principal de 61 (Java 17).
  3. Invariância do Método de Teste: Os métodos de teste (anotados com @Test) não são renomeados, desabilitados ou removidos (verificado via análise de AST).
  4. Invariância da Contagem de Testes: O número de casos de teste não diminui.
• Migração Máxima: Baseia-se na migração mínima adicionando um quinto critério:
  5. Modernização de Dependências: Todas as dependências são atualizadas para suas versões principais estáveis mais recentes disponíveis no Maven Central (a partir de novembro de 2024).

3. Frameworks Agênticos

O artigo avalia várias abordagens baseadas em agentes usando o framework de agente Strands e o Claude-4.5-Sonnet:

• Baseline (Agente Strands): Equipado com ferramentas de shell e edição para migrar código e garantir que mvn clean verify passe.
• Agente de Engenharia de Prompt (PE): Augmentado com prompts de sistema instruindo explicitamente o agente a atualizar todas as dependências para suas versões principais mais recentes.
• Agente RAG: Incorpora uma abordagem de Geração Aumentada por Recuperação (Retrieval-Augmented Generation) onde o agente consulta uma base de conhecimento externa de dependências para identificar as versões mais recentes corretas.
• Abordagem Híbrida: Combina análise estática de código (atualizando dependências de forma determinística) com o agente LLM. A ferramenta estática lida com atualizações de versão, e o agente corrige falhas de build e problemas de compatibilidade resultantes.

Principais Contribuições

1. Conjunto de Dados MigrationBench: A introdução do primeiro benchmark de grande escala para migração de código em nível de repositório, compreendendo 5.102 repositórios (Full) e um subconjunto curado de 300 repositórios (Selected).
2. Framework de Avaliação: Um framework abrangente e automatizado para avaliar o sucesso da migração através de critérios mínimos e máximos, abordando a falta de verdade absoluta em tarefas de migração.
3. Soluções Agênticas: A proposta e avaliação de um fluxo de trabalho agêntico para migração de código, incluindo uma nova Abordagem Híbrida que combina análise estática com raciocínio de LLM para melhorar a eficiência.
4. Recursos Abertos: O lançamento do conjunto de dados, código-fonte de avaliação e trajetórias detalhadas de agentes (incluindo decisões intermediárias e modos de falha) para apoiar a reprodutibilidade e pesquisas futuras.

Resultados Experimentais

Os experimentos foram conduzidos no subconjunto selected (300 repositórios) usando o framework de agente Strands com Claude-4.5-Sonnet.

• Migração Mínima: O agente Strands baseline alcançou uma taxa de sucesso de 71,67% (pass@1) para migração mínima.
• Migração Máxima:
  • O agente baseline alcançou apenas 15,33% de sucesso.
  • Adicionar Engenharia de Prompt (PE) aumentou a eficácia para 45,67%.
  • Incorporar RAG melhorou ainda mais a eficácia para 53,33%.
  • A Abordagem Híbrida igualou a eficácia do agente RAG de 53,33% enquanto reduzia o número médio de chamadas de LLM por repositório (52,55 vs. 59,22), demonstrando uma relação custo-eficiência favorável.
• Comparação de Modelos: Ao aplicar a Abordagem Híbrida a outros modelos (DeepSeek-V3.1, Qwen3-Coder-480B, GLM-5), o Claude-4.5-Sonnet permaneceu o mais eficaz, embora outros modelos tenham mostrado graus variados de sucesso (por exemplo, GLM-5 alcançou 45,33%).
• Compilação vs. Verificação: Desabilitar testes unitários (confiando apenas em mvn clean compile) aumentou a eficácia da migração mínima de 71,67% para 97,67%, destacando o papel crítico dos conjuntos de teste na validação da equivalência funcional.

Significado e Alegações

O artigo posiciona o MigrationBench como um recurso crítico para avançar a pesquisa em engenharia de software e capacidades de LLM. Os autores afirmam que:

• Lacuna de Complexidade: Tarefas de migração apresentam um nível de dificuldade significativamente maior do que a geração de código ou resolução de problemas isolados, exigindo compreensão holística do repositório.
• Viabilidade: LLMs, particularmente quando guiados por fluxos de trabalho agênticos e conhecimento externo (RAG) ou análise estática híbrida, podem lidar efetivamente com migração em nível de repositório do Java 8 para o Java 17.
• Padronização: O framework de avaliação proposto fornece um método rigoroso e padronizado para avaliar o sucesso da migração, indo além de verificações simples de compilação para incluir modernização de dependências e preservação de testes.
• Direção Futura: O lançamento das trajetórias de agentes e do subconjunto UTG abre novas vias para estudar limitações de agentes, modos de falha e a geração de testes unitários para código legado.

Os autores reconhecem limitações, incluindo a dependência da cobertura de testes existente (que pode não garantir equivalência funcional completa para código não testado) e possíveis problemas de reprodutibilidade devido à limitação de taxa (throttling) do Maven Central durante a coleta de dados em grande escala. No entanto, eles mantêm que o MigrationBench oferece uma base robusta para avaliação sistemática e reprodutível de métodos de migração de código.