El uso de machine learning o aprendizaje máquina en toda organización debería venir acompañado de mejores prácticas que ayuden a que este aporte valor al negocio. Aquí es donde entra MLOps. Sin embargo, la aplicación de estas mejores prácticas no es estándar, dependerá de en qué etapa DATA está la organización. En este blogpost te comentamos cómo aplicarlas en las 3 etapas DATA que reconocemos en ixpantia.
Acompañamos en iniciativas y proyectos de ciencia de datos, ingeniería e infraestructura. Visita nuestra página ixpantia y contáctanos.
En 2007-2008 la comunidad de desarrollo de software y operaciones comienza con DevOps, una forma de trabajar poniendo un marco de referencia de mejores prácticas para dicha industria. Siguiendo la línea de las mejores prácticas, en 2015 (Andy Palmer) llegó DataOps, que busca lo mismo pero enfocado en datos. En este caso, participan distintos perfiles técnicos, prácticas y tecnologías pero el objetivo es el mismo. Dentro de DataOps, siguiendo esta misma idea, llega, en el mismo año MLOps (Hidden Technical Debt in Machine Learning Systems, 2015), mismo objetivo pero aún más especializado, ahora en el ámbito de machine learning o aprendizaje máquina. ¿Que tienen en común las 3? Que ponen énfasis en la importancia de tener una comunicación adecuada en el momento adecuado, en documentación, en gestión de versiones, en tener un proceso definido para llevar productos a producción y procesos de control de calidad.
El costo de no gestionar bien el proceso de desarrollo y puesta en marcha de modelos aprendizaje máquina puede ser alto. Esto sucede porque es la base de la inteligencia artificial que construimos e implementamos en una organización y si no se implementa correctamente, puede significar un gasto de recursos no humanos y tecnológicos o incluso puede llevar a la toma de decisiones incorrectas.
En ixpantia trabajamos con los conceptos de gatear, caminar y correr para hablar de las etapas de madurez data de una organización. La idea detrás de gatear, caminar y correr no es nueva, se ha usado a través de los años para describir las etapas que una persona u organización recorre al avanzar en un proceso complejo. La filosofía detrás es que el éxito de un proceso o aprendizaje complejo no puede suceder de la noche a la mañana, es necesario dar pasos pequeños pero bien dados para irnos acercando a la meta.
Antes de describir los estados de madurez MLOps, es importante aclarar que hay un elemento que debe estar presente en todos: un enfoque en construir una cultura de datos activa y que evoluciona con la organización. Sin una cultura de datos en plena evolución, es difícil pasar de un estado de madurez al otro.
Para comenzar a trabajar con modelos de machine learning tu organización recomendamos primero asegurarse de tener una infraestructura de datos que les respalde. El caso ideal es tener un data warehouse o base de datos estable donde las personas que desarrollan los roles de analistas y/o científicos de datos tengan acceso y hayan datos históricos con los que pueden trabajar. Pero también es posible dar los primeros pasos con archivos estáticos como archivos tipo csv.
Si una organización cumple con lo anterior entonces la siguiente decisión para el desarrollo de su primer modelo de aprendizaje máquina será si utilizar una herramienta no-code o code-based. En ixpantia creemos en la filosofía de “código primero” porque encamina a una organización a las mejores prácticas de MLOps desde un inicio. La selección del lenguaje a utilizar depende mucho de cada organización, si personas en el equipo ya utilizan un lenguaje para otras tareas, pueden comenzar por ese y evaluar otros en el futuro. Una vez elegido el lenguaje, viene la etapa de entrenar modelo, versionarlo y ofrecerlo a las personas interesadas para hacer predicciones. Una buena forma de hacer esto es llevarlo a un API. Esto se puede hacer a mano y desde cero o bien, utilizar una herramienta como vetiver. Este proyecto propone un proceso de versionamiento, despliegue y monitoreo de modelos y las librerías necesarias están disponibles tanto para R como para Python.
Al utilizar este marco de trabajo, automáticamente vas a adoptar e implementar mejores prácticas. Por lo tanto, si aún no conoces cuáles son estas prácticas, vetiver ofrece una forma fácil y rápida de introducirlas y seguirlas. Aquí se le da un énfasis especial a la documentación del proceso y modelo como tal. Usando este método de trabajo, creamos un producto que promueve la interoperabilidad en la organización desde el inicio. Para el despliegue como tal, si el equipo no tiene procesos de despliegue de productos de software como parte de su día a día, se pueden utilizar plataformas como Posit Connect. Pero hay alternativas del lado más técnico que reducen el impacto sobre el presupuesto.
En la siguiente etapa, tu organización ya tiene un modelo en producción y ahora necesita un proceso para re-entrenar, re-desplegar y hacer rollback en caso de un despliegue erróneo (o de un modelo que no se comporta bien en el proceso). En esta etapa es importante hacer un énfasis en documentación y establecer protocolos para todos las partes del proceso. Esta documentación (y protocolos) debe tomar en cuenta el público al que pretende satisfacer (desde tomadores de decisiones hasta desarrolladores o ingenieros de ML) y adaptar el lenguaje y narrativa acorde. Para mejores practicas de documentacion puedes referirte a nuestro blogpost que habla al respecto.
Idealmente en esta etapa el despliegue se hace más a la medida de la organización en específico. Si antes estaban utilizando el proceso de despliegue estándar de vetiver por ejemplo, en lugar de utilizar el API determinado por vetiver, pueden usar machotes a medida. Esto requiere más trabajo de parte del equipo que desarrolla pero el producto final se puede adaptar a las condiciones específicas de la organización, tanto en términos técnicos como de negocio. Es difícil que un proceso tan estandarizado se acomode a todas las organizaciones. En este proceso manual se pueden configurar elementos como la autentificación o acceso diferenciado, todo a medida.
En esta etapa también incrementa la necesidad de interoperar con otros sistemas. Aquí es donde los contratos de servicios (SLAs) y de microservicios son de gran ayuda. En estos contratos describimos la solución que implementamos, los sistemas involucrados, lo que esperamos de estos sistemas en términos de desempeño, y por otro lado, las características, endpoints y uso del API que construimos. Crear buenos contratos de este tipo ayuda a una interoperabilidad eficiente y a que las partes involucradas tengan claro lo que se espera de cada elemento en el sistema.
Ahora imagínate que en tu organización ya hay 100 modelos activos, y cada modelo está en una etapa de vida diferente ¿cómo logramos desarrollar, desplegar, monitorear y mantener tantos modelos a la vez? Para esta pregunta no hay una sola respuesta, depende de cada organización.
En esta etapa es necesario que tengamos procesos definidos para reentrenar los modelos en producción en ciclos claramente definidos. La necesidad de negocio y la realidad de los datos dicta cuándo y con cuáles datos reentrenamos los modelos. Lo importante es definir un protocolo claro, donde las responsabilidades de personas y sistemas queden claras, así como la periodicidad y otros detalles de importancia. Por otro lado, es necesario también tener un proceso de monitoreo constante del desempeño de los modelos en producción. En este proceso es importante monitorear el desempeño estadístico, con métricas como AUC y la precisión así como el model drift, además, monitoreamos el desempeño técnico de la solución de despliegue, donde chequeamos tiempos de respuesta, tiempo de carga de datos, etc.
En esta etapa los esfuerzos de reliability engineering, de los cuales hablamos arriba,ya han culminado en acuerdos de servicios claros, con indicadores y objetivos de servicio claramente definidos y siendo monitoreados de forma regular. “Correr” en MLOps también implica pensar en protocolos para la creación de nuevos modelos, no solo el mantenimiento y monitoreo de modelos existentes. El negocio debería tener claro cómo formular y comunicar su necesidad de nuevos modelos predictivos de forma clara para el equipo que los desarrollará. Y del lado del equipo de desarrollo, debe estar claro el tiempo de preguntas que deben hacer para resolver problemas, mejorar modelos existentes y añadir valor de vuelta al negocio.
Y por último, es necesario que las consideraciones éticas del uso de inteligencia artificial en la organización han sido documentadas y son tomadas en cuenta dentro del proceso de desarrollo y puesta en marcha de modelos de aprendizaje máquina. Y esta documentación es revisada con cierta periodicidad para actualizar si nuevas consideraciones o métodos para su aplicación han surgido.
Desarrollar un modelo no es difícil, desplegar un modelo siguiendo buenas prácticas tampoco lo es. El reto más grande está en lograr que esos modelos sean aprovechados en la organización y que su calidad y aporte de valor esté bajo monitoreo continuo. En ixpantia te podemos ayudar no importa en cual etapa estés.
Este blog lo mantiene el equipo de ixpantia y la comunidad de gente interesada en datos de la cual estamos contentos de formar parte ¿Tienes una idea para publicar algo aquí? ¡Escríbenos! Estamos siempre interesados en material e ideas nuevas. © 2019-2022 ixpantia