Resumo Técnico: Os Benchmarks de Otimização de Desempenho Medem Confiavelmente Agentes de Codificação?

Declaração do Problema

Benchmarks de otimização de desempenho em nível de repositório (especificamente GSO, SWE-Perf e SWE-fficiency) são cada vez mais utilizados para avaliar o progresso de agentes de codificação. Esses benchmarks exigem que os agentes gerem patches para repositórios reais que melhorem o desempenho de execução enquanto preservam a correção, sendo avaliados contra patches de referência oficiais e regras de pontuação específicas.

No entanto, a confiabilidade dessas avaliações é questionável devido a três fatores de confusão potenciais:

1. Instabilidade de Execução: Medições de desempenho são propriedades não funcionais sujeitas a ruídos de escalonamento de CPU, estados de cache e efeitos microarquitetônicos. Um patch que é mais rápido em uma máquina pode não ser em outra.
2. Sensibilidade das Regras de Pontuação: Os rankings de liderança comprimem centenas de resultados de tarefas em uma única pontuação. As regras de agregação específicas (ex: portões binários vs. médias harmônicas com penalidades) podem ponderar desproporcionalmente tarefas específicas, potencialmente distorcendo a capacidade percebida de um agente.
3. Saturação de Solubilidade de Tarefas: Não está claro se os benchmarks atuais ainda expõem lacunas genuínas de desempenho ou se as tarefas "não resolvidas" são meros artefatos de limitações de agentes únicos, dado que fluxos de trabalho multi-agente já poderiam cobrir essas lacunas.

Os autores auditam esses três benchmarks para determinar se seus resultados de avaliação podem ser confiados como evidência do progresso dos agentes.

Metodologia

O estudo emprega uma auditoria sistemática através de três dimensões, correspondentes a três Questões de Pesquisa (RQs):

RQ1: Validade do Patch de Referência entre Máquinas

• Configuração: Os autores reproduziram 740 patches de referência oficiais em quatro perfis distintos de máquinas Google Cloud (Intel Cascade Lake, AMD Milan, Intel Emerald Rapids, AMD Turin) com configurações de recursos idênticas (64 vCPUs, 256GB RAM).
• Processo: A carga de trabalho oficial e as regras de validade de cada benchmark foram preservadas. Os autores realizaram três rodadas de reprodução em cada máquina.
• Métricas:
  • Avaliabilidade: A tarefa consegue completar e retornar uma pontuação?
  • Mais Rápido que a Base (Faster-than-Base): O patch de referência supera o código base não otimizado em todas as rodadas de reprodução na máquina?
  • Válido pela Regra Original: A reprodução satisfaz as regras originais de construção do benchmark (ex: limiares específicos de aceleração ou significância estatística)?

RQ2: Sensibilidade da Regra de Pontuação

• Configuração: Os autores analisaram oito submissões públicas compartilhadas entre GSO e SWE-fficiency.
• Processo: Eles re-pontuaram as mesmas saídas por tarefa usando as regras de agregação do benchmark oposto para isolar o efeito do mecanismo de pontuação.
• Análise:
  • Eles compararam rankings oficiais contra rankings re-pontuados.
  • Para o SWE-fficiency, eles analisaram o "alavancagem" (leverage) de tarefas individuais na regra de pontuação de média harmônica, calculando especificamente o peso da pontuação carregado pelas tarefas com pior desempenho.
  • Eles introduziram um "diagnóstico de penalidade limitada" (elevando o piso de 0.001 para 0.5) para testar o quão sensíveis os rankings são a penalidades extremas.

RQ3: Cobertura de Tarefas entre Submissões

• Configuração: Os autores examinaram 10 submissões públicas para cada uma das 450 tarefas de reprodução válida (39 do GSO, 411 do SWE-fficiency). O SWE-Perf foi excluído devido à falta de dados comparáveis de saída de agentes públicos e baixa validade de reprodução.
• Processo: Para cada tarefa, eles verificaram se pelo menos uma das 10 submissões atingiu três marcos: passar nos testes, superar o código base e igualar/superar o patch de referência.
• Análise Profunda: Para as 66 tarefas onde nenhuma submissão única alcançou a velocidade de referência, eles analisaram o "melhor" patch público para determinar se a lacuna era devida a falhas de correção, profundidade insuficiente de aceleração ou incompatibilidades de estratégia (usando uma taxonomia automatizada de categorias de otimização).

