51 Autores Recorrigiram Seis Benchmarks. Os Testes Erraram na Direção Oposta.

TV
Thiago Victorino
7 min de leitura
51 Autores Recorrigiram Seis Benchmarks. Os Testes Erraram na Direção Oposta.

Toda crítica a benchmark que publicamos até aqui argumentava que o número estava alto demais. Em setembro de 2026, um artigo com 51 autores, vários deles professores de física de Yale, recorrigiu seis benchmarks de física e encontrou a falha correndo no sentido inverso: os testes estavam marcando respostas certas como erradas.

O artigo, submetido em 11 de setembro de 2026 como arXiv 2609.13009, cobre HLE-Physics, CMT-Benchmark, CritPt, UGPhysics, PRISM-Physics e PHYBench. A conclusão, nas palavras dos próprios autores: “Most audited cases initially evaluated as incorrect reflect these benchmarking issues rather than errors in the models’ physics reasoning.” O resumo omite qualquer percentual. “A maioria” é o quantificador mais forte disponível, e já basta para quebrar o instrumento.

Três Modos de um Teste Fabricar um Falso Negativo

Os autores nomeiam três classes de defeito: erros do corretor, soluções de referência incorretas e questões ambíguas ou subespecificadas. Nenhuma delas é o modelo falhando em física. Cada uma é o benchmark falhando na própria função, e todas produzem o mesmo artefato no ranking, uma resposta errada que não era errada.

A escala da correção é a parte desconfortável. Para o GPT-5.6-Sol, o HLE-Physics vai de 47,3% para 78,7% em mean@4, e o CMT-Benchmark vai de 61,0% para 87,2% em mean@4, uma vez removidos os itens defeituosos. Os dois números corrigidos são calculados sobre os subconjuntos de avaliação retidos após revisão de especialistas, como os próprios autores declaram. O número corrigido descreve uma população diferente da pontuação original. Quem o produziu foi um teste menor, corrigido direito. No CritPt, o artigo relata 94,4% em pass@4 sobre 54 desafios retidos, outra métrica ainda.

Leia a direção em vez da magnitude e a conclusão é seca: “These findings suggest that current benchmarks substantially understate frontier models’ ability to solve well-posed physics problems.” O recorte importa. Bem postos. A auditoria silencia sobre os problemas mal postos, que é onde colocaríamos a maior parte do trabalho que um time de fato entrega a um modelo, e os autores não afirmam o contrário.

O Que os Autores Recomendam É Aposentadoria

A frase prospectiva do artigo é a que a maioria dos leitores vai pular, e é a que mexe em orçamento: “Near-saturation on these closed-ended tasks highlights the need for more demanding, expert-validated evaluations.”

Ou seja, um grupo de pesquisa avisando que a própria classe de instrumento chegou ao fim da vida útil para diferenciar modelos de ponta entre si. Um remendo no corretor não a recupera, porque o espaço de crescimento acabou. Já argumentamos em invalidez de benchmark não é contaminação que um teste quebrado é um defeito de projeto e não um vazamento, e essa auditoria é a evidência mais forte dessa leitura que já vimos. Os defeitos estavam no aparato de correção, não na cadeia de suprimento dos dados.

No Mesmo Mês, um Benchmark Foi para o Outro Lado

A Specific Labs publicou o Real-SWE em setembro de 2026. Ele roda 8 configurações de modelo mais harness sobre 10 tarefas tiradas de bases de código privadas de empresas, 640 rollouts pontuados, todos em raciocínio alto. O par líder, Fable 5.1 com Claude Code, resolve 38,8%. O GPT-6 Astra com Codex CLI chega a 33,8%. O GPT-5.6 Sol com Codex CLI chega a 16,2%.

A manchete do próprio benchmark é que “6 of 10 tasks have resolution rates below 15%” e que “No model solves every task.” Uma tarefa, um redutor de fluxo de analytics, marcou 0 de 80 em todos os modelos e harnesses testados.

Segure a ressalva enquanto lê esses números. O Real-SWE é publicado por um fornecedor, uma empresa com produto no setor, rodando sobre bases de código privadas licenciadas. Sua reprodução independente está fora de alcance. O que ele oferece é o formato das tarefas: instrução com mediana de 1.742 caracteres e solução de referência com mediana de 11 arquivos alterados, contra 6 do FrontierCode e 6 do DeepSWE. O trabalho é maior do que o que as suítes públicas pedem.

