Evals para agentes: além de 'isso funciona?'

A maioria das equipes mede agente com “rodei 10 prompts e parecem ok”. Isso não é eval — é demo testing. Eval verdadeiro é estatístico, repetível, detecta regressão, e custa pouco.

Este post cobre o design de suite de eval que funciona para agentes brasileiros em produção.

Por que “parece ok” falha

Três razões pelas quais demo testing engana:

1. Confirmation bias. Você testa cenários onde acredita que o agente funciona. Edge cases ficam fora.

2. Não captura regressão. Quando você muda o prompt na semana seguinte, não tem como saber se algo que funcionava parou de funcionar.

3. Não permite comparação. “Versão A vs B” exige métrica numérica, não impressão.

Os 4 níveis de eval

Nível 1 · Unit test de prompt

50-200 entradas representativas, com output esperado (ou critério programático). Roda em CI antes de qualquer mudança de prompt ou modelo.

Exemplo de entrada:

- input: "Estou frustrado, isso não funciona"
  expect:
    - sentiment_detected: "negative"
    - escalation_suggested: true
    - tone: "empathic"

Validador pode ser regex, LLM-as-judge, ou métrica determinística.

Nível 2 · Regression suite

Cresce automaticamente do failure corpus. Cada bug em produção vira teste — não pode voltar a falhar.

Schema:

- id: REG-042
  introduced: 2026-04-12
  cause: "Agente sugeriu cancelamento de plano antes de oferecer downgrade"
  input: "Não estou satisfeito com o plano"
  must_not_output: ["cancele", "cancelamento"]
  must_output: ["downgrade", "alternativa"]

Quanto mais o sistema roda, mais a suite cresce. Bom sinal.

Nível 3 · Behavioral eval (LLM-as-judge)

Para qualidades subjetivas (tom, naturalidade, completude), use outro LLM como juiz. Padrão:

[INPUT] [Output do agente]
[JUDGE] Avalie de 1-5 nas dimensões:
  - Tom (formal apropriado?)
  - Completude (resolve o pedido?)
  - Segurança (revelou info sensível?)

Cuidado: LLM-as-judge tem viés (modelos preferem outputs do próprio modelo, ou mais longos). Calibre com sample humano antes de confiar.

Nível 4 · Production canary

Roda em 1-5% do tráfego real, compara saídas com versão anterior. Detecta drift sutil que sintético não pega.

Estrutura típica:

• 95-99% tráfego → versão estável.
• 1-5% → versão candidata.
• Métrica: aceitação humana, retentativas, tempo até resolução.
• Promote ou rollback após volume mínimo (1.000-5.000 turns).

Métricas que importam

Métrica	O que mede	Quando importa
Pass rate	% de testes passados	Mudança de prompt/modelo
Regression count	Quantos regrediram	Antes de deploy
Behavioral score	Qualidade subjetiva	Avaliação periódica
Production acceptance	% aceito pelo usuário	Canary
Cost per task	$ médio por interação	Optimization
Latency p99	Cauda lenta	UX crítico

O insight contra-intuitivo

Pass rate de 100% é suspeito. Significa que sua suite é fácil demais, ou que o modelo decorou os testes (vazamento). Mire 70-90% pass rate em suite bem desenhada — os 10-30% que falham são onde você aprende.

Padrão que funciona

Inspirado em práticas de runtime governance:

1. Semana 1-2: monte unit suite de 50 entradas. Rode em todo deploy.
2. Semana 3-12: alimente regression suite a partir de failures reais.
3. Mês 3+: adicione LLM-as-judge para dimensões subjetivas.
4. Mês 6+: production canary para mudanças não-triviais.

Não pule passos. Production canary sem unit suite vira loteria.

Anti-padrões comuns

1. Eval idêntico ao prompt. Suite que reusa exemplos do system prompt mede memorização, não capacidade. Use entradas inéditas.

2. Métrica única. Pass rate sozinho engana. Combine com cost, latency, behavioral.

3. Eval que só roda em laptop do dev. Tem que rodar em CI, com snapshot dos resultados versionado.

4. Eval que não testa edge case BR. Acento, gíria regional, formato de CPF/CNPJ, datas BR. Modelo global pode falhar nesses sem você notar.

Onde aprofundar

Para o framework de runtime governance que evals validam: Harness Stack.