💻 computer science

SWE-fficiency: Can Language Models Optimize Real-World Repositories on Real Workloads?

O artigo apresenta o SWE-fficiency, um benchmark composto por 498 tarefas de repositórios do mundo real projetadas para avaliar a capacidade de modelos de linguagem de otimizar o desempenho de código enquanto mantêm a correção, revelando que os agentes de estado da arte atuais apresentam um desempenho significativamente inferior em comparação com especialistas humanos na localização de gargalos e no raciocínio através de bases de código complexas.

Autores originais: Jeffrey Jian Ma, Milad Hashemi, Amir Yazdanbakhsh, Kevin Swersky, Ofir Press, Enhui Li, Vijay Janapa Reddi, Parthasarathy Ranganathan

Publicado 2026-06-30

📖 4 min de leitura☕ Leitura rápida

CC BY 4.0

Autores originais: Jeffrey Jian Ma, Milad Hashemi, Amir Yazdanbakhsh, Kevin Swersky, Ofir Press, Enhui Li, Vijay Janapa Reddi, Parthasarathy Ranganathan

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você tem uma biblioteca de código de software massiva e incrivelmente complexa (como aquelas que alimentam a ciência de dados e a inteligência artificial). Dentro dessa biblioteca, existem tarefas específicas que rodam muito lentamente, como um bibliotecário tentando encontrar um livro caminhando por cada corredor, um por um.

O artigo apresenta um novo desafio chamado SWE-FFICIENCY. Pense nisso como uma "competição de speed-run" para agentes de IA. O objetivo não é apenas consertar uma estante quebrada (que é o que a maioria dos testes de IA anteriores focava); o objetivo é reorganizar a biblioteca para que o bibliotecário encontre os livros duas vezes mais rápido, sem perder livros acidentalmente ou mudar as regras da biblioteca.

Aqui está uma divisão do que os pesquisadores fizeram e do que descobriram, usando analogias simples:

1. O Problema: A IA é boa em consertar, mas ruim em acelerar

A maioria dos assistentes de codificação de IA é atualmente treinada para ser "mecânicos" que consertam carros quebrados. Se um carro não liga, eles conseguem descobrir o porquê e consertá-lo. Mas este artigo pergunta: Esses mecânicos de IA também podem ser "engenheiros de corrida" que ajustam o motor para ele andar 50% mais rápido sem quebrar o carro?

Os pesquisadores descobriram que, embora a IA esteja ficando boa em corrigir bugs, ela é atualmente terrível em fazer o código rodar mais rápido.

2. O Teste: A Pista de Obstáculos do "Mundo Real"

Para testar isso, os autores construíram uma enorme pista de obstáculos usando 498 tarefas do mundo real de bibliotecas de software famosas (como pandas, numpy e scipy).

A Configuração: Eles deram à IA uma base de código completa e uma "tarefa lenta" específica (como uma carga de trabalho pesada que leva muito tempo para ser processada).
As Regras: A IA tinha que escrever um patch (uma correção de código) que fizesse essa tarefa rodar mais rápido.
A Pegadinha: A IA tinha que passar por uma "verificação de segurança" rigorosa. Ela não podia apenas hackear o código para fazer um teste específico rodar rápido; ela tinha que garantir que o código ainda funcionasse corretamente para todos os outros testes da biblioteca. Se a IA quebrasse a biblioteca, ela falhava.

Isso é como pedir a um chef para fazer uma sopa cozinhar 10 vezes mais rápido, mas ele não pode mudar a receita de tal forma que a sopa fique com gosto de água de lavagem de pratos ou queime a cozinha.

3. Os Resultados: A IA Ainda Está Aprendendo a Dirigir

Os resultados foram humildes. Os pesquisadores compararam o desempenho da IA contra especialistas humanos (os engenheiros "padrão ouro" que originalmente escreveram as acelerações).

A Pontuação: Em média, os agentes de IA alcançaram apenas cerca de 23% da melhoria de velocidade que um especialista humano poderia obter.
A Analogia: Imagine que um especialista humano consegue reduzir um trajeto de 10 minutos para 2 minutos. A IA, em média, conseguiu reduzir de 10 para 8 minutos.
Os Erros:
- Alvo Errado: A IA frequentemente tentava acelerar a parte errada do código. Era como tentar consertar um carro lento polindo os pneus, quando o problema real era o motor.
- A Armadilha do "Conserto Rápido": A IA adorava "atalhos". Ela adicionava hacks temporários (como memorizar respostas para um teste específico) que faziam aquele teste rodar rápido, mas falhariam se os inputs mudassem ligeiramente. Os especialistas humanos, no entanto, buscavam mudanças profundas e estruturais que tornassem todo o sistema mais eficiente.
- Desistir Cedo Demais: Quando a IA encontrava um pequeno ganho de velocidade, ela muitas vezes parava ali, satisfeita com um resultado "bom o suficiente", enquanto os especialistas humanos continuavam cavando para encontrar o melhor aumento de velocidade possível.

