Si ya trabajaste con agentes de IA, sabés que ese momento de alivio después de un demo exitoso puede durar muy poco.
El agente impresionó a todos en las pruebas, pasó por todos los escenarios simulados y parecía listo para el mundo real.
Después llegó producción, y la historia cambió por completo. 😅
Usuarios reales encontraron llamadas a herramientas incorrectas, respuestas inconsistentes y fallas que nadie había imaginado durante el desarrollo.
Esa brecha entre el comportamiento esperado y la experiencia del usuario real es uno de los mayores desafíos para quienes trabajan con modelos de lenguaje hoy en día.
Y el problema tiene una raíz bien específica: los LLMs son no determinísticos.
Esto significa que la misma consulta de un usuario puede generar selecciones de herramientas diferentes, caminos de razonamiento distintos y outputs completamente variables dependiendo de la ejecución. Una única prueba exitosa muestra lo que puede pasar, no lo que típicamente pasa. Sin una medición sistemática de estas variaciones, los equipos quedan atrapados en ciclos de pruebas manuales y debugging reactivo, quemando costos de API sin saber con certeza si los cambios están realmente mejorando el agente.
Fue exactamente para resolver esto que AWS desarrolló Amazon Bedrock AgentCore Evaluations, un servicio totalmente gestionado enfocado en la evaluación de rendimiento de agentes a lo largo de todo el ciclo de vida, desde el desarrollo hasta producción.
En este artículo vas a entender cómo funciona este servicio en la práctica, qué enfoques usa para medir la calidad de tus agentes y cómo puede transformar la forma en que los equipos de IA toman decisiones basadas en datos reales, no en suposiciones. 🚀
Por qué la evaluación de agentes de IA exige un enfoque completamente nuevo
Antes de hablar sobre la solución, vale la pena entender mejor el problema. Cuando un usuario envía una solicitud a un agente, múltiples decisiones ocurren en secuencia. El agente determina qué herramientas llamar, ejecuta esas llamadas y genera una respuesta basada en los resultados. Cada etapa introduce puntos potenciales de falla: seleccionar la herramienta equivocada, llamar a la herramienta correcta con parámetros incorrectos o sintetizar los outputs de las herramientas en una respuesta final imprecisa.
A diferencia de aplicaciones tradicionales, donde se testea la salida de una única función, la evaluación de agentes requiere medir la calidad a lo largo de todo ese flujo de interacción. Esto crea desafíos específicos para desarrolladores de agentes que pueden enfrentarse de la siguiente forma:
- Definir criterios de evaluación sobre qué constituye una selección correcta de herramienta, parámetros válidos, una respuesta precisa y una experiencia útil para el usuario.
- Construir datasets de prueba que representen solicitudes reales de usuarios y comportamientos esperados.
- Elegir métodos de puntuación que logren evaluar calidad de forma consistente a lo largo de ejecuciones repetidas.
Cada una de estas definiciones determina directamente lo que el sistema de evaluación mide, y equivocarse en ellas significa optimizar para los resultados equivocados. Sin este trabajo fundamental, la brecha entre lo que los equipos esperan que sus agentes hagan y lo que pueden demostrar que hacen se convierte en un riesgo real de negocio.
Cerrar esa brecha exige un ciclo continuo de evaluación. Los equipos construyen casos de prueba, los ejecutan contra el agente, puntúan los resultados, analizan fallas e implementan mejoras. Cada falla se convierte en un nuevo caso de prueba, y el ciclo continúa con cada iteración del agente. Sin embargo, ejecutar este ciclo de punta a punta requiere infraestructura significativa más allá de la lógica de evaluación en sí. Los equipos necesitan curar datasets, seleccionar y alojar modelos de puntuación, gestionar capacidad de inferencia y límites de API, construir pipelines de datos que transformen traces del agente en formatos listos para evaluación y crear dashboards para visualizar tendencias.
Para organizaciones que ejecutan múltiples agentes, ese overhead se multiplica con cada uno. El resultado es que los equipos terminan gastando más tiempo manteniendo herramientas de evaluación que actuando en base a lo que ellas informan. Este es exactamente el problema que Amazon Bedrock AgentCore Evaluations fue construido para resolver.
Qué es Amazon Bedrock AgentCore Evaluations
Lanzado inicialmente en preview público en el AWS re:Invent 2025, el servicio ahora está disponible de forma general. Gestiona los modelos de evaluación, infraestructura de inferencia, pipelines de datos y escalabilidad para que los equipos puedan enfocarse en mejorar la calidad de los agentes en lugar de construir y mantener sistemas de evaluación. Para evaluadores built-in, la cuota de modelo y capacidad de inferencia están totalmente gestionadas. Esto significa que organizaciones evaluando muchos agentes no están consumiendo sus propias cuotas ni aprovisionando infraestructura separada para workloads de evaluación.
AgentCore Evaluations examina el comportamiento del agente de punta a punta usando traces OpenTelemetry (OTEL) con convenciones semánticas de IA generativa. OTEL es un estándar open source de observabilidad para recolectar traces distribuidos de aplicaciones. Las convenciones semánticas de IA generativa extienden ese estándar con campos específicos para interacciones con modelos de lenguaje, incluyendo prompts, completions, llamadas a herramientas y parámetros de modelo. Al estar construido sobre este estándar, el servicio funciona de forma consistente con agentes construidos con cualquier framework, como Strands Agents o LangGraph, instrumentados con OpenTelemetry y OpenInference.
Las evaluaciones pueden configurarse con diferentes enfoques:
- LLM-as-a-Judge — donde un LLM evalúa cada interacción del agente contra rúbricas estructuradas con criterios claramente definidos.
- Evaluación basada en Ground Truth — que compara las respuestas del agente contra datasets predefinidos o simulados.
- Evaluadores de código customizado — donde podés traer una función Lambda como evaluador con tu propio código.
En el enfoque LLM-as-a-Judge, el modelo juez examina todo el contexto de la interacción, incluyendo historial de conversación, herramientas disponibles, herramientas utilizadas, parámetros pasados e instrucciones del sistema, y proporciona razonamiento detallado antes de asignar una puntuación. Cada puntuación viene con una explicación. Los equipos pueden usar estas puntuaciones para verificar juicios, entender exactamente por qué una interacción recibió una clasificación específica e identificar qué debería haber ocurrido de manera diferente.
Tres principios guían el enfoque del servicio para evaluación:
- Desarrollo orientado por evidencias — sustituye la intuición por métricas cuantitativas, para que los equipos puedan medir el impacto real de los cambios.
- Evaluación multidimensional — evalúa diferentes aspectos del comportamiento del agente de forma independiente, haciendo posible identificar exactamente dónde se necesitan mejoras.
- Medición continua — conecta las líneas base de rendimiento establecidas durante el desarrollo directamente al monitoreo en producción.
Evaluación a lo largo del ciclo de vida del agente
El camino de un agente desde el prototipo hasta producción crea dos necesidades distintas de evaluación. Durante el desarrollo, los equipos necesitan ambientes controlados donde puedan comparar alternativas, probar el agente en datasets curados, reproducir resultados y validar cambios antes de que lleguen a los usuarios. Una vez que el agente está en vivo, el desafío cambia a monitorear interacciones del mundo real en escala, donde los usuarios encuentran edge cases y patrones de interacción que ninguna cantidad de pruebas pre-deploy logró anticipar.
AgentCore Evaluations mapea dos enfoques complementarios para estas fases del ciclo de vida:
Evaluación online para monitoreo en producción
La evaluación online monitorea interacciones en vivo del agente mediante muestreo continuo de un porcentaje configurable de traces, puntuándolos contra los evaluadores elegidos. Definís qué evaluadores aplicar, configurás reglas de muestreo que controlan qué fracción del tráfico de producción se evalúa y definís filtros apropiados. El servicio se encarga de leer los traces, ejecutar las evaluaciones y presentar los resultados en el dashboard de Observabilidad de AgentCore, alimentado por Amazon CloudWatch.
Si ya estás recolectando traces para observabilidad, la evaluación online agrega puntuaciones de calidad con explicación junto a tus métricas operacionales existentes, sin exigir cambios de código o re-deploys.
Los problemas de calidad en producción frecuentemente aparecen de formas que el monitoreo tradicional no captura. Los dashboards operacionales pueden mostrar todo verde en latencia y tasas de error mientras la experiencia del usuario se degrada silenciosamente porque el agente empieza a seleccionar herramientas incorrectas o proporcionar respuestas menos útiles. La puntuación continua de calidad captura estas fallas silenciosas al rastrear métricas de evaluación junto con las métricas operacionales. Como la observabilidad de AgentCore corre en CloudWatch, podés crear dashboards customizados y configurar alarmas para ser alertado en el momento en que las puntuaciones caigan por debajo de tus umbrales.
Evaluación bajo demanda para desarrollo
La evaluación bajo demanda es una API en tiempo real diseñada para workflows de desarrollo y CI/CD. Los equipos la usan para probar cambios antes del deploy, ejecutar suites de evaluación como parte de pipelines CI/CD, hacer pruebas de regresión entre builds y bloquear deploys basándose en umbrales de calidad.
Los desarrolladores seleccionan una sesión completa y especifican spans exactos o traces proporcionando sus IDs. El servicio considera la conversación completa de la sesión y puntúa spans y traces individuales contra los mismos evaluadores usados en producción. Casos de uso comunes incluyen validar cambios de prompt, comparar performance de modelos entre alternativas y prevenir regresiones de calidad.
Como ambos modos usan los mismos evaluadores, lo que probás en CI/CD es lo que monitoreás en producción, garantizando estándares de calidad consistentes a lo largo de todo el ciclo de desarrollo. Juntos, los dos modos forman un loop continuo de feedback entre desarrollo y producción.
Cómo AgentCore evalúa tu agente
AgentCore Evaluations organiza las interacciones del agente en una jerarquía de tres niveles que determina qué puede evaluarse y con qué granularidad:
- Sesión — representa una conversación completa entre un usuario y el agente, agrupando todas las interacciones relacionadas de un único usuario o workflow.
- Trace — captura todo lo que ocurre durante un único intercambio. Cuando un usuario envía un mensaje y recibe una respuesta, ese round trip produce un trace conteniendo cada paso que el agente tomó para generar su respuesta.
- Span — representa acciones individuales específicas que el agente realizó, como invocar una herramienta, recuperar información de una base de conocimiento o generar texto.
El servicio ofrece 13 evaluadores built-in preconfigurados organizados en estos tres niveles, cada uno midiendo un aspecto distinto del comportamiento del agente:
Nivel de sesión
Goal Success Rate — evalúa si todos los objetivos del usuario fueron completados dentro de una conversación.
Nivel de trace
Incluye evaluadores como Helpfulness, Correctness, Coherence, Conciseness, Faithfulness, Harmfulness, Instruction Following, Response Relevance, Context Relevance, Refusal y Stereotyping. Estos evaluadores miden calidad de respuesta, precisión, seguridad y eficacia de comunicación.
Nivel de herramienta
Tool Selection Accuracy y Tool Parameter Accuracy — evalúan las decisiones de selección de herramienta y la precisión en la extracción de parámetros.
Entendiendo las distinciones entre evaluadores
Algunos evaluadores interactúan naturalmente entre sí, así que las puntuaciones deben leerse juntas en lugar de aisladamente. Evaluadores que suenan similares frecuentemente miden cosas fundamentalmente diferentes:
- Correctness verifica si la respuesta es factualmente precisa, mientras que Faithfulness verifica si es consistente con el historial de la conversación. Un agente puede ser fiel a un material fuente incorrecto y aun así estar equivocado.
- Helpfulness pregunta si la respuesta avanza al usuario hacia su objetivo, mientras que Response Relevance pregunta si responde lo que originalmente se preguntó. Un agente puede responder la pregunta equivocada de forma completa.
- Coherence chequea contradicciones internas en el razonamiento, mientras que Context Relevance chequea si el agente tenía la información correcta disponible. Uno revela un problema de generación, el otro un problema de recuperación.
Algunas dependencias también son importantes: Tool Parameter Accuracy solo tiene sentido cuando el agente seleccionó la herramienta correcta, así que una baja Tool Selection Accuracy debe resolverse primero. Correctness frecuentemente depende de Context Relevance porque un agente no puede generar respuestas precisas sin la información correcta. Y Conciseness y Helpfulness muchas veces entran en conflicto porque respuestas breves pueden omitir contexto que los usuarios necesitan.
Evaluadores customizados y basados en código
Además de los evaluadores built-in, el servicio soporta evaluadores customizados usando LLM-as-a-Judge con tus propios modelos, instrucciones, criterios y esquemas de puntuación. Son particularmente valiosos para evaluaciones específicas de industria, como verificación de cumplimiento en salud o servicios financieros, consistencia de voz de marca o cumplimiento de estándares de calidad organizacionales.
Los evaluadores basados en código permiten traer una función AWS Lambda para realizar las evaluaciones. Este tipo de evaluador es ideal cuando tenés métodos de puntuación heurísticos que no requieren comprensión de lenguaje para verificar. Un evaluador LLM puede juzgar si una respuesta suena correcta, pero no puede confirmar de forma confiable que un valor específico de recibo de sueldo aparece literalmente en la respuesta, o que un ID de solicitud sigue un formato específico. Para estas verificaciones determinísticas, código customizado es más rápido, más barato y más confiable.
Cuatro situaciones donde los evaluadores basados en código son especialmente útiles:
- Validación exacta de datos — cuando el agente debe retornar valores específicos de una fuente de datos, como saldos, IDs de transacción o precios.
- Conformidad de formato — cuando las respuestas deben seguir restricciones estructurales, como límites de tamaño, frases obligatorias o schemas de salida.
- Cumplimiento de reglas de negocio — políticas que exigen interpretación precisa, como aplicación correcta de reglas de descuento o cita de la cláusula regulatoria adecuada.
- Monitoreo de producción en alto volumen — las invocaciones Lambda cuestan una fracción de la inferencia LLM, haciendo que los evaluadores basados en código sean la opción correcta cuando toda sesión de producción necesita ser puntuada continuamente en escala.
Evaluando agentes con Ground Truth
La puntuación vía LLM-as-a-Judge dice si las respuestas parecen correctas y útiles según los estándares de un modelo de lenguaje de propósito general. La evaluación con Ground Truth va más allá, permitiéndote especificar la respuesta esperada, las herramientas que deberían haberse llamado y los resultados que la sesión debería haber alcanzado.
AgentCore Evaluations soporta tres tipos de inputs de referencia Ground Truth, cada uno consumido por un conjunto específico de evaluadores:
- expected_response — usado por el evaluador Builtin.Correctness para medir similitud entre la respuesta del agente y la respuesta correcta conocida.
- expected_trajectory — usado por los evaluadores de correspondencia de trayectoria para verificar si el agente llamó a las herramientas correctas en la secuencia correcta.
- assertions — usado por Builtin.GoalSuccessRate para verificar si la sesión satisfizo un conjunto de declaraciones en lenguaje natural sobre resultados esperados.
Estos inputs son opcionales e independientes. Evaluadores que no requieren Ground Truth, como Builtin.Helpfulness y Builtin.ResponseRelevance, pueden incluirse en la misma llamada que evaluadores de Ground Truth, y cada evaluador lee solamente los campos que necesita.
Buenas prácticas para evaluación de agentes
Los criterios de éxito para tu agente típicamente combinan tres dimensiones: la calidad de las respuestas, la latencia con que los usuarios las reciben y el costo de inferencia. AgentCore Evaluations se enfoca en la dimensión de calidad, mientras que métricas operacionales como latencia y costo están disponibles a través de la Observabilidad de AgentCore en CloudWatch.
Desarrollo orientado por evidencias
- Establecé una baseline del rendimiento de tu agente con datos sintéticos y del mundo real. Medí antes y después de cada cambio para que las mejoras estén basadas en evidencias, no en intuición.
- Ejecutá pruebas A/B con rigor estadístico para cada cambio. Ya sea actualizando un prompt del sistema, cambiando un modelo o agregando una herramienta, compará performance usando el mismo conjunto de evaluadores antes y después del deploy.
- Ejecutá pruebas repetidas — al menos 10 por pregunta — organizadas por categoría para medir confiabilidad. La variación entre ejecuciones repetidas revela dónde tu agente es consistente y dónde necesita trabajo.
Evaluación multidimensional
- Definí cómo se ve el éxito desde temprano, usando criterios multidimensionales que reflejen el propósito real del agente.
- Evaluá cada paso en el workflow del agente, no solo los resultados finales. Medir selección de herramienta, precisión de parámetros y calidad de respuesta de forma independiente da la precisión diagnóstica para corregir problemas donde realmente ocurren.
- Involucrá a expertos en la materia en el diseño de tus métricas y en la definición de cobertura de tareas. El input de expertos mantiene tus evaluadores anclados en expectativas del mundo real y captura puntos ciegos que la puntuación automatizada sola puede no percibir.
- Empezá con evaluadores built-in para establecer mediciones de baseline, después creá evaluadores customizados conforme tus necesidades maduren.
Medición continua
- Detectá drift comparando el comportamiento en producción con tus baselines de prueba. Configurá alarmas en CloudWatch en métricas clave para capturar regresiones antes de que alcancen una base amplia de usuarios.
- Recordá que tu dataset de prueba evoluciona con el agente, tus usuarios y los escenarios adversarios que encontrás. Actualizalo regularmente conforme edge cases emergen en producción y los requisitos cambian.
Diagnosticando patrones comunes de evaluación
Entender cómo interpretar los resultados de evaluación es tan importante como configurar el servicio. Acá van algunos patrones específicos que podés encontrar conforme escalás tu aplicación:
- Puntuaciones bajas en todos los evaluadores — el problema típicamente es fundamental. Empezá revisando puntuaciones de Context Relevance para determinar si el agente tiene acceso a la información que necesita. Verificá el prompt del sistema en cuanto a claridad y completitud.
- Puntuaciones inconsistentes para interacciones similares — generalmente apunta a problemas de configuración de evaluación en lugar de problemas del agente. Si estás usando evaluadores customizados, verificá si tus instrucciones son lo suficientemente específicas y si cada nivel de puntuación tiene definiciones claras y distinguibles.
- Alta Tool Selection Accuracy pero bajo Goal Success Rate — el agente selecciona herramientas apropiadas pero falla en completar los objetivos del usuario. Este patrón sugiere que puede ser necesario agregar herramientas para manejar ciertas solicitudes, o que el agente tiene dificultades con tareas que requieren múltiples llamadas secuenciales de herramientas.
- Evaluaciones lentas o fallando por throttling — reducí tu tasa de muestreo para evaluar un porcentaje menor de sesiones. Reducí la cantidad de evaluadores. Para evaluadores customizados, solicitá aumentos de cuota o cambiá a un modelo con cuotas estándar más altas.
El impacto real para equipos que trabajan con IA
Para equipos que están escalando el uso de agentes de IA dentro de sus organizaciones, el mayor beneficio de Amazon Bedrock AgentCore Evaluations no es solo tecnológico, es cultural. Tener una infraestructura de evaluación confiable cambia la forma en que el equipo toma decisiones. En lugar de depender de la intuición de quien desarrolló el agente o de feedbacks esporádicos de usuarios, las decisiones pasan a estar guiadas por métricas objetivas que todos pueden acompañar y discutir. Esto reduce conflictos internos, acelera el ciclo de iteración y aumenta la confianza del equipo en los cambios que está haciendo.
Desde el punto de vista de negocio, la evaluación de rendimiento continua también ayuda a justificar inversiones en modelos de lenguaje más avanzados o en mejoras en la arquitectura del agente. Cuando podés mostrar con datos que un cambio específico aumentó la precisión de las respuestas o redujo el número de llamadas a herramientas incorrectas, se vuelve mucho más fácil conseguir aprobación para seguir evolucionando el producto. Esto es especialmente relevante en ambientes corporativos donde la adopción de IA todavía enfrenta escepticismo y donde resultados concretos hacen toda la diferencia.
Con evaluación bajo demanda anclando el workflow de desarrollo y evaluación online proporcionando visibilidad continua en producción, la calidad se convierte en una propiedad medible y mejorable a lo largo de todo el ciclo de vida del agente. Las relaciones entre evaluadores y los patrones diagnósticos ofrecen un framework no solo para puntuar agentes, sino para entender dónde y por qué ocurren problemas de calidad y dónde concentrar los esfuerzos de mejora.
Al final del día, es la experiencia del usuario la que determina el éxito o el fracaso de cualquier agente de IA en producción. De nada sirve tener el modelo más sofisticado del mercado si no puede responder a las preguntas reales de tus usuarios de forma consistente y confiable. AgentCore Evaluations existe exactamente para garantizar que ese estándar de calidad sea medible, rastreable y continuamente mejorado, transformando el desarrollo de agentes de un arte basado en intuición a una disciplina basada en evidencias. 💡
