Evaluar sistemas de agentes de IA es fundamentalmente distinto a evaluar software tradicional. Un agente es no determinista, no acotado y puede usar herramientas para afectar arbitrariamente a otros sistemas. Esto hace que las pruebas unitarias clásicas y los conjuntos de datos «dorados» sean insuficientes para capturar la larga cola de problemas que surgen en producción.
Lori Voss, ex-cofundadora de npm Inc. y actual responsable de experiencia desarrollador en AriseAI, plantea el problema con claridad: los agentes pueden tomar caminos diferentes cada vez que ejecutan una misma tarea. Una misma instrucción puede generar secuencias de llamadas a herramientas completamente distintas según el estado del modelo, el orden de las operaciones o el contexto acumulado. Esto exige un enfoque de evaluación probabilística, no determinista.
El cambio de paradigma es profundo: en lugar de verificar que un agente hace «lo correcto» siempre de la misma manera, debemos evaluar si el resultado final es correcto y si el agente fue eficiente y seguro en el proceso. Esto implica medir no solo la precisión de la salida, sino también la calidad de las decisiones intermedias.
Las evaluaciones de agentes se estructuran en dos grandes categorías de señales: explícitas e implícitas. Las señales explícitas son métricas objetivas y verificables: tasa de error, latencia, coste por tarea, tasa de regeneración, tiempo medio de finalización. Estas son fáciles de medir y comparar, pero no capturan la calidad semántica del trabajo del agente.
Las señales implícitas son más difíciles de detectar pero ofrecen información más valiosa. Incluyen patrones de regex, clasificadores binarios y autodiagnósticos. Las señales implícitas más efectivas no son valoraciones genéricas tipo «LLM-as-a-judge», sino clasificadores binarios específicos para problemas concretos: rechazos (el agente se niega a actuar), fallo de tarea, frustración del usuario, jailbreaking, brechas de capacidad.
Nicholas Kang (Mozilla) introduce el concepto de evaluaciones agentic a escala: en lugar de depender de conjuntos de datos estáticos, propone usar entornos simulados (como Game Arena, OpenSpiel) donde los agentes compiten o colaboran, generando métricas de rendimiento relativo. Evalúa a los agentes no contra un estándar absoluto, sino contra otros agentes en condiciones comparables.
Una técnica poderosa y de bajo esfuerzo son los autodiagnósticos: añadir una herramienta «report» al conjunto del agente e indicarle en el prompt del sistema que informe de incidencias a sus creadores. Esto permite detectar brechas de capacidad, fallos de herramientas y atajos no deseados (por ejemplo, un agente que evita una herramienta de escritura rota usando bash).
El problema del «modelo pulido»: los modelos están entrenados para ser educados y a menudo se resisten a autoinculparse. Para que los autodiagnósticos funcionen, la herramienta debe presentarse de forma neutral (p. ej., «report» o «feedback al creador») en lugar de negativa (p. ej., «comportamiento inseguro»). El prompt del sistema debe animar a informar de «cualquier cosa destacable», no solo de «fallos».
Los experimentos A/B en producción son el flujo de trabajo central una vez que se establecen las señales. Al enviar un cambio (un nuevo prompt, un modelo diferente) a un porcentaje de usuarios y comparar las tasas de señal (como frustración del usuario) contra un grupo de control, los equipos pueden validar mejoras o detectar regresiones en condiciones reales de forma rápida.
El argumento central de las charlas de Lori Voss y Nicholas Kang es que el paradigma debe desplazarse de depender de «conjuntos de datos dorados» y evaluaciones offline a una monitorización continua en producción. A medida que los agentes se vuelven más complejos y las apuestas más altas, las evaluaciones predefinidas no pueden cubrir todos los comportamientos emergentes.
La monitorización permite a los equipos moverse más rápido y detectar comportamientos indefinidos y emergentes que las evaluaciones no pueden cubrir. En producción, los agentes interactúan con usuarios reales, sistemas reales y datos reales, generando patrones de fallo imposibles de anticipar en laboratorio.
Una métrica especialmente útil es la tasa de regeneración (regeneration rate): con qué frecuencia el usuario o el propio agente solicita regenerar una respuesta. Una tasa alta indica problemas de calidad no capturados por otras métricas. Combinada con la tasa de abandono (el usuario cierra la sesión tras una interacción fallida), ofrece una imagen clara de la salud del agente.
El ecosistema de evaluación de agentes incluye plataformas especializadas. Arise Phoenix (la plataforma de AriseAI) ofrece evaluación y observabilidad integradas para agentes. Bench Pro proporciona benchmarks estandarizados para comparar agentes. Brave Trust y DeepMind contribuyen con marcos de evaluación para entornos de investigación.
La recomendación práctica es empezar con evaluaciones simples (tasa de éxito en tareas de prueba, latencia media) e ir añadiendo capas de complejidad: autodiagnósticos, experimentos A/B, señales implícitas. La clave no es construir el sistema de evaluación perfecto desde el día uno, sino establecer un bucle de retroalimentación que mejore continuamente.
- Lori Voss, AriseAI — *»Ship Real Agents: Hands-On Evals for Agentic Applications»* (AI Engineer). Duración: 2:04:18. URL: https://youtu.be/Xfl50508LZM
- Nicholas Kang, Mozilla — *»Agentic Evaluations at Scale, For Everybody»* (AI Engineer). Duración: 20:02. URL: https://youtu.be/Ubwb6NzegyA
Atribución: Este artículo adapta material de las charlas de Lori Voss (AriseAI) y Nicholas Kang (Mozilla) en el canal AI Engineer.
Deja una respuesta