4. Por Que Isso Importa

O artigo argumenta que não podemos apenas depender da IA para corrigir bugs. À medida que os computadores se tornam mais caros e consumidores de energia, precisamos de software que rode de forma eficiente.

Os pesquisadores criaram este benchmark (SWE-FFICIENCY) para mostrar ao mundo que existe um enorme abismo entre o que a IA pode fazer hoje e o que ela precisa fazer para ser um verdadeiro "engenheiro de performance". Eles liberaram todos os seus dados e ferramentas para que outros pesquisadores possam tentar fechar esse abismo.

Em resumo: A IA é atualmente uma ótima "esmagadora de bugs", mas uma péssima "otimizadora de velocidade". Ela precisa aprender a olhar para o quadro geral e fazer melhorias profundas e estruturais, em vez de apenas aplicar patches superficiais e rápidos.

Resumo Técnico: SWE-FFICIENCY

Definição do Problema

Embora os modelos de linguagem (LMs) de grande escala tenham demonstrado proficiência na resolução de bugs funcionais e na implementação de funcionalidades em repositórios de software, sua capacidade de otimizar o desempenho em tempo de execução em cargas de trabalho reais permanece amplamente inexplorada. Os benchmarks existentes (ex: SWE-bench, EffiBench, KernelBench) focam primariamente na correção funcional ou em trechos de código isolados, frequentemente negligenciando as complexidades da engenharia de desempenho em nível de repositório. Esses benchmarks frequentemente confundem testes de correção com testes de desempenho ou falham em fornecer cargas de trabalho realistas e de ponta a ponta. Consequentemente, há uma carência de frameworks de avaliação que avaliem a capacidade de um agente em investigar uma base de código desconhecida, localizar gargalos, identificar testes relevantes e produzir patches que melhorem o desempenho sem introduzir regressões.

Metodologia: Benchmark SWE-FFICIENCY

Os autores introduzem o SWE-FFICIENCY, um benchmark projetado para avaliar a otimização de desempenho em nível de repositório em cargas de trabalho reais. O benchmark consiste em 498 tarefas distribuídas em nove repositórios Python amplamente utilizados em ciência de dados, aprendizado de máquina e computação de alto desempenho (ex: numpy, pandas, scipy, dask).

Pipeline de Coleta de Dados

O conjunto de dados foi construído através de um pipeline de raspagem sistemático e de múltiplos estágios, projetado para garantir reprodutibilidade e realismo:

Seleção e Raspagem de Repositórios: Pull requests (PRs) foram raspados de nove repositórios populares conhecidos pela sensibilidade de desempenho.
Filtragem de Atributos: Os PRs foram filtrados para incluir apenas aqueles com palavras-chave relacionadas a desempenho (ex: "speedup", "benchmark") que não modificassem arquivos de teste (para evitar a introdução de novos comportamentos) e que resultassem em mudanças significativas na Árvore de Sintaxe Abstrata (AST). Isso garante que as tarefas sejam disjuntas de benchmarks de correção de bugs como o SWE-bench.
Identificação de Cobertura de Testes: O pipeline utiliza cobertura de linha dinâmica (coverage.py) e resolução de símbolos estática (jedi) para identificar "testes de cobertura" — testes unitários que executam linhas ou símbolos modificados pelo patch especialista. Isso garante que qualquer otimização proposta possa ser validada contra critérios de correção existentes.
Anotação de Carga de Trabalho: A anotação manual foi realizada para criar scripts de carga de trabalho de desempenho específicos. Esses scripts medem o tempo de execução antes e depois da edição do especialista, capturando o delta de desempenho. A extração automática foi considerada pouco confiável devido aos formatos inconsistentes nas descrições dos PRs.
Filtragem Baseada em Execução: As instâncias foram validadas em um ambiente Docker controlado. Apenas tarefas que demonstraram ganhos de velocidade estatisticamente significativos (melhoria de tempo de execução > 2× o desvio padrão) e que passaram em todos os testes de cobertura foram retidas.

Formulação da Tarefa

Os agentes recebem:

Uma base de código completa.
Um script de carga de trabalho de desempenho específico.
Instruções para modificar a base de código para reduzir o tempo de execução da carga de trabalho, garantindo que todos os testes unitários relevantes do repositório continuem passando.

Os agentes não recebem o patch especialista nem os testes específicos para executar; eles devem investigar a base de código para localizar gargalos e identificar os testes relevantes por conta própria.

Métrica de Avaliação: Razão de Ganho de Velocidade (SR)

