Benchmarks de LLM: entender os rankings (MMLU, Arena, SWE-bench)

#Por que os benchmarks importam (e enganam você)

Um benchmark de LLM é um conjunto de perguntas cujas respostas são conhecidas, que se apresenta a um modelo para contar quantas ele responde corretamente. O resultado é uma pontuação — um percentual, uma classificação Elo, uma taxa de resolução. É a única linguagem comum que permite comparar dois modelos sem testá-los por conta própria durante horas, e por isso todo mundo o usa.

O problema não é o princípio, é a diferença entre o que a pontuação diz e o que você interpreta a partir dela. Um modelo que mostra 90% no MMLU não é “90% inteligente”: ele responde corretamente a 90% das questões de uma prova de múltipla escolha sobre conhecimentos acadêmicos. Isso não diz nada sobre sua capacidade de seguir suas instruções, de escrever francês correto, de não inventar informações na sua área ou de manter uma conversa de dez rodadas. Um benchmark mede uma competência específica em condições de laboratório.

É possível classificar os benchmarks em três grandes famílias, que medem coisas diferentes e não são manipulados da mesma forma: os benchmarks acadêmicos (questões de múltipla escolha sobre conhecimento e raciocínio), os benchmarks de tarefas reais (resolver um bug real, usar ferramentas) e as arenas de preferência humana (humanos votam na melhor resposta). Vamos examiná-los nessa ordem.

#Os benchmarks acadêmicos: MMLU, GPQA, MATH

É a família histórica, aquela das tabelas de pontuação que vemos nas páginas de lançamento dos modelos. São conjuntos de perguntas com respostas verificáveis, muitas vezes de múltipla escolha, avaliadas automaticamente. Seu ponto forte é a reprodutibilidade; seu ponto fraco é que são fáceis de saturar e contaminar.

MMLU

Massive Multitask Language Understanding: ~14.000 questões de múltipla escolha distribuídas em 57 disciplinas (direito, medicina, história, matemática…). O benchmark de conhecimento mais citado. Hoje, já está amplamente saturado: os bons modelos ultrapassam 88–90%, e a diferença entre eles fica dentro do ruído das medições.

MMLU-Pro

Versão mais difícil do MMLU: 10 opções em vez de 4, perguntas selecionadas novamente para serem mais difíceis, mais raciocínio. Criada especificamente porque o MMLU já não diferenciava os modelos de ponta.

GPQA (Diamond)

« Google-Proof Q&A »: perguntas de nível de doutorado em biologia, física e química, elaboradas para que uma pesquisa no Google não seja suficiente. O subconjunto « Diamond » é o mais difícil. Bom indicador do raciocínio científico de ponta.

MATH / AIME

Problemas de matemática (MATH: nível de ensino médio/concurso; AIME: olimpíadas americanas). Resposta numérica única, portanto fácil de avaliar. Tornou-se um indicador de modelos 'com raciocínio' (reasoning) que refletem em várias etapas.

IFEval

Mede a capacidade de SEGUIR instruções verificáveis (« responda com exatamente 3 itens em uma lista com marcadores », « não use a letra e »). Muitas vezes, é mais revelador para o uso real do que um questionário de múltipla escolha sobre conhecimentos.

