Construção de benchmarks

A construção de benchmarks (benchmark construction) é a arte de transformar um objetivo do mundo real (“modelos devem ser úteis e confiáveis para suporte ao cliente”) em um sistema de medição (um conjunto de dados (dataset) + protocolo (protocol) + métricas (metrics)) que realmente acompanhe esse objetivo. Quando bem-feitos, benchmarks aceleram o progresso ao tornar melhorias legíveis e comparáveis. Quando mal-feitos, eles recompensam a “manipulação de benchmark (benchmark gaming)”, ocultam regressões e produzem placares (leaderboards) enganosos.

Este artigo explica como projetar benchmarks que medem aquilo com que você realmente se importa, da teoria da medição ao desenho prático de conjuntos de dados e protocolos.

O que um benchmark realmente é

Um benchmark não é apenas um conjunto de dados. Ele é uma especificação de medição (measurement specification):

  • Construto-alvo (target construct): a capacidade/comportamento que você quer medir (por exemplo, acurácia factual sob recuperação (retrieval), raciocínio robusto, recusa segura).
  • Formulação da tarefa (task formulation): quais entradas o modelo recebe e quais saídas deve produzir.
  • Dados (data): exemplos extraídos de uma população de interesse.
  • Protocolo (protocol): prompts, acesso a ferramentas, limites de tempo, parâmetros de amostragem, tentativas permitidas, etc.
  • Pontuação (scoring): métricas e agregação, além de como você lida com ambiguidade e saídas ausentes/inválidas.
  • Relato estatístico (statistical reporting): intervalos de confiança, testes de significância, resultados estratificados.

Muitas falhas de benchmarks vêm de um foco excessivo no conjunto de dados e de uma especificação insuficiente do protocolo. Para armadilhas de avaliação específicas de conjuntos de teste e desenho experimental, veja Avaliação Offline.

Comece pelo fim: defina com o que você realmente se importa

A qualidade de um benchmark depende de você traduzir corretamente um objetivo em uma definição operacional (operational definition).

Escreva uma declaração de capacidade-alvo

Uma boa declaração é concreta, sensível ao contexto e falsificável:

  • Ruim: “Medir raciocínio.”
  • Melhor: “Medir raciocínio aritmético de múltiplas etapas com restrições intermediárias.”
  • Melhor ainda: “Medir a capacidade de resolver problemas de enunciado de aritmética em múltiplas etapas sem ferramentas externas, em que a correção é a resposta numérica final e os problemas refletem cenários de faturamento de clientes.”

Inclua:

  • População de usuários / domínio: quem e onde o modelo será usado
  • Entradas: quais informações estão disponíveis (documentos, ferramentas, janela de contexto)
  • Restrições: latência, custo, política de segurança, estilo de recusa
  • Critérios de sucesso: como é o “bom” (acurácia, conformidade, utilidade)

Identifique o “construto” e prováveis fatores de confusão

Em termos de medição, seu construto (construct) pode ser “planejamento de uso de ferramentas” ou “veracidade sob incerteza”. Fatores de confusão (confounders) são variáveis que influenciam pontuações, mas não são o construto:

  • Nível de leitura confunde “raciocínio”
  • Artefatos de conjunto de dados confundem “generalização”
  • Peculiaridades de formatação confundem “seguimento de instruções”
  • Memorização confunde “capacidade” (veja Contaminação do Conjunto de Teste)

Uma técnica prática: liste 5–10 formas pelas quais um modelo poderia pontuar bem sem ter a capacidade desejada. Essas se tornam ameaças à validade que você precisa mitigar.

Fundamentos de medição: validade, confiabilidade e sensibilidade

A construção de benchmarks toma emprestado da psicometria (psychometrics) e do desenho experimental (experimental design). Três propriedades importam mais.

Validade: você está medindo a coisa certa?

Lentes comuns de validade:

  • Validade de conteúdo (content validity): os itens cobrem as habilidades e subdomínios relevantes?
  • Validade de construto (construct validity): o desempenho varia de maneiras esperadas (por exemplo, melhor recuperação melhora QA fundamentado)?
  • Validade de critério (criterion validity): as pontuações predizem resultados no mundo real (testes A/B (A/B tests), satisfação do usuário, taxas de incidentes)?

Um benchmark pode ser internamente consistente e ainda assim inválido se medir um indicador substituto (proxy) que diverge do objetivo real — um caso da Lei de Goodhart (Goodhart’s Law). Veja A Lei de Goodhart em Métricas.

Confiabilidade: você obteria o mesmo resultado de novo?

