Como se mede do que um modelo de IA é capaz?

Avaliar um modelo é rodá-lo sobre um conjunto fixo de tarefas com resposta conhecida e contar quantas ele acerta. O número que sai depende de quatro coisas: quais tarefas, como o prompt foi montado, quem corrige e como se agrega. Trocar qualquer uma delas muda o placar sem que o modelo tenha mudado.

Essa fragilidade não é defeito de execução, é a natureza da coisa. Medir capacidade de um sistema que aceita qualquer entrada em linguagem natural exige escolher uma amostra minúscula do que ele pode fazer e torcer para que ela represente o resto. Como um benchmark é construído é a pergunta que decide se essa aposta tem chance.

Este texto é o mapa do assunto. As quatro famílias de avaliação, o percurso de uma pontuação da pergunta até a linha da tabela e as armadilhas que fazem benchmarks enganarem mesmo quando ninguém age de má-fé. O que cada placar específico mede fica em MMLU, GPQA e SWE-bench explicados.

As quatro famílias

A divisão que importa não é por assunto. É por quem decide se a resposta está certa, porque isso determina o que o número consegue provar.

Conhecimento usa múltipla escolha com gabarito. O MMLU, de 2020, é o exemplo que definiu o formato: perguntas de 57 áreas, de matemática elementar a direito e ética, coletadas de material de prova real e pensadas para exigir conhecimento de mundo em vez de habilidade linguística¹. Correção é comparação de string, o que torna a família barata de rodar e fácil de contaminar.

Raciocínio também tem gabarito, mas exige uma cadeia de passos até chegar nele. O GPQA levou isso ao extremo em 2023: 448 questões de biologia, física e química escritas por doutorandos e doutores, em que especialistas da área acertam 65% e validadores não especialistas com acesso livre à web acertam 34% depois de mais de meia hora por questão. O melhor sistema baseado em GPT-4 da época chegou a 39%². O desenho existe justamente para que buscar na internet não resolva.

Agêntica troca o gabarito por um verificador. O SWE-bench, também de 2023, dá ao modelo um repositório e a descrição de um problema real e pede o patch; a correção é rodar a suíte de testes. São 2.294 problemas tirados de issues e pull requests de 12 projetos Python populares, e no lançamento o melhor modelo resolvia 1,96% deles³. Essa família é a mais cara de rodar e a mais difícil de falsificar: teste não passa por acidente.

Preferência não tem resposta certa. Dois modelos respondem à mesma pergunta, alguém escolhe a melhor, e um sistema de rating converte as escolhas em ranking. A Arena publicou o método em 2024 com mais de 240 mil votos coletados⁴. Mede o que agrada, que é uma informação real e não é a mesma coisa que estar correto.

O caminho de uma pontuação

Um número de benchmark parece um fato e é o resultado de quatro decisões encadeadas. Vale percorrer as quatro, porque cada uma tem um modo de falha documentado.

A pergunta pode já estar no treino

Contaminação é o problema mais conhecido e o mais mal resolvido. A defesa habitual é remover do corpus de treino qualquer trecho que coincida com o teste, por sobreposição de n-gramas. Um trabalho de 2023 mostrou que isso não basta: variações simples do teste, como paráfrase ou tradução, atravessam esses filtros, e um modelo de 13 bilhões de parâmetros treinado sobre elas atinge desempenho comparável ao do GPT-4 no benchmark contaminado. Os autores aplicaram uma detecção mais forte a conjuntos de pré-treino conhecidos e encontraram de 8% a 18% do HumanEval sobrepostos no RedPajama-Data-1T e no StarCoder-Data⁵.

O experimento mais elegante sobre o tamanho do efeito veio em 2024. Um grupo encomendou mil problemas novos no mesmo estilo e dificuldade do GSM8K, o benchmark de aritmética escolar, cuidando para igualar taxa de acerto humano, número de passos e magnitude das respostas. Modelos de várias famílias caíram até 8 pontos ao trocar o teste conhecido pelo teste novo, e a queda se correlacionou com a probabilidade de o modelo gerar exemplos do GSM8K de memória. A parte honesta do resultado: muitos modelos, especialmente os de fronteira, mostraram pouco sinal de sobreajuste⁶. Contaminação é real e não explica tudo.

A resposta muda com a forma de perguntar

Aqui está o fator que mais atrapalha comparação pública e menos aparece em material de divulgação. O mesmo modelo, no mesmo benchmark, produz notas diferentes conforme o prompt é montado, quantos exemplos vão junto, se a resposta é escolhida comparando probabilidades entre alternativas ou gerada como texto livre, e qual regra extrai a resposta do texto gerado.

A equipe que mantém um dos harness mais usados publicou em 2024 um apanhado de três anos de experiência com exatamente isso: sensibilidade do modelo ao arranjo da avaliação, dificuldade de comparar entre métodos e falta de reprodutibilidade e transparência, com casos concretos de onde a ausência de boa prática distorceu resultados⁷. A recomendação prática que sai dali é chata e eficaz: publique a configuração junto com o número, ou não publique o número.

