Testar um modelo de IA generativa numa tarefa não é como testar uma função. Não existe um assert resultado == esperado confiável, porque o mesmo modelo pode responder a mesma pergunta de duas formas diferentes — ambas corretas — e porque "correto" muitas vezes é uma questão de grau, não de sim/não. Um eval é a resposta de engenharia pra esse problema: uma bateria fixa de casos, critérios de nota definidos antes de rodar qualquer coisa, e um processo que transforma "acho que o prompt melhorou" em um número que você pode comparar entre versões.
Este artigo descreve como montar um eval do zero, usando como exemplo um caso concreto: um modelo que atende clientes via chat, respondendo com base na política interna de uma empresa. O raciocínio, porém, vale para qualquer tarefa — classificação, extração, geração de código, resumo.
Por que não dá pra confiar só no "parece bom"
Quando você ajusta um system prompt e testa com três perguntas na mão, duas coisas acontecem: você se convence rápido demais de que melhorou (viés de confirmação — você escolheu perguntas que já esperava que funcionassem), e você não sabe se quebrou algo que não testou. Um eval resolve os dois problemas ao fixar o conjunto de perguntas e repetir exatamente o mesmo teste a cada mudança, registrando o resultado de forma que dê pra comparar.
O eval não substitui o julgamento humano — ele estrutura onde e quando esse julgamento entra, e automatiza o que pode ser automatizado em volta dele.
As três fases
Um eval maduro tem um ciclo de vida em três fases: preparar o material de teste, executar o teste e tirar uma nota, e ajustar o que está sendo testado com base no resultado — o que leva de volta à execução. É um loop, não uma linha reta: a fase 3 não é o fim, é a entrada pra um novo ciclo da fase 2.
Fase 1 — Preparação
A preparação acontece uma vez (ou a cada mudança grande de escopo) e define o que "certo" significa antes de qualquer resposta existir. Isso é o que dá honestidade ao eval: se você define o gabarito depois de ver a resposta do modelo, está ajustando a régua pro resultado caber nela.
- Política interna. O documento-fonte que contém as regras que o modelo precisa seguir — no caso do atendimento via chat, prazos, valores, condições, exceções. É o material contra o qual tudo será medido, então vale a pena estruturá-lo em seções numeradas: cada pergunta do eval pode então apontar pra seção específica que a responde, o que ajuda a rastrear lacunas (seções que nenhuma pergunta cobre são um sinal de alerta).
- Bateria de perguntas. O conjunto fixo de casos de teste. Vale pensar em cobertura deliberada, não só juntar perguntas óbvias: categorias diferentes de pedido, níveis de dificuldade (direto no documento, exige combinar duas seções, não tem resposta no documento), e casos de borda — o que o modelo faz quando a informação simplesmente não existe na política? Um bom teste de "não invente" é tão importante quanto um teste de "responda certo".
- Respostas de referência. Para cada pergunta, uma pessoa escreve a resposta correta — não o modelo. Essa é a verdade contra a qual o modelo sob teste será comparado depois. É trabalho manual e não tem atalho: um eval é tão bom quanto o gabarito que ele usa.
- System prompt inicial. A primeira versão das instruções que vão governar o comportamento do modelo. Faz parte do eval porque é exatamente o que vai ser testado, ajustado e testado de novo — por isso vale guardar com número de versão desde o início, nunca sobrescrevendo a anterior. Comparar a v3 com a v1 só é possível se a v1 ainda existir.
- Fatos esperados. Pra cada resposta de referência, uma lista dos trechos que precisam aparecer pra resposta ser considerada correta — um valor, um prazo, uma condição. É o que permite nota automática na fase seguinte, sem depender de outro modelo pra julgar cada caso.
Fase 2 — Execução
Com o material pronto, a execução roda o teste e produz notas. Aqui entram três camadas de avaliação, cada uma com um ponto cego diferente — e é exatamente por isso que as três coexistem.
- Envio ao modelo sob teste. A bateria inteira é enviada de uma vez, com o system prompt da vez e o documento de política como contexto. Vale registrar tokens e latência junto com a resposta — além da qualidade, isso mostra se uma mudança no prompt encareceu ou atrasou o atendimento.
- Nota por fatos. Checagem automática: cada fato esperado apareceu na resposta? É barata, rápida de rodar em qualquer volume e objetiva — não depende de interpretação. O ponto cego dela é óbvio: um texto pode conter todos os fatos certos e ainda assim ser confuso, ou conter os fatos certos por acaso, no meio de uma resposta errada.
- Modelo juiz. Um segundo modelo recebe a pergunta, a resposta de referência, os fatos esperados e a resposta do modelo sob teste, e dá um veredito — por exemplo correta / parcial / incorreta. É mais caro que a nota por fatos, mas pega nuance que uma checagem literal não pega: contradição, informação inventada, resposta tecnicamente certa mas mal formulada. O prompt do juiz importa tanto quanto o prompt sob teste — vale ser explícito sobre o que conta como "essencial" (valores, prazos, condições) e o que não conta (diferença de formatação, redação).
- Nota humana. Uma pessoa revisa e pontua manualmente, pelo menos uma amostra. Essa camada existe pra calibrar as outras duas: se o juiz e a nota por fatos divergem muito do julgamento humano, o problema não é o modelo sob teste — é o critério de avaliação que precisa de ajuste.
- Avaliação dos resultados. As três notas, lado a lado, por execução. Aqui a pergunta deixa de ser "o modelo acertou essa pergunta" e vira "esse system prompt já está bom o suficiente pra produção, ou ainda tem padrão de erro claro". Vale olhar não só a média, mas onde as notas discordam entre si — isso costuma apontar exatamente o tipo de caso que precisa de mais atenção.
Fase 3 — Ajuste e repetição
- Reformulação do system prompt. Com os resultados em mãos, o prompt é ajustado pra corrigir o padrão de erro encontrado — não pra "parecer melhor", mas pra resolver o que os números mostraram. Isso também vira uma nova versão, nunca uma edição da anterior: o histórico de versões é o que permite, mais tarde, explicar por que uma mudança foi feita.
- Repetição da fase 2. O prompt novo volta pro início da execução, roda a mesma bateria, e as mesmas três camadas de nota entram de novo. O ciclo se repete até os resultados pararem de melhorar de forma significativa ou atingirem o padrão que o time definiu como aceitável antes de começar — não um padrão definido na hora, olhando pro resultado.
Armadilhas comuns
Mudar a bateria de perguntas no meio do processo. Se você adiciona ou remove perguntas entre uma execução e outra, as notas deixam de ser comparáveis. Mude a bateria quando quiser expandir cobertura, mas trate isso como início de um novo histórico, não como continuação do antigo.
Deixar o juiz ser o único critério. Um modelo julgando outro modelo tende a herdar os mesmos vieses — inclusive o de achar um texto bem escrito mais convincente que um texto correto. A nota humana, mesmo em amostra pequena, é o que ancora o resto.
Otimizar para a métrica errada. Nota por fatos alta não significa resposta boa — só significa que os trechos certos apareceram em algum lugar do texto. Olhar só um número tende a produzir prompts que "decoram o gabarito" sem necessariamente ficarem mais úteis.
Não versionar nada. Sem guardar cada versão do prompt, do documento e das notas que ela produziu, fica impossível responder "o que mudou entre a v2 e a v3" — e essa é a pergunta mais importante de um ciclo de ajuste.
Fechando
Um eval bem montado não é sobre chegar numa nota perfeita — é sobre ter um processo honesto o suficiente pra saber, a cada mudança, se as coisas melhoraram, pioraram ou só mudaram de lugar. A estrutura em três fases (preparar, executar, ajustar) existe pra manter o gabarito fixo enquanto o que está sendo testado evolui — que é exatamente o contrário do que a maioria faz quando testa um prompt "no olho".