
Dois scores de MMLU: por que o nome do benchmark não basta
Dois scores, um mesmo nome
O post de Dmitrii Zatona parte de um par concreto: dois registros de avaliação reportam acurácia em MMLU de 0,781 (build 42) e 0,79 (build 44) para duas versões da mesma família de modelo, com mesmo fornecedor, métrica, unidade e nome de benchmark. A diferença aritmética é +0,009, mas ambos os registros apontam para frames (molduras de procedimento) com hashes diferentes, e um verificador responde "incomparável" a uma consulta de diferença de score. A tese central: o nome do benchmark fixa apenas um rótulo; comparabilidade é propriedade da referência a que os resultados são rastreáveis, não do número.
O que "mmlu" não fixa
O autor lista cinco variáveis abertas sob o mesmo rótulo:
- Split: o artigo original do MMLU reporta 14.079 questões de teste; o dataset
cais/mmludo Hugging Face reporta 14.042 de teste e 285 de desenvolvimento, sem documento revisado que explique a diferença. Um frame pontua emdev(por design, fonte dos exemplos few-shot) e outro emtest-lite, rótulo sem artefato público encontrado. - Implementação: um post do Hugging Face de 2023 mostra três harnesses (HELM, Eleuther, código original) pontuando llama-65b em 0,637, 0,488 e 0,636 - resultados declarados incomparáveis, com inversão de posições no ranking entre llama-65b e falcon-40b.
- Variante de tarefa e shot count: o lm-evaluation-harness define três tarefas MMLU sobre os mesmos dados; "5-shot" é uma flag de linha de comando, não propriedade da tarefa.
- Formato de prompt e posição da resposta: a Anthropic reporta variação de cerca de 5% só com formatação; Zheng et al. mostram queda de gpt-3.5-turbo de 67,2 para 60,9 ao mover respostas corretas para a posição D, e ganho de 15,2 pontos para llama-30b na posição A, invertendo rankings.
- Grader e acesso à rede: frame A usa exact-match-v1, frame B usa llm-judge-v3, um procedimento diferente com viés de posição documentado (consistência de 65,0% para GPT-4, 46,2% para GPT-3.5, 23,8% para Claude-v1). A CAISI descobriu post hoc ter rodado SWE-bench Verified com internet, e o trabalho da Scale sobre contaminação em tempo de busca achou cerca de 3% das questões recuperáveis com rótulos, com queda de ~15 pontos ao bloquear a fonte.
Uma pesquisa de 2026 com 101.843 resultados publicados (5.816 modelos, 635 benchmarks) constatou que 96,5% carecem de ao menos um campo mínimo de reprodutibilidade, e registrou um modelo com 20,9% por um avaliador e 61,8% por outro no MMLU-Pro.
Comparabilidade e metrologia
O autor ancora o argumento no VIM (JCGM 200:2012): comparabilidade metrológica exige rastreabilidade a uma referência comum. Paralelos fora de IA: HbA1c tem dois métodos de referência com unidades separadas (mmol/mol desde 2007), e SLAs de AWS EC2 e Google Compute imprimem "99,99%" sobre mensurandos distintos. Documentos de NIST AI 800-2 e da rede NAAIMES chegam à mesma conclusão sem o vocabulário metrológico.
Frames endereçados por conteúdo
No perfil APL AI-Eval, o frame é um objeto separado endereçado por conteúdo, com hash SHA-256 sobre bytes canônicos RFC 8785. O validador exige runner_id, grader_id, benchmark_id, variant, split e três marcadores de exclusão. Um detalhe: frame A escreve subset: "all", frame B omite a chave - e a igualdade de escopo é decidida por bytes canônicos, não por normalização de padrões; "all" e ausente são escopos diferentes.
O que o verificador retorna
Na crate Rust apl-ai-eval (v0.3.1), cada claim isolado retorna apl-valid - bem-formado e vinculado ao frame, sem dizer nada sobre a correção do score. A consulta score-delta entre os dois retorna incomparable, com diagnósticos de hashes diferentes e ausência de bridge. Um bridge adversarial que assume "todos os resultados MMLU são intercambiáveis" é rejeitado por incompatibilidade de família de aspecto; um bridge válido (mesmo grader, mesmo escopo, só runner diferente) retorna bridged-comparable.
O que não fica provado
O autor ressalva que apl-valid não prova que qualquer score está correto (o MMLU-Redux estima 6,49% de questões erradas no MMLU), não garante que identificadores idênticos nomeiem o mesmo artefato, não identifica datasets por digest, não trata de limiares, incerteza (o perfil v0.1 não tem campo para isso) nem de estabilidade do vocabulário, ainda um rascunho. O que o frame estabelece é mais estreito: vincula um procedimento declarado a uma claim por hash - e, sem bridge aplicável, a subtração não tem resultado definido.