Resumo Técnico: Além da Taxa de Resolução: Um Estudo de Qualidade Não Funcional

Declaração do Problema

Benchmarks de codificação em nível de repositório, como o SWE-bench, avaliam primariamente as capacidades de Grandes Modelos de Linguagem (LLMs) medindo a "taxa de resolução" — a porcentagem de problemas para os quais um modelo gera um patch que passa nas suítes de testes fornecidas. Embora esta métrica meça efetivamente a correção funcional, ela negligencia a qualidade não funcional do código gerado. Um patch pode corrigir com sucesso um bug, mas introduzir novos code smells, vulnerabilidades de segurança, problemas de manutenibilidade ou regressões de desempenho.

Avaliações existentes frequentemente assumem que novas gerações de modelos, que tipicamente alcançam taxas de resolução mais altas, também produzem código de maior qualidade. No entanto, há uma falta de evidência empírica sobre se as melhorias na correção funcional são acompanhadas por melhorias correspondentes em atributos não funcionais (segurança, manutenibilidade, confiabilidade e desempenho) em tarefas que tanto modelos antigos quanto novos conseguem resolver. Este estudo aborda essa lacuna investigando se modelos mais recentes produzem patches funcionalmente corretos com melhores características não funcionais do que modelos anteriores de mesmas famílias de provedores.

Metodologia

Design Experimental

O estudo conduziu dois estudos de caso comparando um modelo anterior e um posterior de duas famílias distintas: Claude (Sonnet 4 vs. Opus 4.6) e DeepSeek (R1 vs. V3.2). Os experimentos utilizaram o SWE-bench Lite, um benchmark consistindo de 300 pares de problemas e pull requests reais de repositórios Python (Django e SymPy).

• Framework de Agente: Todos os modelos foram avaliados usando o framework SWE-agent com o template de prompt padrão do SWE-bench Lite, que foca na reparação de bugs funcionais sem instruções explícitas para melhorar qualidades não funcionais.
• Restrições de Custo: Um limite de custo por instância de $0,50 foi aplicado para garantir a viabilidade, permitindo ao mesmo tempo um orçamento suficiente para a conclusão das tarefas.
• Validação Funcional: Os patches foram primeiro validados usando o harness de avaliação oficial do SWE-bench em um ambiente Docker. Apenas os patches que aplicaram e resolveram o problema com sucesso foram retidos para análise não funcional.

Métricas de Avaliação de Qualidade

O estudo empregou uma abordagem multifacetada para avaliar a qualidade não funcional:

1. Análise Estática:

   • CodeQL: Utilizado a suíte oficial de consultas de segurança e qualidade de Python para detectar problemas relacionados a segurança, confiabilidade e manutenibilidade. A análise comparou os achados antes e depois da aplicação do patch para calcular a mudança líquida (achados adicionados menos achados removidos).
   • CodeScene: Utilizado o comando cs delta para medir mudanças em "Saúde do Código" (Code Health), uma métrica para manutenibilidade baseada em complexidade estrutural e evolução do código.
   • Escopo: O CodeQL utilizou análise em todo o repositório, enquanto o CodeScene utilizou análise incremental.

2. Medições de Tempo de Execução e Recursos:

   • Tempo de CPU: Medido como a soma do tempo de usuário e sistema via estatísticas do cgroup v2 durante a execução dos testes.
   • Pico de Memória: Medido como o ponto máximo (high-water mark) das estatísticas de memória do cgroup v2.
   • Cada patch foi executado cinco vezes para calcular os valores médios, com mecanismos de fallback (tempo de relógio de parede e memória do Docker API) caso os dados do cgroup estivessem indisponíveis.

Análise de Dados

A análise primária focou em instâncias comumente resolvidas — tarefas resolvidas tanto pelo modelo anterior quanto pelo posterior dentro de uma família (71 instâncias para Claude, 56 para DeepSeek). Esta abordagem controlou as diferenças de composição das tarefas. As comparações estatísticas utilizaram testes de randomização de postos pareados de duas caudas, correlações de rank-biserial pareadas e intervalos de confiança bootstrap de 95%. A correção de Holm foi aplicada para considerar múltiplas comparações.

