Resumo Técnico: Além da Taxa de Aprovação: Uma Avaliação Multilíngue e Baseada em Execução de LLMs de Código Abertos

Declaração do Problema

As avaliações atuais de Grandes Modelos de Linguagem (LLMs) para geração de código baseiam-se frequentemente em benchmarks compactos de linguagem única e taxas de aprovação agregadas (ex: pass@1). Os autores argumentam que esses resumos obscurecem dimensões críticas do desempenho dos modelos, incluindo a variabilidade entre linguagens de programação, famílias de problemas, níveis de dificuldade e modos de falha específicos. Além disso, os benchmarks padrão frequentemente falham em distinguir entre correção funcional e manutenibilidade de código (qualidade estática), e não capturam adequadamente a natureza das falhas (ex: erros sintáticos vs. semânticos). Este estudo aborda essa lacuna propondo uma avaliação de larga escala, fundamentada em execução, que preserva o pipeline completo de geração-para-execução para revelar os compromissos ocultos por tabelas de classificação de métrica única.

Metodologia

Construção do Corpus

Os autores construíram um benchmark utilizando 2.707 problemas do LeetCode gratuitos (não premium) para garantir a reprodutibilidade. O corpus abrange 12 linguagens de programação: C, C++, C#, Go, Java, JavaScript, PHP, Python, Ruby, Scala, Swift e TypeScript.

• Escala: O estudo gerou 325.343 tarefas de problema–modelo–linguagem.
• Modelos: Nove LLMs de instrução de código, acessíveis ou de pesos abertos, foram avaliados, incluindo Yi-Coder-9B-Chat, Qwen2.5-Coder-14B-Instruct, Gemma-2-27B-IT, DeepSeek-Coder-V2-Lite-Instruct, Codestral-22B-v0.1, Phi-4, Meta-Llama-3.1-8B-Instruct, Granite-3.1-8B-Instruct e Stable-Code-Instruct-3B.
• Preservação de Dados: Cada tarefa retém o prompt, a resposta bruta do modelo, o código extraído, o resultado de execução oficial do LeetCode e os sinais de análise estática.

Pipeline de Execução

1. Prompting: Prompts específicos para cada linguagem foram gerados para cada par problema–linguagem.
2. Inferência: Uma fila de tarefas baseada em servidor distribuído gerenciou a inferência entre modelos locais (hospedados no LM Studio) para lidar com a escala de mais de 300 mil tarefas. Erros operacionais (rede, timeouts) foram distinguidos de falhas do modelo e tratados via tentativas de reexecução (retries).
3. Extração de Código: O pós-processamento extraiu blocos de código das respostas do modelo (especificamente seções entre aspas triplas) para servirem como submissões candidatas.
4. Avaliação: Um script de automação em Python usando Selenium submeteu o código extraído ao juiz oficial do LeetCode. Os resultados foram recuperados via GraphQL, capturando status como Aceito (Accepted), Resposta Errada (Wrong Answer), Erro de Compilação (Compile Error), Erro de Tempo de Execução (Runtime Error), Tempo Limite Excedido (Time Limit Exceeded) e Limite de Memória Excedido (Memory Limit Exceeded).
5. Seleção de Métricas: Para cada tarefa, a "melhor" submissão foi selecionada com base na maior razão de correção, depois no status de aceitação e, por fim, no timestamp.
6. Análise Estática: O estudo realizou análise estática (linting) nos artefatos de código aceitos usando ast-grep e ferramentas do tipo Pylint para medir a qualidade do código, complexidade e adesão a convenções.

Principais Contribuições

1. Arquivo de Larga Escala: A construção de um arquivo de execução reprodutível cobrindo 2.707 problemas, 12 linguagens e 9 modelos, contendo mais de 325.000 tarefas de execução.
2. Avaliação Multidimensional: Um framework de avaliação que vai além de pontuações agregadas para analisar o desempenho através de média de correção, cobertura de problemas aceitos, fatias de dificuldade, fatias de linguagem, categorias de tópicos, resultados comparativos diretos (head-to-head) e composição de falhas.
3. Análise Conjunta Funcional e Estática: Uma análise simultânea da correção funcional e da qualidade estática, demonstrando que o sucesso de execução e os sinais orientados à manutenibilidade podem divergir significativamente.

