Avaliação Offline

O que significa “Avaliação offline (offline evaluation)”

A avaliação offline é a prática de avaliar um modelo de I.A./aprendizado de máquina (AI/ML) usando dados previamente coletados — tipicamente um conjunto de teste reservado (held-out test set) — sem implantar o modelo em um ambiente ao vivo. Ela responde a perguntas como:

  • “Quão bem meu modelo generaliza para exemplos não vistos, extraídos da mesma (ou de uma distribuição semelhante)?”
  • “O modelo A é melhor do que o modelo B sob um protocolo fixo?”
  • “Quais modos de falha aparecem em um ambiente controlado?”

A avaliação offline é a espinha dorsal da maioria dos testes de referência acadêmicos (benchmarks) e de muitos fluxos de trabalho de produção, mas pode ser enganosa se o conjunto de teste (test set), o protocolo de avaliação (evaluation protocol) ou as métricas (metrics) não corresponderem à tarefa do mundo real.

Este artigo se concentra em conjuntos de teste, protocolos de avaliação e armadilhas comuns. Para tópicos relacionados, veja:

Fundamentos Teóricos: O que é (e o que não é) um Conjunto de Teste

No aprendizado supervisionado (supervised learning), muitas vezes assumimos que exemplos ((x, y)) são amostrados de forma i.i.d. (independentes e identicamente distribuídos) a partir de alguma distribuição (D). A avaliação offline estima o desempenho de generalização (generalization performance):

[ \mathbb{E}_{(x,y)\sim D}[\text{metric}(f(x), y)] ]

Um conjunto de teste é uma amostra de (D) que não foi usada para ajustar o modelo nem para ajustar decisões sobre o modelo. Na prática, esse requisito de “não usada” é mais rigoroso do que parece:

  • Não usada diretamente para treinar parâmetros
  • Não usada indiretamente via ajuste de hiperparâmetros (hyperparameter tuning) ou seleção repetida de modelo (model selection)
  • Não usada via escolhas de pré-processamento (preprocessing) que “espiam” os rótulos do teste
  • Não usada via iteração manual baseada em erros no teste

A avaliação offline é uma estimativa, não uma garantia. Sua estimativa pode ser enviesada por:

  • mudança de distribuição (dataset shift) (teste ≠ mundo real)
  • efeitos de seleção (como o conjunto de teste foi coletado)
  • vazamento de informação (leakage) (informação “vazando” do teste para o treinamento)
  • incompatibilidade de métrica (metric mismatch) (otimizar a coisa errada)

Conjuntos de Teste e Divisões de Dados na Prática

Treino / Validação / Teste: Papéis e Disciplina

Uma divisão comum é:

  • Conjunto de treinamento (training set): ajustar os parâmetros do modelo (por exemplo, pesos (weights))
  • Conjunto de validação (dev) (validation set): ajustar hiperparâmetros, escolher checkpoints (checkpoints), parada antecipada (early stopping), selecionar instruções (prompts), escolher limiares
  • Conjunto de teste: estimativa final não enviesada usada uma vez (ou raramente) para reporte

Uma regra prática: se você o usou para decidir algo, então não é mais conjunto de teste.

Quando Divisões Aleatórias Estão Erradas: Divisões por Grupo e Temporais

Divisões aleatórias assumem que os exemplos são permutáveis. Muitos conjuntos de dados reais violam isso.

Divisões por grupo (grouped splits) (para evitar vazamento de identidade (identity leakage))

Se múltiplos exemplos vêm da mesma entidade (usuário, paciente, documento, dispositivo), uma divisão aleatória pode vazar informações específicas da entidade.

  • Exemplo: imagens médicas em que múltiplas varreduras vêm de um paciente
    Divisões aleatórias podem colocar o mesmo paciente em treino e teste, inflando a acurácia.

Use divisões por grupo: todas as amostras de um grupo vão para exatamente uma divisão.

Divisões temporais (temporal splits) (para respeitar causalidade)

