Use Modelos de Decisão com o Amazon Bedrock AgentCore Evaluations

O que são modelos de decisão e por que importam na avaliação de agentes

Ao avaliar um agente de Inteligência Artificial (IA), algumas perguntas são objetivas e se repetem com frequência: “essa resposta seguiu a política definida?”, “essa chamada de ferramenta é segura de aprovar?”, “a resposta está alinhada com o contexto recuperado?”. Para esse tipo de verificação, os modelos de decisão são uma escolha particularmente eficaz.

Diferente de um Modelo de Linguagem Grande (LLM, do inglês Large Language Model) de uso geral, que produz uma pontuação acompanhada de uma justificativa em texto livre, um modelo de decisão retorna uma distribuição de probabilidade sobre um conjunto fixo de respostas predefinidas. Isso oferece uma medida de confiança direta — que pode ser usada como limiar, agregada e processada programaticamente — sem depender de texto cuja confiança varia de execução para execução.

A Amazon Bedrock AgentCore Evaluations, uma capacidade do Amazon Bedrock AgentCore, avalia agentes em todo o seu ciclo de vida: sob demanda durante o desenvolvimento, em lotes contra sessões armazenadas e de forma contínua contra o tráfego em produção. Além de 15 avaliadores nativos, a plataforma suporta avaliadores personalizados definidos como LLM-as-a-judge ou como avaliadores baseados em código (code-based evaluators). É justamente nessa segunda categoria que os modelos de decisão se encaixam.

Como funcionam os modelos de decisão

Um modelo de decisão é um modelo pequeno e especializado, treinado para selecionar entre um conjunto fixo de opções e retornar pontuações de confiança calibradas. Ele não gera texto livre — produz uma distribuição de probabilidade sobre respostas predefinidas. Isso o torna ideal para tarefas de avaliação em que o julgamento pode ser expresso como uma escolha entre opções fixas, como “essa resposta está fundamentada?” ou “o agente completou o objetivo do usuário?”

Dois backends de modelos de decisão são apresentados como referência neste contexto. O Jev, modelo de decisão hospedado da TypeSafe, e o Strands Decider 2B, um modelo de código aberto com 2 bilhões de parâmetros desenvolvido pela equipe do Strands Agents. Ambos suportam três tipos de perguntas:

• Noul: pergunta de sim/não, retornando uma probabilidade entre 0 (não) e 1 (sim).
• Choice (escolha): pergunta sobre qual de até 255 opções se aplica, retornando a opção mais provável com a distribuição completa e uma pontuação de confiança.
• Score (pontuação): pergunta sobre qual de 2 a 10 níveis ordenados se aplica, retornando uma pontuação ponderada por probabilidade, a distribuição sobre os níveis e uma confiança.

Muitas rubricas de avaliação se encaixam em um desses tipos. “Cada fato nessa resposta está suportado pelos resultados das ferramentas?” é uma pergunta de sim/não. “Quão útil foi essa resposta, em uma rubrica de quatro níveis?” é uma pergunta de pontuação.

Modelos de decisão versus LLM-as-a-judge

Os avaliadores nativos do AgentCore usam um LLM de uso geral para avaliar a resposta do agente contra uma rubrica e explicar o julgamento. Isso é valioso quando a avaliação exige conectar evidências, identificar informações ausentes ou analisar uma resposta em profundidade — situações em que a explicação é tão útil quanto a pontuação.

Modelos de decisão não são um substituto para avaliadores LLM. São um complemento que o framework de avaliadores baseados em código torna possível. Use-os para verificações objetivas e bem definidas ao lado da avaliação mais ampla dos avaliadores nativos.

Um padrão em cascata funciona assim: primeiro, execute um modelo de decisão rápido e calibrado em cada turno de cada sessão para obter um sinal barato de aprovação/reprovação. Depois, invoque um avaliador LLM completo apenas nas sessões onde o sinal cair abaixo do limiar definido. Isso reduz custo e latência sem abrir mão da profundidade analítica quando ela é necessária.

Visão geral da solução: o agente HR Assistant

Para demonstrar como esses tipos de avaliadores funcionam juntos, a AWS construiu um exemplo ponta a ponta de um agente assistente de Recursos Humanos (RH), avaliado por verificações determinísticas, avaliadores LLM-as-a-judge nativos e avaliadores com modelos de decisão (Jev ou Strands Decider 2B).