HLE (Humanity's Last Exam)

Benchmark recente e deliberadamente extremo: perguntas especializadas de várias áreas, elaboradas para continuarem difíceis por muito tempo. Os melhores modelos ainda obtêm pontuações baixas nele, o que faz desse benchmark uma boa ferramenta para diferenciar os modelos em 2026.

#Benchmarks de tarefas reais: SWE-bench e agentes

Essa família é mais recente e muito mais difícil de enganar, porque não faz perguntas: pede que se execute uma tarefa completa cujo resultado pode ser verificado objetivamente. Resolver um ticket real do GitHub, fazer uma suíte de testes passar, navegar em um repositório de código. Falamos disso em detalhes no nosso guia dedicado aos benchmarks de código; aqui está o essencial.

SWE-bench Verified

Um subconjunto de 500 problemas reais do GitHub (issues + patch esperado) validados manualmente pela OpenAI como solucionáveis e bem especificados. O modelo deve produzir um patch que faça os testes do repositório passarem. Isso se tornou O padrão para código em condições reais, muito mais significativo que o HumanEval (hoje saturado em 96-98 %).

SWE-bench (full / Lite)

A versão completa (~2.300 tarefas) e uma versão reduzida para iterar rapidamente. As pontuações publicadas dependem enormemente do « harness » (o agente que orquestra o modelo): um mesmo modelo pode ganhar 15 pontos dependendo do conjunto de ferramentas usado com ele.

Tau-bench / benchmarks de agentes

Benchmarks de agentes que usam ferramentas (chamadas de funções, APIs, cumprimento de regras de negócio) ao longo de vários turnos. Medem a confiabilidade no uso como "assistente que age", não apenas que responde.

LiveCodeBench

Problemas de programação competitiva coletados continuamente, com data de publicação. É possível avaliar apenas os problemas posteriores à data de treinamento de um modelo — um antídoto direto contra a contaminação.

#LMArena: o ranking por preferência humana

LMArena (a antiga “Chatbot Arena” do LMSYS) funciona de forma diferente: dois modelos anônimos respondem à mesma pergunta feita por um usuário real, que vota na melhor resposta. A partir de milhões de duelos, calcula-se uma pontuação Elo (o mesmo sistema usado no xadrez). É o benchmark que mais se aproxima da pergunta “qual modelo as pessoas realmente preferem?”.

O que mede bem

Qualidade percebida em conversa aberta: tom, estrutura, utilidade global, capacidade de fornecer uma resposta agradável. Isso está fortemente correlacionado com a satisfação no uso real.

O que mede mal

A precisão factual. Os votantes muitas vezes recompensam respostas longas, bem formatadas e confiantes — mesmo quando estão erradas. Um modelo « bajulador » pode subir no ranking sem ser mais preciso.

Elo não é um percentual

Uma diferença de 10 a 20 pontos Elo é ruído estatístico. Sempre verifique o intervalo de confiança exibido: dois modelos podem estar 'empatados' mesmo que não estejam na mesma linha da tabela.

Rankings por categoria

A LMArena oferece categorias (código, matemática, respostas longas, estilo controlado). O ranking específico de “hard prompts” ou “style control” costuma ser mais informativo do que o ranking geral, que mistura tudo.

#A armadilha nº1: a contaminação de dados

A contaminação ocorre quando as perguntas de um benchmark (ou suas respostas) acabam, intencionalmente ou não, nos dados de treinamento do modelo. O modelo então deixa de raciocinar: ele recita. Os benchmarks públicos circulam na web, no GitHub, no Hugging Face — acabam inevitavelmente nos corpora de pré-treinamento. Resultado: uma pontuação inflada que não prevê nada sobre perguntas inéditas.

É o calcanhar de Aquiles de todos os benchmarks estáticos e públicos. Quanto mais antigo e famoso for um benchmark, maior o risco. Alguns sinais de alerta:

Diferença entre versões

Um modelo que brilha no MMLU mas desmorona no MMLU-Pro (mesmas disciplinas, perguntas novas) indica mais memorização do que compreensão.

Nota anormalmente alta para o tamanho

Um pequeno modelo de 7B que supera modelos de 70B em UM benchmark específico, e apenas nesse: desconfie, pois muitas vezes isso resulta de um treinamento direcionado (« benchmaxxing ») nesse conjunto de testes.

Benchmarks com data definida

As avaliações “live” (LiveCodeBench, perguntas com data e hora registradas) contornam o problema: só se atribui uma pontuação ao que é posterior à data de corte do modelo.

Lapsos de memória suspeitos

Alguns testes injetam variantes-canário (« canary strings ») ou reformulações para detectar a reprodução de conteúdo memorizado. Uma grande diferença entre a pergunta original e a reformulada revela a contaminação.

#A armadilha nº 2: a saturação

Um benchmark está saturado quando os melhores modelos atingem pontuações tão altas que ele não consegue mais diferenciá-los. Quando todos atingem 96-99 %, os 3 pontos restantes são ruído de medição (perguntas ambíguas, erros de etiquetagem), e não uma verdadeira diferença de capacidade. HumanEval (código) e MMLU (conhecimento) são os exemplos canônicos: foram muito úteis, mas não servem mais para diferenciar o topo do ranking.

É por isso que novos benchmarks mais difíceis surgem constantemente: MMLU-Pro substitui o MMLU, GPQA Diamond e HLE passam a ser as referências para raciocínio, e SWE-bench Verified substitui o HumanEval para código. Um benchmark tem uma vida útil; quando o nível médio ultrapassa determinado patamar, você deve retirá-lo dos seus critérios de decisão.

#Ler um leaderboard sem ser enganado

Aqui está o método a aplicar em qualquer tabela de resultados, seja de um comunicado de modelo ou de um ranking público.

1. 01
   Identifique quem publica

   Um gráfico em uma apresentação de modelo é marketing: ele escolhe os benchmarks favoráveis e o protocolo vantajoso (cherry-picking). Um leaderboard externo e neutro (Open LLM Leaderboard, LMArena, a página oficial do SWE-bench) é muito mais confiável do que um slide de lançamento.
2. 02
   Verifique o protocolo

   0-shot ou few-shot? Com chain-of-thought? Com qual ambiente de execução para agentes? Duas pontuações só podem ser comparadas se o método for idêntico. Um asterisco com a indicação “self-reported” (autodeclarado) vale menos que uma pontuação reproduzida por um terceiro.
3. 03
   Verifique os intervalos de confiança

   No LMArena, uma diferença Elo inferior a ~15 pontos é ruído. Nos benchmarks com amostras pequenas (GPQA Diamond, 198 perguntas), algumas respostas corretas fazem a pontuação variar em vários pontos. Um ranking sem margem de erro deve ser considerado com cautela.
4. 04
   Compare vários benchmarks

   Nunca decida com base em um único número. Um modelo sólido tem bom desempenho em um conjunto de testes variados, não apenas em um pico isolado. Um pico isolado e anormal sugere uma otimização direcionada.
5. 05
   Pondere com base no SEU uso

   Você programa? Consulte o SWE-bench e o LiveCodeBench, não o MMLU. Usa francês? Nenhum desses benchmarks está em francês — procure avaliações em francês ou faça seus próprios testes. Usa o modelo para conversar? O LMArena tem prioridade. O melhor modelo “em média” não é necessariamente o melhor para você.

#Avaliar um modelo local em suas próprias tarefas

A conclusão lógica de tudo o que foi dito anteriormente: o benchmark mais confiável para você é o seu próprio. Ele não pode ser contaminado (suas perguntas não estão na web), nunca está saturado (você o calibra com seus casos difíceis) e mede exatamente o que você precisa. Não é necessária uma infraestrutura pesada: cerca de vinte exemplos representativos são suficientes para distinguir dois modelos.

1. 01
   Monte um pequeno conjunto de testes

   Reúna 15 a 30 prompts tirados de seus casos reais de uso (e-mails a serem escritos, extrações, perguntas sobre seus documentos, trechos de código). Para cada um, anote o que uma boa resposta deve conter. Mantenha esse conjunto privado e estável para comparar os modelos ao longo do tempo.
2. 02
   Instale os modelos para comparar

   Com Ollama, baixe os modelos candidatos. Ollama disponibiliza uma API compatível com OpenAI em http://localhost:11434, o que permite automatizar as chamadas.
3. 03
   Automatize as chamadas

   Um pequeno script percorre seus prompts em um loop e grava as respostas de cada modelo lado a lado, em um arquivo, para comparar essas respostas com calma, sem se deixar influenciar pelo nome do modelo.
4. 04
   Avalie às cegas

   Releia as respostas sem saber qual modelo produziu cada uma (misture a ordem). Avalie com base nos seus próprios critérios: exatidão, respeito à instrução, qualidade do francês, ausência de invenções. Essa é a sua “Arena” pessoal.
5. 05
   Meça também o custo real

   A qualidade não é tudo: anote a velocidade (tokens/segundo) e a VRAM consumida. Um modelo de 14B em Q4_K_M (~9 GB) que cabe na sua RTX 4070 e responde rápido pode superar um 70B (~40 GB) teoricamente "melhor", mas inviável para você.

# Récupérer deux candidats via Ollama
ollama pull qwen3:14b
ollama pull gemma3:12b

# Vérifier qu'ils répondent (API locale sur le port 11434)
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:14b",
  "prompt": "Résume ce texte en 3 puces : ...",
  "stream": false
}'

