{"id":34134,"date":"2025-05-12T09:29:32","date_gmt":"2025-05-12T07:29:32","guid":{"rendered":"https:\/\/inlab.fib.upc.edu\/?p=34134"},"modified":"2025-05-12T11:08:56","modified_gmt":"2025-05-12T09:08:56","slug":"mlops-integracion-gitlab-mlflow","status":"publish","type":"post","link":"https:\/\/inlab.fib.upc.edu\/es\/articulos\/mlops-integracion-gitlab-mlflow","title":{"rendered":"MLOps: Integraci\u00f3n GitLab-MLflow"},"content":{"rendered":"\n<p>En proyectos de <em>Machine Learning, <\/em>es habitual generar m\u00faltiples versiones de un mismo modelo, desde algunas con simples cambios en hiperpar\u00e1metros, pasando por otras con modificaciones en la estructura o arquitectura del modelo, hasta aquellas que utilizan diferentes conjuntos de datos de entrenamiento. Todo esto puede dar lugar a un elevado n\u00famero de ejecuciones que deben estar gestionadas debidamente.<\/p>\n\n\n\n<p>Una buena organizaci\u00f3n de los distintos modelos, junto con sus m\u00e9tricas y configuraciones, es fundamental para evaluar cu\u00e1l de ellos ofrece un mejor rendimiento y es el que se quiere utilizar, as\u00ed como para facilitar su gesti\u00f3n a lo largo de todo el ciclo de vida del modelo.<\/p>\n\n\n\n<p>Este tipo de gesti\u00f3n forma parte del paradigma MLOps (<em>Machine Learning Operations<\/em>), que incorpora buenas pr\u00e1cticas para implementar y mantener modelos de <em>machine learning<\/em> de forma confiable en producci\u00f3n, manteniendo un historial comprensible de todos los modelos aplicados, indicando los meta-argumentos utilizados y los resultados de los tests de validaci\u00f3n.<\/p>\n\n\n\n<p>Este art\u00edculo explora la funcionalidad de integraci\u00f3n de GitLab junto con MLflow para optimizar el proceso de desarrollo y despliegue de modelos de <em>machine learning<\/em>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">MLflow<a href=\"#_ftn1\" id=\"_ftnref1\">[1]<\/a><\/h2>\n\n\n\n<p>MLflow se trata de una plataforma de c\u00f3digo abierto ideada para dar soporte a los equipos y profesionales de proyectos de <em>machine learning<\/em>, centr\u00e1ndose en el ciclo de vida de los modelos y asegurando la trazabilidad y reproducibilidad de cada fase. MLflow est\u00e1 organizado en 4 componentes distintas, que pueden usarse por separadas o todas ellas conjuntamente. Las componentes son las siguientes:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>MLflow Tracking<\/strong>: se trata de una API que permite mantener un seguimiento de par\u00e1metros, c\u00f3digo y resultados de experimentos de ML. Adem\u00e1s, ofrece una interfaz web interactiva que facilita la comparaci\u00f3n entre ejecuciones.<\/li>\n\n\n\n<li><strong>MLflow Projects<\/strong>: &nbsp;son una convenci\u00f3n para organizar y describir c\u00f3digo de manera que sea reutilizable por compa\u00f1eros o herramientas automatizadas.&nbsp;<\/li>\n\n\n\n<li><strong>MLflow Models<\/strong>: es un formato est\u00e1ndar para empaquetar modelos de Machine Learning facilitando su reutilizaci\u00f3n y despliegue en distintos entornos.<\/li>\n\n\n\n<li><strong>MLflow Model Registry<\/strong>: act\u00faa como un almac\u00e9n de modelos, manteniendo la trazabilidad de estos junto a los par\u00e1metros.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Integraci\u00f3n de GitLab con MLflow<\/h2>\n\n\n\n<p>Recientemente, GitLab, una conocida plataforma que ofrece potentes herramientas de colaboraci\u00f3n y control de versiones, ha incluido la compatibilidad con MLflow, permitiendo el uso de este como backend. De manera similar al c\u00f3digo, permite la publicaci\u00f3n de los modelos<\/p>\n\n\n\n<p>y metadatos asociados, directamente en el registro de GitLab. Adem\u00e1s, los resultados de los modelos se pueden consultar de forma totalmente transparente directamente desde la interfaz web de GitLab.<\/p>\n\n\n\n<p>La integraci\u00f3n es llevada a cabo mediante los componentes <em>Model registry<\/em><a href=\"#_ftn2\" id=\"_ftnref2\">[2]<\/a> y <em>Model experiment tracking<a href=\"#_ftn3\" id=\"_ftnref3\"><strong>[3]<\/strong><\/a><\/em> proporcionados por GitLab y totalmente compatibles con la API de MLflow Tracking, la cual puede ser usada desde el c\u00f3digo mediante MLflow Client<a href=\"#_ftn4\" id=\"_ftnref4\">[4]<\/a>.<\/p>\n\n\n\n<p>El siguiente diagrama ilustra como se lleva a cabo la integraci\u00f3n de GitLab con el componente de MLflow Tracking: el c\u00f3digo registra par\u00e1metros, m\u00e9tricas y artefactos (como el modelo en s\u00ed) mediante la API de MLflow, y estas son almacenadas en GitLab y accesibles y visibles por todo el equipo. Las m\u00e9tricas y metadatos de los experimentos son guardados en la base de datos de GitLab mientras que los artefactos, que son archivos y objetos pesados, son almacenados en el <em>Package registry<\/em> de GitLab.<\/p>\n\n\n\n<figure class=\"wp-block-image aligncenter size-full is-resized\"><img fetchpriority=\"high\" decoding=\"async\" width=\"380\" height=\"508\" src=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-1.png\" alt=\"\" class=\"wp-image-34116\" style=\"width:347px;height:auto\" srcset=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-1.png 380w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-1-224x300.png 224w\" sizes=\"(max-width: 380px) 100vw, 380px\" \/><figcaption class=\"wp-element-caption\">Figure 1. Esquema que muestra el flujo de trabajo de la integraci\u00f3n de GitLab con el componente de MLflow Tracking.<\/figcaption><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Ejemplo de flujo de trabajo<\/h2>\n\n\n\n<p>A continuaci\u00f3n, se muestra un ejemplo de c\u00f3mo funciona el flujo de trabajo para trabajar con modelos de ML aprovechando la integraci\u00f3n de GitLab con MLflow. Sin embargo, primero hace falta distinguir entre los componentes de <em>Model registry<\/em> y <em>Model experiments tracking<\/em> de GitLab.<\/p>\n\n\n\n<p>El componente de <em>Model registry<\/em> sirve como repositorio para la gesti\u00f3n de modelos de aprendizaje autom\u00e1tico a lo largo de su ciclo de vida. Permite comparar versiones de modelos y monitorear su evoluci\u00f3n a lo largo del tiempo.<\/p>\n\n\n\n<figure class=\"wp-block-image aligncenter size-full\"><img decoding=\"async\" width=\"886\" height=\"225\" src=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-2.png\" alt=\"\" class=\"wp-image-34120\" srcset=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-2.png 886w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-2-300x76.png 300w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-2-768x195.png 768w\" sizes=\"(max-width: 886px) 100vw, 886px\" \/><figcaption class=\"wp-element-caption\">Figure 2. Model registry del repositorio GitLab<\/figcaption><\/figure>\n\n\n\n<p>El componente de <em>Model experiment tracking<\/em> de GitLab permite realizar el seguimiento de experimentos de <em>machine learning<\/em> con el cliente de MLflow. Los experimentos est\u00e1n asociados a los modelos guardados en el <em>Model Registry<\/em>. Cuando mediante c\u00f3digo se crea una ejecuci\u00f3n de MLflow de un experimento se puede asociar a un modelo ya registrado en el <em>Model Registry<\/em> o si no se genera uno nuevo adem\u00e1s de su experimento asociado, con nombre \u201c[model]\u201d seguido del nombre del nuevo modelo.<\/p>\n\n\n\n<figure class=\"wp-block-image aligncenter size-full\"><img decoding=\"async\" width=\"886\" height=\"176\" src=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-3.png\" alt=\"\" class=\"wp-image-34123\" srcset=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-3.png 886w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-3-300x60.png 300w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-3-768x153.png 768w\" sizes=\"(max-width: 886px) 100vw, 886px\" \/><figcaption class=\"wp-element-caption\">Figure 3. Model experiments del repositorio GitLab. Creaci\u00f3n de un experimento.<\/figcaption><\/figure>\n\n\n\n<p>Un experimento es una colecci\u00f3n de distintas ejecuciones de modelos comparables entre s\u00ed, normalmente compartiendo el set de par\u00e1metros y de m\u00e9tricas usadas para su evaluaci\u00f3n.<\/p>\n\n\n\n<figure class=\"wp-block-image aligncenter size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"886\" height=\"200\" src=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-4.png\" alt=\"\" class=\"wp-image-34126\" srcset=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-4.png 886w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-4-300x68.png 300w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-4-768x173.png 768w\" sizes=\"(max-width: 886px) 100vw, 886px\" \/><figcaption class=\"wp-element-caption\">Figure 4. Experimento del modelo con una ejecuci\u00f3n.<\/figcaption><\/figure>\n\n\n\n<p>Despu\u00e9s de la ejecuci\u00f3n de un nuevo modelo, los diferentes artefactos, como transformadores, codificadores y el propio modelo, se almacenan en la secci\u00f3n de <em>Artifacts<\/em> dentro del experimento. Mientras tanto, las m\u00e9tricas de entrenamiento (como precision, recall, accuracy, etc.) se registran en la secci\u00f3n de <em>Performance<\/em>.<\/p>\n\n\n\n<figure class=\"wp-block-image aligncenter size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"886\" height=\"651\" src=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-5.png\" alt=\"\" class=\"wp-image-34129\" srcset=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-5.png 886w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-5-300x220.png 300w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2025\/04\/image-5-768x564.png 768w\" sizes=\"(max-width: 886px) 100vw, 886px\" \/><figcaption class=\"wp-element-caption\">Figure 5. Ejecuci\u00f3n del modelo con artefactos y m\u00e9tricas.<\/figcaption><\/figure>\n\n\n\n<p>De esta manera, haciendo uso de la integraci\u00f3n de GitLab con MLflow se puede tener un seguimiento de todos los modelos con sus respectivos experimentos y sus respectivos par\u00e1metros, m\u00e9tricas y artefactos directamente en GitLab, estando disponibles en todo momento.<\/p>\n\n\n\n<p>El componente de <em>Model Registry<\/em> puede ser usado para el despliegue de un modelo en producci\u00f3n. La selecci\u00f3n de la versi\u00f3n del modelo a desplegar sigue siendo un proceso manual basado en la evaluaci\u00f3n de las m\u00e9tricas obtenidas. Cuando el usuario escoja una ejecuci\u00f3n satisfactoria para utilizar como modelo para hacer inferencia, deber\u00e1 ir al experimento en espec\u00edfico y pulsar el bot\u00f3n de <em>promote<\/em> para crear una nueva versi\u00f3n del modelo y esta ser\u00e1 guardada como una nueva versi\u00f3n en el <em>Model Registry<\/em>. Entonces, la versi\u00f3n del modelo que debe ser utilizada para hacer inferencia es la \u00faltima versi\u00f3n disponible en el <em>Model Registry<\/em>.<\/p>\n\n\n\n<p>Aunque tener modelos en el repositorio es extremadamente \u00fatil, tener que cargar el modelo localmente cada vez que se intenta hacer inferencia es poco eficiente, por lo que se puede seguir la estrategia de tener una copia del modelo localmente que se actualice peri\u00f3dicamente o una vez alguien haya creado una nueva versi\u00f3n del modelo.<\/p>\n\n\n\n<p>Cabe mencionar que la integraci\u00f3n de MLflow con GitLab a\u00fan se encuentra en desarrollo y faltan funcionalidades por implementar, por lo que en un futuro podr\u00eda ser posible aplicar mejoras en el proceso de registro y promoci\u00f3n de modelos para su despliegue. Sin embargo, esta integraci\u00f3n ya ofrece una funcionalidad de gran utilidad para tener un seguimiento detallado e hist\u00f3rico de todos los modelos y experimentos de un proyecto, accesibles por todo el equipo en todo momento.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p><a href=\"#_ftnref1\" id=\"_ftn1\">[1]<\/a> <a href=\"https:\/\/mlflow.org\/\">https:\/\/mlflow.org\/<\/a><\/p>\n\n\n\n<p><a href=\"#_ftnref2\" id=\"_ftn2\">[2]<\/a> <a href=\"https:\/\/docs.gitlab.com\/user\/project\/ml\/model_registry\/\">https:\/\/docs.gitlab.com\/user\/project\/ml\/model_registry\/<\/a><\/p>\n\n\n\n<p><a href=\"#_ftnref3\" id=\"_ftn3\">[3]<\/a> <a href=\"https:\/\/docs.gitlab.com\/user\/project\/ml\/experiment_tracking\/\">https:\/\/docs.gitlab.com\/user\/project\/ml\/experiment_tracking\/<\/a><\/p>\n\n\n\n<p><a href=\"#_ftnref4\" id=\"_ftn4\">[4]<\/a> <a href=\"https:\/\/docs.gitlab.com\/ee\/user\/project\/ml\/experiment_tracking\/mlflow_client.html\">https:\/\/docs.gitlab.com\/ee\/user\/project\/ml\/experiment_tracking\/mlflow_client.html<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>En proyectos de Machine Learning, es habitual generar m\u00faltiples versiones de un mismo modelo, desde algunas con simples cambios en hiperpar\u00e1metros, pasando por otras con modificaciones en la estructura o arquitectura del modelo, hasta aquellas que utilizan diferentes conjuntos de datos de entrenamiento. Todo esto puede dar lugar a un elevado n\u00famero de ejecuciones que [&hellip;]<\/p>\n","protected":false},"author":1273,"featured_media":34165,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[496],"tags":[],"experteses":[],"class_list":["post-34134","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-articulos"],"acf":[],"_links":{"self":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts\/34134","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/users\/1273"}],"replies":[{"embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/comments?post=34134"}],"version-history":[{"count":4,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts\/34134\/revisions"}],"predecessor-version":[{"id":34174,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts\/34134\/revisions\/34174"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/media\/34165"}],"wp:attachment":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/media?parent=34134"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/categories?post=34134"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/tags?post=34134"},{"taxonomy":"experteses","embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/experteses?post=34134"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}