Porque é que o SWE-bench Verified deixou de medir as capacidades de programação de ponta

Desde que publicámos pela primeira vez o SWE-bench Verified, em agosto de 2024, a indústria tem utilizado amplamente este benchmark para medir o progresso dos modelos em tarefas de engenharia de software autónoma. Após o seu lançamento, o SWE-bench Verified forneceu um sinal forte de progresso nas capacidades e tornou-se uma métrica padrão reportada nos lançamentos de modelos de ponta. Acompanhar e prever o progresso destas capacidades é também uma parte importante do trabalho do Preparedness Framework da OpenAI. Quando criámos inicialmente o benchmark Verified, procurámos resolver problemas na avaliação original que tornavam certas tarefas impossíveis de realizar no conjunto de dados SWE-bench⁠(abre numa nova janela).

Após os avanços iniciais, o progresso de ponta no SWE-bench Verified abrandou, melhorando⁠(abre numa nova janela) de 74,9% para 80,9% nos últimos 6 meses. Isto levanta a questão: as falhas restantes refletem limitações do modelo ou características do próprio conjunto de dados?

Numa nova análise, identificámos dois problemas principais no conjunto Verified que indicam que o benchmark já não é adequado para medir o progresso nas capacidades autónomas de engenharia de software em lançamentos de modelos de ponta, aos níveis de desempenho atuais:

1. Os testes rejeitam soluções corretas: auditámos 27,6% do conjunto de dados que os modelos frequentemente não conseguiam resolver e verificámos que, pelo menos, 59,4% dos problemas auditados apresentam casos de teste defeituosos que rejeitam submissões funcionalmente corretas, apesar dos nossos esforços em melhorar isto durante a criação inicial do SWE-bench Verified.
2. Treino com soluções: como os grandes modelos de ponta podem aprender informações durante o treino, é importante que nunca sejam treinados com problemas e soluções sobre os quais vão ser avaliados. Isto é semelhante a partilhar problemas e soluções de um teste futuro com os alunos antes do teste — eles podem não memorizar a resposta, mas os alunos que já viram as respostas certamente terão um desempenho melhor do que aqueles que não as viram. Os problemas do SWE-bench são provenientes de repositórios open-source que muitos fornecedores de modelos utilizam para fins de treino. Na nossa análise, verificámos que todos os modelos de ponta que testámos conseguiram reproduzir a correção de bug original escrita por humanos, utilizada como referência de verdade fundamental (gold patch), ou detalhes literais do enunciado do problema para certas tarefas, indicando que todos eles tiveram contacto, pelo menos com alguns dos problemas e soluções durante o treino.

Verificámos igualmente que os modelos expostos aos problemas durante o treino apresentam maior taxa de sucesso, por beneficiarem de informação adicional indispensável para satisfazer testes com especificação insuficiente.

Isto significa que as melhorias no SWE-bench Verified já não refletem melhorias significativas nas capacidades reais dos modelos em desenvolvimento de software. Em vez disso, refletem cada vez mais o grau de exposição do modelo ao benchmark durante o treino. É por isso que deixámos de reportar resultados no SWE-bench Verified e recomendamos que outros programadores de modelos façam o mesmo.

Estamos a desenvolver novas avaliações, livres de contaminação, para acompanhar de forma mais fiável as capacidades de programação, e acreditamos que este é um domínio importante em que a comunidade de investigação em geral deve concentrar-se. Enquanto não as tivermos, a OpenAI recomenda divulgar os resultados do SWE-bench Pro.

A avaliação original SWE-bench⁠(abre numa nova janela) foi lançada em 2023. Cada problema provém de um issue resolvido no GitHub, em um dos 12 repositórios open-source de Python, e está associado ao pull request (PR) correspondente. Para determinar se uma alteração de código gerada por um modelo está correta, cada problema inclui dois conjuntos de testes:

• Testes que falham na base de código não modificada, mas passam se o problema for corrigido corretamente
• Testes de regressão que passam tanto antes como depois da correção, para garantir que funcionalidades não relacionadas se mantêm intactas.

O modelo não vê os testes. Tem de produzir uma alteração de código com base apenas no texto do problema original e no estado do repositório antes da correção. Um problema é considerado resolvido apenas se, depois de aplicada a modificação de código, todos os testes forem bem-sucedidos.

Identificámos vários problemas nessa avaliação que podem levar a uma subestimação das capacidades dos modelos.

