Avaliação em IA é enganosamente difícil porque a coisa que você está tentando medir — "essa saída é boa?" — é frequentemente subjetiva, dependente de contexto e multidimensional. A resposta de um modelo para "explique emaranhamento quântico" pode ser precisa mas técnica demais para o público, ou acessível mas levemente errada, ou perfeitamente correta mas entediante. Testes de software tradicionais têm critérios claros de passa/não-passa. Avaliação de IA raramente tem. É por isso que o campo desenvolveu múltiplas abordagens complementares: benchmarks automatizados para medição ampla de capacidade, avaliação humana para julgamento de qualidade, LLM-como-juiz para aproximações escaláveis de julgamento humano, e métricas específicas de tarefa para domínios estreitos. Nenhuma abordagem única é suficiente. As equipes que avaliam bem usam todas em camadas.
Benchmarks públicos como MMLU, HumanEval, MATH e GPQA dão uma forma padronizada de comparar modelos em tarefas bem definidas. São úteis para ter uma noção geral das capacidades de um modelo e para acompanhar progresso ao longo do tempo. Mas têm limitações sérias que você precisa entender antes de depender deles. Contaminação de benchmark é disseminada — dados de treinamento frequentemente incluem questões de benchmark, então pontuações altas podem refletir memorização em vez de capacidade. Saturação de benchmark significa que quando a maioria dos modelos de fronteira pontua acima de 90% em um teste, ele para de ser informativo. E o problema mais fundamental é que benchmarks testam habilidades estreitas e bem definidas, enquanto aplicações reais exigem raciocínio amplo, confuso e dependente de contexto. Um modelo que pontua 92% no MMLU e 87% no HumanEval ainda pode ser terrível para seu caso de uso específico — escrever controllers Symfony, resumir documentos jurídicos em francês ou gerar SQL para seu schema particular. Benchmarks dizem o que um modelo pode fazer em geral. Suas próprias avaliações dizem o que ele pode fazer para você.
O trabalho de avaliação mais valioso que você pode fazer é construir uma suíte de testes específica para sua aplicação. Comece coletando 50 a 100 exemplos reais de inputs que seu sistema verá, junto com o que uma boa saída parece. Podem ser consultas reais de usuários, casos extremos sintéticos ou inputs adversariais que sondent modos de falha conhecidos. Para cada exemplo, defina o que "correto" significa da forma mais concreta possível — palavras-chave esperadas, estrutura requerida, afirmações factuais que devem estar presentes ou ausentes, critérios de tom. Depois automatize a avaliação: rode seu prompt contra cada exemplo, pontue as saídas (usando correspondência exata, regex ou um LLM-como-juiz) e acompanhe os resultados ao longo do tempo. Ferramentas como Braintrust, Langfuse e Promptfoo facilitam isso, mas você também pode construir com uma planilha e um script. O ponto é ter um processo repetível para que quando você mude um prompt, troque um modelo ou atualize seu pipeline de recuperação, possa ver imediatamente se as coisas melhoraram ou pioraram.
Usar um LLM para avaliar a saída de outro LLM — o padrão "LLM-como-juiz" — se tornou a abordagem padrão para avaliação escalável. Você dá a um modelo forte (tipicamente GPT-4 ou Claude) a pergunta original, a resposta do modelo e uma rúbrica, e pede que pontue a resposta em critérios como precisão, utilidade e segurança. Funciona surpreendentemente bem para muitas tarefas, especialmente quando você fornece rúbricas detalhadas e exemplos de calibração. Mas tem pontos cegos: juízes LLM tendem a preferir respostas mais longas, podem perder erros factuais sutis e exibem viés de posição (favorecendo a resposta que aparece primeiro numa comparação par a par). Avaliação humana permanece o padrão ouro para aplicações sensíveis à qualidade. Serviços como Scale AI e Surge fornecem anotadores treinados, mas mesmo revisão humana informal — ter três membros da equipe avaliando independentemente 50 saídas — pega modos de falha que avaliação automatizada não pega. Os pipelines de avaliação mais robustos usam métricas automatizadas como filtro rápido, LLM-como-juiz para decisões de média confiança, e revisão humana para casos de alta importância ou ambíguos.
A parte mais difícil da avaliação não é técnica — é cultural. Equipes que entregam ótimos produtos de IA tratam avaliação como uma disciplina de engenharia de primeira classe, não uma consideração tardia. Escrevem avaliações antes de escrever prompts, da mesma forma que bons desenvolvedores escrevem testes antes de escrever código. Mantêm suítes de avaliação vivas que crescem conforme descobrem novos modos de falha em produção. E resistem à tentação de otimizar para pontuações de benchmark à custa de performance no mundo real. Se seu modelo gabarita sua suíte de avaliação mas usuários estão reclamando, suas avaliações estão erradas, não seus usuários. Os melhores frameworks de avaliação são os que mantêm você honesto sobre o que seu sistema realmente faz, especialmente nos casos em que ele falha.