Problemas de confiabilidade aparecem como rankings instáveis, grande variância entre execuções ou forte dependência de sementes aleatórias (random seeds).

Fontes de falta de confiabilidade:

  • Conjuntos de teste pequenos
  • Decodificação estocástica (stochastic decoding) sem controles
  • Inconsistência entre avaliadores humanos
  • Não determinismo de ferramentas (tooling nondeterminism) (timeouts de API, conteúdo web em mudança)

Sensibilidade: você consegue detectar melhorias significativas?

Um benchmark deve conseguir distinguir:

  • Deltas ruidosos (variação aleatória)
  • Deltas reais (melhorias pequenas, porém consistentes)
  • Regressões em subgrupos importantes

A sensibilidade vem de tamanho de amostra suficiente, boa estratificação e relato estatístico robusto (veja Reprodutibilidade e Significância Estatística).

Passo 1: escolha uma formulação de tarefa de avaliação

A formulação da tarefa é onde “com o que você se importa” vira “o que o modelo deve fazer”.

Decida o modelo de interação

Padrões comuns:

  • Turno único (single-turn): um prompt → uma resposta (QA clássico)
  • Múltiplos turnos (multi-turn): o estado da conversa importa (agentes de suporte)
  • Com ferramentas (tool-augmented): o modelo pode chamar ferramentas (recuperação, calculadora, execução de código)
  • Agêntico (agentic): planeja, executa ações, recupera-se de erros (veja Avaliação de Agentes)

Faça a formulação corresponder à implantação. Se a produção usa recuperação, seu benchmark deve incluir recuperação no loop; caso contrário, você pode medir “recordação paramétrica (parametric recall)” em vez de “respostas fundamentadas (grounded answering)”.

Especifique restrições que moldam o comportamento

Exemplos:

  • Ferramentas permitidas e esquemas de ferramentas
  • Timeouts e orçamentos (tokens, chamadas de ferramenta, custo)
  • Formato de saída e esquemas (JSON, chamadas de função)
  • Expectativas de política de segurança (recusar vs cumprir vs responder com segurança e completude)

Anote isso como parte da especificação do benchmark; não deixe implícito.

Controle graus de liberdade (ou os declare)

Graus de liberdade não controlados convidam overfitting e comparações injustas:

  • Redação do prompt
  • Exemplos de poucos exemplos (few-shot)
  • Parâmetros de decodificação (decoding) (temperatura, top_p)
  • Mensagens de sistema e configurações de segurança
  • Estratégias de retry

Você pode:

  1. Padronizá-los (melhor para comparabilidade), ou
  2. Permitir ajuste mas exigir relato e uma divisão de validação (melhor ao comparar sistemas, não apenas modelos-base).

Passo 2: desenhe o conjunto de dados (quais exemplos você inclui)

Defina a população e a estratégia de amostragem

Pergunte: com qual distribuição eu me importo? Então amostre de acordo.

Abordagens:

  • Amostragem naturalística (naturalistic sampling): logs, consultas de usuários, documentos reais (ótima validade externa; exige trabalho de privacidade)
  • Amostragem estratificada (stratified sampling): força cobertura de tópicos/dificuldades (ótima cobertura; pode distorcer prevalência)
  • Geração sintética (synthetic generation): escalável e controlável; risco de aprendizado de artefatos

Um compromisso prático é um conjunto de dados híbrido (hybrid): consultas reais + casos difíceis sintéticos + casos adversariais.

Cobertura e estratificação

Crie tags (metadados) para aspectos de que você se importa:

  • Tópico/domínio
  • Proxy de dificuldade (comprimento, etapas, ambiguidade)
  • Capacidade exigida (recuperação, matemática, uso de ferramentas)
  • Categoria de segurança (autoagressão, medicina, golpes)

Então relate métricas gerais e por recorte (slices). Muitas regressões são invisíveis no agregado.

Evite vazamento e contaminação por design

Contaminação pode ocorrer por:

  • Conjuntos de teste publicados publicamente e usados em treinamento
  • Itens quase duplicados de fontes comuns da web
  • “Ecos” do benchmark em corpora de ajuste fino por instruções (instruction-tuning)

Mitigações:

  • Manter dados de teste privados quando possível
  • Usar strings canário (canary strings) ou marcação d’água (watermarking) para detecção de vazamento (quando apropriado)
  • Deduplicar contra corpora conhecidos
  • Preferir dados frescos (divisões por tempo) para domínios que mudam rapidamente

Veja Contaminação do Conjunto de Teste para estratégias mais profundas.

Divisões de treino/validação/teste que reflitam o objetivo

