Algunas de las preguntas que se formulan al evaluar un agente son estrechas y repetibles. ¿Se mantuvo esta respuesta dentro de la política? ¿Es seguro aprobar esta llamada a la herramienta? ¿Coincide esta respuesta con el contexto recuperado? Los modelos de decisión responden exactamente a este tipo de preguntas. Toman un estado estructurado y un conjunto fijo de respuestas permitidas y devuelven una probabilidad calibrada sobre ellas, en lugar de texto de forma libre cuya confianza varía de una ejecución a otra. Eso los hace una buena opción para el paso de puntuación en la evaluación de un agente, donde se desea una etiqueta y un número que se pueda umbralizar y confiar.

Evaluaciones de Amazon Bedrock AgentCore, una capacidad de Amazon Bedrock AgentCore, puntuación a un agente a lo largo de todo su ciclo de vida, a demanda durante el desarrollo, en trabajos por lotes contra sesiones almacenadas y en línea contra tráfico de producción. Junto con 15 evaluadores integrados, las Evaluaciones de AgentCore admiten evaluadores personalizados que se definen como un juez LLM o un evaluador basado en código. Los evaluadores personalizados LLM-as-a-judge aplican sus instrucciones y escala de calificación con un modelo en Amazon Bedrock. Los evaluadores basados en código ejecutan su propia lógica en una función AWS Lambda, y esa lógica puede llamar a su elección de sistema externo, modelo o API, incluido un modelo de decisión.

Los modelos de decisión se adaptan a preguntas con un conjunto fijo de respuestas que una persona informada podría decidir a primera vista, como si el agente rechazó una solicitud o si una respuesta se mantuvo en el tema. Después de validar una pregunta en su propio tráfico, un modelo de decisión puede ser suficiente para esa decisión o puntuación, y puede extender el mismo enfoque a categorías específicas de daño o estereotipos en su política. Debido a que ambas partes traseras pueden responder varias preguntas sobre el mismo estado en una sola solicitud, puede utilizarlas como una capa de selección en lugar de un reemplazo, ejecutando una señal de aprobación o rechazo a través de sus métricas para seleccionar las vueltas que merecen una evaluación más profunda por parte de los evaluadores integrados, cuyas explicaciones lo ayudan a investigar qué salió mal.

Esta publicación muestra cómo conectar dos partes traseras de modelos de decisión a las Evaluaciones de AgentCore a través de evaluadores basados en código. El primero es Jev, un modelo de decisión alojado de TypeSafe. El segundo es Strands Decider 2B, un modelo de decisión de código abierto que se ejecuta usted mismo. Al final de esta publicación, sabrá cómo convertir la entrada del evaluador de AgentCore en una solicitud de modelo de decisión, y las probabilidades del modelo nuevamente en un resultado de evaluación de AgentCore. Primero, sin embargo, ¿cuándo debe recurrir a un evaluador personalizado LLM-as-a-judge, y cuándo es mejor un modelo de decisión? La siguiente sección desglosa qué es un modelo de decisión y las compensaciones involucradas.

Modelos de decisión

Un modelo de decisión es un modelo pequeño y especializado entrenado para seleccionar de un conjunto fijo de opciones y devolver puntajes de confianza calibrados en lugar de generar texto de forma libre. Un evaluador de modelo de lenguaje grande (LLM) de propósito general produce un puntaje con una justificación. Un modelo de decisión, en cambio, produce una distribución de probabilidad sobre respuestas predefinidas. Eso te da una medida directa de confianza que puedes umbralizar, agregar y actuar sobre de manera programática. Esto hace que los modelos de decisión sean adecuados para tareas de evaluación donde el juicio se puede expresar como una elección entre un conjunto fijo de opciones: "¿Está esta respuesta fundamentada?" o "¿El agente completó la meta del usuario!"

