A OpenAI Recomendou o Benchmark. Depois Auditou e Achou Um Terço das Questões com Defeito.

Oito meses. Foi o tempo que a taxa de acerto dos modelos de fronteira no SWE-Bench Pro levou para subir de 23,3% para 80,3%. Um salto tão íngreme é ou um avanço real de capacidade ou um instrumento de medição quebrado. A OpenAI auditou o benchmark para descobrir, publicou o resultado em 8 de julho de 2026, e a resposta foi o instrumento. Cerca de um terço das tarefas públicas do benchmark tem defeito.

Duas contagens independentes sobre o conjunto público de 731 tarefas chegaram à mesma ordem de grandeza. Um pipeline automatizado marcou 200 tarefas, 27,4% do conjunto. Uma campanha separada de anotação humana marcou 249 tarefas, 34,1%. Um filtro automatizado inicial havia levantado 286 candidatas para revisão mais profunda antes de o número se estabilizar.

Já escrevemos sobre confiança em benchmarks por três ângulos. Contaminação é o modelo ter visto as respostas durante o treino. Inflação de infraestrutura é o scaffold inflar a nota em torno de uma pergunta honesta. O placar quebrado dos dois lados é a medição errada na entrada e na saída. Esta auditoria expõe uma quarta falha, que fica embaixo das outras três: as próprias questões são inválidas. Um teste que reprova uma resposta funcionalmente correta não mede nada, por mais limpo que seja o dado de treino e por mais honesto que seja o harness.

Um fornecedor auditando a própria recomendação

A OpenAI havia recomendado o SWE-Bench Pro. Depois de rodar a auditoria, retirou essa recomendação por escrito. Um fornecedor retratando um benchmark que endossou é mais raro do que parece, e merece leitura atenta.

A razão declarada é de governança. A OpenAI trata o caso como higiene de processo. Esses resultados de avaliação alimentam as decisões do Preparedness Framework da OpenAI, o processo interno que libera o lançamento de modelos contra limiares de capacidade e segurança. Quando a eval tem defeito, nas palavras da própria OpenAI, ela “deturpa os argumentos de segurança”. Um benchmark que deixa uma correção incompleta passar não só bajula o modelo. Ele diz a quem decide se um sistema é seguro para entrar em produção que o sistema superou uma barra que nunca chegou a tocar.

O padrão que a OpenAI define para uma eval utilizável é compacto o bastante para roubar: uma eval deve ser “difícil de burlar, fácil de confiar e genuinamente representativa da capacidade ou do alinhamento do modelo”. Três propriedades. A maioria das suítes internas de eval, na maioria das empresas, satisfaz a primeira por acaso e as outras duas nunca.

Uma correção antes da taxonomia, porque duas newsletters erraram. A TLDR DEV creditou esta auditoria à Anthropic; a TLDR AI creditou à OpenAI. Ambas apontaram para a mesma URL da openai.com, diferindo apenas por uma tag UTM. A publicadora e autora é a OpenAI. A provável origem da confusão: a ferramenta de auditoria da OpenAI rodou sobre agentes investigadores baseados no Codex, e um leitor procurando um nome achou o errado. Se você viu isto creditado à Anthropic, foi a newsletter, não a fonte.

As quatro formas de uma questão quebrar

A auditoria classifica cada defeito em quatro categorias. Esta é a parte que você guarda. É um checklist para rodar contra as suas próprias tarefas.

Testes rígidos demais. Os testes ocultos exigem detalhes de implementação que o prompt nunca especificou. Uma submissão que resolve o problema enunciado corretamente ainda falha, porque escolheu um nome de variável, um formato de retorno ou uma estrutura interna que o autor do teste exigiu em silêncio. O modelo estava certo. O teste estava errado.

Prompts subespecificados. A imagem espelhada. O prompt omite requisitos que os testes ocultos depois cobram. O modelo não consegue satisfazer uma restrição sobre a qual nunca foi avisado. Nenhuma dose de capacidade cobre essa distância, porque a informação necessária está ausente da pergunta.

