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.

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 de tal manera que el usuario introduzca o cargue algún dato (la entrada del pipeline), le daría a algún botón y esto provocaría que los datos se enviaran al servidor web, el cual a su vez los pasaría a nuestra aplicación web dentro de cuyo código se invocaría al método predict() del modelo.

Lógicamente la carga del modelo se tendría que realizar a la hora de arrancar el servidor, no cada vez que un usuario requiera una predicción.

Otra alternativa mejor es empaquetar el modelo en un web service, con el que nuestra aplicación pueda actuar a través de una API REST. Una de las ventajas de esto es que nos facilita el escalado, puesto que podremos arrancar tantos web services como necesitemos y balancear las peticiones procedentes de la aplicación web entre los web services existentes.

Dentro de la estrategia anterior, tenemos el caso particular de desplegar nuestro modelo en el Cloud, si por ejemplo optamos por Google Cloud Platform, podemos recurrir a Cloud IA (lo que antes se llamaba ML Engine) y hacer lo siguiente: subir el fichero joblib que hemos guardado a un bucket del Google Cloud Storage y dentro de Cloud IA, crear un modelo con su correspondiente versión, que apunte al fichero que hemos subido.

Si el modelo ya existía y queremos subir una nueva versión, el procedimiento sería el mismo solo que no habría que crear un modelo, sino una versión del mismo y luego asegurarnos que esta versión es la que está activa.

De esta manera tendríamos un web service simple, que se encargaría del escalado y el balanceo de carga por nosotros. Habría que tener en cuenta que los datos de entrada tendrían que venir en formato JSON y los datos de salida se devolverían en ese mismo formato. Luego ya sería usar este web service en nuestra web o en nuestro sistema de producción correspondiente.

Todo esto está muy bien, pero hay un lado más oscuro del que no se habla tanto y que es el del “babysitting” o monitorización del rendimiento de nuestro modelo.

No existe eso de, “entreno mi modelo lo despliego y ya está” …Es necesario invertir tiempo en escribir código que permita controlar el rendimiento de nuestro modelo periódicamente y enviar alertas cuando aquel 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, lo cual es lógico: si nuestro modelo fue entrenado con datos de hace un año, es muy posible que no se adapte a los datos actuales.

Si lo piensas, incluso un modelo que haga algo tan aparentemente poco cambiante como clasificar fotos de gatos y perros puede requerir de un reentrenamiento regular.

Claro, esto no es porque los gatos y los perros muten de repente (en principio…), sino porque, por ejemplo, las cámaras utilizadas para tomar las fotos, junto con los formatos de imagen, contrastes y brillos, sí que tienden a cambiar cada cierto tiempo.

Sin mencionar el tema de las modas, razas que antes eran marginales y que de repente se vuelven tendencia…o circunstancias como que de repente surja la moda de poner chalequitos o gorritas a los pobres animales. Todo ello es motivo suficiente para que el rendimiento de nuestro sistema se vea afectado.

Descubre toda nuestra formación para poder desarrollar tus modelos de Machine Learning.