Phase 10 - Lesson 10

Avaliação: Benchmarks, Evals, LM Harness

This lesson includes a graded coding exercise that runs in your browser, unlocked with lifetime access.

Lei de Goodhart: quando uma medida se torna uma meta, ela deixa de ser uma boa medida. Todos os laboratórios de fronteira manipulam benchmarks. As pontuações do MMLU sobem enquanto os modelos ainda não conseguem contar com segurança o número de R's em "strawberry". A única avaliação que importa é a SUA avaliação -- na SUA tarefa, com os SEUS dados.

Tipo: Construção Idiomas: Python Pré-requisitos: Fase 10, Lições 01-05 (LLMs do Zero) Tempo: ~90 minutos

Objetivos de Aprendizado

  • Construir um harness de avaliação customizado que execute benchmarks de múltipla escolha e de resposta aberta contra um modelo de linguagem
  • Explicar por que benchmarks padrão (MMLU, HumanEval) saturam e falham em diferenciar modelos de fronteira
  • Implementar evals específicos de tarefas com métricas adequadas: correspondência exata (exact match), F1, BLEU e pontuação com LLM como juiz (LLM-as-judge)
  • Projetar uma suite de avaliação customizada direcionada ao seu caso de uso específico, em vez de depender apenas de tabelas de classificação (leaderboards) públicas

O Problema

O MMLU foi publicado em 2020 com 15.908 perguntas em 57 assuntos. Em três anos, os modelos de fronteira o saturaram. O GPT-4 obteve 86,4%. O Claude 3 Opus obteve 86,8%. O Llama 3 405B obteve 88,6%. A tabela de classificação comprimiu-se em um intervalo de 3 pontos onde as diferenças são ruídos estatísticos, não lacunas reais de capacidade.

Enquanto isso, esses mesmos modelos falham em tarefas que uma criança de 10 anos resolve sem pensar. O Claude 3.5 Sonnet, com pontuação de 88,7% no MMLU, inicialmente não conseguia contar as letras em "strawberry" -- uma tarefa que requer zero conhecimento de mundo e zero raciocínio, apenas iteração em nível de caractere. O HumanEval testa a geração de código com 164 problemas. Os modelos obtêm mais de 90% nele enquanto ainda produzem código que falha em casos extremos (edge cases) que qualquer desenvolvedor júnior detectaria.

A lacuna entre o desempenho em benchmarks e a confiabilidade no mundo real é o problema central da avaliação de LLMs. Os benchmarks informam como um modelo se sai no benchmark. Eles não dizem quase nada sobre como esse modelo se sairá na sua tarefa específica, com seus dados específicos, sob seus modos de falha específicos. Se você está construindo um bot de suporte ao cliente, o MMLU é irrelevante. Se você está construindo um assistente de código, o HumanEval cobre apenas a geração no nível de função -- não diz nada sobre depuração, refatoração ou explicação de código entre arquivos.

Você precisa de evals customizadas. Não porque os benchmarks sejam inúteis -- eles são úteis para uma seleção preliminar de modelos -- mas porque a avaliação final deve corresponder exatamente às suas condições de implantação.

O Conceito

O Cenário de Avaliação

Existem três categorias de avaliação, cada uma com custos e qualidade de sinal diferentes.

Benchmarks são suites de testes padronizadas. MMLU, HumanEval, SWE-bench, MATH, ARC, HellaSwag. Você executa um modelo contra o benchmark e obtém uma pontuação. A vantagem: todos usam o mesmo teste, permitindo comparar modelos. A desvantagem: modelos e dados de treinamento contaminam cada vez mais esses benchmarks. Os laboratórios treinam os modelos em dados que incluem perguntas dos benchmarks. As pontuações sobem. A capacidade real pode não subir.

Evals customizadas são suites de testes que você constrói para o seu caso de uso específico. Você define as entradas, as saídas esperadas e a função de pontuação. Um sumarizador de documentos jurídicos é avaliado em documentos jurídicos. Um gerador de SQL é avaliado no esquema do seu banco de dados. Essas suites são caras para criar, mas são a única avaliação que prevê o desempenho em produção.