Los modelos de decisión son más útiles cuando deseas un puntaje de confianza bien calibrado junto con la etiqueta, no solo un juicio binario. También son adecuados cuando deseas aplicar un rubric específico de manera consistente sin depender de un LLM de propósito general para interpretarlo.

Jev, el modelo de decisión alojado de TypeSafe, y Strands Decider, un modelo de decisión de código abierto de 2 mil millones de parámetros del equipo de Strands Agents, ambos admiten tres tipos de preguntas. Una pregunta noul plantea una pregunta de sí/no y devuelve una probabilidad entre 0 (no) y 1 (sí). Una pregunta choice pregunta cuál de hasta 255 opciones se aplica, devolviendo la opción más probable junto con la distribución completa y una confianza. Una pregunta score pregunta cuál de 2 a 10 niveles ordenados se aplica, devolviendo una puntuación ponderada por probabilidad, la distribución sobre los niveles y una confianza. Muchas rúbricas de evaluación se ajustan a uno de estos tipos. "¿Está cada hecho en esta respuesta respaldado por los resultados de la herramienta?" es una pregunta de sí/no, y "¿Cuán útil fue esta respuesta, en una rúbrica de cuatro niveles?" es una puntuación.

Modelos de decisión versus LLM como juez

Los evaluadores integrados en AgentCore hoy utilizan un LLM de propósito general para evaluar la respuesta del agente contra una rúbrica y explicar su juicio. Esto es valioso cuando la evaluación requiere conectar evidencia, identificar información faltante o trabajar en una respuesta en profundidad en tareas donde la explicación es tan útil como el puntaje. Los modelos de decisión no son un reemplazo para los evaluadores LLM. Son una adición que el marco de evaluador basado en código hace posible. Úsalos para comprobaciones estrechas y bien definidas junto con la evaluación más amplia de los evaluadores integrados.

Visión general de la solución

Para mostrar cómo funcionan juntos estos tipos de evaluadores, esta publicación construye un ejemplo de extremo a extremo de un agente de asistente de recursos humanos evaluado por comprobaciones deterministas basadas en código, evaluadores LLM como juez integrados y evaluadores de modelo de decisión respaldados por Jev o Strands Decider 2B.

El agente se construye con Strands Agents y se implementa en el runtime de AgentCore, una capacidad de Amazon Bedrock AgentCore. Responde a las preguntas de los empleados utilizando cinco herramientas que devuelven datos mock fijos, como saldos de tiempo libre pagado (PTO), solicitudes de PTO, políticas de RRHH, beneficios y talones de pago. Utilizamos datos fijos en este ejemplo de código para que sea sencillo verificar el comportamiento del evaluador desde LLM-as-a-judge y los modelos de decisión. Cuando también tengas la verdad fundamental, puedes confirmar si cada evaluador detecta los fallos correctos. Este ejemplo de código te ayuda a configurar el framework para probar los modelos de decisión en comparación con LLM-as-a-judge para tus propios casos de uso.

Figura 1: Arquitectura de extremo a extremo del asistente de RRHH evaluado por controles basados en código, evaluadores integrados y evaluadores de modelo de decisión respaldados por Jev o Strands Decider

Requisitos previos

Para implementar el ejemplo, necesitas lo siguiente:

• Una cuenta de AWS en una Región donde esté disponible AgentCore Evaluations. El ejemplo predeterminado es US West (Oregon).
• Amazon CloudWatch Transaction Search habilitado en la cuenta.
• Acceso a un modelo base en Amazon Bedrock.
• Python 3.12 o posterior, la interfaz de línea de comandos de AWS (AWS CLI) y Docker.
• Jev requiere una clave de API de TypeSafe. Visita typesafe.ai para obtener detalles de acceso.
• Strands Decider requiere un host que ejecute el servidor de Strands Decider. Puedes ejecutarlo localmente para pruebas o en Amazon Elastic Compute Cloud (Amazon EC2) dentro de tu red privada virtual (VPC) para que la función Lambda pueda alcanzarlo.

