Como ler um benchmark de LLM sem cair no marketing?

Fala aí, beleza? A tabela de lançamento é a peça de marketing mais técnica que existe, e quase todo mundo lê só a coluna em negrito 😛

Todo modelo novo chega com aquela grade de porcentagens, cheia de siglas, com o número do lançamento sempre um pouquinho acima dos concorrentes

Só que sem saber o que cada teste mede e em que condições ele foi rodado, colocar dois números lado a lado engana MUITO mais do que ajuda

Então bora destrinchar isso: o que cada família de benchmark de LLM realmente mede, quais armadilhas distorcem a comparação e um roteiro pra tu ler a próxima tabela sem cair no papo de vendedor 🙂

O que cada tipo de benchmark de LLM realmente mede?

Antes de olhar qualquer número, vale entender que benchmark não é tudo igual

Tem teste de conhecimento, teste de raciocínio, teste de código e teste de agente usando ferramentas, e cada um responde uma pergunta diferente sobre o modelo

Conhecimento geral: MMLU e MMLU-Pro

Esses testes medem se o modelo sabe coisa, tipo uma prova de vestibular gigante

O problema é que o MMLU já não separa os modelos de ponta, e o MMLU-Pro surgiu justamente pra deixar a prova mais difícil, com 10 alternativas no lugar de 4

Pra quem usa o modelo no dia a dia, isso diz pouco sobre como ele vai se sair resolvendo um problema seu

Raciocínio difícil: GPQA Diamond e Humanity’s Last Exam

Aqui a ideia é ver se o modelo raciocina em cima de questões que nem uma busca no Google resolve

No GPQA Diamond, um especialista humano acerta em média cerca de 65%, então é um teste que ainda tem régua humana pra comparar

O HLE nasceu porque os testes populares ficaram fáceis demais, e é o tipo de número que importa se tu precisa de raciocínio técnico ou científico pesado

Código: SWE-bench Verified, SWE-bench Pro e LiveCodeBench

Se você programa ou faz vibe coding, essa é a família que mais te interessa

Porém é também a que mais sofre com contaminação, por isso o detalhe de cada teste (código privado no SWE-bench Pro, data de publicação no LiveCodeBench) pesa tanto quanto a nota

Agentes e ferramentas: τ-bench e Terminal-Bench 2.0

Aqui não basta responder certo: o modelo precisa agir, chamar ferramenta, seguir regra e chegar no estado final esperado

É o teste mais próximo de colocar uma IA pra trabalhar sozinha num fluxo real, tipo atendimento ou automação no terminal

As armadilhas que distorcem a comparação entre modelos:

Saber o que o teste mede é metade do caminho

A outra metade é perceber quando o número está distorcido, e o mesmo raciocínio vale quando você vai comparar modelo aberto com fechado

Por que todo modelo empata no MMLU?

Sintoma: os modelos novos aparecem todos colados perto do teto, separados por 1 ou 2 pontos

Causa: o MMLU saturou em meados de 2024, com os modelos de fronteira entre 88% e 92%, e estima-se que cerca de 6,5% das questões tenham erro (enunciado ambíguo, mais de uma resposta certa ou gabarito errado)

Com um gabarito desses, brigar por 1 ponto não diz muita coisa né?

Solução: olhe testes que ainda separam os modelos, como MMLU-Pro, GPQA Diamond e Humanity’s Last Exam

Como prevenir: antes de se impressionar com um número alto, pergunte se aquele teste ainda tem espaço pra diferenciar alguém

O que é contaminação de dados em benchmark de LLM?

Sintoma: o modelo tira nota altíssima no benchmark e essa performance não se repete no uso real

Causa: as questões são públicas e acabam vazando pro material de treino, aí o modelo meio que decora a prova 😅

O caso mais escancarado é o do SWE-bench Verified: segundo a auditoria da OpenAI, 59,4% dos problemas auditados têm testes que rejeitam soluções funcionalmente corretas, e modelos de fronteira conseguiam reproduzir de forma literal o patch de referência de algumas tarefas

Resultado: a OpenAI parou de reportar o SWE-bench Verified e passou a recomendar o SWE-bench Pro

Solução: prefira testes com código privado (SWE-bench Pro) ou recortados por data, como o LiveCodeBench filtrado pra problemas publicados depois do corte de treino do modelo

Como prevenir: desconfie de benchmark antigo e público em que todo mundo tira nota absurda

Por que o mesmo modelo tem dois números no mesmo benchmark?

Sintoma: você vê duas notas diferentes pro mesmo modelo, no mesmo teste

Causa: configuração diferente de prompt e de computação

Se liga nesse exemplo real: no anúncio do Claude 4, a Anthropic publicou dois números de SWE-bench pra cada modelo

• Claude Opus 4: 72,5% e 79,4% usando parallel test-time compute
• Claude Sonnet 4: 72,7% e 80,2% usando parallel test-time compute

Não tem nada escondido aí, a configuração está informada

O problema é quando alguém pega o número turbinado de um modelo e compara com o número padrão de outro

Solução: leia as notas de rodapé e compare só números rodados na mesma configuração, ou use um avaliador independente que roda tudo igual pra todo mundo

A Artificial Analysis faz isso: roda os benchmarks com implementação própria, usa os mesmos prompts (zero-shot, em inglês) pra todos os modelos e publica a metodologia

Como prevenir: sem nota de rodapé, trate o número como incompleto

A versão no ranking é a mesma que foi lançada?

Sintoma: o modelo brilha no ranking e decepciona quando você usa

Causa: a versão testada não é a versão que chegou pra você

