14 Avaliação, Checkpoints e Escala

Este capítulo apresenta métricas de linguagem, avaliação em múltiplas camadas e checkpoints reproduzíveis.

Após o treinamento, é preciso quantificar desempenho, comparar configurações de forma justa e preservar o estado necessário para retomar experimentos. Essas práticas conectam pesquisa, reprodutibilidade e operação.

14.1 1. Métricas de Avaliação: Perplexidade e Loss

Ao contrário de tarefas de classificação binária onde a “acurácia” é uma métrica clara, modelos generativos requerem métricas que avaliem a probabilidade das sequências geradas.

14.1.1 1.1. Cross-Entropy Loss (Perda de Entropia Cruzada)

A função de perda fundamental durante o treinamento é a Cross-Entropy Loss. Ela mede a diferença entre a distribuição de probabilidade prevista pelo modelo e a distribuição real (o próximo token correto).

14.1.2 1.2. Perplexidade (Perplexity - PPL)

A Perplexidade é a métrica padrão-ouro para avaliar modelos de linguagem autoregressivos. Intuitivamente, ela mede o quão “surpreso” o modelo fica ao ver novos dados. * Definição Matemática: A perplexidade é a exponenciação da perda de entropia cruzada média. \[ PPL = e^{Loss} \] * Interpretação: * Uma PPL baixa indica que o modelo atribui alta probabilidade ao próximo token correto. * Uma PPL de 1 seria um modelo perfeito (certeza absoluta). * Uma PPL igual ao tamanho do vocabulário indica que o modelo está “chutando” aleatoriamente.

14.1.2.1 Exemplo de Implementação (PyTorch)

import torch
import torch.nn.functional as F

def calculate_perplexity(logits, targets):
    """
    Calcula a perplexidade dado os logits do modelo e os tokens alvo.
    
    Args:
        logits: Saída crua do modelo [batch_size, seq_len, vocab_size]
        targets: Tokens reais [batch_size, seq_len]
    
    Returns:
        float: Valor da perplexidade
    """
    # Redimensionar para compatibilidade com cross_entropy
    # [batch_size * seq_len, vocab_size]
    logits_flat = logits.view(-1, logits.size(-1))
    targets_flat = targets.view(-1)
    
    # Calcular Cross Entropy Loss
    loss = F.cross_entropy(logits_flat, targets_flat)
    
    # Calcular Perplexidade
    perplexity = torch.exp(loss)
    
    return perplexity.item()

14.1.3 Fluxo de Avaliação

graph LR
    A[Dataset de Validação] --> B(Modelo)
    B --> C{Logits}
    C --> D[Cálculo de Loss]
    D --> E[Cálculo de Perplexidade]
    E --> F[Métrica Final]
    style F fill:#90EE90,stroke:#333,stroke-width:2px

14.2 2. Salvamento de Checkpoints (Persistência)

O treinamento de LLMs é computacionalmente custoso e propenso a falhas de hardware. O salvamento de checkpoints não serve apenas para salvar o modelo final, mas para permitir a retomada do treinamento (resuming) e a análise de overfitting.

14.2.1 O que salvar?

Um checkpoint robusto deve conter mais do que apenas os pesos do modelo (state_dict).

Pesos do Modelo: Parâmetros aprendidos.
Estado do Otimizador: Momentos e variância (essencial para AdamW).
Estado do Scheduler: Learning rate atual.
Metadados: Número da época, step atual e valor da loss.

14.2.1.1 Estratégia de Salvamento

import os

def save_checkpoint(model, optimizer, scheduler, epoch, loss, path="checkpoints"):
    if not os.path.exists(path):
        os.makedirs(path)
        
    checkpoint = {
        'epoch': epoch,
        'model_state_dict': model.state_dict(),
        'optimizer_state_dict': optimizer.state_dict(),
        'scheduler_state_dict': scheduler.state_dict(),
        'loss': loss,
    }
    
    file_name = f"{path}/checkpoint_epoch_{epoch}.pt"
    torch.save(checkpoint, file_name)
    print(f"Checkpoint salvo em: {file_name}")

