¿Cómo escalar modelos de ML en producción? Un viaje por la construcción de nuestro framework de MLOps — Parte 1
Introducción
En el siguiente post vamos a explicar cómo hemos construido los últimos 2 años el framework de MLOps que tenemos en MACH. El post se dividirá en dos partes: en la primera explicaremos qué es MLOps, cuándo es necesario tener un framework de MLOps y cuáles son las principales componentes del framework que tenemos en MACH. En la segunda, explicaremos los principales flujos de trabajo que tenemos en nuestro framework de MLOps.
¿Qué es MLOps?
MLOps significa Machine Learning Operations e involucra todo el proceso de llevar modelos de ML a producción, mantenerlos y monitorearlos; de manera eficiente y confiable.
Si venimos de hacer un curso tradicional de ML o de Kaggle (competencias de ML), probablemente pensemos que lo más importante es lograr un modelo con las mejores métricas de desempeño en nuestra muestra de test. La realidad es que el código de los modelos de ML solo es una componente pequeña dentro de todo lo que conlleva el MLOps.
En los modelos en producción no existe un dataset depurado con el que podemos directamente entrenar el modelo. Tenemos normalmente distintas fuentes de información, de las que debemos extraer las features que ocuparemos luego en nuestros modelos. Además, estos datos con los que calculamos las features están constantemente cambiando, a veces de manera abrupta (crisis del Covid, por ejemplo) o de manera gradual. Por este motivo, es muy necesario monitorear todo el proceso para asegurarnos que nuestro modelo siga teniendo un impacto positivo en el negocio.
¿Realmente necesito un framework de MLOps?
Antes de presentar el framework de MLOps en MACH, debemos preguntarnos si para el caso de uso que tenemos en mente realmente necesitamos un modelo de ML o un framework de MLOps. Muchas veces el problema de negocio se puede abordar de manera más simple y lograr un impacto más rápido y barato. Por ejemplo, en vez de desarrollar un modelo de clasificación de texto, podemos partir ocupando expresiones regulares, palabras claves o heurísticas que nos permitan abordar el problema que queremos resolver.
Para que se justifique tener un framework de MLOps debemos tener la necesidad de escalar y desplegar varios modelos de ML en producción. Si queremos partir con un solo modelo, podemos desarrollarlo en un notebook de Jupyter y guardar sus predicciones en una tabla que se ocupe después para tomar una decisión (a qué clientes mandarles cierta campaña, por ejemplo). Esto nos va a permitir validar que el modelo tenga un impacto positivo en el negocio antes de desarrollar un framework completo.
¿Cómo lo hicimos en MACH?
En MACH la primera necesidad que tuvimos fue poder compartir y estandarizar las features que se ocupaban en los modelos de ML. Para esto, desarrollamos un Feature Store que presentamos en otro post que dejamos en el link.
Después fuimos desarrollando todas las componentes necesarias para entrenar y desplegar un modelo de ML:
- Features (del Feature Store): todas las variables independientes que se ocupan para entrenar los modelos de ML.
- Audiencias: todos los clientes de MACH a los que se les aplicará un determinado modelo
- Targets: todas las variables dependientes que queremos predecir en nuestros modelos
- Tablones de entrenamiento e inferencia: cada vez que entrenamos o hacemos inferencia con un modelo, guardamos las features que se ocuparon.
- Resultados de modelos: tabla que guarda los resultados de la inferencia de los modelos.
- Calidad de features: calculamos distintos estadísticos de las features (media, mediana, porcentaje de nulos, etc.) para asegurarnos que las variables que ocupamos en los modelos tengan una buena calidad.
- Estabilidad de features: calculamos el CSI de las features en el dataset de entrenamiento vs el dataset de inferencia para detectar cambios en la distribución (data drift).
- Desempeño y estabilidad de modelos: calculamos las métricas de desempeño de los modelos y también su estabilidad en el tiempo, para detectar cambios abruptos en la inferencia de los modelos.
- Grupos de control: usuarios a los que no se les envían campañas comerciales para medir el impacto de los modelos que se ocupan en el área comercial.
- Sistema de alertas: tenemos distintas alertas que nos avisan si existe algún problema dentro de todo el flujo de MLOps (features con errores, caídas en desempeño de modelos, cambios en la distribución de las variables, etc.)
En la siguiente publicación, explicaremos cómo utilizamos estas distintas componentes en los flujos de trabajo que tenemos en MLOps.
🙌 Si te interesó lo que leíste y quieres ser parte de un ambiente colaborativo y 100% flexible, puedes postular acá 👀 y trabajar con nosotros MACH, de Bci para todos 💜
