Evals para agentes: como testar o que não tem resposta certa

Numa pesquisa com 1.340 respostas, 89% das organizações implementaram alguma forma de observabilidade para os agentes. Metade avalia o que eles produzem.

E 29,5% não avaliam de forma alguma. Entre quem já tem agente em produção, 22,8%.

Quase todo mundo quis saber o que aconteceu. Bem menos gente quis saber se prestou.

A fila anda menos aqui por um motivo específico. Teste comum compara a saída com a resposta certa, e em boa parte do que um agente produz não existe uma.

Um teste comum afirma igualdade. Você espera 42 e recebe 42. A premissa é que existe uma saída correta e só uma.

Peça a um agente para resumir um relatório e não existe o resumo certo. Existem dezenas de resumos aceitáveis e centenas de ruins, e nenhuma comparação de string separa os dois grupos.

Isso não significa que nada é testável. Significa que a pergunta muda. Em vez de "a saída é igual à esperada?", você passa a perguntar três coisas: a saída respeita o contrato, ela contém ou evita o que deveria, e os indicadores calculáveis ficaram dentro da faixa.

Vale separar de uma camada vizinha. O loop de verificação responde se o trabalho rodou: compilou, passou nos testes, não quebrou o que funcionava. Eval responde se o trabalho prestou. São perguntas diferentes, e a segunda é a que quase ninguém automatiza.

Existem três coisas chamadas de "eval" e elas medem objetos diferentes.

A confusão custa caro numa situação específica. Um modelo novo sai, sobe três pontos no MMLU, e o time troca. Duas semanas depois, a qualidade percebida caiu.

Benchmark de capacidade mede uma habilidade geral em tarefas padronizadas. Ele não sabe nada sobre o seu prompt, as suas ferramentas, o seu domínio. Um modelo pode melhorar em média e piorar no seu caso. A única coisa que responde isso é um conjunto de teste seu, o que é a camada do meio.

Quatro tipos de verificação, do mais barato ao mais caro. A ordem importa: comece por cima e desça só quando precisar.

Contrato. A saída tem o formato combinado? Campo obrigatório presente, tipo correto, valor dentro da faixa, referência apontando para algo que existe. É determinístico, roda em milissegundos e pega a maior parte das falhas grosseiras.

Assertiva. A saída contém ou evita algo específico? Menciona a fonte exigida, não inventa nome de campo, não devolve texto vazio, respeita o limite de tamanho. Também determinístico, e é onde a maior parte das regras de negócio cabe.

Proxy. Uma métrica calculável que correlaciona com qualidade sem ser qualidade. Legibilidade, tamanho médio de frase, densidade de repetição, número de passos. Não diz se está bom, e diz quando algo mudou.

Juiz. Um modelo avaliando com rubrica explícita. É o mais caro e o mais frágil, e mesmo assim é usado por 53,3% de quem avalia. Quando confiar na nota dele é o assunto do post de amanhã, e por isso fica aqui em um parágrafo só. A saída de um juiz também é texto gerado, com as fragilidades descritas em prompt injection quando o conteúdo avaliado vem de fora.

Um dado que contraria a expectativa de automação total: entre quem avalia, o método mais usado continua sendo revisão humana, com 59,8% (LangChain, pesquisa com 1.340 respostas coletadas entre 18 de novembro e 2 de dezembro de 2025, publicada em 12 de junho de 2026; acesso em 28/08/2026). Eval maduro não elimina a pessoa. Ele decide o que a pessoa não precisa mais olhar.

Um caso de teste, inteiro

Fica mais claro com um exemplo. Um agente que recebe uma issue e devolve um diff.

caso: corrige-import-quebrado
entrada: "Issue #482: build falha com 'Cannot find module lib/covers'"

contrato:
  - saida_e_diff_valido: true
  - arquivos_tocados_max: 3

assertiva:
  - contem_arquivo: "lib/covers.ts"
  - nao_contem: "node_modules"
  - nao_altera: "package.json"

