SWE-Bench Verified: o que um resultado realmente mede e por que ele não basta para escolher um agente de código

Que pergunta o SWE-Bench Verified responde — e qual ele não responde

O SWE-Bench é uma avaliação baseada em issues históricas do GitHub e nas alterações corretivas associadas a elas. Seu subconjunto Verified contém 500 instâncias revisadas por pessoas para melhorar a confiabilidade da avaliação. Em termos práticos, ele formula uma pergunta delimitada: dado o contexto fornecido para uma issue de um repositório específico, um sistema consegue propor um patch que passe nos testes definidos para essa tarefa em um ambiente reproduzido?

A resposta é valiosa porque relaciona a geração de código a um resultado executável, e não apenas a uma preferência humana ou a uma correspondência textual com uma solução esperada. Um agente precisa navegar por uma base de código, interpretar uma descrição, editar arquivos e gerar uma modificação compatível com os testes do ambiente. Ainda assim, a métrica resume esse processo em uma proporção de tarefas que cumprem um critério binário de resolução.

Ela não responde, por si só, se um agente consegue operar com autonomia responsável em um repositório real. Não estabelece que ele saiba priorizar uma fila de issues, pedir esclarecimentos sobre requisitos ambíguos, decidir que não deve alterar código, revisar uma contribuição de terceiros, gerenciar segredos, coordenar uma implantação, responder a um alerta operacional nem assumir a responsabilidade por uma regressão. Essas atividades dependem de pessoas, políticas, sistemas e contextos que não são plenamente representados por uma instância fechada.

Por isso, uma pontuação deve ser lida como evidência sobre uma capacidade avaliada em um protocolo determinado, e não como uma classificação geral de ferramentas de engenharia. Nas seções Benchmarks, Comparar e Descobrir, pode ser razoável usá-la como um sinal entre vários, desde que suas condições de obtenção sejam preservadas e um número isolado não seja transformado em promessa de resultados operacionais.

Anatomia de uma tarefa: de uma issue histórica a um patch avaliado

A construção original do SWE-Bench parte de problemas resolvidos no GitHub em 12 repositórios Python de código aberto e os relaciona ao pull request correspondente. Uma instância reúne, ao menos conceitualmente, a issue, o estado histórico do repositório sobre o qual o trabalho será realizado e a alteração de referência do projeto. O benchmark converte esse material histórico em uma tarefa que um sistema pode tentar resolver por meio de uma edição de código.

Convém distinguir a alteração de referência da condição de vitória. O objetivo não é necessariamente reproduzir literalmente o patch humano original, caractere por caractere. Um patch alternativo pode ser aceitável se, ao ser aplicado ao ambiente da instância, satisfizer os testes de correção previstos e não quebrar os testes de preservação. Essa distinção importa porque evita tratar o benchmark como um exercício de recuperação exata de uma resposta.

O Verified adiciona uma camada de filtragem humana às instâncias do SWE-Bench. A documentação do projeto descreve o conjunto como um subconjunto de 500 instâncias validadas por pessoas. A seleção procura remover casos cuja avaliação não seja suficientemente confiável; ainda assim, o subconjunto não transforma cada problema em uma representação exaustiva da engenharia de software nem elimina toda possível ambiguidade de interpretação.

Uma execução reproduzível exige mais do que o texto da issue. Ela deve especificar a revisão dos dados, o identificador de cada instância, a imagem ou definição do ambiente, a versão do harness, o patch produzido e os limites de execução. A distribuição de dados consultada é servida a partir de uma ramificação que pode mudar; portanto, citar apenas o nome da ramificação não fixa o mesmo conjunto para repetições futuras. É preciso fixar uma revisão completa e registrar a data de consulta.

Como uma resolução é definida e por que o percentual final esconde decisões metodológicas

Segundo a descrição da avaliação, o agente não vê os testes. O harness avalia o patch por meio de dois grupos: os testes FAIL_TO_PASS e os testes PASS_TO_PASS. Os primeiros representam o comportamento que a alteração deve corrigir; os segundos servem para verificar que a edição não tenha quebrado involuntariamente partes não relacionadas da base de código. Para que uma edição conte como resolução completa, ambos os grupos precisam ser aprovados.

Essa definição é mais exigente do que verificar se o código compila ou se apenas um novo teste passa. Ela também permite comparar patches funcionalmente distintos sem impor igualdade com a alteração histórica. Porém, um percentual final ainda esconde decisões: quantas instâncias entraram no denominador, o que ocorreu com erros de infraestrutura, quanto tempo cada tarefa recebeu, quantas amostras foram geradas e qual foi a política para escolher uma delas.

O harness oficial documenta parâmetros para selecionar o conjunto e as instâncias, definir um tempo limite e separar execuções. Ele também aplica patches, executa testes e calcula resultados. Consequentemente, informar apenas uma taxa de resolução sem publicar o comando ou uma configuração equivalente torna difícil verificar se dois números usaram as mesmas tarefas, os mesmos limites e o mesmo mecanismo de avaliação.

