Bedrock AgentCore Evaluations cobre vazamento de dados e pulo de etapas em agentes antes de produção

O problema que o dashboard não mostra

Um agente de suporte pode resolver 100% dos tickets e ainda assim vazar dado pessoal na resposta. Taxa de conclusão alta, falha grave escondida. É esse o alerta que a AWS faz num post recente do AWS Machine Learning Blog sobre o Amazon Bedrock AgentCore Evaluations: latência, spot-check manual e feedback de usuário não respondem se o agente seguiu as etapas certas, se ficou no assunto numa sessão longa ou se vazou informação sensível.

O post chama isso de comportamento "abaixo da linha d'água": o time vê o que está na superfície (o agente rodou, respondeu, não caiu) e não vê o que decide se o agente serve para o negócio. Para quem bota agente Bedrock em produção, essa é a diferença entre testar se o código roda e testar se ele faz o que prometeu.

Comece pelo resultado de negócio, não pelo nome da métrica

A AWS recomenda inverter a ordem usual de trabalho. Em vez de abrir o catálogo de métricas e escolher a que "parece certa" ("Helpfulness soa bem, vamos de Helpfulness"), o caminho sugerido tem três passos:

1. Definir sucesso em termos de negócio: para um agente de suporte, resolução no primeiro contato; para um agente de pesquisa, resposta completa e rastreável às fontes.
2. Quebrar esse resultado em comportamentos observáveis: completar o objetivo, manter coerência entre turnos, respeitar limite de compliance, chamar a ferramenta certa.
3. Mapear cada comportamento para um avaliador no nível certo: métricas de trace cobrem comportamento por turno ou chamada de ferramenta; métricas de sessão olham a conversa inteira.

Quem pula direto para a lista de métricas tende a rodar uma avaliação que produz número, mas não produz decisão.

Três fontes de avaliadores, um catálogo só

O AgentCore Evaluations organiza os avaliadores em três camadas, acessíveis pelo mesmo catálogo e pela mesma API ListEvaluators:

• Built-in: mantidos e testados pela própria AWS, chamados por ID (Builtin.GoalSuccessRate, Builtin.Helpfulness e mais 13). O serviço cuida de tudo; é o ponto de partida natural.
• Third-party gerenciados: DeepEval e AutoEval, duas bibliotecas open-source de avaliação. Em modo gerenciado, o AgentCore hospeda o código, escolhe o modelo-juiz e roda a inferência na própria capacidade do serviço, igual aos built-in.
• Custom: parte de um avaliador built-in ou third-party como base e permite trocar o modelo-juiz ou editar o prompt/rubrica. Depois de criado, um avaliador custom se usa exatamente como os outros.

Os built-in cobrem cinco grupos: qualidade de resposta (Correctness, Faithfulness, Helpfulness, ResponseRelevance, Conciseness, Coherence, InstructionFollowing, Refusal), conclusão de tarefa/objetivo (GoalSuccessRate, de nível sessão), uso de ferramenta (ToolSelectionAccuracy, ToolParameterAccuracy), skills (SkillSelectionAccuracy, SkillInstructionFollowing) e segurança (Harmfulness, Stereotyping). Há ainda três checagens de trajetória contra um caminho esperado (TrajectoryExactOrderMatch, TrajectoryInOrderMatch, TrajectoryAnyOrderMatch), úteis quando o caminho que o agente percorreu importa tanto quanto a resposta final.

O DeepEval entra com métricas fortes para agente multi-turno: ConversationCompleteness flagra quando o agente responde à última mensagem e silenciosamente ignora um pedido anterior; KnowledgeRetention pega o agente que esquece algo que o usuário disse três turnos atrás. Completam o conjunto TaskCompletion, GoalAccuracy, TurnRelevancy, Summarization, ToolUse, Bias, Toxicity e PIILeakage — este último é o que detecta o vazamento de dado pessoal citado no exemplo do agente de suporte.

O AutoEval traz sinais mais específicos: Security flagra tentativa de injeção de instrução ou de extrair o prompt de sistema; Possible pega agente excessivamente cauteloso que declara impossível uma tarefa que era factível; Humor serve para agente conversacional onde personalidade importa.

Quando uma nota só não basta