Tipos comuns de divisão:

  • Divisão aleatória (random split): a mais simples; pode superestimar generalização se houver duplicatas
  • Divisão por grupo (group split): dividir por usuário, documento ou entidade para prevenir vazamento (por exemplo, todas as perguntas sobre o mesmo cliente ficam juntas)
  • Divisão temporal (time split): treinar no passado, testar no futuro (melhor para distribuições em evolução)
  • Divisão por domínio (domain split): testar em novos domínios para medir transferência

Se você quer generalização robusta, divisões aleatórias frequentemente são insuficientes.

Passo 3: defina ground truth e processos de anotação

Ground truth é fácil para algumas tarefas (respostas por correspondência exata) e intrinsecamente difuso para outras (utilidade, estilo, segurança). Seu benchmark precisa decidir como lidar com ambiguidade.

Desenho de rótulos: decida o que “correto” significa

Para tarefas abertas, especifique:

  • Variantes aceitáveis de resposta
  • Citações / evidências obrigatórias
  • Como lidar com correção parcial
  • Quando a recusa é correta (segurança, falta de informação)

Para muitas aplicações de modelos de linguagem grande (LLM), você precisa de rótulos com múltiplos atributos (por exemplo, “útil”, “fiel”, “seguro”). Isso é central em Avaliação de Apps com LLM.

Controles de qualidade de anotação

Se humanos rotulam dados:

  • Crie um guia de rotulagem (labeling guide) com exemplos e contraexemplos
  • Use rodadas de treinamento e calibração (calibration)
  • Meça concordância entre anotadores (inter-annotator agreement) (e investigue itens com baixa concordância)
  • Adicione questões ouro (gold questions) para detectar rotulagem de baixo esforço
  • Use arbitragem (adjudication) (desempate) para itens críticos

Se os rótulos são difusos, não finja que são perfeitamente objetivos; em vez disso, modele a incerteza (por exemplo, distribuições sobre notas).

Usando modelos no loop (com cuidado)

LLMs podem ajudar a gerar candidatos, rascunhar rótulos ou pré-triar itens — mas isso adiciona riscos:

  • Viés em direção às preferências do modelo julgador
  • Erros sistemáticos que viram “ground truth”
  • Acoplamento oculto se o modelo avaliado foi treinado em dados similares

Se você usa julgamento por LLM, trate-o como um instrumento que exige calibração e auditoria; veja LLM como Juiz. Para avaliações subjetivas humanas, veja Avaliação Humana.

Passo 4: escolha métricas que incentivem o comportamento certo

Métricas são onde a Lei de Goodhart atinge com mais força: modelos otimizam o que você mede, não o que você quer dizer.

Propriedades de boas métricas

Prefira métricas que sejam:

  • Alinhadas: correlacionam com sucesso no mundo real
  • Robustas: não são facilmente manipuladas por truques superficiais
  • Interpretáveis: stakeholders entendem mudanças
  • Decomponíveis: permitem diagnosticar modos de falha via recortes
  • Estáveis: baixa variância entre execuções

Combine tipo de métrica com tipo de tarefa

Exemplos:

  • Classificação (classification): acurácia, F1, AUROC (escolha com base em desbalanceamento de classes e custo)
  • QA (question answering): correspondência exata (exact match) + F1 em nível de token (token-level F1); mas valide contra ambiguidade
  • Geração (generation): métricas automatizadas (BLEU/ROUGE) frequentemente desalinhadas; use julgamento humano/por LLM com guardrails
  • Geração aumentada por recuperação (RAG): separe qualidade da recuperação e fundamentação da resposta (veja Avaliação de Apps com LLM)
  • Segurança (safety): meça tanto conformidade insegura (unsafe compliance) quanto recusa excessiva (over-refusal) (veja Avaliação de Segurança)

Use múltiplas métricas quando necessário, mas evite “sopa de métricas”

Se você acompanha muitas métricas, defina:

  • Uma métrica primária para comparações de destaque
  • Métricas secundárias para diagnóstico
  • Uma política de trade-offs (por exemplo, “aceitamos ≤1% de queda em utilidade por ≥30% de redução em conformidade insegura”)

Se você combina métricas em um único score, documente os pesos e justifique-os.

Passo 5: especifique o protocolo de avaliação (as “regras do jogo”)

Detalhes do protocolo podem mudar rankings.

Padronize prompting e decodificação

Defina:

  • Prompt de sistema / instrução
  • Exemplos de poucos exemplos (se houver)
  • Configurações de decodificação (temperatura, top_p, max_tokens)
  • Sequências de parada (stop sequences)
  • Requisitos de formato de saída

