MLOps: administrando el diseño y ciclo de vida de los modelos de machine learning

Resumen

En este trabajo se tratará las razones porque las que es necesario el uso de MLOps (Machine Learning Operation) para realizar desarrollos de Machine Learning (ML). Para ello se justificará históricamente su aparición, se describirá como metodología, se seleccionará la herramienta que se crea más adecuada para el problema propuesto, se definirá una arquitectura para soportarla, se definirá la metodología específica que se ha diseñado y se aplicará a un caso de uso. Finalmente se estudiará su impacto y deficiencias. La inteligencia artificial (IA) durante su historia ha tenido épocas álgidas y otras más discretas (inviernos de la IA). Por lo que su desarrollo hasta los últimos años ha sido más lento, y por lo tanto no se contaba con metodologías específicas de desarrollo. MLOps es la extensión de DevOps para ML. DevOps una metodología de desarrollo ágil, basada en la división entre el entorno de desarrollo y él de producción, la integración y entrega continua (CI/CD). MLOps añade estas ideas a los desarrollos de ML. Para lograr esto se ha de automatizar las fases de un desarrollo de ML. La limpieza y preparación de datos han de ser recogidas en un pipeline que permita la preparación de datsets, lo mismo ocurre con los entrenamientos. Se ha de añadir un sistema para dar replicabilidad y trazabilidad a todos los experimentos realizados y a los modelos generados como salida. La puesta en producción de los modelos se realizará sobre servicios web que monitoricen la calidad de los modelos en el tiempo. En el caso de que la calidad de los modelos disminuya es necesario la reactivación de los pipelines para la generación de nuevos modelos. MLOps tiene varios niveles: 0, 1, 2. EL nivel 0 todo ha realizarse de manera manual, no hay nada automatizado, con el único elemento propio de MLOps que se cuenta es con su herramienta para la gestión de entrenamientos y de modelos. En el nivel 1 ya existe una gestión automatizada de los pipelines de datos es decir los entrenamientos y preparación de datos, aunque su activación sigue siendo manual. En el nivel 3 se automatiza la activación de los pipelines de datos, es decir se crean los pipelines de CI/CD. Para seleccionar la herramienta que gestionará los modelos y entrenamientos se realizará un estudio sobre las herramientas disponibles. Existe una gran selección de herramientas cada una teniendo sus ventajas e inconvenientes propios. Se ha optado por elegir MLflow una herramienta de código abierto, con mucho énfasis en la flexibilidad y una comunidad de desarrollo activa. Además, es usada para realizar tareas de MLOps en otras plataformas ML más amplias como puede ser Data Bricks. Su nivel MLOps es 0 pero con otras herramientas como ETLs (Extract, Transform, Load) puede incrementar su nivel. Para el despliegue de MLflow se ha optado por un despliegue in-premise medianI te contenedores Docker, uno por cada microservicio que sea necesario. MLflow en cuanto a su arquitectura está formado por tres partes, el servidor de MLflow, una base de datos para el almacenamiento de los parámetros y métricas de los entrenamientos y un sistema de ficheros distribuidos que almacene los artefactos, para los ficheros relacionados con los entrenamientos, incluyendo el propio modelo. MLflow y el gestor de bases de datos seleccionado, PostgreSQL son desplegados desde contenedores Docker, mientras el sistema de ficheros se almacena en un NAS y se comparte por NFS (para sistemas UNIX) y SMB (para sistemas Windows). Todos los componentes que almacenan datos son sometidos a back-ups periódicamente. Una vez seleccionada la herramienta es necesario realizar diseñar una metodología que siga MLOps que se adapte a la herramienta. Se seguirán los mismos pasos que los definidos por MLOps. Primero se ha de describir el problema, después limpiar y preparar los datos, estas dos ultimas han de ser automatizadas. Después se ha de realizar los experimentos para generar los modelos, esto se divide en ejecuciones, de cada ejecución se ha de registrar parámetros, métricas, artefactos, modelo, entrada y salida del modelo, código de entrenamiento y datasets. Después se ha de seleccionar el modelo con respecto a las métricas, exponerlo como servicio y monitorizar su precisión. En el caso de que decaiga se ha de volver a ejecutar los pipelines que preparan los datos y realizan los entrenamientos, elegir el nuevo modelo y volver a ponerlo en producción sustituyendo el antiguo. Esto será ejemplificado con un desarrollo. Por último, se revisará el impacto y deficiencias de la metodología producida. El impacto esperado es una reducción de los tiempos de desarrollo, la cantidad repeticiones necesarias para encontrar el modelo óptimo. Aunque en cuanto a sus deficiencias si que cabe resaltar que al no tener un nivel de MLOps 0 o 1 esas automatizaciones recaen en los usuarios o en otras herramientas.

ABSTRACT

This project will cover the reasons why MLOps (Machine Learning Operations) should be implemented in ML (Machine Learnings) developments. In order to achieve these goals, MLOps would be justified from an historical point of view and the methodology itself is going to be described. Followingly, the most adequate tool would be selected, and the architecture produce to sustain it would be described. Using all of the previous elements a specific methodology would set in place and test. Finally, the impact and deficiencies would be studied. In the history of Artificial Intelligence (AI) there has been high and low moments (AI winters). Until the most recent years AI had not had a specific methodology to itself. MLOps is an extension to DevOps (Develop Operations). DevOps is an agile methodology, based on the division between development and production environments and continuous integration and deployment (CI/CD). MLOps brings these ideas into ML developments. The process of cleaning and preparing the data must be integrated into a pipeline, as well as the training processes. A system to provide traceability and replicability, for the experiments that took place and the models produced, has to be put in place. Moving into the production side the models should be expose as web services. In the case of model quality decline a trigger should restart all the processes in order to obtain new models. MLOps has the following levels: 0, 1 and 2. In the level 0 everything has to be done manually, there is nothing automated. The only element from MLOps that is present is the tool to mange training and models. In the level 1 the automatic management of pipelines of training and data appear, although its activations keep being manual. The last level provides automatization of the activation of data pipelines, i.e., the CI/CD pipelines. Successively, a study of the available tools to perform the management of the models and the training processes. There is a great selection of tools each one with its own set of advantages and drawbacks. MLflow, an open-source tool, has been selected for its emphasis on flexibility, its active developer community. Moreover, MLflow is used as MLOps tool in other ones much more brought such as Data Bricks. Its MLOps level is 0 although it can be improved external tools such as ETL (Extract, Transform, Load) it can be upgraded. The deployment of MLOps is done in-premise with docker containers, one for each microservice. MLflow architecture is divided into there main parts: MLflow server, a database for storing the parameters and the metrics; and a distributed file system, for files related with trainings, including the model. MLflow and PostgreSQL, the selected data base management system, are deployed as docker III containers, whereas the file system is deployed in a NAS and shared via NFS (for UNIX systems) and SMB (for Windows systems). All the systems that store data are backed-up periodically.