trajetoria:
  - chamou_ferramenta: ["buscar_arquivo", "editar", "rodar_teste"]
  - passos_max: 8
  - rodou_teste_antes_de_concluir: true

proxy:
  - linhas_alteradas: [1, 40]

Nenhuma dessas verificações precisa de modelo para rodar. Todas são código comum lendo a saída e o trace.

Repare no bloco de trajetória. Ele é o que separa "o diff está certo" de "o agente chegou lá do jeito certo". Um agente que devolveu o diff correto sem rodar o teste passa nas três primeiras seções e falha nesta — e é bom que falhe, porque da próxima vez ele erra.

E repare no que não está ali: nenhuma verificação sobre o diff estar elegante, idiomático ou bem escrito. Isso é julgamento, e julgamento não entra em portão automático sem alguém pagar o preço de um juiz.

Um agente pode chegar ao resultado certo pelo caminho errado. Se você só olha a saída, ele passa.

O problema é que o caminho errado não se repete. Ele acertou porque a ordem das ferramentas calhou de funcionar naquele caso. Na variação seguinte, falha — e o seu conjunto de teste dizia que estava tudo bem.

O que dá para avaliar na trajetória:

• A ferramenta correta foi chamada, e não uma que devolveu a resposta por acaso.
• A ordem das chamadas bate com a esperada, quando a ordem importa.
• O número de passos ficou dentro da faixa.
• Nenhuma ferramenta foi chamada em laço.

A boa notícia é que esse dado já existe se você seguiu a camada anterior. A árvore de spans, com invoke_agent no topo e execute_tool para cada ferramenta, é o registro da trajetória. Avaliar caminho vira ler o que o trace já guardou.

Comece pelos casos que já falharam.

É o conselho mais barato deste post e o mais ignorado. Todo bug que chegou a produção é um caso de teste pronto, com entrada real e resultado conhecido. Um conjunto montado assim reflete o seu risco de verdade, e não uma ideia do que talvez dê errado.

Três regras que valem mais que o tamanho:

Pequeno e estável ganha de grande e mutável. Trinta casos que não mudam permitem comparar rodadas. Trezentos casos que mudam a cada semana não permitem comparar nada, porque a nota subiu ou desceu sem que ninguém saiba se foi o sistema ou o conjunto.

Caso novo entra quando bug novo aparece. É a mesma disciplina do pilar deste cluster: o erro que escapou vira mudança permanente no ambiente. Aqui a mudança é uma linha no conjunto.

Guarde um conjunto que você não usa para ajustar. Se você otimiza contra o mesmo conjunto que mede, o número sobe sem o sistema melhorar. Separe uma parte e só olhe nela de vez em quando.

Eval no CI morre de uma causa: reprova quando não devia, o time desativa, e ninguém liga de volta.

Três técnicas evitam isso. Elas vêm de prática corrente relatada por quem opera esses portões, e não de estudo controlado.

Falta decidir o que acontece quando reprova, e a resposta não é sempre "bloqueia".

Verificação de contrato e assertiva merece bloqueio: são determinísticas e falha ali é falha de verdade. Proxy merece aviso: ele indica mudança, e mudança pode ter explicação. Nota de juiz merece registro e revisão humana antes de virar regra.

Isso conversa com as quatro métricas da camada de guardrails: nem tudo que se mede precisa travar alguma coisa. Métrica que bloqueia sem necessidade tem o mesmo destino de guardrail que barra tráfego legítimo.

Você não precisa de framework para o primeiro eval. Precisa de três arquivos.

Um arquivo com os casos. Comece com cinco, tirados de coisas que já deram errado. Cada caso tem entrada e as verificações que ele deve passar.

Um script que roda. Ele executa o agente em cada caso, coleta a saída e o trace, e aplica as verificações. Imprime uma linha por caso.

Uma linha no CI. O script roda no pull request. Falha de contrato quebra o build. Proxy fora da faixa imprime aviso.

Feito isso, três coisas passam a existir. Você sabe se a mudança de prompt piorou alguma coisa. Sabe qual caso quebrou, e não só que algo quebrou. E tem onde acrescentar o próximo bug.

