AWS lanza UAEF: un único conjunto de 36 métricas para agentes en cualquier framework

Has construido un agente en LangGraph, funciona y las métricas están configuradas. Entonces el equipo decide pasarse a Strands o trasladar parte de la lógica a AgentCore, y resulta que el scoring, el almacenamiento de resultados y los informes están pensados para el formato de trazas del framework anterior. Hay que reconstruir la evaluación desde cero, y la sencilla pregunta «¿mejoró el agente tras cambiar el prompt?» se queda sin respuesta.

AWS propone romper este acoplamiento. UAEF (Universal Agent Evaluation Framework) es un proyecto abierto con licencia Apache 2.0 (repositorio awslabs/uaef). Separa «cómo registró el framework la ejecución del agente» de «cómo evaluamos la calidad». Según AWS, ya lo han usado 12 organizaciones de telecomunicaciones, sanidad y finanzas.

Cómo funciona

La entrada son dos elementos: un agente y un dataset. El dataset contiene consultas y, opcionalmente, respuestas de referencia. Para verificar las llamadas a herramientas, la referencia debe incluir también las llamadas esperadas: qué herramientas, en qué orden y con qué argumentos.

Después, el pipeline funciona así:

1. Un adaptador lee la traza de ejecución nativa (mensajes, llamadas a herramientas, traspasos entre agentes) y la convierte al formato unificado AgentTrace. Se puede aportar una traza ya preparada, de logs o de Langfuse. O bien UAEF invoca por sí mismo al agente mediante ARN o endpoint HTTP con cada entrada del dataset.
2. Antes de guardarla, se comprueba que la traza no contenga datos personales (correos, teléfonos, números de tarjeta).
3. El motor calcula las métricas. Son 36, distribuidas en 7 dimensiones: llamadas a herramientas, calidad de la respuesta, IA responsable, rendimiento, diálogo de varios turnos, coordinación de varios agentes y razonamiento.
4. El resultado se registra como un experimento: metadatos en DynamoDB y resultados completos, junto con las justificaciones del juez, en S3.

La idea principal está en el orden de las operaciones: primero normalización, luego evaluación. Por eso se puede comparar con justicia un agente de un framework con uno de otro en una misma escala. Cada métrica devuelve un número de 0 a 1, donde 1 es el mejor valor.

Métricas deterministas y LLM como juez

Hay dos tipos de métricas. Las deterministas se calculan directamente a partir de la traza y la referencia y son reproducibles exactamente. El resto funciona mediante LLM-as-a-judge: un modelo en Amazon Bedrock evalúa lo que es difícil de formalizar, como la relevancia o la seguridad. Se pueden añadir métricas propias e integrar RAGAS y DeepEval.

Los autores describen por separado la protección del juez. La respuesta del agente entra en el prompt del juez, de modo que es una entrada no confiable. De lo contrario, un agente capaz de influir en el juez podría influir en sus propias puntuaciones. Los criterios se envían por separado del contenido, el contenido se escapa y el juez debe citar literalmente un fragmento del texto evaluado. Si la cita no aparece en el texto, la puntuación se descarta. Aun así, AWS advierte con franqueza que las puntuaciones del juez son una señal para el desarrollo, no un mecanismo de seguridad. Para la protección en tiempo de ejecución hacen falta Bedrock Guardrails.

Comparación de versiones y regresiones

Esta es la parte más práctica. Para cada métrica común a dos ejecuciones, UAEF calcula el cambio absoluto y porcentual y la marca como regresión, mejora o sin cambios. El umbral por defecto es del 5%. La gravedad de la regresión se divide en tres niveles: leve (5–10%), moderada (10–20%) y grave (más del 20%). Las regresiones se agrupan por dimensiones.

Imaginemos que has retocado el prompt del sistema. La comparación puede mostrar que la calidad de la respuesta no cambió, pero la precisión en la elección de herramientas cayó un 12%, es decir, una regresión moderada. Sin el desglose por dimensiones solo verías la puntuación media, que apenas se movió.

A la ejecución se le puede asociar una configuración: framework, modelo, herramientas, prompt, parámetros e incluso el commit de Git. Una ejecución puede designarse como base. Así, cada puntuación queda vinculada al cambio que la originó.

Los informes funcionan en tres niveles: resumen de resultados en la interfaz web, informe estadístico e insights con LLM. El informe estadístico se calcula solo a partir de las puntuaciones, sin LLM, con intervalos de confianza y valores atípicos, por lo que con los mismos datos siempre es idéntico. Los insights, es decir, hipótesis sobre las causas y prioridades de corrección, los genera un modelo en Bedrock mediante la biblioteca de Python.

Qué hacer con ello

Primero: no actives las 36 métricas sin más. En su playbook, AWS aconseja partir del escenario de uso. Un asistente RAG necesita relevancia, precisión y faithfulness de RAGAS, y un agente con herramientas, la selección y el orden de las llamadas y la calidad de los parámetros. Las métricas de más cuestan tiempo y llamadas a Bedrock.

Segundo: UAEF se puede integrar en CI/CD mediante la biblioteca de Python, y para los compañeros menos técnicos hay un servicio desplegable con interfaz low-code. El motor es el mismo en ambos casos.

Las limitaciones también son evidentes. La herramienta está muy ligada a AWS: el juez funciona en Bedrock y el almacenamiento es DynamoDB y S3. Un umbral del 5% en un dataset pequeño se confunde fácilmente con ruido, así que fíjate en los intervalos de confianza del informe. Y no confundas la evaluación de calidad con la protección: para la seguridad se necesitan barreras de protección aparte.

Para los equipos que ejecutan agentes en varios frameworks o piensan migrar, es una base lista para las pruebas de regresión de agentes que, de otro modo, habría que escribir uno mismo.