La IA o las aplicaciones de aprendizaje automático están en boca de todos desde hace unos años y esta tecnología conquista cada vez más sectores. Los algoritmos y la cantidad y calidad de los datos disponibles para los modelos de aprendizaje automático ya están avanzados. Pero la profesionalización de las operaciones va a la zaga. Mientras tanto, se ha establecido un nuevo enfoque para facilitar el uso productivo del aprendizaje automático: MLOps, compuesto de aprendizaje automático (ML) y operaciones (Ops). MLOps es un conjunto de métodos y herramientas de software cuyo objetivo es garantizar el uso operativo de las aplicaciones de IA. Aclaramos el tema de MLOps y abordamos estas cuestiones fundamentales:

• ¿Qué significa MLOps en detalle?
• ¿En qué se diferencia MLOps de DevOps?
• ¿Cuáles son los retos operativos de los productos ML que se resuelven con MLOps?

¿Qué es exactamente MLOps?

El uso profesional del aprendizaje automático está en expansión: Más del 50 por ciento de las empresas ya utilizan el aprendizaje automático de forma productiva. Al mismo tiempo, las empresas y los científicos de datos, ingenieros y gestores de productos implicados observan que el funcionamiento productivo está resultando complicado, normalmente más de lo esperado. Gartner ha determinado que sólo 54% de los proyectos de ML habrán llegado a la operación productiva en 2022 [1]. E incluso si consiguen llegar a la producción, el tiempo de comercialización es elevado: en casi la mitad de los casos, los equipos emplean más de 30 días en poner en producción un modelo acabado [2].

La respuesta al desarrollo ineficaz de productos ML es MLOps. MLOps es un conjunto de métodos y tecnologías para diseñar eficazmente el desarrollo de modelos de aprendizaje automático y el uso operativo de productos basados en ellos. Cuando se desarrolla un producto de ML, se distinguen 3 pasos: Diseñar, Construir y Ejecutar.

Con marcos maduros para el procesamiento de datos (Pandas, Spark y otros), aprendizaje automático (PyTorch, Scikit-Learn, etc.) y ofertas en la nube, los dos primeros pasos son bien manejables hoy en día con una complejidad baja o media de un producto de ML. Después, sin embargo, surgen los verdaderos retos. El modelo desplegado debe supervisarse, mantenerse y optimizarse. Y una vez que se ha "completado" el desarrollo de un primer producto de ML, los planes para las siguientes ideas de productos de ML suelen estar ya en los tacos de salida. Por lo tanto, el esfuerzo que se aleja del puro desarrollo de canalizaciones de datos y aprendizaje automático aumenta constantemente. La coordinación de equipos cada vez más numerosos y el mantenimiento del cumplimiento también se interponen en el camino para escalar con éxito el uso del aprendizaje automático.

Desarrollar e implantar sistemas de ML es relativamente rápido y barato, pero mantenerlos a lo largo del tiempo es difícil y caro.

D. Sculley et al, "Deuda técnica oculta en los sistemas de aprendizaje automático, 2015".

Los métodos y el software MLOps son, por tanto, soluciones para reducir la deuda técnica causada por los productos de ML. Lo más importante que hay que recordar es que los métodos MLOps y la colaboración eficaz son el centro de atención y que la elección de la pila tecnológica es secundaria. La clave del éxito es, tener ya una idea concreta de cómo se va a operativizar el modelo desde el inicio del desarrollo de un modelo de ML (fase de diseño). O dicho de otro modo, lo ideal es aplicar la metodología MLOps desde el principio del proyecto.

¿Necesita ayuda con sus proyectos MLOps? Desde la formación y el análisis de madurez hasta el desarrollo completo y el mantenimiento de productos MLOps, Alexander Thamm GmbH ofrece a sus clientes una amplia gama de servicios en el campo de MLOps. Obtenga más información en nuestra página de servicios y póngase en contacto con nosotros en cualquier momento para una consulta sin compromiso:

Las plataformas MLOps ayudan a aumentar la colaboración en equipo, cumplir los requisitos normativos y de conformidad y reducir el tiempo de comercialización. Más información en nuestro artículo sobre el tema:

Plataforma MLOps: creación, ampliación y puesta en marcha

¿Qué retos resuelve MLOps?

Si MLOps pretende reducir la deuda técnica, ¿qué significa exactamente? Entendemos por tal los obstáculos organizativos y tecnológicos que repercuten negativamente en la productividad y los costes, pero que son evitables. Estos son los problemas elementales recurrentes en la operacionalización del aprendizaje automático:

Esfuerzo manual excesivo para la formación y el mantenimiento

