Noticias IA · fuente primaria
AgentCore evalúa agentes de cualquier framework con OpenTelemetry
Edición: Álvaro MaureiraFecha: Fuente: Amazon Web Services
Amazon Web Services documentó cómo AgentCore Evaluations puede puntuar agentes construidos con distintos frameworks a partir de telemetría OpenTelemetry.
La clave es reconstruir cada sesión con spans comparables y comprobar que el contenido de los mensajes también llegue al evaluador.
Capítulo 01
La noticia no es otro framework: es una capa común de evaluación
Amazon Bedrock AgentCore Evaluations permite evaluar agentes construidos con distintos frameworks cuando su telemetría sigue OpenTelemetry. El servicio reconstruye la sesión a partir de spans de invocación, inferencia y herramientas, y aplica evaluadores como GoalSuccessRate, Correctness y Helpfulness. AWS también describe una ruta genérica para instrumentaciones compatibles.
Amazon Web Services publicó una guía sobre Amazon Bedrock AgentCore Evaluations cuyo foco no es lanzar un SDK, sino explicar cómo evaluar agentes construidos con herramientas distintas. La idea central es separar la medición del framework que organiza el bucle. Si la telemetría adopta un contrato reconocible, el servicio puede reconstruir la sesión y pasarla a los evaluadores.
Para un equipo que compara proveedores o cambia de framework, esta diferencia importa. No significa que los frameworks se comporten igual, sino que pueden presentarse ante una superficie común de evaluación. Es una inferencia de la guía: la comparabilidad nace de la instrumentación, no del nombre del SDK.
Capítulo 02
OpenTelemetry convierte trazas en un idioma compartido
OpenTelemetry es un marco de instrumentación neutral que estandariza cómo los sistemas emiten trazas, métricas y logs. Una traza se compone de spans; cada span representa una unidad de trabajo con nombre, marcas de tiempo, atributos tipados y eventos opcionales. La guía explica que los spans viajan por OTLP y que, en un runtime de AgentCore, ADOT los enruta junto con los registros de eventos hacia Amazon CloudWatch.
Un turno puede mezclar llamadas al modelo, herramientas, recuperación, reranking, embeddings, guardrails, memoria y orquestación. Las convenciones GenAI de OpenTelemetry y OpenInference ponen nombres y tipos a esas operaciones. La noticia no exige que cada elemento sea evaluable: parte del valor está en distinguir qué span aporta el dato necesario y cuál sólo agrega contexto.
- Produce spans y eventosAgente
- Transporta telemetríaOTLP
- Recolecta en runtimeADOT
- Conserva la evidenciaCloudWatch
Capítulo 03
Tres señales bastan para reconstruir una sesión
La guía de AWS dice que el servicio necesita tres roles de span para reconstruir lo ocurrido en una sesión y puntuarlo. El span de invocación del agente aporta el prompt del usuario y la respuesta final; el span de inferencia aporta los mensajes enviados al modelo y su respuesta; el span de ejecución de herramienta aporta nombre, parámetros y resultado. Esa división convierte un flujo complejo en piezas que se pueden inspeccionar.
El resto de la traza no desaparece: recuperación, reranking, guardrails y memoria pueden enriquecer el contexto. La sesión se agrupa con session.id y cada trace_id representa un turno. Por eso una puntuación no debería leerse aislada: hay que comprobar secuencia, contenido y pertenencia a la sesión.
- Invoke agentPrompt y respuesta final
- InferenceMensajes y réplica del modelo
- Execute toolNombre, parámetros y resultado
- ContextoRetrieval, memoria o guardrails
Capítulo 04
El prefijo de instrumentación decide la ruta
Frameworks e instrumentaciones pueden registrar los mismos roles con atributos y convenciones de span diferentes. AgentCore Evaluations actúa como puente entre OpenTelemetry GenAI y OpenInference. En lugar de pedir un adaptador para cada SDK, clasifica el span y extrae los valores siguiendo el esquema reconocido.
La cobertura también alcanza implementaciones fuera de la lista de frameworks nombrados. La fuente describe una ruta genérica para scopes bajo opentelemetry.instrumentation.* o openinference.instrumentation.*. Un scope arbitrario como mycompany.agent.tracing no entra automáticamente, aunque sus spans parezcan correctos. El prefijo funciona como una señal explícita de que la instrumentación adopta un esquema documentado.
Capítulo 05
La evaluación deja de depender del SDK
Una vez clasificados los spans y reconstruida la sesión, la fuente describe una evaluación agnóstica al framework: los mismos evaluadores GoalSuccessRate, Correctness, Helpfulness y los jueces LLM personalizados pueden puntuar los frameworks admitidos. Ese es el cambio práctico de la noticia. Un equipo puede conservar una batería de pruebas mientras reemplaza la capa que ejecuta al agente.
La uniformidad del evaluador no garantiza calidad. Dos agentes pueden recibir la misma métrica y producir resultados distintos por sus instrucciones, herramientas, datos o políticas. Lo comparable es el mecanismo de observación y puntuación. Para decidir, la métrica necesita una pregunta fija, una sesión identificable y el contenido que originó la respuesta.
- Trayectoria de herramientasGoalSuccessRate
- Puntuación por turnoCorrectness
- Utilidad de respuestaHelpfulness
- Criterio definido por el equipoCustom judge
Capítulo 06
El requisito invisible es que el contenido llegue
La guía fija una condición que puede perderse cuando sólo se mira el dashboard: la fuente de datos debe contener el contenido de los mensajes, no únicamente los spans. Para agrupar la sesión, session.id debe coincidir con el runtimeSessionId con el que se invocó el agente; en AgentCore runtime ADOT lo inyecta automáticamente. Sin agrupación y contenido, la reconstrucción queda incompleta.
AWS distingue la observabilidad unificada de configuraciones antiguas: los spans pueden llegar a aws/spans mientras los mensajes quedan como eventos correlacionados en el log group del agente. Si se cubre sólo aws/spans, la clasificación puede funcionar, pero un evaluador puede devolver error por falta de contenido. La primera prueba es de datos, no de puntuación.
- Coincide con runtimeSessionIdsession.id
- Input y output están presentesMensajes
- La fuente cubre la configuración usadaLog group
- No quedaron fuera del snapshotEventos
Capítulo 07
Del pipeline a la prueba reproducible
Para una prueba bajo demanda, AWS muestra EvaluationClient.run después de invocar el agente. El equipo puede aportar ReferenceInputs con respuestas esperadas, trayectorias de herramientas y assertions. Esa forma de trabajo encaja con integración y entrega continuas: una ejecución conocida genera una sesión y el pipeline puede fallar si un evaluador cae bajo el umbral definido.
La evaluación online responde otra pregunta. El tráfico real no suele traer respuesta esperada, por lo que la guía limita ese modo a evaluadores que no requieren ground truth. Así se evita comparar una regresión controlada con una señal de producción sin contexto. La prueba reproducible conserva prompt, sesión, configuración y telemetría.
Capítulo 08
Cómo decidir si la instrumentación está lista
La pregunta útil para adoptar este patrón no es qué framework tiene más marketing, sino si la evidencia que produce permite reconstruir y comparar. Una implementación está mejor preparada cuando declara un scope reconocido, conserva session.id, entrega contenido de mensajes y permite separar los turnos por trace_id. Si alguno de esos puntos falla, añadir más evaluadores no repara la observabilidad de base.
Esta regla ordena la migración. Primero se valida que la instrumentación produce los tres roles; después se compara una sesión con ground truth; finalmente se decide si el modo online aporta señal. Es una secuencia derivada de AWS, no una certificación. Disponibilidad, permisos y desempeño deben comprobarse en la cuenta y región propias.
- ScopeRuta de clasificación
- SessionAgrupación consistente
- ContentMensajes disponibles
- Ground truthComparación bajo demanda
Capítulo 09
Veredicto: más comparabilidad, no una garantía automática
La fuente primaria sí respalda un punto concreto: AgentCore Evaluations puede aplicar una superficie de evaluación común a agentes de distintos frameworks cuando la instrumentación entrega las señales que reconoce. Los tres roles de span, el scope y el contenido de los mensajes hacen posible reconstruir una sesión. GoalSuccessRate, Correctness y Helpfulness aparecen como evaluadores que pueden reutilizarse en ese recorrido.
Lo que queda abierto es relevante. La guía no demuestra rendimiento universal, calidad idéntica, disponibilidad regional para cada cuenta ni seguridad automática por usar OpenTelemetry. También recomienda vaciar la telemetría antes de la suspensión del runtime, porque spans o eventos pendientes pueden desaparecer. Para una organización en Chile, conviene medir primero la evidencia propia y después comparar.
- Evaluación agnóstica al frameworkDocumentado
- Spans, scope y mensajesNecesario
- Cuenta, región y desempeñoPendiente
- Evidencia propia antes de adoptarCriterio
Comunidad IA gratuita
Convierte esta noticia en aprendizaje aplicado
Continúa con clases, recursos y una ruta práctica para entender la inteligencia artificial y llevarla a decisiones reales, a tu ritmo y sin costo.