Principais Resultados

Resultados Funcionais

Modelos posteriores alcançaram taxas de resolução mais altas:

• Claude: Opus 4.6 (44,33%) vs. Sonnet 4 (36,00%).
• DeepSeek: V3.2 (44,33%) vs. R1 (26,33%).

Qualidade Estática (CodeQL e CodeScene)

• Sem Melhoria Significativa: Em instâncias comumente resolvidas, a diferença mediana pareada para ambos os achados do CodeQL e para o Code Health do CodeScene foi zero para ambas as famílias de modelos.
• Significância Estatística: Após a correção de Holm, nenhuma comparação permaneceu estatisticamente significativa. A maioria das diferenças pareadas foi zero (66/71 para Claude CodeQL, 52/56 para DeepSeek CodeQL).
• Regressão vs. Melhoria: A maioria dos patches foi classificada como "neutra" (72–94%). Regressões foram mais comuns do que melhorias. Notavelmente, o padrão de regressões diferiu entre as ferramentas: o CodeScene reportou taxas de regressão mais altas (15,8–26,3%) do que o CodeQL (5,3–14,8%) para patches de LLM, enquanto a linha de base de ouro mostrou o oposto.

Tempo de Execução e Memória

• Tempo de CPU: As diferenças foram pequenas e inconsistentes. Para o Claude, o Opus 4.6 usou um pouco mais de tempo de CPU (mediana +0,048s), o que foi significativo. Para o DeepSeek, a diferença não foi significativa.
• Pico de Memória: Modelos posteriores mostraram um aumento leve, mas estatisticamente significativo, no uso de pico de memória em tarefas comumente resolvidas.
  • Claude: O Opus 4.6 usou 4,524 MiB a mais que o Sonnet 4.
  • DeepSeek: O V3.2 usou 0,512 MiB a mais que o R1.
  • Todos os Quatro Modelos: Nas 30 instâncias resolvidas por todos os modelos, os dois modelos posteriores usaram, em média, 2,876 MiB a mais de memória.

Características do Patch

• Tamanho do Patch: Os padrões variaram por família. O modelo Claude posterior (Opus 4.6) produziu patches menores (menos linhas e arquivos alterados) do que o modelo anterior. Inversamente, o modelo DeepSeek posterior (V3.2) produziu patches maiores.
• Prevalência de Regras: Regras específicas do CodeQL e categorias do CodeScene variaram em prevalência entre os modelos, mas nenhuma dessas diferenças sobreviveu à correção de Holm.

Significância e Alegações

O artigo alega que taxas de resolução mais altas não necessariamente correspondem a melhores características não funcionais. O estudo demonstra que, embora modelos mais novos resolvam mais problemas, eles não produzem consistentemente patches com qualidade estática superior ou menor consumo de recursos nas tarefas que ambos resolvem.

As principais contribuições e conclusões incluem:

1. Desacoplamento de Métricas: Taxa de resolução, achados de análise estática, uso de recursos e características de patch capturam diferentes aspectos do desempenho do modelo e devem ser reportados separadamente em avaliações de nível de repositório.
2. Complementaridade de Ferramentas: CodeQL e CodeScene fornecem visões complementares, mas distintas, da qualidade do patch; confiar em uma única ferramenta pode resultar em avaliações incompletas ou conflitantes.
3. Contexto de Melhoria: O estudo destaca que prompts funcionais focados apenas na correção de bugs não impulsionam inerentemente melhorias nas qualidades não funcionais.
4. Alegações Modestas: Os autores declaram explicitamente que seus achados se aplicam ao cenário de reparação específico, configuração de agente e carga de trabalho de benchmark utilizados. Eles não alegam representar o potencial total dos modelos para melhorar a qualidade não funcional se forem explicitamente instruídos ou refinados iterativamente. O estudo serve como um chamado para um framework de avaliação mais abrangente que vá além da "taxa de resolução" para avaliar as capacidades práticas de engenharia de software de LLMs.