MLOps – Versionado de datos y modelos

En la siguiente entrada veremos un ejemplo de cómo versionar los datos y los modelos usando Databricks, MLFlow y Delta Engine, pero antes vamos a repasar algunos conceptos.

Introducción a MLOPS

¿Qué es Mlops?

Se entiende Mlops como la aplicación de metodología DevOps en el mundo del Machine Learning, el cual busca la gestión, la evolución y la automatización de las diferentes fases del ciclo de vida de los modelos de IA.

¿Porque MLOps?

Para poder desarrollar, integrar y productivizar modelos IA en las organizaciones a gran escala de forma automatizada; garantizando calidad, estabilidad, confianza y gobernanza de los múltiples modelos IA.

Principios de Mlops:

1. Automatización: Mediante pipelines de CI/CD
2. Versionado: De los datos de entrenamiento, del código y del modelo.
3. Test: Tests unitarios y test de integración.
4. Monitorización: De los recursos/infraestructura y también del rendimiento en el tiempo del modelo para evitar la degradación de este. 
5. Reproducibilidad: Ser capaces en todas las fases (procesado de los datos, entrenamiento del modelo y despliegue del modelo) de reproducir los mismos resultados dado una misma entrada.

En esta entrada vamos a centrarnos en la parte técnica del versionado tanto de los modelos como de los datos.

¿Por qué versionar los datos y los modelos?

En los proyectos de Machine Learning, los Data Scientists están continuamente intentando desarrollar nuevos modelos o mejorar los actuales. Este proceso requiere probar diferentes datasets, parámetros de configuración, así como múltiples algoritmos. Es por ello por lo que es realmente necesario disponer de un histórico de versiones tanto de los datos como de los modelos para poder desplazarnos a través de ellos.
También por razones de explicabilidad y reproducibilidad, hay que ser capaces de demostrar con que datos se ha entrenado cada versión del modelo ya sea para el análisis y comparativa interna como para auditoría externa, lo cual exigen desde la mayoría de los sectores, siendo muy críticos en banca o seguros, por ejemplo. 

¿Cómo podemos hacerlo?

Esto es algo que dependerá de las tecnologías o del proveedor cloud donde se encuentre el proyecto, por ejemplo, Azure dispone de esta funcionalidad de forma nativa en Azure Machine Learning. Pero en este caso vamos a mostrar una solución agnóstica al proveedor cloud, para ello vamos a usar las siguientes tecnologías:

• Databricks como plataforma para el procesado y preparación de los datos, así como de plataforma de cómputo para el entrenamiento de los modelos.
• MLFlow como solución para la gestión del ciclo de vida.
• Delta Lake como capa de governance y management para el almacenamiento de los datos.

Por poner la solución en contexto, imaginemos un proyecto o caso de uso, con su fase de ETL, posteriormente un modelo predictivo que funciona en modo batch sobre esos datos y unos resultados que son visualizados finalmente con una herramienta de dashboarding.
Como podemos ver a continuación distinguimos dos flujos o procesos, por una parte, el proceso de entrenamiento y por otra parte el proceso de inferencia.

Flujo de Entrenamiento:

1. Se obtienen los datos iniciales, se prepara y genera el dataset para el entrenamiento del modelo.
2. Mediante Delta Engine se guarda la nueva versión del dataset en el storage.
3. Posteriormente mediante MLFlow se guarda como parámetro la versión del dataset utilizada para entrenar el modelo, la versión del modelo y los múltiples KPI’s que se decidan para medir el rendimiento de este.
4. Se ejecuta el entrenamiento del modelo y este queda registrado en la UI de MLFlow en Databricks.
5. Posteriormente podremos comparar los KPI’s del nuevo entrenamiento y decidir si éste mejora el modelo actual en producción.
6. En caso de que mejore el rendimiento, cambiaremos el Stage a “Production” y automáticamente el modelo actual que hay en producción pasará a “Archive”. Si no mejora, no cambiaremos el stage y se mantendrá el modelo actual.
7. Todas las versiones del modelo quedan registradas en MLFlow, por lo que en caso de Rollback solo será necesario cambiar el Stage del modelo en cuestión.

Flujo de Inferencia:

1. Databricks usará la versión del modelo con el stage “Producción”.
2. Tomará también los datos que queremos inferir
3. Ejecutará el modelo con los datos de inferencia y mostrará las predicciones
4. Estos datos se pueden consumir de múltiples formas, por ejemplo, mediante un SQL Endpoint conectado a una herramienta de dashboarding para la visualización.

