Su agente de IA trabajó en la demostración, impresionó a las partes interesadas, manejó escenarios de prueba y parecía estar listo para la producción. Luego lo implementaste y la imagen cambió. Los usuarios reales experimentaron llamadas de herramientas incorrectas, respuestas inconsistentes y modos de falla que nadie anticipó durante las pruebas.
El resultado es una brecha entre el comportamiento esperado del agente y la experiencia real del usuario en producción. La evaluación de agentes presenta desafíos para los que las pruebas de software tradicionales no fueron diseñadas. Debido a que los modelos de lenguaje grande (LLM) no son deterministas, la misma consulta de usuario puede producir diferentes selecciones de herramientas, rutas de razonamiento y resultados en múltiples ejecuciones. Esto significa que debe probar cada escenario repetidamente para comprender los patrones de comportamiento reales de su agente. Una sola pasada de prueba le indica lo que puede suceder, no lo que suele suceder. Sin una medición sistemática de estas variaciones, los equipos quedan atrapados en ciclos de pruebas manuales y depuración reactiva. Esto consume costos de API sin tener una idea clara de si los cambios mejoran el rendimiento del agente. Esta incertidumbre hace que cualquier modificación inmediata sea riesgosa y deja una pregunta fundamental sin respuesta: "¿Este agente es realmente mejor ahora?"
En esta publicación, presentamos Amazon Bedrock AgentCore Assessments, un servicio totalmente administrado para evaluar el rendimiento de los agentes de IA durante todo el ciclo de vida del desarrollo. Analizamos cómo el servicio mide la precisión de los agentes en múltiples dimensiones de calidad. Explicamos los dos enfoques de evaluación para el desarrollo y la producción y compartimos orientación práctica para crear agentes que pueda implementar con confianza.
Por qué la evaluación de agentes requiere un nuevo enfoque
Cuando un usuario envía una solicitud a un agente, se toman múltiples decisiones en secuencia. El agente determina a qué herramientas (si corresponde) llamar, ejecuta esas llamadas y genera una respuesta basada en los resultados. Cada paso introduce puntos de falla potenciales: seleccionar la herramienta incorrecta, llamar a la herramienta correcta con parámetros incorrectos o sintetizar los resultados de la herramienta en una respuesta final inexacta. A diferencia de las aplicaciones tradicionales en las que se prueba el resultado de una única función, la evaluación del agente requiere medir la calidad en todo este flujo de interacción.
Esto crea desafíos específicos para los desarrolladores de agentes que pueden abordarse haciendo lo siguiente:
Defina criterios de evaluación sobre lo que constituye una selección correcta de herramientas, parámetros de herramientas válidos, una respuesta precisa y una experiencia de usuario útil. Cree conjuntos de datos de prueba que representen solicitudes de usuarios reales y comportamientos esperados. Elija métodos de puntuación que puedan evaluar la calidad de manera consistente en ejecuciones repetidas.
Cada una de estas definiciones determina directamente lo que mide su sistema de evaluación y equivocarse significa optimizar para obtener resultados incorrectos. Sin este trabajo fundamental, la brecha entre lo que los equipos esperan que hagan sus agentes y lo que pueden demostrar que hacen se convierte en un riesgo comercial real. Cerrar esta brecha requiere un ciclo de evaluación continuo, como se muestra en la Figura 1. Los equipos crean casos de prueba, los ejecutan contra el agente, califican los resultados, analizan fallas e implementan mejoras. Cada falla se convierte en un nuevo caso de prueba y el ciclo continúa en cada iteración del agente.
Figura 1: El proceso de evaluación del agente sigue un ciclo continuo de casos de prueba, ejecución del agente, puntuación, análisis y mejoras. Los fracasos se convierten en nuevos casos de prueba.
Sin embargo, ejecutar este ciclo de principio a fin requiere una infraestructura significativa más allá de la lógica de evaluación misma. Los equipos deben seleccionar conjuntos de datos, seleccionar y alojar modelos de puntuación, gestionar la capacidad de inferencia y los límites de tasa de API, crear canales de datos que transformen los seguimientos de los agentes en formatos listos para la evaluación y crear paneles para visualizar tendencias. Para las organizaciones que ejecutan varios agentes, esta sobrecarga se multiplica con cada uno. El resultado es que los equipos de desarrollo de agentes terminan dedicando más tiempo a mantener las herramientas de evaluación que a actuar según lo que les dice. Este es el problema para el que se creó Amazon Bedrock AgentCore Assessments.
Presentamos las evaluaciones de Amazon Bedrock AgentCore
Lanzado por primera vez en versión preliminar pública en AWS re:Invent 2025, el servicio ya está disponible de forma generalizada. Maneja los modelos de evaluación, la infraestructura de inferencia, las canalizaciones de datos y el escalado para que los equipos puedan centrarse en mejorar la calidad de los agentes en lugar de crear y mantener sistemas de evaluación. Para los evaluadores integrados, la cuota del modelo y la capacidad de inferencia se gestionan por completo. Esto significa que las organizaciones que evalúan muchos agentes no consumen sus propias cuotas ni aprovisionan una infraestructura separada para las cargas de trabajo de evaluación.
Las evaluaciones de AgentCore examinan el comportamiento de los agentes de un extremo a otro utilizando rastreos de OpenTelemetry (OTEL) con convenciones semánticas de IA generativa. OTEL es un estándar de observabilidad de código abierto para recopilar seguimientos distribuidos de aplicaciones. Las convenciones semánticas de la IA generativa lo amplían con campos específicos de las interacciones del modelo de lenguaje, incluidas indicaciones, completaciones, llamadas a herramientas y parámetros del modelo. Al basarse en este estándar, el servicio funciona de manera consistente en todos los agentes creados con cualquier Strands Agents o LangGraph, e instrumentados con OpenTelemetry y OpenInference, capturando el contexto completo necesario para una evaluación significativa.
Las evaluaciones se pueden configurar con diferentes enfoques:
LLM-as-a-Judge donde un LLM evalúa la interacción de cada agente contra rúbricas estructuradas con criterios claramente definidos. La evaluación basada en Ground Truth se puede utilizar para comparar las respuestas de los agentes con conjuntos de datos predefinidos o simulados. Evaluadores de código personalizados donde puede incorporar un Lambda como evaluador con su propio código personalizado.
En el enfoque LLM como juez, el modelo Judge examina el contexto de interacción completo, incluido el historial de conversaciones, las herramientas disponibles, las herramientas utilizadas, los parámetros aprobados y las instrucciones del sistema, y luego proporciona un razonamiento detallado antes de asignar una puntuación. Cada partitura viene con una explicación. Los equipos pueden usar estas puntuaciones para verificar juicios, comprender exactamente por qué una interacción recibió una calificación particular e identificar qué debería haber sucedido de manera diferente. Este enfoque va más allá de simples juicios de aprobación/rechazo, ya que proporciona una evaluación estructurada y un razonamiento transparente que permite la evaluación de la calidad a una escala que la revisión manual no puede igualar.
Tres principios guían cómo el servicio aborda la evaluación. El desarrollo basado en evidencia reemplaza la intuición con métricas cuantitativas, de modo que los equipos pueden medir el impacto real de los cambios en lugar de debatir si una modificación inmediata "se siente mejor". La evaluación multidimensional evalúa diferentes aspectos del comportamiento del agente de forma independiente. Esto permite identificar exactamente dónde se necesitan mejoras en lugar de depender de una única puntuación agregada. La medición continua conecta las líneas base de desempeño establecidas durante el desarrollo directamente con el monitoreo de la producción, asegurando que la calidad se mantenga a medida que evolucionan las condiciones del mundo real. Estos principios se aplican durante todo el ciclo de vida del agente, desde la primera ronda de pruebas de desarrollo hasta el monitoreo continuo de la producción.
Evaluación a lo largo del ciclo de vida del agente
El viaje de un agente desde el prototipo hasta la producción crea dos necesidades de evaluación distintas. Durante el desarrollo, los equipos necesitan entornos controlados donde puedan comparar alternativas, probar el agente en conjuntos de datos seleccionados, reproducir resultados y validar los cambios antes de que lleguen a los usuarios. Una vez que el agente está activo, el desafío pasa a monitorear las interacciones del mundo real a escala, donde los usuarios encuentran casos extremos y patrones de interacción que ninguna cantidad de pruebas previas a la implementación anticiparon. La Figura 2 ilustra cómo la evaluación respalda cada etapa de este viaje, desde la prueba inicial de concepto hasta las pruebas paralelas, las pruebas A/B y el monitoreo continuo de la producción.
Figura 2: Desde POC hasta producción, la evaluación valida los agentes antes de la implementación. A medida que los agentes maduran, la evaluación respalda las pruebas paralelas, las pruebas A/B y el monitoreo continuo a escala.
Las evaluaciones de AgentCore asignan dos enfoques complementarios a estas fases del ciclo de vida, como se muestra en la Figura 3. La evaluación en línea maneja el monitoreo continuo de la producción, mientras que la evaluación bajo demanda respalda las pruebas controladas durante el desarrollo y los flujos de trabajo de integración continua y entrega continua (CI/CD), incluidas las evaluaciones contra la verdad del terreno.
Evaluación bajo demanda Evaluación en línea Ventajas Depuración paso a paso considerando la información del nivel de sesión Validación de componentes Integración de CI/CD Calidad de la conversación Monitoreo de interacciones de agentes en vivo Casos de uso Evaluación comparativa Validación de estabilidad Monitoreo de componentes Verificación previa al lanzamiento Muestreo continuo Paneles de control en vivo
Figura 3: La evaluación en línea monitorea continuamente el tráfico de producción, mientras que la evaluación bajo demanda respalda las pruebas controladas durante el desarrollo.
Evaluación en línea para el seguimiento de la producción.
La evaluación en línea monitorea las interacciones de los agentes en vivo muestreando continuamente un porcentaje configurable de seguimientos y calificándolos con los evaluadores elegidos. Usted define qué evaluadores aplicar, establece reglas de muestreo que controlan qué fracción del tráfico de producción se evalúa y configura los filtros adecuados. El servicio se encarga de leer seguimientos, ejecutar evaluaciones y mostrar resultados en el panel de Observabilidad de AgentCore con tecnología de Amazon CloudWatch. Si ya está recopilando seguimientos para la observabilidad, la evaluación en línea agrega puntuaciones de calidad con explicación, junto con sus métricas operativas existentes, sin necesidad de cambios de código ni reimplementaciones. La Figura 4 muestra cómo funciona este proceso.
Los problemas de calidad en la producción a menudo surgen de maneras que el monitoreo tradicional pasa desapercibido. Los paneles operativos pueden mostrarse en verde en cuanto a latencia y tasas de error, mientras que la experiencia del usuario se degrada silenciosamente porque el agente comienza a seleccionar herramientas incorrectas o a proporcionar respuestas menos útiles. La puntuación de calidad continua detecta estos fallos silenciosos mediante el seguimiento de las métricas de evaluación junto con las operativas. Debido a que AgentCore Observability se ejecuta en CloudWatch, puede crear paneles personalizados y configurar alarmas para recibir alertas en el momento en que las puntuaciones caigan por debajo de sus umbrales.
Evaluación bajo demanda para el desarrollo
La evaluación bajo demanda es una API en tiempo real diseñada para desarrollo y flujos de trabajo de CI/CD. Los equipos lo utilizan para probar los cambios antes de la implementación, ejecutar conjuntos de evaluación como parte de los procesos de CI/CD, realizar pruebas de regresión en todas las compilaciones y controlar las implementaciones en umbrales de calidad. Los desarrolladores seleccionan una sesión completa y especifican intervalos exactos (operaciones individuales dentro de un seguimiento) o seguimientos proporcionando sus ID. El servicio considera la conversación de la sesión completa y califica los tramos/rastros individuales con los mismos evaluadores utilizados en producción. Los casos de uso comunes incluyen validar cambios rápidos, comparar el rendimiento del modelo entre alternativas y prevenir regresiones de calidad.
Figura 5: La evaluación bajo demanda permite a los desarrolladores preparar conjuntos de datos de seguimiento, invocar evaluaciones a través de una canalización de CI/CD o un entorno de desarrollo y recibir puntuaciones utilizando evaluadores integrados o personalizados impulsados por los modelos básicos de Amazon Bedrock.
Debido a que ambos modos utilizan los mismos evaluadores, lo que prueba en CI/CD es lo que monitorea en producción, lo que le brinda estándares de calidad consistentes durante todo el ciclo de vida de desarrollo. La evaluación bajo demanda proporciona el entorno controlado necesario para las decisiones de arquitectura y la mejora sistemática, mientras que la evaluación en línea mantiene el seguimiento de la calidad después de que el agente esté activo. Juntos, los dos modos forman un circuito de retroalimentación continua entre el desarrollo y la producción, y ambos se basan en el mismo conjunto de evaluadores e infraestructura de puntuación.
Cómo AgentCore evalúa a su agente
AgentCore Assessments organiza las interacciones de los agentes en una jerarquía de tres niveles que determina qué se puede evaluar y con qué granularidad. Una sesión representa una conversación completa entre un usuario y su agente, agrupando todas las interacciones relacionadas de un único usuario o flujo de trabajo. Dentro de cada sesión, un seguimiento captura todo lo que sucede durante un único intercambio. Cuando un usuario envía un mensaje y recibe una respuesta, ese viaje de ida y vuelta produce un rastro que contiene cada paso que dio el agente para generar su respuesta. A su vez, cada seguimiento contiene operaciones individuales llamadas intervalos, que representan acciones específicas que realizó su agente, como invocar una herramienta, recuperar información de una base de conocimientos o generar texto.
Diferentes evaluadores operan en diferentes niveles de esta jerarquía, y los problemas en un nivel pueden verse muy diferentes de los problemas en otro. El servicio proporciona 13 evaluadores integrados preconfigurados organizados en estos tres niveles, cada uno de los cuales mide un aspecto distinto del comportamiento del agente (Figura 6). Puede definir evaluadores personalizados utilizando LLM-as-a-Judge y evaluadores de código personalizados que pueden trabajar en niveles de sesión, seguimiento y extensión.
Evaluadores de nivel Propósito Verdad sobre el terreno Uso Sesión Tasa de éxito de objetivos Evalúa si todos los objetivos del usuario se completaron dentro de una conversación El usuario proporciona afirmaciones textuales de forma libre sobre la consecución de objetivos, que se comparan con el comportamiento del sistema y se miden mediante el seguimiento de la tasa de éxito de objetivos Utilidad, corrección, coherencia, concisión, fidelidad, nocividad, seguimiento de instrucciones, relevancia de la respuesta, relevancia del contexto, rechazo, estereotipos Evalúa la calidad de la respuesta, precisión, seguridad y eficacia de la comunicación Verdad sobre el terreno de nivel (p. ej., respuesta o atributos esperados) por turno) admite la evaluación de la corrección de la herramienta, la precisión de la selección de la herramienta y la precisión de los parámetros de la herramienta. Evalúa las decisiones de selección de herramientas y la precisión de la extracción de parámetros. La verdad sobre el terreno de la llamada de herramienta especifica la secuencia correcta de la herramienta, lo que permite la coincidencia de trayectoria en orden exacto, la coincidencia de trayectoria en orden y la coincidencia de trayectoria en cualquier orden.
Figura 6: Los evaluadores integrados funcionan a nivel de sesión, seguimiento y herramienta. Cada nivel mide diferentes aspectos del comportamiento del agente. Ground Truth se puede proporcionar como afirmaciones, respuesta esperada y trayectoria esperada para evaluación a nivel de sesión, seguimiento y herramienta.
Evaluar cada nivel de forma independiente ayuda a los equipos a diagnosticar si un problema se origina en la selección de herramientas, la generación de respuestas o la planificación a nivel de sesión. Un agente puede elegir la herramienta adecuada con parámetros precisos pero luego sintetizar mal el resultado de la herramienta en su respuesta final. Este patrón sólo se vuelve visible cuando cada nivel se evalúa por sí solo. El propósito principal de su agente guía a qué evaluadores priorizar. Los agentes de servicio al cliente deben centrarse en la utilidad, la tasa de éxito de los objetivos y el seguimiento de las instrucciones, ya que resolver los problemas de los usuarios dentro de límites definidos afecta directamente la satisfacción. Los agentes con componentes de generación aumentada de recuperación (RAG) se benefician más de la corrección y la fidelidad para garantizar que las respuestas se basen en el contexto proporcionado. Los agentes que utilizan muchas herramientas necesitan puntuaciones sólidas en precisión de selección de herramientas y precisión de parámetros de herramientas. Se recomienda comenzar con tres o cuatro evaluadores que se alineen con el propósito de su agente y ampliar la cobertura a medida que madure su comprensión.
Comprender las distinciones del evaluador
Algunos evaluadores interactúan naturalmente entre sí, por lo que las puntuaciones deben leerse juntas y no de forma aislada. Los evaluadores que parecen similares a menudo miden cosas fundamentalmente diferentes, y comprender estas distinciones es importante para el diagnóstico.
La corrección verifica si la respuesta es objetivamente precisa, mientras que la fidelidad verifica si es consistente con el historial de la conversación. Por ejemplo, un agente puede ser fiel a un material fuente defectuoso pero aun así estar equivocado. La utilidad pregunta si la respuesta hace avanzar al usuario hacia su objetivo, mientras que la relevancia de la respuesta pregunta si aborda lo que se preguntó originalmente. Por ejemplo, un agente puede responder exhaustivamente a la pregunta equivocada. La coherencia comprueba las contradicciones internas en el razonamiento, mientras que la relevancia del contexto comprueba si el agente tenía disponible la información correcta. Por ejemplo, uno revela un problema de generación, el otro un problema de recuperación.
Algunos evaluadores también dependen unos de otros o se compensan entre sí. Por ejemplo:
La precisión de los parámetros de la herramienta es significativa solo cuando el agente ha seleccionado la herramienta correcta, por lo que primero se debe abordar la baja precisión de la selección de herramientas. La corrección a menudo depende de la relevancia del contexto porque un agente no puede generar respuestas precisas sin la información correcta. La concisión y la utilidad a menudo entran en conflicto porque las respuestas breves pueden omitir el contexto que los usuarios necesitan.
Los evaluadores integrados se entregan con plantillas de indicaciones predefinidas, modelos de evaluadores seleccionados y criterios de puntuación estandarizados, con configuraciones fijas para preservar la coherencia entre las evaluaciones. Utilizan inferencia entre regiones para seleccionar automáticamente la computación de las regiones de AWS dentro de su geografía, lo que mejora la disponibilidad y el rendimiento del modelo y, al mismo tiempo, mantiene los datos almacenados en la región de origen. Los evaluadores personalizados amplían esta base con soporte para su propio modelo de evaluador, instrucciones de evaluación, criterios y esquema de puntuación. Son particularmente valiosos para evaluaciones específicas de la industria, como la verificación del cumplimiento en servicios financieros o de atención médica, la verificación de la coherencia de la voz de la marca o el cumplimiento de los estándares de calidad organizacionales. Los evaluadores de código personalizados le permiten incorporar una función AWS Lambda para realizar las evaluaciones. Esto también le permite crear una puntuación determinista de sus agentes.
Para casos de uso que requieren todo el procesamiento dentro de una sola región, los evaluadores personalizados también brindan control total sobre la configuración de inferencia. Al crear un evaluador personalizado, define instrucciones con marcadores de posición que se reemplazan con información de seguimiento real antes de enviarse al modelo de juez. El alcance de la información disponible depende del nivel del evaluador: un evaluador a nivel de sesión puede acceder al contexto completo de la conversación y a las herramientas disponibles, un evaluador a nivel de seguimiento ve los turnos anteriores más la respuesta actual del asistente, y un evaluador a nivel de herramienta se centra en llamadas de herramientas específicas dentro de su contexto circundante. La consola de AWS ofrece la opción de cargar la plantilla de solicitud de cualquier evaluador integrado existente como punto de partida, lo que facilita la creación de variantes personalizadas (Figura 7).
Figura 7: La consola de AgentCore Assessments ofrece la opción de cargar cualquier plantilla de solicitud de evaluador integrada como punto de partida al crear un evaluador personalizado.
Al crear varios evaluadores personalizados, utilice el principio MECE (mutuamente exclusivo, colectivamente exhaustivo) para diseñar su conjunto de evaluación. Cada evaluador debe tener un alcance distinto y que no se superponga y, al mismo tiempo, cubrir colectivamente todas las dimensiones de calidad que le interesan. Por ejemplo, en lugar de crear dos evaluadores que evalúen parcialmente la “calidad de la respuesta”, sepárelos en uno que evalúe la base fáctica y otro que evalúe la claridad de la comunicación. Además, para escribir las instrucciones del evaluador, establezca el papel del modelo de juez como evaluador de desempeño para evitar confusión entre evaluación y ejecución de tareas. Utilice instrucciones claras y secuenciales con un lenguaje preciso y considere incluir de uno a tres ejemplos relevantes con pares de entrada/salida coincidentes que representen sus estándares esperados. Para la puntuación, elija entre escalas binarias (0/1) para escenarios de aprobación/reprobación o escalas ordinales (como 1 a 5) para evaluaciones más matizadas, y comience con una puntuación binaria cuando no esté seguro. El servicio estandariza la salida para incluir un campo de motivo seguido de un campo de puntuación, de modo que el modelo de juez siempre presenta su razonamiento antes de asignar un número. Evite incluir sus propias instrucciones de formato de salida, ya que pueden confundir el modelo Judge.
Evaluadores basados en código personalizado
Tanto los evaluadores integrados como los personalizados utilizan un LLM como juez. AgentCore Assessments también admite un tercer enfoque: evaluadores basados en código, donde se puede utilizar una función de AWS Lambda como evaluador con su código personalizado.
Los evaluadores basados en código son ideales cuando se tienen métodos de puntuación heurísticos que no requieren comprensión del lenguaje para su verificación. Un evaluador de LLM puede juzgar si una respuesta “suena correcta”, pero no puede confirmar de manera confiable que una cifra específica de recibo de pago de $8,333.33 aparezca palabra por palabra en una respuesta, o que una identificación de solicitud generada siga el formato PTO-2026-NNN. Para estas comprobaciones deterministas, un código personalizado es más rápido, más económico y más confiable. Hay cuatro situaciones en las que los evaluadores basados en códigos son particularmente útiles:
Validación de datos exactos: se espera que el agente devuelva valores específicos de una fuente de datos, como saldos de cuentas, ID de transacciones o precios. Cumplimiento del formato: las respuestas deben cumplir con restricciones estructurales, como límites de longitud, frases requeridas o esquemas de salida. Aplicación de reglas comerciales: políticas que requieren una interpretación precisa, como si una respuesta aplica correctamente una regla de descuento escalonada o cita la cláusula regulatoria correcta. Monitoreo de producción de alto volumen: las invocaciones Lambda cuestan una fracción de la inferencia LLM, lo que hace que los evaluadores basados en código sean la opción correcta cuando cada sesión de producción debe calificarse continuamente a escala.
Crear un evaluador basado en código
Un evaluador basado en código se configura como una función de AWS Lambda con su lógica personalizada. AgentCore pasa los intervalos OTel del agente a su función como un evento estructurado y espera un resultado a cambio. Su función extrae toda la información que necesita de los tramos y devuelve una puntuación, una etiqueta y una explicación.
Una vez que su Lambda esté implementado y se le haya otorgado permiso para que la entidad de servicio AgentCore lo invoque, lo registrará como evaluador de AgentCore. Una vez registrado, el ID del evaluador se puede utilizar para la evaluación bajo demanda.
Configuración de evaluaciones de AgentCore
La configuración del servicio implica tres pasos. Seleccione su agente, elija sus evaluadores y establezca sus reglas de muestreo. Antes de comenzar, implemente su agente usando AgentCore Runtime y configure la observabilidad a través de OpenTelemetry u OpenInference instrumentación. El repositorio de muestras de AgentCore en GitHub proporciona ejemplos prácticos.
Configurar la evaluación en línea
Cree una nueva configuración de evaluación en línea a través de la consola de evaluaciones de AgentCore. Aquí usted especifica qué evaluadores aplicar, qué fuente de datos monitorear y qué parámetros de muestreo usar. Para la fuente de datos, seleccione un punto final de AgentCore Runtime existente o un grupo de registros de CloudWatch para agentes no alojados en AgentCore Runtime. Luego elija a sus evaluadores y defina sus reglas de muestreo.
Figura 8: La consola de AgentCore Evaluaciones para crear una configuración de evaluación en línea, incluida la selección de fuente de datos, la asignación del evaluador y las reglas de muestreo.
También puede crear configuraciones mediante programación utilizando la API CreateOnlineEvaluaciónConfig con un nombre de configuración único, fuente de datos, lista de evaluadores (hasta 10) y función de servicio IAM. El parámetro enableOnCreate controla si la evaluación comienza inmediatamente o permanece en pausa, yexecutionStatus determina si la configuración procesa activamente los seguimientos una vez habilitados. Cuando se ejecuta una configuración, todos los evaluadores personalizados a los que hace referencia se bloquean y no se pueden modificar ni eliminar. Si necesita cambiar un evaluador, clónelo y cree una nueva versión. Los resultados de la evaluación en línea se guardan en un grupo de registros de CloudWatch dedicado en formato JSON.
Resultados del seguimiento
Después de habilitar su configuración, supervise los resultados a través del panel de Observabilidad de AgentCore en Amazon CloudWatch. Las vistas a nivel de agente muestran tendencias y métricas de evaluación agregadas, y puede profundizar en sesiones y seguimientos específicos para ver puntuaciones individuales y el razonamiento detrás de cada una.
Figura 9: El panel de Observabilidad de AgentCore muestra métricas de evaluación y tendencias a nivel de agente, con desglose de sesiones individuales, seguimientos, puntuaciones y razonamiento de los jueces.
Profundizar en un seguimiento individual revela las puntuaciones de evaluación y explicaciones detalladas para esa interacción específica, de modo que los equipos puedan verificar el razonamiento del juez y comprender por qué el agente recibió una calificación particular.
Figura 10: La vista a nivel de seguimiento muestra puntuaciones de evaluación y explicaciones directamente en seguimientos individuales, mostrando el razonamiento del modelo de juez para cada métrica.
Uso de la evaluación bajo demanda
Para el desarrollo y las pruebas, puede utilizar la evaluación bajo demanda para analizar interacciones específicas seleccionando las trazas o tramos que desea examinar, aplicando los evaluadores elegidos y recibiendo puntuaciones detalladas con explicaciones. Los resultados regresan directamente en la respuesta de la API, limitados a 10 evaluaciones por llamada, y cada resultado contiene el contexto, la puntuación y el razonamiento. Si una evaluación falla parcialmente, la respuesta incluye resultados exitosos y fallidos con códigos y mensajes de error. La evaluación bajo demanda funciona bien para probar evaluadores personalizados, investigar problemas de calidad específicos y validar correcciones antes de la implementación.
Evaluación de agentes con verdad sobre el terreno
La puntuación de LLM como juez le indica si las respuestas parecen correctas y útiles según los estándares de un modelo de lenguaje de propósito general. La evaluación de la verdad sobre el terreno va más allá al permitirle especificar la respuesta, las herramientas que deberían haberse convocado y los resultados que la sesión debería haber logrado. Esto le ayuda a medir en qué medida el comportamiento real del agente coincide con sus entradas de referencia. Esto es particularmente valioso durante el desarrollo, cuando tiene conocimiento de dominio sobre cuál es el comportamiento correcto y desea probar escenarios específicos.
AgentCore Assessments admite tres tipos de entradas de referencia reales, cada una consumida por un conjunto específico de evaluadores:
Evaluador de entrada de referencia Qué mide expected_response Builtin.Correctness Similitud entre la respuesta del agente y la respuesta correcta conocida expected_trajectory Builtin.TrajectoryExactOrderMatch, Builtin.TrajectoryInOrderMatch, Builtin.TrajectoryAnyOrderMatch Si el agente llamó a las herramientas correctas en la secuencia correcta afirmaciones Builtin.GoalSuccessRate Si la sesión satisfizo un conjunto de declaraciones en lenguaje natural sobre los resultados esperados
Estas entradas son opcionales e independientes. Los evaluadores que no requieren verdad sobre el terreno, como Builtin.Helpfulness y Builtin.ResponseRelevance, se pueden incluir en la misma llamada que los evaluadores de verdad sobre el terreno, y cada evaluador lee solo los campos que necesita. Puede proporcionar las tres entradas de referencia simultáneamente para una evaluación integral o proporcionar solo el subconjunto relevante para un escenario determinado.
El SDK de Python de bedrock-agentcore proporciona dos interfaces para la evaluación de la verdad fundamental: EvaluaciónClient para evaluar sesiones existentes y OnDemandEvaluaciónRunner para evaluación automatizada de conjuntos de datos.
Cliente de evaluación: evaluación de sesiones existentes
El Cliente de evaluación es la opción correcta cuando ya tiene sesiones de agente registradas en CloudWatch y desea evaluar interacciones específicas. Usted proporciona el ID de la sesión, el ID del agente, los evaluadores elegidos, una ventana retrospectiva para la recuperación del intervalo de CloudWatch y entradas de referencia opcionales. El cliente recupera los intervalos de la sesión y los envía para su evaluación. Esto es muy adecuado para el análisis de desarrollo, la depuración de fallas de agentes específicos y la validación de interacciones conocidas después de cambios de modelo o avisos.
El cliente de evaluación funciona igualmente bien para sesiones de varios turnos. Cuando pasa un ID de sesión de una conversación de varios turnos, el cliente recupera todos los intervalos de esa sesión y evalúa el diálogo completo. Los evaluadores de trayectoria verifican el uso de la herramienta en todos los turnos, las afirmaciones de éxito de objetivos se aplican a la sesión y los evaluadores de corrección califican cada respuesta individual con su correspondiente respuesta esperada.
Ejecutor de conjuntos de datos de evaluación bajo demanda: evaluación automatizada de conjuntos de datos
On-Demand Assessment Dataset Runner es la opción correcta cuando desea evaluar su agente sistemáticamente a través de un conjunto de datos seleccionado invocando al agente para cada escenario, recopilando intervalos de CloudWatch y calificando los resultados en un único flujo de trabajo automatizado. Usted define un conjunto de datos que contiene escenarios de múltiples turnos con verdad básica por turno y por escenario y proporciona una función agent_invoker que el corredor llama para cada turno. El corredor gestiona los ID de sesión y maneja toda la coordinación entre la invocación, la recopilación de intervalos y la evaluación.
On-Demand Assessment Dataset Runner es ideal para canalizaciones de CI/CD donde el mismo conjunto de datos se ejecuta en cada compilación, pruebas de regresión después de cambios de modelo o avisos y evaluación por lotes en un gran corpus de casos de prueba antes de un lanzamiento.
Las dos interfaces comparten los mismos evaluadores y el mismo esquema de entradas de referencia, por lo que puede desarrollar y validar casos de prueba reales de forma interactiva con el cliente de evaluación en comparación con sesiones de producción existentes y luego promover esos mismos escenarios en su conjunto de datos de Evaluación Runner para realizar pruebas de regresión sistemática. El tutorial práctico en el repositorio de ejemplos de AgentCore demuestra ambas interfaces de un extremo a otro utilizando un agente de ejemplo en escenarios de un solo turno y de varios turnos con los tres tipos de entradas de referencia de verdad del terreno.
Mejores prácticas
Los criterios de éxito para su agente generalmente combinan tres dimensiones: la calidad de las respuestas, la latencia con la que los usuarios las reciben y el costo de la inferencia. Las evaluaciones de AgentCore se centran en la dimensión de calidad, mientras que las métricas operativas como la latencia y el costo están disponibles a través de AgentCore Observability en CloudWatch. Las siguientes mejores prácticas están organizadas en torno a los tres principios de evaluación descritos anteriormente y reflejan patrones que surgen al trabajar con la evaluación de agentes a escala.
Desarrollo basado en evidencia
Base el desempeño de su agente con datos sintéticos y del mundo real, y experimente rigurosamente. Mida antes y después de cada cambio para que las mejoras se basen en evidencia, no en intuición. Comience a realizar pruebas temprano con los casos de prueba que tiene y desarrolle su corpus continuamente. El ciclo de evaluación descrito en la Figura 1 garantiza que las fallas se conviertan en nuevos casos de prueba con el tiempo. Ejecute pruebas A/B con rigor estadístico para cada cambio. Ya sea que esté actualizando un mensaje del sistema, intercambiando un modelo o agregando una herramienta, compare el rendimiento en el mismo conjunto de evaluadores antes y después de la implementación. Realice pruebas repetidas (al menos 10 por pregunta) organizadas por categoría para comparar la confiabilidad e identificar oportunidades de especialización. La variación entre ejecuciones repetidas revela dónde su agente es consistente y dónde necesita trabajar.
Evaluación multidimensional
Defina cómo se ve el éxito desde el principio, utilizando criterios multidimensionales que reflejen el propósito real de su agente. Considere qué niveles de evaluación son más importantes (sesión, seguimiento o herramienta) y seleccione evaluadores que se correspondan con sus objetivos comerciales. Evalúe cada paso del flujo de trabajo del agente, no solo los resultados finales. La medición independiente de la selección de herramientas, la precisión de los parámetros y la calidad de la respuesta le brinda la precisión del diagnóstico para solucionar los problemas donde realmente ocurren. Involucre a expertos en la materia en el diseño de sus métricas, la definición de la cobertura de tareas y la realización de revisiones humanas para garantizar la calidad. Las aportaciones de las PYME mantienen a sus evaluadores basados en las expectativas del mundo real y detectan puntos ciegos que la puntuación automatizada por sí sola puede pasar por alto. Comience con evaluadores integrados para establecer mediciones de referencia y luego cree evaluadores personalizados a medida que sus necesidades maduren. Calibre la puntuación personalizada del evaluador con las PYME para que los juicios automatizados se alineen con las expectativas humanas en su dominio.
Medición continua
Detecte desviaciones comparando el comportamiento de producción con sus líneas base de prueba. Configure alarmas de CloudWatch en métricas clave para detectar regresiones antes de que lleguen a un amplio conjunto de usuarios. Recuerde que su conjunto de datos de prueba evoluciona con su agente, sus usuarios y los escenarios adversos que encuentre. Actualícelo periódicamente a medida que surjan casos extremos en la producción y cambien los requisitos.
Solución de problemas de patrones de evaluación comunes
Las relaciones del evaluador descritas anteriormente le ayudan a interpretar las puntuaciones de forma diagnóstica. Los siguientes patrones se describen para escenarios específicos que puede encontrar a medida que escala su aplicación junto con los pasos para resolverlos. Si observa puntuaciones bajas en todos los evaluadores, el problema suele ser fundamental. Comience revisando las puntuaciones de relevancia del contexto para determinar si su agente tiene acceso a la información que necesita. Verifique que el mensaje del sistema de su agente sea claro y esté completo; instrucciones vagas o contradictorias afectan todos los comportamientos posteriores. Verifique que las descripciones de las herramientas expliquen con precisión cuándo y cómo utilizar cada herramienta. Si observa puntuaciones inconsistentes para interacciones similares, generalmente indica problemas de configuración de evaluación en lugar de problemas del agente. Si utiliza evaluadores personalizados, verifique si sus instrucciones son lo suficientemente específicas y si cada nivel de puntuación tiene definiciones claras y distinguibles. Considere reducir el parámetro de temperatura en la configuración del modelo de su evaluador personalizado para producir una puntuación más determinista. Si ve una precisión de selección de herramientas alta pero una tasa de éxito de objetivos baja, su agente selecciona las herramientas adecuadas pero no logra completar los objetivos del usuario. Este patrón sugiere que es posible que necesite herramientas adicionales para manejar ciertas solicitudes de los usuarios, o que su agente tenga dificultades con tareas que requieren múltiples llamadas secuenciales a herramientas. Verifique también las puntuaciones de utilidad; el agente puede utilizar las herramientas correctamente pero explicar mal los resultados. Si las evaluaciones son lentas o fallan debido a la limitación, reduzca su frecuencia de muestreo para evaluar un porcentaje menor de sesiones. Reduzca el número de evaluadores. Para evaluadores personalizados, solicite aumentos de cuota para el modelo elegido o cambie a un modelo con cuotas predeterminadas más altas.
Conclusión
En esta publicación, mostramos cómo Amazon Bedrock AgentCore Assessments ayuda a los equipos a pasar de la depuración reactiva a la gestión de calidad sistemática para los agentes de IA. Como servicio totalmente administrado, maneja los modelos de evaluación, la infraestructura de inferencia y los canales de datos que, de otro modo, los equipos necesitarían crear y mantener para cada agente. Con la evaluación bajo demanda que ancla el flujo de trabajo de desarrollo y la evaluación en línea que proporciona información continua sobre la producción, la calidad se convierte en una propiedad mensurable y mejorable durante todo el ciclo de vida del agente. Las relaciones con los evaluadores y los patrones de diagnóstico brindan un marco no sólo para calificar a los agentes sino también para comprender dónde y por qué ocurren los problemas de calidad y dónde enfocar los esfuerzos de mejora.
Para explorar las evaluaciones de AgentCore en detalle, mire la sesión de lanzamiento de vista previa pública de AWS re:Invent 2025 para ver un recorrido con demostraciones en vivo. Visite el repositorio de muestras de Amazon Bedrock AgentCore en GitHub para obtener tutoriales prácticos. Para obtener detalles técnicos sobre la configuración y el uso de API, consulte la documentación de evaluaciones de AgentCore. También puede revisar los límites y precios del servicio.
Sobre los autores
Akarsha Sehwag
Akarsha Sehwag es científico de datos de IA generativa de WW para el equipo de Amazon Bedrock Agentcore GTM. Con más de siete años de experiencia en el desarrollo de productos de IA/ML, ha creado soluciones empresariales en diversos segmentos de clientes. Fuera del trabajo, le gusta aprender algo nuevo, ser mentora, hablar en conferencias o estar al aire libre en la naturaleza.
Ishan Singh
Ishan Singh es científico aplicado sénior en Amazon Web Services, donde ayuda a los clientes a crear soluciones y productos de IA generativa innovadores y responsables. Con una sólida experiencia en IA/ML, Ishan se especializa en la creación de soluciones de IA generativa que impulsan el valor empresarial. Fuera del trabajo, le gusta jugar voleibol, explorar senderos para bicicletas locales y pasar tiempo con su esposa y su perro, Beau.
Bharathi Srinivasan
Bharathi Srinivasan es científico de datos de IA generativa en AWS. Le apasiona la IA responsable para aumentar la confiabilidad de los agentes de IA en escenarios del mundo real. Bharathi guía a los equipos internos y a los clientes de AWS en su viaje hacia la IA responsable. Ha presentado su trabajo en varias conferencias sobre aprendizaje automático.
Jack Gordley
Jack Gordley contribuyó a las evaluaciones de AgentCore y se centró en ofrecer productos que ayuden a las empresas a monitorear e implementar agentes listos para producción a escala.
Samaneh Aminikhanghahi
Samaneh Aminikhanghahi es científica aplicada en el Centro de innovación de IA generativa de AWS, donde trabaja con clientes de diferentes sectores verticales para acelerar su adopción de la IA generativa. Se especializa en marcos de IA agentes, en la creación de sistemas de evaluación sólidos y en la implementación de prácticas de IA responsables que impulsen resultados comerciales sostenibles.
Osman Santos
Osman Santos es arquitecto sénior de aprendizaje profundo en el Centro de innovación de IA generativa de AWS, donde ayuda a los clientes empresariales a diseñar, construir y escalar soluciones de IA generativa y agente. Se especializa en IA agente, desde casos de uso individuales hasta la habilitación de plataformas en toda la empresa. Fuera del trabajo, Osman disfruta pasar tiempo con su familia, jugar juegos de mesa y ponerse al día con el contenido más reciente de anime y ciencia ficción.