Avaliações humanas usam anotadores pagos para julgar as saídas dos modelos com base em critérios como utilidade, correção, fluência e segurança. O padrão-ouro para tarefas abertas onde a pontuação automatizada falha. O Chatbot Arena coletou mais de 2 milhões de votos de preferência humana em mais de 100 modelos. A desvantagem: custo (de $0,10 a

,00 por julgamento) e velocidade (de horas a dias).

graph TD
    subgraph Eval["Panorama de Avaliação"]
        direction LR
        B["Benchmarks\n(MMLU, HumanEval)\nBarato, padronizado\nManipulável, defasado"]
        C["Evals Personalizadas\nSua tarefa, seus dados\nSinal mais alto\nCaro de construir"]
        H["Avaliações Humanas\n(Chatbot Arena)\nPadrão-ouro\nLento, dispendioso"]
    end

    B -->|"seleção preliminar de modelos"| C
    C -->|"casos ambíguos"| H

    style B fill:#1a1a2e,stroke:#ffa500,color:#fff
    style C fill:#1a1a2e,stroke:#51cf66,color:#fff
    style H fill:#1a1a2e,stroke:#e94560,color:#fff

Por Que os Benchmarks Quebram

Três mecanismos fazem com que as pontuações dos benchmarks deixem de refletir a capacidade real.

Contaminação de dados. Os corpora de treinamento coletam dados da internet. As perguntas dos benchmarks estão na internet. Os modelos veem as respostas durante o treinamento. Isso não é trapaça no sentido tradicional -- os laboratórios não incluem intencionalmente os dados dos benchmarks. Mas a coleta em escala web torna a exclusão quase impossível.

Ensinar para a prova (teaching to the test). Os laboratórios otimizam as misturas de treinamento para o desempenho em benchmarks. Se 5% da mistura de treinamento for de múltipla escolha no estilo MMLU, o modelo aprende o formato e a distribuição das respostas. O MMLU tem perguntas de múltipla escolha com 4 opções. Os modelos aprendem que a distribuição das respostas é aproximadamente uniforme entre A/B/C/D, o que ajuda mesmo quando o modelo não sabe a resposta.

Saturação. Quando todo modelo de fronteira atinge entre 85% e 90% em um benchmark, o benchmark deixa de discriminar. Os 10% a 15% restantes das perguntas podem ser ambíguos, rotulados incorretamente ou exigir conhecimento de domínio obscuro. Melhorar de 87% para 89% no MMLU pode significar que o modelo memorizou mais duas perguntas obscuras, não que ficou mais inteligente.

Perplexidade: Um Rápido Teste de Integridade (Health Check)

A perplexidade mede o quão surpreso um modelo fica por uma sequência de tokens. Formalmente, é o logaritmo negativo médio da verossimilhança exponenciado:

PPL = exp(-1/N * sum(log P(token_i | context)))

Uma perplexidade de 10 significa que o modelo está, em média, tão incerto quanto escolher uniformemente entre 10 opções em cada posição de token. Quanto menor, melhor. O GPT-2 obtém uma perplexidade de ~30 no WikiText-103. O GPT-3 obtém ~20. O Llama 3 8B obtém ~7.

A perplexidade é útil para comparar modelos no mesmo conjunto de testes, mas tem pontos cegos. Um modelo pode ter baixa perplexidade ao prever bem padrões comuns, enquanto falha em padrões raros, porém importantes. Ela também não diz nada sobre seguimento de instruções, raciocínio ou precisão factual. Use-a como um teste de integridade, não como um veredito final.

LLM como Juiz (LLM-as-Judge)

Use um modelo forte para avaliar a saída de um modelo mais fraco. A ideia é simples: peça ao GPT-4o ou ao Claude Sonnet para avaliar uma resposta em uma escala de 1 a 5 para correção, utilidade e segurança. Isso custa cerca de $0,01 por julgamento com o GPT-4o-mini e correlaciona-se surpreendentemente bem com julgamentos humanos -- cerca de 80% de concordância na maioria das tarefas.

