Juízes LLM reprovam em teste de confiabilidade pré-registrado

Modelos de linguagem hoje avaliam outros modelos de linguagem. Eles pontuam respostas, classificam traços de raciocínio, filtram dados de treinamento e alimentam rankings públicos. Quando um modelo é usado assim, ele deixa de ser objeto de estudo e passa a ser instrumento de medição. E todo instrumento carrega uma premissa que quase nunca se enuncia: a de que é estável.

Um artigo publicado no arXiv em 3 de setembro de 2026 auditou exatamente essa premissa e encontrou um resultado desconfortável. Assinado por Haoyuan Zhu, da Escola de Engenharia Elétrica e Eletrônica da Universidade de Sheffield, e Jie Zhang, do departamento de pesquisa e desenvolvimento da Ranplan Wireless Network Design e da Cambridge AI+, ambos no Reino Unido, o trabalho relata duas campanhas experimentais pré-registradas que nenhuma delas passou da etapa de validar o próprio instrumento.

O desenho do experimento

Pré-registro é uma prática metodológica emprestada das ciências biomédicas: os pesquisadores fixam antecipadamente as hipóteses, os procedimentos e — o ponto crítico aqui — os limiares de aceitação, antes de olhar os dados. Isso impede o ajuste retroativo dos critérios para acomodar o resultado obtido.

As duas campanhas foram construídas para testar se um modelo observador consegue ler o progresso de uma solução a partir de traços parciais de raciocínio. Todos os limiares foram congelados de antemão. Antes de chegar à pergunta de pesquisa, porém, era preciso passar por um portão de validação: verificar se o instrumento de medição era confiável. Nenhuma das duas passou.

O volume auditado foi de 52.988 tentativas de requisição. Os dois números centrais:

• Repetições dentro da mesma janela concordaram com correlação de Spearman de 0,400, contra um limiar exigido de 0,90.
• Reexecuções no dia seguinte, com corpos de requisição byte a byte idênticos, concordaram a 0,78, contra um limiar exigido de 0,99.

Em ambos os casos, o registro de execução estava no teto. Ou seja, do ponto de vista da engenharia, tudo funcionou como projetado: as requisições saíram corretas, foram entregues e retornaram respostas válidas. O que falhou não foi o código, foi a medição. Daí o título do trabalho, que contrapõe engenharia limpa a medição instável.

Por que isso acontece

Os autores localizam a causa na infraestrutura de servimento compartilhado, apoiados na literatura de sistemas. Três mecanismos se combinam.

Primeiro, servidores de inferência agrupam requisições concorrentes em lotes para ganhar eficiência. Núcleos de inferência comuns não são invariantes ao tamanho do lote: a mesma entrada, processada em um lote de composição diferente, pode produzir resultados numericamente distintos por causa da ordem das operações de ponto flutuante.

Segundo, implantações mudam por trás de nomes de modelo fixos. O rótulo permanece o mesmo enquanto o que está servindo por baixo pode ter sido atualizado.

Terceiro, e decisivo: nada disso aparece nos metadados de resposta que um avaliador consegue registrar. Um estudo de caixa-preta observa a instabilidade sem conseguir atribuí-la a uma causa específica.

Os três modos de falha

O artigo nomeia três modos, na ordem em que foram encontrados.

M1: viés no mapeamento entre rótulo e significado

O protocolo inicial passou no critério de repetibilidade escalar, mas falhou no critério de ordenação, e falhou com mediana negativa. Ao inverter qual rótulo significava correto, a mediana de Spearman da ordenação de candidatos dentro de cada tarefa ficou em -0,632, contra o limiar congelado de 0,90, enquanto a variação absoluta mediana de probabilidade foi de 0,0233, dentro do limite de 0,03.

Uma mediana negativa é assinatura de algo mais forte que ruído: trocar o significado dos rótulos tendia a inverter a ordenação. Em outras palavras, parte substancial do sinal medido vinha da convenção de rotulagem, não do conteúdo avaliado.

M2: instabilidade de ordenação sobre grandezas quase degeneradas

Quando os candidatos a serem ordenados diferem entre si por margens muito pequenas — os autores descrevem lacunas várias ordens de grandeza abaixo do piso de ruído do próprio instrumento —, a ordenação produzida vira essencialmente sorteio. Não há sinal a extrair.

M3: entradas idênticas, saídas que derivam

É o resultado mais concreto. O instrumento reexecutou 100 requisições congeladas após um intervalo obrigatório de 24 horas, com corpos verificados por SHA-256 como idênticos byte a byte, 100 de 100. A ordenação exata foi reproduzida 78 vezes em 100.

As 22 permutações que derivaram se espalharam por 16 de 25 tarefas, e todos os campos de metadados visíveis ao provedor permaneceram constantes. A deriva, porém, é local: 78 reproduções exatas, 11 a distância de Kendall 1 e 11 espalhadas entre distâncias 2 e 11. A concordância de primeiro colocado foi de 95 em 100, e a concordância de ordem par a par ficou em 4.436 de 4.500, ou aproximadamente 0,986. São, majoritariamente, transposições de posições adjacentes.

Vale um registro de honestidade metodológica dos autores: eles inicialmente chamaram esse modo de deriva noturna, atribuindo-o a mudanças de backend durante as 24 horas. Um experimento suplementar posterior falsificou essa atribuição, e o nome foi corrigido. O intervalo não era a causa.