Deve-se evitar uma conclusão inversa igualmente simplista: a de que uma métrica binária não tem utilidade porque não cobre todo o ciclo de desenvolvimento. A métrica pode, sim, fornecer evidência concreta sobre a correção de issues em condições definidas. A questão é delimitar seu alcance e exigir rastreabilidade suficiente para que outra pessoa possa inspecionar as condições da afirmação.

Os sete campos mínimos para comparar dois resultados publicados

Uma tabela responsável não precisa incluir todos os detalhes internos de um sistema, mas deve permitir distinguir uma execução de outra. O primeiro campo é a identidade exata do conjunto: nome, variante, revisão fixada e lista de instâncias ou regra de seleção. “SWE-Bench Verified” não basta se o resultado foi produzido em uma amostra, uma cópia modificada ou uma versão diferente dos dados.

O segundo campo é o modelo: fornecedor, nome, versão ou data identificável, quando houver, e parâmetros de inferência que afetem o resultado. O terceiro é a estrutura do agente: framework, versão e estratégia de planejamento ou edição. Um mesmo modelo pode obter resultados diferentes se mudarem o ciclo de ferramentas, o formato do contexto, o tratamento de erros ou o critério de parada.

O quarto campo descreve as ferramentas habilitadas: terminal, busca local, edição de arquivos, execução de testes, acesso à rede e qualquer recuperação externa. O quinto declara o orçamento: limite de etapas, chamadas ao modelo, tokens quando disponíveis, tempo por instância e recursos de computação. O sexto indica o protocolo: número de amostras, temperatura ou outra configuração de geração, repetições e regra de seleção. O sétimo fornece os artefatos que permitam verificar o resultado: configuração, logs suficientes, patches ou previsões e a saída do harness, quando puderem ser compartilhados.

A página do projeto distingue um leaderboard geral, que reúne sistemas heterogêneos, de uma comparação de modelos com uma configuração comum baseada em mini-SWE-agent. Essa separação é um alerta metodológico: uma classificação de sistemas completos não isola o efeito do modelo, enquanto uma configuração comum pode ajudar nessa comparação específica. Além disso, o próprio projeto adverte que as versões 1.x e 2.x do mini-SWE-agent não são necessariamente comparáveis.

Nem todos esses dados estarão disponíveis em uma nota de lançamento. Nesse caso, o resultado não é automaticamente refutado, mas deve ser rotulado como incompletamente especificado. A resposta rigorosa não é preencher as lacunas com suposições sobre o fornecedor nem ordenar números heterogêneos como se pertencessem a um experimento controlado.

O que pode inflar ou limitar uma pontuação

A seleção de tarefas é o primeiro fator. Um subconjunto escolhido por dificuldade, disponibilidade de ambiente ou sucessos anteriores não precisa preservar a mesma distribuição do conjunto completo. Também importa saber se instâncias que excedem o tempo, falham ao construir a imagem ou apresentam problemas de infraestrutura são excluídas. Um relatório deve separar, na medida do possível, uma falha do agente de uma falha do ambiente e explicar como ambas afetam o resultado agregado.

As repetições e as múltiplas amostras merecem atenção específica. Testar vários patches por issue pode ser uma decisão técnica legítima, especialmente se refletir o uso pretendido do sistema, mas muda a unidade prática da avaliação: deixa de ser medido o sucesso de uma única tentativa. Devem ser informados o número máximo de tentativas, a existência de reinicializações do agente e se execuções que falham são iniciadas novamente.

A informação acessível ao sistema altera a natureza da tarefa. Testes ocultos reduzem uma via direta de adaptação à resposta esperada, mas não eliminam outras diferenças: o agente pode dispor de busca, ferramentas de execução, documentação local ou acesso externo, conforme o protocolo. Uma comparação válida exige saber quais recursos foram habilitados e se eram iguais para todos os sistemas comparados.

Há também uma incerteza temporal. A OpenAI apresentou sua posição de que o SWE-Bench Verified deixou de medir capacidades de programação de fronteira e apontou o risco de contaminação decorrente da disponibilidade pública dos problemas e das soluções históricas. Essa é uma avaliação e recomendação da OpenAI, não uma medição independente que permita quantificar a contaminação de cada modelo. Ainda assim, ela exige prudência ao interpretar uma melhoria recente como progresso geral sem examinar a potencial exposição aos dados.

A análise da Epoch AI propõe outra limitação: o benchmark se concentra em repositórios conhecidos e em correções relativamente delimitadas. Essa é uma interpretação secundária, não uma propriedade que deva ser apresentada como fato definitivo sobre cada instância. Ela serve, contudo, para formular uma pergunta útil: a carteira de manutenção da organização se parece materialmente com essas tarefas históricas de repositórios Python? Se a resposta for não, a transferência esperada do sinal será limitada e incerta.

Por que uma issue resolvida não demonstra manutenção autônoma

Em um repositório real, resolver uma issue começa antes de escrever um patch. É preciso fazer triagem, reproduzir o problema, estimar o impacto, identificar dependências, negociar requisitos e decidir prioridades. Uma tarefa de benchmark fornece uma formulação histórica e um critério de teste preparado; nas operações normais, essas entradas podem estar ausentes, ser contraditórias ou mudar durante a investigação.