O prompt de pontuação importa mais do que o modelo. Um prompt vago ("Avalie esta resposta") produz pontuações ruidosas. Um prompt estruturado com uma rubrica ("Dê nota 5 se a resposta for factualmente correta e citar uma fonte, nota 4 se for correta mas sem fontes, nota 3 se for parcialmente correta...") produz pontuações consistentes e reproduzíveis.

Modos de falha: os modelos juízes exibem viés de posição (preferem a primeira resposta em comparações pareadas), viés de verbosidade (preferem respostas mais longas) e autopreferência (o GPT-4 pontua saídas do GPT-4 mais alto do que saídas equivalentes do Claude). Mitigações: randomize a ordem, normalize pelo comprimento, use um juiz diferente do modelo que está sendo avaliado.

Classificações ELO a Partir de Comparações Pareadas

A abordagem do Chatbot Arena. Mostre duas respostas para o mesmo prompt a partir de modelos diferentes. Um humano (ou juiz LLM) escolhe a melhor. A partir de milhares dessas comparações, calcule uma classificação ELO para cada modelo -- o mesmo sistema usado no xadrez.

Vantagens do ELO: a classificação relativa é mais confiável do que a pontuação absoluta, lida com empates de forma elegante e converge com menos comparações do que pontuar cada saída de forma independente. No início de 2026, as classificações do Chatbot Arena mostram o GPT-4o, o Claude 3.5 Sonnet e o Gemini 1.5 Pro com uma diferença de menos de 20 pontos de ELO entre si no topo.

graph LR
    subgraph ELO["Pipeline de Classificação ELO"]
        direction TB
        P["Prompt"] --> MA["Saída do Modelo A"]
        P --> MB["Saída do Modelo B"]
        MA --> J["Juiz\n(Humano ou LLM)"]
        MB --> J
        J --> W["A Vence / B Vence / Empate"]
        W --> E["Atualização do ELO\nK=32"]
    end

    style P fill:#1a1a2e,stroke:#0f3460,color:#fff
    style J fill:#1a1a2e,stroke:#e94560,color:#fff
    style E fill:#1a1a2e,stroke:#51cf66,color:#fff

Frameworks de Avaliação

lm-evaluation-harness (EleutherAI): o framework de avaliação de código aberto padrão. Suporta mais de 200 benchmarks. Execute qualquer modelo da Hugging Face contra o MMLU, HellaSwag, ARC, etc. com um único comando. Utilizado pelo Open LLM Leaderboard.

RAGAS: framework de avaliação especificamente para pipelines de RAG. Mede a fidelidade (a resposta corresponde ao contexto recuperado?), a relevância (o contexto recuperado é relevante para a pergunta?) e a correção da resposta.

promptfoo: avaliação baseada em configuração para engenharia de prompts. Defina casos de teste em YAML, execute contra múltiplos modelos e obtenha um relatório de aprovação/reprovação. Útil para testes de regressão de prompts -- garanta que uma alteração de prompt não quebre os casos de teste existentes.

Construindo Evals Customizadas

A única avaliação que importa para a produção. O processo:

  1. Defina a tarefa. O que exatamente o modelo deve fazer? Seja preciso. "Responder a perguntas" é muito vago. "Dado um e-mail de reclamação do cliente, extrair o nome do produto, a categoria do problema e o sentimento" é uma tarefa que você pode avaliar.

  2. Crie casos de teste. Mínimo de 50 para uma avaliação de protótipo, mais de 200 para produção. Cada caso de teste é um par (entrada, saída_esperada). Inclua casos extremos: entradas vazias, entradas adversariais, entradas ambíguas, entradas em outros idiomas.

  3. Defina a pontuação. Correspondência exata (exact match) para saídas estruturadas. BLEU/ROUGE para similaridade de texto. LLM como juiz para qualidade de respostas abertas. F1 para tarefas de extração. Combine múltiplas métricas com pesos.

  4. Automatize. Cada avaliação é executada com um único comando. Sem etapas manuais. Armazene os resultados em um formato que permita a comparação ao longo do tempo.

  5. Acompanhe ao longo do tempo. Uma pontuação de avaliação não tem significado isoladamente. Você precisa da linha de tendência. A pontuação melhorou após a última alteração do prompt? Ela piorou após a troca de modelos? Versione sua avaliação juntamente com seus prompts.

