MLOps: cuando machine learning alcanza la mayoría de edad

En el Grupo CaixaBank, diariamente, se ejecutan cientos de modelos de scoring, prevención de fraude, clasificación y segmentación de usuarios, análisis o clasificación de texto…, algunos de ellos en real time. En total, se da servicio y soporte a la operación financiera y comercial a los más de 20 millones de clientes del banco.

La operación de estos modelos, una vez desarrollado por nuestros excelentes equipos de data scientists, contiene altos requerimientos técnicos de confiabilidad, robustez y trazabilidad. MLOPS nos proporciona un framework para asegurar que se cumplen esos requerimientos.

A continuación, veremos los conceptos básicos de machine learning y MLOPS.

Desmitificando Términos

En este mundo se han acuñado muchos términos que suenan en el día a día, pero ¿qué significan?

• Data drift: supongamos el caso de un esquimal que lleva toda su vida generando un modelo mental de cuándo debe salir con paraguas y se traslada a vivir al trópico. A la hora de decidir si tiene que salir a la calle con paraguas, cuando las condiciones son tan sumamente distintas a las que tenía cuando generó su modelo, eso se llama data drift.
• Falsos positivos: si miro al pasado, de las 10 predicciones que hice que debía llevar paraguas y lo llevé, en cuántas no acerté. De igual modo existen falsos negativos, verdaderos positivos y verdaderos negativos. En definitiva, son los datos en los que nos basamos para calcular el accuracy o precisión.
• Accuracy: el porcentaje resultante de calcular de cada 10 veces que salgo a la calle y llevo paraguas, cuántas realmente he acertado y no me he mojado. Mide lo fiable que es mi modelo a la hora de predecir.
• Model monitoring: quizás este sea uno de los términos más importantes, porque es el que trata de decidir en qué momento el modelo deja de ser fiable, qué tengo que hacer en ese momento. En el traslado al trópico, debo sustituir un modelo por otro, debo generar resultados con ambos e ir comparando, un día uno y otro día otro hasta que demuestre que el nuevo es mejor.

Todo este set de términos tan chulos, y otro sinfín de ellos, tratan de expresar en el mundo modelos de confianza que puedo tener en las predicciones para tomar decisiones y describir los motivos y tiempos en los que dicha confianza se pierde.

Sin querer entrar en el mundo de los datos, sí es importante destacar que es la base primordial para que las decisiones sean buenas, por lo que es importante conocer lo que se denomina la predictibilidad de una variable. Es decir, «el dolor de cadera» es una variable predictiva mientras el dolor no sea perenne o no haya existido nunca, en que deja de ser predictiva. En definitiva, encontrar la información adecuada, recopilarla, tratarla «como debe ser»… Que todos los tipos de información posibles estén representados (sesgo) es de vital importancia para que podamos vivir tranquilos con nuestras decisiones basadas en predicciones.

 

¿Quién es Quién?

El reto

Intervinientes en ML

1. Datos, obviando el método por el que se generan. Siempre debemos estar atentos a cómo varían los datos con los que tomamos nuestras decisiones.
2. Algoritmos, el modo en el que se procesan los datos para generar un entrenamiento.
3. Software, el proceso que define el flujo (pipeline) que se produce para generar la predicción.
4. Modelo, el resultado de aplicar a los datos el algoritmo en un pipeline y que servirá para generar las predicciones.
5. Monitorización, qué tan bien se comporta el modelo en relación con los datos de entrada y los resultados reales.

Ciclo de vida

Anteriormente hemos sentado las bases necesarias para el ML. Veamos cómo hasta ahora se creaba y se ponía en producción un modelo.

La petición

Una de las unidades de ventas quiere lanzar una campaña en la que regala un paraguas si abres una cuenta en un día lluvioso y quieren generar un stock de paraguas suficiente. Para calcular las unidades que deberán fabricar, piden una previsión de los días lluviosos en los próximos 6 meses a partir de enero. El reparto se irá generando diariamente según la predicción meteorológica para el día siguiente.

El desarrollo/experimentación

Esta fase se centra en los datos de entrada, el algoritmo y el modelo, desatendiendo en gran medida el software y la monitorización.

Nos llega la petición y debemos tener listo el modelo en producción el día 1 de enero.

1. Para calcular el promedio de días lluviosos en los primeros 6 meses del año, nos basamos en datos históricos y, mediante métodos estadísticos, realizamos una predicción aproximada del número de días lluviosos y las contrataciones de cuentas en días lluviosos, y se genera un stock aproximado redondeando al alza.
2. Para generar la distribución del reparto, se generará un modelo predictivo basado en series temporales, la predicción del tiempo, la afluencia a la oficina en días lluviosos, la probabilidad de contratación, etc.

Es necesario decir que la fase de experimentación tiene gran dependencia de los datos históricos, con lo que se debe garantizar que esta fase se produce con datos que representan fielmente la distribución de los datos de producción.

Para resolver la segunda parte, en la queremos generar el modelo predictivo, establecemos una sistemática de trabajo:

