Notas sobre Evals

O que são Evals

Da mesma forma que precisamos de testes para garantir a qualidade de software determinístico, as evaluations (ou só evals) vêm suprir essa necessidade para sistemas agênticos: checar se as respostas de LLMs cumprem determinados critérios de qualidade.

Ao tentar evoluir um agente de IA focando somente em alterar o comportamento do sistema via prompt engineering, fine-tuning ou qualquer outro tipo de técnica sem uma boa suíte de evals e debugging, o seu sistema se torna limitado e ineficiente. Como disse Hamel Husain, ao fazer isso você “impede a evolução dos produtos de LLM para além de uma demo”. Hamel Husain Your AI Product Needs Evals hamel.dev ↗

Entretanto, construir uma suíte de evaluations para agentes pode não ser tão simples quanto aparenta, tendo em vista a natureza adaptativa deles ao ambiente (diferentemente de uma chamada de LLM de turno único, por exemplo). Para resolver isso, diversas técnicas foram desenvolvidas nos últimos anos com diferentes propósitos, e é o que vamos explorar agora neste texto.

Tipos de Evals

De forma geral, podemos dividir as evals em três grandes famílias. As determinísticas verificam propriedades objetivas da resposta, como formato, presença de um campo ou validade de um JSON, e funcionam como testes de unidade tradicionais. As baseadas em modelo usam uma LLM para julgar critérios mais subjetivos, como tom, completude ou fidelidade ao contexto. E as humanas, em que uma pessoa lê a saída (ou o trace inteiro) e dá o veredito.

O senso comum trata a avaliação humana como o tipo mais caro e lento, algo a automatizar o quanto antes. Ela custa caro mesmo, mas a conclusão me parece apressada. Olhar os próprios dados costuma ser o passo de maior alavancagem: examinar traces, fazer análise de erro e transformar falhas recorrentes em evals.

Tenho uma hipótese que vai um pouco na contramão. Especialmente quando você está evoluindo o harness de um agente de código, costuma render mais usar avaliação humana para corrigir prompts de forma pontual do que investir cedo demais em um sistema que tenta automatizar todo o julgamento. O “avaliador perfeito” quase sempre sai mais caro e menos eficiente do que uma pessoa lendo alguns traces (ou qualquer outro método que pode ser usado para consulta) e ajustando uma instrução.

Automação continua valendo, desde que venha na ordem certa. A avaliação funciona melhor como um processo: definir critérios, rotular exemplos à mão e só então alinhar um juiz-LLM contra esses rótulos humanos. O julgamento humano vira a fonte de verdade, o ponto de referência que torna confiável tudo o que vem depois.

Como as métricas nascem do uso real

Bora pegar um exemplo: um agente de suporte que pode abrir reembolsos. O usuário avisa no começo da conversa que quer o reembolso no cartão, a conversa cresce até essa mensagem sair da janela de contexto, e o agente processa o reembolso na carteira, que é o padrão do sistema. A resposta final parece que foi o fluxo foi bem-sucedido, mas o trace mostra que o contexto se perdeu e o agente assumiu o default.

Nestes tipos de caso, a ideia seria anotar onde o agente falhou, agrupar as falhas em uma taxonomia e transformar as categorias recorrentes em testes; esses casos formam o dataset da suíte, com casos sintéticos preenchendo os buracos que a produção ainda não cobriu. A recomendação que eu mais vejo é justamente essa: gastar a maior parte do tempo em análise de erro, não escrevendo asserts.

Quando algum critério é promovido a juiz-LLM, ele pode funcionar bem: em benchmarks como o MT-Bench, juízes fortes chegaram a mais de 80% de concordância com humanos. Antes de confiar no juiz, porém, vale rotular um lote à mão e ajustar a rubrica até que as notas dele batam com as suas.

Atualização (julho de 2026): uma pesquisa recente da Anthropic sobre o global workspace de LLMs mostrou que parte do raciocínio do modelo acontece internamente, sem aparecer no texto que ele gera. A explicação que o modelo dá sobre o que fez não é um registro fiel do que aconteceu, o que reforça a importância de avaliar o comportamento observado no trace, e não a narração.