Tipo de Avaliação Custo por julgamento Concordância com humanos Ideal para
Correspondência exata ~$0 100% (quando aplicável) Saída estruturada, classificação
BLEU/ROUGE ~$0 ~60% Tradução, sumarização
LLM como juiz ~$0.01 ~80% Geração de respostas abertas
Avaliação humana $0.10- .00 N/A (é a referência real) Tarefas ambíguas de alta relevância

Construa

Passo 1: Um Framework de Avaliação Mínimo

Defina as abstrações centrais. Um caso de avaliação possui uma entrada, uma saída esperada e um dicionário de metadados opcional. Um pontuador (scorer) recebe uma previsão e uma referência e retorna uma pontuação entre 0 e 1.

import json
from collections import Counter

class EvalCase:
    def __init__(self, input_text, expected, metadata=None):
        self.input_text = input_text
        self.expected = expected
        self.metadata = metadata or {}

class EvalSuite:
    def __init__(self, name, cases, scorers):
        self.name = name
        self.cases = cases
        self.scorers = scorers

    def run(self, model_fn):
        results = []
        for case in self.cases:
            prediction = model_fn(case.input_text)
            scores = {}
            for scorer_name, scorer_fn in self.scorers.items():
                scores[scorer_name] = scorer_fn(prediction, case.expected)
            results.append({
                "input": case.input_text,
                "expected": case.expected,
                "prediction": prediction,
                "scores": scores,
            })
        return results

Passo 2: Funções de Pontuação

Construa funções para correspondência exata, F1 de tokens e um pontuador simulado de LLM como juiz.

def exact_match(prediction, expected):
    return 1.0 if prediction.strip().lower() == expected.strip().lower() else 0.0

def token_f1(prediction, expected):
    pred_tokens = set(prediction.lower().split())
    exp_tokens = set(expected.lower().split())
    if not pred_tokens or not exp_tokens:
        return 0.0
    common = pred_tokens & exp_tokens
    precision = len(common) / len(pred_tokens)
    recall = len(common) / len(exp_tokens)
    if precision + recall == 0:
        return 0.0
    return 2 * (precision * recall) / (precision + recall)

def llm_judge_simulated(prediction, expected):
    pred_words = set(prediction.lower().split())
    exp_words = set(expected.lower().split())
    if not exp_words:
        return 0.0
    overlap = len(pred_words & exp_words) / len(exp_words)
    length_penalty = min(1.0, len(prediction) / max(len(expected), 1))
    return round(overlap * 0.7 + length_penalty * 0.3, 3)

Passo 3: Sistema de Classificação ELO

Implemente comparações pareadas com atualizações de ELO. Este é exatamente o sistema que o Chatbot Arena utiliza para classificar modelos.

class ELOTracker:
    def __init__(self, k=32, initial_rating=1500):
        self.ratings = {}
        self.k = k
        self.initial_rating = initial_rating
        self.history = []

    def _ensure_player(self, name):
        if name not in self.ratings:
            self.ratings[name] = self.initial_rating

    def expected_score(self, rating_a, rating_b):
        return 1 / (1 + 10 ** ((rating_b - rating_a) / 400))

    def record_match(self, player_a, player_b, outcome):
        self._ensure_player(player_a)
        self._ensure_player(player_b)

        ea = self.expected_score(self.ratings[player_a], self.ratings[player_b])
        eb = 1 - ea

        if outcome == "a":
            sa, sb = 1.0, 0.0
        elif outcome == "b":
            sa, sb = 0.0, 1.0
        else:
            sa, sb = 0.5, 0.5

        self.ratings[player_a] += self.k * (sa - ea)
        self.ratings[player_b] += self.k * (sb - eb)

        self.history.append({
            "a": player_a, "b": player_b,
            "outcome": outcome,
            "rating_a": round(self.ratings[player_a], 1),
            "rating_b": round(self.ratings[player_b], 1),
        })

    def leaderboard(self):
        return sorted(self.ratings.items(), key=lambda x: -x[1])