Resultados Experimentais

Desempenho e Classificação dos Modelos

• Correção Média: O Yi-Coder-9B-Chat alcançou a maior correção média (23,64%), seguido pelo Qwen2.5-Coder-14B-Instruct e Gemma-2-27B-IT. No entanto, todos os modelos permanecem muito abaixo da linha de base de aceitação humana de 57,2%.
• Cobertura de Problemas: O Qwen2.5-Coder-14B-Instruct demonstrou a mais ampla cobertura de problemas aceitos (77,1%), indicando que pode resolver uma variedade maior de problemas distintos, mesmo que sua correção média por tarefa seja ligeiramente inferior à do Yi-Coder.
• Fatias de Dificuldade: As classificações dependem da fatia. O Yi-Coder lidera em problemas fáceis e médios, enquanto o Qwen2.5-Coder-14B-Instruct apresenta melhor desempenho em problemas difíceis.
• Fatias de Linguagem: A qualidade do modelo não é invariante à linguagem. O Yi-Coder é mais forte em alvos convencionais compilados/scripting (C++, Java, Python), o Qwen é competitivo em C#, JavaScript, Ruby, Swift e TypeScript, e o Gemma é mais forte em Go e Scala.
• Fatias de Tópico: As classificações variam por tópico. Por exemplo, o Yi-Coder é consistentemente forte em tópicos de alta frequência como arrays e strings, enquanto o Qwen lidera em categorias algorítmicas específicas.

Análise de Falhas

• Modo de Falha Dominante: Erros de compilação representam 63,25% das melhores submissões não aceitas. Isso indica que a maioria das falhas ocorre antes que a correção semântica possa ser testada.
• Mudança de Falha: Modelos mais fortes tendem a reduzir a proporção de erros de compilação, expondo relativamente mais casos de tempo de execução ou resposta errada.
• Correção Parcial: O arquivo mostra que os casos de resposta errada estão concentrados no compartimento de zero por cento de casos de teste passados, com evidência limitada de sucesso de "quase acerto" intermediário.

Qualidade Estática vs. Correção Funcional

• Divergência: A correção funcional e a limpeza estática medem propriedades diferentes. O Stable-Code-Instruct-3B alcançou o melhor escore de qualidade estrutural, apesar de ter o desempenho funcional mais fraco.
• Taxas de Passagem de Lint: O Gemma-2-27B-IT alcançou a maior taxa de passagem de lint em todas as linguagens. Por outro lado, o Qwen, apesar do forte desempenho de execução, passou menos vezes nas regras de lint.
• Tipos de Problemas: A carga de análise estática é dominada por avisos (141.376 ocorrências) e convenções (45.537 ocorrências) em vez de erros críticos. Problemas comuns de convenção incluem using-namespace-std (48% das ocorrências de convenção) e importações curinga (wildcard). Achados de refatoração foram raros (402 no total).

Significância e Alegações

O artigo alega que sua significância reside em demonstrar que a avaliação multilíngue e de preservação de artefatos revela os compromissos ocultos por tabelas de classificação de linguagem única ou métrica única.

• Não Existe um Único Melhor Modelo: O "melhor" modelo depende inteiramente do objetivo downstream. Se o objetivo é a correção média, o Yi-Coder-9B-Chat é preferível; se o objetivo é a cobertura de problemas distintos ou sucesso em tarefas difíceis, o Qwen2.5-Coder-14B-Instruct é superior; se o objetivo é minimizar o fardo de revisão via código limpo, o Gemma-2-27B-IT ou o Stable-Code-Instruct-3B podem ser preferíveis.
• Lacunas de Confiabilidade: O estudo destaca que os modelos abertos atuais estão longe da confiabilidade de nível humano, sendo os erros de compilação a principal barreira para a execução.
• Rigor de Avaliação: Os autores argumentam que a avaliação de modelos de código deve preservar a execução, a cobertura de linguagem, os modos de falha e os sinais de qualidade. Confiar em uma única pontuação colapsa dimensões de desempenho que são críticas para a implantação prática, como se um modelo produz código manutenível ou falha devido à sintaxe em vez de lógica.

O artigo conclui que avaliar LLMs de geração de código exige uma mudança de identificar um único "vencedor" para entender como e por que eles têm sucesso ou falham em diversos contextos de programação.