Para reprodutibilidade, prefira configurações determinísticas ou de baixa variância ao medir melhorias pequenas.

Trate saídas inválidas explicitamente

Decida o que acontece se o modelo:

  • Produz JSON malformado
  • Estoura tempo
  • Chama ferramentas incorretamente
  • Recusa quando não deveria (ou vice-versa)

Escreva regras de pontuação como “saídas malformadas contam como incorretas” ou “uma tentativa de retry é permitida com o mesmo prompt”.

Versione seu benchmark e o harness

Benchmarks são software. Versione:

  • Conjunto de dados
  • Prompts
  • Ferramentas (versões do recuperador, endpoints de API)
  • Código de pontuação

Sem versionamento, resultados se tornam incomparáveis ao longo do tempo — especialmente com ferramentas dinâmicas.

Passo 6: projete com rigor estatístico

Um benchmark deve relatar incerteza, não apenas estimativas pontuais.

Use intervalos de confiança e testes pareados

Ao comparar dois modelos nos mesmos itens, use análises pareadas (paired) (por exemplo, bootstrap em diferenças no nível do item). Isso aumenta a sensibilidade.

Aqui está um esboço mínimo de intervalo de confiança por bootstrap:

import random
import numpy as np

def bootstrap_ci(deltas, n_boot=2000, alpha=0.05, seed=0):
    rng = random.Random(seed)
    deltas = np.array(deltas)  # per-item (modelA_score - modelB_score)
    n = len(deltas)
    means = []
    for _ in range(n_boot):
        sample = [deltas[rng.randrange(n)] for _ in range(n)]
        means.append(float(np.mean(sample)))
    means.sort()
    lo = means[int((alpha/2) * n_boot)]
    hi = means[int((1-alpha/2) * n_boot)]
    return (np.mean(deltas), lo, hi)

Se seu intervalo de confiança inclui 0, trate a diferença como inconclusiva, a menos que você tenha razões prévias fortes.

Para mais sobre variância e melhorias significativas, veja Reprodutibilidade e Significância Estatística.

Poder e tamanho de amostra (pensamento por regra de bolso)

  • Se sua métrica é ruidosa (avaliações humanas, julgamento por LLM), em geral você precisa de mais itens do que em tarefas de correspondência exata.
  • Se você se importa com falhas raras (segurança, alucinações (hallucinations)), pode precisar de amostragem direcionada de casos de alto risco em vez de apenas escalar conjuntos aleatórios.

Passo 7: incorpore robustez, mudança de distribuição e testes adversariais

Benchmarks que medem apenas o “caso médio” frequentemente deixam passar fragilidades do mundo real.

Robustez como objetivo de primeira classe

Inclua:

  • Paráfrases / reescritas
  • Entradas ruidosas (erros de OCR, typos)
  • Mudanças de formato
  • Mudanças de domínio (novos tópicos, novas entidades)
  • Casos escolhidos adversarialmente

Isso se sobrepõe a Avaliação Robusta.

Considerações de segurança e uso indevido

Se seu sistema é implantado amplamente, inclua:

  • Pedidos que violam políticas
  • Tentativas de evasão de salvaguardas (jailbreak) e injeções de prompt (prompt injections)
  • Cenários de duplo uso (dual-use) (bio, cyber, fraude)
  • Testes de recusa excessiva (o modelo ainda consegue ajudar com segurança?)

Veja Avaliação de Segurança.

Exemplos trabalhados (do objetivo ao benchmark)

Exemplo 1: geração de código para ferramentas internas

Objetivo: “Gerar funções Python corretas para tarefas de limpeza de dados usadas por analistas.”

Construto: correção funcional sob restrições realistas.

Escolhas de design:

  • Conjunto de dados: 500 prompts derivados de tarefas reais (desidentificadas), estratificados por bibliotecas usadas (pandas, regex, datetime).
  • Protocolo: o modelo deve produzir um único corpo de função com uma assinatura; sem internet; decodificação determinística.
  • Pontuação: executar testes unitários (unit tests) em um ambiente isolado (sandbox). Métrica: pass@1 mais detalhamento por tipo de erro (erro de sintaxe, saída errada, timeout).

Por que isso mede o que você quer:

  • Testes unitários aproximam melhor a correção em produção do que métricas de similaridade.
  • O detalhamento de erros direciona melhorias acionáveis (prompting vs capacidade do modelo).

Exemplo 2: benchmark de RAG para artigos de suporte ao cliente

