Avaliação de Agentes como Disciplina de Engenharia
Durante anos, a avaliação de sistemas de IA em produção foi tratada como um problema de ciência de dados, um notebook Jupyter rodado antes do deploy, métricas de acurácia calculadas offline, e a esperança de que o comportamento em produção refletisse o que foi medido no laboratório. Agentes de IA quebraram esse contrato de vez. Um agente que orquestra chamadas a ferramentas, mantém estado entre turnos e toma decisões ramificadas não pode ser avaliado com um único score de F1. O lançamento do Bedrock AgentCore, e especificamente sua capacidade de construir suites de testes que evoluem junto com o agente, é o sinal mais claro até agora de que a indústria está reconhecendo avaliação de agentes como uma disciplina de engenharia de primeira classe, não um pós-pensamento de MLOps.
Por que o momento é agora
O Sinal: Do Vibe-Testing à Engenharia de Avaliação
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.
Por que Agentes São Fundamentalmente Diferentes de Modelos
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.
Pipeline de Avaliação de Agentes com Bedrock AgentCore
Fluxo completo desde a mudança de código do agente até o quality gate de CI/CD, passando por execução de avaliadores compostos e rastreabilidade de regressão
- Agent Code · PR / commit
- CodePipeline · / GitHub Actions
- AgentCore · Eval Orchestrator
- Dataset Store · versioned + lineage
- Agent Under Test · Bedrock Runtime
- LLM-as-Judge · Claude 3.5 Sonnet
- Deterministic · Heuristic Evals
- Trace Fidelity · Evaluator (OTel)
- CloudWatch · Eval Metrics + Alarms
- S3 · Eval Results + Audit Log
- Quality Gate · threshold check
O que muda para arquitetos com este sinal
Posicionamento para Sistemas Financeiros: O Contrato Mínimo
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.
Modos de Falha Reais e Como Instrumentá-los
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.
O Paradoxo do Juiz LLM em Produção Financeira
LLM-as-judge é poderoso para avaliar qualidade semântica, coerência, relevância, tom, mas introduz não-determinismo no próprio processo de avaliação. Em sistemas financeiros onde a auditabilidade é mandatória, você precisa de um log imutável de cada julgamento, incluindo o prompt exato enviado ao juiz, a versão do modelo juiz, e a resposta raw. Armazene isso no S3 com Object Lock (WORM) e configure um hash SHA-256 de cada julgamento no DynamoDB para verificação de integridade. Sem isso, você tem um sistema de avaliação que você mesmo não consegue auditar.
Anti-Padrões que Vejo Repetidamente
- Dataset estático como único conjunto de avaliação: usar o mesmo conjunto de 50 casos de teste por 6 meses enquanto o agente evolui, o dataset precisa crescer junto com o agente, especialmente incorporando casos de falha de produção como novos testes de regressão.
- Avaliação apenas no resultado final: ignorar o traço de execução e avaliar apenas a resposta final, em agentes financeiros, o caminho importa tanto quanto o destino.
- Quality gate com threshold único para todas as categorias: um threshold de 95% de acurácia que se aplica igualmente a casos nominais e adversariais é uma falsa segurança, categorias de risco alto precisam de thresholds mais rígidos.
- Modelo juiz não fixado em versão: usar
claude-3-5-sonnet-latestcomo juiz significa que uma atualização do modelo pode mudar os scores de avaliação sem nenhuma mudança no agente, sempre pinar o modelo juiz a uma versão específica (ex.:claude-3-5-sonnet-20241022). - Avaliação desacoplada do pipeline de deploy: rodar avaliações manualmente ou em um pipeline separado sem integração com o gate de promoção de versão, avaliação precisa ser um bloqueador de deploy, não uma métrica informativa.
Lentes Well-Architected para Avaliação de Agentes
Segurança
Isole quotas de inferência entre agente de produção e agente sob teste via perfis de inferência separados. Use KMS CMKs distintas para dataset store e resultados de avaliação. Armazene julgamentos LLM com S3 Object Lock para auditabilidade regulatória. Aplique IAM conditions bedrock:InferenceProfileIdentifier para prevenir cross-contamination de contexto.
Confiabilidade
Configure retry com backoff exponencial e jitter no evaluator runtime para lidar com throttling do Bedrock Runtime. Implemente circuit breaker no quality gate, se o evaluator runtime falhar, o gate deve falhar fechado (bloquear deploy), não aberto. Mantenha pelo menos dois evaluadores independentes por categoria de risco para redundância de julgamento.
Eficiência de performance
Use avaliadores determinísticos como filtro primário para reduzir o volume de chamadas LLM-as-judge em 60–80%. Paralelize execução de casos de teste com Step Functions Map state (concorrência máxima configurável). Considere batch inference do Bedrock para suites grandes, pode reduzir custo em até 50% versus invocação síncrona.
Otimização de custos
Dimensione suites de avaliação com consciência de custo: avaliadores determinísticos primeiro, LLM-as-judge apenas para casos ambíguos. Use S3 Intelligent-Tiering para datasets históricos de avaliação. Configure CloudWatch Budget Alerts para custo de inferência de avaliação separado do custo de produção.
O que eu faria concretamente: começaria com um dataset mínimo de 30 casos: 10 nominais, 10 edge cases de domínio financeiro, 10 adversariais, e um quality gate com thresholds diferenciados por categoria antes de qualquer deploy em produção. A lição que aprendi da forma mais difícil é que suites de avaliação que não crescem com o agente criam uma falsa sensação de segurança que é pior do que não ter avaliação nenhuma, porque você para de questionar o sistema. O segundo ponto crítico: fixe o modelo juiz em uma versão específica desde o dia um e documente isso como um ADR, a deriva silenciosa de scores por atualização de modelo é um dos problemas mais difíceis de diagnosticar em retrospecto. E por fim: avaliação de agente não é responsabilidade exclusiva da equipe de ML, em sistemas financeiros, a equipe de domínio precisa ser co-autora dos datasets de edge cases.
Veredicto: Adote Agora, com Governança
O Bedrock AgentCore representa uma inflexão real na maturidade de plataformas de agentes de IA, não por ser a única solução possível, mas por ser o sinal mais claro de que a indústria está convergindo em avaliação de agentes como disciplina de engenharia com infraestrutura dedicada. Para equipes em sistemas financeiros, a recomendação é clara: adote o padrão agora, mas faça-o com governança explícita. Isso significa: datasets de avaliação como artefatos versionados com donos de produto, quality gates que bloqueiam deploy com thresholds diferenciados por categoria de risco, rastreabilidade de traço completa via OpenTelemetry, modelo juiz fixado em versão com julgamentos armazenados imutavelmente para auditoria, e um processo formal de incorporação de falhas de produção como novos casos de teste. Equipes que construírem essa disciplina agora terão uma vantagem operacional significativa à medida que os agentes assumem responsabilidades de maior consequência. Equipes que não o fizerem descobrirão o custo dessa omissão em um momento inoportuno.
Referências
Continue lendo
Deep dives de arquitetura, AWS, IA e mercado: direto no seu email. Grátis.
Sem spam · cancele quando quiser
Pergunte ao Fernando sobre isto
Uma resposta focada sobre este artigo, do meu assistente de IA, baseada no meu trabalho.
Participe da conversa
Entre para comentar
Confirme seu e-mail para participar, você também recebe a newsletter. Sem senha.