O eval harness é o pedaço de software que toma essas decisões e não aparece na tabela.

A correção pode estar errada

O gabarito é escrito por gente, e gente erra. Um trabalho de 2024 anotou manualmente 5.700 questões dos 57 assuntos do MMLU e estimou que 6,49% do benchmark contém erro de gabarito. A concentração é o dado que assusta: no subconjunto de virologia, 57% das questões analisadas tinham problema. Ao recomputar as notas sobre a versão corrigida, as diferenças em relação ao reportado originalmente foram significativas⁸.

Isso tem uma implicação desconfortável. Quando um modelo está a poucos pontos do teto de um benchmark, parte da distância que falta é composta de questões cuja resposta “certa” está errada. Otimizar contra esse resto premia reproduzir o erro do anotador.

O número sai sem margem

A última etapa é agregação, e é onde se perde a informação mais útil. Um placar de 87,3% sobre 448 questões carrega uma incerteza amostral que raramente é publicada. Um artigo de 2024 tratou avaliações como o que elas são, experimentos, e mostrou como calcular a variância de uma medida, como comparar dois modelos levando em conta que eles responderam às mesmas perguntas e como dimensionar quantas questões são necessárias para detectar uma diferença de tamanho dado⁹.

A consequência prática cabe em uma frase: diferença de um ponto entre dois modelos em um benchmark de algumas centenas de questões costuma ser ruído, e é exatamente esse tipo de diferença que vira manchete.

Preferência humana mede outra coisa

A avaliação por comparação resolve o problema do gabarito ao custo de trocar “correto” por “preferido”. A Arena documentou o método em 2024 e mostrou que os votos da multidão concordam bem com avaliadores especialistas nas perguntas coletadas⁴. Uma variante automatiza o juiz: um modelo forte compara as duas respostas em vez de uma pessoa, o que barateia a operação e introduz os vieses do juiz, como preferir respostas longas ou a que aparece primeiro¹⁰.

Em 2025 apareceu a crítica estrutural. Um trabalho analisou as práticas da Arena e identificou que testes privados não divulgados beneficiam alguns fornecedores, que podem avaliar várias variantes antes do lançamento público e escolher qual pontuação divulgar. Os autores identificaram 27 variantes privadas testadas por um único fornecedor antes de um lançamento, e estimaram que dois fornecedores receberam cerca de 19,2% e 20,4% de todos os dados da plataforma, enquanto 83 modelos de peso aberto somados ficaram com 29,7%¹¹. O efeito descrito é sobreajuste à dinâmica da arena, não qualidade geral.

Nada disso torna o ranking inútil. Torna-o um sinal com viés conhecido, que é uma coisa que se usa com cuidado e não uma coisa que se cita como veredito.

O mapa do assunto

Construir decide de onde vêm as perguntas, quem escreve o gabarito e como se tenta manter o teste fora do treino. É a etapa que define o teto de qualidade de tudo que vem depois.

Executar é o harness, o formato do prompt e quantas amostras por questão. Barata de fazer certo e responsável pela maior parte das discrepâncias entre números publicados.

Interpretar inclui barra de erro, comparação entre versões e o caso especial dos benchmarks de contexto longo, em que a diferença entre janela anunciada e janela útil só aparece se o teste for desenhado para isso.

Armadilhas é a categoria que não some com boa engenharia, porque é feita de incentivo: treinar para o teste, saturação de benchmark, e a seleção que acontece quando quem publica o número também escolhe qual número publicar. O ranking por preferência é onde essa dinâmica está melhor documentada.

O ciclo de vida de um benchmark

Todo benchmark segue o mesmo arco, e reconhecê-lo ajuda a ler qualquer placar pela data. Ele nasce difícil, com os melhores modelos no chão. Vira alvo de otimização. Sobe rápido, em parte por capacidade real e em parte por contaminação. Satura acima de 90%. E é aposentado, substituído por outro mais difícil, enquanto continua aparecendo em material de marketing por mais um ano.

O SWE-bench ilustra a primeira metade do arco: 1,96% no lançamento em 2023³, e dois anos depois já era o teste que todo laboratório citava. O MMLU ilustra a segunda: em 2025, um grupo lançou um benchmark novo argumentando explicitamente que os testes populares não estavam acompanhando a dificuldade, já que os modelos passavam de 90% no MMLU, e montou 2.500 questões de fronteira do conhecimento escritas por especialistas de dezenas de áreas para voltar a ter sinal¹².

A consequência para quem lê é direta. Um placar alto em benchmark maduro informa pouco, porque todo mundo está alto. Um placar em benchmark recém-lançado informa mais, e é menos comparável, porque ainda não há histórico. Nenhum dos dois substitui medir o seu caso.

Onde falha

Benchmark satura e para de informar. Quando os modelos de topo passam de 90%, o que resta a medir é o resíduo, que é feito de questões ambíguas e de erro de gabarito. A partir daí o placar separa modelos pelo motivo errado.

