Evals: como testar saída de LLM sem ser subjetivo

O problema

Quando o time começa a mexer com LLM, aparece rápido uma cena conhecida:

• alguém mostra três respostas
• outra pessoa diz que a segunda “soa melhor”
• uma terceira fala que a primeira estava “mais natural”
• no fim, a decisão vira gosto pessoal com roupa de critério técnico

Isso quebra rápido quando você precisa:

• trocar prompt
• trocar modelo
• trocar contexto
• comparar versão antiga com nova
• saber se uma mudança melhorou ou piorou

Sem eval, muita decisão vira:

• impressão
• memória seletiva
• preferência de estilo
• confiança excessiva em demo

E aí o time acha que está iterando em qualidade, quando na prática está só girando o volante.

Modelo mental

Pense assim:

eval é uma régua explícita para comparar comportamento, não uma máquina de descobrir verdade absoluta.

Essa frase importa porque coloca a expectativa no lugar certo.

Eval não responde:

• “esse sistema é perfeito?”

Eval ajuda a responder:

• “a versão B ficou melhor ou pior que a A para os casos que importam?”
• “quais tipos de erro continuam acontecendo?”
• “essa mudança melhorou uma coisa e estragou outra?”

Ou seja:

eval boa não elimina toda subjetividade.

Ela reduz a subjetividade o bastante para que a decisão deixe de ser puro palpite.

Quebrando o problema

Primeiro defina o que é uma saída boa para essa tarefa

Esse é o ponto que mais falta.

Muita equipe quer avaliar resposta de LLM sem antes definir o que ela espera da tarefa.

Exemplos diferentes pedem critérios diferentes:

• resumo precisa preservar fatos importantes
• classificação precisa bater na classe certa
• resposta para cliente precisa ser correta, segura e útil
• geração de código precisa funcionar, respeitar contexto e não inventar API

Se você não define isso, a discussão vira:

• “gostei mais dessa”
• “essa parece mais inteligente”

Isso não é avaliação. É opinião.

Casos de teste precisam representar o trabalho real

Outro erro comum é montar eval com exemplos bonitos demais.

A equipe pega:

• caso simples
• input limpo
• prompt ideal
• contexto completo

E depois conclui que o sistema está ótimo.

Só que produção não chega arrumada.

Conjunto de casos bom costuma misturar:

• casos fáceis
• casos medianos
• casos ambíguos
• casos problemáticos
• casos que já quebraram antes

Se a eval não inclui os cenários que doem no mundo real, ela vira encenação de qualidade.

Rubrica é o que transforma gosto em comparação

Rubrica é só um jeito explícito de dizer:

• o que vamos observar
• o que conta como acerto
• o que conta como erro

Ela não precisa ser complicada.

Às vezes uma boa rubrica já resolve muito:

1. a resposta entendeu a intenção?
2. trouxe informação correta?
3. deixou algo crítico de fora?
4. inventou coisa?
5. tomou o formato esperado?

Cada item pode virar:

• passa ou falha
• nota de 1 a 5
• peso maior para erro crítico

O ganho aqui não é fingir precisão científica.

É fazer duas pessoas avaliarem quase pelo mesmo padrão.

Nem toda eval precisa ser igual

Tem pelo menos três famílias úteis de avaliação.

Checks determinísticos

Servem para coisas objetivas como:

• JSON válido
• presença de campos obrigatórios
• ausência de palavra proibida
• referência a fonte obrigatória

Rubrica humana

Serve para coisas em que julgamento ainda importa:

• clareza
• utilidade
• aderência ao pedido
• alucinação perceptível

Judge automatizado com outro modelo

Pode ajudar a escalar comparação e triagem, mas não deve virar autoridade cega.

Modelo julgando modelo é útil para reduzir trabalho manual.

Não é desculpa para parar de inspecionar erro de perto.

Compare versões, não só respostas isoladas

Esse é um ajuste de mentalidade importante.

Pergunta fraca:

• “essa resposta está boa?”

Pergunta melhor:

• “essa nova versão está melhor que a anterior nos casos que importam?”

Porque em produto real você quase sempre está decidindo entre opções:

• prompt antigo vs prompt novo
• modelo A vs modelo B
• chunking antigo vs chunking novo
• contexto curto vs contexto longo

Eval forte ajuda a responder regressão e ganho relativo.

Ela não precisa provar perfeição.

