Neste artigo
- O que são evals e por que quase todo projeto de IA os ignora
- Quando construir o conjunto de avaliação
- Como montar um conjunto de avaliação que serve para algo
- Evals automáticos versus evals com julgamento humano
- O que esperar de um bom conjunto de avaliação
- O impacto de ir para produção sem evals definidos
- Dúvidas comuns sobre evals para IA
- Conclusão e próximo passo
Você ajusta o prompt, testa algumas vezes no playground, os resultados parecem bons e o modelo vai para produção. Duas semanas depois, alguém da equipe de suporte manda uma print de uma resposta completamente errada. Você abre o histórico, tenta reproduzir, não consegue. Não dá pra saber se sempre foi assim ou se algo mudou.
Esse ciclo é mais comum do que parece. E quase sempre não é problema do modelo. O problema é que ninguém definiu o que ‘funcionar’ significa antes do deploy.
Trabalho com ML em produção há alguns anos, e o padrão que vejo repetir é o seguinte: times investem semanas em fine-tuning ou engenharia de prompt e zero horas em definir como vão medir o resultado. Aí chegam em mim perguntando por que o modelo ‘degradou’. Spoiler: ele não degradou. Vocês nunca souberam como estava.
Os evals para IA, ou conjuntos de avaliação, são a etapa que separa um projeto que você consegue operar de um que você só torce para continuar funcionando. Neste artigo, você vai entender o que são, quando montar, como estruturar e o que esperar de um conjunto de avaliação que realmente serve para alguma coisa.
O que são evals e por que quase todo projeto de IA os ignora
Um conjunto de avaliação, ou eval set, é uma coleção de entradas com saídas esperadas e critérios claros de julgamento. Você usa para medir, de forma repetível, se o modelo está entregando o que o produto precisa.
Não é uma lista de exemplos bonitos que funcionaram bem no desenvolvimento. É uma amostra representativa dos casos reais, incluindo os difíceis, os ambíguos e os que já quebraram antes.
A maioria dos times ignora evals porque eles dão trabalho antes de existir qualquer resultado visível. É mais fácil testar manualmente, aprovar o que parece bom e partir para o próximo problema. O custo disso aparece mais tarde, quando você precisa trocar de modelo, ajustar o prompt ou escalar o produto e não tem como saber se a mudança melhorou ou piorou.
Quando construir o conjunto de avaliação
Antes de começar a ajustar qualquer modelo. Essa é a resposta que a maioria não quer ouvir.
O raciocínio é simples: se você monta os evals depois, corre o risco de construir exemplos que favorecem o comportamento atual do modelo, não o comportamento que o produto precisa. Você tendencia o julgamento sem perceber.
Na prática, o momento certo é logo após definir o objetivo da feature. Antes de escolher modelo, antes de engenharia de prompt, antes de qualquer experimento. A pergunta que precisa ter resposta antes de qualquer outra é: como a gente vai saber que funcionou?
Como montar um conjunto de avaliação que serve para algo
Defina o critério antes dos exemplos
O erro mais comum é coletar exemplos primeiro e tentar criar um critério de julgamento depois. Acontece que os exemplos moldam o critério de um jeito que você não percebe.
O caminho correto é o inverso. Primeiro, escreva em linguagem simples o que torna uma resposta boa e o que torna uma resposta inaceitável. Esse critério precisa ser específico o suficiente para que duas pessoas diferentes cheguem ao mesmo julgamento lendo a mesma saída.
Se você não consegue escrever esse critério sem ambiguidade, o problema não é o modelo. É a falta de clareza sobre o que o produto precisa.
Quantos exemplos você precisa de verdade
A resposta correta depende da variabilidade das entradas. Para tarefas bem definidas e homogêneas, 50 a 100 exemplos já permitem detectar regressões. Para tarefas com muita variação, como sumarização de documentos de domínios diferentes, você precisa de mais, e de estratificação.
O que não funciona é usar um número arbitrário porque ‘parece suficiente’. Cada categoria de entrada relevante precisa ter representação no conjunto. Se 30% das suas entradas reais são reclamações de cliente e seu eval set não tem nenhuma, você tem um conjunto de avaliação inútil para esse caso específico.
Como rotular sem viés
Rotulação é o ponto mais sensível. Quando quem rotula é o mesmo time que construiu o modelo, o viés de confirmação entra sem que ninguém perceba. Você aprova respostas que ‘parecem boas’ mas que um usuário real rejeitaria.
Algumas práticas que ajudam: rotulação às cegas, sem saber qual modelo gerou a saída. Usar ao menos duas pessoas para os casos ambíguos e registrar os casos de discordância, porque eles revelam onde o critério precisa ser afinado, não onde o julgador errou.
Evals automáticos versus evals com julgamento humano
Os dois têm lugar. A questão é saber quando cada um serve.
Evals automáticos são bons para tarefas onde existe uma resposta objetivamente correta ou onde você pode definir uma métrica confiável, como extração de dados estruturados, classificação com categorias fechadas ou verificação de formato. Eles escalam, são rápidos e permitem rodar avaliações a cada mudança de prompt ou modelo.
Julgamento humano é necessário para tarefas abertas, onde a qualidade depende de contexto, nuance ou preferência do usuário final. Sumarização, resposta a perguntas complexas, geração de texto com voz de marca, tudo isso precisa de olho humano em algum ponto do ciclo, ao menos para calibrar os evals automáticos.
O erro é usar só um dos dois. Evals automáticos sem calibração humana derivam silenciosamente. Julgamento humano sem automação não escala e é inconsistente ao longo do tempo.
O que esperar de um bom conjunto de avaliação
- Você consegue detectar regressões antes de ir para produção, não depois.
- Quando troca de modelo, você tem um número para comparar, não só uma impressão.
- Casos que já quebraram em produção estão representados, então você sabe se a correção funcionou.
- O critério de julgamento é explícito o suficiente para que alguém que entrou no time recentemente consiga rotular sem muita dúvida.
- Os exemplos cobrem a distribuição real das entradas, não só os casos fáceis.
O impacto de ir para produção sem evals definidos
Sem um conjunto de avaliação, você não tem baseline. Qualquer mudança de modelo, prompt ou pipeline vira um experimento sem controle. Você não sabe se melhorou, piorou ou ficou igual. Só descobre quando um usuário reclama.
O custo aparece de formas diferentes. Regressões que passam despercebidas por semanas. Decisões de trocar de modelo baseadas em feeling, não em dados. Times que gastam horas debugando problema que um eval set de 80 exemplos teria detectado em minutos.
E tem o custo menos visível: a perda de confiança interna. Quando o time não consegue responder ‘como a gente sabe que melhorou?’, a pressão vai toda para demos e julgamentos subjetivos. Isso cansa e gera decisões piores ao longo do tempo.
Dúvidas comuns sobre evals para IA
Preciso de evals mesmo para um projeto pequeno?
Se for algo que vai para usuário real, sim. O tamanho do projeto não muda o fato de que você precisa saber se está funcionando. Para projetos pequenos, um eval set menor resolve, mas ele precisa existir.
LLM-as-judge substitui julgamento humano?
Parcialmente. Usar um modelo para julgar as saídas de outro modelo funciona bem como proxy para alguns tipos de tarefa, especialmente quando calibrado contra julgamento humano real. O risco é adotar LLM-as-judge sem validar que ele concorda com humanos nos casos que importam. Sempre que você introduzir julgamento automatizado, valide a concordância antes de confiar no número.
Com que frequência atualizar o conjunto de avaliação?
Sempre que o produto mudar de forma que afete o tipo de entrada ou o critério de sucesso. E sempre que um bug de produção revelar uma categoria de caso que não estava representada. O eval set é um artefato vivo, não um documento que você faz uma vez e esquece.
E se os exemplos do eval set vazarem para o treino do modelo?
Esse é um risco real em fine-tuning. O conjunto de avaliação precisa ser mantido separado dos dados de treino desde o começo. Contaminação entre treino e eval invalida os números e você não tem como saber o quanto o modelo memorizou em vez de generalizar.
Conclusão e próximo passo
Evals para IA não são etapa opcional de times maduros. São o mínimo necessário para operar qualquer sistema de IA com algum controle sobre o que ele faz.
O ponto de partida é simples: antes da próxima feature com modelo de linguagem, escreva o critério de sucesso em linguagem que duas pessoas diferentes interpretariam igual. Depois colete 50 exemplos reais, incluindo os que você sabe que são difíceis. Esse conjunto vai te dar uma baseline que você não tem hoje.
Se quiser aprofundar o lado do monitoramento contínuo, o próximo passo natural é explorar como avaliar respostas de LLM em produção sem depender de achismo. E se o problema está antes disso, na qualidade dos dados que alimentam o modelo, data contracts na prática é onde vale olhar.