• Alguns testes unitários eram demasiado específicos ou estavam desalinhados com a tarefa, pelo que correções corretas poderiam ser rejeitadas.
• Muitas descrições de tarefas estavam insuficientemente especificadas, o que podia levar a múltiplas interpretações válidas — enquanto os testes apenas cobriam uma interpretação específica.
• Dependendo da configuração do ambiente (por exemplo, Linux vs Windows, ou a versão do python), alguns testes podiam apresentar falhas indevidas

Criámos o SWE-bench Verified em 2024 para resolver estes problemas. Trabalhámos com engenheiros de software especialistas para rever 1.699 problemas do SWE-bench e filtrar aqueles que apresentavam estes problemas. Cada problema foi revisto por três especialistas de forma independente. Este processo de revisão resultou no SWE-bench Verified, um conjunto selecionado de 500 problemas.

Embora o SWE-bench Verified seja uma grande melhoria em relação à versão inicial, ainda persistem problemas residuais. Realizámos uma auditoria a 138 problemas do SWE-bench Verified que a OpenAI o3 não conseguiu resolver de forma consistente em 64 execuções independentes. Cada caso foi revisto de forma independente por, pelo menos, seis engenheiros de software experientes. Se um especialista sinalizou um problema, este foi verificado novamente por uma equipa adicional.

Verificámos que 59,4% dos 138 problemas continham problemas significativos no desenho dos testes e/ou na descrição das tarefas, tornando-os extremamente difíceis ou mesmo impossíveis de resolver, mesmo para o modelo ou humano mais capaz. 

• 35,5% das tarefas auditadas possuem casos de teste rigorosos que impõem detalhes específicos de implementação, invalidando muitas submissões funcionalmente corretas, aos quais chamamos casos de teste restritivos.
• 18,8% das tarefas auditadas possuem testes que verificam funcionalidades adicionais que não estavam especificadas na descrição do problema, aos quais chamamos casos de teste abrangentes.
• Os restantes 5,1% das tarefas apresentavam problemas diversos que não se enquadravam bem nesta taxonomia.

Um exemplo ilustrativo do primeiro modo de falha é pylint-dev__pylint-4551⁠(abre numa nova janela), em que o PR introduz uma nova função `get_annotation` como parte da solução global. Este nome de função não é mencionado na descrição do problema, mas é importado diretamente pelos testes. Embora alguns modelos possam intuir a necessidade de criar tal função, não é estritamente necessário implementar uma função com este nome específico para resolver corretamente o problema. Muitas soluções válidas falham nos testes devido a erros de importação.

Um exemplo de casos de teste demasiado abrangentes é sympy__sympy-18199⁠(abre numa nova janela). Esta tarefa teve origem num PR que abordou três problemas distintos com a função `nthroot_mod`, especificamente #17373⁠(abre numa nova janela), #17377⁠(abre numa nova janela) e #18212⁠(abre numa nova janela). A descrição da tarefa SWE-bench Verified, no entanto, abrange apenas o problema final #18212⁠(abre numa nova janela). Isto cria uma discrepância: os testes do PR abrangem os três problemas, enquanto a descrição detalha apenas um. Nas nossas execuções, os modelos frequentemente implementam corretamente a correção descrita e depois falham nos testes que abrangem a implementação das outras duas questões.

O SWE-bench Verified e os repositórios (bases de código e notas de lançamento) são ambos open-source e amplamente utilizados e discutidos, o que torna difícil evitar a contaminação para os desenvolvedores de modelos.

Encontrámos pela primeira vez sinais de contaminação nos nossos próprios modelos. Por exemplo, quando o GPT‑5.2 resolveu 31 tarefas que identificámos como quase impossíveis de resolver. Em django__django-14725⁠(abre numa nova janela) os testes exigem um novo parâmetro específico `edit_only` que não é explicitamente exigido pelo enunciado do problema. Ao resolver o problema, o GPT‑5.2 demonstra na sua cadeia de raciocínio que possui informações sobre as notas de versão que detalham alterações na base de código, e identifica corretamente que o parâmetro `edit_only` foi introduzido no Django 4.1.

Para avaliar quão significativa é a contaminação de forma mais ampla, criámos uma configuração automatizada de red-teaming. Para cada questão do SWE-bench Verified, incumbimos o GPT‑5 de sondar um GPT‑5.2‑Chat, Claude Opus 4.5 e Gemini 3 Flash Preview para contaminação. Estes modelos foram escolhidos para excluir modelos de raciocínio, mas reconhecemos que provavelmente existe uma diferença de capacidades significativa entre eles.

