Um Artigo do ICML Ganhou o Benchmark Sem Responder Nada

Paulo Rodrigues8 min de leitura

Há um artigo no ICML 2026 cujo argumento inteiro é uma partida que resulta.

Os autores criaram um método a que chamam Prejudicial Trick. Faz o seguinte: na maior parte das vezes, não devolve nada. Uma resposta vazia. Ocasionalmente, em poucos por cento das vezes, devolve uma resposta inflacionada.

Na métrica-padrão que a área usa para avaliar este tipo de sistema, ganha. Não por enganar a medição. Por a satisfazer, exatamente como está escrita, sendo completamente inútil.

É esse o objetivo. Os autores não estavam a propor um método. Estavam a construir uma arma para provar que a métrica está partida.

Passei uma tarde a verificar se tinham razão. Tinham. E depois encontrei uma coisa que eles não mencionam.

O que a métrica mede, e o que não mede

Os sistemas em causa produzem intervalos de previsão — em vez de "esta casa vale 340.000 €", dizem "esta casa vale entre 310.000 € e 370.000 €, e acerto em 90% dos casos".

Dois números avaliam isso. Cobertura: a resposta verdadeira cai dentro do intervalo com a frequência prometida? Comprimento: quão largo é o intervalo? Quer cobertura alta e intervalos curtos, porque um sistema que diz "entre 0 € e 10 milhões, 100% correto" é tecnicamente honesto e praticamente inútil.

Parece razoável. Toda a gente reporta assim. E eis a abertura por onde os autores passaram.

Devolva um intervalo vazio em 4% dos casos. Perde um pouco de cobertura. Compense alargando ligeiramente os outros 96% — recupera a cobertura. Efeito final no marcador: a cobertura mantém-se nos 90% e o comprimento médio desce.

Acabou de ganhar. O seu método é melhor no papel do que o método que envolve.

O que faz na realidade: dê-lhe a mesma casa duas vezes e diz "310.000 € a 370.000 €" à primeira e absolutamente nada à segunda. A métrica não consegue ver isto, porque mede uma média e uma taxa de acerto. E o lançamento de uma moeda também tem uma média perfeitamente aceitável.

Repeti a experiência

O artigo reporta 22,894 para o método honesto e 22,614 para o truque. Intervalos ligeiramente mais curtos, a mesma cobertura. É esse o título.

Fui buscar o código deles e corri-o. 22,8938. O número deles, cinco algarismos significativos, a partir do CPU de um portátil em cerca de oito segundos. Sem GPU e sem nuvem: numpy, scikit-learn e uma regressão linear sobre um conjunto sintético pequeno.

O truque também reproduz, e a razão pela qual é veneno reproduz igualmente. O artigo prova que a instabilidade do truque (o quanto a resposta para uma entrada fixa salta entre execuções) é matematicamente garantida como maior do que zero, enquanto a do método honesto é exatamente zero. Reproduzi isso em conjuntos de dados reais: 1,14 para o truque, 0,00 para o método honesto. O número que expõe a fraude não é subtil. Apenas não é o número que alguém reporta.

A parte que não está no artigo

O código deles não reproduz o artigo deles.

Corra o script exatamente como está publicado e obtém 43,566 onde o artigo diz 22,894. Quase o dobro. Parece que o artigo é falso.

Não é. O script fixa uma constante, um valor de bias, em 20. A tabela foi feita com 10. O valor correto está no mesmo ficheiro, numa lista que o script nunca usa. Mude um número e 15 dos 16 valores da tabela regressam.

Depois a mesma doença num segundo sítio: uma lista de constantes por conjunto de dados, três das quais não correspondem à tabela publicada. E num terceiro: o ficheiro de dependências permite uma versão do pandas em que o código não consegue correr — instale-o de raiz hoje e rebenta.

Três defeitos. Dois deles falham em silêncio, entregando números plausíveis e errados.

Só consegui ter confiança nisto por causa de um controlo. Um dos conjuntos de dados da tabela reproduz na perfeição usando a constante que eles lançaram. O mesmo código, a mesma máquina, a mesma tarde. É isso que separa "a constante deles está errada" de "parti alguma coisa" — sem o controlo, teria uma acusação em vez de uma conclusão. Se levar apenas uma ideia de método deste artigo, leve essa.

Submeti as três correções no repositório deles e publiquei a reprodução completa, com todos os comandos e resultados, no âmbito do desafio de reprodução do ICML 2026 da Hugging Face e da alphaXiv. O trabalho é bom. O empacotamento é que o está a fazer parecer fraude.

Porque é que isto lhe interessa

Provavelmente não está a comprar predição conforme. Está a receber números.

93% de exatidão. 40% mais rápido. 87% de redução de custos.

Três coisas viajam daquele artigo diretamente para aquela frase.

Primeira: uma pontuação é um atalho, e há sempre alguém a otimizar contra o atalho. Não necessariamente com desonestidade. Aponte um otimizador qualquer (uma equipa, um ciclo de treino, uma apresentação comercial) a um número, e ele encontra o caminho mais barato para mexer nesse número. Às vezes o caminho mais barato passa por fazer bem o trabalho. Às vezes passa pela distância entre o que é medido e o que interessa. O Prejudicial Trick é essa distância, tornada visível de propósito.

Segunda: pergunte o que foi medido, não o que foi pontuado. "93% de exatidão" não é prova até saber exato em quê, sobre que dados, contra que referência. A cobertura do truque era uns genuínos 90%. Todos os números que reportava eram verdadeiros. O número que ninguém pediu era o único que importava.