1. Preparamos los datos de entrenamiento del modelo con datos históricos, con los que ya conocemos la contratación en días lluviosos.
2. Tomamos una parte representativa de los datos para el entrenamiento y el resto los dejamos para validar los resultados.
3. Introducimos los datos en un algoritmo, que genera un aprendizaje.
4. De los datos que habíamos reservado, quitamos el componente de si se produjo o no la contratación, los pasamos por el resultado del aprendizaje y generamos una predicción.
5. Confrontamos los resultados del aprendizaje con los resultados reales y generamos un valor que indica la confiabilidad del modelo.

Este proceso se realiza iterativamente hasta que se consigue un indicador de confiabilidad suficientemente bueno como para continuar adelante con el proceso, es decir, hasta que estemos bastante seguros de que no nos vamos a confundir con la cantidad de paraguas que predecimos que serán necesarios para el día siguiente.

La industrialización

Esta fase se centra en el software y la monitorización. Se trata de estandarizar para que sea repetible, automatizable, escalable, monitorizable, mantenible, etc.

Al contrario que en la experimentación, la dependencia de los datos es mínima, bastará con hacer que los datos viajen según los flujos definidos sin generar errores inesperados.

Partiendo del experimento que se dio por bueno en la fase anterior y bajo los parámetros definidos por el DS, comienza un proceso de desarrollo de software.

1. Entender el flujo.
2. Implementar el flujo de entrenamiento.
3. Implementar el flujo de predicción.
4. Implementar el flujo de monitorización.
5. Implementar la lógica de reentrenamiento.
6. Implementar la lógica de puesta en producción.
7. Integrar la monitorización de datos y modelos.

Para dar por concluida esta fase de desarrollo, se debe validar que todos los componentes juegan su papel en el momento en que es necesario y que los resultados que se obtienen son los esperados.

En el supuesto de que todo lo anterior tenga el OK, los datos, las monitorizaciones, el software, el modelo, etc., se podrá poner en producción.

La producción

Asumamos que todo está perfecto y conseguimos ponerlo en producción para el día 1 de enero. Tendremos en producción:

1. Un software que es estable y que a partir de unos datos de entrada es capaz de generar una predicción.
2. Un software que es estable y que a partir de una orden puede generar con el mismo algoritmo una nueva versión del modelo que aprende con los nuevos datos que se han ido generando, es decir, cambia el modo de pensar.
3. Un software que es estable y que es capaz de comparar las predicciones con los datos reales y generar las métricas comparativas.
4. Un software que es estable y que es capaz de medir cuándo los datos que utilizamos para predecir y los resultados se están alejando de lo esperado.

Puesto que el proceso se ejecuta diariamente, en primer lugar se debe evaluar si las predicciones y la realidad están suficientemente cercanos, es decir, si puedo seguir concluyendo como lo hacía antes. En caso de que esto no sea así será porque las condiciones de contorno han cambiado. Deberemos, entonces, lanzar una petición que genere un nuevo modelo y se valide si ofrecerá mejores predicciones que el actual. Si de nuevo la respuesta es afirmativa, se sustituirá uno por otro, dejando registrado el cambio.

Curiosamente, todas estas modificaciones se han producido bajo los paradigmas establecidos por DevOps: «Un software se desarrolla, se configuran los pipelines de despliegue, se realizan pruebas estándares y, pasando por distintos entornos, llega a producción. Salvo que la monitorización arroje algún error o se desarrollen nuevos evolutivos, ni el software ni el modelo de trabajo cambiarán.»

Conclusiones

La madurez de las organizaciones viene dada por la fluidez con la que se ejecute el ciclo de vida. El papel de los ML Engineer es el de implantar en las organizaciones este nuevo paradigma. Por lo tanto:

– Deben aportar a los DS conocimientos y mecanismos propios del ciclo de vida del software que acorten la etapa de industrialización.

– Deben aportar herramientas que permitan a los DS centrarse en sus desarrollos sin necesidad de imbuirse en el mundo de la ingeniería de software, pero que por el contrario sigan las mejores praxis definidas para este.

– Deben proporcionar a DevOps los conocimientos y mecanismos propios a través de los que se garantice la estabilidad del software que se pone en producción.

– Deben aportar herramientas que permitan a DevOps centrarse en las operaciones sin necesidad de imbuirse en el mundo de la IA, pero que por el contrario sigan las mejores praxis definidas para este.

El peor enemigo de la evolución es la incertidumbre. ¿Estarías dispuesto a montar en un coche autónomo? Nuestra misión es aportar la confiabilidad y generar un entorno amigable en todos los ámbitos y que los entornos industriales permitan que también el software sea autónomo.

Sugiero una pregunta: mañana, ¿saldrás con paraguas?

¿Qué hacemos en CaixaBank Tech?

Nos estamos subiendo al futuro del ML industrializado incorporando estándares de la industria y generando nuestros propios frameworks, que respetan las reglas presentes del ML y garantizan la adaptabilidad a los futuros marcos regulatorios y éticos. Desde el área de Analítica Avanzada de CaixaBank Tech, buscamos generar un marco de trabajo escalable, mantenible y sostenible, que minimice el impacto de nuestra huella con la optimización de nuestros procesos.