Cada avaliador do catálogo devolve uma nota por trace ou por sessão. Isso funciona quando se mede um comportamento isolado, mas uma resposta de suporte boa precisa resolver o problema, seguir a política de reembolso e manter tom profissional ao mesmo tempo — um juiz único que pesa os três critérios devolve um número só, e não dá para saber qual critério puxou a nota para baixo.

Para esse caso o post descreve o avaliador multidimensional: um LLM-as-a-judge custom com uma lista de dimensões em vez de uma escala única. Cada dimensão tem nome, instrução e escala próprias; o juiz lê o trace uma vez e pontua todas as dimensões na mesma chamada, e o AgentCore devolve um resultado por dimensão, sem nota composta.

Vale a pena usar quando os critérios de sucesso podem falhar de forma independente — resposta correta mas fora de política, por exemplo — e quando dá para julgar tudo com a mesma evidência. Não vale a pena quando um critério já tem métrica pronta (Builtin.Correctness, ThirdParty.DeepEval.PIILeakage) ou quando os critérios precisam de modelo-juiz ou nível diferentes, já que as dimensões de um mesmo avaliador compartilham nível e modelo.

Três modos de rodar, mesma chamada de API

O AgentCore oferece três modos de execução, e trocar de um para outro é mudança de configuração, não reescrita de código:

• On-demand: chamada direta em client.evaluate() durante desenvolvimento ou depuração, com todo o catálogo disponível, incluindo third-party.
• Online: anexa ao runtime do agente em produção e amostra tráfego real numa taxa configurada; built-in e third-party se misturam livremente numa mesma configuração.
• Batch: roda uma pilha fixa de avaliadores contra um dataset de referência (o "golden dataset"), para regressão antes de um release — o jeito de confirmar que uma troca de prompt ou de modelo não quebrou nenhuma dimensão que importa.

O exemplo de código do post mostra o formato básico da chamada on-demand:

import boto3

client = boto3.client('bedrock-agentcore')

response = client.evaluate(
    evaluatorId="ThirdParty.DeepEval.TaskCompletion",
    evaluationInput={"sessionSpans": session_span_logs}
)

for result in response["evaluationResults"]:
    print(f"Value: {result.get('value')}")
    print(f"Explanation: {result.get('explanation', '')}")

Note que evaluatorId aceita o mesmo identificador seja o avaliador built-in, DeepEval, AutoEval ou custom — é essa uniformidade que permite testar em desenvolvimento e depois ligar o mesmo avaliador em produção sem tocar no pipeline.

Montando a pilha: o caso do agente de suporte

O post sugere começar com dois ou três avaliadores que capturem o resultado de negócio e só adicionar mais quando um modo de falha escapar desse primeiro conjunto. Para um agente de suporte, cujo risco principal é pedido abandonado ou resposta insegura/fora de compliance:

• Âncora: Builtin.GoalSuccessRate.
• ThirdParty.DeepEval.ConversationCompleteness para pegar pedido ignorado numa conversa longa.
• ThirdParty.DeepEval.PIILeakage para vazamento de dado pessoal.
• Adicionar depois, conforme a necessidade: ThirdParty.DeepEval.Toxicity e ThirdParty.AutoEval.Security quando o agente mexe com dado sensível de conta.

Para um agente de pesquisa multi-etapa, a âncora muda para Builtin.TrajectoryAnyOrderMatch (exige trajetória de referência, por isso só roda em avaliação batch) somado a ThirdParty.DeepEval.GoalAccuracy e KnowledgeRetention. Para conteúdo de domínio regulado (médico, jurídico, financeiro), o post é direto: resposta errada é pior que nenhuma resposta, então a pilha gira em torno de Builtin.Correctness com gabarito e ThirdParty.AutoEval.Security.

O que o post não diz

O material consultado não especifica preço por avaliação nem em quais regiões do Bedrock o AgentCore Evaluations está disponível — não há menção a sa-east-1 (São Paulo). Antes de decidir rodar avaliação online contra tráfego real de produção, vale checar a tabela de regiões e o guia de preços do AgentCore na documentação, porque cada chamada de avaliador dispara inferência de um modelo-juiz, e isso tem custo e cota como qualquer chamada ao Bedrock.

O ganho prático para quem já tem agente rodando em AgentCore Runtime é claro: o mesmo evaluatorId que você testa isolado em notebook vira sinal de saúde em produção e vira teste de regressão antes de cada release, sem três pipelines de avaliação diferentes para manter.

Fonte: AWS Machine Learning Blog