Un modelo de ML suele basarse en datos del mundo real y cambia constantemente. Por lo tanto, los modelos de ML se quedan obsoletos rápidamente y es necesario volver a entrenarlos con regularidad. En un entorno no optimizado, el esfuerzo resultante puede inmovilizar cantidades significativas de tiempo de trabajo. Veamos un ejemplo ficticio: un equipo de científicos de datos e ingenieros dedica unas 20 horas al mes a mantener en funcionamiento un único modelo ML. Este esfuerzo se debe a un bajo nivel de automatización del procesamiento de datos, el ajuste del modelo y el despliegue de nuevos modelos. El producto ML en sí es un éxito y más tarde se introducen un segundo producto ML y un segundo modelo. Debido a la falta de automatización y sinergias, el esfuerzo mensual es ahora de 40 horas. Por cierto, esto se refiere al cuidado y mantenimiento de los modelos ML en sentido estricto. Las 20 o 40 horas mensuales no fluyen hacia la mejora de los productos, se trata exclusivamente de eso, Mantener el statu quo. Si se piensa en esta situación con más detenimiento, la mera explotación de más modelos en algún momento inmovilizaría a toda una plantilla, hasta el punto de que no quedaría capacidad alguna disponible para el nuevo y ulterior desarrollo de productos ML.

También es importante tener en cuenta que la automatización en el desarrollo del aprendizaje automático es una documentar el efecto tiene, al igual que ocurre con las herramientas DevOps. Incluso si un grupo de productos de ML puede ser gestionado por un puñado de miembros del equipo, esto seguirá funcionando tan pronto como estos miembros abandonen o dejen el proyecto (palabra clave "Factor bus")?

Falta de rentabilidad en la formación y el funcionamiento del ML

El aprendizaje automático puede ser caro, especialmente cuando se basa en GPU. En las grandes empresas, el coste mensual de las capacidades informáticas para el entrenamiento y el funcionamiento de los modelos oscila entre cuatro y cinco cifras. Resulta aún más molesto cuando los recursos de hardware se malgastan debido a una arquitectura ineficaz o una configuración defectuosa. De este modo, se desaprovecha el potencial de ahorro. Los desencadenantes típicos son las instancias de GPU que funcionan en vacío debido a un escalado ineficaz o a un entrenamiento redundante de los modelos, aunque no se produzcan cambios en los datos o parámetros de entrada. Este problema también puede darse en una infraestructura on-prem, con la consiguiente pérdida de tiempo de cálculo.

Falta de conocimiento sobre el rendimiento de un modelo ML

Los modelos de ML son estocásticos, no deterministas. Los datos subyacentes se desactualizan rápidamente (deriva de datos) y debe controlarse continuamente si las predicciones producidas cumplen la calidad requerida, especialmente entre actualizaciones del modelo (deriva de modelos). En cualquier caso, deben definirse KPI que cuantifiquen el rendimiento de un producto de ML. Pueden ser afirmaciones clásicas sobre la precisión, como la especificidad o la sensibilidad, si son determinables. Alternativamente, también son posibles el número de clics, la tasa de compromiso, el número de incidentes, etc.

Mientras sólo haya unos pocos modelos en funcionamiento y su rendimiento pueda registrarse manualmente tras el despliegue de nuevos modelos, la automatización no es necesariamente necesaria en este punto. Sin embargo, en cuanto aumenta el número de modelos en producción o la frecuencia de despliegue, se hace necesaria la supervisión automatizada del rendimiento, o volvemos al problema 1 y el esfuerzo manual alcanza un nivel inaceptable.

Responsabilidades poco claras y falta de eficacia en la cooperación

Este problema es de naturaleza organizativa. Un equipo en torno a un nuevo producto de ML puede empezar con unas pocas personas para preparar los datos y entrenar los modelos de ML. Para estos y todos los procesos posteriores, es necesario definir claramente las responsabilidades o surgirán muchas preguntas, por ejemplo:

• ¿Quién se encarga del funcionamiento operativo del modelo?
• ¿Quién garantiza que un modelo cumple los requisitos, tanto en el momento del lanzamiento como 6 meses después? Si los requisitos se definieron claramente de antemano.
• ¿Quién comprueba si los datos suministrados para la formación desde una base de datos o API son completos y correctos?

Incluso en la era de DevOps y compañía, ocurre con demasiada frecuencia que los científicos de datos tiran sus modelos entrenados por encima de la valla metafórica y apenas participan en operaciones productivas. En los equipos interfuncionales, es importante que las responsabilidades estén claramente definidas. Además, en la medida de lo posible, deben utilizarse pilas tecnológicas uniformes en todos los productos de ML, es decir, herramientas idénticas para el versionado, el almacenamiento de artefactos, la entrega del modelo, etc.. De lo contrario, cada equipo tendrá que gestionar sus propias herramientas, lo que lleva mucho tiempo.

