Avaliação de LLMs: métricas que importam

Trocar de modelo ou de prompt sem avaliação é deploy às cegas. Para aplicações em produção, você precisa de métricas alinhadas ao que o usuário considera sucesso — não apenas perplexidade ou notas em benchmarks abertos.

O problema com benchmarks genéricos

MMLU, HellaSwag, HumanEval são úteis para comparar modelos em tarefas gerais. Mas eles não dizem se o seu assistente responde bem perguntas sobre as suas políticas internas, se mantém o tom de voz da sua marca, ou se consegue extrair dados estruturados dos seus documentos específicos. Um modelo com 95% no MMLU pode ter 60% de acurácia no seu domínio.

Por que benchmarks públicos não bastam

• Não cobrem o seu domínio específico (jurídico, médico, financeiro, etc)
• Não testam o formato de saída que você precisa (JSON, tabelas, citações)
• Não medem latência, custo ou taxa de recusa em casos reais
• Podem vazar para os dados de treino dos modelos (benchmark contamination)
• Não capturam requisitos de compliance ou segurança do seu contexto

Definição de sucesso com o negócio

Traduza requisitos em critérios testáveis: 'resposta deve citar a fonte correta', 'não pode inventar cláusula', 'deve responder em até N tokens', 'tom formal'. Isso vira rubrica humana ou checklist automatizado parcial.

Criando rubricas de avaliação

Uma rubrica é um conjunto de critérios específicos e mensuráveis. Exemplo para um assistente de RH: (1) Factualidade: resposta baseada apenas em documentos da empresa (peso 40%), (2) Completude: responde todas as partes da pergunta (peso 30%), (3) Tom: linguagem profissional e respeitosa (peso 15%), (4) Citação: inclui referências aos documentos fonte (peso 15%). Cada critério recebe nota 0-3, e você tem uma nota final ponderada.

Envolvendo stakeholders

Não defina métricas sozinho. Sente com: usuários finais (o que é uma boa resposta para eles?), especialistas no domínio (o que está factualmente correto?), compliance/legal (o que não pode ser dito?), e produto (qual métrica move o negócio?). Isso garante que você está otimizando para o que realmente importa.

Camadas de avaliação

Avaliação não é um único número. É uma pirâmide de camadas, cada uma testando um aspecto diferente do sistema.

1. Recuperação (para sistemas RAG)

• Precisão@k: dos k documentos retornados, quantos são relevantes?
• Recall@k: dos documentos relevantes no índice, quantos foram recuperados?
• MRR (Mean Reciprocal Rank): em que posição aparece o primeiro documento relevante?
• NDCG (Normalized Discounted Cumulative Gain): considera relevância gradual e posição

2. Geração (qualidade da resposta)

• Acurácia factual: humanos validam se a resposta está correta (gold standard)
• LLM-as-judge: usar GPT-4 para avaliar respostas segundo critérios definidos (complemento, não substituto)
• Conformidade com formato: se pediu JSON, retornou JSON válido?
• Groundedness: a resposta se baseia apenas no contexto fornecido?

3. Regressão (mudanças não quebraram o que funcionava)

Conjunto fixo de casos de teste (regression suite) que roda em CI após mudanças de: prompt, modelo, índice RAG, ou código de pós-processamento. Se a acurácia cair além de um threshold (ex: -5%), o deploy é bloqueado.

Construindo datasets de avaliação

Um bom dataset de avaliação é pequeno, mas representativo. Não precisa de 10 mil exemplos — 100 exemplos bem escolhidos valem mais.

Como construir seu dataset

• Casos comuns (70%): perguntas que você espera receber frequentemente
• Casos extremos (15%): edge cases, perguntas ambíguas, múltiplas interpretações
• Casos adversariais (10%): tentativas de quebrar o sistema, injection attacks
• Casos de 'não sei' (5%): perguntas onde a resposta correta é admitir falta de informação

Fontes de dados

Onde encontrar casos de teste: logs de perguntas reais de usuários (quando disponível), perguntas simuladas por especialistas no domínio, queries sintéticas geradas por LLM (validadas por humanos), e casos de falha reportados pelo suporte.

LLM-as-judge: quando usar e quando não usar

Usar um LLM para avaliar outro LLM é tentador: escala facilmente e é mais barato que anotação humana. Mas tem armadilhas.

Quando LLM-as-judge funciona bem

• Critérios objetivos: 'resposta contém uma citação?', 'formato é JSON válido?'
• Comparação de pares: qual de duas respostas é melhor?
• Rubrica bem definida: com exemplos de notas 1, 2, 3 para cada critério
• Volume alto: quando você tem milhares de casos e não pode validar todos manualmente

Quando LLM-as-judge falha

LLM-as-judge tem vieses: prefere respostas mais longas, prefere respostas do próprio modelo (GPT-4 avaliando GPT-4), tem dificuldade com nuance e contexto cultural, e pode ser manipulado (o modelo avaliado aprende a 'enganar' o juiz). Use sempre em conjunto com validação humana em amostra.

Sinais em produção: o que realmente importa

Métricas offline (no dataset de teste) são importantes, mas não substituem métricas online (em produção). Usuários reais têm comportamentos que você não antecipou.

Métricas comportamentais

• Thumbs up/down: usuários avaliam se a resposta foi útil
• Taxa de abandono: % de usuários que saem após ver a resposta
• Follow-up rate: usuário refaz a pergunta de forma diferente? (sinal de resposta ruim)
• Time-to-next-action: quanto tempo até o usuário fazer algo após a resposta?
• Copy rate: % de respostas que usuários copiam (sinal de utilidade)

Métricas técnicas

• Latência p50, p95, p99: distribuição de tempo de resposta
• Taxa de erro: % de queries que falharam com erro técnico
• Taxa de recusa: % de queries onde o modelo disse 'não sei'
• Custo por query: para monitorar OPEX e identificar queries caras
• Taxa de citação: % de respostas que incluíram referências (em RAG)

Testes A/B e experimentos controlados

Quando você tem tráfego significativo, testes A/B são a melhor forma de validar mudanças. Divida usuários em: grupo controle (modelo/prompt atual) e grupo tratamento (nova versão). Compare métricas comportamentais entre os grupos.

Boas práticas para A/B em LLMs

• Tamanho de amostra: precisa de centenas/milhares de queries para significância estatística
• Duração: rode por pelo menos 1 semana para capturar variação temporal
• Segmentação: usuários novos vs recorrentes podem reagir diferente
• Multiple testing: se testar muitas variantes, ajuste para false positive rate
• Cuidado com métricas de vaidade: mais tokens não significa melhor resposta

Ferramentas para avaliação de LLMs

• PromptFoo: framework open-source para testes e comparação de prompts
• LangSmith: datasets de avaliação, comparação de runs, LLM-as-judge integrado
• Ragas: métricas específicas para RAG (faithfulness, answer relevancy, context recall)
• DeepEval: similar ao Pytest, mas para LLMs — testes automatizados com asserções
• Phoenix (Arize): análise de embeddings, detecção de drift, traces

Conclusão

Avaliação não é uma métrica única, é um sistema. Combine: métricas offline (dataset de teste), LLM-as-judge (com validação humana), métricas online (produção), e feedback direto dos usuários. Defina sucesso com stakeholders, não sozinho. E sempre tenha um regression suite para não quebrar o que já funciona.

Lembre-se: o objetivo não é maximizar uma métrica de benchmark. O objetivo é construir algo que usuários reais considerem útil, confiável e que o negócio possa sustentar economicamente.