Se seu modelo vai prever sobre dados futuros, sua avaliação deve imitar isso.

  • Exemplo: detecção de fraude, previsão de demanda, previsão de cliques
    Uma divisão aleatória pode permitir “padrões futuros” no treinamento.

Use divisões baseadas em tempo (time-based splits) (treinar no passado, validar/testar em períodos posteriores).

Divisões estratificadas (stratified splits) (para preservar proporções de classe)

Se as classes são desbalanceadas, divisões aleatórias ingênuas podem produzir estimativas instáveis para a classe minoritária. Use estratificação para preservar a distribuição de rótulos por divisão.

Validação Cruzada: Útil, Mas Não Mágica

A validação cruzada K-fold (K-fold cross-validation) faz a média do desempenho ao longo de (K) divisões. Ela ajuda quando os dados são limitados, mas ainda pode falhar sob vazamento ou estrutura não i.i.d.

Principais cuidados:

  • Se você ajusta hiperparâmetros usando validação cruzada e depois reporta o mesmo resultado da validação cruzada, você está com viés otimista. Considere validação cruzada aninhada (nested CV) ao fazer seleção pesada de modelos.
  • Se os dados são agrupados ou temporais, você precisa de validação cruzada por grupo (grouped CV) ou validação cruzada por janela móvel/em blocos (rolling/blocked CV).

Conjuntos de Teste Estáticos vs. Dinâmicos

Um conjunto de teste estático permite reprodutibilidade, mas incentiva sobreajuste (overfitting) — especialmente quando muitas equipes iteram sobre ele (comum em testes de referência e em Placares).

Mitigações incluem:

  • Conjuntos de teste privados (rótulos ocultos)
  • Avaliação em duas etapas (conjunto dev público + conjunto final privado)
  • Conjuntos de teste continuamente atualizados
  • Conjuntos de desafio que miram modos de falha conhecidos

Protocolos de Avaliação: O que Você Mede e Como Você Mede

Um protocolo de avaliação define:

  1. Definição da tarefa (entradas, saídas, restrições)
  2. Dados (quais exemplos, quais filtros)
  3. Métricas (o que conta como “bom”)
  4. Agregação (como pontuações por exemplo viram um número final)
  5. Procedimento estatístico (intervalos de confiança, significância, múltiplas comparações)
  6. Detalhes de reprodutibilidade (sementes aleatórias (random seeds), versão do modelo, pré-processamento)

Pequenas escolhas de protocolo podem dominar os resultados.

Escolha de Métrica: Alinhe com o Objetivo Real

Métricas são aproximações. De acordo com a Lei de Goodhart nas Métricas, quando uma métrica vira um alvo, ela pode deixar de refletir o que você valoriza.

Métricas de classificação

  • Acurácia: pode ser enganosa com desbalanceamento de classes
  • Precisão / Revocação / F1: melhores quando falsos positivos/negativos têm custos diferentes
  • Área sob a curva ROC (AUROC): qualidade de ranqueamento ao longo de limiares; pode parecer boa mesmo quando a precisão é ruim sob desbalanceamento extremo
  • Área sob a curva precisão-revocação (AUPRC): frequentemente mais informativa para positivos raros
  • Calibração (calibration) (pontuação de Brier (Brier score), erro de calibração esperado (expected calibration error, ECE)): importante quando probabilidades orientam decisões

A seleção de limiar faz parte do protocolo: escolher um limiar no conjunto de teste é vazamento.

Métricas de regressão

  • MAE vs MSE/RMSE: MSE penaliza mais erros grandes
  • Cuidado com caudas pesadas e outliers: considere métricas robustas ou reporte múltiplas

Métricas de ranqueamento/recuperação

Usadas em busca e sistemas de recomendação (recommenders):

  • MRR, NDCG@k, Recall@k, Precision@k
  • Elas assumem que você tem um conjunto significativo de itens candidatos e rótulos de relevância

