Resumo Técnico: Maior Nem Sempre é Melhor: Uma Avaliação Comparativa de LLMs para Revisão de Código Automatizada

Declaração do Problema

A revisão de código automatizada usando Grandes Modelos de Linguagem (LLMs) tornou-se integrante das cadeias de ferramentas de desenvolvimento de software moderno (ex: CodeRabbit, GitHub Copilot). Uma decisão de engenharia crítica nesses sistemas é a seleção do modelo: determinar qual LLM fornece as revisões de maior qualidade com custo e latência aceitáveis. O senso comum sugere que modelos maiores e mais caros devem superar os menores em tarefas de raciocínio complexas como a revisão de código, que exige compreensão de fluxo de controle, dependências de dados e convenções de domínio. Este artigo testa empiricamente essa suposição e, simultaneamente, critica a metodologia de avaliação predominante, que depende fortemente de benchmarks sintéticos que podem não refletir o desempenho no mundo real.

Metodologia

Estrutura de Avaliação

Os autores propõem uma estrutura de avaliação de dois passos reutilizável para enfrentar o desafio de combinar os achados de modelos (em formato livre) com as anotações de verdade fundamental (ground-truth):

1. Passo 1 (Correspondência Determinística): Os achados do modelo são comparados com a verdade fundamental usando três critérios: caminho de arquivo normalizado, sobreposição de intervalo de linhas (±5 linhas) e compatibilidade de tipo de comentário. Este passo lida com aproximadamente de 70% dos casos (verdadeiros positivos, falsos positivos e falsos negativos claros) com custo zero de LLM.
2. Passo 2 (Adjudicação por LLM): Casos ambíguos são adjudicados pelo Claude Opus 4.6 (temperatura 0.0) usando uma rubrica estruturada. O juiz classifica os achados como TRUE_POSITIVE, FALSE_POSITIVE ou PARTIAL_MATCH e pontua quatro dimensões qualitativas: Profundidade, Consciência de Contexto, Especificidade e Correção da Sugestão.

Modelos e Conjunto de Dados

• Modelos Avaliados: Cinco modelos de três provedores com uma variação de custo de 15×:
  • Anthropic: Claude Sonnet 4.6 (grande), Claude Haiku 4.5 (pequeno).
  • OpenAI: GPT-5.4 mini.
  • Minimax: Minimax M2.7.
  • Zhipu AI: GLM-5 Turbo.
• Conjunto de Dados (150 Amostras):
  • Sintético (n=100): 13 operadores de mutação injetando bugs conhecidos (ex: injeção de SQL, erros de "off-by-one") em 8 templates de código (TypeScript, Python, Go). Estes são pequenos (mediana de 5 linhas).
  • Real (n=50): Pull Requests (PRs) de correção de bugs mesclados de oito repositórios importantes (ex: vercel/next.js, facebook/react). Estes são substancialmente maiores (mediana de 117 linhas) e contêm mudanças de múltiplos arquivos e ruído de formatação.

Condições Experimentais

Três experimentos foram conduzidos para testar escalabilidade e generalização:

1. Calibração (n=25): Apenas sintético.
2. Linha de Base Estável (n=100): Apenas sintético.
3. Generalização (n=150): 100 sintéticos + 50 PRs reais.

Principais Resultados

1. Modelos Menores Superam Modelos Maiores

Contrariando a suposição de que "maior é melhor", o Claude Haiku 4.5 superou consistentemente o maior Claude Sonnet 4.6 em todas as condições experimentais.

• Desempenho: O Haiku alcançou um F1 score superior (0.365 vs. 0.343) e um recall significativamente maior (0.293 vs. 0.248, um aumento de 18%) no conjunto de dados completo.
• Pontuações Qualitativas: O Haiku pontuou mais alto em todas as quatro dimensões qualitativas (Profundidade, Contexto, Especificidade, Sugestões).
• Eficiência de Custo: O Haiku operou com um custo 3.2× menor por revisão do que o Sonnet.
• Validação Externa: Estes resultados foram replicados no benchmark independente Martian Code Review, onde o Haiku ficou acima do Sonnet (F1 36.4% vs. 27.1%).

2. O Abismo Sintético-para-Real

O artigo identifica uma degradação severa no desempenho dos modelos ao passar de dados sintéticos para dados do mundo real.

• Magnitude: Em amostras sintéticas isoladas, o melhor modelo (Haiku) alcançou um F1 de 0.847. Em PRs reais isolados, este caiu para 0.066 (uma degradação de 92%).
• Causa: A degradação é impulsionada pelo tamanho do diff, ruído de formatação e interações entre múltiplos arquivos, ausentes nos dados sintéticos.
• Preditor de Tamanho de Diff: O tamanho do diff é o preditor dominante de desempenho. O F1 cai de ~0.66–0.80 em diffs pequenos (<10 linhas) para ~0.04–0.07 em diffs grandes (>150 linhas).

3. Análise de Categoria e Linguagem

• Categorias de Bugs: Bugs de segurança são bem detectados (~70% de recall). Bugs de lógica mostram divergência (Haiku 24.5% vs. Sonnet 19.6%). Bugs de performance (ex: consultas N+1) são amplamente indetectáveis, com quatro de cinco modelos alcançando 0% de recall.
• Linguagens: Revisões de Go renderam os melhores resultados (F1 do Haiku 0.485), provavelmente devido ao tratamento de erro explícito e tipagem forte do Go, em comparação com TypeScript (0.272) e Python (0.209).

4. Estratégias de Ensemble

Combinar modelos (tomando a união dos achados do Haiku e outro modelo) diminuiu os F1 scores globais. Os modelos detectam majoritariamente os mesmos bugs; adicionar um segundo modelo introduz falsos positivos sem aumentar significativamente os verdadeiros positivos.

Significância e Alegações

O artigo alega três contribuições primárias para o campo da revisão de código automatizada:

1. Desafiando o Paradigma de Escala: Fornece evidência empírica de que, para revisão de código, um modelo menor e mais barato (Haiku 4.5) pode superar um modelo maior e mais caro (Sonnet 4.6) tanto em qualidade quanto em eficiência de custo. Isso sugere que a revisão de código pode não se beneficiar de escala adicional de modelo além de um certo limiar de capacidade.
2. Expondo a Armadilha de Avaliação: O estudo demonstra que benchmarks sintéticos superestimam perigosamente a capacidade dos modelos (em até 12×). Argumenta-se que avaliações baseadas apenas em dados sintéticos são enganosas e que PRs do mundo real devem ser incluídos para avaliar a generalização.
3. Identificando Gargalos Sistêmicos: O artigo identifica o tamanho do diff como o principal gargalo para os atuais LLMs em revisão de código. Sugere-se que o pré-processamento de grandes PRs em blocos menores é a intervenção mais eficaz para melhorar a qualidade da revisão no mundo real, observando também que bugs relacionados à performance permanecem fora do alcance dos atuais LLMs, exigando análise estática.

Os autores concluem que, para sistemas de produção, modelos menores como o Haiku 4.5 são a escolha primária recomendada, suplementados por regras determinísticas para questões de performance e pré-processamento de diff para mitigar o gargalo de tamanho.