# Exemplo de uso no loop de treino
# save_checkpoint(model, optimizer, scheduler, current_epoch, current_loss)

14.3 Conclusão do Capítulo

Perplexidade e perda ajudam a acompanhar a modelagem de tokens, mas devem ser complementadas por tarefas, revisão humana e testes de sistema. Checkpoints preservam o progresso e tornam comparações e retomadas mais confiáveis.

14.4 Avaliação em múltiplas camadas

Perplexidade compara a previsão de tokens sob o mesmo tokenizer e corpus, mas não mede sozinha utilidade, segurança ou factualidade. Uma avaliação completa combina métricas intrínsecas, tarefas automáticas, revisão humana e testes do sistema integrado. Compare modelos com a mesma preparação de dados para não atribuir ao modelo uma diferença causada pela tokenização.

Separe um conjunto de teste antes de ajustar hiperparâmetros. Use validação durante o desenvolvimento e consulte o teste apenas nas decisões finais. Documente versão do checkpoint, prompt, parâmetros de geração, dependências e semente; sem isso, uma pontuação isolada não é reproduzível.

Checkpoint não é apenas o modelo

Para retomar treinamento de forma fiel, salve também estado do otimizador e scheduler, scaler de precisão mista, passo global e estados aleatórios. Para inferência, pesos, configuração e tokenizer compatível são o mínimo necessário.

14.5 Uma pirâmide de avaliação

Avaliações baratas e frequentes devem ficar na base; avaliações caras e contextualizadas, no topo. Durante o treino, loss e perplexidade detectam regressões rapidamente. Depois, tarefas automáticas medem capacidades específicas. Amostras humanas avaliam utilidade, clareza e critérios difíceis de codificar. Por fim, testes do sistema verificam recuperação, ferramentas, permissões, latência e falhas em produção.

flowchart BT
    A[Loss e perplexidade] --> B[Tarefas automáticas]
    B --> C[Avaliação humana]
    C --> D[Testes adversariais e de sistema]

Nenhuma camada substitui as demais. Uma perplexidade menor pode não melhorar instruções; uma preferência humana pode favorecer estilo sem detectar erro factual; um benchmark pode estar contaminado pelos dados de treino.

14.5.1 Incerteza e intervalos

Uma média sem variabilidade pode induzir conclusões frágeis. Para acurácia em \(n\) exemplos, use intervalos de confiança ou bootstrap. Ao comparar dois modelos, avalie-os nos mesmos itens e examine a distribuição das diferenças. Pequenos ganhos podem desaparecer com outra semente, prompt ou amostra.

14.5.2 Avaliação de geração aberta

Textos podem ter várias respostas válidas. Métricas baseadas em sobreposição lexical penalizam paráfrases corretas, enquanto avaliadores baseados em modelos podem introduzir preferência por estilo, ordem ou verbosidade. Defina rubricas com critérios observáveis e calibre avaliadores automáticos contra julgamentos humanos.

Dimensão	Pergunta operacional
Correção	As afirmações podem ser verificadas?
Relevância	A resposta atende ao pedido sem desvios?
Robustez	Pequenas reformulações preservam o resultado?
Segurança	Entradas adversariais atravessam controles?
Eficiência	Latência e memória atendem ao orçamento?

14.6 Estratégia de checkpoints

Salvar a cada intervalo fixo simplifica a retomada, mas pode consumir armazenamento excessivo. Uma política prática conserva o melhor checkpoint de validação, o mais recente e alguns marcos espaçados. Grave primeiro em arquivo temporário e finalize com operação atômica para reduzir risco de corrupção.

Teste a restauração

Um checkpoint só é confiável depois de carregado. Automatize um teste que restaura o estado, executa um lote conhecido e confirma passo global, taxa de aprendizado e saída esperada dentro de tolerância.