Uma armadilha comum: métricas offline de ranqueamento podem ser enviesadas porque você só observa feedback do usuário sobre itens que foram exibidos (viés de exposição (exposure bias)). Resultados offline podem não prever desempenho online.

Métricas de modelos generativos

Para geração de texto/imagem, “correção” é multidimensional.

  • Baseadas em referência: BLEU/ROUGE (frequentemente frágeis), METEOR, chrF
  • Baseadas em representações vetoriais (embedding): BERTScore (captura semântica, mas tem seus próprios vieses)
  • Específicas da tarefa: correspondência exata (exact match) para saídas estruturadas, testes unitários (unit tests) para código, verificações de consistência factual (factual consistency) para resumos

Para aplicações com modelos de linguagem de grande porte (large language models, LLMs), veja também Avaliação de Aplicações de Modelos de Linguagem de Grande Porte, Avaliação Humana e Modelo de Linguagem de Grande Porte como Juiz (LLM-as-Judge).

Agregação: Micro vs Macro, e Por que Isso Importa

Como você faz a média pode mudar conclusões:

  • Média micro (micro-average): agrupa todas as instâncias (classes majoritárias dominam)
  • Média macro (macro-average): faz a média por classe (trata cada classe igualmente)
  • Macro ponderada (weighted macro): equilibra entre as duas

Para conjuntos de dados com dificuldade ou importância heterogêneas, considere reportar:

  • Métrica geral
  • Métricas por recorte (slice) (por exemplo, por idioma, região, tipo de dispositivo)
  • Desempenho do pior grupo quando relevante

Validade Estatística: Variância, Incerteza e Múltiplas Comparações

Métricas offline são estimativas com variância:

  • Diferentes sementes aleatórias
  • Diferentes amostras no conjunto de teste
  • Decodificação estocástica (stochastic decoding) (para LLMs)
  • Não independência (múltiplos exemplos por usuário)

Boas práticas:

  • Reporte intervalos de confiança (confidence intervals) (reamostragem bootstrap (bootstrap) é comum)
  • Use testes pareados (paired tests) ao comparar modelos nos mesmos exemplos
  • Corrija para múltiplas comparações (multiple comparisons) se você testou muitas variantes
  • Seja cético com pequenas melhorias sem suporte estatístico

Veja Reprodutibilidade e Significância Estatística para orientações mais profundas.

Exemplos Práticos

Exemplo 1: Evitando Vazamento no Pré-processamento (Classificação)

Um erro clássico é ajustar o pré-processamento no conjunto de dados inteiro (treino + teste). Por exemplo, escalar atributos usando a média/variância globais vaza informação da distribuição de teste.

Abordagem correta: ajustar o pré-processamento apenas no conjunto de treinamento, aplicar em validação/teste.

from sklearn.model_selection import train_test_split
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import f1_score

X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, stratify=y, random_state=0
)

clf = make_pipeline(
    StandardScaler(),              # fit only on X_train inside the pipeline
    LogisticRegression(max_iter=1000)
)

clf.fit(X_train, y_train)
y_pred = clf.predict(X_test)

print("Test F1:", f1_score(y_test, y_pred))

Se, em vez disso, você escalasse X antes de dividir, seu desempenho no teste poderia ser artificialmente inflado.

Exemplo 2: Divisão Baseada em Tempo (Previsão/Fraude)

Suponha que você esteja prevendo fraude em transações. Uma avaliação realista treina em meses passados e testa em meses posteriores:

# Pseudocode
train = data[data["date"] < "2025-01-01"]
test  = data[(data["date"] >= "2025-01-01") & (data["date"] < "2025-02-01")]

# Train on train, evaluate on test

Isso evita treinar em padrões que só aparecem no futuro. Também expõe deriva de conceito (concept drift) — degradação de desempenho devido a mudanças de comportamento.

Exemplo 3: Métricas Offline de Ranqueamento em Recomendação (e sua Armadilha)