Verlo en acción

Puedes encontrar el ejemplo de código completo en el repositorio de GitHub de ejemplos de AgentCore. Dos scripts de Python manejan todo:

• ../utils/deploy.py despliega el asistente de RRHH en el runtime de AgentCore.
• evaluate.py despliega evaluadores, invoca al agente y ejecuta los modos de evaluación.

Ejecutar evaluate.py sin flags ejecuta cinco pasos:

1. Crea el rol de ejecución de Lambda (AgentCoreLambdaEvaluatorRole).
2. Empaqueta y despliega dos evaluadores de Lambda deterministas: hr-response-length (un evaluador de nivel de traza que verifica si la respuesta del agente se mantiene dentro de los límites de longitud) y hr-fact-checker (un evaluador de nivel de sesión que valida hechos de RRHH contra los datos de mock conocidos mediante regex).
3. Registra ambos como evaluadores de código de AgentCore a través del plano de control.
4. Ejecuta la evaluación bajo demanda con EvaluationClient y OnDemandEvaluationDatasetRunner en cinco escenarios etiquetados, combinando los evaluadores de código con Builtin.Correctness, Builtin.Helpfulness y Builtin.ResponseRelevance.
5. Crea una configuración de evaluación en línea que califica sesiones en vivo de forma continua con una muestra del 100 por ciento.

En este punto, tiene una canalización de evaluación funcionando con controles deterministas y puntuación de LLM como juez. Los evaluadores de modelo de decisión son opcionales. Puede agregarlos con una flag y se ejecutan junto con los evaluadores base sin cambios en el flujo existente. Utilizando la flag --with-jev --jev-secret-arn <ARN> despliega jev-evaluator y registra tres evaluadores: JevGroundedness, JevHelpfulness y JevGoalCompletion. Utilizando la flag --with-decider despliega strands-decider-evaluator y registra los mismos tres evaluadores respaldados por Strands Decider 2B. Agregue --decider-ec2 para aprovisionar automáticamente la instancia de Amazon EC2, grupos de seguridad, rol de IAM y configuración de VPC de Lambda sin pasos manuales de consola.

Figura 2: La canalización de evaluación desplegada por evaluate.py, desde controles deterministas hasta evaluadores integrados y de modelo de decisión

Cada backend de modelo de decisión contribuye con tres evaluadores:

Construir el evaluador con modelos de decisión

Usando las banderas --with-jev y --with-decider se crea un evaluador personalizado basado en código, donde tiene el control total del código que desea ejecutar como evaluador. Creamos funciones AWS Lambda donde el modelo de decisión se invoca dentro de una función AWS Lambda y devuelve una etiqueta o un valor numérico. Esta función Lambda se registra como el evaluador basado en código en AgentCore Evaluations.

La Lambda que se registra como evaluador recibe trazas OpenTelemetry del agente. El módulo spans.py normaliza las formas en que el contenido OpenTelemetry puede llegar y luego lo formato adecuadamente para hacer la llamada al modelo de decisión. Para la evaluación a nivel de traza, solo se envían el turno objetivo y la historia breve anterior, mientras que la conversación completa se incluye para el nivel de sesión.

Figura 3: Cómo el evaluador Lambda basado en código adapta trazas OpenTelemetry para el modelo de decisión y mapea el resultado de regreso a AgentCore

El adaptador convierte la distribución de probabilidad del modelo en un resultado que la evaluación de AgentCore espera. Para una pregunta noul, la probabilidad de true se convierte en el valor y la respuesta más probable se convierte en la etiqueta. Para una pregunta score, el valor es el nivel esperado con ponderación de probabilidad escalado a [0, 1]. Para una pregunta choice, es el promedio ponderado de valores de opciones predefinidas.

Validar un evaluador de modelo de decisión en su propio tráfico

Cuando reescribas una rúbrica como una pregunta de modelo de decisión, habrás creado una nueva medición en lugar de una copia de la antigua. Una rúbrica reenfocada a menudo resulta más estricta o más flexible que la originalmente pretendida, y no verás ese desvío hasta que la compares con sesiones reales. Antes de bloquear una versión en un evaluador de modelo de decisión, valídallo de la misma manera que validarías cualquier nueva medición, contra una muestra etiquetada de tu propio tráfico. El objetivo de esta sección es guiarte a través de esa validación de principio a fin, para que termines con un evaluador con el que puedas establecer umbrales con confianza.

El procedimiento tiene cinco pasos.

Paso 1. Crea una muestra etiquetada. Extrae un conjunto de sesiones almacenadas del tráfico de tu agente, con suficiente cobertura de los fallos y casos límite que te importan. Una muestra que solo cubre la ruta feliz no te dice nada sobre dónde se rompe el evaluador.

Paso 2. Obten etiquetas de referencia humanas. Haz que tres etiquetadores independientes califiquen cada turno para la propiedad que mide tu pregunta y tomen el voto mayoritario como la etiqueta de referencia. Mantén un registro de qué turnos fueron unánimes y cuáles estuvieron divididos. Aunque los turnos unánimes son los casos claros, los turnos con voto dividido son los valiosos, porque revelan ambigüedad en la rúbrica en sí antes de que el modelo la vea.

Paso 3. Ejecuta ambos evaluadores en las mismas entradas. Ejecuta el evaluador de modelo de decisión y el evaluador integrado coincidente en esas mismas sesiones en una evaluación por lotes única. Calificar entradas idénticas es lo que hace que la comparación sea justa.

Paso 4. Lee los resultados a través de tres lentes. Con las etiquetas de voto mayoritario y la división fácil y difícil en mano, ahora puedes responder las tres preguntas que te dicen si el evaluador está listo.

• Tasa de acuerdo: ¿coincide con tus humanos? Mida con qué frecuencia cada evaluador está de acuerdo con las etiquetas de votación mayoritaria y hágalo por pregunta, ya que la precisión de una pregunta no dice nada sobre la de otra. Luego desglose los números por casos fáciles (unánimes) y difíciles (votos divididos). Un evaluador que tropieza solo en los casos difíciles se comporta mucho como lo hicieron tus etiquetadores humanos, lo que es exactamente lo que deseas.
• Calibración: ¿los puntajes de confianza significan algo? Agrupe las vueltas por la probabilidad informada del evaluador y compare el acuerdo de cada grupo con las etiquetas. Una mayor confianza debe rastrear una mayor precisión. Luego verifique si los casos fáciles consistentemente atraen una mayor confianza que los difíciles. Si lo hacen, la incertidumbre del modelo está rastreando la ambigüedad genuina, y puede usar esos grupos para elegir un umbral de decisión por evaluador en lugar de usar el valor predeterminado de 0,5.
• Análisis de desacuerdo: ¿dónde y por qué difieren? Encuentre las vueltas donde los dos evaluadores no están de acuerdo entre sí y verifique si esas son las mismas vueltas que sus humanos encontraron ambiguas. Léalas. La mayoría de los desacuerdos se remontan a la redacción de la pregunta, y una pregunta revisada las aclara. Cuando los errores se agrupan en los casos difíciles, el rubric es el problema en lugar del modelo.

Paso 5. Vuelva a ejecutar la comprobación cuando algo cambie. Trátelo como una comprobación repetible en lugar de una puerta de una sola vez. Cada vez que reformule una pregunta o pase a una nueva versión del modelo, ejecute la comprobación nuevamente. Cada explicación de resultado registra la versión del modelo que lo produjo, por lo que sabe de qué versión provino una puntuación determinada.

Elección del mejor conjunto de evaluadores para su agente

Los evaluadores integrados siguen siendo la base de la estrategia de evaluación amplia en AgentCore Evaluations. Evalúan la respuesta contra un rubric y su contexto de apoyo, y explican el juicio para que los desarrolladores puedan investigar qué salió mal. Para el asistente de recursos humanos, una evaluación de fidelidad puede identificar una afirmación que contradice un resultado de herramienta, mientras que una evaluación de utilidad puede señalar que el agente respondió una pregunta de equilibrio pero dejó una acción solicitada incompleta.

La fidelidad, la utilidad y la corrección pueden requerir conectar evidencia, identificar información faltante o trabajar a través de una solución. El preprint JEV-as-a-Judge: Accept When Confident, Escalate When Unsure describe una distinción relacionada como “leer versus derivar”. Una verificación de modelo de decisión estrecha puede marcar un turno para llamar la atención, mientras que el evaluador integrado proporciona la evaluación y razonamiento más amplias necesarias para revisarlo. Los modelos de decisión brillan con más fuerza cuando se los trata como una puerta en lugar de un reemplazo. El patrón de cascada funciona de la siguiente manera. Primero, ejecuta un modelo de decisión rápido y calibrado en cada turno de cada sesión para obtener una señal de aprobado/reprobado a bajo costo. Luego, invoca un evaluador de LLM completo solo en las sesiones donde la señal decae por debajo de su umbral.

Figura 4: El patrón de cascada, donde un modelo de decisión calibrado examina cada turno y solo los turnos de baja confianza escalan a un evaluador integrado

Recomendamos la siguiente configuración:

1. Configure la evaluación en línea con los evaluadores integrados en los que confías, como la medida estándar de calidad en todos tus agentes.
2. Agrega evaluadores de modelo de decisión para preguntas de sí/no y de elección específicas del dominio a la misma configuración, junto con evaluadores deterministas basados en código para cualquier cosa que puedas calcular con exactitud.
3. Cada semana, o según el calendario que se adapte a tu ciclo de lanzamiento, consulta los resultados en línea de las sesiones donde falló una comprobación del modelo de decisión o obtuvo una puntuación cerca de su umbral, y ejecuta evaluaciones por lotes en esas sesiones con los evaluadores integrados para obtener explicaciones.
4. Controla los lanzamientos con los evaluadores integrados y con los evaluadores de modelo de decisión que hayas validado contra datos etiquetados, y rastrea con qué frecuencia están de acuerdo los dos.

Limpieza

Para evitar cargos continuos, ejecuta el cleanup.py que elimina el agente alojado en el runtime de AgentCore, los evaluadores y la configuración de evaluación, las funciones de AWS Lambda registradas como evaluadores, la instancia de EC2 que aloja el modelo de Strands Decider, la clave de AWS Secrets Manager y el grupo de registros asociado en CloudWatch.

Conclusión

En esta publicación, conectaste dos modelos de decisión, Jev y Strands Decider, a las Evaluaciones de AgentCore utilizando evaluadores basados en código, y la muestra de código acompañante te proporciona un marco para probar esos modelos y ver dónde agregan valor como evaluadores. Los evaluadores integrados siguen siendo tu referencia. Los modelos de decisión agregan comprobaciones validadas y estrechas que vienen con una medida de certeza que puedes umbralizar y actuar en consecuencia. El camino práctico hacia adelante es agregar comprobaciones de modelo de decisión junto con los evaluadores integrados que ya ejecutas, medir con qué frecuencia están de acuerdo con tus etiquetas de referencia en tu propio tráfico y ampliar la cobertura solo una vez que confíes en ellos.

Para empezar, revisa la documentación de Evaluaciones de Amazon Bedrock AgentCore, integra evaluadores personalizados utilizando evaluadores basados en código y haz una mirada más profunda al modelo de Strands Decider. Comienza con muestras de código implementando los evaluadores de muestra del repositorio de muestras de Amazon Bedrock AgentCore.

Sobre los autores