Avaliação de Agentes como Disciplina de Engenharia

O padrão dominante até recentemente era o que eu chamo de vibe-testing: um engenheiro roda o agente manualmente contra um punhado de prompts representativos, observa se a saída "parece certa", e aprova o deploy. Isso funciona exatamente até o momento em que não funciona — e em sistemas financeiros, esse momento costuma ser caro.

O Bedrock AgentCore muda o frame ao introduzir infraestrutura gerenciada para três problemas que até então eram resolvidos com cola e fita adesiva: (1) gerenciamento de datasets de avaliação com versionamento e linhagem, (2) execução de avaliadores que podem ser LLM-as-judge, heurísticos determinísticos ou uma composição dos dois, e (3) integração com pipelines de CI/CD via quality gates que bloqueiam promoção de versão quando scores caem abaixo de thresholds configuráveis.

A arquitetura subjacente é reveladora: ao separar o dataset store do evaluator runtime e do agent under test, o AgentCore permite que equipes evoluam cada componente independentemente — um princípio que qualquer arquiteto de dados reconhecerá do Data Mesh. Datasets de avaliação tornam-se produtos de dados com donos, SLOs e contratos de schema. Isso não é acidental; é o sinal de maturidade que separa plataformas de experimentação de plataformas de produção.

Quando avaliamos um modelo de classificação, o espaço de saída é discreto e a função de perda é bem definida. Quando avaliamos um agente, estamos avaliando um processo — uma sequência de decisões, chamadas de ferramenta, atualizações de estado e respostas intermediárias que culminam em um resultado final. A falha pode ocorrer em qualquer ponto dessa cadeia, e o resultado final pode parecer correto mesmo quando o caminho foi completamente errado.

Considere um agente de reconciliação financeira que usa ferramentas para consultar saldos, validar transações e gerar relatórios. Um teste que verifica apenas o relatório final perde falhas críticas: o agente pode ter chamado a ferramenta errada, usado parâmetros incorretos, ou tomado um atalho que funciona para o caso de teste mas falha em edge cases de produção. Isso é o que eu chamo de fidelidade de traço — a capacidade de verificar não apenas o resultado, mas o caminho.

O AgentCore endereça isso ao instrumentar o ciclo de vida completo da execução do agente com spans OpenTelemetry, tornando cada chamada de ferramenta, cada decisão de roteamento e cada atualização de memória observável e avaliável. Para sistemas financeiros sujeitos a auditoria, isso não é opcional — é a diferença entre um sistema que você pode defender perante um regulador e um que você torce para não ser questionado.

Em sistemas financeiros, a tolerância a falhas silenciosas é próxima de zero. Um agente que erra em 2% dos casos em um produto de consumo pode ser aceitável; o mesmo agente processando reconciliações de câmbio ou gerenciando limites de crédito não pode. Isso significa que o contrato mínimo para avaliação de agentes em contextos financeiros é significativamente mais exigente do que o padrão da indústria.

O que eu defendo como contrato mínimo para produção financeira: primeiro, datasets de avaliação devem cobrir pelo menos três categorias — casos nominais (happy path), edge cases de domínio (ex.: transações com múltiplas moedas, falhas de idempotência, timeouts de ferramenta) e casos adversariais (prompt injection, tentativas de exfiltração de dados via ferramenta). Segundo, cada caso de teste deve ter um avaliador determinístico para o resultado final E um avaliador de traço para verificar que o caminho de execução foi correto. Terceiro, o quality gate deve ser configurado com thresholds diferenciados por categoria — um agente pode ter 98% de acurácia em casos nominais mas ainda falhar no gate se tiver menos de 100% em casos adversariais.

No nível de configuração AWS: use IAM conditions com bedrock:InferenceProfileIdentifier para garantir que o agente sob teste e o agente juiz usem perfis de inferência separados com quotas isoladas — você não quer que um pico de avaliação throttle seu agente de produção. Configure KMS CMKs distintas para o dataset store (S3 com SSE-KMS) e os resultados de avaliação, com políticas de acesso separadas para a equipe de ML e para auditores.

Ao longo de engajamentos com equipes construindo agentes em produção, três modos de falha aparecem repetidamente e são sistematicamente sub-cobertos por suites de avaliação imaturos.

Falha de idempotência de ferramenta: um agente que retenta uma chamada de ferramenta após timeout pode executar a mesma operação duas vezes se a ferramenta não for idempotente. Em contextos financeiros, isso pode significar débitos duplicados. O avaliador de traço deve verificar que o agente não emitiu chamadas de ferramenta duplicadas para operações não-idempotentes, usando o span de trace para contar invocações por tool_name e correlation_id. Configure um alarme CloudWatch em EvalMetric/DuplicateToolCall com threshold zero.

Deriva de memória entre turnos: em agentes multi-turn, o estado acumulado pode introduzir viés em decisões posteriores — o agente "lembra" de uma transação anterior e aplica lógica incorreta a uma nova. Datasets de avaliação para este modo de falha precisam de conversas multi-turn com estado deliberadamente contrastante entre turnos. O avaliador LLM-as-judge deve ser instruído explicitamente a verificar se a resposta do turno N é independente de contexto irrelevante do turno N-2.

Escalada de privilégio via ferramenta: um agente com acesso a múltiplas ferramentas pode ser induzido a combinar chamadas de forma que resulte em acesso a dados além do seu escopo intencional. Isso é particularmente crítico quando as ferramentas têm acesso a APIs internas com autenticação delegada. O avaliador adversarial deve incluir casos que tentem induzir o agente a usar ferramentas fora do fluxo intencional, e o quality gate deve bloquear qualquer versão que falhe nesses casos — sem exceções.