Testes de baixa cobertura. Os testes checam o recurso pela metade, então uma correção incompleta passa. Este é o perigoso, porque infla a nota para cima e em silêncio. É também onde revisores humanos e de máquina mais divergiram: o pipeline de agente marcou 4,1% das tarefas como baixa cobertura, os engenheiros humanos marcaram 9,4%. Os humanos pegaram mais que o dobro do que a automação pegou. O pipeline automatizado subconta sistematicamente justamente o defeito que faz um benchmark parecer melhor do que é.

Prompts enganosos. O prompt aponta o modelo para o comportamento errado, contradizendo diretamente o que os testes exigem. A tarefa é uma armadilha. Seguir as instruções garante reprovação no avaliador.

Dois desses quatro (testes rígidos demais e prompts enganosos) punem o trabalho correto. Dois deles (prompts subespecificados e testes de baixa cobertura) deixam o trabalho errado passar. Um benchmark carregando os quatro não está medindo capacidade. Está gerando ruído com uma casa decimal.

O protocolo que os encontrou

O achado é útil. O método é o ativo transferível, e é mais barato de copiar do que de admirar.

O estágio 2b da auditoria colocou cada tarefa diante de cinco engenheiros de software experientes. Cada um foi treinado antes na taxonomia de quatro categorias. Cada um julgou de forma independente a partir do enunciado do problema, dos testes e do patch de referência, formando um veredito antes de ver qualquer saída do pipeline. Discordâncias eram escaladas, não diluídas em média.

Os resultados são o que tornam o protocolo digno de adoção. A concordância de categoria entre agente e humano ficou em 74%. Em nenhuma tarefa marcada o veredito humano mais comum foi “não está quebrada”. Toda tarefa que o pipeline marcou, o painel humano também considerou defeituosa. A automação e os humanos discordaram apenas sobre qual defeito cada tarefa carregava. Sobre haver um defeito, concordaram. Esse veredito compartilhado é a assinatura de um problema real, do tipo que um revisor exigente sozinho não produziria.

Repare na regra de ordenação, porque é a parte que os times pulam. Os revisores formaram um juízo a partir do material bruto antes de ver a marcação da máquina. Mostre a marcação primeiro e você obtém confirmação disfarçada de revisão. Os humanos ancoram, depois a automação os confere, depois os humanos julgam.

Rode isto contra as suas próprias evals esta semana

Toda empresa que lança recursos de IA agora roda evals internas para decidir o que é bom o suficiente para ir ao ar. Quase nenhuma audita essas evals. Os números do SWE-Bench Pro são um aviso sobre o que uma suíte não auditada esconde: um terço do seu sinal de aprovado/reprovado pode estar medindo a coisa errada, nas duas direções ao mesmo tempo.

Puxe dez tarefas da sua eval interna mais confiável. Para cada uma, sem olhar nenhuma nota automatizada, peça a um engenheiro para ler o prompt, os testes e a solução de referência, e responder quatro perguntas. Os testes exigem algo que o prompt nunca pediu? O prompt omite algo que os testes cobram? Uma solução incompleta conseguiria passar? O prompt aponta para longe do que os testes querem? Cada sim aponta um defeito na sua régua, e a régua é o que você conserta.

Depois faça a aritmética que importa. Se duas de dez tarefas estão quebradas, e a sua decisão de lançamento depende de um movimento de dois pontos na nota, a sua decisão de lançamento depende de ruído. A OpenAI precisou de cinco revisores treinados e uma taxonomia para confiar no próprio benchmark. A sua suíte interna, a que libera o seu modelo em produção, quase certamente nunca foi verificada.

A nota de um modelo só é tão confiável quanto as questões por trás dela. Esta semana, leia as suas questões.

Fontes

OpenAI. “Separating Signal From Noise in Coding Evaluations.” Julho de 2026.

A Victorino ajuda organizações de engenharia a auditar as evals de que dependem suas decisões de lançamento, antes que essas decisões cheguem à produção: contato@victorino.com.br | www.victorino.com.br