Passo 4: Cálculo de Perplexidade

Calcule a perplexidade usando probabilidades de tokens. Na prática, você obteria estas probabilidades a partir dos logits do modelo. Aqui, simulamos com uma distribuição de probabilidade.

import numpy as np

def perplexity(log_probs):
    if not log_probs:
        return float("inf")
    avg_neg_log_prob = -np.mean(log_probs)
    return float(np.exp(avg_neg_log_prob))

def token_log_probs_simulated(text, model_quality=0.8):
    np.random.seed(hash(text) % 2**31)
    tokens = text.split()
    log_probs = []
    for i, token in enumerate(tokens):
        base_prob = model_quality
        if len(token) > 8:
            base_prob *= 0.6
        if i == 0:
            base_prob *= 0.7
        prob = np.clip(base_prob + np.random.normal(0, 0.1), 0.01, 0.99)
        log_probs.append(float(np.log(prob)))
    return log_probs

Passo 5: Agregar Resultados

Calcule estatísticas resumidas de uma execução de avaliação: média, mediana, taxa de aprovação com base em um limite e detalhamento por métrica.

def summarize_results(results, threshold=0.8):
    all_scores = {}
    for r in results:
        for metric, score in r["scores"].items():
            all_scores.setdefault(metric, []).append(score)

    summary = {}
    for metric, scores in all_scores.items():
        arr = np.array(scores)
        summary[metric] = {
            "mean": round(float(np.mean(arr)), 3),
            "median": round(float(np.median(arr)), 3),
            "std": round(float(np.std(arr)), 3),
            "min": round(float(np.min(arr)), 3),
            "max": round(float(np.max(arr)), 3),
            "pass_rate": round(float(np.mean(arr >= threshold)), 3),
            "n": len(scores),
        }
    return summary

def print_summary(summary, suite_name="Eval"):
    print(f"\n{'=' * 60}")
    print(f"  {suite_name} Summary")
    print(f"{'=' * 60}")
    for metric, stats in summary.items():
        print(f"\n  {metric}:")
        print(f"    Mean:      {stats['mean']:.3f}")
        print(f"    Median:    {stats['median']:.3f}")
        print(f"    Std:       {stats['std']:.3f}")
        print(f"    Range:     [{stats['min']:.3f}, {stats['max']:.3f}]")
        print(f"    Pass rate: {stats['pass_rate']:.1%} (threshold >= 0.8)")
        print(f"    N:         {stats['n']}")

Passo 6: Executar o Pipeline Completo

Conecte tudo. Defina uma tarefa, crie casos de teste, simule dois modelos, execute avaliações, calcule o ELO a partir de comparações pareadas e exiba a tabela de classificação.

def demo_model_good(prompt):
    responses = {
        "What is the capital of France?": "Paris",
        "What is 2 + 2?": "4",
        "Who wrote Hamlet?": "William Shakespeare",
        "What language is PyTorch written in?": "Python and C++",
        "What is the boiling point of water?": "100 degrees Celsius",
    }
    return responses.get(prompt, "I don't know")

def demo_model_bad(prompt):
    responses = {
        "What is the capital of France?": "Paris is the capital city of France",
        "What is 2 + 2?": "The answer is four",
        "Who wrote Hamlet?": "Shakespeare",
        "What language is PyTorch written in?": "Python",
        "What is the boiling point of water?": "212 Fahrenheit",
    }
    return responses.get(prompt, "Unknown")