Objetivo: “Responder perguntas usando apenas docs recuperados do help center; não alucinar.”

Construtos: eficácia da recuperação + geração de resposta fundamentada.

Escolhas de design:

  • Conjunto de dados: (pergunta, conjunto de docs, resposta de referência, citações). Perguntas amostradas de tickets reais; docs do snapshot do help center.
  • Protocolo: fornecer o mecanismo de recuperação (retriever); o modelo recebe as passagens top-k; deve citar IDs das passagens.
  • Métricas:
    • Recall@k de recuperação (o doc certo aparece?)
    • Fundamentação: as afirmações são sustentadas pelas passagens citadas?
    • Utilidade: resolve o problema do usuário?

Este é um caso clássico para Avaliação de Apps com LLM: frequentemente você precisa de múltiplas métricas porque “correção” se decompõe em comportamento do recuperador + do gerador.

Exemplo 3: benchmark de agente com uso de ferramentas e orçamento

Objetivo: “Um agente (agent) pode concluir troubleshooting de conta chamando ferramentas aprovadas dentro de limites de custo e tempo.”

Construtos: planejamento, correção de uso de ferramentas, recuperação de erros.

Escolhas de design:

  • Ambiente: sistema de tickets simulado com ferramentas (lookup_user, reset_password, check_status).
  • Protocolo: no máximo 10 chamadas de ferramenta, 2 minutos de tempo de relógio, deve produzir uma mensagem final ao usuário mais um log interno de ações.
  • Pontuação:
    • Taxa de sucesso da tarefa (ticket resolvido)
    • Taxa de validade de chamadas de ferramenta
    • Média de chamadas e tempo (eficiência)
    • Restrições de segurança (sem exfiltração de dados)

Isso se alinha a princípios de avaliação agêntica em Avaliação de Agentes.

Modos de falha comuns (e como evitá-los)

Overfitting a artefatos

Sintomas: modelos exploram pistas espúrias, padrões de formatação ou peculiaridades do conjunto de dados.

Mitigações:

  • Deduplicar e randomizar templates
  • Usar múltiplas fontes e paráfrases
  • Incluir contrafactuais (mesma estrutura, resposta diferente)

Scores de número único enganosos

Sintomas: o score geral sobe enquanto o desempenho em recortes críticos cai.

Mitigações:

  • Predefinir recortes e relatá-los
  • Definir métricas de guardrail e limiares mínimos aceitáveis

O benchmark se torna obsoleto

Sintomas: efeito de teto, scores saturados, deixa de refletir necessidades do usuário.

Mitigações:

  • Atualizações com versionamento
  • Introduzir itens mais difíceis ou mais realistas
  • Manter “conjuntos de desafio” para falhas raras

Dinâmicas de placar distorcem o progresso

Sintomas: otimização para o conjunto de teste público, treinamento em dados “parecidos com benchmark”.

Mitigações:

  • Conjuntos de teste ocultos/privados
  • Rotação de itens de avaliação
  • Documentação e políticas fortes

Veja Placares para como dinâmicas competitivas moldam comportamento.

Checklist prático para construção de benchmarks

  • Clareza do objetivo

    • Declaração escrita de capacidade-alvo com restrições e critérios de sucesso
    • “Formas de trapacear” enumeradas e mitigações

  • Conjunto de dados

    • População definida; amostragem justificada
    • Recortes/tags definidos para subgrupos-chave
    • Estratégia de divisão corresponde ao objetivo de generalização (grupo/tempo quando necessário)
    • Risco de contaminação avaliado (veja Contaminação do Conjunto de Teste)

  • Protocolo

    • Prompting, acesso a ferramentas e configurações de decodificação especificados
    • Tratamento de saída inválida definido
    • Versionamento para dados + harness

  • Rótulos e métricas

    • Especificação de ground truth (incluindo política de ambiguidade)
    • Métrica(s) alinhada(s) com resultado real; guardrails definidos
    • Julgamento humano/por LLM calibrado, se usado (veja Avaliação Humana, LLM como Juiz)

  • Estatística

    • Intervalos de confiança e comparações pareadas
    • Tamanho de amostra adequado para a sensibilidade pretendida

  • Robustez e segurança

Perspectiva final

A construção de benchmarks é, fundamentalmente, desenhar incentivos. Os melhores benchmarks tornam fácil fazer a coisa certa (melhorar capacidade real) e difícil fazer a coisa errada (manipular o indicador substituto). Trate benchmarks como instrumentos vivos de medição — especificados, versionados, auditados e atualizados conforme seus objetivos e realidades de implantação evoluem.