A Differential Fuzzing-Based Evaluation of Functional Equivalence in LLM-Generated Code Refactorings

1. Problema

O uso de Grandes Modelos de Linguagem (LLMs) para refatoração automática de código está em crescimento, visando melhorar a qualidade interna do software sem reescritas manuais. No entanto, um critério fundamental para a confiança nesses sistemas é a equivalência funcional: o código refatorado deve manter o mesmo comportamento semântico do original.

O problema central identificado pelos autores é que as avaliações anteriores baseiam-se quase exclusivamente em testes pré-definidos (como métricas de pass@k ou proporção de testes aprovados). Essa abordagem é falha porque:

• Os conjuntos de testes existentes cobrem apenas uma fração limitada do espaço de entrada.
• Um código refatorado pode passar em todos os testes existentes, mas ainda assim alterar a semântica do programa em casos não cobertos pelos testes.
• Não há garantia de que os testes existentes sejam suficientes para detectar divergências semânticas profundas.

2. Metodologia

Para superar as limitações dos testes estáticos, os autores propõem uma avaliação em larga escala utilizando Fuzzing Diferencial (Differential Fuzzing).

• Abordagem (Eq@DFuzz): Em vez de depender de testes manuais, o estudo utiliza um fuzzer (Atheris) para gerar automaticamente milhares de entradas de teste diversas que respeitam as restrições de tipos e dependências do código.
• Verificação de Equivalência: O código original e o código refatorado são executados com as mesmas entradas geradas. Se houver qualquer discrepância na saída para qualquer entrada, o refatoramento é classificado como não equivalente.
• Configuração Experimental:
  • Modelos (6 LLMs): CodeLlama, Codestral, StarChat2, Qwen-2.5, Olmo-3 e GPT-4o (incluindo modelos open-source e fechados).
  • Datasets (3): HumanEval, MBPP e APPS (cobrindo níveis de função e programa).
  • Tarefas de Refatoração: Otimização de desempenho e simplificação de código.
  • Prompting: Uso de prompts zero-shot para instruir os modelos a refatorar o código sem alterar a funcionalidade.
  • Escala: Foram gerados e analisados 4.368 refatoramentos, dos quais 3.538 foram válidos para análise final.

3. Contribuições Principais

1. Método de Avaliação Robusto: Introdução e aplicação da métrica Eq@DFuzz, que elimina a dependência de suites de testes pré-existentes e explora um espaço de entrada muito maior através da geração automática de casos de teste.
2. Avaliação em Larga Escala: A primeira análise abrangente da equivalência funcional de seis LLMs de ponta em múltiplos datasets e tipos de refatoração.
3. Demonstração da Insuficiência dos Testes Atuais: Evidência empírica de que as suites de testes padrão de benchmarks populares (HumanEval, MBPP, APPS) falham em detectar uma proporção significativa de erros semânticos introduzidos por LLMs.

4. Resultados Chave

• Alta Taxa de Não Equivalência: Todos os modelos avaliados apresentaram uma tendência não trivial de alterar a semântica do programa. A taxa de refatoramentos funcionalmente não equivalentes variou entre 19% e 35%, dependendo do modelo.
  • O Codestral teve a pior performance (~35% de falhas).
  • Modelos considerados State-of-the-Art (como GPT-4o e Qwen-2.5) ainda produziram cerca de 19-22% de refatoramentos não equivalentes.
• Impacto da Complexidade: A probabilidade de falha aumenta com a complexidade do código. No dataset APPS (código de nível de programa), a taxa de refatoramentos que quebram a funcionalidade foi 7 a 10 pontos percentuais maior do que em datasets de nível de função (MBPP e HumanEval).
• Falha dos Testes Existentes (RQ2): O estudo descobriu que, em média, 21,65% dos refatoramentos identificados como não equivalentes pelo fuzzing diferencial passaram em todos os testes existentes dos datasets.
  • Isso indica que confiar apenas na aprovação de testes existentes superestima drasticamente a correção dos LLMs.
  • Mesmo datasets com muitos casos de teste (como APPS) falharam em detectar essas divergências, sugerindo redundância nos caminhos de execução testados.

5. Significado e Implicações

• Risco de Confiança Cega: A dependência exclusiva de LLMs para refatoração de código é arriscada, pois eles frequentemente introduzem erros semânticos sutis que não são capturados por testes convencionais.
• Reavaliação de Métricas: A comunidade de engenharia de software deve reconsiderar o uso de "taxa de aprovação de testes" como o principal proxy para correção em tarefas de geração e transformação de código.
• Necessidade de Novas Ferramentas: É imperativo adotar técnicas de verificação mais fortes, como o fuzzing diferencial, para validar a correção funcional antes de integrar refatoramentos automáticos em pipelines de CI/CD.
• Limitações dos Benchmarks: Os datasets atuais, amplamente utilizados para avaliar LLMs, podem não ser adequados para garantir a segurança semântica em tarefas de refatoração, exigindo a criação de novas benchmarks ou a expansão de suites de testes.

Em conclusão, o artigo alerta que, embora os LLMs sejam poderosos para reescrever código, eles ainda não são confiáveis para garantir a preservação da funcionalidade sem o uso de métodos de validação mais rigorosos do que os testes unitários tradicionais.