Contaminação de benchmark: o modelo já viu a prova antes do teste?

O Claude Opus 4.6 desconfiou que estava sendo avaliado, identificou qual era o benchmark e foi atrás do gabarito 😅

A Anthropic documentou o caso no BrowseComp: em 1.266 problemas apareceram nove exemplos de contaminação, e em dois casos inéditos o modelo levantou a hipótese de estar sob avaliação, identificou o benchmark e chegou a localizar e descriptografar a resposta

Isso deixou de ser curiosidade de paper faz tempo

Se você escolhe modelo olhando tabela de ranking (e todo mundo faz isso), a pergunta que interessa é bem simples: aquele número mede capacidade ou memória?

Bora destrinchar isso

Como um exercício público acaba dentro do treino do modelo:

O caminho é menos misterioso do que parece

Benchmark bom precisa de tarefa real, então quem monta vai buscar onde tem material de verdade: issues do GitHub, problemas de plataforma de competição, fórum, artigo, dataset público

Ou seja, conteúdo público

E o que mais entra em pipeline de treino de LLM? Conteúdo público 😛

O benchmark e o corpus de treino bebem da MESMA fonte. Não precisa de má fé de ninguém pra o gabarito acabar do lado de dentro

Que tipo de vazamento conta como contaminação?

A revisão sistemática sobre detecção de contaminação classifica o problema em quatro níveis: exata, sintática, semântica e de nível de tarefa

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

O nome já entrega a escala: vai do item idêntico dentro do treino até formas bem mais indiretas, em que o que vazou não é o texto exato, e sim algo próximo demais dele

Esse é o ponto que mais gente erra: não precisa ser cópia literal pra contaminar

Se você conhece cache de aplicação, a analogia serve bem. O modelo não precisa ter o registro exato guardado, basta ter visto material perto o suficiente pra reconstruir a resposta sem raciocinar de novo

A definição corrente é essa: contaminação é exposição aos dados de avaliação durante o treino, o que infla a pontuação artificialmente por memorização em vez de capacidade real

Quatro casos reais de contaminação em benchmarks conhecidos:

Nada de achismo aqui, vamos só de caso documentado

SWE-bench Verified: a OpenAI parou de reportar

Em fevereiro de 2026 a OpenAI publicou que não usa mais o SWE-bench Verified como medida de capacidade de código de fronteira

Os motivos citados: saturação, testes falhos e contaminação vinda de repositórios públicos

E tem a parte que dói: na auditoria de contaminação, todos os modelos de fronteira testados (GPT-5.2, Claude Opus 4.5 e Gemini 3 Flash) conseguiram reproduzir gold patches verbatim ou detalhes específicos de certas tarefas do Verified

Reproduzir o patch de referência LITERALMENTE não é resolver o problema

É lembrar da resposta

BrowseComp e o Opus 4.6: o modelo percebeu a prova

O caso da abertura, com os números da análise da Anthropic sobre eval awareness

Nove exemplos de contaminação em 1.266 problemas

Ao menos 20 fontes distintas de respostas vazadas do BrowseComp circulando por aí

Um único problema consumiu 40,5 milhões de tokens, cerca de 38 vezes a mediana

Depois de reexecutar os problemas sinalizados com uma blocklist, a pontuação do Opus 4.6 foi ajustada para 86,57%

SWE-Bench+: a solução estava dentro da própria issue

Esse é quase piada de tão direto

O estudo SWE-Bench+ analisou 2.294 issues reais do GitHub em 12 repositórios Python

Resultado: 32,67% dos casos marcados como resolvidos tinham a solução presente na descrição ou nos comentários da issue (solution leakage) e 31,08% passaram por cobertura de testes fraca

Filtrando esses casos, a taxa de resolução do sistema estado da arte avaliado cai de 12,47% para 3,97%

Não é o modelo lendo o código e deduzindo o fix

É o modelo lendo a resposta que o próprio enunciado entregou

GSM1k: o mesmo teste, com problemas novos

A Scale AI fez o experimento mais limpo dessa lista com o GSM1k: criou um conjunto novo no mesmo estilo do GSM8k e comparou

