What's in a Benchmark? The Case of SWE-Bench in Automated Program Repair

Resumo Técnico: O que há em um Benchmark? O Caso do SWE-Bench na Reparação Automática de Programas

Declaração do Problema
O campo da Reparação Automática de Programas (APR) evoluiu rapidamente com a integração de Grandes Modelos de Linguagem (LLMs) e sistemas baseados em agentes. Embora benchmarks como o Defects4J tenham servido historicamente como bases comuns para avaliação, o SWE-Bench surgiu como um benchmark dominante projetado para refletir cenários do mundo real, minerando problemas de repositórios Python populares sem casos de teste pré-existentes para validação. Apesar de sua rápida adoção e da existência de leaderboards públicos (SWE-Bench Lite e SWE-Bench Verified), houve uma falta de análise sistemática em relação ao ecossistema que envolve esses benchmarks. Especificamente, a dinâmica de quem está enviando soluções, a natureza dos produtos e modelos empregados, e a abertura dessas abordagens permanecem subinvestigadas. Este artigo aborda a necessidade de compreender a composição do ecossistema SWE-Bench para guiar pesquisas futuras em direção a uma maior transparência e diversidade.

Metodologia
Os autores realizaram o primeiro estudo abrangente dos leaderboards SWE-Bench Lite e SWE-Bench Verified. O estudo analisou um total de 212 entradas: 79 do leaderboard Lite e 133 do leaderboard Verified.

• Coleta de Dados: Os pesquisadores inspecionaram manualmente cada entrada do leaderboard, recuperando metadados das pull requests de submissão, sites associados e arquivos de repositório (ex: README.md, metadata.yaml). Eles complementaram isso com buscas direcionadas no Google (usando o nome da entrada + "SWE-Bench") e exame de perfis do LinkedIn para identificar afiliações dos submetedores e detalhes do produto.
• Critérios de Exclusão: Os leaderboards "Full" e "Multimodal" foram excluídos porque as soluções em "Full" já estão representadas nos outros leaderboards, e o estudo focou estritamente em agentes baseados em linguagem.
• Anotação: Usando uma combinação de codificação dedutiva e indutiva, os autores categorizaram os dados em cinco dimensões correspondentes às suas Questões de Pesquisa (RQs):
  1. Evolução: Rastreamento de contagens de submissão e precisão (% Resolvido) ao longo do tempo.
  2. Perfil do Submetedor: Classificando submetedores como Academia, Indústria (posteriormente segmentada por tamanho e status público), Colaborações Academia-Indústria, Comunidade Open-Source, Desenvolvedores Individuais ou Desconhecido.
  3. Produtos & Disponibilidade: Categorizando os artefatos de software (ex: plugins de IDE, plataformas em nuvem, ferramentas de resolução de problemas) e seus modos de disponibilidade (Produto Publicamente Disponível, Sob Solicitação, B2B, Solução Não Comercial, Indisponível).
  4. Abertura: Distinguindo entre código de solução open-source e closed-source.
  5. LLMs Empregados: Identificando os LLMs específicos utilizados, incluindo combinações e se são proprietários ou open-source.

Principais Contribuições e Resultados

