Hugging Face reproduziu 2.200 papers do ICML e achou 496 com claims falsificados

Quem coloca um modelo de pesquisa em produção geralmente parte de um pressuposto perigoso: se o paper foi aceito num evento como o ICML, os números batem. Um experimento recente da Hugging Face, documentado no post "What We Learned by Reproducing 2,200 papers from ICML", sugere que esse pressuposto merece muito mais ceticismo do que a comunidade costuma admitir.

O que foi feito, na prática

Entre 15 de julho e 2 de agosto de 2026, mais de 1.200 participantes rodaram um hackathon de reprodução. Em vez de auditar papers internamente, a Hugging Face abriu o desafio para a comunidade, cada um trazendo o próprio agente de código: Claude Code, Codex, Cursor, o orx da OpenResearch, entre outros. Em 19 dias foram publicados 6.816 "logbooks" (registros de reprodução) cobrindo 2.226 papers, cerca de 34% de todo o ICML 2026.

O fluxo era direto e vale entender porque ele resolve um problema real de escala:

• Os 6.341 papers aceitos foram indexados e tiveram seus claims científicos centrais extraídos. O agente não recebia um PDF de 40 páginas: recebia alvos concretos e verificáveis.
• Cada participante rodava a reprodução (ou uma versão "toy", em dados sintéticos, quando o dataset original era proprietário ou os checkpoints não tinham sido liberados) e publicava tudo: write-up, código, artefatos e, opcionalmente, o trace completo de execução do agente.
• Um Logbook Judge automático, rodando o modelo de pesos abertos GLM-5.2, relia cada logbook e emitia um veredito por claim: verified, falsified, toy ou inconclusive. O juiz era explicitamente instruído a tratar a autoavaliação de cada logbook como não confiável.

No total foram 35.908 claims julgados, 2.962 jobs lançados na infraestrutura da HF e 274 traces completos de agente publicados. Cada participante recebeu US$ 20 em créditos de compute. A escala é o ponto: checar um paper cuidadosamente custava a um revisor um fim de semana; um agente tenta isso numa tarde, em paralelo, milhares de vezes.

Por que isso surgiu agora

O ICML 2026 recebeu 23.918 submissões e aceitou 6.352 papers, praticamente o dobro do ano anterior. O post é honesto sobre a causa: os mesmos agentes que aceleram experimentos e a escrita estão inflando o volume de submissões. A capacidade de revisão, feita por voluntários, não dobrou junto.

O post cita a revisão de um paper que virou spotlight (destaque), nas palavras do próprio revisor: "Minha nota de confiança é baixa porque eu não checei todas as provas com cuidado." Segure essa frase, porque ela reaparece nos resultados.

Os números que importam para quem constrói

Agregando os vereditos por paper:

• 51% (1.103 papers) tiveram ao menos um claim verificado de forma independente. Desses, 266 foram totalmente reproduzidos, com todos os claims confirmados.
• 23% (496 papers) tiveram ao menos um claim falsificado ou contestado. Aí entram 49 papers em que nada pôde ser verificado e, o dado mais desconfortável, 242 papers em que times independentes chegaram a vereditos opostos sobre o mesmo claim.
• O resto ficou no meio: 502 com evidência apenas em escala reduzida e 280 onde nada pôde ser estabelecido, quase sempre por artefatos ausentes.

A leitura que o post extrai é a mais útil para engenharia: reprodutibilidade não é binária, é adversarial. Um claim pode "passar" em dezenas de checagens e desabar na quadragésima, dependendo de quem olha e de até onde a checagem vai.

As falsificações confirmadas dizem muito

Os 35 casos formalmente reivindicados como falsificação foram re-verificados adversarialmente pela equipe: relendo o paper, relendo o logbook e re-derivando a matemática. Alguns exemplos deixam claro o tipo de erro que passa batido numa revisão apressada:

• O paper de paging do começo do post. "Towards Optimal Robustness in Learning-Augmented Paging" afirmava robustez de H_k + O(1). Um logbook mediu o termo aditivo crescendo como 0.38·ln k e apontou o passo exato da prova que quebra. A re-implementação estendeu a varredura até k = 1.024 e confirmou o crescimento a cerca de nove sigma. A robustez real é H_k + Θ(log k). Era justamente o paper cujo revisor admitiu não ter checado as provas.
• Um teorema que cai depois do passo 224. Em "Attention's forward pass and Frank-Wolfe", três times acharam contraexemplos que só apareciam em t = 224, ~3.800 e 6.416 passos. Isso explica por que outros "verificaram": checagens de horizonte finito paravam cedo demais. Os autores confirmaram no mesmo dia.
• Teoria de uma loss, resultado de outra. Em "Self-Distillation Enables Continual Learning", toda a seção teórica analisa a divergência KL reversa, mas o default do código liberado, que segundo os autores gerou todos os resultados, computa KL direta.
• Avaliação inflada por padding. Em "Do Transformers Need Three Projections?", ~66% das posições avaliadas eram tokens de padding EOS que treinam para loss quase zero, deflacionando a perplexidade em cerca de três vezes. O custo de qualidade anunciado ("3,1% para 50% de redução de cache") vira ~9,4% quando corrigido.

E houve também falsas falsificações: um logbook alardeou que "o método é 2x mais lento que o baseline", mas o erro estava na própria reprodução (comparar tempo por trajetória com tempo por lote de 50). Normalizado corretamente, os dados confirmavam o speedup de 8x do paper original.

O que isso muda para o dev brasileiro

O recado prático é direto: um paper aceito, mesmo com spotlight, não é garantia de que os números se sustentam no seu caso de uso. Antes de portar uma técnica de quantização, uma loss customizada ou uma garantia teórica para produção, vale reproduzir o claim específico que você depende, no regime de escala que você vai usar. Os casos acima mostram que erros aparecem exatamente em escala (o termo log-k), em detalhes de implementação (KL direta vs. reversa) e em métricas mal configuradas (padding inflando perplexidade). São todos problemas que só surgem quando alguém roda o código de verdade.

A boa notícia é que o custo dessa checagem despencou. A infraestrutura do desafio é replicável: extrair os claims verificáveis de um paper, apontar um agente de código com um alvo concreto e deixá-lo rodar o experimento é hoje um workflow de uma tarde, não de um fim de semana.

O limite dos agentes, e onde o humano ainda pesa

O post é cético consigo mesmo, e isso é o mais valioso. Agentes puros travaram em loops, leram mal comportamento dependente de escala (vários "verified" no paper de paging vieram de checagens que pararam antes do crescimento log-k ficar visível) e chegaram a construir uma falsificação inteira em cima de um erro de unidades.

Os resultados mais confiáveis vieram de fluxos com humano no comando: re-apontando o agente, questionando uma premissa ou decidindo que o experimento estava mal formulado antes de queimar uma semana de compute. O caso vencedor de "human-in-the-loop" envolvia geração de imagens sob quantização extrema: as métricas numéricas diziam "sem colapso", mas se as imagens eram usáveis era uma questão perceptual. O agente montou uma UI de revisão e o humano julgou pessoalmente os 128 pares de imagens.

A analogia que o post usa é a de um orientador (PI) que monta o ambiente, o compute, os harnesses, o acesso a dados, e dá feedback nos momentos certos, deixando o aluno rodar. Quem tirou mais dos agentes foi quem construiu o ambiente certo e fez as perguntas certas. Fica em aberto quanto dessa supervisão será automatizável, mas por ora ela é o que separa uma auditoria útil de um número bonito e errado.

Fonte: Hugging Face Blog