A média esconde a distribuição. Um modelo com 80% pode acertar tudo em 56 dos 57 assuntos do MMLU e zerar em um. Para a sua aplicação, que provavelmente vive em um assunto só, esses dois modelos de 80% não são intercambiáveis.

Capacidade média não prevê o seu caso. Essa é a falha mais cara na prática. O benchmark mede tarefa curta, entrada limpa e critério fixo; a sua aplicação tem entrada suja, contexto próprio e critério que ninguém escreveu ainda.

O que não é medido some. Latência, custo por chamada, estabilidade de formato, comportamento em entrada adversarial e taxa de recusa raramente entram no placar, e decidem se o sistema entra em produção.

Como avaliar o seu caso

1. Escreva de 30 a 50 casos reais antes de olhar qualquer placar. Entrada de verdade, saída esperada de verdade. É o único instrumento que responde à sua pergunta.
2. Defina a regra de correção antes de rodar. Se você não consegue escrever o que conta como acerto, o número que sair não vai significar nada.
3. Rode cada caso mais de uma vez. Com temperatura acima de zero a resposta varia, e uma única execução mede a sorte junto com a capacidade.
4. Calcule a margem antes de decidir. Em 40 casos, uma diferença de dois acertos entre dois modelos não é diferença.
5. Meça o que o benchmark público ignora. Custo por chamada, tempo até a primeira resposta e taxa de saída malformada, na mesma planilha da acurácia.
6. Congele o conjunto e a configuração. Mudar os casos e o modelo na mesma semana torna impossível saber o que causou a mudança no número.

Quanto custa

Em ordem de grandeza: um conjunto de 50 casos, rodado três vezes em três modelos, são 450 chamadas. Com prompts de alguns milhares de tokens, isso custa alguns dólares e roda em minutos. O custo real é humano, e está em escrever as saídas esperadas e revisar as discordâncias: contar algumas horas de trabalho de quem conhece o domínio é mais realista do que contar tokens.

Avaliação agêntica muda a conta. Cada caso pode envolver dezenas de chamadas, execução de código em ambiente isolado e minutos de relógio, o que coloca uma rodada completa na casa das dezenas ou centenas de dólares. É a razão pela qual essa família é rodada com menos frequência, e a razão pela qual vale automatizar a execução antes de aumentar o número de casos.

Footnotes

1. Hendrycks et al. (2020) construíram um teste de múltipla escolha cobrindo 57 assuntos, de matemática elementar a direito e ética, desenhado para exigir conhecimento de mundo em vez de habilidade linguística. ↩

2. Rein et al. (2023) escreveram 448 questões de biologia, física e química validadas por especialistas: 65% de acerto entre quem tem ou está fazendo doutorado na área, 34% entre validadores não especialistas com acesso livre à web, e 39% para o melhor sistema baseado em GPT-4 da época. ↩

3. Jimenez et al. (2023) montaram 2.294 problemas a partir de issues e pull requests reais de 12 repositórios Python, corrigidos pela execução da suíte de testes. No lançamento, o melhor modelo resolvia 1,96%. ↩ ↩²

4. Chiang et al. (2024) descreveram a plataforma de comparação par a par com mais de 240 mil votos coletados, e verificaram que os votos da multidão concordam com avaliadores especialistas. ↩ ↩²

5. Yang et al. (2023) mostraram que paráfrase e tradução do teste atravessam filtros de descontaminação por sobreposição de texto, e encontraram de 8% a 18% do HumanEval sobrepostos em conjuntos de pré-treino públicos. ↩

6. Zhang et al. (2024) encomendaram mil problemas novos no estilo do GSM8K e mediram quedas de até 8 pontos, correlacionadas com a probabilidade de o modelo gerar exemplos do benchmark original de memória. ↩

7. Biderman et al. (2024) documentaram, a partir de três anos mantendo um harness de avaliação, a sensibilidade dos modelos ao arranjo do teste e a falta de reprodutibilidade entre implementações. ↩

8. Gema et al. (2024) reanotaram manualmente 5.700 questões dos 57 assuntos do MMLU, estimaram 6,49% de erro de gabarito no benchmark inteiro e 57% no subconjunto de virologia analisado. ↩

9. Miller (2024) tratou avaliações como experimentos estatísticos e derivou fórmulas para variância, comparação entre dois modelos sobre as mesmas questões e dimensionamento do número de questões. ↩

10. Zheng et al. (2023) mediram a concordância entre juízes automáticos e preferência humana, e catalogaram os vieses do juiz, entre eles a preferência por respostas longas e pela posição. ↩

11. Singh et al. (2025) identificaram testes privados não divulgados na Arena, incluindo 27 variantes testadas por um único fornecedor antes de um lançamento, e assimetria de acesso a dados entre fornecedores fechados e modelos de peso aberto. ↩

12. Phan et al. (2025) montaram 2.500 questões escritas por especialistas de dezenas de áreas, argumentando que os benchmarks populares pararam de informar quando os modelos passaram de 90% em testes como o MMLU. ↩