# Avaliação de Agentes como Disciplina de Engenharia A avaliação de agentes de IA deixou de ser um exercício ad hoc de prompt engineering e tornou-se uma disciplina de engenharia com datasets versionados, quality gates automatizados e rastreabilidade de regressões. O Bedrock AgentCore materializa esse salto ao trazer infraestrutura gerenciada para o ciclo de vida de testes de agentes. Para arquitetos de sistemas financeiros, isso muda o contrato entre equipes de ML e engenharia de plataforma. - URL: https://fernando.moretes.com/blog/avaliacao-agentes-bedrock-agentcore-datasets - Markdown: https://fernando.moretes.com/blog/avaliacao-agentes-bedrock-agentcore-datasets/article.md?lang=pt - Published: 2026-06-06T09:55:00.000Z - Category: IA & Agentes - Tags: bedrock-agentcore, agent-evaluation, ai-testing, quality-gates, mlops, financial-grade, devops, observability - Reading time: 8 min - Source: [Build a test suite that grows with your agent using Bedrock AgentCore](https://aws.amazon.com/blogs/machine-learning/) --- 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 - **~40%** — dos incidentes de produção em agentes de IA rastreados a regressões de. Dado empírico de postmortems internos em equipes de LLMOps — regressões silenciosas são o modo de falha dominante - **10–30×** — custo de latência de avaliação manual versus avaliação automatizada com. Avaliação manual de um agente multi-turn em 50 casos pode levar dias; pipelines automatizados rodam em minutos - **3 camadas** — de observabilidade necessárias para agentes: traço de ferramenta, fidelidade de. Nenhuma métrica isolada cobre os três — suites de testes precisam compor avaliadores especializados ## 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 ### 🔧 Dev & CI — Source - Agent Code PR / commit (user) - CodePipeline / GitHub Actions (ci) ### 🟧 AWS — Bedrock AgentCore - AgentCore Eval Orchestrator (ai) - Dataset Store versioned + lineage (storage) - Agent Under Test Bedrock Runtime (ai) ### ⚖️ AWS — Evaluator Runtime - LLM-as-Judge Claude 3.5 Sonnet (ai) - Deterministic Heuristic Evals (compute) - Trace Fidelity Evaluator (OTel) (compute) ### 📊 AWS — Observability & Gate - CloudWatch Eval Metrics + Alarms (data) - S3 Eval Results + Audit Log (storage) - Quality Gate threshold check (security) ### Fluxos - dev -> ci: push / PR - ci -> agentcore: aciona avaliação - agentcore -> dataset: carrega dataset versionado - agentcore -> agent_ut: executa casos de teste - agent_ut -> llm_judge: saída → julgamento - agent_ut -> heuristic: saída → regras - agent_ut -> trace_eval: spans OTel → fidelidade - llm_judge -> agentcore: score - heuristic -> agentcore: score - trace_eval -> agentcore: score - agentcore -> cw: métricas de avaliação - agentcore -> s3_results: resultados + linhagem - agentcore -> gate: score composto - gate -> ci: pass / block deploy ## O que muda para arquitetos com este sinal - **Datasets de avaliação são artefatos de engenharia**: precisam de versionamento semântico, contratos de schema (ex.: JSON Schema ou Avro), e um dono de produto — não podem viver em um Google Sheet compartilhado. - **Quality gates de agente bloqueiam promoção de versão**: o mesmo padrão de feature flags e canary deployments que usamos para serviços precisa ser aplicado a versões de agente, com rollback automático quando scores de avaliação regridem além de um threshold (ex.: >5% de queda em fidelidade de ferramenta). - **LLM-as-judge requer calibração e auditabilidade**: usar Claude 3.5 Sonnet como juiz de outro agente Bedrock introduz um loop de dependência que precisa ser gerenciado — o modelo juiz deve ser fixado em uma versão específica e seus julgamentos devem ser amostrados e auditados por humanos periodicamente. - **Rastreabilidade de traço é requisito regulatório em finanças**: para agentes que tocam dados financeiros, cada chamada de ferramenta, cada decisão de roteamento e cada acesso a dados deve ser rastreável com correlação de trace ID — OpenTelemetry com exportação para CloudWatch X-Ray ou Datadog é o padrão mínimo. - **Custo de avaliação é uma variável de design**: rodar Claude 3.5 Sonnet como juiz em 500 casos de teste por PR pode custar $15–40 dependendo do tamanho do contexto — arquitetos precisam dimensionar suites de avaliação com consciência de custo, usando avaliadores determinísticos como filtro primário e LLM-as-judge apenas para casos ambíguos. - **Datasets sintéticos precisam de cobertura de edge cases financeiros**: geração automática de casos de teste via LLM tende a sub-representar edge cases de alto impacto (ex.: transações com valores negativos, moedas exóticas, falhas de idempotência) — equipes de domínio financeiro devem contribuir ativamente com casos de borda para o dataset store. ## 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-latest` como 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 - **security**: 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. - **reliability**: 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. - **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. - **cost**: 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. > **Nota do Curador:** 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. **Rating:** Adopt with governance ## Referências - [AWS Bedrock AgentCore — Agent Evaluation](https://aws.amazon.com/blogs/machine-learning/) - [Amazon Bedrock — Inference Profiles](https://docs.aws.amazon.com/bedrock/latest/userguide/inference-profiles.html) - [AWS Well-Architected — Machine Learning Lens](https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/welcome.html) - [OpenTelemetry — Semantic Conventions for GenAI](https://opentelemetry.io/docs/specs/semconv/gen-ai/) - [LangSmith — LLM Evaluation Platform](https://docs.smith.langchain.com/) - [NIST AI RMF — AI Risk Management Framework](https://airc.nist.gov/RMF) - [Amazon Bedrock — Batch Inference](https://docs.aws.amazon.com/bedrock/latest/userguide/batch-inference.html) - [AWS Step Functions — Map State](https://docs.aws.amazon.com/step-functions/latest/dg/amazon-states-language-map-state.html)