Uma decisão para tomar cedo, porque é cara depois: guarde o resultado de cada rodada, com data e a versão do que foi testado. Sem histórico, você compara com a memória, e a memória sempre acha que estava melhor antes.

Framework entra quando o número de casos passa de algumas dezenas, ou quando você quer comparar provedores em matriz. Antes disso, ele resolve um problema que você ainda não tem — pelo mesmo raciocínio de não conectar ferramenta que não vai usar.

O que segue é o que cada ferramenta documenta e o que se relata do uso. Não testei nenhuma delas, e trato isto como mapa de decisão, não como avaliação própria.

Um fato de mercado que importa para escolha. Em 9 de março de 2026, a OpenAI anunciou a aquisição do Promptfoo, com integração ao OpenAI Frontier, lançado em 5 de fevereiro daquele ano. O Promptfoo foi fundado em 2024 por Ian Webster e Michael D'Angelo, é usado por mais de 25% das empresas da Fortune 500, e a OpenAI declarou que segue desenvolvendo os componentes de código aberto (OpenAI, acesso em 28/08/2026).

O julgamento aqui é morno de propósito: a aquisição não invalida a ferramenta, e o histórico de código aberto continua. É um dado a pesar por quem precisa de neutralidade entre provedores de modelo, e irrelevante para quem já escolheu um.

<!-- [ORIGINAL DATA] -->

Texto é o caso mais difícil de avaliar, porque não existe resposta certa. E mesmo assim esta operação roda um portão automático antes de cada publicação.

O que ele mede:

Os sete posts deste cluster, medidos:

O portão reprovou dois de sete. E os dois casos ensinam mais que os cinco aprovados, porque falharam pelo motivo oposto.

O post de prompt injection ficou em 60,1 com frase média de 18,4 palavras. Frase longa demais. A correção seria escrever mais curto, e eu escolhi não reescrever porque o assunto pedia encadeamento.

O de observabilidade ficou em 61,6 com frase média de 13,4 palavras — a mais curta do cluster. Ali a prosa estava ótima e a métrica caiu do mesmo jeito, porque nomes como gen_ai.usage.cache_read.input_tokens contam como palavras longas. Escrever mais curto não resolveria; só tirar o conteúdo resolveria.

Isso é a faixa de tolerância da seção anterior, encontrada na prática antes de eu ler a recomendação em algum lugar.

Uma nota de rodapé com graça própria. Este post, sobre eval, passou pelo portão antes de sair: Flesch 70, o maior dos oito, frase média de 14,2 palavras, sete travessões, nenhuma frase batida. O número alto tem explicação prosaica e não literária. Aqui quase não há nome técnico com ponto e sublinhado para carregar a conta.

E houve um detalhe que só aparece quando o texto fala de si mesmo. Escrevi o valor exato com uma casa decimal, rodei a medição de novo, e ele tinha mudado — porque a frase que anunciava o número entrou na conta do número. Arredondei para 70 e segui. É a versão em miniatura do problema de medir sistema que reage à medida, e mais uma evidência de que o proxy mede o que mede.

E a confissão que falta: nada disso mede se o post está bom. Mede formato, tique e proxy. Se eu escrever três mil palavras corretas, legíveis e sem nada a dizer, o portão aprova. A avaliação de qualidade continua sendo minha, e o portão existe para me poupar de discutir o que dá para contar.

A camada tem custo, e há casos em que ele não se paga.

Tarefa que roda uma vez. Montar conjunto, script e portão para algo que acontece uma vez é trabalho maior que a tarefa. Olhe o resultado e siga.

Protótipo que ainda muda de formato toda semana. Conjunto de teste pressupõe que a saída tem uma forma estável. Enquanto a forma muda, o conjunto quebra por motivo errado e ensina a ignorar o portão.

Volume baixo com revisor disponível. Se saem cinco itens por semana e alguém olha todos, a revisão humana já é o eval. Automatizar ali troca uma coisa que funciona por uma que precisa de manutenção.