Principais Resultados

1. Instabilidade do Patch de Referência (RQ1)

• Avaliabilidade: A maioria das tarefas é executável (apenas 6 falhas totais em 740 tarefas).
• Validade: Uma parte significativa dos patches de referência falha em manter a validade entre as máquinas.
  • GSO: Apenas 39/102 tarefas satisfizeram as regras de validade originais em todas as reproduções entre máquinas.
  • SWE-Perf: Apenas 11/140 tarefas permaneceram válidas. Este benchmark é particularmente frágil porque muitos patches de referência produzem mudanças de tempo de execução próximas de zero (mediana de -0.03%), tornando-os suscetíveis ao ruído.
  • SWE-fficiency: 411/498 tarefas permaneceram válidas.
• Conclusão: Os sinais de referência não são estáveis entre máquinas; muitos pacotes "oficiais" perdem seu sinal de desempenho quando reproduzidos em hardware diferente.

2. Dominância da Regra de Pontuação (RQ2)

• Desacordo de Ranking: Os rankings oficiais para as oito submissões compartilhadas discordaram em 9 de 28 comparações pareadas.
• Sensibilidade do SWE-fficiency: A regra de pontuação de média harmônica com um piso de 0.001 cria uma sensibilidade extrema. As 10 piores tarefas carregam de 58,5% a 82,8% do peso total da pontuação de uma submissão. Uma única tarefa de aceleração próxima de zero pode dominar o ranking.
• Impacto das Penalidades: Aplicar um diagnóstico de penalidade limitada (piso = 0.5) alterou 6 de 8 rankings de submissão e inverteu 8 de 28 ordens pareadas, demonstrando que os rankings refletem o design da penalidade tanto quanto a capacidade do agente.

3. Cobertura de Tarefas e Lacunas Remanescentes (RQ3)

• Alta Cobertura: Entre as 450 tarefas de reprodução válida, pelo menos uma submissão pública igualou ou superou o patch de referência em 384 tarefas (85,3%).
• Melhoria da Base: 449/450 tarefas tiveram um patch público que superou o código base não otimizado.
• Natureza das Lacunas Remanescentes: Nas 66 tarefas onde nenhuma submissão única alcançou a velocidade de referência, raramente se tratava de falhas básicas de correção.
  • 65/66 possuíam patches públicos mais rápidos que a base.
  • A mediana do melhor patch público alcançou 85,3% (GSO) e 87,9% (SWE-fficiency) da aceleração de referência.
  • Incompatibilidade de estratégia (usar uma categoria de otimização diferente da referência) não foi a causa primária da falha; muitos patches da "mesma categoria" ainda falharam em alcançar a velocidade de referência, sugerindo que a lacuna reside na profundidade da implementação, e não na seleção da estratégia.

Significância e Alegações

O artigo afirma que os scores de liderança sozinhos são insuficientes para interpretar o progresso dos agentes de otimização de desempenho. Os autores argumentam que:

1. Sinal vs. Ruído: Os benchmarks atuais frequentemente confundem instabilidade de tempo de execução com desempenho do agente. Os usuários devem distinguir entre tarefas com sinais de referência estáveis e aquelas onde o sinal é perdido para o ruído da máquina.
2. O Design da Métrica Importa: Os rankings são fortemente influenciados pelas regras de pontuação. Especificamente, o design atual do SWE-fficiency permite que algumas falhas severas ditem todo o ranking, mascarando tendências amplas de desempenho.
3. O Problema da "Última Milha": Para muitas tarefas, o status de "não resolvido" em rankings de agentes únicos é um artefato da configuração de avaliação, e não uma incapacidade fundamental de otimização. A lacuna restante é frequentemente sobre refinar uma otimização funcional conhecida para atingir a velocidade de referência, em vez de encontrar uma nova estratégia.

Os autores concluem que os futuros benchmarks devem ir além de simples patching sob cargas de trabalho fixas. Eles devem testar o fluxo de trabalho completo de engenharia de desempenho: identificar gargalos a partir de perfis, escolher alvos de otimização e validar melhorias contra múltiplas métricas de recursos (latência, memória, etc.), em vez de depender apenas de scores agregados de liderança que podem ser instáveis ou excessivamente sensíveis a artefatos de pontuação.