La pregunta sobre cómo se va a monitorear un modelo de ML en producción suele llegar en el momento equivocado: después del despliegue, cuando el sistema ya está funcionando y alguien se da cuenta de que no hay forma de saber si sigue funcionando bien.
En Aleph Server, esa pregunta se hace antes de definir la arquitectura del pipeline. No es una práctica ceremonial: es la consecuencia de haber visto qué ocurre cuando el monitoreo se trata como una etapa posterior.
El problema de la degradación silenciosa
Un modelo de Machine Learning en producción no tiene un comportamiento estático. Los datos que lo alimentan cambian con el tiempo: los patrones de comportamiento de los clientes evolucionan, los sistemas de origen modifican sus formatos, las variables que eran predictivas en un período dejan de serlo en otro.
Ese fenómeno, conocido como model drift o data drift, produce una degradación gradual en la calidad de las predicciones. El modelo sigue respondiendo con normalidad aparente, pero sus predicciones son progresivamente menos confiables. Sin monitoreo activo, esa degradación es invisible hasta que sus consecuencias aparecen en el negocio: decisiones tomadas sobre datos incorrectos, procesos automatizados que producen resultados erróneos, clientes afectados por recomendaciones que ya no son válidas.
El costo de detectar el problema tarde no es solo el costo de corregir el modelo. Es el costo de todas las decisiones tomadas durante el período en que el modelo estaba degradado sin que nadie lo supiera.
Por qué el monitoreo no puede diseñarse después
Si el monitoreo se define después del despliegue, hay una probabilidad alta de que el sistema no tenga la instrumentación necesaria para soportarlo. Los pipelines no están registrando los datos que el monitoreo necesita. Las predicciones no se almacenan junto a sus inputs. No hay mecanismo para comparar predicciones con resultados reales de forma sistemática.
Retrofitear monitoreo sobre un sistema que no fue construido para ser observado requiere modificar el pipeline en producción, lo que implica riesgo operacional, tiempo de ingeniería y, frecuentemente, la pérdida de los datos históricos necesarios para establecer una línea base.
Cuando el monitoreo se define antes, el pipeline se construye de forma que genera los datos necesarios desde la primera ejecución. Las decisiones de diseño —qué registrar, en qué formato, con qué frecuencia— se toman una sola vez, en el momento correcto.
Las tres preguntas que definen el monitoreo antes del diseño
En Aleph Server, antes de proponer cualquier arquitectura de ML, se responden estas tres preguntas con el equipo del cliente:
Primera: ¿cómo vamos a saber si el modelo sigue siendo preciso? La respuesta requiere definir cuándo se conocen los resultados reales que permiten comparar con las predicciones, y cómo se registran esos resultados junto a la predicción correspondiente en el momento en que se generó. Sin ese registro, la evaluación retrospectiva no es posible.
Segunda: ¿qué pasa si los datos de entrada cambian su distribución? Hay que definir qué variables se monitorean, qué umbrales de variación son aceptables, y qué acción se toma cuando esos umbrales se superan. Esa acción puede ser una alerta para revisión manual, un reentrenamiento automático del modelo, o la suspensión de las predicciones hasta que el equipo evalúe la situación.
Tercera: si el modelo empieza a fallar hoy, ¿cuánto tiempo tardaríamos en detectarlo? La respuesta honesta a esta pregunta define el riesgo operacional real del sistema. Si la respuesta es más de 48 horas, el sistema no tiene monitoreo efectivo independientemente de lo que diga la documentación.
Qué implica esto en el alcance del proyecto
Definir el monitoreo como criterio de diseño implica que el alcance del proyecto incluye, desde el inicio, tres componentes que frecuentemente se omiten: el registro estructurado de predicciones con sus inputs, el cálculo y almacenamiento de métricas de calidad en cada ciclo de ejecución, y los umbrales y mecanismos de alerta para derivaciones.
Eso agrega tiempo al desarrollo inicial. También elimina el tiempo —considerablemente mayor— que se invierte en diagnosticar problemas de un sistema que no fue construido para ser observado.
La postura de Aleph Server
Un sistema de ML sin monitoreo efectivo no es un sistema en producción: es un sistema que nadie sabe si funciona. Esa distinción es parte de la conversación que tenemos antes de proponer cualquier arquitectura, y forma parte del criterio con que evaluamos si un proyecto está listo para desplegarse.
No siempre es la conversación que el cliente espera en esa etapa. Siempre es la conversación que el cliente agradece cuando el sistema lleva seis meses en producción y sigue siendo confiable.