cases = [
    EvalCase("What is the capital of France?", "Paris"),
    EvalCase("What is 2 + 2?", "4"),
    EvalCase("Who wrote Hamlet?", "William Shakespeare"),
    EvalCase("What language is PyTorch written in?", "Python and C++"),
    EvalCase("What is the boiling point of water?", "100 degrees Celsius"),
]

suite = EvalSuite(
    name="General Knowledge",
    cases=cases,
    scorers={
        "exact_match": exact_match,
        "token_f1": token_f1,
        "llm_judge": llm_judge_simulated,
    },
)

results_good = suite.run(demo_model_good)
results_bad = suite.run(demo_model_bad)

print_summary(summarize_results(results_good), "Model A (concise)")
print_summary(summarize_results(results_bad), "Model B (verbose)")

O modelo "bom" fornece respostas exatas. O modelo "ruim" fornece paráfrases prolixas. A correspondência exata pune severamente o modelo prolixo. O F1 de tokens e o LLM como juiz são mais tolerantes. Isso ilustra por que a escolha da métrica importa: o mesmo modelo parece excelente ou terrível dependendo de como você o pontua.

Passo 7: Torneio ELO

Execute comparações pareadas entre modelos ao longo de múltiplos rounds.

elo = ELOTracker(k=32)

for case in cases:
    pred_a = demo_model_good(case.input_text)
    pred_b = demo_model_bad(case.input_text)

    score_a = token_f1(pred_a, case.expected)
    score_b = token_f1(pred_b, case.expected)

    if score_a > score_b:
        outcome = "a"
    elif score_b > score_a:
        outcome = "b"
    else:
        outcome = "tie"

    elo.record_match("model_a_concise", "model_b_verbose", outcome)

print("\nELO Leaderboard:")
for name, rating in elo.leaderboard():
    print(f"  {name}: {rating:.0f}")

Passo 8: Comparação de Perplexidade

Compare a perplexidade entre "modelos" de diferentes níveis de qualidade.

test_text = "The quick brown fox jumps over the lazy dog in the garden"

for quality, label in [(0.9, "Strong model"), (0.7, "Medium model"), (0.4, "Weak model")]:
    log_probs = token_log_probs_simulated(test_text, model_quality=quality)
    ppl = perplexity(log_probs)
    print(f"  {label} (quality={quality}): perplexity = {ppl:.2f}")

Como Usar

lm-evaluation-harness (EleutherAI)

A ferramenta padrão para executar benchmarks em qualquer modelo.

# pip install lm-eval
# Command line:
# lm_eval --model hf --model_args pretrained=meta-llama/Llama-3.1-8B --tasks mmlu --batch_size 8

# Python API:
# import lm_eval
# results = lm_eval.simple_evaluate(
#     model="hf",
#     model_args="pretrained=meta-llama/Llama-3.1-8B",
#     tasks=["mmlu", "hellaswag", "arc_easy"],
#     batch_size=8,
# )
# print(results["results"])

promptfoo

Avaliação baseada em configuração para engenharia de prompts. Defina testes em YAML e execute contra múltiplos provedores.

# promptfoo.yaml
providers:
  - openai:gpt-4o-mini
  - anthropic:claude-3-haiku

prompts:
  - "Answer in one word: {{question}}"

tests:
  - vars:
      question: "What is the capital of France?"
    assert:
      - type: contains
        value: "Paris"
  - vars:
      question: "What is 2 + 2?"
    assert:
      - type: equals
        value: "4"

RAGAS para avaliação de RAG

# pip install ragas
# from ragas import evaluate
# from ragas.metrics import faithfulness, answer_relevancy, context_precision
#
# result = evaluate(
#     dataset,
#     metrics=[faithfulness, answer_relevancy, context_precision],
# )
# print(result)

O RAGAS mede o que avaliações genéricas deixam passar: se a resposta do modelo está fundamentada no contexto recuperado, e não apenas se a resposta é "correta" no abstrato.

