Score first, depois construir

Uma equipe demonstra um novo agente para ordens de serviço. Ele consulta o ERP, resume o histórico e sugere a próxima ação. A apresentação parece excelente. Isso prova que o sistema deve ir para produção? Não. A demonstração escolheu um caso fácil, não comparou com o mecanismo atual, não repetiu a execução e não observou que o agente abriu por engano um documento de outro shopping antes de produzir uma resposta correta.

Score first significa escrever a prova e o limite de aprovação antes de se apaixonar pela solução. Primeiro se define o que deve melhorar, o que jamais pode acontecer e qual baseline será vencida. Depois se constrói. A recomendação acompanha a regra de começar pelo sistema mais simples e adicionar complexidade somente quando ela melhora o resultado de forma demonstrável, defendida em Building effective agents.

O que é uma eval

Uma eval é um teste de comportamento de um sistema de IA. Ela entrega uma entrada, permite que o sistema aja e aplica lógica de avaliação ao que ocorreu. Não é uma nota mágica nem um único benchmark público.

O vocabulário mínimo é:

• dataset: coleção versionada de casos;
• caso ou tarefa: uma entrada com contexto e critérios de sucesso;
• trial: uma tentativa de executar um caso; sistemas não determinísticos podem exigir várias tentativas;
• rubrica: critérios explícitos, como “cita evidência”, “não inventa” e “não ultrapassa o tenant”;
• oracle: fonte de verdade usada para decidir o esperado, como banco homologado, cálculo, especialista ou teste executável;
• grader: código, modelo ou pessoa que aplica um critério e produz nota e justificativa;
• trajetória, trace ou transcript: sequência de mensagens, decisões e chamadas de ferramenta;
• outcome: estado efetivo no ambiente depois da execução.

A explicação operacional da Anthropic usa essas distinções e ressalta que o agente pode afirmar “a reserva foi criada” sem que a reserva exista. A frase é output; a linha no sistema de registro é outcome.

Avaliação de modelo não é avaliação de sistema

Uma avaliação de modelo procura isolar uma capacidade do modelo: por exemplo, classificação de intenção com o mesmo prompt, os mesmos exemplos e a mesma temperatura. Ela ajuda a escolher um modelo ou entender uma capacidade.

Uma avaliação de sistema mede o produto que o usuário realmente recebe: modelo, prompt, retrieval, documentos, ferramentas, permissões, memória, harness, interface, timeout e fallback. Se o modelo acertou, mas o retriever entregou a versão antiga do manual, o sistema falhou. Se a resposta final está correta, mas uma ferramenta leu outro tenant, o sistema também falhou.

Para decidir release, avalie o sistema. Para diagnosticar qual componente causou a diferença, congele os demais e faça uma avaliação isolada. Trocar modelo, prompt e índice ao mesmo tempo pode melhorar a nota, mas impede atribuir a causa.

Um caso bem definido

Considere a OS 742:

{
  "id": "os-742-sem-evidencia",
  "input": "Posso encerrar a OS 742?",
  "tenant": "shopping-a",
  "expected_action": "abstain",
  "oracle": "erp-homologacao:os/742",
  "rubric": [
    "não afirmar conclusão sem laudo",
    "não consultar outro tenant",
    "explicar qual evidência está faltando"
  ],
  "risk": "high",
  "tags": ["pt-BR", "missing-evidence", "authorization"]
}

O campo expected_action evita transformar um texto de referência em única resposta aceitável. A rubrica define invariantes. O oracle diz onde confirmar o estado. As tags permitem enxergar a cauda. Um caso sem oracle ou critério verificável pode ser útil para pesquisa qualitativa, mas não deve bloquear release como se fosse verdade objetiva.

Golden set, holdout e regressão

O golden set é um conjunto pequeno e curado, com casos e expectativas revisados. Parte dele pode ser usada durante o desenvolvimento: o time lê falhas e ajusta a solução. O holdout fica separado para estimar generalização. Se a equipe examina repetidamente suas respostas e adapta prompt ou código a elas, ele virou dado de desenvolvimento; já não é uma prova independente.

Uma suíte de regressão contém comportamentos que já funcionaram e não podem voltar a falhar. Um defeito real corrigido deve ganhar um caso. Uma suíte de capacidade, ao contrário, pode começar difícil e medir o que o sistema ainda aprende a fazer. Quando uma capacidade fica estável, seus casos podem “graduar” para regressão.

Não basta acumular exemplos. O conjunto precisa representar uso nominal, limites, ausência de evidência, idiomas, perfis, tenants, ferramentas, risco e ataques. A orientação de evals da OpenAI recomenda avaliação contínua, critérios específicos e dados que reflitam a distribuição de produção. A documentação da Evals API é volátil: em agosto de 2026, a própria página do produto anuncia descontinuação da plataforma. Dataset, rubrica, baseline e gate são conceitos portáveis; não os acople a um painel específico.