Você pode calcular NDCG@10 em interações registradas e ver um ganho, mas em produção o modelo tem desempenho pior porque:

  • Dados registrados são enviesados para itens aos quais o sistema antigo deu exposição
  • O novo modelo muda a exposição, alterando qual feedback você obtém
  • Usuários reagem ao layout da página inteira e à novidade, não a itens isolados

A avaliação offline ainda é útil para iteração, mas para recomendação frequentemente precisa ser complementada com testes online ou métodos contrafactuais (counterfactual methods).

Armadilhas Comuns na Avaliação Offline (e Como Evitá-las)

1) Vazamento de Dados (Direto e Indireto)

Vazamento ocorre quando informações indisponíveis no momento de inferência são usadas durante treinamento/avaliação.

Formas comuns:

  • Vazamento do alvo (target leakage): atributos codificam o rótulo (por exemplo, “shipped_date” prevendo “delivered”)
  • Vazamento por duplicata (duplicate leakage): exemplos quase duplicados aparecem em treino e teste
  • Vazamento no pré-processamento (preprocessing leakage): normalização/seleção de atributos feita nos dados completos
  • Vazamento com humano no loop (human-in-the-loop leakage): análise manual de erros no conjunto de teste leva a mudanças iterativas

Mitigações:

  • Use pipeline (pipeline) que ajustem transformações apenas nos dados de treinamento
  • Remova duplicatas e verifique similaridade entre divisões
  • Aplique restrições de agrupamento (usuário/paciente/documento)
  • Trate o conjunto de teste como protegido contra escrita

Para cenários de testes de referência, veja Contaminação do Conjunto de Teste.

2) Sobreajuste ao Conjunto de Validação/Teste

Mesmo sem treinar no conjunto de teste, iteração repetida pode sobreajustar a ele:

  • Testar muitas variantes de modelo e reportar o melhor resultado no teste
  • Ajustar instruções contra um teste de referência público
  • Selecionar parâmetros de decodificação (decoding parameters) no conjunto de teste

Mitigações:

  • Mantenha uma retenção final (final holdout) usada uma única vez
  • Use validação cruzada aninhada ao fazer seleção extensa
  • Pré-registre (pre-register) o protocolo de avaliação (comum em estudos rigorosos)
  • Para placares, confie em conjuntos de teste ocultos/privados (Placares)

3) Mudança de Distribuição: “Meu Conjunto de Teste Não São Meus Usuários”

A avaliação offline frequentemente assume que a distribuição de teste coincide com a implantação. Violações incluem:

  • Populações de usuários diferentes
  • Idiomas/domínios diferentes
  • Sensores/câmeras alterados
  • Efeitos sazonais
  • Mudanças de política causando ciclos de realimentação (feedback loops)

Mitigações:

  • Construa conjuntos de teste que representem as condições esperadas
  • Adicione testes de estresse e recortes com deslocamento
  • Mantenha múltiplos conjuntos de teste: “na distribuição” + conjuntos de “robustez”
    Veja Avaliação Robusta.

4) Ruído de Rótulo, Ambiguidade e Verdade de Base Inconsistente

Pontuações offline podem ser limitadas pela qualidade dos rótulos:

  • Tarefas ambíguas (toxicidade, sentimento, “utilidade”)
  • Deriva nas diretrizes de anotação
  • Baixa concordância entre anotadores (inter-annotator agreement)

Mitigações:

  • Meça concordância e audite a qualidade dos rótulos
  • Use adjudicação ou distribuições multi-rótulo quando apropriado
  • Para tarefas subjetivas, considere Avaliação Humana

5) Mau Uso e Desalinhamento de Métricas

Exemplos:

  • Reportar acurácia em um problema desbalanceado 99:1
  • Usar AUROC quando você se importa com alta precisão sob baixa taxa de falso positivo
  • Reportar desempenho médio ignorando recortes críticos de pior caso
  • Otimizar ROUGE para sumarização enquanto a factualidade degrada

