Se você não consegue colocar um número em se uma mudança tornou seu agente melhor ou pior, você não está fazendo engenharia, está chutando com passos extras. A razão mais comum para projetos de agentes travarem não é um modelo fraco, é a ausência de um harness de eval. Sem um, toda mudança de prompt, mudança de ferramenta e troca de modelo é avaliada por alguém olhando um punhado de saídas e declarando que "parece melhor", que é como você lança uma regressão e descobre por um usuário. O placar precisa existir antes do agente, porque você não consegue melhorar o que não consegue pontuar.

O reenquadramento: um conjunto de eval é sua suíte de testes para código probabilístico. Você não refatoraria um serviço sem testes e lançaria com base na sensação de que parece bom. Um agente é mais difícil de raciocinar do que esse serviço, não mais fácil, então ele precisa do placar mais, não menos.

Construa o harness antes do agente

Um harness de eval é pouco glamoroso e pequeno no início: um conjunto de entradas representativas, uma definição de uma boa saída para cada uma, e uma forma de rodar o sistema atual contra todas elas e obter uma pontuação. Vinte a cinquenta exemplos reais, tirados de tráfego real ou esperado, vencem mil exemplos sintéticos. O ponto é ter uma régua fixa, para que "melhoramos o agente" vire uma afirmação que você pode verificar em vez de uma sensação.

Uma vez que ele existe, o fluxo de trabalho se inverte. Toda mudança, novo prompt, nova ferramenta, novo modelo, roda contra o harness primeiro. Uma mudança que eleva a pontuação vai para produção; uma mudança que a reduz não vai, não importa quão esperta parecesse. No Bedrock, o Model Evaluation te dá um caminho gerenciado para isso, com métricas automáticas e revisão humana, e ficou disponível de forma geral bem antes de você precisar dele aqui. A ferramenta importa menos que a disciplina: pontue, depois decida.

LLM-as-a-judge, e onde ele mente para você

Pontuar saídas abertas na mão não escala, então o movimento padrão é usar um modelo como juiz: dar a um modelo forte a entrada, a saída do agente, e uma rubrica, e pedir que ele avalie. O Bedrock Model Evaluation suporta exatamente isso. É genuinamente útil e também é um componente que pode errar, o que os times esquecem no momento em que ele começa a emitir números arrumadinhos.

O juiz tem modos de falha previsíveis, e você precisa projetar em torno deles:

  • Viés de posição e verbosidade. Juízes tendem a preferir a primeira opção mostrada e a resposta mais longa e de tom mais confiante, independentemente de correção. Randomize a ordem e controle o comprimento.
  • Auto-preferência. Um juiz da mesma família de modelo pode avaliar saídas de sua própria família com nota mais alta. Onde isso importa, use um juiz de uma família diferente da do modelo sendo testado.
  • Deriva de rubrica. Uma rubrica vaga ("essa resposta é boa") produz pontuações vagas e instáveis. Uma rubrica específica ("a resposta cita a seção da política, e a seção citada está correta") produz pontuações sobre as quais você pode agir.
  • Concordância confiante com uma resposta errada. Se a entrada contém uma premissa falsa, o juiz pode recompensar uma saída que embarca nela. Inclua casos adversariais em que o comportamento correto é recusar ou corrigir.

O juiz não é verdade absoluta. É uma aproximação rápida e barata da verdade que você calibra contra um pequeno conjunto rotulado por humanos. Se o juiz e seus humanos discordam nesse conjunto, conserte a rubrica antes de confiar no juiz para o resto.

Pontue a trajetória, não só a resposta

Para agentes especificamente, a resposta final é só metade do que importa. Um agente pode produzir uma resposta certa por um caminho errado: chamando uma ferramenta que não deveria, gastando dez passos numa tarefa de dois passos, ou vazando dados para um log ao longo do caminho. Avalie a trajetória tanto quanto a saída. Ele usou as ferramentas esperadas? Ficou dentro das ações permitidas? Terminou em um número sensato de passos? Um agente que chega na resposta certa enquanto chama uma API de delete que nunca deveria tocar falhou no eval, seja qual for o texto final.

A conclusão

A ordem não é negociável: harness de eval primeiro, agente depois. O harness é um conjunto pequeno e fixo de entradas reais com boas saídas definidas e uma pontuação repetível, e ele transforma toda mudança de um vibe check em uma decisão medida. Use um LLM-as-a-judge para escalar a pontuação, mas trate-o como um componente falível: controle seus vieses, dê a ele uma rubrica específica, e calibre-o contra rótulos humanos. Pontue o caminho, não só o resultado. Você não pode lançar o que não consegue pontuar, e os times que lançam agentes confiáveis são os que construíram o placar antes de construir o jogador.

Leia isso a seguir

Para o lado de plataforma de conectar evals a um pipeline de entrega, as notas de campo de cloud estão em ercan.cloud, e o hub fica em ercanermis.com.