Fase de Entrenamiento

Esta parte se suele ejecutar mediante un pipeline de orquestación, la cual puede ejecutarse bajo demanda o de forma desatendida o programada en el tiempo, en esta entrada vamos a centrarnos solo en la parte del código que hace posible el entrenamiento y el versionado de los datos y el modelo.
Estos serían los principales bloques del código usado para el entrenamiento del modelo:
 

Transformar y preparar los datos

Guardamos el dataset haciendo uso del Delta Engine, esto nos permitirá más adelante consultar las diferentes versiones de los datos utilizadas para entrenar cada modelo.
Como podemos ver en el siguiente código, creamos la tabla en formato Delta que es el que permitirá el versionado de los datos.
Para el ejemplo usaremos el propio storage interno de Databricks, pero es recomendable usar un storage desacoplado como puede ser AWS S3 o Azure Datalake.

Entreno y registro del modelo 

En el siguiente bloque de código, ejecuta el entrenamiento, se definen las variables y los parámetros de este y se registra el modelo mediante la API de MLFlow.

Log de metricas en MLFlow

Como primera métrica en este ejemplo contamos con el resultado de la función “precision_score” de SKLearn que proporciona un valor para medir la precisión del modelo, en esta función la precisión se mide como tp / (tp+fp) donde tp es el número “true positives” y fp es el número de “false positives” aunque dependiendo del modelo se podrían usar muchas otras como RMSE, MAPE o MAE entre otras.

Otro dato que puede ser interesante dependiendo de cómo se entrene el modelo es el número de registros con el que se ha entrenado el modelo, así como el número de registros con el que se ha testeado.
Estas metricas son utilites para poder identificar problemas con los datasets de entrada por una parte y también pueden ayudarnos a comprender los cambios de precisión entre múltiples entrenos del mismo modelo.
 

Log de parámetros en MLFlow

Con el siguiente bloque de código consultamos la versión actual de la tabla del dataset que estamos usando para entrenar el modelo y guardamos el número de versión como un parámetro en MLFlow. Esto contribuirá posteriormente a poder consultar los datos de esta versión del modelo.

Guardamos la versión del modelo:

Por último, cerramos la ejecución o run actual. 

Como hemos adelantado MLFlow nos permite hacer tracking de todos los componentes que conforman un modelo, desde su código y artefactos hasta los parámetros y las métricas, así como otros metadatos de interés. También nos ayuda en la gestión de los modelos mediante el model registry que nos permite indicar en que fase se encuentra cada versión del modelo.

A continuación, se muestra la UI de MLFlow dentro de Databricks para nuestra demo.
Por una parte, si accedemos al experimento en este caso “MLFlow Registry” nos van a aparecer todas las ejecuciones o entrenamientos que hemos hecho de este modelo.
Como información relevante, o en lo que hemos hecho foco en este post, en la parte derecha aparecen las métricas y los parámetros que se han registrado durante el entreno; destacar en esta parte los parámetros que hemos registrado con nuestro código “DataV” para la versión del dataset de entreno y “ModelV” para la versión del modelo.
También podemos ver el número de registros con los que se ha entrenado “TrainRows” y testeado “TestRows” cada versión del modelo, los cuales nos aportan más información sobre el dataset utilizado.
 

Datos de entreno

Si nos dirigimos a la pestaña de datos y seleccionamos la tabla de entrenamiento, podemos ver el histórico de versiones de la tabla que hemos creado previamente “iris_training_data”.

También en un notebook mediante query podemos consultar las diferentes versiones de la tabla, donde inicialmente tenía 50 registros, en la versión 1 tenía 100 y finalmente en la versión 2 cuenta con 150 registros. 

Esto sería por ejemplo un proyecto con una carga incremental donde el modelo puede ir mejorando su precisión en el futuro al tener más datos con los que entrenarse. Dependerá de la frecuencia de llegada y de la cantidad de datos decidir el tiempo entre entrenamientos.

Otra información que podemos ver desde MLFlow son las dependencias y el pkl de esta versión del modelo, haciendo clic sobre el modelo en cuestión.
 

Como hemos podido observar a lo largo de esta entrada las posibilidades que nos ofrece MLFlow son muy extensas y de hecho es una herramienta que se ha consolidado como un estándar en la industria cuando empresas como Databricks o Azure entre muchas otras la han integrado en sus productos, además cuenta con muchas organizaciones como “contributors” lo que garantiza su mantenimiento y evolución.