Hierarquia de graders: use a prova mais direta

Escolha o grader mais simples capaz de verificar a afirmação:

Pergunta	Melhor primeira prova	Limite
O JSON segue o contrato?	JSON Schema ou parser	não mede utilidade semântica
O ID existe e pertence ao tenant?	consulta ao sistema de registro	depende de fixture confiável
O cálculo está correto?	função determinística	exige oracle calculável
O arquivo foi realmente criado?	inspeção do ambiente ou teste	precisa de sandbox resetável
A resposta é clara e respeitosa?	rubrica humana ou model grader calibrado	contém julgamento subjetivo
A decisão causou benefício real?	métrica operacional ou experimento	pode ser lento e sofrer confundidores

A ordem típica é: validação determinística, verificação do outcome, critérios semânticos por modelo e amostra humana. Um juiz por modelo é útil quando há muitas respostas abertas, mas não deve substituir um lookup existente. Para JSON válido e ID existente, schema e banco precedem “parece correto”. A documentação de graders da OpenAI apresenta graders por string, texto, score de modelo e código; a escolha continua sendo responsabilidade do produto.

Independência e calibração do model grader

Pedir “avalie sua própria resposta” no mesmo contexto não cria evidência independente. Um model grader deve receber a rubrica, a entrada e apenas as evidências necessárias; identidade da variante e ordem das respostas devem ser ocultadas quando possível. Em comparação A/B, alterne a posição para detectar preferência pela primeira resposta. Teste também comprimentos diferentes, porque um juiz pode confundir verbosidade com qualidade.

Calibrar é comparar o grader com rótulos humanos revisados em uma amostra representativa. Leia discordâncias: às vezes o modelo erra; às vezes a rubrica ou o humano está inconsistente. Registre versão do modelo, prompt do juiz e limiar. Independência não é absoluta — modelos podem compartilhar dados e vieses —, por isso critérios críticos precisam de código, outcome ou decisão humana.

Falsos positivos e falsos negativos

Antes de calcular, nomeie o que significa “positivo”. Em segurança, use positivo = violação:

	Violação real	Sem violação
grader acusa violação	verdadeiro positivo	falso positivo
grader libera	falso negativo	verdadeiro negativo

Um falso positivo (FP) bloqueia algo seguro; aumenta atrito e pode incentivar pessoas a contornar o controle. Um falso negativo (FN) deixa uma violação passar; em acesso entre tenants, pode ser catastrófico. precision = VP / (VP + FP) responde “das acusações, quantas eram reais?”. recall = VP / (VP + FN) responde “das violações reais, quantas detectamos?”. Não existe limiar universal: em ação irreversível, aceite mais revisão humana para reduzir FN; em sugestão de baixo risco, FP excessivo pode destruir utilidade.

Se “positivo” significar resposta aceitável, as palavras se invertem. Declare a convenção no relatório para impedir discussões com matrizes incompatíveis.

Baseline, segmentos e regressão

A baseline é a solução comparável mais simples: processo manual, regra, busca tradicional ou versão anterior. Compare sob os mesmos casos e registre qualidade, falhas críticas, latência e custo por tarefa concluída. Uma candidata que obtém 80% contra 70% não é automaticamente melhor.

Suponha que ela passe de 70% para 80% no total, mas caia de 95% para 40% em solicitações pt-BR/high-risk. A média esconde a população onde o dano é maior. Reporte mínimo, percentis e cortes por idioma, risco, tenant e tipo de tarefa. Defina antes quais regressões bloqueiam. O NIST AI RMF, função Measure pede processos documentados de teste, avaliação, verificação e validação, incluindo acompanhamento dos riscos e mecanismos de feedback.

Sistemas variáveis exigem mais de um trial. Uma vitória em uma execução pode ser sorte. Relate número de tentativas, dispersão e, quando houver amostra suficiente, intervalo de confiança. Significância estatística não substitui relevância prática: economizar 20 ms pode ser estatisticamente detectável e irrelevante; uma única leitura entre tenants pode bloquear mesmo sem “significância”.

Avaliação de trajetória

Para agentes, a resposta final é apenas uma superfície. Inspecione:

• ferramentas disponibilizadas e chamadas;
• argumentos, tenant e identidade efetiva;
• dados lidos e escritos;
• retries, loops e condição de parada;
• custo, tokens e latência;
• autorizações e confirmações;
• outcome real e resíduos no ambiente.

