21  Avaliação, Escala e Próximos Passos

Métricas de avaliação como Perplexidade, salvamento de checkpoints, introdução ao Fine-Tuning e considerações sobre ética e viés em IA.

22 Avaliação, Escala e Próximos Passos

Após a fase de treinamento de um Modelo de Linguagem (LLM), entramos em um estágio crítico que define a viabilidade, a qualidade e a responsabilidade do modelo. Este capítulo aborda como quantificar o desempenho (Avaliação), como garantir a persistência e continuidade do treinamento (Checkpoints), como especializar o modelo (Fine-Tuning) e, crucialmente, como mitigar riscos inerentes (Ética e Viés).

22.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.

22.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).

22.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.

22.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()

22.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

---

22.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.

22.2.1 O que salvar?

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

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

22.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)

---

22.3 3. Introdução ao Fine-Tuning (Ajuste Fino)

Após o Pre-training (onde o modelo aprende a estrutura da linguagem e conhecimento geral), o modelo geralmente não é bom em seguir instruções específicas. O Fine-Tuning é o processo de especialização.

22.3.1 3.1. Tipos de Fine-Tuning

1. Full Fine-Tuning: Atualiza todos os parâmetros do modelo. Requer alto poder computacional.
2. PEFT (Parameter-Efficient Fine-Tuning): Atualiza apenas uma pequena fração dos parâmetros ou adiciona camadas adaptadoras.
   • LoRA (Low-Rank Adaptation): A técnica mais popular atualmente. Congela os pesos do modelo base e treina matrizes de baixa ordem injetadas nas camadas de atenção.

22.3.2 3.2. Instruction Tuning

Transforma um modelo de “autocompletar texto” em um modelo de “assistente”. O dataset muda de texto bruto para pares de (Instrução, Resposta).

flowchart TD
    subgraph PreTraining [Pré-Treinamento]
        A[Corpus Massivo de Texto] --> B(Treinamento Auto-Supervisionado)
        B --> C[Base Model]
    end

    subgraph FineTuning [Fine-Tuning / PEFT]
        C --> D{Congelar Pesos Base}
        D --> E[Injetar Adaptadores LoRA]
        F[Dataset de Instruções] --> E
        E --> G(Treinamento Supervisionado)
        G --> H[Modelo Especializado]
    end
    
    style C fill:#f9f,stroke:#333
    style H fill:#90EE90,stroke:#333

---

22.4 4. Ética, Viés e Segurança em IA

A capacidade técnica de criar um modelo deve ser acompanhada pela responsabilidade de sua implantação. Modelos de linguagem aprendem padrões estatísticos dos dados, o que inclui preconceitos, estereótipos e informações falsas.

22.4.1 4.1. Viés nos Dados (Data Bias)

Se o dataset de treinamento contém predominantemente texto em inglês ocidental, o modelo terá um desempenho inferior e possíveis alucinações culturais ao tratar de outros contextos. * Mitigação: Curadoria de dados (Data Curation), balanceamento de fontes e filtragem de conteúdo tóxico antes do treinamento.

22.4.2 4.2. Alucinações (Hallucinations)

O modelo gera informações factualmente incorretas com alta confiança. * Causa: O modelo otimiza a probabilidade da próxima palavra, não a veracidade. * Mitigação: RAG (Retrieval-Augmented Generation) para ancorar o modelo em dados externos confiáveis.

22.4.3 4.3. Alinhamento (Alignment)

Garantir que o modelo aja de acordo com a intenção humana e normas de segurança. * RLHF (Reinforcement Learning from Human Feedback): Usa feedback humano para treinar um “Modelo de Recompensa” que pune respostas tóxicas, perigosas ou inúteis durante o fine-tuning.

22.4.4 Checklist de Segurança para Deploy

Área	Ação Necessária
Dados	Remover PII (Informações Pessoais Identificáveis) do dataset.
Avaliação	Testar contra benchmarks de toxicidade (ex: RealToxicityPrompts).
Guardrails	Implementar filtros de entrada/saída para bloquear tópicos sensíveis.
Transparência	Documentar as limitações do modelo (Model Card).

---

22.5 Conclusão do Capítulo

Neste capítulo, movemos o foco da arquitetura para a operacionalização. Aprendemos que a Perplexidade guia nossa avaliação de qualidade, os Checkpoints garantem a segurança do processo de treino, o Fine-Tuning adapta o modelo para o mundo real e as considerações de Ética são mandatórias para qualquer arquiteto de software moderno.

Próximos Passos: Com o modelo avaliado e ajustado, o próximo estágio lógico seria a Inferência Otimizada e o Deployment em produção (quantização, ONNX, vLLM).