Avaliação de LLMs: como saber se seu sistema está funcionando

Na série sobre arquitetura de IA eu falei bastante sobre RAG, fine-tuning e deploy — mas deixei passar um tema que sustenta todos os outros: como saber se qualquer mudança que você faz no sistema está tornando ele melhor ou pior. Sem isso, cada ajuste de prompt, cada troca de modelo, cada nova versão de contexto é uma aposta às cegas.

Esse processo tem nome: avaliação, ou "evals". E ele é sistematicamente subestimado, mesmo por times técnicos experientes, porque parece menos urgente do que fazer o sistema funcionar no primeiro lugar.

Por que "parece bom" não é suficiente

Testar um sistema de IA manualmente, digitando algumas perguntas e olhando as respostas, funciona para pegar erros óbvios. Não funciona para detectar regressões sutis — quando uma mudança melhora 80% dos casos e piora 5%, só que os 5% que pioraram eram justamente os casos mais importantes para o seu negócio. Sem um processo sistemático, essas regressões só aparecem quando um usuário real reclama, o que já é tarde.

Os três tipos de avaliação que importam

O primeiro é avaliação baseada em referência: você tem um conjunto de perguntas com respostas corretas conhecidas (um "golden dataset") e mede a taxa de acerto a cada mudança. É o mais confiável, mas só funciona para tarefas com resposta objetiva — classificação, extração de dados, respostas factuais verificáveis.

O segundo é LLM-as-judge: usar um modelo (geralmente mais forte ou mais caro) para avaliar a qualidade da resposta de outro modelo, segundo critérios definidos por você. Funciona bem para tarefas mais subjetivas — tom, completude, aderência a um formato — mas exige calibração cuidadosa, porque o modelo-juiz também erra e tem vieses próprios.

O terceiro é avaliação humana amostral: revisar manualmente uma amostra pequena e representativa de interações reais, periodicamente. Não escala para todo o volume, mas é insubstituível para pegar problemas que os dois métodos anteriores não capturam — coisas que só um humano familiarizado com o negócio percebe como erradas.

Montando o golden dataset

O erro mais comum aqui é criar um dataset pequeno demais ou tendencioso — só com os casos fáceis. Um bom golden dataset tem no mínimo alguns exemplos de cada categoria de caso que o sistema vai encontrar: os típicos, os de borda (edge cases), os adversariais (usuários tentando confundir o sistema) e os que o sistema historicamente errou. Esse último grupo é o mais valioso: cada bug real que aparece em produção deveria virar um caso de teste permanente, para garantir que ele nunca volte silenciosamente numa versão futura.

Rodando isso no dia a dia

A prática que funciona na maioria dos times que acompanho é simples: toda mudança relevante em prompt, modelo ou pipeline de RAG roda contra o golden dataset antes de ir para produção, como um teste automatizado qualquer. Se a métrica cair, a mudança é revisada antes de seguir. Isso transforma "acho que melhorou" em "melhorou 3 pontos percentuais na categoria X, mas piorou 1 ponto na categoria Y" — uma conversa muito mais produtiva.

Avaliação não é um projeto à parte que você faz quando sobra tempo. É a infraestrutura que permite que todo o resto — RAG, fine-tuning, prompt engineering — evolua com segurança em vez de por sorte.