O que não resolveu

A parte mais útil do trabalho, do ponto de vista prático, é o conjunto de saídas testadas e descartadas:

• Esperar não ajuda. Nos dias amostrados, a concordância ficou em 0,805 contra 0,800, resultado replicado por mais cinco dias.
• Trocar de provedor não ajuda. Quatro provedores compartilham o mesmo piso, com medianas entre 0,74 e 0,88, e nenhum campo de metadados que eles expõem prevê onde cada um cai.
• Hospedar por conta própria ajuda apenas parcialmente. Com núcleos invariantes a lote, funcionou enquanto o servidor estava ocioso. Sob carga, o problema retorna.
• Trocar a métrica ou aumentar a amostragem não repara. Nenhuma das duas alternativas resolveu na grade testada.

Sobre erros construídos com lacunas conhecidas, a separação produzida pelo instrumento acompanha o tipo do erro, não o seu tamanho, o que é um problema sério para qualquer uso do juiz como medida ordinal de qualidade.

O que os autores propõem

O artigo não para no diagnóstico. Ele condensa as evidências em uma escada de três níveis de identidade de instantâneo, oito regras de projeto e uma lista de verificação para relato. Entre as regras:

• Fixe o instantâneo antes de confiar em qualquer portão de estabilidade. A preferência é por pesos abertos auto-hospedados; depois, instantâneos fixados pelo provedor; e só então endpoints compartilhados, nesse caso apenas com portões sobre leituras agregadas.
• Nenhum portão se congela sobre uma grandeza nunca medida. As duas campanhas morreram em portões fixados sobre quantidades que ninguém havia pilotado antes.
• Condicione portões de ordenação a pares informativos, evitando comparar candidatos indistinguíveis.
• Prefira leituras contínuas com faixas de equivalência a ordenações por permutação exata, que amplificam pequenas perturbações.
• Coloque a agregação dentro da definição da medida, e não como pós-processamento.
• Falhe fechado: uma proteção que não consegue interpretar a saída deve recusá-la, não adivinhar.

O achado mais acionável talvez seja este: segundo os autores, um piloto com aproximadamente 2% do volume de chamadas do estudo teria exposto antecipadamente os dois portões inalcançáveis. O custo de validar o instrumento antes de congelar critérios é pequeno diante do custo de perder duas campanhas inteiras.

Os limites do que foi demonstrado

O artigo dedica uma seção inteira a delimitar suas próprias afirmações, e reproduzi-la é importante para não superinterpretar o resultado.

Nenhum dos achados diz respeito a estados internos, representações ou dinâmica semântica dos modelos observados. Todas as grandezas são operacionalizações de medição externa sobre registros visíveis. O trabalho também não é avaliação de qualidade de serviço de nenhum provedor nomeado: os comportamentos documentados são consistentes com propriedades de engenharia públicas de serviços de inferência compartilhada, especificamente o agrupamento dinâmico em lotes sem núcleos invariantes.

E, sobretudo, os autores afirmam explicitamente que não concluem que a avaliação com juízes LLM seja inutilizável. A conclusão é outra: instrumentos desse tipo têm pisos de ruído mensuráveis, distribuições de lacuna e fronteiras de auditabilidade, e isso precisa ser medido antes de qualquer critério ser congelado.

Duas limitações adicionais valem menção. A grandeza medida foi definida pelos próprios pesquisadores, o que restringe a generalização direta para outros desenhos de avaliação. E o artigo é uma pré-publicação, sem revisão por pares até o momento.

Por que isso importa fora do laboratório

O resultado toca uma prática hoje generalizada. Rankings de modelos, comparações entre versões, seleção de dados de treinamento e boa parte das tabelas de benchmark que circulam na imprensa técnica, incluindo as que este portal publica, dependem em algum ponto da cadeia de avaliação automatizada rodando sobre endpoints compartilhados.

Se a mesma requisição, enviada ao mesmo nome de modelo, produz ordenações diferentes em 22% das reexecuções, diferenças pequenas entre modelos concorrentes podem não ser distinguíveis do ruído do instrumento. Isso não invalida comparações com margens largas; torna suspeitas as disputas decididas por frações de ponto percentual.

O tema conversa com uma discussão que o Plugged Ninja já abordou em agosto, quando um estudo mostrou que o ranking de LLMs muda conforme o limite de tokens concedido. Os mecanismos são diferentes — lá, orçamento de computação; aqui, não determinismo da infraestrutura de servimento —, mas o efeito prático converge: a posição de um modelo em uma tabela depende de condições de medição que raramente são reportadas.

Para quem avalia modelos profissionalmente, a recomendação que emerge do artigo é direta: medir o instrumento antes de usar o instrumento, rodar um piloto pequeno antes de congelar limiares, e desconfiar de qualquer diferença menor que o piso de ruído que ninguém calculou.

Fontes e referências

• arXiv — Clean Engineering, Unstable Measurement: A Preregistered Reliability Failure of Black-Box LLM Observers on Shared Endpoints, de Haoyuan Zhu e Jie Zhang, arXiv:2609.04198v1 [cs.AI], 3 de setembro de 2026
• arXiv — Versão HTML completa do artigo, seções 4 a 11, das quais foram extraídos os números citados
• DOI — 10.48550/arXiv.2609.04198