import json, requests

OLLAMA = "http://localhost:11434/api/generate"
MODELES = ["qwen3:14b", "gemma3:12b"]

# Vos prompts réels — la clé d'une éval qui vous ressemble
prompts = [
    "Rédige un mail de relance poli à un client en retard de paiement.",
    "Extrais les dates et montants de ce texte : ...",
    "Explique la différence entre Q4_K_M et Q8_0 en 2 phrases.",
]

def interroger(modele, prompt):
    r = requests.post(OLLAMA, json={
        "model": modele, "prompt": prompt, "stream": False
    }, timeout=120)
    return r.json()["response"].strip()

resultats = []
for p in prompts:
    ligne = {"prompt": p}
    for m in MODELES:
        ligne[m] = interroger(m, p)
    resultats.append(ligne)

# À relire en aveugle, sans regarder la colonne du modèle
with open("comparaison.json", "w", encoding="utf-8") as f:
    json.dump(resultats, f, ensure_ascii=False, indent=2)
print("OK — comparaison.json généré, notez les réponses à froid.")

#Para se aprofundar

Esses guias complementam os conceitos apresentados aqui, no que diz respeito a benchmarks especializados e à escolha concreta de um modelo local:

Benchmarks de código em detalhe

« HumanEval está morto: entender os benchmarks de código LLM em 2026 » explora em profundidade o SWE-bench, o LiveCodeBench e como interpretar as pontuações de código — a continuação direta deste guia na área de desenvolvimento.

Escolher a quantização

« Quantização GGUF em 2026: Q4_K_M vs Q5_K_M vs Q6_K » mostra como medir o impacto real de uma quantização na qualidade — uma avaliação interna aplicada a um caso concreto.

Teste completo do modelo

« Qwen 3 localmente: teste completo e benchmarks reais » ilustra o método de avaliação local (tokens/segundo, qualidade FR, VRAM) em um modelo específico.