Foi o que aconteceu com o Llama 4 Maverick: a Meta colocou no LMArena (o nome que a plataforma tinha na época, hoje ela se chama Arena) uma versão experimental otimizada pra conversa, diferente do modelo aberto lançado

A experimental chegou ao 2º lugar, e a versão lançada sem modificações ficou em 32º

Solução: confira se o nome do modelo no ranking bate exatamente com o que você vai rodar

Como prevenir: palavras como experimental, preview ou variante no nome são sinal amarelo

Como um ranking pode mostrar só a melhor variante?

Sintoma: um provedor aparece sempre no topo logo no lançamento

Causa: o provedor testa várias variantes em privado e só mostra a que foi melhor, então o placar público vira a vitrine da melhor tentativa

O paper The Leaderboard Illusion (NeurIPS 2025) mostrou que alguns provedores testam várias variantes privadas no Chatbot Arena antes do lançamento e só divulgam a melhor

Num caso extremo, um provedor testou 27 variantes privadas

É tipo fazer a prova 27 vezes e entregar só a de nota maior haha

Detalhe: o LMArena mudou de nome pra Arena em 28 de janeiro de 2026 e hoje fica em arena.ai

Solução: use o ranking de preferência como um sinal entre vários, nunca como prova única

Como prevenir: quanto mais o resultado depende de um único placar, mais cético você precisa ser

Acertar uma vez significa que o agente é confiável?

Sintoma: o agente resolve a tarefa na demo e falha quando você repete

Causa: a métrica conta acerto em uma tentativa, não consistência

O τ-bench propôs a métrica pass^k, que mede a probabilidade de o agente acertar a mesma tarefa em TODAS as k tentativas

No lançamento, agentes baseados em GPT-4 resolveram menos de 50% das tarefas, e cerca de 25% quando a mesma tarefa era repetida 8 vezes

Ou seja: acertar uma vez é muiiito diferente de acertar sempre

Solução: pra agentes, procure números de consistência, não só de acerto único

Como prevenir: se o agente vai rodar sozinho em produção, pergunte quantas vezes seguidas ele acerta

Roteiro para interpretar uma tabela de lançamento de LLM:

Beleza, agora junta tudo num checklist que dá pra aplicar em qualquer anúncio, tipo a tabela de resultados do GPT-6 Astra ou a do próximo modelo que sair semana que vem 😀

1. Identifique a família de cada linha da tabela: conhecimento, raciocínio, código ou agente

O erro comum deste passo: somar tudo numa impressão geral de que o modelo é melhor em tudo

2. Risque os testes saturados ou com ressalva conhecida: MMLU e SWE-bench Verified entram aqui

O erro comum deste passo: se impressionar com 90% no MMLU

3. Leia as notas de rodapé sobre configuração: parallel test-time compute, número de tentativas, uso de ferramentas

O erro comum deste passo: comparar o número turbinado de um modelo com o número padrão de outro

4. Verifique se o modelo comparado é o mesmo que você vai usar: nome, versão, se é experimental ou não

O erro comum deste passo: confiar em ranking de variante experimental

5. Procure sinal de contaminação e prefira testes resistentes: SWE-bench Pro, com código privado, e LiveCodeBench filtrado por data

O erro comum deste passo: tratar nota alta em teste público e antigo como prova de capacidade real

6. Pra agentes, olhe consistência: pass^k diz mais do que acerto único

O erro comum deste passo: escolher o agente pela melhor tentativa, não pela média de comportamento

7. Cruze com uma fonte independente: o Artificial Analysis Intelligence Index v4.1 junta 9 avaliações (GDPval-AA v2, τ³-Banking, Terminal-Bench v2.1, SciCode, Humanity’s Last Exam, GPQA Diamond, CritPt, AA-Omniscience e AA-LCR)

Se liga: o Terminal-Bench do índice é a v2.1, não a 2.0 da tabela lá de cima, e o τ³-Banking aparece com nome próprio, então não trate ele como o mesmo τ-bench de companhia aérea e varejo que a gente viu antes

O erro comum deste passo: tratar o índice como verdade única em vez de mais um sinal

Qual benchmark olhar para cada uso?

Não precisa decorar tudo, olha só o que importa pro teu caso:

• Pra programar e fazer vibe coding: SWE-bench Pro, LiveCodeBench e Terminal-Bench 2.0
• Pra montar agentes com ferramentas e atendimento: τ-bench (de olho no pass^k) e Terminal-Bench 2.0
• Pra raciocínio técnico ou científico: GPQA Diamond e Humanity’s Last Exam
• Pra preferência em conversa: Arena, sempre lembrando das ressalvas de variantes privadas e versão experimental

E o mais importante: nenhum número substitui testar o modelo na SUA tarefa

O benchmark te diz onde procurar, quem decide é o teu uso real

Teste o modelo no seu próprio código:

A melhor forma de complementar qualquer tabela é colocar a IA pra trabalhar num projeto de verdade

Pra ver isso na prática, este vídeo do canal mostra uma skill que faz a IA ler seu código e desenhar a arquitetura sozinha, o tipo de tarefa real que te mostra rapidinho se o modelo dá conta do recado 🙂

Benchmark é ponto de partida, não veredito:

O número sozinho não vale nada

Ele só faz sentido com contexto: o que o teste mede, em que configuração rodou, se está saturado ou contaminado e se o modelo testado é o mesmo que foi lançado

Então o próximo passo é simples: na próxima tabela de lançamento, aplica o roteiro, risca o que não presta e depois roda o modelo numa tarefa real do teu dia a dia antes de trocar de ferramenta

Assim você para de escolher modelo pela coluna em negrito e passa a escolher pelo que ele entrega pra você 😀

Espero que tenha curtido, até o próximo post!