Conclusão

Esta lição produz outputs/prompt-eval-designer.md -- um prompt reutilizável que projeta suites de avaliação customizadas para qualquer tarefa. Forneça uma descrição da tarefa e ele gerará casos de teste, funções de pontuação e uma recomendação de limite de aprovação/reprovação.

Também produz outputs/skill-evaluation.md -- uma estrutura de decisão para escolher a estratégia de avaliação correta com base no tipo de tarefa, orçamento e requisitos de latência.

Exercícios

  1. Adicione um pontuador de "consistência" que execute a mesma entrada no modelo 5 vezes e meça a frequência com que as saídas correspondem. Respostas inconsistentes em entradas determinísticas revelam prompts frágeis ou configurações de temperatura elevadas.

  2. Estenda o rastreador de ELO para suportar múltiplas funções de julgamento (correspondência exata, F1, LLM como juiz) e atribua pesos a elas. Compare como a tabela de classificação muda quando você atribui muito peso à correspondência exata versus ao F1.

  3. Construa uma suite de avaliação para uma tarefa específica: classificação de e-mails em 5 categorias. Crie 100 casos de teste com exemplos diversos, incluindo casos extremos (e-mails que poderiam pertencer a múltiplas categorias, e-mails vazios, e-mails em outros idiomas). Meça o desempenho de diferentes "modelos" (baseado em regras, correspondência de palavras-chave, LLM simulado).

  4. Implemente a detecção de contaminação: dado um conjunto de perguntas de avaliação e um corpus de treinamento, verifique qual porcentagem das perguntas de avaliação (ou paráfrases próximas) aparece nos dados de treinamento. É assim que pesquisadores auditam a validade de benchmarks.

  5. Construa uma ferramenta de "diff de modelos". Dados os resultados de avaliação de duas versões de modelos, destaque quais casos de teste específicos melhoraram, quais regrediram e quais permaneceram iguais. Este é o equivalente de avaliação de um diff de código -- essencial para entender se uma alteração ajudou ou prejudicou.

Termos-Chave

Termo O que dizem O que realmente significa
MMLU "O benchmark" Massive Multitask Language Understanding -- 15.908 perguntas de múltipla escolha em 57 assuntos, saturado acima de 88% por volta de 2025
HumanEval "Avaliação de código" 164 problemas de preenchimento de função em Python da OpenAI, testa apenas a geração de funções isoladas
SWE-bench "Avaliação de codificação real" 2.294 problemas do GitHub extraídos de 12 repositórios Python, mede a correção de bugs de ponta a ponta, incluindo a geração de testes
Perplexidade (Perplexity) "O quão confuso o modelo está" exp(-avg(log P(token_i dado o contexto))) -- menor significa que o modelo atribui maior probabilidade aos tokens reais
Classificação ELO "Ranking de xadrez para modelos" Uma classificação de habilidade relativa calculada a partir de registros pareados de vitórias/derrotas, usada pelo Chatbot Arena para classificar mais de 100 modelos
LLM como juiz "Usar IA para dar nota à IA" Um modelo forte pontua as saídas de um modelo mais fraco contra uma rubrica, com ~80% de concordância com juízes humanos a um custo de ~$0,01 por julgamento
Contaminação de dados "O modelo viu a prova" Os dados de treinamento incluem perguntas do benchmark, inflando as pontuações sem melhorar a capacidade real
Suite de avaliação (Eval suite) "Um monte de testes" Uma coleção versionada de triplas (entrada, saída_esperada, pontuador) que medem uma capacidade específica
Taxa de aprovação (Pass rate) "Qual porcentagem ele acerta" Fração de casos de avaliação que pontuam acima de um limite -- mais acionável do que a pontuação média porque mede a confiabilidade
Chatbot Arena "Site de ranking de modelos" Plataforma LMSYS com mais de 2 milhões de votos de preferência humana, gerando a tabela de classificação de LLMs mais confiável por meio de classificações ELO

Leituras Adicionais