Resumo Técnico: PROBE: Avaliando o Desempenho de Geração de Código em Grandes Modelos de Linguagem

Declaração do Problema

Grandes Modelos de Linguagem (LLMs) são cada vez mais utilizados para a geração automatizada de código, mas sua confiabilidade permanece insuficiente para a engenharia de software de produção. Os benchmarks existentes para a geração de texto-para-código sofrem de limitações significativas: frequentemente visam uma única linguagem de programação, dependem exclusivamente de resultados de testes unitários (métricas de passar/falhar) e negligenciam dimensões críticas como a proximidade do código gerado em relação a soluções válidas e a qualidade geral do código. Além disso, muitas avaliações existentes carecem de procedimentos experimentais rigorosos, dificultando a reprodutibilidade e a comparação justa entre modelos e linguagens. Há uma necessidade de um framework de benchmarking sistemático, extensível e multidimensional para avaliar com precisão os pontos fortes e as limitações dos LLMs na geração de código.

Metodologia: O Framework PROBE

Os autores introduzem o PROBE, um framework de benchmarking sistemático e extensível projetado para avaliar LLMs através de três dimensões complementares: corretude funcional, proximidade de soluções válidas e qualidade do código.

Componentes Principais

1. Enquadramento do Problema e Carga de Trabalho:

   • A carga de trabalho é derivada do conjunto de dados IBM CodeNet, que compreende 1.651 problemas de programação em cinco linguagens: Python, C++, Java, C e Rust.
   • Os problemas foram pré-processados para remover o viés de linguagem (ex: removendo descrições em japonês) e formatados em descrições de tarefas estruturadas.
   • Testes Unitários: Cada problema inclui pelo menos três testes unitários para avaliação e um reservado para Aprendizado em Contexto (ICL). Os testes foram aumentados usando LLMs onde necessário e validados contra múltiplas soluções de referência para garantir a cobertura (cobertura de linha média: 97,1%).
   • Soluções de Referência: Múltiplas soluções de referência (3 a 250 por problema) foram filtradas quanto à corretude e outliers estruturais para servirem como verdade fundamental para as métricas de proximidade e qualidade.

2. Métricas de Avaliação:

   • Corretude Funcional: Medida via pass@k (probabilidade de que pelo menos uma das $k$ amostras seja correta) e Taxa de Resultado (categorizando resultados como Passou, Falhou, Tempo Limite Excedido, Erro, Não Compila ou Sem Código).
   • Proximidade de Solução Válida: Avaliada usando CodeBLEU, uma métrica que combina correspondência de n-gramas, similaridade sintática (AST) e semântica (fluxo de dados) contra as soluções de referência.
   • Qualidade do Código: Avaliada usando métricas de análise estática: Complexidade Ciclomática e Número de Linhas de Código (NLOC). Estas são computadas apenas para soluções corretas e normalizadas em relação às implementações de referência para considerar a dificuldade do problema.

3. Procedimento Experimental:

   • Modelos Avaliados: Seis modelos foram testados, incluindo dois proprietários (GPT-4.1-mini, Gemini-2.0-flash) e quatro de código aberto (variantes Qwen2.5, Deepseek-Coder-v2).
   • Estratégias de Prompting: Três estratégias foram comparadas:
     • Baseline: Prompt padrão com descrição da tarefa.
     • Aprendizado em Contexto (ICL): Aprendizado de 1-shot com um par de entrada-saída de exemplo.
     • Incorporação de Feedback: Refinamento iterativo onde o modelo recebe feedback de execução (ex: erros de compilação, erros de tempo de execução) e tenta corrigir o código (até duas iterações).
   • Agrupamento por Dificuldade: Os problemas foram agrupados em quatro níveis de dificuldade baseados em métricas de código estático (complexidade ciclomática, esforço, SLOC) das soluções de referência.

Resultados Principais

Corretude Funcional