A dispersão por tarefa é a parte útil, porque ela é irregular. Chaves de API e ambientes resolvem em 71,9%. Uma varredura multirregião, 68,8%. Linhas de excedente de direito de uso, 50,0%. Migração de identidade de cliente, 37,5%. Depois desaba: migração de cronograma de cobrança 14,1%, medição de tokens de API 12,5%, medição de datastore S3 10,9%, varredura linearizável 10,9%, jurisdição tributária 3,1%, redutor de fluxo de analytics 0,0%. Duas das piores pontuações são problemas difíceis de sistemas distribuídos, então a dispersão fala sobre tipo de tarefa, e não sobre exposição regulatória.

O Real-SWE também classifica como os agentes falham: premissa não verificada, requisito perdido, erro de integração, regressão, arquivo errado. A página afirma que “Missed requirements are the most common failure” e que “Different models fail in different ways.” A duração do rollout tampouco salva o quadro. Pelas contagens do gráfico do próprio benchmark, 76 de 108 rollouts curtos falharam e 385 de 532 dos mais longos falharam, cerca de 70% e 72%. Os modelos falham até em rollouts curtos.

Uma Pontuação Pública Já Não Informa em Nenhuma Direção

Junte os dois e um número público passa a carregar erro nos dois sinais ao mesmo tempo. A auditoria de física mostra um instrumento que fabrica falsos negativos pelo próprio aparato de correção. O Real-SWE mostra pontuações que ficam perto de 38,8% no topo quando o trabalho se parece com o que uma empresa de fato mantém. Nenhuma das duas fontes faz esse ponto sozinha, e nenhuma delas diz em que direção a sua pontuação específica está errada.

Já escrevemos que dá para vencer o benchmark e perder a carga de trabalho, e que o placar está quebrado dos dois lados, porque o número infla na entrada e o custo se esconde na saída. A evidência de setembro acrescenta a peça que derruba a última defesa. Até agora, um líder podia tratar um benchmark público como piso conservador, no raciocínio de que gaming e contaminação empurram a pontuação para cima, logo a capacidade real estaria abaixo da manchete. Essa defesa acabou. Uma pontuação que pode errar nos dois sentidos, subestimada pelo próprio corretor e inflada por um vazamento, deixa de ser piso, teto ou limite de qualquer tipo.

Faça Isto Agora: Mude o Que o Memorando de Fornecedor Pergunta

Apague a linha de benchmark do seu próximo memorando de seleção de modelo. Ela perdeu o valor de decisão em qualquer direção, e mantê-la convida alguém a tratá-la como evidência.

No lugar, coloque as duas perguntas que o Real-SWE está estruturado para responder e que nenhuma posição de ranking responde.

Em qual classe de tarefa esse par falha? Peça a decomposição por tarefa, no lugar do agregado. Nos dados do Real-SWE a mesma suíte varia de 71,9% a 0,0% conforme a tarefa. A sua base de código tem a própria versão dessa curva, e as tarefas que o seu time entrega a um agente toda semana são as únicas que contam. Escolha cinco tickets recentes que um modelo poderia plausivelmente assumir e registre a resolução por ticket, sem média.

Qual classe de falha ele produz? Requisito perdido, premissa não verificada, erro de integração, regressão, arquivo errado. Cada uma tem custo e controle diferentes. Um requisito perdido é pego na revisão, desde que o requisito esteja escrito. Uma premissa não verificada sobrevive à revisão e falha em produção. Saber qual delas um par produz diz onde gastar o orçamento de revisão, e a posição no ranking silencia sobre isso.

Os autores do artigo de física pediram “more demanding, expert-validated evaluations.” Dentro de uma empresa, o especialista é o seu engenheiro sênior e a avaliação exigente é o trabalho que já está no seu backlog. Essa avaliação é cara de construir e é a única que continua honesta quando os instrumentos públicos falham em direções opostas.


Fontes

A Victorino constrói avaliações em nível de tarefa sobre o seu próprio backlog para que decisões de modelo se apoiem no seu trabalho e não em uma pontuação pública: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa