Evals: O Novo Teste Unitário Para Agentes de IA

Você trocou uma linha do prompt do agente de suporte. Testou na mão com três perguntas que sempre usa, todas passaram, fez merge. Duas semanas depois, o CS reporta que o agente começou a inventar prazo de reembolso que não existe em nenhuma política. Ninguém mudou a política, ninguém trocou o modelo. Só aquela linha, que parecia inofensiva, mudou o comportamento num canto do espaço de casos que você nunca testou.

Isso não é falta de atenção, é a consequência natural de tratar agente como função determinística, validável com dois ou três exemplos que "parecem cobrir o caso". Agente de IA tem superfície de comportamento gigantesca, sensível a detalhes de prompt, contexto e modelo, que nenhum humano explora sistematicamente na mão. Teste manual prova que o agente funciona nos casos que você pensou em testar. Não prova nada sobre os milhares que você não pensou.

No post de ontem sobre observabilidade e tracing, o tema foi enxergar o que o agente fez de fato em produção: qual ferramenta chamou, com que argumento, em que ordem. Isso resolve metade do problema — sem observabilidade, você está cego. Mas ver o que o agente fez não diz se estava certo. Essa é a segunda metade, e é dela que este post trata: como avaliar sistematicamente a qualidade do comportamento do agente, antes de ir para produção e continuamente depois.

---

O Problema Do "Parece Funcionar Nos Meus Testes"

Todo tech lead já viveu essa cena: alguém abre uma sessão de chat, faz cinco perguntas, gosta das respostas e declara o agente pronto. O problema não é o instinto, é razoável querer ver o agente funcionando antes de confiar nele. O problema é achar que essa amostra representa a distribuição real de entradas em produção.

Um agente de atendimento recebe milhares de variações da mesma intenção: usuário educado, grosseiro, que digita errado, que muda de assunto no meio, que tenta manipular o agente para ignorar instruções, que faz duas perguntas na mesma mensagem. Cada variação é um ponto diferente no espaço de entrada, e o comportamento do modelo não é garantidamente estável entre eles. Um prompt que funciona bem com frase educada pode falhar silenciosamente com frase ambígua. Cinco casos felizes não capturam nada disso.

Há ainda um problema mais sutil: teste manual não é reproduzível nem comparável. Se você testa hoje, muda o prompt amanhã e testa de novo "na mão", está comparando impressões subjetivas em momentos diferentes, sem registro do que foi testado antes. Não existe baseline, não existe diff. Você não consegue responder com dados a pergunta mais básica: essa mudança tornou o agente melhor ou pior, considerando tudo que ele precisa fazer bem?

É esse vácuo que os evals preenchem. Eval é para agente o que teste automatizado é para código: transformar "acho que funciona" em "meço que funciona, nestes N casos, com este critério, e sei exatamente quando parou de funcionar".

---

O Que É Um Eval, De Fato

Um eval tem três peças, e todas precisam existir para ele ser útil. A primeira é um dataset de casos: entradas representativas do que o agente vai encontrar de verdade, não hipóteses do time. A segunda é um critério de sucesso: forma objetiva ou semi-objetiva de dizer se a saída está certa. A terceira é execução automatizada: rodar o dataset inteiro contra o critério sem intervenção manual, de forma que qualquer pessoa dispare o eval e receba um resultado.

Sem dataset representativo, o eval mede o vazio. Sem critério de sucesso, vira um log bonito que alguém ainda precisa ler um por um — o mesmo trabalho manual que você queria eliminar. Sem automação, não escala e não entra em CI, e será esquecido depois da segunda ou terceira mudança de prompt.

Um eval bem montado responde, em minutos e sem reler transcript manualmente, à pergunta: "se eu mudar X, quantos dos 40 casos que o agente acertava antes ele continua acertando, e quais passou a errar?". Uma vez montados dataset e critério, o custo de rodar de novo é quase zero, e o custo de não rodar é uma regressão silenciosa em produção. Vale reforçar: eval não é testar se o modelo responde bem uma pergunta genérica. É sempre no contexto do seu agente, com suas ferramentas, prompt e dados — um artefato de engenharia do produto, não um benchmark de LLM.

---

Os Três Tipos De Eval Que Você Vai Precisar

Nem todo caso de uso tem resposta certa única, por isso existem abordagens diferentes, cada uma cobrindo um tipo de output.

O primeiro é o golden dataset com resposta esperada. Funciona quando a saída é estruturada: classificar um ticket, extrair um valor de documento, decidir entre chamar a ferramenta A ou B. Você compara a saída contra um valor esperado, com igualdade exata ou métrica de similaridade, e o resultado é binário. É o tipo mais barato de montar, mas cobre só uma fração dos casos reais, já que a maioria dos agentes produz texto livre.

O segundo é LLM-as-judge, que existe porque a maior parte do output de um agente moderno não tem resposta única — resumo, resposta de suporte, explicação técnica, todos têm várias formas corretas. Aqui um segundo modelo avalia com um rubric explícito ("a resposta contradiz a política? é educada? responde à pergunta?") e retorna um veredito estruturado por critério. É poderoso porque escala para outputs abertos, mas vem com armadilhas sérias, tratadas adiante.

O terceiro, e o mais negligenciado, é a avaliação de trajetória ou tool-calling. Para agente que usa ferramentas, o resultado final pode estar certo por acaso mesmo com caminho errado. Um agente que deveria consultar o estoque antes de confirmar uma venda, mas "adivinhou" que tinha e acertou por sorte, passa no teste de resultado e falha no que importa: seguiu o processo certo? A avaliação de trajetória verifica sequência de chamadas, argumentos, ordem, e se passos obrigatórios não foram pulados. Ela se conecta direto com o tracing: os traces de produção viram matéria-prima para saber se a trajetória observada foi a correta.

Times maduros combinam os três no mesmo eval suite, porque cada um captura uma falha que os outros deixam passar.

---

Montando Um Golden Dataset Mínimo Viável

A pergunta que mais trava times é "de onde tiro os casos?". A resposta é: da produção, não da imaginação. Um dataset inventado em reunião cobre só os casos óbvios. O valor real está nos casos estranhos que só aparecem com usuário de verdade.

Um ponto de partida realista é entre 20 e 50 casos — suficiente para pegar regressão sem exigir meses de projeto antes de ter qualquer proteção. Metade deveria vir de conversas reais capturadas via tracing: interações que geraram reclamação, feedback negativo, ou correção manual, onde o agente já provou que pode falhar. A outra metade deveria cobrir edge cases conhecidos: entrada ambígua, tentativa de prompt injection, pergunta fora do escopo, múltiplas intenções na mesma mensagem, informação faltando que o agente deveria pedir em vez de assumir.

Um erro comum é montar um dataset só com casos fáceis, que vêm à cabeça primeiro. Isso produz um eval que sempre passa e não discrimina entre versão boa e ruim do agente. O critério de bom caso não é "o agente consegue fazer isso", é "esse caso já quebrou, ou é plausível que quebre". Cada caso é uma aposta sobre onde a próxima regressão vai aparecer — e anotar por que está ali vira documentação viva dos riscos já mapeados.

---

As Armadilhas Do LLM-as-Judge

Usar um modelo para avaliar outro parece elegante, mas carrega vieses conhecidos que, ignorados, produzem uma falsa sensação de segurança — o pior resultado possível, já que o eval existe para substituir sensação por medição.

O primeiro é o viés de posição: ao comparar duas respostas lado a lado, o juiz tende a favorecer a que aparece primeiro (ou, em alguns modelos, a segunda), independente do conteúdo. A mitigação é rodar a comparação nas duas ordens; se o veredito mudar, o critério não é confiável para aquele caso.

O segundo é o viés de verbosidade: juízes baseados em LLM tendem a associar resposta mais longa com mais completa e correta, mesmo quando o texto extra é enchimento. Isso é perigoso para agentes de suporte, onde resposta curta e direta costuma ser a melhor prática, mas pode ser penalizada pelo juiz. Rubrics que proíbem julgar por tamanho ajudam a neutralizar o efeito.

O terceiro problema é estrutural: o juiz precisa ser calibrado contra avaliação humana antes de ser confiável sozinho. Pegue uma amostra do dataset, tenha um humano avaliando cada caso de forma independente, e compare com o veredito do juiz. Concordância baixa significa que o rubric precisa de ajuste — e a calibração deve se repetir sempre que o rubric mudar ou o modelo-juiz for trocado. Pedir justificativa estruturada por critério ("violou a política? sim/não, com trecho citado") em vez de nota solta de 1 a 10 reduz ruído e inconsistência entre execuções.

---

Regressão Silenciosa E O Papel Do Eval No CI

O cenário mais caro em produção de agente não é o bug óbvio que todo mundo percebe no mesmo dia. É a regressão silenciosa: uma mudança de prompt, modelo, ou até de versão de dependência, que faz o agente parar de acertar um subconjunto de casos que acertava antes, sem que ninguém perceba porque só se testaram os casos felizes de sempre.

Isso acontece com mais frequência do que a maioria imagina. Trocar de modelo, de um fornecedor para outro ou entre versões do mesmo, muda comportamento em detalhes finos: como interpreta instrução ambígua, quando decide chamar uma ferramenta versus responder direto, como lida com contexto longo. Um prompt afinado para o comportamento de um modelo pode se tornar sutilmente pior em outro, mesmo que o novo seja superior em benchmarks gerais. Sem eval suite, a degradação só aparece quando um usuário reclama, dias depois, quando já é tarde para reverter com confiança sobre a causa real.

É aqui que eval em CI vira defesa estrutural, análoga ao teste automatizado para código. A prática recomendada é rodar o eval suite completo em todo pull request que toque prompt, configuração de ferramenta ou versão de modelo, e bloquear o merge se a taxa de sucesso cair abaixo de um limiar, ou se um caso crítico regredir. Isso transforma "alguém vai perceber que isso quebrou?" em "o pipeline não deixa entrar sem mostrar o diff de quais casos pioraram".

O ganho de compor isso com observabilidade é direto: os casos mais valiosos do golden dataset nascem dos incidentes reais capturados via tracing, e o eval suite garante que, corrigido um incidente, ele nunca mais volta a passar despercebido. Observar o que o agente fez, avaliar se estava certo, e transformar todo erro em caso de regressão permanente: esse ciclo separa um time que trata IA como experimento de um time que a trata como sistema em produção de verdade — a mesma disciplina discutida ao falar de DORA metrics e retrabalho gerado por IA: métrica sem processo que a alimenta é decoração.

---

Ferramentas Do Mercado

Você não precisa construir tudo do zero. Para a maioria dos times, faz sentido começar com uma ferramenta existente.

Braintrust se posiciona como plataforma de avaliação e observabilidade integrada, com loop contínuo entre trace de produção e eval, LLM-as-judge nativo e comparação de experimentos lado a lado. Promptfoo é mais leve e orientado a linha de comando, popular por rodar bem em CI sem infraestrutura pesada: casos de teste em YAML, comparação de prompts e modelos no mesmo dataset. LangSmith, da LangChain, integra bem com quem já constrói o agente em LangChain ou LangGraph, com datasets versionados e rastreamento no mesmo painel do trace de execução.

Para RAG, Ragas virou referência por oferecer métricas para os modos de falha típicos de recuperação aumentada: fidelidade ao contexto recuperado, relevância do contexto e completude da resposta. Isso complementa o que já foi discutido sobre RAG avançado no blog: de nada adianta melhorar reranking e hybrid search sem eval específico para saber se a recuperação melhor virou resposta melhor. E, assim como ao tratar de métricas além do DORA, ferramenta nenhuma substitui a disciplina de escolher o que medir e por quê.

---

Conclusão

Agente de IA não é função pura, e por isso não pode ser validado com a displicência de "rodei aqui e funcionou". A superfície de comportamento é grande e sensível demais a detalhe de prompt e modelo para que teste manual dê garantia real. Eval é o mecanismo que fecha essa lacuna: dataset representativo, critério de sucesso explícito, execução automatizada, rodando toda vez que algo no agente muda.

O caminho prático não exige perfeição desde o primeiro dia. Comece com um golden dataset pequeno, de 20 a 50 casos reais tirados de produção, priorizando edge cases que já causaram dor. Adicione LLM-as-judge para outputs abertos, mas calibre o juiz contra avaliação humana antes de confiar nele, e desconfie de vieses de posição e verbosidade. Cubra trajetória de tool-calling, porque resultado certo por caminho errado é uma falha que só esse tipo de eval enxerga. E coloque tudo em CI, para que regressão de prompt ou modelo vire um diff visível antes do merge, não uma reclamação de cliente semanas depois.

O time que investe nisso cedo ganha uma vantagem difícil de replicar: mudar o agente com confiança, sabendo exatamente o que quebrou e o que continuou funcionando. Sem isso, toda mudança é um salto de fé. Com isso, é engenharia.

---

Fontes:

• Braintrust — Evaluating AI applications: a practical guide
• promptfoo — LLM evaluation and red teaming for AI apps
• LangChain — LangSmith Evaluation concepts
• Ragas — Metrics for evaluating RAG and agentic systems