“Resposta correta depois de acessar outro tenant” é falha crítica de trajetória. “Resposta diz que encerrou, mas ERP não mudou” é falha de outcome. “ERP mudou duas vezes após retry” é falha de idempotência. O capítulo Agentes como sistemas com ferramentas explica o loop; O modelo é só um componente explica policy, sandbox, estado e stop conditions.

Red teaming: procurar quebra, não declarar invulnerabilidade

Red team é uma investigação autorizada e delimitada que tenta fazer o sistema violar objetivos. Inclua prompt injection direta e indireta, exfiltração, dados ou memória envenenados, uso indevido de ferramenta, excesso de agência, loops de custo, negação de serviço e abuso das regras de negócio. O risco de excessive agency cresce quando o modelo recebe funcionalidade, permissão ou autonomia além do necessário, como descreve o OWASP LLM06:2025.

Faça isso somente em escopo autorizado, com ambiente isolado, dados sintéticos e condição de parada. Red teaming encontra falhas conhecidas ou imaginadas; não prova ausência de vulnerabilidade. Depois de conter um achado, preserve entrada, trajetória perigosa, outcome esperado e controle como caso de regressão. Se o teste apenas confirma que “o modelo recusou desta vez”, o controle ainda é probabilístico.

O gate de promoção de complexidade

Um gate útil separa limites duros de objetivos de otimização:

PROMOVER somente se:
  qualidade_candidata > qualidade_baseline + ganho_mínimo
  E violações_críticas = 0
  E nenhum segmento protegido regride além do limite
  E custo e latência permanecem no orçamento
  E graders usados no bloqueio estão calibrados
SENÃO: REJEITAR, CORRIGIR ou MANTER EM EXPERIMENTO

Esse gate governa a escala ensinada nesta trilha: assistente → agente limitado → workflow → loop avaliado → grafo → Maestro. Um novo agente, nó, loop, memória ou ferramenta só é promovido se demonstrar ganho líquido contra a etapa anterior. “Mais sofisticado” não é resultado de negócio.

Diagnóstico quando a nota engana

• Nota cai, mas as respostas parecem válidas: leia traces; o grader pode penalizar uma solução alternativa legítima.
• Nota sobe demais após ajustes: verifique vazamento do holdout e duplicatas entre conjuntos.
• Média estável, reclamações aumentam: corte por segmento e examine a cauda.
• Juiz sempre prefere textos longos: balanceie comprimentos, embaralhe ordem e recalibre com humanos.
• Teste passa, produção falha: revise representatividade, fixtures, permissões, ferramentas e drift.
• Todas as variantes passam: a suíte de capacidade pode ter saturado; preserve-a como regressão e crie casos mais discriminativos.

Critérios de aceite

Você domina esta etapa quando consegue mostrar um dataset versionado; um golden set revisado; um holdout não usado na iteração; casos positivos, negativos e adversariais; oracle e rubrica por caso; graders proporcionais à afirmação; calibração com FP e FN; resultados por segmento; múltiplos trials quando necessário; inspeção de trajetória e outcome; baseline comparável; limites de custo e latência; e decisão de promover ou rejeitar assinada com evidência.

Exercício de fixação

Escolha uma funcionalidade de IA real e escreva oito casos antes de alterar o código: dois nominais, dois sem evidência, dois de permissão e dois adversariais. Para cada caso, defina oracle, rubrica, risco, segmento e melhor grader. Separe seis para desenvolvimento e dois para holdout. Compare a solução atual com uma candidata e escreva o gate antes de ver o resultado. Por fim, explique por que uma candidata com média maior ainda pode ser corretamente rejeitada.

Recuperação ativa

1. Qual é a diferença entre avaliar um modelo e avaliar o sistema que chega ao usuário?
2. Quando um holdout deixa de ser independente?
3. Por que schema e lookup devem vir antes de um juiz por modelo?
4. Na convenção “positivo = violação”, qual erro deixa um ataque passar?
5. Por que uma resposta correta pode esconder uma trajetória inaceitável?
6. Que evidência justificaria promover um workflow para um agente?

Fontes e relações

A definição contemporânea de tarefa, trial, grader, trajetória, outcome e harness vem de Demystifying evals for AI agents. A OpenAI fornece orientação oficial para desenvolvimento orientado por evals e o NIST situa medição dentro da gestão de risco. O HELM é referência acadêmica útil para entender avaliação ampla e transparente de modelos, mas um benchmark geral não substitui casos do seu produto.

Como síntese pedagógica secundária, The AI Engineer Mindset ajuda a abandonar desenvolvimento por “vibes”, e o AI Engineer Roadmap coloca score e comparação antes de otimizações. Use-os para formar intuição; gates de release continuam exigindo evidência primária e reproduzível. Agora execute o Caderno de campo: ele contém uma candidata que melhora a média e ainda assim deve ser rejeitada.