Terceira — e é esta que eu usaria: peça a variância, não a média. O truque é invisível na média e óbvio no instante em que corre a mesma entrada duas vezes. Não é um teste difícil. É a pergunta mais barata da sala, e quase nenhum benchmark lhe responde. Quando um fornecedor demonstrar um sistema de IA, corra a mesma entrada três vezes. Se as respostas diferirem, a média que lhe apresentaram está a esconder uma distribuição que ainda não viu.

E por baixo das três: código publicado falha frequentemente a reproduzir resultados publicados. Não por malícia, mas por uma constante deixada no valor errado ou por um intervalo de dependências que apodreceu. Se isto acontece num artigo revisto por pares do ICML, cujos autores claramente se preocuparam, presuma que acontece na demonstração comercial que foi montada na terça-feira passada.

Os limites honestos

Verifiquei três das cinco alegações do artigo. Duas exigem um conjunto de dados médicos com um acordo institucional que não tenho. Não verifiquei as demonstrações matemáticas — apenas que as experiências fazem o que o artigo diz. Uma das minhas conclusões, sobre um conjunto de dados a que não consegui aceder, está assinalada no registo como um palpite por testar e não como um resultado, porque é isso que é.

Também errei pelo caminho. Construí um argumento para o erro tipográfico do artigo que se revelou inválido — a conclusão sobreviveu, mas apenas porque uma verificação adversarial demoliu o raciocínio e encontrou prova melhor: o próprio ficheiro que os autores publicaram contém o valor correto. Um artefacto deles, a contradizer a tabela deles, dentro do repositório todo este tempo. Eu tinha-o copiado horas antes e nunca o abri.

O que é exatamente a mesma lição da métrica. Tinha uma cadeia de raciocínio plausível e tratei-a como prova. O truque tem uma pontuação plausível e trata-a como qualidade. São o mesmo erro: confundir aquilo que é fácil de medir com aquilo que se quer realmente.

A solução não são métricas mais espertas. É lembrarmo-nos de quais dos nossos números são atalhos — e estarmos dispostos a ir abrir o ficheiro.

Perguntas Frequentes

O que significa dizer que um benchmark pode ser manipulado?

Significa que um método pode pontuar melhor na métrica publicada e ser pior no trabalho real. O artigo que reproduzi demonstra-o de forma concreta: o Prejudicial Trick devolve uma resposta vazia na maior parte das vezes e uma resposta inflacionada ocasionalmente. Na métrica-padrão de cobertura e comprimento, ganha — a pontuação melhora mesmo. Mas o que produz é inútil, porque a mesma entrada recebe uma resposta completamente diferente de cada vez que corre. A métrica mede a largura média e a taxa de acerto. Não mede se o sistema é estável. Um método que explora a distância entre o que é medido e o que interessa parece progresso no papel.

Isto quer dizer que os benchmarks de IA não valem nada?

Não. Quer dizer que um benchmark é um indicador aproximado, e todos os indicadores têm uma distância entre o que medem e aquilo que lhe interessa. Isso é normal e inevitável — são os atalhos que tornam a avaliação barata. A falha está em esquecer quais dos seus números são atalhos e depois tratar o resultado do atalho como se fosse a coisa real. Uma pontuação diz como um sistema se comportou numa medição específica. Não diz que o sistema é bom. São afirmações diferentes, e os fornecedores citam a primeira a sugerir a segunda.

Se o código de um artigo não corre, a investigação está errada?

Normalmente não — e é essa a parte incómoda. A ciência deste artigo estava correta: todos os números que consegui verificar bateram certo com a tabela publicada. Mas o código lançado trazia uma constante errada em dois sítios e um intervalo de dependências que já não instala. Corra-o tal como está publicado e obtém números com cerca do dobro, ou um erro. Quem verificasse honestamente, hoje, concluiria muito provavelmente que o artigo era falso. Não era. Código partido e investigação má são indistinguíveis de fora — e é exatamente por isso que a reprodução tem de ser feita, não presumida.

Como deve uma empresa avaliar as alegações de desempenho de um fornecedor de IA?

Pergunte o que foi medido, não o que foi pontuado. Um número sem a definição da métrica não é prova. Depois peça que corram o sistema à sua frente, com os seus dados, e olhe para a variância em vez da média — se a mesma entrada dá respostas diferentes, a média está a escondê-lo. A contribuição central do artigo é precisamente uma métrica de estabilidade que apanha isso. A maioria dos benchmarks comerciais reporta uma média e nenhuma variância, e é por essa abertura que este método passa.

É realmente possível verificar um artigo científico por conta própria?

Às vezes, e mais vezes do que se pensa. Este demorou oito segundos de CPU — sem GPU, sem nuvem, apenas numpy e scikit-learn num portátil. A experiência inteira era um conjunto sintético pequeno e uma regressão linear. A barreira nunca foi o poder de cálculo; foi ninguém ter tentado. Havia cerca de seis mil artigos no desafio e apenas cerca de 1% das alegações tinham sido verificadas.

Pronto para automatizar o seu negócio?

Construímos ferramentas de IA e sistemas de automação para PMEs europeias — desde MVPs rápidos até sistemas em produção, sempre em conformidade com o GDPR.

it's human stuff

Insights semanais de IA para PMEs europeias. Sem exageros, apenas o que funciona.

Continue a Ler