12 Métricas de Fiabilidad de Agentes

Qué Mide

Si el agente tiene éxito o falla consistentemente en intentos repetidos de la misma tarea. Un agente de reclamos de seguros que aprueba un reclamo en una ejecución pero niega el reclamo idéntico en la siguiente crea responsabilidad legal y destruye la confianza del usuario, independientemente de la precisión promedio.

Señales de Falla

• La misma entrada produce éxito un día y falla al siguiente
• Las demos funcionan; producción no. O viceversa.
• "Funcionaba cuando lo probé" es una respuesta común de soporte
• Las tasas de error se disparan en lotes de tareas idénticas ejecutadas en diferentes momentos

Cómo Evaluar

Ejecuta K tareas idénticas múltiples veces. Mide pass∧k (éxito en TODAS las K ejecuciones) en lugar de pass@k (éxito en al menos una ejecución). Normaliza la varianza por p(1−p) para aislar consistencia del nivel de capacidad.

Fallas Comunes

• Reportar pass@k como métrica de fiabilidad: mide capacidad del mejor caso, no consistencia
• Probar con una ejecución y declarar el sistema "validado"
• Tratar la varianza de resultados como "estocasticidad del modelo aceptable"

Qué Mide

Si el agente usa tipos y frecuencias similares de acciones a través de ejecuciones repetidas, incluso cuando llega a la misma conclusión. ¿Siempre busca antes de escribir? ¿Siempre verifica antes de ejecutar? La distribución de tipos de acción debería ser estable a través de las ejecuciones.

Señales de Falla

• El agente a veces lee archivos antes de escribir, a veces escribe directamente
• Los registros de auditoría se ven completamente diferentes para tareas idénticas
• Los conteos de llamadas a herramientas fluctúan salvajemente a través de ejecuciones del mismo flujo
• Los equipos de cumplimiento no pueden generar rastros de auditoría reproducibles

Cómo Evaluar

Compara distribuciones de frecuencia de tipos de acción a través de K ejecuciones usando medidas de similitud distribucional. Marca alta varianza en "lo que hace el agente" incluso cuando los resultados finales coinciden. Los procesos de auditoría requieren distribuciones de acción estables.

Fallas Comunes

• Medir solo resultados finales mientras ignora consistencia de comportamiento
• Asumir que "mismo resultado" significa "mismo comportamiento"
• Construir marcos de cumplimiento solo en auditoría de resultados

Qué Mide

Si el agente sigue ordenamientos de acción consistentes a través de las ejecuciones. Incluso cuando los tipos de acción son similares, ¿a veces cobra una tarjeta antes de verificar inventario? ¿Verifica identidad después de tomar acción? Las inconsistencias de ordenamiento crean modos de falla invisibles a la evaluación solo de resultados.

Señales de Falla

• Las fallas de "estado interrumpido" son impredecibles y difíciles de recuperar
• La misma tarea crea diferentes estados intermedios a través de ejecuciones
• Los procedimientos de recuperación funcionan a veces pero no consistentemente
• Los mecanismos de rollback fallan porque se violaron los supuestos de estado

Cómo Evaluar

Compara secuencias de acción usando medidas de similitud de secuencia (ej. distancia de edición en trazas de acción). Define invariantes de ordenamiento para procesos críticos (pasos que siempre deben preceder a otros) y verifica que se mantengan a través de K ejecuciones.

Fallas Comunes

• Asumir que el ordenamiento de acciones es irrelevante si el resultado final es correcto
• Saltarse el análisis de flujo de trabajo en favor de solo verificación de estado final
• No definir o probar invariantes de ordenamiento para procesos de alto riesgo

Qué Mide

Si el costo computacional, latencia y consumo de tokens API del agente son predecibles a través de tareas idénticas. Un agente que cuesta $0.02 por tarea el lunes y $2.00 el viernes no puede operarse de manera segura a escala, incluso con precisión idéntica.

Señales de Falla

• La latencia P99 es 10× la mediana sin razón aparente
• Los costos API mensuales varían 200% para la misma carga de trabajo
• La duración de tareas fluctúa de 3 segundos a 3 minutos impredeciblemente
• Ocurren sobrecostos presupuestarios en tareas rutinarias repetidas

Cómo Evaluar

Mide varianza de latencia, consumo de tokens y costo API a través de K ejecuciones. Reporta coeficiente de variación, no solo la media. Marca tareas donde la varianza de costo o latencia excede 50% de la media como riesgos de fiabilidad.

Fallas Comunes

• Reportar costo y latencia medios sin varianza como señal de fiabilidad
• Solo medir consumo de recursos en entornos de desarrollo
• Tratar picos de costo como problemas de infraestructura en lugar de problemas de comportamiento del agente

Qué Mide

