Por qué tu monitorización de IA no está funcionando (y cómo solucionarlo)

Vamos a ser directos: si vigilas tu aplicación con IA de la misma forma que vigilas tus endpoints API, estás operando a ciegas.

Lo veo constantemente. Equipos montan su servicio de IA, lo conectan a su stack de observabilidad existente, ven las lucecitas verdes... y después se llevan un susto de muerte cuando los usuarios se quejan de la calidad de las respuestas o cuando la factura mensual es un 300% más alta de lo esperado. Las herramientas les dicen que todo va perfecto. Y no es así.

El problema va más allá de elegir métricas diferentes. Es que los sistemas de IA rompen por completo las suposiciones sobre las que construimos nuestra infraestructura de monitorización.

El modelo mental de los servicios web no encaja

La monitorización web tradicional asume una señal limpia: llega una petición, ocurre algo, sale una respuesta. Éxito o fracaso es binario. La latencia es latencia. Tu percentil 99 te dice algo útil.

Los modelos de lenguaje rompen cada una de esas suposiciones.

Una respuesta no llega de golpe: se genera token a token, lo que significa que "latencia" son en realidad al menos tres números distintos dependiendo de dónde estés en el proceso. Un HTTP 200 no significa nada sobre la calidad del resultado. El coste escala con tokens, no con peticiones. Y los fallos más graves son completamente silenciosos: el modelo devuelve una barbaridad con total confianza y un código HTTP perfecto.

Time to First Token: el número que el usuario realmente nota

Cuando alguien envía un prompt a tu función de IA, lo primero que experimenta es la espera. Concretamente, está esperando a que aparezca el primer token en pantalla. Eso es el Time to First Token (TTFT), y es lo más parecido a la "latencia percibida" que existe en el mundo de los LLM.

El problema del TTFT es que crece con la longitud del prompt. Si estás construyendo un sistema RAG que mete contextos enormes en cada solicitud para mejorar la precisión, estás arruinando al mismo tiempo el rendimiento percibido. Este es un compromiso fundamental que la monitorización tradicional no te va a mostrar.

Inter-Token Latency: el factor fluidez

Una vez que empieza el streaming, los usuarios desarrollan expectativas sobre la velocidad de lectura. El Inter-Token Latency (ITL) —el hueco entre tokens consecutivos— es lo que determina si la salida se siente fluida o entrecortada.

Los usuarios son sorprendentemente tolerantes con un flujo lento pero constante. Lo que odian es un flujo más rápido que se congela y se entrecorta. Tu monitorización debería distinguir entre estas experiencias, aunque el rendimiento bruto parezca aceptable.

Latencia extremo a extremo: el contexto lo es todo

La métrica p99 que funciona de maravilla para tu API REST te va a engañar completamente para solicitudes de IA. ¿Por qué? Porque una tarea de clasificación de 50 tokens y una generación de informes de 2.000 tokens tienen perfiles de latencia completamente distintos, y promediarlos genera un número que no representa nada.

Haz seguimiento de latencia por caso de uso. Cada métrica debe corresponder a una carga de trabajo con características consistentes. Si no, estás optimizando para una abstracción que no existe.

El problema del fallo silencioso

Aquí viene la parte más inquietante: los peores incidentes en producción con sistemas de IA a menudo producen cero alertas.

Tu modelo empieza a generar alucinaciones con total seguridad. El drift en tus prompts introduce sesgo sutil. El contexto recuperado se ignora en favor de memorias del entrenamiento. Todo esto devuelve HTTP 200, termina en un tiempo aceptable y parece perfectamente sano en tu dashboard.

No vas a detectar esto con checks de uptime. Necesitas monitorización de calidad de salida, y aunque es más difícil de implementar, es absolutamente esencial.

Lo que realmente importa

Agrupa tus métricas de IA alrededor de las preguntas que responden:

• ¿Es rápido? TTFT, ITL, percentiles de latencia por caso de uso
• ¿Escalable? Rendimiento de tokens, profundidad de colas, utilización de contexto
• ¿Es correcto? Tasas de completitud de tareas, patrones de error en las salidas
• ¿Es sostenible? Coste por tarea, eficiencia de tokens, consistencia del modelo
• ¿Cómo se comporta? (Para agentes) Completitud de tareas, conteo de pasos, detección de bucles

Algunas de estas cifras las tendrás gratis de tu infraestructura. La mayoría, no. Construir instrumentación personalizada para cargas de trabajo de IA no es opcional: es la única forma de ver lo que realmente está pasando.

Los equipos que lo hacen bien no usan mejores dashboards. Hacen mejores preguntas.