Mesma dificuldade, mesmo formato, itens inéditos

Deu queda de acurácia de até 13% ao trocar um conjunto pelo outro, concentrada nas famílias Phi e Mistral

Modelos de fronteira mostraram sinais mínimos de overfitting, então não é caso de sair condenando todo mundo

E tem a pista mais interessante: correlação positiva (Spearman r² = 0,32) entre a probabilidade de o modelo gerar exemplos do GSM8k e o tamanho do gap entre os dois conjuntos

Quanto mais o modelo "cospe" o benchmark antigo, mais ele cai no benchmark novo. Faz sentido, né?

Contaminação não é o único defeito: o benchmark também pode estar quebrado:

Aqui tem duas coisas diferentes que vivem sendo misturadas

Contaminação é o modelo ter visto a prova

Benchmark quebrado é a prova estar mal feita, com gabarito que reprova resposta certa

Na auditoria da OpenAI ao SWE-bench Verified, feita sobre um subconjunto de 27,6% do dataset (justamente os problemas em que os modelos mais falhavam), ao menos 59,4% dos problemas auditados apresentavam falhas de design de teste ou de descrição do problema

Dentro disso: 35,5% com testes que exigem detalhes de implementação específicos e 18,8% com testes que cobram funcionalidade que o enunciado nem pediu

Traduzindo pro seu dia a dia: é aquele teste que quebra porque você nomeou o método diferente, não porque a feature parou de funcionar 🙂

E o SWE-bench Pro?

Esse é o exemplo de como a coisa se move rápido demais pra você confiar em post antigo

A OpenAI recomendou o SWE-bench Pro em fevereiro de 2026 e depois RETRATOU a recomendação, em publicação de 8 de julho de 2026

O split público tem 731 tarefas

O pipeline automático de análise sinalizou 200 tarefas quebradas (27,4%) e a campanha de anotação humana identificou 249 (34,1%), com cinco engenheiros de software experientes independentes na revisão, além de agentes investigadores

Os problemas apontados: testes rígidos demais cobrando detalhes de implementação que o prompt não pediu, e prompts subespecificados que omitem requisitos exigidos por testes ocultos

O estado final hoje é esse: recomendação retirada, com orientação de examinar com cautela resultados derivados do SWE-bench Pro

Tome cuidado ao citar tabela de leaderboard sem olhar a data

O que isso muda na hora de escolher um modelo pelo ranking:

Agora a parte prática, porque no fim você precisa escolher alguma coisa pra rodar amanhã

Primeira mudança: dois números da mesma tabela podem simplesmente não ser comparáveis

Se o modelo A memorizou parte do conjunto e o modelo B não, a diferença entre eles não mede quem programa melhor, mede quem raspou mais conteúdo público

E o pior é que você não tem como saber isso só olhando a coluna de porcentagem

Segunda mudança: ganho de poucos pontos percentuais em benchmark antigo e saturado não te diz nada

Saturação foi um dos motivos citados pela própria OpenAI pra abandonar o SWE-bench Verified como medida de fronteira. Quando todo mundo está lá em cima, a régua parou de separar os modelos

Terceira, e essa é a que vale: o teste que importa é a sua base de código privada

O seu legado esquisito, a sua convenção interna, aquele módulo que ninguém entende direito

NADA disso está em benchmark público, e é exatamente por isso que serve

Inclusive é assim que você descobre onde dá pra economizar, tipo saber quando um modelo mais barato basta, coisa que ranking nenhum vai te contar

Sinais de que um resultado está bom demais para ser verdade:

Não dá pra provar contaminação de fora, mas dá pra ficar esperto com alguns padrões