Depois do patch, também intervêm atividades que uma taxa de resolução não cobre suficientemente: revisão por pares, análise de segurança, licenças, compatibilidade retroativa, migrações, desempenho, observabilidade, aprovação de mudanças e implantação. Os testes de preservação do benchmark são uma proteção importante dentro da instância, mas não equivalem a todas as validações de uma organização nem aos efeitos de integrar uma mudança com branches, serviços e usuários atuais.

A responsabilidade operacional é outro limite. Um agente pode gerar uma modificação que passa nos testes do harness e ainda assim exigir supervisão humana para decidir se ela deve ser incorporada, quando deve ser implantada e como deve ser revertida. Portanto, a compra, adoção ou concessão de permissão de escrita a uma ferramenta não deve depender apenas de um percentual do SWE-Bench Verified. Ela deve incorporar controles de acesso, revisão, rastreabilidade, isolamento e testes específicos do ambiente próprio.

Isso não implica que o benchmark seja irrelevante para responsáveis por engenharia. Ele pode ajudar a selecionar hipóteses para um teste posterior: por exemplo, se um sistema demonstra capacidade de editar e validar patches em tarefas históricas, ele pode merecer uma avaliação controlada em issues internas de baixo risco. A transição correta vai de evidência de benchmark a experimento local, não de benchmark a autonomia em produção.

Como transferir o sinal para um teste breve no repositório próprio

Não é necessário reproduzir todo o SWE-Bench para obter informação mais próxima da realidade local. Um teste breve pode usar um pequeno conjunto de issues já encerradas ou de mudanças preparadas expressamente, desde que os responsáveis definam antecipadamente os critérios de inclusão, o acesso permitido e o método de avaliação. A finalidade não é fabricar uma nova tabela pública, mas reduzir a incerteza de uma decisão técnica concreta.

O desenho deve separar as tarefas de desenvolvimento das tarefas de avaliação. A pessoa ou equipe que prepara os casos pode manter testes de aceitação não visíveis para o agente, quando isso for viável e apropriado. Cada caso deve incluir um ambiente isolado, um estado de repositório fixado e limites explícitos de tempo, custo e ferramentas. Não se deve dar ao sistema acesso a credenciais de produção nem permitir mudanças fora do ambiente controlado.

Meça mais de uma dimensão. Além de verificar se os testes passam, registre o tempo até o patch, o número de intervenções humanas, a qualidade da explicação, o cumprimento das convenções do repositório, os achados da revisão e os incidentes de segurança ou de processo. Uma amostra pequena não permite inferências amplas; ela pode, porém, revelar incompatibilidades evidentes, custos inesperados ou classes de tarefas nas quais o sistema exige supervisão excessiva.

A comparação mais útil mantém o protocolo constante. Se dois sistemas forem testados, procure garantir que recebam os mesmos casos, a mesma janela de tempo, o mesmo acesso a ferramentas e os mesmos limites. Se o agente for modificado ou for permitido a um deles um orçamento maior, informe essa mudança como parte do resultado, em vez de atribuir toda diferença ao modelo.

Ficha final: o que pode ser afirmado com rigor

Uma afirmação sólida assume uma forma limitada: “Na revisão declarada do SWE-Bench Verified, com este modelo, esta versão de agente, estas ferramentas, este orçamento e este protocolo, a execução obteve esta taxa de instâncias que passaram no critério do harness”. Se os artefatos estiverem disponíveis, pode-se acrescentar que o resultado é auditável ou reproduzível nas condições publicadas. Se estiverem ausentes, é correto dizer que a afirmação não pode ser completamente verificada com a informação disponível.

Não é rigoroso transformar essa afirmação em “o modelo resolve essa porcentagem de bugs reais”, “é o melhor agente de código” ou “consegue manter um repositório sem supervisão”. Essas conclusões ampliam população, contexto e responsabilidades sem evidência equivalente. Mesmo uma execução impecável no benchmark responde apenas às tarefas e ao protocolo que foram efetivamente avaliados.

A documentação primária oferece bases claras para essa leitura: o Verified é um subconjunto humano de 500 instâncias; a resolução exige superar testes de correção e de preservação; e a configuração do harness é parte material da execução. Ao mesmo tempo, persistem incertezas: a disponibilidade pública das tarefas pode afetar a validade temporal para certos modelos, as configurações de agentes mudam e uma tarefa histórica não reproduz todos os mecanismos sociais e operacionais da manutenção.

A decisão prática consiste em preservar ambas as ideias. O SWE-Bench Verified pode ser um sinal técnico útil e mais concreto do que uma demonstração anedótica. Ele não é garantia de autonomia, segurança, produtividade líquida nem adequação a um repositório próprio. Quem publicar, comparar ou comprar com base nesses resultados deve tornar visíveis as condições que transformam um número em evidência e as incertezas que impedem transformá-lo em promessa.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.