O gatilho para construir é volume ou repetição. Quando você começa a olhar a mesma coisa pela vigésima vez, ou quando o número de saídas passa do que dá para revisar, a conta vira.

E existe um caso em que vale mesmo com volume baixo: quando o erro é caro. Uma saída por semana que pode derrubar produção justifica portão, ainda que a revisão humana desse conta do volume.

Uma última ressalva sobre o que a camada não cobre. Eval mede a saída contra critérios que você escolheu. Se o critério estiver errado, o portão aprova com nota alta a coisa errada, e com consistência. Nenhuma métrica avisa que a pergunta era outra.

O que são evals?

São testes para sistemas cuja saída não é determinística. Em vez de comparar com uma resposta única esperada, avaliam se a saída respeita um contrato, contém ou evita elementos definidos, e mantém indicadores calculáveis dentro de uma faixa. Rodam contra um conjunto de casos estável, geralmente no CI, e servem para detectar regressão quando o prompt, o modelo ou as ferramentas mudam.

Qual a diferença entre eval e benchmark?

Benchmark de capacidade, como MMLU ou HumanEval, mede uma habilidade geral do modelo em tarefas padronizadas. Eval de aplicação mede o seu sistema no seu domínio, com os seus prompts e ferramentas. A distinção é prática: um modelo pode subir num benchmark e piorar no seu caso, então trocar de modelo com base em benchmark, sem conjunto de teste próprio, é decidir no escuro.

Como criar um conjunto de teste para LLM?

Comece pelos casos que já falharam em produção, porque eles têm entrada real e resultado conhecido. Mantenha o conjunto pequeno e estável, para que as notas de rodadas diferentes possam ser comparadas. Acrescente um caso novo sempre que um bug novo aparecer. E separe uma parte do conjunto para não usar em ajustes, de forma a perceber quando o número subiu por causa de sobreajuste.

Eval deve bloquear o deploy?

Depende do tipo. Verificação de contrato e assertiva pode bloquear, porque é determinística e falha ali é falha real. Proxy merece aviso e não bloqueio, já que oscilação normal reprovaria sem motivo. Nota de juiz merece registro e olhar humano. Portão que reprova por ruído acaba desligado, e um portão desligado protege menos que um portão que só avisa.

Como sei se meu conjunto de teste é bom?

Três sinais indicam que ele está funcionando. Ele reprova de vez em quando, porque conjunto que nunca falha não está medindo nada. Quando reprova, você consegue dizer qual caso quebrou e por quê, e não só que o número caiu. E os casos vieram de falhas reais, e não de cenários imaginados na mesa. Um conjunto que só contém o caminho feliz aprova qualquer coisa que não exploda.

Preciso de ferramenta paga para começar?

Não. Um script que roda o conjunto de casos, calcula as verificações e imprime o resultado já entrega quase todo o valor no começo. As três verificações mais baratas — contrato, assertiva e proxy — são código comum, sem modelo envolvido. Plataforma paga resolve agregação, histórico e comparação entre versões, que são problemas de escala.

• 89% instrumentaram, 52,4% avaliam, 29,5% não avaliam nada. Saber o que aconteceu virou padrão; saber se prestou, não.
• Benchmark mede o modelo, framework de métrica mede o seu sistema. Trocar de modelo por benchmark é decidir no escuro.
• Avalie a trajetória. Acertar por acaso com o caminho errado é falha que passa no teste e reaparece na variação seguinte.
• No CI: faixa de tolerância, juiz com versão fixa, conjunto estável. Portão que grita sem motivo é portão que alguém desliga.
• Nem toda métrica merece bloqueio. Contrato bloqueia, proxy avisa, juiz pede revisão.
• Eval mede proxy, não qualidade. O julgamento continua humano.

O post de amanhã trata do tipo de verificação que ficou de fora aqui: usar um modelo como juiz, e quando a nota dele merece confiança. O mapa das cinco camadas segue no pilar sobre harness engineering.