O agente é construído com Strands Agents e implantado no AgentCore runtime. Ele responde a perguntas de funcionários usando cinco ferramentas que retornam dados simulados fixos, como saldos de dias de folga remunerada (PTO, do inglês Paid Time Off), solicitações de PTO, políticas de RH, benefícios e contracheques. O uso de dados fixos facilita a verificação do comportamento dos avaliadores.

Pré-requisitos para implantar o exemplo

Para implantar o exemplo, são necessários:

• Uma conta AWS em uma região onde o AgentCore Evaluations está disponível. O padrão do exemplo é US West (Oregon).
• Amazon CloudWatch Transaction Search habilitado na conta.
• Acesso a um modelo de fundação no Amazon Bedrock.
• Python 3.12 ou superior, AWS Command Line Interface (AWS CLI) e Docker.
• Jev exige uma chave de API da TypeSafe. Acesse typesafe.ai para detalhes.
• Strands Decider requer um servidor em execução — localmente para testes ou em uma instância do Amazon Elastic Compute Cloud (Amazon EC2) dentro da sua Virtual Private Cloud (VPC) para que a função AWS Lambda possa acessá-lo.

Como o pipeline de avaliação é montado

O código completo está disponível no repositório de exemplos do AgentCore no GitHub. Dois scripts Python cuidam de tudo: deploy.py implanta o agente no AgentCore runtime, e evaluate.py implanta os avaliadores, invoca o agente e executa os modos de avaliação.

Ao executar evaluate.py sem flags, cinco etapas são realizadas automaticamente:

• Criação do papel de execução Lambda (AgentCoreLambdaEvaluatorRole).
• Empacotamento e implantação de dois avaliadores Lambda determinísticos: hr-response-length (avaliador em nível de trace que verifica se a resposta do agente está dentro dos limites de tamanho) e hr-fact-checker (avaliador em nível de sessão que valida fatos de RH via regex contra os dados simulados conhecidos).
• Registro de ambos como avaliadores baseados em código no plano de controle do AgentCore.
• Execução de avaliação sob demanda com EvaluationClient e OnDemandEvaluationDatasetRunner em cinco cenários rotulados, combinando os avaliadores baseados em código com Builtin.Correctness, Builtin.Helpfulness e Builtin.ResponseRelevance.
• Criação de uma configuração de avaliação online que pontua sessões ao vivo continuamente com 100% de amostragem.

Os avaliadores com modelos de decisão são opcionais e ativados por flags. Usar --with-jev --jev-secret-arn <ARN> implanta o jev-evaluator e registra três avaliadores: JevGroundedness, JevHelpfulness e JevGoalCompletion. Usar --with-decider implanta o strands-decider-evaluator com os mesmos três avaliadores, desta vez apoiados pelo Strands Decider 2B. A flag --decider-ec2 provisiona automaticamente a instância EC2, grupos de segurança, papel IAM e configuração VPC do Lambda.

Cada backend de modelo de decisão contribui com três avaliadores, conforme a tabela a seguir:

• JevGroundedness / DeciderGroundedness — nível TRACE, tipo noul — retorna “Grounded” ou “Ungrounded” com probabilidade P(grounded).
• JevHelpfulness / DeciderHelpfulness — nível TRACE, tipo score (4 níveis) — retorna o nível mais provável escalado de 0 a 1.
• JevGoalCompletion / DeciderGoalCompletion — nível SESSION, tipo choice (3 opções) — retorna a opção mais provável com valor ponderado por probabilidade.

Como o adaptador converte spans OpenTelemetry para o modelo de decisão

A função Lambda registrada como avaliador recebe spans OpenTelemetry do agente. O módulo spans.py normaliza os formatos em que o conteúdo OpenTelemetry pode chegar e os formata adequadamente para a chamada ao modelo de decisão. Para avaliação em nível de trace, apenas o turno alvo e um breve histórico anterior são enviados; para nível de sessão, a conversa completa é incluída.

O adaptador converte a distribuição de probabilidade do modelo em um resultado que o AgentCore Evaluations espera. Para uma pergunta noul, a probabilidade de verdadeiro torna-se o valor e a resposta mais provável torna-se o rótulo. Para uma pergunta de pontuação, o valor é o nível esperado ponderado por probabilidade, escalado para o intervalo [0, 1]. Para uma pergunta de escolha, é a média ponderada de valores de opções predefinidos.

Como validar um avaliador com modelo de decisão no seu próprio tráfego

Ao reformular uma rubrica como uma pergunta de modelo de decisão, cria-se uma nova medição — não uma cópia da original. Uma rubrica reformulada pode acabar sendo mais rigorosa ou mais permissiva do que o pretendido, e esse desvio só aparece ao verificar contra sessões reais. Antes de usar um avaliador com modelo de decisão como critério de aprovação de releases, é recomendável validá-lo contra uma amostra rotulada do próprio tráfego. O procedimento tem cinco etapas:

• Etapa 1 — Construa uma amostra rotulada: extraia um conjunto de sessões armazenadas com boa cobertura de falhas e casos extremos relevantes.
• Etapa 2 — Obtenha rótulos de referência humanos: peça a três rotuladores independentes que pontuem cada turno e use o voto majoritário como rótulo de referência. Registre quais turnos foram unânimes e quais foram divididos.
• Etapa 3 — Execute os dois avaliadores nas mesmas entradas: rode o avaliador com modelo de decisão e o avaliador nativo correspondente sobre as mesmas sessões em uma única avaliação em lote.
• Etapa 4 — Leia os resultados por três ângulos: taxa de concordância com os humanos; calibração (se pontuações de maior confiança correspondem a maior precisão); análise de discordâncias (onde e por que os avaliadores divergem).
• Etapa 5 — Repita a verificação sempre que algo mudar: trate isso como uma verificação recorrente, não uma etapa única. Sempre que reformular uma pergunta ou migrar para uma nova versão do modelo, execute novamente.

Como escolher o conjunto ideal de avaliadores para seu agente

Os avaliadores nativos continuam sendo a base de uma estratégia ampla de avaliação no AgentCore Evaluations. Eles avaliam a resposta contra uma rubrica e seu contexto de suporte, e explicam o julgamento para que os desenvolvedores possam investigar o que deu errado. Para o agente de RH, por exemplo, uma avaliação de fidelidade pode identificar uma afirmação que contradiz um resultado de ferramenta, enquanto uma avaliação de utilidade pode apontar que o agente respondeu a uma pergunta de saldo mas deixou uma ação solicitada incompleta.

Modelos de decisão brilham quando tratados como uma camada de triagem, não como substitutos. A recomendação é a seguinte:

• Configure a avaliação online com os avaliadores nativos que você já usa como medida padrão de qualidade.
• Adicione avaliadores com modelos de decisão para perguntas de sim/não e de escolha específicas do domínio, junto com avaliadores determinísticos baseados em código para tudo que pode ser calculado exatamente.
• Periodicamente, consulte os resultados online para sessões onde uma verificação com modelo de decisão falhou ou ficou próxima do limiar, e execute avaliações em lote nessas sessões com os avaliadores nativos para obter explicações.
• Use como critério de aprovação de releases tanto os avaliadores nativos quanto os avaliadores com modelos de decisão que você já validou contra dados rotulados.

Limpeza de recursos

Para evitar cobranças contínuas, o script cleanup.py remove todos os recursos criados: o agente hospedado no AgentCore runtime, os avaliadores e a configuração de avaliação, as funções AWS Lambda registradas como avaliadores, a instância EC2 que hospeda o modelo Strands Decider, a chave do AWS Secrets Manager e o grupo de logs associado no CloudWatch.

Conclusão

A integração de modelos de decisão ao Amazon Bedrock AgentCore Evaluations por meio de avaliadores baseados em código oferece uma camada adicional de verificação calibrada e objetiva para pipelines de avaliação de agentes. Os avaliadores nativos continuam sendo a base — modelos de decisão como o Strands Decider adicionam verificações objetivas e validadas que vêm com uma medida de certeza passível de threshold e ação programática.

O caminho prático é adicionar verificações com modelos de decisão ao lado dos avaliadores nativos já em uso, medir com que frequência eles concordam com os rótulos de referência no tráfego real e expandir a cobertura apenas após confiar neles. Para começar, acesse os exemplos de código no repositório de exemplos do Amazon Bedrock AgentCore.

Fonte

Use decision models with Amazon Bedrock AgentCore Evaluations (https://aws.amazon.com/blogs/machine-learning/use-decision-models-with-amazon-bedrock-agentcore-evaluations/)