Cómo pasar de Jupyter Notebooks a modelos en producción
Todos los Data Scientist amamos a Jupyter Notebook. Es una de las herramientas más populares y útiles cuando damos esos primeros pasos. Recuerdo que después de estar usando R-Studio por varios meses, Jupyter me resultó muy útil para aprender y consolidar mis habilidades en Python. Y es que esa sensación de ir “paso a paso” y mantener el control de la ejecución genera una confianza que es primordial cuando te inicias en el mundo del Machine Learning. Además, los Notebooks te permiten hacer mucho EDA (Exploratory Data Analysis), con sus interfaces gráficas adaptadas a matplotlib y a plotly, y puedes ir desarrollando y anotando las ideas y resultados. También es genial para versionar los cuadernos e ir desarrollando pruebas de concepto (PoC). Llega un momento en el que te parece que Jupyter Notebook es lo único que necesitas tener en tu arsenal de herramientas, pero pronto te das cuenta que no es así.
Y si bien es muy cómodo mantenerse allí, y en principio no tiene nada de malo usar Notebooks, hay varias razones para hacerte migrar en el mediano o largo plazo. La gran mayoría de profesionales está de acuerdo en que usar un entorno de programación (IDE) como PyCharm, Spyder o VisualStudio mejorará tu trabajo como Data Scientist en muchos sentidos:
- EL IDE es más eficiente a nivel de recursos.
- El IDE te obliga a usar mejores prácticas de desarrollo.
- Disminuye el tiempo de implementación.
- Aumenta la posibilidad de tu script llegue a producción.
- Es difícil hacer debuging en Jupyter, y no existen herramientas de control de código, ni autocompletación.
- Se corre el riesgo de concentrar el foco del proyecto solo en la parte de Machine Learning y olvidarse del resto (implementación de funciones API y autenticación, por ejemplo).
Otros autores añaden a esta lista dos factores muy importantes, pero que a mi juicio deben ser vistos con cautela: la falta de reproducibilidad y la falta de trazabilidad. Sostengo que deben ser vistos con cautela porque éstos tienen que ver más con el proceso mental del equipo y del Data Scientist, que con una falla de Jupyter Notebook. Aclaremos en primer lugar, que la supuesta falta de trazabilidad responde a que Jupyter Notebook es una herramienta que permite al Data Scientist trabajar solo en su ordenador (los cuadernos en GitHub no hacen buen merge) y entonces el resto del equipo pierde la visibilidad del proyecto. Personalmente, no he visto un controlador de versiones que trabaje bien con Jupyter, aunque confieso que no he probado JupyterLab.
Con respecto al segundo factor, también es algo que debe verse con cuidado, porque tampoco es una falla del producto en sí. Se refiere a que las celdas en los Notebook puede ser ejecutadas en cualquier orden, sin restricciones, y si no se tiene cuidado se puede alterar la data original sin darnos cuenta. Si ejecutas una celda, y luego la corriges y la vuelves a ejecutar, se borrará lo que había antes y se perderá la reproducibilidad. Cualquier valor intermedio también se pierde. En Data Science, muchas veces el proceso no es top to bottom, ni siquiera lineal, sino que tiene muchas iteraciones e idas y vueltas, y precisamente esta capacidad de Jupyter de poder reejecutar celdas en cualquier orden es de gran ayuda, pero conlleva un gran peligro implícito: una vez trastocado el orden no se puede reproducir.
Dicho lo anterior, sigo amando a Jupyter Notebook. Pero quizá la razón más importante por la que no es buena idea quedarse con él como herramienta oficial del equipo DS, es que no es posible pasar a producción con un Notebook. A pesar de que todas las plataformas de ML en la nube prometen sinceramente que si se puede, siempre hay que reescribir le código y aplicar las mejores prácticas de desarrollo. Es inevitable entonces retrabajar para limpiar y ordenar el script para hacerlo más ejecutable. Parece entonces, que al final tiene más sentido usar Jupyter Notebook para EDA y hacer pruebas de concepto, pero pasar lo antes posible a un IDE (PyCharm, VS o Spyder) para completar el resto proyecto. Afortunadamente se puede reusar parte del código.
Y, ¿cómo pasar entonces a producción, una vez que hayas migrado a un IDE? En primer lugar, hay que desarrollar un script ejecutable, y lograr que corra sin problemas. Luego, hay dos vías para pasar a producción. La primera es sirviéndose de un programa “orquestador”, que se encargue de correr automáticamente nuestro script en el día y hora deseada. Hay varias alternativas, de alto y bajo nivel, pero mencionaremos las open sourced como Airflow, DAGSter. He visto también proyectos que usan UiPath como orquestrador y funcionan bien. Debo mencionar que en tiempos remotos, la orquestación era basada en demonios tipo cron, que llevaban un rígido calendario para ejecutar las aplicaciones en su momento. Hoy en día, la tendencia es a manejarse más en el mundo de los eventos, es decir, ejecutar los programas como una secuencia de eventos, más que a una hora programada. Una secuencia de eventos y procesos que se ejecutan en un orden establecido se puede representar como un gráfico dirigido no cíclico, o DAG en inglés, y es en esta filosofía que funcionan AirFlow y DAGster. Esto permite enlazar varios programas y usar la salida de uno para alimentar al siguiente, y así continuar.
La segunda alternativa, es repensar nuestro script como una aplicación web o una API, es decir como un programa residente en un servidor que responde a peticiones aleatorias bajo demanda. Para ello, puedo recomendar usar la librería Flask, que adapta el script para convertirlo en web server. Una vez adaptado, podemos instalar entonces este web server en un entorno local o remoto, con su url propia y sus puertos de entrada y salida, y enviarle peticiones. Si el tráfico es bajo, esto ya nos valdría, pero siempre hay que tener en cuenta cierta planificación para escalar el servicio cuando lo amerite. Hace poco encontré la librería Streamlit, que permite publicar los scripts directamente en la web, y lo estuve probando con buenos resultados, aunque no estoy seguro de como funcionaría en un entorno corporativo. Una alternativa a este enfoque es usar Function as a Service, o cualquier opción “serverless” de Amazon, Google Cloud o Azure. Estas opciones prometen tomar el script “as is” y convertirlo en una función tipo Lambda de AWS sin tener que preocuparnos por la configuración del servidor. El concepto es el mismo, pero el servicio cloud se ocuparía de la configuración y puesta en marcha.
Una vez puesto en producción, el modelo debería ser monitoreado para detectar posibles desviaciones de rendimiento. Si se detectan, entonces se reinicia el proceso para entrenar de nuevo al modelo y el ciclo empieza de nuevo.
El objetivo final de un departamento de DS debería integrar su trabajo en el flujo de las operaciones de la empresa, esto es lo que se llama MLOps, u operaciones de Machine Learning. Este término se relaciona con el DevOps, o desarrollo contínuo. La integración debería ser normal con la operación diaria de la empresa, sin necesidad de paradas de máquinas o migraciones complicadas. Parte del trabajo para lograr ese objetivo es lograr coherencia e integración entre el grupo DS, los Data Engineers y el resto del equipo. Deshacerse de Jupyter Notebook es el primer paso hacia lograrlo, ya que permitiría hablar en un lenguaje común. Las normas y standards de desarrollo deberían ser compartidos.
Sin embargo, como conclusión, debo señalar que si bien lo anterior es la forma de trabajar actualmente, la tendencia es ir hacia entornos complejos, tipo “Code Less”, que permitan pasar ya no del Notebook, sino de un entorno gráfico para realizar experimentos ML a la implementación directamente con un botón. Tal es el caso de Sagemaker de AWS, Azure ML de Microsoft, y Solver AI Studio de Asseco. Las premisas de estas plataformas es liberar al Data Scientist de la carga del código y hacerlo enfocarse en los datos y en los resultados. Algunas de estas plataformas, por ejemplo Solver AI Studio, cuentan con modelos precargados y pre entrenados de varios casos de uso para acelerar la puesta en producción de los modelos predictivos. Incluso, poseen herramientas para monitorizar los modelos en producción y medir su desempeño, para reentrenarlos de forma automática cuando sea necesario. Todo esto sin escribir una línea de código.
Nosotros en Asseco podemos ayudarles en la selección del modelo de trabajo que mejor se adapte a sus necesidades. Podemos guiarlos en el proceso de convertir sus modelos de laboratorio en modelos en producción.
Carlos Alberto García
Data Scientist
Asseco Spain Group