• Escala do Modelo: Modelos maiores superaram consistentemente os menores. No entanto, mesmo os modelos mais fortes (GPT-4.1-mini) atingiram um pass@1 máximo de apenas 0,70 em Python, indicando que nenhum modelo é atualmente "pronto para uso" para todas as tarefas.
• Dependência de Linguagem: O desempenho variou significativamente por linguagem. Python apresentou as maiores taxas de sucesso, seguido por C++ e Java. Rust foi a mais desafiadora, particularmente para modelos menores, provavelmente devido à sintaxe mais rigorosa e menores recursos de treinamento.
• Estratégias de Prompting:
  • ICL: Teve um impacto negligível no desempenho (mudanças < 0,01), sugerindo que o prompt base já fornecia orientação estrutural suficiente.
  • Incorporação de Feedback: Produziu ganhos consistentes e significativos (+0,05 de aumento médio em pass@k). Esta estratégia reduziu principalmente erros de compilação (ex: importações ausentes, incompatibilidades de tipos) por uma margem substancial, especialmente em linguagens rigorosas como Rust e C++.

Proximidade e Qualidade do Código

• Proximidade: Modelos mais fortes geraram códigos mais similares às soluções de referência (maiores pontuações CodeBLEU). No entanto, a similaridade diminuiu conforme a dificuldade do problema aumentava. O feedback e o ICL tiveram impacto mínimo na similaridade estrutural, indicando que as correções foram localizadas, não estruturais.
• Qualidade do Código: O código gerado por LLM foi geralmente mais simples e curto (menor complexidade ciclomática e NLOC) do que as referências escritas por humanos, exceto em Python. Essa tendência foi mais pronunciada em Rust, C++ e Java.
• Impacto da Dificuldade: À medida que a dificuldade do problema aumentava, a corretude funcional e a proximidade das soluções caíam drasticamente. No entanto, a lacuna na qualidade do código entre o código do LLM e o código humano não aumentou sistematicamente, sugerindo que os modelos não produzem necessariamente códigos estruturalmente "piores" para problemas difíceis, mas sim falham em resolvê-los.

Análise de Erros

A inspeção manual do código gerado revelou que as falhas frequentemente derivavam de erros fundamentais e facilmente evitáveis:

• Erros de Compilação: Importações ausentes, variáveis não definidas e problemas de escopo.
• Erros de Tempo de Execução: Acesso fora dos limites de array, estouros de inteiros (particularmente em Rust) e falhas de alocação de memória.
• Tempos Limite Excedidos (Timeouts): Algoritmos ineficientes (ex: soluções de força bruta $O(N^3)$) e operações desnecessárias (ex: reversões repetidas de lista).
• Lógica Incorreta: Interpretação incorreta de restrições do problema (ex: estratégias gananciosas onde o necessário é programação dinâmica) ou problemas de precisão de ponto flutuante.

Significância e Contribuições

O artigo reivindica as seguintes contribuições:

1. Framework PROBE: Uma metodologia nova, sistemática e extensível que vai além das métricas binárias de passar/falhar para avaliar a geração de código através de corretude funcional, proximidade da solução e qualidade do código.
2. Avaliação em Larga Escala: Um estudo abrangente cobrindo seis modelos diversos, cinco linguagens de programação com diferentes complexidades sintáticas e três paradigmas de prompting.
3. Diretrizes de Extensibilidade: Instruções práticas para integrar novas cargas de trabalho, métricas e métodos de prompting, garantindo que o framework se adapte aos futuros avanços dos LLMs.
4. Análise Detalhada de Erros: Identificação de padrões comuns de falha (ex: estouros, importações ausentes) que destacam os riscos de confiar excessivamente em LLMs para geração de código.
5. Recurso Público: Um repositório publicamente disponível contendo a carga de trabalho, resultados de avaliação e código, promovendo transparência e reprodutibilidade.

Os autores concluem que, embora os LLMs mostrem promessa, eles permanecem não confiáveis para tarefas complexas e frequentemente exibem erros básicos que podem levar a vulnerabilidades ou regressões de desempenho. O estudo ressalta a necessidade de benchmarks robustos e multidimensionais como o PROBE para guiar o desenvolvimento de sistemas de geração de código mais confiáveis.