Productivización modelos machine learning. Mi modelo está listo ¿y ahora qué?
A estas alturas de la película, seguro que todo el mundo tiene claro ya que para pensar siquiera en productivizar nuestro modelo de Machine Learning. Su performance con respecto al conjunto de test (esos datos que desde un principio no se deben tocar, mirar, ni mencionar para no distorsionar la verdadera capacidad de generalización de nuestro modelo aspirante a pasar a producción) tiene que ser bueno. Esto quiere decir que, o bien mejore al modelo actual, o bien si no hay tal modelo, por lo menos descargue a las personas que actualmente se encargan de estimar lo mismo que el modelo, de esta tarea. De modo que puedan dedicar su tiempo a algo más provechoso.
Pues bien, si hemos conseguido lo comentado anteriormente, tendremos que presentar nuestro modelo a los jefes haciendo especial hincapié en los siguientes puntos:
- ¿Qué hemos aprendido de los datos?
- ¿Definir qué fue aquello que intentamos y funcionó peor?
- ¿Identificar qué fue aquello que sí que funcionó bien?
- Posibles alternativas para mejorar el resultado actual y tiempo necesario para probarlas.
Una bonita presentación, con visualizaciones claras y frases concisas y fáciles de recordar del tipo «según el modelo actual la feature X, parece ser la que tiene más peso a la hora de predecir el label y», será imprescindible también.
¡Perfecto! Nuestros jefes han quedado encantados, pero… ¿y ahora cómo ponemos el modelo en producción? Bueno, si has montado tu modelo en scikit-learn puedes optar por volcar a disco tu modelo entrenado, por supuesto incluyendo todo el pipeline de preprocesamiento de datos y de predicción.
Para ello podemos utilizar nuestro querido pickle, aunque para esta tarea, casi es preferible el uso de joblib más eficiente a la hora de tratar con objetos que internamente manejan grandes estructuras de numpy, como suele ser el caso de los estimators de scikit-learn.
MLflow: rastrea experimentos y gestiona versiones de modelo
Antes de pasar a producción, aparece rápido un problema cuando se trabajan varios modelos o se prueban distintas configuraciones: la trazabilidad. ¿Con qué hiperparámetros entrené el modelo que mejor funcionó la semana pasada? ¿Qué versión está activa en producción ahora mismo? MLflow resuelve exactamente esto. Es una plataforma open source que registra automáticamente cada experimento —parámetros, métricas, artefactos y el propio fichero del modelo— y ofrece una interfaz web para comparar ejecuciones de un vistazo.
La pieza más útil para la productivización de modelos de machine learning es el Model Registry de MLflow: asigna estados (Staging, Production, Archived) a cada versión del modelo, convirtiendo el paso a producción en un cambio de estado auditado en lugar de un copy-paste de ficheros. Si la nueva versión no funciona bien, revertir a la anterior es tan sencillo como cambiar el estado de vuelta. Esta gestión de versiones es la que separa un proyecto de datos profesional de uno que depende de que nadie renombre un fichero sin avisar.
Despliegue moderno: FastAPI y Docker
El cómo desplegar nuestro modelo dependerá del caso de uso. Por ejemplo, supongamos que nuestro modelo se vaya a usar en una página web: el usuario introduce o carga algún dato, pulsa un botón, los datos se envían al servidor y este los pasa a nuestra aplicación, que invoca al método predict() del modelo. Lógicamente la carga del modelo se tendría que realizar al arrancar el servidor, no cada vez que un usuario requiera una predicción.
Una alternativa mejor, y hoy el estándar de facto, es empaquetar el modelo como un web service REST independiente. El framework de referencia para esto es FastAPI: asíncrono, con validación automática de entrada y salida vía Pydantic, documentación Swagger generada automáticamente y rendimiento que compite con los frameworks más rápidos. En la práctica, un endpoint de predicción en FastAPI se escribe en pocas líneas: se carga el modelo al arrancar la aplicación, se define un endpoint /predict que acepta un JSON con los datos de entrada y devuelve la predicción. Una ventaja añadida es que permite arrancar tantas instancias como sean necesarias y balancear la carga entre ellas.
La pieza que cierra el ciclo es Docker. Empaquetar el modelo, el código de la API y todas las dependencias en una imagen Docker garantiza que lo que funciona en tu portátil funcione igual en el servidor de producción. El Dockerfile de un servicio de predicción habitual no supera las 15 líneas: imagen base de Python, instalación de dependencias desde requirements.txt, copia del modelo serializado y del código de FastAPI, y comando de arranque con Uvicorn. A partir de ahí, el mismo contenedor se puede desplegar en Vertex AI, AWS SageMaker, Azure ML o en cualquier servidor propio.
Si optamos por Google Cloud Platform, podemos recurrir a Vertex AI (que evolucionó del antiguo ML Engine) y hacer lo siguiente: subir la imagen Docker o el fichero joblib a un bucket de Google Cloud Storage y crear un modelo con su correspondiente versión en Vertex AI. Si el modelo ya existía y queremos subir una nueva versión, el procedimiento es el mismo, solo que no habría que crear el modelo desde cero, sino solo asegurarnos de que la nueva versión queda activa. De esta manera tendríamos un web service que se encargaría del escalado y el balanceo de carga por nosotros, con los datos de entrada y salida en formato JSON.
Monitorización del rendimiento: data drift y concept drift
Todo esto está muy bien, pero hay un lado más oscuro del que no se habla tanto: el del «babysitting» o monitorización del rendimiento del modelo. No existe eso de «entreno mi modelo, lo despliego y ya está». Es necesario invertir tiempo en código que permita controlar el rendimiento periódicamente y enviar alertas cuando decrezca.
Podremos encontrarnos con caídas fuertes y evidentes (por ejemplo, si falla algún componente de infraestructura) o con un deterioro paulatino más difícil de detectar a largo plazo. Esto último es habitual ya que los modelos tienden a «deteriorarse» con el tiempo: si el modelo fue entrenado con datos de hace un año, es muy posible que no se adapte bien a los datos actuales.
Si lo piensas, incluso un modelo que haga algo tan aparentemente estable como clasificar fotos de gatos y perros puede requerir reentrenamiento regular. No porque los animales muten, sino porque las cámaras, los formatos de imagen, los contrastes y los brillos sí cambian con el tiempo. Sin mencionar modas, razas que se vuelven tendencia o la costumbre de poner chalequitos a las mascotas. Todo ello es motivo suficiente para que el rendimiento del sistema se vea afectado.
Este deterioro tiene nombre técnico: data drift (cuando la distribución de los datos de entrada cambia respecto a los datos de entrenamiento) y concept drift (cuando cambia la relación entre las features y el target). Detectarlos a tiempo es lo que separa un sistema de ML gestionado de uno que falla en silencio durante semanas.
Evidently es una librería open source que genera informes HTML o JSON con tests estadísticos sobre data drift, calidad de datos y métricas de rendimiento del modelo. Se integra fácilmente en pipelines existentes y permite definir umbrales de alerta: si la distribución de una feature clave se desvía más de un margen definido, el informe lo marca en rojo. WhyLabs va un paso más allá y ofrece observabilidad continua: los perfiles de datos se envían periódicamente a su API y la plataforma detecta anomalías automáticamente, alertando al equipo antes de que el impacto llegue al negocio.
Si quieres dominar todo este ciclo, desde la preparación del modelo hasta su monitorización en producción, el Máster Experto en Data Science, Big Data e IA de Datahack cubre MLOps, despliegue y el stack completo con práctica real.