Precisa ajudar a escolher melhor.

Failure modes importam mais do que uma média bonita

Média geral pode esconder problema sério.

Exemplo:

• 80% dos casos melhoraram um pouco
• 20% começaram a inventar informação crítica

Se esse 20% bate em fluxo sensível, a média não salva a decisão.

Por isso vale separar failure modes como:

• inventar dado
• ignorar restrição
• responder fora do formato
• omitir passo importante
• errar exatamente nos casos difíceis

Time maduro não olha só score final.

Olha onde o sistema falha e se esse tipo de falha é aceitável ou não.

Exemplo simples

Imagine uma feature que gera primeira resposta para tickets de suporte.

O time quer comparar duas versões de prompt.

Jeito ruim de avaliar:

• pega 5 tickets
• lê as respostas
• decide pela que “pareceu melhor”

Jeito melhor:

1. separar 40 tickets reais já anonimizado
2. misturar cobrança, bug, dúvida simples e caso ambíguo
3. definir rubrica

Rubrica possível:

• entendeu o problema do usuário?
• não inventou política da empresa?
• pediu informação extra só quando necessário?
• sugeriu próximo passo útil?
• manteve o tom esperado?

Depois:

1. rodar prompt A nos 40 casos
2. rodar prompt B nos mesmos 40 casos
3. medir checks automáticos de formato e política
4. revisar manualmente amostra dos casos mais sensíveis
5. comparar onde B melhorou e onde piorou

Talvez o resultado seja:

• prompt B parece mais natural
• mas inventa política de reembolso em 6 casos

Nesse cenário, “soa melhor” é irrelevante.

O erro crítico matou a escolha.

É isso que uma eval boa revela.

Erros comuns

Avaliar só com casos bonitos

Se você testa apenas o caminho limpo, a eval vira vitrine.

Misturar tudo na mesma mudança

Trocar prompt, modelo, retrieval e pós-processamento ao mesmo tempo dificulta saber o que causou melhora ou regressão.

Tratar score único como verdade final

Número agregado ajuda, mas não substitui leitura de erros importantes.

Confiar cegamente em model-as-judge

Juiz automatizado acelera.

Mas ele também carrega viés, inconsistência e pontos cegos.

Não versionar o conjunto de casos

Sem conjunto relativamente estável, você não sabe se a comparação ficou justa entre hoje e amanhã.

Esquecer avaliação online

Eval offline ajuda muito.

Mas depois que a feature vai para produção, ainda importa observar:

• aceitação
• retrabalho
• fallback
• tempo de conclusão
• custo

Porque qualidade de saída e impacto no produto não são a mesma coisa.

Como um senior pensa

Um senior tende a pensar assim:

• “o que exatamente estamos tentando melhorar?”
• “quais erros são aceitáveis e quais matam a feature?”
• “nosso conjunto de casos representa produção ou só nosso melhor cenário?”
• “essa avaliação ajuda a decidir ou só parece sofisticada?”

Também costuma ter menos ilusão sobre score.

Ele sabe que:

• eval é aproximação
• qualidade depende de contexto
• sistema probabilístico pede comparação disciplinada, não certeza absoluta

Então a postura madura não é:

• “agora temos o número verdadeiro da qualidade”

É:

• “agora temos uma régua melhor para iterar sem nos enganar tanto”

Esse ponto parece pequeno, mas muda muito a qualidade das decisões.

O que o entrevistador quer ver

Quando o tema aparece em entrevista, o avaliador geralmente não quer ouvir buzzword.

Ele quer ver se você sabe transformar algo nebuloso em processo de engenharia.

Uma resposta forte costuma ter esta linha:

1. definir a tarefa e o que conta como sucesso
2. listar failure modes importantes
3. montar conjunto de casos representativo
4. combinar checks objetivos com rubrica de qualidade
5. comparar baseline com versão nova
6. revisar regressões críticas manualmente
7. acompanhar sinal online depois do deploy

Se você disser algo assim, passa uma imagem muito melhor do que falar:

• “eu usaria evals para medir acurácia do prompt”

Isso soa raso.

O entrevistador quer ver critério, não vocabulário.

Eval boa não tira toda a subjetividade da mesa, mas tira o suficiente para a decisão parar de depender de opinião solta.

Em IA aplicada, maturidade não é prometer certeza. É saber comparar versões sem se enganar com demo bonita.