Resumo Técnico: HEJ-Robust

Declaração do Problema

Recentes Modelos de Linguagem de Grande Escala (LLMs) demonstraram desempenho robusto em Reparo Automático de Programas (APR) em benchmarks padrão. No entanto, os benchmarks existentes, como Defects4J e HumanEval-Java-Bug, tipicamente avaliam os modelos em uma única forma canônica de código defeituoso. Esses benchmarks falham em refletir as variações sintáticas comuns no software do mundo real, deixando a robustez dos modelos de reparo baseados em LLMs amplamente não examinada. Embora se saiba que modelos de código neurais são sensíveis a transformações que preservam a semântica em outras tarefas, a avaliação de robustez para benchmarks de APR em nível de função, criados manualmente por humanos, permanece uma lacuna aberta.

Metodologia

Os autores introduzem o HEJ-Robust, um benchmark de robustez projetado para avaliar a consistência dos modelos de APR sob perturbações sintáticas.

Construção do Conjunto de Dados

• Conjunto de Dados Base: O benchmark é construído sobre o HumanEval-Java-Bug, um conjunto de dados de 164 programas Java manualmente curados com bugs injetados, localizações de linhas defeituosas anotadas, casos de teste executáveis e correções escritas por humanos.
• Transformações: Os autores aplicaram oito transformações de código que preservam a semântica ao conjunto de dados base, resultando em 1.450 instâncias transformadas. Essas transformações refletem práticas comuns de codificação no mundo real:
  1. Renomeação de Variáveis Locais: Renomeia variáveis locais usando substituição consciente de naturalidade (via CodeBERT/GraphCodeBERT) em vez de strings aleatórias.
  2. Renomeação de Métodos: Renomeia nomes de métodos.
  3. Renomeação de Parâmetros: Renomeia parâmetros de métodos.
  4. Inserção de Instruções de Log: Adiciona instruções System.out.println (não afeta os resultados dos testes, pois os testes validam valores de retorno).
  5. Inserção de Try-Catch: Adiciona blocos try-catch em locais aplicáveis.
  6. Troca Booleana: Inverte valores de inicialização booleana e nega usos subsequentes para manter a equivalência semântica.
  7. Troca de Loops: Converte loops for em loops while e vice-versa.
  8. Reordenação de Condições: Troca operandos em expressões == e !=.
• Anotação: Após a transformação, as localizações das linhas defeituosas foram reanotadas manualmente. Instâncias onde a transformação modificou diretamente a linha defeituosa foram removidas para evitar ambiguidade.

Configuração Experimental

• Modelos: Cinco LLMs ajustados finamente foram avaliados: PLBART (base e grande) e CodeT5 (pequeno, base e grande). Eles foram selecionados por serem os únicos modelos de APR ajustados finamente e disponíveis publicamente avaliados no HumanEval-Java-Bug.
• Métricas:
  • Pass@10: A métrica principal para correção funcional (um bug é corrigido se pelo menos uma das 10 correções geradas passar em todos os casos de teste).
  • CodeBLEU: Reportado como uma métrica de controle de referência para similaridade de código.
• Protocolo: Os modelos foram avaliados sem modificação em suas configurações originais de treinamento ou decodificação.

Principais Resultados

A avaliação revela lacunas significativas de robustez nos atuais modelos de reparo baseados em LLM:

• Degradação de Desempenho: Na maioria das transformações, o desempenho do modelo (Pass@10) caiu significativamente. A degradação mais severa ocorreu sob Renomeação de Variáveis Locais, onde o desempenho diminuiu de 50,5% a 57,31% entre os modelos. Isso sugere que os modelos dependem fortemente de padrões específicos de identificadores aprendidos durante o treinamento.
• Impacto Variável:
  • Renomeação de Parâmetros e Inserção de Instruções de Log causaram quedas menores, indicando que o contexto em nível de método ou o registro de log anexado é menos disruptivo.
  • Transformações Estruturais (por exemplo, Troca de Loops) causaram quedas moderadas.
  • Os resultados da Troca Booleana foram excluídos das afirmações principais devido ao pequeno tamanho da amostra (7 instâncias), o que tornou a significância estatística inatingível.
• Correlação com Tamanho do Modelo: A robustez não correlaciona-se com o tamanho do modelo. Em vários casos, modelos maiores (por exemplo, CodeT5-large, PLBART-large) degradaram-se mais do que suas contrapartes menores.
• Confiabilidade da Métrica: As pontuações CodeBLEU permaneceram amplamente estáveis através das transformações, mesmo quando o Pass@10 caiu drasticamente. Isso confirma que o CodeBLEU é um indicador não confiável de robustez funcional para APR, pois os modelos podem produzir correções sintaticamente similares, mas funcionalmente incorretas.

Principais Contribuições

1. Benchmark HEJ-Robust: A introdução de um benchmark de robustez baseado em transformações construído sobre o HumanEval-Java-Bug, cobrindo oito transformações que preservam a semântica e fornecendo avaliação em nível de função, executável por testes.
2. Avaliação Sistemática: Uma avaliação abrangente de cinco LLMs ajustados finamente sob transformações que preservam a semântica, demonstrando que os modelos atuais carecem de robustez a variações sintáticas menores.
3. Recursos Abertos: O lançamento público do benchmark, código e artefatos para facilitar pesquisas futuras sobre reparo automático de programas robusto e confiável.

Significado e Afirmações

O artigo afirma que os atuais modelos de reparo baseados em LLM não são robustos a variações sintáticas menores, uma limitação crítica para implantação no mundo real, onde estilos e estruturas de código variam. Os autores enfatizam que:

• Os benchmarks existentes ignoram a diversidade sintética, potencialmente inflando as capacidades percebidas dos modelos.
• Métricas funcionais (Pass@k) são essenciais para avaliação de robustez, enquanto métricas de similaridade (CodeBLEU) falham em capturar a degradação funcional.
• O benchmark é complementar ao Defects4J-TRANS (que visa bugs em nível de projeto); o HEJ-Robust visa especificamente bugs em nível de função, criados manualmente por humanos.

Os autores concluem que, embora suas descobertas destaquem lacunas substanciais de robustez, eles são modestos quanto à generalização, observando que o benchmark é limitado a programas isolados em nível de função e famílias de modelos específicas (PLBART e CodeT5). Sugere-se trabalho futuro para explorar espaços de transformação mais ricos, dependências em nível de projeto e LLMs ajustados por instrução ou baseados em agentes.