Si el agente maneja fallas de infraestructura graciosamente: timeouts de API, respuestas malformadas, indisponibilidad de herramientas, devoluciones de datos parciales. Un agente robusto reintenta, retrocede, o falla seguramente. Un agente frágil entra en estado inconsistente o abandona silenciosamente la tarea.

Señales de Falla

• Un solo timeout de API crashea todo el pipeline de tareas
• Fallas parciales de herramientas se propagan en resultados corrompidos downstream
• El agente hace bucles indefinidamente en errores reintentables
• Sin distinción de comportamiento entre fallas transitorias y permanentes

Cómo Evaluar

Inyecta escenarios de falla controlada: timeouts de herramientas, respuestas API malformadas, devoluciones de datos parciales. Mide ratio de precisión entre condiciones nominales y de falla. Un agente con R_fault = 0.9 mantiene 90% del rendimiento nominal bajo fallas de infraestructura.

Fallas Comunes

• Probar solo en entornos ideales y llamar al sistema "listo para producción"
• No construir lógica de reintento o respaldo gracioso en flujos agénticos
• Tratar todos los errores como fatales en lugar de categorizar por recuperabilidad

Qué Mide

Si el agente mantiene rendimiento cuando su entorno cambia de maneras semánticamente neutras: campos JSON reordenados, parámetros API renombrados, formatos de fecha cambiados, interfaces de herramientas evolucionadas. Los entornos de producción reales derivan. Los agentes frágiles fallan silenciosamente cuando lo hacen.

Señales de Falla

• El agente se rompe cuando el esquema de base de datos cambia, incluso en cambios no-rompientes
• El versionado API causa fallas silenciosas sin mensajes de error
• El reordenamiento de campos JSON produce comportamiento diferente del agente
• Los cambios de locale o zona horaria causan resultados impredecibles

Cómo Evaluar

Aplica transformaciones que preservan semántica al entorno: reordena campos, renombra parámetros, altera formatos. Compara rendimiento con línea base nominal. Un agente listo para producción debería ser indiferente a variación ambiental cosmética.

Fallas Comunes

• Asumir APIs y esquemas estables durante la vida del despliegue
• Hardcodear nombres de campos, formatos de fecha, o expectativas de ordenamiento
• No probar deriva de entorno como escenario de fiabilidad de primera clase

Qué Mide

Si el agente funciona consistentemente a través de reformulaciones semánticamente equivalentes de instrucciones: parafraseados, traducciones, variaciones de registro. Los usuarios reales no hablan como prompts de benchmark. Si "cancelar mi suscripción" tiene éxito pero "terminar mi plan" falla, el agente no puede manejar tráfico real.

Señales de Falla

• Las tasas de éxito caen significativamente para instrucciones no-inglesas
• El fraseo formal versus informal produce resultados diferentes
• Usuarios de diferentes trasfondos reciben resultados diferentes para solicitudes equivalentes
• La sensibilidad a paráfrasis es alta pero no documentada

Cómo Evaluar

Genera variantes de prompt semánticamente equivalentes usando parafraseado, traducción, y cambios de registro. Mide ratio de precisión entre prompts originales y variantes. Apunta a R_prompt cerca de 1.0 para cualquier despliegue de producción sirviendo usuarios reales.

Fallas Comunes

• Evaluar solo en formulaciones de prompt "canónicas" del benchmark
• Ignorar fiabilidad cross-lingual para despliegues multilingües
• Tratar sensibilidad a prompt como "comportamiento esperado" en lugar de defecto

Qué Mide

Si los niveles de confianza declarados del agente coinciden con sus tasas de éxito empíricas. Un agente que afirma 80% de confianza debería tener éxito aproximadamente 80% de las veces. Los agentes sobreconfiados causan que los usuarios confíen en resultados que deberían verificar. Los agentes subconfiados generan bucles de revisión humana innecesarios.

Señales de Falla

• Los resultados de alta confianza están mal con frecuencia sorprendente
• El agente nunca se abstiene o marca incertidumbre, incluso en tareas claramente difíciles
• Los puntajes de confianza se agrupan cerca de 90%+ independientemente de la dificultad de la tarea
• Los revisores humanos constantemente anulan decisiones "confiadas" del agente

Cómo Evaluar

Recolecta puntajes de confianza y resultados del agente. Grafica curvas de calibración (confianza vs. precisión empírica). Usa Error de Calibración Esperado (ECE) para cuantificar mala calibración. Los agentes bien calibrados tienen curvas en la diagonal.

Fallas Comunes

• No extraer o rastrear puntajes de confianza del agente en absoluto
• Tratar puntajes de confianza como ornamentales en lugar de relevantes para decisiones
• Optimizar para precisión sin probar calidad de calibración

Qué Mide

