O problema
Um time trocou o prompt do agente de triagem de tickets pra reduzir custo — trocou um bloco de instruções longo por um mais enxuto. Em produção, ninguém percebeu nada errado por três semanas. Aí um cliente importante recebeu uma resposta que ignorava uma política de reembolso que existia havia dois anos. Ninguém tinha como saber que aquilo ia quebrar, porque ninguém tinha um jeito de medir "esse agente ainda faz a coisa certa" antes de publicar a mudança.
Isso não é um problema de prompt. É um problema de evidência. Sem um eval, cada mudança em um agente é uma aposta silenciosa: pode ter melhorado, pode ter piorado, e a única forma de descobrir é esperar alguém reclamar.
O conceito central
Um eval é um conjunto de casos representativos — com entrada e critério de sucesso conhecidos — que você roda contra o agente antes de qualquer mudança ir pra produção. Não é a mesma coisa que um teste de unidade determinístico, porque a saída de um modelo não é sempre idêntica byte a byte. E não é a mesma coisa que "pedir pro Claude ler a resposta e dizer se ficou boa" sem nenhuma estrutura, porque isso não produz um número que você possa comparar entre versões.
Um eval mínimo mas útil tem três peças:
- Um conjunto de casos fixo, com pelo menos alguns exemplos que representam os failure modes que você já viu acontecer — não só os casos fáceis.
- Um critério de sucesso verificável — pode ser uma checagem programática (a resposta contém o campo certo, respeita a política X) ou um julgamento por outro modelo com rubrica explícita, nunca "parece bom".
- Um número que você acompanha ao longo do tempo — taxa de acerto no conjunto, não uma impressão pontual de "testei um exemplo e funcionou".
O erro mais comum é confundir avaliação com depuração. Rodar o agente uma vez, ler a saída, achar que está bom, e seguir em frente é depuração pontual — útil pra entender um caso específico, inútil pra garantir que a próxima mudança não quebra os outros 40 casos que já funcionavam.
A segunda peça importante é separar quem gera da resposta de quem revisa. Se o mesmo agente que produziu a resposta também julga se ela está certa, o viés de confirmação entra de graça: um modelo tende a defender a própria saída. Um passe de revisão independente — outro prompt, focado só em verificar critérios objetivos contra a resposta já pronta, sem ver o raciocínio que a gerou — pega erros que a geração original nunca ia admitir sozinha.
Isso também define o que vira gate de release: não é "o time achou que ficou bom", é "a taxa de acerto no eval não caiu abaixo do limiar acordado, e nenhum caso do conjunto de regressão (os failure modes já conhecidos) voltou a falhar". Um agente pode ficar 95% bom no eval geral e ainda assim regredir exatamente no caso que já causou um incidente antes — por isso o conjunto de regressão precisa crescer toda vez que um bug real aparece em produção.
Coloque em prática
No laboratório desta lição você vai construir um eval mínimo em Python: um conjunto de casos fixos, um verificador programático de critério de sucesso, e um segundo passe de revisão independente que confirma (ou rejeita) o resultado do primeiro — exatamente a separação entre gerar e revisar que evita o viés de autoavaliação.