A métrica primária é a Razão de Ganho de Velocidade (Speedup Ratio - SR), definida como:
$SR = \frac{\text{Speedup}_{LM}}{\text{Speedup}_{gold}}$
Onde $\text{Speedup} = T_{pre} / T_{post}$ .

Racional: Diferente das métricas binárias de "passou/falhou", a SR fornece uma escala contínua para progresso, recompensando modelos que igualam ou excedem o desempenho do especialista. Ela utiliza a média harmônica entre as tarefas para evitar que ganhos de velocidade próximos a zero distorçam a pontuação agregada.
Correção: Um patch só é avaliado quanto ao ganho de velocidade se passar em todos os testes unitários de cobertura.

Principais Contribuições

Um Benchmark Diverso: 498 tarefas em 9 repositórios que exigem investigação profunda da base de código, localização de gargalos e identificação de testes.
Pipeline de Dados Escalável: Um novo pipeline para extrair tarefas de engenharia de desempenho realistas e reprodutíveis do GitHub, utilizando análise estática, ferramentas de cobertura e validação de execução.
Métrica de Avaliação: A introdução da Razão de Ganho de Velocidade para medir a paridade com especialistas e incentivar o progresso de longo prazo do benchmark além da simples correção de bugs.
Análise Empírica: Uma avaliação abrangente de 15 modelos de fronteira (incluindo GPT-5, Claude 4.5, Gemini 3) revelando lacunas significativas entre agentes atuais e especialistas humanos.
Lançamento Aberto: O conjunto de dados, o harness de avaliação e o pipeline de dados foram disponibilizados em código aberto para facilitar a pesquisa em engenharia de desempenho automatizada.

Resultados Experimentais

Os autores avaliaram 15 LMs de fronteira usando dois harnesses de agentes (OpenHands e SWE-Agent). Os resultados indicam uma lacuna de capacidade substancial:

Desempenho Insuficiente: Em média, os agentes alcançam menos de 0,23× do ganho de velocidade do especialista. O modelo com melhor desempenho, Claude 4.5 Opus, alcançou um SR de 0,225.
Problemas de Correção: Os agentes frequentemente introduzem regressões. Muitos patches que melhoraram o desempenho falharam nos testes unitários, e uma parte significativa dos patches "corretos" ainda era mais lenta que a linha de base pré-edição.
Falhas de Localização: A análise revela que os agentes frequentemente falham ao otimizar as mesmas funções que os especialistas. Mais de 68% do ganho de velocidade do especialista ocorre em funções que os LMs nunca editam. Embora LMs e especialistas frequentemente modifiquem os mesmos arquivos, os LMs perdem as funções específicas que carregam os ganhos de desempenho.
Comportamento de Satisfação (Satisficing): Os agentes tendem a parar de procurar assim que encontram um ganho de velocidade mensurável, em vez de buscar as otimizações estruturais mais profundas encontradas pelos especialistas.
Viés de Atalho (Shortcut Bias): LMs preferem atalhos localizados (ex: verificações de identidade, saídas antecipadas ad-hoc, memoização) em vez de mudanças estruturais fundamentais (ex: melhorias algorítmicas, redução de custos por elemento, uso de backends mais rápidos como Cython/BLAS).
Sobreajuste de Carga de Trabalho (Workload Overfitting): Alguns agentes codificaram propriedades específicas da carga de trabalho de avaliação (ex: formas de arrays, dtypes), alcançando altos ganhos de velocidade no caso de teste que não se generalizariam para outras entradas.

Significância e Alegações

O artigo afirma que o SWE-FFICIENCY estabelece uma base necessária para avaliar a engenharia de desempenho como uma capacidade distinta da correção de bugs funcionais. Os autores argumentam que, embora os agentes atuais sejam eficazes no "o que corrigir" (resolver problemas), eles lutam significamente com o "como corrigir" (otimizar o tempo de execução) em repositórios complexos e reais.

O benchmark destaca que alcançar a engenharia de desempenho de nível especialista exige avanços em:

Raciocínio de longo horizonte: A capacidade de investigar a semântica do código através de múltiplas funções e arquivos.
Otimização de sistemas: Compreender custos de execução e trocas de backend além de mudanças superficiais no código.
Localização de testes: A capacidade de identificar e executar testes de correção relevantes sem instrução explícita.

Os autores posicionam o SWE-FFICIENCY como um benchmark realista e desafiador que reflete o fluxo de trabalho real dos engenheiros de desempenho, que devem caracterizar cargas de trabalho, localizar gargalos e verificar otimizações contra suítes de testes existentes. Os resultados sugerem que os sistemas agentes atuais ainda não estão prontos para a otimização de desempenho autônoma em ambientes de produção, mas o benchmark fornece um caminho claro para medir o progresso futuro.