• RQ1 (Evolução): As submissões cresceram constantemente, com a atividade deslocando-se significativamente para o leaderboard Verified desde seu lançamento oficial em agosto de 2024. Enquanto as submissões do Lite desaceleraram em 2025, o Verified continua a crescer. O leaderboard Verified demonstra maior precisão, com uma mediana de 46,6% e um máximo de 76,8%, comparado à mediana de 32% e máximo de 60,3% do Lite. Essa diferença é atribuída à construção do Verified, que filtra instâncias consideradas muito difíceis ou insolúveis.
• RQ2 (Perfil do Submetedor): A maioria das submissões se origina da indústria (58% do total, subindo para 79% ao incluir colaborações). Pequenas empresas e grandes corporações de capital aberto (ex: Amazon, IBM, Google, EPAM) são os contribuintes mais ativos. Embora as contribuições acadêmicas continuem competitivas, elas constituem uma parcela menor do total de entradas, particularmente no Verified. Desenvolvedores individuais e comunidades de código aberto estão presentes, mas são menos dominantes no leaderboard Verified.
• RQ3 (Produtos & Disponibilidade): As entradas estão associadas a diversas formas de produtos, incluindo Assistentes de Codificação (frequentemente plugins de IDE), Plataformas de Desenvolvimento (baseadas em nuvem) e Ferramentas de Resolução de Problemas. Produtos Publicamente Disponíveis (PAP) e Soluções Não Comerciais (NCS) são os modos de disponibilidade mais comuns. Notavelmente, entradas associadas a PAPs e soluções "Sob Solicitação" tendem a alcançar maior precisão, correlacionando-se com maior envolvimento da indústria.
• RQ4 (Abertura): Existe uma divisão distinta de abertura. A academia impulsiona o ecossistema open-source; quando instituições acadêmicas estão envolvidas (sozinhas ou em colaboração), as soluções são predominantemente open-source. Em contraste, as submissões da indústria são majoritariamente closed-source. Embora soluções closed-source geralmente alcancem maior precisão mediana, várias abordagens open-source atingiram o estado da arte, particularmente em 2025.
• RQ5 (LLMs): LLMs proprietários dominam os principais resultados. A família Claude (especificamente o Claude 4 Sonnet) é o modelo mais prevalente para alcançar resultados de estado da arte em ambos os leaderboards. O principal resultado no Verified (76,8%) foi alcançado usando o Claude 4 Sonnet. Embora modelos open-source (ex: Qwen2.5, Llama) sejam usados, frequentemente em combinação com modelos fechados ou ajustados (fine-tuned), eles geralmente rendem menor precisão quando usados exclusivamente. Combinações de múltiplos LLMs são comuns entre os melhores performers.

Significância e Implicações
O artigo argumenta que o ecossistema SWE-Bench é atualmente caracterizado por uma forte presença industrial e uma dependência de LLMs proprietários de alto custo para alcançar o desempenho de topo. Os autores destacam várias implicações críticas:

• Para Pesquisadores: Há um desalinhamento entre as comunidades de Engenharia de Software (SE) e IA em relação à validação de patches. Pesquisadores de SE tipicamente distinguem entre patches corretos e de overfitting, enquanto muitas submissões focadas em IA reportam apenas resultados de passagem de testes. O artigo pede maior disseminação dos riscos de overfitting e incentiva a produção de artefatos open-source.
• Para Praticantes: As pontuações de leaderboard devem ser interpretadas com cautela devido aos riscos de overfitting de patch e contaminação de dados (memorização de dados de treinamento). O desempenho no SWE-Bench pode não se generalizar para diversos cenários do mundo real.
• Para Criadores de Benchmarks: Existe um trade-off entre transparência e participação. Embora metadados detalhados melhorem a compreensão, requisitos rigorosos podem desencorajar a participação da indústria. Os autores sugerem equilibrar requisitos de metadados leves com a necessidade de rastreabilidade. Eles também pedem mecanismos para rastrear versões de benchmarks, lidar com subconjuntos emergentes (ex: SWE-bench-Lite-S) e mitigar a contaminação de dados através de infraestrutura evolutiva como o SWE-bench-Live.
• Custo e Acessibilidade: A dependência de APIs caras baseadas em nuvem para o desempenho de alto nível cria uma barreira de entrada para pesquisadores acadêmicos e entidades menores. O artigo sugere que avaliações futuras devem considerar as relações custo-desempenho e incentivar o reporte de resultados de modelos open-source para fornecer baselines diversas.

Em conclusão, o estudo fornece uma compreensão fundamental do estado atual da pesquisa em APR conforme refletido no SWE-Bench, revelando um cenário impulsionado pela indústria e por modelos proprietários, ao mesmo tempo em que identifica áreas específicas onde a comunidade deve evoluir para garantir robustez, transparência e inclusividade em pesquisas futuras baseadas em benchmarks.