O que são evals de LLM?

A resposta curta

Eval é um teste para software que não produz a mesma saída duas vezes. Em vez de afirmar que uma função retorna 4, você verifica se uma resposta atende a um padrão: está ancorada na fonte, segue o formato, recusa quando deveria recusar.

É essa a ideia inteira. A dificuldade não é conceitual, é que você precisa escrever o que significa "bom" antes de conseguir medir, e a maioria dos times nunca faz isso.

Por que "ficou bom" não é teste

Todo time começa igual. Alguém testa quinze prompts na mão, as respostas impressionam, e a feature vai pro ar. Funciona até parar de funcionar, porque conferência manual tem três propriedades que a inutilizam como rede de segurança.

Não é repetível, então você não sabe se hoje está melhor ou pior que terça passada. É enviesada para os casos que você pensou, que nunca são os casos que quebram. E não escala, então na hora que você muda um prompt, ou reconfere tudo na mão ou não confere nada.

O resultado é um sistema que degrada em silêncio. Ninguém mexeu, e mesmo assim as respostas pioraram, e o primeiro sinal é reclamação de cliente.

Os três tipos que importam

Evals de conjunto de referência. Uma coleção fixa de entradas reais com saídas boas conhecidas. Você roda a cada mudança, como suíte de teste. É a espinha dorsal e é justamente a que os times pulam.

Evals por rubrica. Para saída aberta, onde não existe uma resposta única certa, você pontua contra critérios: está ancorada, está completa, o tom está certo, ficou dentro do escopo. Um modelo pode aplicar a rubrica, mas um humano precisa escrevê-la.

Evals em produção. Amostrar tráfego real depois do fato e pontuar. É o único que pega as entradas que você nunca imaginou, que na prática são a maioria.

Montando seu primeiro conjunto de referência

Cinquenta a duzentos casos reais já bastam para começar, e começar vale mais que acertar de primeira. Tire de uso real em vez de inventar, porque caso inventado carrega a sua suposição sobre o que o usuário faz, e é exatamente essa suposição que está errada.

Puxe para os casos que doem. Inclua os ambíguos, aqueles em que a resposta correta é recusar, aqueles em que falta dado, e o punhado que já causou incidente. Um conjunto só de casos fáceis passa para sempre e não te diz nada.

Escreva a saída esperada de cada um. Isso é lento e é o trabalho de verdade. Se ninguém no time consegue dizer qual é a resposta certa, isso não é problema de eval, é problema de definição de produto disfarçado.

Quem escreve a rubrica

Não é o engenheiro, e essa é a parte que se pula. A rubrica codifica o que significa uma boa resposta no seu negócio, então ela pertence a quem é dono do resultado: o analista de crédito, o líder de atendimento, a pessoa que faria isso na mão.

Engenharia é dona de rodar os evals. O especialista do domínio é dono do que significa passar. Quando os dois viram a mesma pessoa, a rubrica deriva para o que é fácil medir em vez do que importa, e você acaba otimizando um número que deixou de representar alguma coisa.

Rode em CI, não em planilha

Eval que você roda manualmente é eval que você roda duas vezes e abandona. O conjunto precisa executar a cada mudança de prompt, a cada versão de modelo, a cada ajuste de recuperação, e precisa falhar alto.

Na prática: um comando no seu pipeline que roda o conjunto, reporta taxa de acerto por categoria e trava o merge quando a taxa cai abaixo da linha. Na hora que o fornecedor do modelo publica uma atualização, você quer que a falha chegue como build vermelho, não como ticket de suporte três semanas depois.

É a mesma disciplina de qualquer outro sistema em produção. Por isso tratamos eval como parte de entregar, não como atividade de pesquisa, em todo trabalho em que construímos IA em produção, ponta a ponta.

Eval em produção é monitoramento, não teste

Passar no seu conjunto de referência significa que o sistema lida com os casos que você conhecia. Não diz nada sobre os que estão chegando agora. Entrada real deriva: seu produto muda, seus clientes perguntam coisas novas, um concorrente lança e as perguntas mudam.

Então você amostra tráfego real, pontua contra a mesma rubrica e acompanha a tendência. Não toda requisição, uma porcentagem. O que você procura não é uma resposta ruim isolada, é a inclinação: a queda silenciosa que significa que a recuperação está degradando ou que uma mudança de prompt teve consequência que ninguém previu.

O que é um número bom

Não existe número universal, e quem cita um está vendendo alguma coisa. O alvo certo vem do custo de errar. Um sistema que sugere artigos relacionados vive bem com oitenta por cento. Um sistema que participa de decisão de crédito não vive.

O que importa mais que o valor absoluto é ter uma linha de base e uma direção. Saber o número de hoje, saber qual era mês passado, e saber qual categoria está puxando para baixo. Um time que consegue dizer "ancoragem está em 94 e caiu dois pontos depois da mudança de recuperação" está no controle. Um time que cita uma acurácia geral única normalmente não está.

Acompanhe recusa e escalonamento em separado. Um sistema que responde tudo com confiança não é melhor que um que passa para o humano na hora certa, é só menos honesto sobre os próprios limites.

Onde os times erram

Três falhas, em ordem de frequência. Montar o conjunto de eval depois do lançamento, quando o incentivo é fazer passar em vez de achar problema. Medir o modelo em vez do sistema, então qualidade de recuperação e estrutura de prompt se escondem atrás de uma nota de modelo. E deixar o eval envelhecer, então o conjunto descreve um produto que não existe mais.

A quarta, menos comum e mais cara: avaliar um problema de geração quando a falha real é de recuperação. Se o trecho certo nunca chega ao modelo, nenhum ajuste de prompt resolve. Cobrimos essa divisão em o que é RAG, e é o erro de diagnóstico mais comum nesse trabalho.

Se você está antes disso e ainda dimensionando, quanto custa um agente de IA mostra onde avaliação entra num orçamento real.