Evals antes do release: como transformar expectativa em critério executável

“O agente ficou melhor” é uma sensação. “O agente resolveu 18 de 20 casos críticos, preservou os cinco negativos e não criou efeitos proibidos” é uma afirmação que pode orientar um release.

Evals transformam expectativas de produto em tarefas, graders, trials e resultados observáveis. Elas não eliminam incerteza, mas impedem que cada mudança dependa apenas de memória, demo ou confiança no modelo mais novo.

Resumo executivo

Comece evals antes de automatizar o fluxo inteiro.

Um score não é qualidade total. É evidência sobre propriedades definidas.

Comece pelo produto, não pela métrica

Antes de escolher framework, escreva:

• quem usa o agente;
• que resultado espera;
• que falha é inaceitável;
• que comportamento é subjetivo;
• qual estado do ambiente prova conclusão;
• qual variação é tolerável;
• qual decisão o eval libera.

Se duas pessoas de domínio discordam sobre o que deveria passar, o problema ainda está na especificação.

Task success não é uma variável única

Um agente pode produzir a resposta correta e violar policy. Pode seguir policy e não concluir a ação. Pode concluir e criar retrabalho depois.

Separe dimensões:

O gate pode exigir todas as dimensões críticas, não uma média que compensa falha de segurança com boa redação.

Escolha o grader pela propriedade

Código

Use teste, schema, query, lint ou inspeção de estado quando a propriedade é objetiva.

Modelo

Use rubrica para aspectos sem verificador determinístico, com exemplos e calibração humana. Um judge não deve receber autoridade maior do que a evidência que produz.

Pessoa

Use especialista quando contexto, impacto ou subjetividade exigem julgamento. Revisão humana também calibra graders automáticos.

Combinar camadas é mais robusto do que esperar um verificador universal.

Dataset nasce do trabalho real

Uma primeira suíte pode vir de:

• tarefas manuais frequentes;
• incidentes e bugs;
• tickets de suporte;
• casos que o time sempre demonstra;
• inputs adversariais;
• decisões em que o agente deveria escalar;
• casos em que ele não deveria usar uma ferramenta.

Não use apenas exemplos felizes. Uma suíte unilateral ensina o sistema a fazer sempre aquilo que só deveria fazer às vezes.

Capability e regressão medem coisas diferentes

• capability eval: o que ainda não conseguimos fazer de forma suficiente?
• regression eval: o que já funcionava e não pode piorar?

Quando uma capability amadurece, seus casos estáveis podem migrar para regressão. O release precisa proteger as duas direções: melhorar a fronteira sem perder o chão.

Não esconda não determinismo

Uma tentativa bem-sucedida não prova consistência. Rode trials proporcionais ao risco e diferencie:

• chance de obter ao menos um sucesso em várias tentativas;
• chance de repetir sucesso em todas as tentativas;
• variância de custo, passos e resultado.

Uma ferramenta de exploração pode aceitar várias tentativas. Um agente que executa efeito financeiro pode precisar de consistência e gate muito mais fortes.

Fontes elegíveis de eval e tracing sustentam que baseline, resultado e observabilidade precisam ser calibrados por caso de uso; elas não definem thresholds universais da FORGE. [R3-C1]

O eval também pode estar errado

Leia traces e procure:

• tarefa ambígua;
• referência impossível;
• grader que penaliza solução válida;
• vazamento da resposta no contexto;
• dataset contaminado;
• distribuição diferente da produção;
• score saturado;
• incentivo a explorar loophole;
• melhoria de score com piora do outcome.

Um eval é software e hipótese de produto. Precisa de owner, versionamento e manutenção.

Um gate de release simples

1. regressões críticas = 0
2. casos de segurança negativos = 100% bloqueados
3. capability alvo melhora sobre baseline
4. custo e latência dentro do budget
5. traces amostrados sem falha material nova
6. reviewer aceita os limites

Os números acima são estrutura, não thresholds universais. Cada produto define risco e tolerância.

Evals não substituem produção

Pré-release testa cenários conhecidos. Produção revela distribuição real, mudança de comportamento, integrações e efeitos que o dataset não antecipou.

Combine:

• evals offline;
• monitoramento e traces;
• feedback de usuário;
• testes controlados quando houver tráfego e base;
• revisão periódica de casos;
• incidentes convertidos em regressão.

Se um incidente não muda a suíte ou o controle, o sistema pode repetir a falha com outra aparência.

Evals aceleram troca de modelo

Sem suíte, um modelo novo reinicia a discussão por demos. Com suíte, a equipe compara no próprio contexto:

• sucesso por classe de tarefa;
• consistência;
• custo total;
• latência;
• falhas novas;
• comportamento de segurança;
• necessidade de scaffolding.

O leaderboard informa possibilidade. A suíte interna informa adequação.

O que este artigo prova — e o que não prova

Fontes oficiais e práticas públicas sustentam tarefas, trials, graders, traces e combinação de sinais. Elas não provam que eval automatizado representa todo valor de produto, nem que LLM-as-judge é independente por definição.

Este artigo oferece um desenho mínimo. Validade depende do dataset, do ambiente, dos reviewers e da decisão ligada ao score.

Conclusão

Evals tornam expectativas discutíveis antes do release. Elas transformam “parece melhor” em casos, propriedades, resultados e limites que a equipe pode revisar.

O objetivo não é produzir um número bonito. É saber o que mudou, o que permaneceu protegido e qual risco ainda não foi medido.

Leitura anterior: O agente não pode ser seu próprio auditor. Próxima leitura sugerida: Design Partner não é mercado.