Mitigações:

  • Escolha métricas atreladas a custos e restrições reais
  • Reporte múltiplas métricas complementares (por exemplo, AUPRC + calibração)
  • Faça avaliação por recorte para subpopulações importantes
  • Observe efeitos de Goodhart (Lei de Goodhart nas Métricas)

6) Graus de Liberdade Ocultos no Protocolo

Duas equipes podem alegar avaliar no “mesmo conjunto de teste”, mas diferir em:

  • Regras de filtragem (cortes de comprimento, detecção de idioma)
  • Pré-processamento (tokenização (tokenization), normalização (normalization))
  • Pós-processamento (post-processing) (remoção de duplicatas nas saídas, truncamento)
  • Tratamento de saídas inválidas/timeouts
  • Se usam ferramentas externas ou recuperação (retrieval)

Mitigações:

  • Especifique o protocolo com precisão
  • Versione conjuntos de dados e código
  • Use arcabouços de avaliação (evaluation harnesses) com configurações fixas
  • Registre configuração do modelo e aleatoriedade

Avaliação Offline para Sistemas Modernos com LLM: Considerações Extras

Sistemas baseados em modelos de linguagem de grande porte frequentemente incluem recuperação, ferramentas e raciocínio em múltiplas etapas. A avaliação offline deve definir o que é fixo.

Perguntas-chave:

  • Você avalia o modelo base ou o sistema (instrução + recuperação + ferramentas)?
  • O corpus de recuperação é fixo e versionado?
  • Você está medindo factualidade (factuality), fundamentação (groundedness) e comportamento de recusa (refusal behavior)?

Conjuntos de teste offline para aplicações de LLM podem incluir:

  • Pares consulta + resposta de referência
  • Consulta + documentos permitidos (para geração aumentada por recuperação (retrieval-augmented generation, RAG)) + citações esperadas
  • Instruções adversariais e casos de conformidade com políticas (veja Avaliação de Segurança)

Para pontuação baseada em juiz, veja Modelo de Linguagem de Grande Porte como Juiz: isso pode escalar a avaliação, mas introduz preocupações de calibração e viés.

Checklist de Boas Práticas

Projetando o conjunto de teste

  • Correspondência com a distribuição de implantação (ou defina explicitamente o que ele representa)
  • Use divisões por grupo/temporais quando necessário
  • Remova duplicatas e verifique quase duplicatas entre divisões
  • Garanta que os rótulos sejam confiáveis; meça concordância quando for subjetivo

Definindo o protocolo

  • Fixe métricas, agregação, limiares e tratamento de saídas inválidas
  • Versione tudo (instantâneos de dados, código, checkpoint do modelo, instruções)
  • Separe dev/teste de forma limpa; trate o teste como imutável

Reportando resultados

  • Forneça intervalos de confiança ou testes estatísticos
  • Reporte múltiplas métricas quando trade-offs importarem
  • Inclua análises por recorte e análise qualitativa de erros
  • Documente limitações e incompatibilidades conhecidas com o uso no mundo real

Protegendo contra “sobreajuste a testes de referência (benchmark overfitting)”

  • Minimize iterações no conjunto de teste
  • Prefira conjuntos de teste privados/ocultos em cenários competitivos
  • Atualize conjuntos de teste ou adicione conjuntos de desafio ao longo do tempo
  • Observe contaminação e memorização (Contaminação do Conjunto de Teste)

Quando a Avaliação Offline Não É Suficiente

A avaliação offline é indispensável para iteração rápida e comparações controladas, mas pode não capturar:

  • Comportamento real de usuários, ciclos de realimentação e incentivos
  • Falhas de cauda longa (long-tail) não cobertas no conjunto de teste
  • Restrições operacionais (latência (latency), custo, confiabilidade)
  • Não-estacionariedade (non-stationarity) e deriva

Uma estratégia saudável de avaliação trata a avaliação offline como uma base — e então a complementa com verificações de robustez (Avaliação Robusta), análise cuidadosa de significância (Reprodutibilidade e Significância Estatística) e (quando apropriado) avaliação online ou centrada em humanos (Avaliação Humana).