- A avaliação da capacidade de programação de modelos de IA está diretamente ligada a decisões de implantação e segurança, mas uma auditoria da OpenAI estimou que cerca de 30% das tarefas do SWE-Bench Pro estavam quebradas
- O SWE-Bench Pro buscava um escopo de tarefas mais longo e desafios mais realistas, mas ficou difícil confiar no resultado de que, em 731 tarefas públicas, a taxa de aprovação subiu de 23,3% para 80,3% em 8 meses
- Os defeitos se dividem em testes excessivamente rígidos, prompts subespecificados, testes de baixa cobertura e prompts enganosos, o que pode fazer submissões corretas falharem ou correções incompletas passarem
- A auditoria sinalizou 286 tarefas potencialmente problemáticas com base em tentativas dos modelos, metadados das tarefas e rastreamento de falhas, antes de submetê-las à revisão independente de um agente investigador e de 5 engenheiros experientes
- A OpenAI retirou a recomendação de adotar o SWE-Bench Pro, e benchmarks de avaliação precisam fornecer sinais significativos que não distorçam julgamentos sobre capacidade e segurança dos modelos
Problemas revelados na auditoria do SWE-Bench Pro
- A OpenAI auditou o SWE-Bench Pro e estimou que cerca de 30% de todas as tarefas estavam quebradas
- Medir com precisão a capacidade dos modelos também afeta decisões de implantação e segurança segundo o Preparedness Framework
- Avaliações defeituosas podem levar a uma compreensão errada da capacidade real dos modelos e abalar avaliações de segurança e prioridades de pesquisa
Objetivo do SWE-Bench Pro e mudança na taxa de aprovação
- A OpenAI já havia identificado problemas de projeto e contaminação no amplamente usado SWE-bench Verified e concluiu que essa avaliação já não fornecia sinais significativos sobre capacidade de desenvolvimento de software
- Na época, a OpenAI recomendou à comunidade migrar para o SWE-Bench Pro
- O SWE-Bench Pro foi projetado para melhorar o SWE-bench Verified, acompanhando capacidade de codificação com agentes em tarefas mais longas e desafios de programação mais realistas
- As tarefas são extraídas programaticamente do histórico de mudanças de funcionalidades em repositórios públicos e privados
- O modelo precisa implementar uma solução que passe nos novos testes de funcionalidade sem quebrar funcionalidades existentes
- Na divisão pública de 731 tarefas, a taxa de aprovação de modelos de fronteira subiu de 23,3% para 80,3% ao longo de 8 meses
Pipeline de garantia de qualidade
- A OpenAI criou um pipeline de garantia de qualidade para verificar se cada ponto de dado realmente refletia a capacidade dos modelos
- Um filtro automático inicial analisa as instruções dadas ao modelo, suas tentativas de solução e os testes de avaliação, marcando exemplos quebrados ou suspeitos de problema
- Nesse processo, 286 tarefas potencialmente problemáticas foram sinalizadas
- O subconjunto sinalizado passou então por uma revisão mais profunda em dois caminhos
- Revisão de agente supervisionada por humanos: um agente investigador faz verificações detalhadas e passa por julgamento humano final
- Campanha de anotação humana: desenvolvedores de software experientes revisam diretamente as tarefas
Como funcionaram a revisão por agente e a revisão humana
- Os problemas sinalizados foram auditados por um agente investigador baseado em Codex
- O agente tinha acesso ao repositório da tarefa e ao ambiente de execução
- Podia executar testes, inspecionar arquivos do repositório e investigar tentativas dos modelos e modos comuns de falha
- Isso foi usado para distinguir ambiguidades razoáveis, solucionáveis pelo código ao redor e pelas convenções do repositório, de casos reais de subespecificação
- Após várias auditorias independentes e profundas, pesquisadores revisaram os resumos e atribuíram o julgamento final e os rótulos do problema
- Em paralelo, na campanha de anotação humana, engenheiros de software experientes revisaram as tarefas após receber treinamento sobre os objetivos do benchmark, classificação de problemas e casos limítrofes
- Cada tarefa foi revisada por 5 engenheiros
- Os revisores primeiro faziam um julgamento independente com base na descrição visível do problema, nos casos de teste e no gold patch, a solução de referência correta
- Depois, usavam a análise do pipeline ou os registros como contexto auxiliar
- Com base em evidências concretas, atribuíam rótulos e gravidade, e casos com discordância ou baixa confiança eram encaminhados para revisão adicional
Quatro tipos de falha
- Os problemas identificados na auditoria se dividem principalmente em quatro categorias
- Testes excessivamente rígidos: invalidam submissões funcionalmente corretas ao exigir detalhes específicos de implementação que não aparecem no prompt
- Prompts subespecificados: omitem requisitos exigidos pelos testes ocultos, mas difíceis de inferir de forma razoável
- Testes de baixa cobertura: não verificam suficientemente a funcionalidade solicitada, permitindo que correções incompletas também passem
- Prompts enganosos: induzem o modelo a um comportamento incorreto ou entram em contradição com os requisitos dos testes
- Em algumas tarefas, o prompt exigia uma implementação específica, mas os casos de teste ocultos esperavam outro comportamento
Diferenças entre revisão humana e revisão por agente
- Revisores humanos tinham maior probabilidade de marcar uma tarefa como quebrada do que o agente investigador
- Houve diferenças de classificação entre os dois caminhos de revisão, mas entre as tarefas sinalizadas não houve nenhum caso em que o rótulo mais frequente nas marcações humanas fosse “não quebrada”
- A categoria sinalizada pelo pipeline do agente e o julgamento dos revisores humanos coincidiram em 74% dos casos
- Revisores humanos também selecionavam com mais frequência vários rótulos para uma mesma tarefa
- Isso indica que algumas tarefas estavam quebradas de várias maneiras ou não se encaixavam de forma limpa em uma única categoria
- Um pipeline que combina agente e revisores capturou os modos amplos de falha encontrados por humanos, mas contou problemas adicionais ou sobrepostos de forma conservadora
- A maior diferença apareceu em testes de baixa cobertura
- Humanos apontaram isso como o problema mais comum em 9,4% do benchmark
- O pipeline do agente marcou 4,1%
Por que é difícil construir benchmarks
- Os casos do SWE-Bench Pro e do SWE-bench Verified mostram que benchmarks precisam ser validados com rigor
- Issues e pull requests em repositórios open source não são criados originalmente para avaliação de modelos, e sim para colaboração humana
- Em ambientes com muita discussão de ida e volta entre mantenedores e contribuidores, descrições de problemas, código mesclado e testes unitários nem sempre formam tarefas limpas e independentes para avaliação de modelos
- Testes incluídos em pull requests podem ser escritos para validar uma mudança específica e, por isso, impor uma implementação específica em vez de um critério de solução independente da forma de implementação
Direção futura das avaliações
- À medida que a capacidade dos modelos melhora, os defeitos das avaliações também ficam mais fáceis de encontrar do que antes
- Modelos aprimorados conseguem inspecionar prompts, testes, patches, rastros de execução e casos limítrofes com mais profundidade e consistência, revelando problemas de benchmark que antes eram difíceis ou caros de encontrar em larga escala
- A OpenAI espera que a comunidade mais ampla de avaliação desenvolva novos benchmarks criados por desenvolvedores de software experientes especificamente para testar a capacidade dos modelos
- Essa abordagem pode manter o alto grau de dificuldade e realismo que se pretende medir, ao mesmo tempo em que permite melhor supervisão humana ao longo de todo o processo
- A OpenAI retirou sua recomendação anterior de adoção do SWE-Bench Pro devido aos problemas revelados nesta análise
- As avaliações devem ser difíceis de manipular, fáceis de confiar e fornecer sinais significativos que reflitam de fato a capacidade ou o estado de alinhamento dos modelos
1 comentários
Comentários do Hacker News
É preciso medir eficiência e inteligência ao mesmo tempo. Modelos pequenos podem usar estratégias como testar resultados com uso do computador ou insistir mais tempo em um problema e verificar a saída, enquanto modelos grandes podem ter pouco orçamento para autoteste, então parece que surgiriam diferenças táticas interessantes
https://artificialanalysis.ai/?cost=intelligence-vs-cost-per...
Toby Ord fez o que pôde com dados públicos, mas o resultado não parece muito bom
https://www.tobyord.com/writing/hourly-costs-for-ai-agents
Além disso, há trapaça no nível do harness de execução, reward hacking do modelo etc. O que continua me incomodando meses depois é a submissão oficial do gpt-5.5, especialmente esta tarefa: https://www.tbench.ai/leaderboard/terminal-bench/2.0/codex/0...
Pelo https://github.com/harbor-framework/terminal-bench-2/blob/ma..., o limite de tempo da tarefa é de 1200 segundos para o verifier, 1200 segundos para o agent e 600 segundos para a build do ambiente, então nenhum agente deveria passar de 3000 segundos. Mas, no link acima, 2 das 5 tentativas passaram bastante de 3000 segundos, levando 75 e 80 minutos, respectivamente. Mesmo que tenham falhado, é suspeito terem rodado por tanto tempo. É um caso de lei de Goodhart em ação
Benchmark de humanos também não funciona muito bem. Capacidade de programação só dá para medir direito até certo ponto por interação direta. Se o modelo é basicamente um simulador de pessoas, então parece até estranho esperar que benchmarks continuem úteis à medida que a simulação fica mais precisa. No fim, isso é só uma versão mais longa da tal “lei de Goodhart”, e ela realmente funciona como uma lei
Então a lógica é que o modelo de ponta não é nem um engenheiro júnior, mas um estagiário de primeiro mês sem capacidade de ir além desse nível?
O interessante é como os LLMs conseguem passar de 70% em benchmarks assim, ou acertar algumas perguntas mal formuladas. Será que aprenderam implicitamente o estilo do autor dos testes? Será que as respostas vazaram para os dados de treino?
Ainda assim, é reconfortante que até o Fable pare em cerca de 72% em um conjunto oculto no qual a OpenAI não rodou essa análise. Parece improvável que tenha aprendido diretamente o benchmark, exceto talvez de forma muito indireta
Modelos abertos pequenos jamais conseguiriam aprender essas manias estranhas, então é realmente importante ter uma boa forma de avaliar modelos com justiça. Além disso, a OpenAI está confundindo um pouco as águas: só cerca de 20% dos problemas estão quebrados de um jeito injusto para o agente, e de 4% a 10% estão quebrados em direção favorável, então o teto do benchmark provavelmente fica mais perto de 80–85%
Por isso, prompts de tarefa muito estreitos são fáceis de verificar, mas provavelmente simples demais para servirem como desafio. Em contrapartida, prompts de tarefa mais realistas são muito mais difíceis de verificar, e também fica difícil construir verificadores robustos e executá-los de forma barata
Claro, nesse caso o benchmark está testando algo diferente do que diz testar, mas às vezes acaba testando por acidente algo mais próximo da realidade do que um benchmark limpinho, então isso tem seu valor
Só que isso depende de o agente poder ver os testes que falharam e iterar. Se não puder, então é só um problema. E é ainda pior quando colocam nos testes detalhes de implementação de uma solução específica, exigindo alguma estrutura interna arbitrária. Na vida real, você não encontra esse tipo de situação
Por um lado, é louvável que eles tenham realmente feito esse trabalho. Por outro, é literalmente aquilo de garbage in, garbage out. É meio constrangedor que os autores originais não tenham verificado isso de fato, e também é constrangedor que ninguém a jusante tenha verificado. E, pelo texto, parece que o LLM até encontrou os problemas, mas tendia a subestimar os problemas identificados por um engenheiro de software especializado
Os benchmarks, quando você olha por dentro, em geral são bem ruins
Para dar contexto: estou iterando continuamente um agente supervisor para substituir vários procedimentos incômodos envolvidos no uso de Codex/Claude Code, e recentemente rodei esse agente no Terminal Bench 2.1
No começo fiquei feliz, porque o supervisor baseado em especificação foi melhor que o Codex básico em várias tarefas. Mas, olhando mais a fundo, havia muitos problemas nas próprias tarefas
O ponto central é que as instruções frequentemente são ambíguas, enquanto os casos de teste são específicos demais. Por exemplo,
configure-git-webservertem expressões como “so that I can run”, o que torna nebuloso o limite entre o que o agente deve fornecer e o que deve remover. Um agente que pensa demais configura o servidor e depois conclui que, se o usuário executar o mesmo comando, haverá conflito, então apaga os arquivos exatos que o validador verificaEm
make-mips-interpreter, a frase “I will check that you booted doom correctly” fez o supervisor interpretar que o usuário não verificaria se o Doom inicializa de forma independente, mas sim o resultado da inicialização feita pelo agente, então ele deixa o/tmp/frame.bmpgerado. O validador encerra se já existir um/tmp/frame.bmp, então não consegue iniciar o Doom e também não verifica se um novo arquivo é gerado durante o processo de boot[0]Em
mcmc-sampling-stan, o agente supervisor frequentemente chegava ao valor correto, mas, em vez de uma casa decimal simples, emitia uma saída numérica específica do domínio em notação científica. O validador fazia o parse do resultado de forma incorreta e marcava falha[1]Essas inconsistências são só uma parte do problema, e por isso considero que o Terminal Bench 2.1 já saturou, com os resultados do GPT-5.6 e do Mythos, 88,8% e 88% respectivamente, chegando quase ao teto esperável. O maior problema é que a maioria dos benchmarks é de execução única, e quase não testa modelos+harnesses em tarefas longas e iterativas, que é a principal forma como usuários reais usam ferramentas
[0] https://github.com/harbor-framework/terminal-bench-2-1/issue...
[1] https://github.com/harbor-framework/terminal-bench-2-1/issue...
Não era algo que todo mundo já sabia desde o começo, que o SWE-Bench inteiro tinha defeitos? Até os autores reconheceram as limitações e seguiram adiante faz tempo
Entendo por que isso pode virar um benchmark ruim, mas se o problema é algo como testes rigorosos demais invalidarem submissões funcionalmente corretas ao impor detalhes específicos de implementação não explicitados no prompt; prompts insuficientes omitirem requisitos que testes ocultos impõem, mas que não dá para inferir de forma razoável; testes de baixa cobertura validarem menos a funcionalidade solicitada e deixarem passar correções incompletas; e prompts enganosos levarem o modelo a um comportamento incorreto ou conflitarem com as exigências dos testes, então isso é uma situação bem realista se o objetivo é comparar modelos com engenheiros de software reais
É parecido com criar uma prova de enfermagem e depois marcar algumas questões porque era preciso pedir ao médico responsável informações adicionais que não estavam no prontuário, ou porque a família do paciente não explicou direito o histórico médico da avó idosa. Dá para querer um benchmark mais rigoroso, mas, se a OpenAI prometeu o modelo como substituto de trabalhadores reais, isso não pinta um quadro favorável. Na verdade, esse é justamente o tipo de coisa que deveria querer testar
Isso soa como “fizemos todo o trabalho necessário para consertar o benchmark e, no fim, decidimos abandoná-lo”. Os dados de base são tão preciosos assim que não dá para corrigir? No final se fala em uma abordagem um pouco mais seletiva para criar benchmarks, mas me parece que corrigir de forma justa testes bagunçados e incompletos vindos de dados do mundo real também é um caminho bem sólido
Teria sido bom dizer algo como “aqui está a lista de instâncias quebradas” ou “este é o subconjunto do SWE Bench Pro que vamos usar daqui para frente”. Estão deixando o perfeito atrapalhar o bom
Dito isso, a OpenAI fez exatamente esse tipo de coisa ao lançar o SWE-Bench Verified, então posso estar falando bobagem
O que deve ser considerado o estado da arte em benchmarks SWE agora?
Na minha visão e nas minhas avaliações pessoais, já faz bastante tempo que considero que, mesmo que o teto potencial de um modelo seja mais alto, se eu não tenho confiança para realmente aprovar aquele código, o valor dele é limitado
[0] https://deepswe.datacurve.ai/
[1] https://cognition.com/blog/frontier-code-1.1
[0]: https://deepswe.datacurve.ai/
Há https://cognition.ai/blog/frontier-code. Para deixar claro, eu fazia parte dessa equipe, mas aqui também tratamos dos problemas swebench pro/deepswe
Alcançar AGI precisa ser mais do que passar em todos os benchmarks, e também deve considerar problemas desconhecidos
A solução seria apenas: a) tornar o LLM menor com desempenho parecido, para que ele não consiga memorizar nem atacar benchmarks, ou b) criar um benchmark que cubra todos os dados do mundo real, mas isso é inviável