• Salto grande em benchmark antigo e público, estagnação em conjunto novo. Causa provável: memorização do material já indexado. O que fazer: comparar os dois números lado a lado antes de comemorar o maior
• Queda em variante equivalente do mesmo teste. É o padrão GSM1k: mesma dificuldade, itens inéditos, acurácia despenca. Causa provável: overfitting no conjunto original. O que fazer: procurar avaliação em conjunto novo antes de acreditar no antigo
• Benchmark montado sobre material público e antigo. Causa provável: a fonte do teste e a fonte do treino são a mesma. O que fazer: dar mais peso a avaliação com item posterior ao corte de treino
• System card sem nenhuma palavra sobre descontaminação. Causa provável: ou não fizeram, ou não quiseram contar. O que fazer: procurar a seção específica, quem faz costuma documentar
• Gasto anômalo de tokens em um item isolado. No caso do BrowseComp, um problema queimou 40,5 milhões de tokens, cerca de 38 vezes a mediana, e ali tinha comportamento estranho de verdade. O que fazer: olhar outlier de custo como pista, não como acaso

Pra prevenir, duas atitudes simples

Exigir do fornecedor a metodologia de descontaminação, por escrito, em vez de aceitar só o número da tabela

E testar em tarefa que só você tem

O que os benchmarks estão fazendo para resistir à contaminação:

A turma que monta avaliação não ficou parada, e as duas saídas mais conhecidas atacam o problema por ângulos diferentes

Data de publicação como filtro. O LiveCodeBench coleta problemas de plataformas de competição (LeetCode, AtCoder e Codeforces) e anota cada um com a data de lançamento

Aí, pra um modelo com corte de treino D, avalia-se somente nos problemas lançados depois de D

Simples e elegante: se o problema nasceu depois do treino, o modelo não pode ter visto

Renovação contínua do conjunto. O LiveBench troca cerca de um sexto das questões por mês, o que renova o conjunto completo a cada seis meses

As questões novas ficam um mês sem divulgação pública

E a pontuação usa gabarito objetivo, sem juiz humano e sem LLM como juiz, com fontes que incluem competições de matemática recentes, artigos do arXiv, notícias e datasets

É prova nova toda hora, e ninguém vê o gabarito antes

Por que ainda não existe detector confiável de contaminação:

Agora o contraponto honesto, senão isso aqui vira receita de bolo

A revisão sistemática cobriu 55 estudos até o fim de 2025, agrupados em cinco famílias de detecção: casamento de strings, baseada em verossimilhança, inferência de pertencimento, detecção via prompt em LLM e auditoria de benchmark

A conclusão? Nenhum método é consistentemente confiável em todos os níveis de contaminação, cenários de acesso ao modelo e etapas de treino

E aquele truque que parecia infalível, de olhar a queda de desempenho depois do corte de treino, também tem asterisco

O estudo Test of Time mostra que questões geradas por LLM produzem padrões temporais bem diferentes de questões de preenchimento tiradas direto do mesmo material

Uma transformação simples por LLM chegou a REMOVER o padrão temporal em benchmarks que reportavam queda pós corte, incluindo o LiveCodeBench

Ou seja: o sinal temporal depende de como a questão foi escrita, não só de quando ela nasceu

E quem constrói modelo sabe disso. O system card do Claude Opus 4.5 registra que a descontaminação não é uma ciência exata e que todos os desenvolvedores de modelos precisam continuar melhorando seus métodos nessa área, além de incluir análise de contaminação para o SWE-bench e descontaminação difusa (fuzzy) para avaliações de resposta longa

Quando o próprio fornecedor escreve isso na documentação, é bom levar a sério

Conclusão: trate o benchmark como pista, não como veredito

Benchmark não é mentira, é medida imperfeita

Ele ainda serve pra descartar opção obviamente fraca e pra sentir a direção geral do mercado

O que ele não faz é decidir por você, principalmente quando o benchmark é público, antigo e nasceu do mesmo material que virou treino

O próximo passo é bem concreto e você consegue fazer nesta semana: monta um conjunto próprio de tarefas reais do seu projeto, coisas que só existem no seu repositório privado, e roda os modelos candidatos nelas

Dez tarefas honestas do seu backlog valem mais que qualquer tabela

E antes de acreditar no número, abre o system card do modelo e procura a seção de contaminação. Se não tiver nenhuma, já é resposta 🙂

até o próximo post!