Pular para conteúdo

Capítulo 2.11 — Avaliação de LLMs

🎯 Objetivo

Mostrar que avaliar LLMs é diferente e mais difícil do que avaliar modelos clássicos. ML tradicional tem ground truth, métricas estáveis e benchmarks consagrados. LLM tem ground truth muitas vezes ambígua, várias respostas igualmente válidas, sensibilidade alta a prompt e janela de contexto, e muito espaço para falha silenciosa.

Avaliação de LLM não é o passo final do projeto; é um sistema que roda ao lado, com seus próprios datasets, gatekeepers e métricas.

🧠 Tipos de dataset

Dataset O que é Para quê
Golden Casos reais curados, com input + resposta esperada Verdade prática para regressão
Synthetic Casos gerados automaticamente Cobrir distribuições e edge cases
Adversarial Casos hostis (injection, OOD, ambiguidade) Testar defesa em profundidade
Regression Casos que precisam continuar passando Bloquear release que quebra comportamento previamente correto
Production traces (redigidos) Réplica anonimizada do tráfego real Garantir que o eval reflete o mundo

Boas práticas de dataset:

  • Versionar com semver: golden_support_v3, adversarial_pi_v2.
  • Documentar origem, critério de inclusão, viés conhecido.
  • Não treinar com o dataset que vai avaliar (válido para FT e para LLM-as-judge).
  • Atualizar com novos incidentes: cada incidente vira caso de eval para que nunca mais aconteça em silêncio.

🧪 Tipos de teste

  • Unit - tools, parsers, formatadores.
  • Contract - schemas, function calling, structured outputs.
  • Integration - pipeline ponta-a-ponta com dependências reais.
  • End-to-end - tarefa do usuário, do prompt à resposta final.
  • Prompt regression - comparar versão N vs N-1 em casos estáveis.
  • Policy - testes positivos e negativos em policy-as-code (ver Cap. 4.7).
  • Security - prompt injection direta e indireta, DLP, tenant isolation.
  • Cost / latency - guard rails em custo por tarefa, p95.
  • Replay de traces - re-executar tráfego histórico contra a versão candidata e medir diferença.

🤖 LLM-as-a-judge (com cautela)

Usar um LLM para julgar a saída de outro LLM funciona em vários contextos, principalmente para avaliação subjetiva (qualidade de resumo, fidelidade a tom, faithfulness). Mas não é mágico:

  • Vieses do juiz propagam para a métrica (preferência por respostas longas, por estilo confiante, por respostas com listas, etc.).
  • Custo. Em escala, o juiz pode ser tão caro quanto o avaliado.
  • Auto-favorecimento. Modelos tendem a preferir respostas similares às que eles mesmos produziriam; evite usar o mesmo modelo para gerar e julgar.
  • Rubrica clara. Sem rubrica escrita, o juiz vira gerador de número aleatório calibrado.

Padrão recomendado:

  1. Defina rubrica em texto com critérios objetivos.
  2. Use um modelo diferente do avaliado quando possível.
  3. Calibre o juiz contra anotação humana em amostra (kappa, correlação).
  4. Use o juiz para escala, mas reserve revisão humana para amostras críticas e para casos de discordância alta.

👥 Human evaluation e governança de golden set

Avaliação automática não substitui revisão humana em domínios sensíveis (jurídico, financeiro, médico, suporte com impacto operacional). Princípios para fazer essa avaliação direito:

  • Rotuladores treinados. Forneça rubrica e exemplos. Sem isso, cada anotador inventa o critério.
  • Inter-annotator agreement. Meça concordância (Cohen's κ, Fleiss' κ) e investigue casos de discordância: ou a rubrica é ambígua, ou o caso é genuinamente difícil - os dois ensinam.
  • Sample suficiente, não absurdo. Amostras pequenas e bem rotuladas batem amostras grandes ruidosas.
  • Disagreement como sinal. Casos onde anotadores divergem costumam ser exatamente onde o modelo também erra.
  • Atualização do golden set. Datasets de avaliação envelhecem: novas verticais, novas regras, novas violações. Trate como artefato vivo, com owner, ciclo de revisão e changelog.
  • Overfitting ao benchmark interno. Quanto mais o time itera contra o mesmo dataset, maior a chance de melhorar nele sem melhorar em produção. Reserve uma fração holdout, nunca usada para iterar, apenas para validar antes de release.
  • Governança de traces de produção em eval. Se você reusa traces como golden set:
  • garanta redaction de PII;
  • documente a base legal para retenção;
  • declare que o tráfego do cliente pode aparecer agregado em eval;
  • dê caminhos de opt-out quando aplicável.

Em domínios de alto risco, a regra é simples: avaliação automática prepara, humana decide. O eval contínuo filtra; a revisão humana valida o que vai para release.

📊 Métricas frequentes

  • Task success rate.
  • Groundedness / faithfulness.
  • Hallucination rate.
  • Tool call accuracy.
  • Schema validity.
  • Citation coverage.
  • Retrieval precision/recall, NDCG, MRR.
  • Cost por tarefa / por sucesso.
  • Latency p95/p99.
  • Policy violation rate.
  • Escalation rate (HITL), fallback rate.

📌 Checklist

  • [ ] Há golden, adversarial e regression set versionados?
  • [ ] Há eval rodando em CI antes de promover prompt/modelo/tool?
  • [ ] Há revisão humana em amostra para domínios sensíveis?
  • [ ] LLM-as-judge usa modelo diferente e rubrica documentada?
  • [ ] Existe holdout que nunca é usado para iterar?

📚 Referências