Si los puntajes de confianza del agente separan exitosamente éxitos de fallas. Un agente puede ser sistemáticamente sobreconfiado pero aún así asignar mayor confianza a tareas que completa correctamente. P_AUROC mide esta calidad de ranking independientemente del nivel de calibración.

Señales de Falla

• Los puntajes de confianza son idénticos para tareas que el agente domina y tareas en las que falla
• Las colas de revisión diseñadas alrededor de tareas de "baja confianza" no capturan fallas reales
• El enrutamiento basado en confianza no proporciona mejora sobre asignación aleatoria
• Los revisores humanos no pueden usar puntajes de confianza para priorizar su trabajo

Cómo Evaluar

Computa AUROC de puntajes de confianza prediciendo éxito binario de tarea. AUROC = 0.5 significa que la confianza es poco informativa; AUROC = 1.0 significa separación perfecta. Apunta a AUROC > 0.7 antes de construir enrutamiento basado en confianza en flujos de trabajo de producción.

Fallas Comunes

• Asumir que calibración implica discriminación. Son propiedades independientes
• Construir flujos de trabajo de revisión en puntajes de confianza sin validar AUROC
• Usar estimaciones puntuales en lugar de representaciones de confianza distribucionales

Qué Mide

Una regla de puntuación propia que penaliza conjuntamente tanto mala calibración como pobre discriminación. A diferencia de ECE o AUROC solos, el Puntaje Brier proporciona una medida holística única de calidad predictiva que incentiva reportes de confianza honestos. La desviación de la probabilidad verdadera siempre empeora el puntaje.

Señales de Falla

• El agente logra buen AUROC pero pobre calibración, o viceversa
• Reporte de confianza optimizado para una dimensión mientras la otra se degrada
• Ninguna métrica unificada única rastrea calidad predictiva general a través de versiones del modelo
• Las actualizaciones del modelo mejoran precisión pero silenciosamente degradan calidad de confianza

Cómo Evaluar

Computa Puntaje Brier = mean((confianza − resultado)²) a través de tareas. Rango [0,1]; menor es mejor. Usa como la métrica primaria agregada de predictibilidad en selección de modelo y decisiones de despliegue.

Fallas Comunes

• Rastrear solo precisión y AUROC sin una regla de puntuación propia
• Usar Puntaje Brier sin también reportar su descomposición de calibración/resolución
• Tratar calidad de confianza como preocupación secundaria a precisión de tarea

Qué Mide

Si el agente se adhiere a restricciones operacionales predefinidas: no exposición de PII, no acciones no autorizadas, no sobrepaso de límites. El cumplimiento evalúa adherencia a restricciones independientemente de si las violaciones causan daño inmediatamente observable.

Señales de Falla

• El agente ejecuta acciones fuera de su alcance de permisos definido
• Datos sensibles aparecen en logs, resultados, o sistemas downstream
• El agente evita pasos de confirmación para acciones irreversibles
• Las violaciones de límites solo se descubren en revisiones post-incidente

Cómo Evaluar

Define conjuntos de restricciones explícitamente antes del despliegue. Registra todas las acciones del agente. Computa S_comp = (tareas restringidas − tareas violadas) / tareas restringidas. Apunta a S_comp = 1.0; cualquier violación bajo este umbral es un riesgo de producción que debe abordarse antes de escalar.

Fallas Comunes

• Definir restricciones en documentación en lugar de en código ejecutable
• Probar cumplimiento solo en entornos sandbox con herramientas simuladas
• Tratar violaciones de cumplimiento como incidentes aislados en lugar de señales de fiabilidad

Qué Mide

Entre tareas donde ocurren violaciones de restricciones, ¿qué tan severas son las consecuencias? Devolver resultados en orden incorrecto es benigno. Ejecutar una declaración DELETE no intencionada es catastrófico. S_harm separa frecuencia de violación de severidad de violación. Es la descomposición clásica de riesgo de la ingeniería crítica de seguridad.

Señales de Falla

• Las violaciones se agrupan en categorías de acción de alta consecuencia: eliminaciones, pagos, comunicaciones
• El agente tiene acceso a herramientas irreversibles sin salvaguardas de autorización proporcionales
• No existe clasificación de severidad para diferentes tipos de violación
• La severidad de incidentes del mundo real es mayor que lo que predijeron las pruebas de seguridad

Cómo Evaluar

Asigna puntajes de severidad (0 = benigno, 1 = catastrófico) a categorías de violación antes del despliegue. Computa ℛ_Saf = 1 − P(violación) × E[severidad | violación]. Reporta métricas de seguridad separadamente de otras dimensiones. La seguridad es una restricción dura, no un intercambio.

Fallas Comunes

• Tratar todas las violaciones como igualmente severas, ignorando la distribución de severidad
• Otorgar acceso a capacidades irreversibles sin autorización escalonada
• Reportar solo tasas de violación sin análisis de consecuencias