Incertidumbre sobre las medidas de cumplimiento y el RGPD

Todas las empresas deben cumplir normativas externas, como el Reglamento General de Protección de Datos europeo (RGPD), así como directrices de cumplimiento internas. Lamentablemente, los responsables de cumplimiento y protección de datos no suelen participar hasta una fase tardía del proceso de desarrollo del producto, si es que lo hacen. En cuanto surge la incertidumbre sobre si un producto de protección de datos cumple toda la normativa pertinente, en el peor de los casos, debe suspenderse su usoaunque en realidad no se haya producido ninguna infracción. En particular, si un producto tiene que estar fuera de servicio hasta que se haya verificado el cumplimiento de la normativa legal, las pérdidas de facturación y productividad pueden ser enormes. Hay que dejar claro aquí que la tecnología por sí sola no puede resolver estos requisitos. Solo un ser humano puede evaluar si un producto ML cumple o no los requisitos del GDPR o las normativas específicas del sector. Sin embargo, una pila tecnológica uniforme permite una evaluación más rápida del cumplimiento que 10 soluciones individuales para 10 productos de ML. Si existe una infraestructura de ML homogénea y los responsables de cumplimiento y protección de datos participan en una fase temprana, los procesos de toma de decisiones se acortan y los riesgos de cumplimiento se minimizan.

Conclusión

Las organizaciones que pretendan utilizar varios productos de ML deben aplicar sistemáticamente la filosofía MLOps lo antes posible, preferiblemente desde el principio. Aplicar MLOps a posteriori es factible, pero resulta más complejo. Sin embargo, ya sea desde el principio o más tarde, las organizaciones que aplican MLOps consiguen mejoras significativas en su proyecto - y en el 97% de los casos [3]. Sin embargo, es probable que los obstáculos normativos aumenten bruscamente en breve. En 2023 o 2024, se espera que la Reglamento europeo sobre IA entren en vigor. Para entonces, a más tardar, el cumplimiento ya no será sólo un requisito abstracto, sino que corresponderá a una base jurídica concreta que deberá cumplir todo producto de LD utilizado comercialmente.

Pero, ¿cómo se implementa MLOps en la práctica? Pronto descubrirá cómo los equipos implementan MLOps de forma significativa, qué herramientas son necesarias para ello y cuáles no tanto. en la segunda parte de nuestro especial MLOps.

Términos: DevOps vs. DataOps vs. MLOps

Ha surgido una verdadera confusión de términos sobre el tema de las operaciones y el aprendizaje automático. Aquí clasificamos los términos.

• DevOps: Describe la convergencia del desarrollo (Dev) y las operaciones (Ops) con la ayuda de prácticas que reducen el esfuerzo necesario para trasladar los cambios en el software a un funcionamiento productivo. En la práctica, para DevOps se utilizan técnicas como contenedores, infraestructura como código e integración continua (CI). DevOps describe métodos generales para lograr una alta eficiencia en el funcionamiento del software y no está específicamente adaptado al aprendizaje automático, la IA o el procesamiento de grandes cantidades de datos.
• DataOps: DataOps incluye todos los métodos de DevOps, ampliados con métodos en torno al procesamiento eficiente y la integración de (grandes) cantidades de datos. Esto suele incluir la implementación de canalizaciones de datos, incluida la supervisión de canalizaciones y la gestión de incidencias. El término "DataOps" se utiliza con menos frecuencia, ya que "MLOps" se ha convertido en la palabra clave aceptada para describir los aspectos operativos del aprendizaje automático y el procesamiento de datos necesario para ello.
• MLOps: Conjunto de métodos y herramientas para la creación y el funcionamiento eficientes de modelos de aprendizaje automático y productos basados en ellos. Así pues, MLOps incluye todos los aspectos de DevOps y DataOps y, por tanto, es la más compleja de estas disciplinas.

Además, términos como "ModelOps" o "AIOps" pueden encontrarse en la web y ocasionalmente en la literatura. Pueden considerarse equivalentes a MLOps.

Fuentes:

[1] https://www.gartner.com/en/newsroom/press-releases/2022-08-22-gartner-survey-reveals-80-percent-of-executives-think-automation-can-be-applied-to-any-business-decision 
[2] https://cdn2.hubspot.net/hubfs/2631050/0284%20CDAO%20FS/Algorithmia_2020_State_of_Enterprise_ML.pdf , p.12
[3] https://pages.barc.de/hubfs/Marketing/Reports/Report_Driving-Innovation-with-AI.pdf, p.10 
[4] Sculley, D. et al. (2015). Deuda técnica oculta en sistemas de aprendizaje automático. En Avances en sistemas de procesamiento neuronal de la información