Para investigar a contaminação, o GPT‑5 recebeu: o ID da tarefa do SWE-bench Verified, a descrição, a correção de referência (gold patch) e os testes do PR. Ao longo de 15 interações, permitimos que o GPT‑5 variasse o system/developer prompt, o user prompt, o preenchimento inicial do assistente (assistant prefill) e diferentes estratégias de elicitação. Após cada turno, um modelo juiz avaliou a quantidade de informação nova e específica da tarefa que apareceu, e cada resposta foi classificada quanto à gravidade da contaminação, de “nenhuma” a “forte”. O GPT‑5 teve permissão para adaptar a sua estratégia com base em vezes anteriores para recuperar iterativamente detalhes específicos da tarefa. Para cada exemplo de contaminação forte, verificámos com outro juiz que o GPT‑5 não divulgou demasiada informação ao modelo de destino. Por fim, revimos manualmente os exemplos “fortes” que constituem as transcrições desta publicação.

Abaixo estão exemplos de forte contaminação entre diferentes fornecedores de modelos.

Dado um pequeno excerto da descrição da tarefa, o GPT‑5.2 gera a correção de referência exata. Em particular, ele sabe o nome exato da classe e do método, e a nova condição de retorno antecipado `se o nome de utilizador é Nenhum ou a palavra-passe é Nenhum` que é introduzida.

ID da tarefa: django__django-11451⁠(abre numa nova janela)

O Opus consegue não só recordar a alteração funcional de 4 linhas que o PR introduziu, juntamente com o ficheiro e o método específicos que foram afetados, como também cita literalmente o comentário inline que fazia parte do diff. 

ID da tarefa: astropy__astropy-13236⁠(abre numa nova janela)

O Gemini 3 Flash, quando não recebe qualquer informação adicional sobre a tarefa além do ID, consegue reproduzir literalmente detalhes da descrição da tarefa e da correção de referência. Isto inclui a nova expressão regular para validação de nomes de utilizador e os números exatos das linhas da alteração.

ID da tarefa: django__django-11099⁠(abre numa nova janela)

A partir desta auditoria ao SWE-bench Verified, retiramos duas lições mais amplas sobre o desenho de avaliações. Em primeiro lugar, os benchmarks obtidos a partir de material publicamente disponível apresentam risco de contaminação, uma vez que a exposição aos dados de treino pode inflacionar os resultados de forma silenciosa. Se forem utilizados dados recolhidos publicamente na construção do benchmark, os desenvolvedores de modelos devem realizar testes adicionais para deteção de contaminação. Os benchmarks, e até as suas soluções, quando publicados publicamente, podem acabar por integrar os dados de treino. Deve ser prestada especial atenção tanto à forma como os conjuntos de dados são publicados (por exemplo, protegidos por palavra-passe) como à filtragem dos dados de treino (i.e. cumprimento rigoroso de canary strings). 

Em segundo lugar, a pontuação automática é difícil de acertar; os testes ideais devem verificar totalmente a funcionalidade correta, sendo ao mesmo tempo independentes de detalhes de implementação irrelevantes e resistentes a soluções de atalho. Estes problemas são inerentemente complexos e difíceis de resolver. Identificar estes problemas exigiu várias campanhas extensas de anotação humana. 

Incorporámos estas conclusões nos nossos esforços de avaliação mais recentes. Nos últimos meses, optámos por reportar os resultados da divisão pública do SWE-Bench Pro. Recomendamos que outros programadores de modelos façam o mesmo. O SWE-bench Pro não é perfeito, mas empiricamente parece apresentar menos problemas de contaminação. O nosso sistema de deteção de contaminação identificou alguns casos, mas estes eram significativamente mais raros e menos graves do que no SWE-bench Verified, e nenhum modelo conseguiu produzir uma correção de referência completa e literal.

Continuaremos a investir em benchmarks originais, de autoria privada, e a pedir ajuda à indústria e à academia para fazerem o mesmo. No GDPVal⁠, as tarefas são elaboradas de forma privada por especialistas da área, reduzindo o risco de exposição, e as soluções são avaliadas de forma holística por revisores treinados. Esta abordagem exige muitos recursos, mas é cada vez mais necessária para medir as verdadeiras melhorias de capacidade.