Marco de las operaciones de Machine Learning (MLOps) para escalar el ciclo de vida de aprendizaje automático con Azure Machine Learning

Este proyecto cliente ayudó a una empresa alimentaria Fortune 500 a mejorar su previsión de la demanda. La empresa envía productos directamente a varios puntos de venta al por menor. La mejora les ayudó a optimizar las existencias de sus productos en diferentes almacenes de varias regiones de EE. UU. Para lograrlo, el equipo de ingeniería de software comercial (CSE) de Microsoft trabajó con los científicos de datos del cliente en un estudio piloto para desarrollar modelos de Machine Learning personalizados para las regiones seleccionadas. Los modelos tienen en cuenta:

• Datos demográficos de los compradores
• Historial y pronóstico meteorológicos
• Envíos pasados
• Devoluciones de productos
• Eventos especiales

El objetivo de optimizar las existencias representaba un componente importante del proyecto y el cliente logró un aumento de ventas importante en las primeras pruebas de campo. Además, el equipo experimentó una reducción del 40 % en el error de porcentaje absoluto medio (MAPE) de la previsión al compararlo con un modelo de base de referencia de la media histórica.

Una parte importante del proyecto era descubrir cómo escalar verticalmente el flujo de trabajo de ciencia de datos del estudio piloto a un nivel de producción. Este flujo de trabajo de nivel de producción requería al equipo de CSE:

• Desarrollar modelos para muchas regiones.
• Actualizar y supervisar constantemente el rendimiento de los modelos.
• Facilitar la colaboración entre los equipos de datos y de ingeniería.

El flujo de trabajo de ciencia de datos típico de hoy en día se aproxima más a un entorno de laboratorio único que a un flujo de trabajo de producción. Un entorno para los científicos de datos debe ser adecuado para que puedan:

• Preparar los datos.
• Experimentar con diferentes modelos.
• Ajustar los hiperparámetros.
• Crear un ciclo de compilación, prueba, evaluación y perfeccionamiento.

La mayoría de las herramientas que se usan para estas tareas tienen fines específicos y no son adecuadas para la automatización. En una operación de aprendizaje automático de nivel de producción, se debe tener más en cuenta la administración del ciclo de vida de las aplicaciones y DevOps.

El equipo de CSE ayudó al cliente a escalar verticalmente la operación a los niveles de producción. Implementaron varios aspectos de las funcionalidades de integración continua y entrega continua (CI/CD) y abordaron problemas como la observabilidad y la integración con las funcionalidades de Azure. Durante la implementación, el equipo descubrió brechas en las instrucciones de MLOps existentes. Esas brechas tuvieron que repararse para que MLOps se entendiera mejor y se aplicara a gran escala.

Comprender las prácticas de MLOps ayuda a las organizaciones a garantizar que los modelos de Machine Learning generados por el sistema son modelos con calidad de producción que mejoran el rendimiento empresarial. Al implementar MLOps, la organización ya no tiene que centrarse tanto tiempo en los mínimos detalles relacionados con la infraestructura y el trabajo de ingeniería necesarios para desarrollar y ejecutar modelos de Machine Learning para las operaciones de nivel de producción. La implementación de MLOps también ayuda a las comunidades de ciencia de datos e ingeniería de software a aprender a trabajar juntos para ofrecer un sistema listo para producción.

El equipo de CSE usaba este proyecto para abordar las necesidades de la comunidad de aprendizaje automático mediante la gestión de problemas como el desarrollo de un modelo de madurez de MLOps. Estos esfuerzos estaban dirigidos a mejorar la adopción de MLOps al comprender los desafíos típicos de los actores clave en el proceso de MLOps.

Escenarios de involucración del usuario y técnicos

En el escenario de involucración del usuario se describen los desafíos reales que el equipo de CSE debía resolver. El escenario técnico define los requisitos para crear un ciclo de vida de MLOps tan confiable como el reconocido ciclo de vida de DevOps.

Escenario de involucración

El cliente entrega los productos directamente a tiendas menoristas siguiendo una programación regular. Cada tienda minorista varía en los patrones de uso de los productos, de modo que el inventario debe variar en cada entrega semanal. Maximizar las ventas y minimizar las devoluciones de productos y las oportunidades de venta perdidas son los objetivos de las metodologías de previsión de la demanda que el cliente emplea. Este proyecto se centra en el uso del aprendizaje automático para mejorar las previsiones.

El equipo de CSE dividió el proyecto en dos fases. La fase 1 se centró en el desarrollo de modelos de Machine Learning para admitir un estudio piloto de campo sobre la eficacia de la previsión del aprendizaje automático en una región de ventas seleccionada. El éxito de la fase 1 llevó a la fase 2, en la que el equipo escaló verticalmente el estudio piloto inicial a partir de un grupo mínimo de modelos que admitieron una sola región geográfica a un conjunto de modelos de nivel de producción sostenible para todas las regiones de ventas del cliente. Una de las principales consideraciones de la solución escalada verticalmente era la necesidad de acomodar el gran número de regiones geográficas y sus tiendas minoristas locales. El equipo dedicó los modelos de Machine Learning a tiendas minoristas grandes y pequeñas de cada región.

En la fase 1 del estudio piloto se determinó que un modelo dedicado a las tiendas minoristas de una región podía usar el historial de ventas local, los datos demográficos locales, el tiempo y los eventos especiales para optimizar la previsión de los comercios de la región. Cuatro modelos de previsión de aprendizaje automático de conjunto sirvieron a las tiendas de una sola región. Los modelos procesaron los datos en lotes semanales. Además, el equipo desarrolló dos modelos de base de referencia con datos históricos para la comparación.

Para la primera versión de la solución de fase 2 escalada verticalmente, el equipo de CSE seleccionó 14 regiones geográficas para participar, que incluyeron grandes y pequeños comercios. Usaron más de 50 modelos de previsión de aprendizaje automático. El equipo esperaba un mayor crecimiento del sistema y un perfeccionamiento continuo de los modelos de Machine Learning. Pronto quedó claro que esta solución de aprendizaje automático a mayor escala solo podía ser sostenible si se basaba en los principios de los procedimientos recomendados de DevOps para el entorno de aprendizaje automático.

Entorno	Región del mercado	Formato	Modelos	Subdivisión del modelo	Descripción del modelo
Entorno de desarrollo	Cada región o mercado geográfico (por ejemplo, el norte de Texas)	Grandes almacenes (supermercados, grandes superficies, etc.)	Dos modelos de conjunto	Productos de baja rotación	Tanto la baja como la alta rotación tienen un conjunto formado por un modelo de regresión lineal LASSO (Least Absolute Shrinkage and Selection Operator) y una red neuronal con inserciones de categorías.
				Productos de alta rotación	Tanto la baja como la alta rotación tienen un conjunto formado por un modelo de regresión lineal LASSO y una red neuronal con inserciones de categorías.
			Un modelo de conjunto	N/D	Media histórica
		Comercios pequeños (farmacias, ultramarinos, etc.)	Dos modelos de conjunto	Productos de baja rotación	Tanto la baja como la alta rotación tienen un conjunto formado por un modelo de regresión lineal LASSO y una red neuronal con inserciones de categorías.
				Productos de alta rotación	Tanto la baja como la alta rotación tienen un conjunto formado por un modelo de regresión lineal LASSO y una red neuronal con inserciones de categorías.
			Un modelo de conjunto	N/D	Media histórica
	Igual que el caso anterior para las otras 13 regiones geográficas
Igual que el anterior para el entorno de producción

El proceso de MLOps proporcionó un marco para el sistema de escalado vertical que dirigió todo el ciclo de vida de los modelos de Machine Learning. El marco incluye desarrollo, pruebas, implementación, operación y supervisión. Satisface las necesidades de un proceso clásico de CI/CD. Sin embargo, debido a su inmadurez relativa en comparación con DevOps, resultó evidente que había brechas en la guía de MLOps existente. El equipo del proyecto trabajó para reparar algunas de esas brechas. Querían proporcionar un modelo de proceso funcional que garantizara la viabilidad de la solución de aprendizaje automático escalada.

El proceso de MLOps que se desarrolló a partir de este proyecto realizó un importante paso real para trasladar MLOps a un nivel mayor de madurez y viabilidad. El nuevo proceso es aplicable directamente a otros proyectos de aprendizaje automático. El equipo de CSE usó lo que aprendió para crear un borrador de un modelo de madurez de MLOps que cualquiera pueda aplicar a otros proyectos de aprendizaje automático.

Escenario técnico

MLOps, también conocido como DevOps para el aprendizaje automático, es un término general que abarca filosofías, procedimiento y tecnologías relacionadas con la implementación de ciclos de vida de aprendizaje automático en un entorno de producción. Sigue siendo un concepto relativamente nuevo. Ha habido muchos intentos de definir MLOps y muchas personas han cuestionado si MLOps puede subsumir todo, desde cómo los científicos de datos preparan los datos a la manera en que, en última instancia, entregan, supervisan y evalúan los resultados del aprendizaje automático. Mientras que DevOps ha tenido años para desarrollar un conjunto de prácticas fundamentales, MLOps es un enfoque muy nuevo. A medida que evoluciona, detectamos los desafíos de reunir dos disciplinas que suelen funcionar con diferentes conjuntos de aptitudes y prioridades: ingeniería de software/operaciones y ciencia de datos.

La implementación de MLOps en entornos de producción reales presenta desafíos únicos que deben superarse. Los equipos pueden usar Azure para admitir patrones de MLOps. Azure también puede proporcionar a los clientes servicios de orquestación y administración de recursos para una administración eficaz del ciclo de vida de aprendizaje automático. Los servicios de Azure son la base de la solución de MLOps que se describe en este artículo.

Requisitos de los modelos de Machine Learning

Gran parte del trabajo realizado durante la fase 1 del estudio de campo piloto implicaba la creación de modelos de Machine Learning que el equipo de CSE aplicó a tiendas minoristas grandes y pequeñas de una sola región. Los requisitos destacados del modelo incluían:

• Uso de Azure Machine Learning Service.

• Modelos experimentales iniciales desarrollados en Jupyter Notebook e implementados en Python.

  Nota:

  Los equipos usaban el mismo enfoque de aprendizaje automático para tiendas grandes y pequeñas, pero los datos de entrenamiento y puntuación dependían del tamaño de la tienda.

• Preparación de los datos para el consumo del modelo.

• Procesamiento de datos por lotes en lugar de en tiempo real.

• Entrenamiento del modelo cada vez que cambia el código o los datos, o el modelo queda obsoleto.

• Visualización del rendimiento del modelo en paneles de Power BI.

• Rendimiento del modelo en la puntuación considerada importante cuando MAPE <=45 % en comparación con un modelo de base de referencia de la media histórica.

Requisitos de MLOps

El equipo tenía que cumplir varios requisitos clave para escalar verticalmente la solución desde la fase 1 del estudio piloto, en la que solo se desarrollaron algunos modelos para una sola región de ventas. En la fase 2 se implementaron modelos de aprendizaje automático personalizados para varias regiones. La implementación incluyó:

• Procesamiento por lotes semanal para tiendas grandes y pequeñas en cada región para volver a entrenar los modelos con nuevos conjuntos de datos.

• Perfeccionamiento continuo de los modelos de Machine Learning.

• Integración del proceso de desarrollo, pruebas, paquetes e implementación común para CI/CD en un entorno de procesamiento similar a DevOps para MLOps.

  Nota

  Esto representa un cambio en la forma en que los científicos de datos y los ingenieros de datos solían trabajar en el pasado.

• Un modelo único que representaba cada región para tiendas grandes y pequeñas basado en el historial de las tiendas, los datos demográficos y otras variables clave. El modelo tenía que procesar todo el conjunto de datos para minimizar el riesgo de error de procesamiento.

• La capacidad de escalado vertical inicial para admitir 14 regiones de ventas con planes de escalado vertical adicional.

• Planes de modelos adicionales para la previsión a largo plazo para regiones y otros clústeres de tiendas.

Solución de modelo de Machine Learning

El ciclo de vida de aprendizaje automático, también conocido como ciclo de vida de ciencia de datos, se ajusta aproximadamente al siguiente flujo de proceso general:

Aquí, la implementación del modelo puede representar cualquier uso operativo del modelo de Machine Learning validado. En comparación con DevOps, MLOps presenta el desafío adicional de cómo integrar este ciclo de vida de aprendizaje automático en el proceso típico de CI/CD.

Este ciclo de vida de ciencia de datos no sigue el típico ciclo de vida de desarrollo de software. Incluye el uso de Azure Machine Learning para entrenar y puntuar los modelos, por lo que estos pasos tenían que incluirse en la automatización de CI/CD.

El procesamiento por lotes de los datos es la base de la arquitectura. Dos canalizaciones de Azure Machine Learning son fundamentales para el proceso, una para el entrenamiento y otra para la puntuación. En este diagrama se muestra la metodología de ciencia de datos utilizada para la fase inicial del proyecto de cliente:

El equipo probó varios algoritmos. En última instancia, eligieron un diseño de conjunto de un modelo de regresión lineal LASSO y una red neuronal con inserciones de categorías. El equipo usó el mismo modelo, definido por el nivel de producto que el cliente podía almacenar en el sitio, para tiendas grandes y pequeñas. El equipo subdividió aún más el modelo en productos de movimiento de rotación rápida y lenta.

Los científicos de datos entrenan modelos de Machine Learning cuando el equipo publica código nuevo y cuando hay nuevos datos disponibles. El entrenamiento suele realiza con frecuencia semanal. Por lo tanto, cada ejecución de procesamiento implica una gran cantidad de datos. Dado que el equipo recopila datos de muchos orígenes en formatos diferentes, requiere acondicionamiento para configurarlos en un formato consumible de modo que los científicos de datos puedan procesarlos. El acondicionamiento de los datos requiere un esfuerzo manual considerable y el equipo de CSE lo identificó como candidato principal para la automatización.

Como ya se ha mencionado, los científicos de datos desarrollaron y aplicaron los modelos experimentales de Azure Machine Learning a una sola región de ventas en la fase 1 del estudio de campo piloto para evaluar la utilidad de este enfoque de previsión. El equipo de CSE consideró que el aumento de ventas observado en las tiendas del estudio piloto era significativo. Este éxito justificó la aplicación de la solución a niveles de producción completos en la fase 2, empezando por 14 regiones geográficas y miles de tiendas. Después, el equipo podría usar el mismo patrón para agregar regiones adicionales.

El modelo piloto sirvió de base para la solución escalada vertical, pero el equipo de CSE sabía que el modelo necesitaba refinamiento continuo para mejorar su rendimiento.

Solución de MLOps

A medida que los conceptos de MLOps maduran, los equipos suelen detectar desafíos para reunir las materias de ciencia de datos y DevOps. La razón es que los principales participantes de las disciplinas, ingenieros de software y científicos de datos, funcionan con diferentes conjuntos de aptitudes y prioridades.

Pero hay similitudes de partida. MLOps, al igual que DevOps, es un proceso de desarrollo implementado por una cadena de herramientas. La cadena de herramientas de MLOps incluye elementos tales como:

• Control de versiones
• Análisis de código
• Automatización de compilaciones
• Integración continua
• Marcos de pruebas y automatización
• Directivas de cumplimiento integradas en canalizaciones de CI/CD
• Automatización de la implementación
• Supervisión
• Recuperación ante desastres y alta disponibilidad
• Administración de paquetes y contenedores

Como se indicó anteriormente, la solución aprovecha las ventajas de la guía de DevOps existente, pero se amplía para crear una implementación de MLOps más madura que satisfaga las necesidades del cliente y de la comunidad de ciencia de datos. MLOps se basa en la guía de DevOps con estos requisitos adicionales:

• El control de versiones de datos o modelos no es los mismo que el control de versiones de código: debe haber control de versiones de los conjuntos de datos a medida que cambien los datos de origen y esquema.
• Requisitos de pista de auditoría digital: realice un seguimiento de todos los cambios al trabajar con código y datos de cliente.
• Generalización: los modelos son diferentes del código para su reutilización, ya que el científico de datos debe ajustar los modelos en función de los datos de entrada o el escenario. Para reutilizar un modelo para un escenario nuevo, puede que deba ajustarlo, transferirlo o aprender de él. Necesita la canalización de entrenamiento.
• Modelos obsoletos: los modelos tienden a deteriorarse con el tiempo y se necesita la capacidad de volver a entrenarlos a petición para garantizar que siguen siendo pertinentes en producción.

Desafíos de MLOps

MLOps inmaduro estándar

El patrón estándar de MLOps todavía está en evolución. Una solución normalmente se crea desde cero y se diseña para adaptarse a las necesidades de un cliente o usuario determinado. El equipo de CSE reconoció esta brecha y buscó usar los procedimientos recomendados de DevOps en este proyecto. Aumentó el proceso DevOps para ajustarse a los requisitos adicionales de MLOps. El proceso desarrollado por el equipo es un ejemplo viable del aspecto que debería tener un patrón de MLOps estándar.

Diferencias en los conjuntos de aptitudes

Los ingenieros de software y los científicos de datos aportan conjuntos de aptitudes únicos al equipo. Estos conjuntos de aptitudes distintos pueden dificultar la búsqueda de una solución que se ajuste a las necesidades de todos los usuarios. Es importante crear un flujo de trabajo fácil de entender para la entrega de modelos de experimentación a producción. Los miembros del equipo deben compartir una explicación sobre cómo integrar los cambios en el sistema sin interrumpir el proceso de MLOps.

Administración de varios modelos

A menudo se necesitan varios modelos para resolver escenarios difíciles de aprendizaje automático. Uno de los desafíos de MLOps es administrar estos modelos, que incluye lo siguiente:

• Tener un esquema de control de versiones coherente.
• Evaluar y supervisar continuamente todos los modelos.

También se necesita un linaje de código rastreable y de datos para diagnosticar los problemas del modelo y crear modelos reproducibles. Los paneles personalizados pueden explicar cómo funcionan los modelos implementados e indicar cuándo se debe intervenir. El equipo creó estos paneles para este proyecto.

Necesidad de acondicionamiento de datos

Los datos usados con estos modelos provienen de muchos orígenes públicos y privados. Dado que los datos originales están desorganizados, el modelo de Machine Learning no puede consumir los datos sin procesar. Los científicos de datos deben acondicionar los datos a un formato estándar para el consumo del modelo de Machine Learning.

Gran parte de la prueba de campo piloto se centró en el acondicionamiento de los datos sin procesar para que el modelo de Machine Learning pudiera procesarlos. En un sistema de MLOps, el equipo debe automatizar este proceso y realizar un seguimiento de las salidas.

Modelo de madurez de MLOps

El propósito del modelo de madurez de MLOps es aclarar los principios y las prácticas, así como identificar las brechas en la implementación de MLOps. También es una manera de mostrar a un cliente cómo desarrollar de manera incremental su capacidad de MLOps en lugar de intentarlo todo de una vez. El cliente debe usarlo como guía para:

• Estimar el ámbito del trabajo del proyecto.
• Establecer criterios de éxito.
• Identificar los resultados.

El modelo de madurez de MLOps abarca cinco niveles de funcionalidad técnica:

Nivel	Descripción
0	Sin operaciones
1	DevOps sin MLOps
2	Entrenamiento automatizado
3	Implementación del modelo automatizada
4	Operaciones automatizadas (MLOps completo)

Para la versión actual del modelo de madurez de MLOps, consulte el artículo Modelo de madurez de MLOps.

Definición del proceso de MLOps

MLOps incluye todas las actividades desde la adquisición de los datos sin procesar hasta la entrega de la salida del modelo, también conocida como puntuación:

• Acondicionamiento de datos
• Entrenamiento del modelo
• Pruebas y evaluación de modelos
• Definición y canalización de compilación
• Canalización de versión
• Implementación
• Puntuaciones

Proceso de aprendizaje automático básico

El proceso básico de aprendizaje automático se parece al de desarrollo de software tradicional, pero existen diferencias importantes. En este diagrama se ilustran los pasos principales del proceso de aprendizaje automático:

La fase del experimento es exclusiva del ciclo de vida de la ciencia de datos, que refleja cómo los científicos han realizado tradicionalmente su trabajo. Difiere de la forma en que los desarrolladores de código realizan el suyo. En el siguiente diagrama se muestra este ciclo de vida más detalladamente.

La integración de este proceso de desarrollo de datos en MLOps supone un reto. Aquí se muestra el patrón que el equipo usó para integrar el proceso en un formulario compatible con MLOps:

El rol de MLOps es crear un proceso coordinado que pueda admitir eficazmente los entornos de CI/CD a gran escala comunes en los sistemas de nivel de producción. Conceptualmente, el modelo de MLOps debe incluir todos los requisitos del proceso desde la experimentación hasta la puntuación.

El equipo de CSE refinó el proceso de MLOps para adaptarlo a las necesidades específicas del cliente. Lo más notable fue la necesidad de procesamiento por lotes en lugar del procesamiento en tiempo real. A medida que el equipo desarrolló el sistema de escalado vertical, identificó y resolvió algunas deficiencias. Las más importantes derivaron en el desarrollo de un puente entre Azure Data Factory y Azure Machine Learning que el equipo implementó como un conector integrado en Azure Data Factory. Crearon este conjunto de componentes para facilitar el desencadenamiento y la supervisión de estado necesarios para que la automatización del proceso funcionara.

Otro cambio fundamental fue que el científico de datos necesitaba la capacidad de exportar código experimental desde cuadernos de Jupyter Notebook al proceso de implementación de MLOps en lugar de desencadenar directamente el entrenamiento y la puntuación.

Este es el concepto de modelo de proceso de MLOps final:

Flujo del proceso de MLOps

En el diagrama siguiente se describe cómo aplicar flujos de trabajo de desarrollo y lanzamiento de CI/CD al ciclo de vida de aprendizaje automático:

• Cuando se crea una solicitud de incorporación de cambios desde una rama de características, la canalización ejecuta pruebas de validación de código para comprobar la calidad del código con pruebas unitarias y de calidad del código. Para validar la calidad ascendente, la canalización también ejecuta pruebas de validación de modelo básicas para validar los pasos de entrenamiento y puntuación de un extremo a otro con un conjunto de muestras de datos ficticios.
• Si la solicitud de incorporación de cambios se combina en la rama principal, la canalización de CI ejecutará las mismas pruebas de validación de código y las pruebas de validación de modelo básicas con más tiempo. A continuación, la canalización empaquetará los artefactos, que incluyen el código y los archivos binarios, para ejecutarlos en el entorno de aprendizaje automático.
• Una vez que los artefactos estén disponibles, se desencadenará una canalización de CD de validación de modelos. Ejecuta la validación de un extremo a otro en el entorno de aprendizaje automático de desarrollo. Se publicará un mecanismo de puntuación. En un escenario de puntuación por lotes, se publica una canalización de puntuación en el entorno de aprendizaje automático y se desencadena para generar resultados. Si quiere usar un escenario de puntuación en tiempo real, puede publicar una aplicación web o implementar un contenedor.
• Una vez que se crea un hito y se combina en la rama de versión, se desencadenan la misma canalización de CI y la canalización de CD de validación de modelos. Esta vez, se ejecutan en el código de la rama de versión.

Puede considerar el flujo de datos de proceso de MLOps mostrado anteriormente como un marco de arquetipos para los proyectos que utilizan opciones de arquitectura similares.

Pruebas de validación de código

Las pruebas de validación de código para el aprendizaje automático se centran en la validación de la calidad del código base. Es el mismo concepto que el de cualquier proyecto de ingeniería con pruebas de calidad del código (linting), pruebas unitarias y medición de la cobertura de código.

Pruebas de validación de modelos básicos

La validación del modelo normalmente hace referencia a la validación de los pasos de todo el proceso de un extremo a otro necesarios para generar un modelo de Machine Learning válido. Incluye pasos como:

• Validación de datos: garantiza que los datos de entrada sean válidos.
• Validación del entrenamiento: garantiza que el modelo se pueda entrenar correctamente.
• Validación de la puntuación: garantiza que el equipo pueda utilizar correctamente el modelo entrenado para la puntuación con los datos de entrada.

La ejecución de este conjunto completo de pasos en el entorno de aprendizaje automático es costosa y requiere mucho tiempo. Consecuentemente, el equipo realizó las pruebas de validación del modelo básicas en una máquina de desarrollo local. Ejecutó los pasos anteriores y usó lo siguiente:

• Conjunto de datos de prueba local: un conjunto de datos pequeño, a menudo ofuscado, protegido en el repositorio y consumido como origen de datos de entrada.
• Marca local: marca o argumento en el código del modelo que indica que el código pretende que el conjunto de datos se ejecute localmente. La marca permite que el código omita cualquier llamada al entorno de aprendizaje automático.

El objetivo de estas pruebas de validación no es evaluar el rendimiento del modelo entrenado. Mejor dicho, es comprobar que el código del proceso global es de buena calidad. Garantiza la calidad del código que se inserta en dirección ascendente mediante incorporación de pruebas de validación de modelos en la compilación de PR y CI. También permite a los ingenieros y científicos de datos colocar puntos de interrupción en el código con fines de depuración.

Canalización de CD de validación de modelos

El objetivo de la canalización de validación de modelos es validar los pasos de entrenamiento y puntuación de los modelos de un extremo a otro en el entorno de aprendizaje automático con datos reales. Cualquier modelo entrenado que se produzca se agregará al registro de modelos y se etiquetará, a la espera de su promoción una vez completada la validación. En la predicción por lotes, la promoción puede consistir en publicar una canalización de puntuación que use esta versión del modelo. Para la puntuación en tiempo real, el modelo se puede etiquetar para indicar que se ha promocionado.

Canalización de CD de puntuación

La canalización de CD de puntuación es aplicable para el escenario de inferencia de lotes, donde el mismo orquestador de modelos que se usa para la validación del modelo desencadena la canalización de puntuación publicada.

Comparación de entornos de desarrollo y producción

Es recomendable separar los entornos de desarrollo (dev) y de producción (prod). La separación permite que el sistema desencadene la canalización de CD de validación de modelos y la canalización de CD de puntuación con programas distintos. En el flujo de MLOps descrito, las canalizaciones que tienen como destino la rama principal se ejecutan en el entorno de desarrollo y la canalización dirigida a la rama de versión se ejecuta en el entorno de producción.

Cambios de código frente a cambios de datos

En las secciones anteriores se aborda principalmente cómo controlar los cambios de código desde el desarrollo hasta el lanzamiento. Sin embargo, los cambios de datos deben seguir el mismo rigor que los cambios de código para proporcionar la misma calidad en la validación y coherencia en la producción. Con un desencadenador de cambio de datos o un desencadenador de temporizador, el sistema puede desencadenar la canalización de CD de validación de modelos y la canalización de CD de puntuación desde el orquestador de modelos para ejecutar el mismo proceso que al cambiar el código en el entorno de producción de la rama de versión.

Personas y roles de MLOps

Un requisito clave para cualquier proceso de MLOps es que satisfaga las necesidades de todos los usuarios del proceso. Para fines de diseño, considere estos usuarios como roles individuales. Para este proyecto, el equipo identificó los siguientes roles:

• Científico de datos: crea el modelo de Machine Learning y sus algoritmos.
• Ingeniero
  • Ingeniero de datos: controla el acondicionamiento de datos.
  • Ingeniero de software: controla la integración del modelo en el paquete de recursos y el flujo de trabajo de CI/CD.
• Operaciones o TI: supervisa las operaciones del sistema.
• Partes interesadas de la empresa: se preocupan de las predicciones realizadas por el modelo de Machine Learning y de la ayuda que proporcionan a la empresa.
• Usuario final de los datos: consume la salida del modelo de forma útil para la toma de decisiones empresariales.

El equipo tenía que abordar tres conclusiones clave de los estudios de roles y funciones:

• Los científicos e ingenieros de datos discrepan en el enfoque y las aptitudes de su trabajo. Facilitar que el científico y el ingeniero de datos trabajen en colaboración es una consideración importante que tener en cuenta para el diseño del flujo del proceso de MLOps. Requiere nuevas adquisiciones de aptitudes por parte de todos los miembros del equipo.
• Existe una necesidad de unificar todos los roles principales sin apartar a nadie. Una manera de hacerlo es la siguiente:
  • Asegúrese de entender el modelo conceptual de MLOps.
  • Llegue a un acuerdo sobre los miembros del equipo que trabajarán juntos.
  • Establezca las instrucciones de trabajo para lograr objetivos comunes.
• Si la parte interesada empresarial y el usuario final de los datos necesitan una manera de interactuar con la salida de datos de los modelos, una interfaz de usuario fácil de usar es la solución estándar.

Otros equipos experimentarán problemas similares en otros proyectos de aprendizaje automático a medida que se escalen verticalmente para su uso en producción.

Arquitectura de la solución de MLOps

Arquitectura lógica

Los datos proceden de numerosos orígenes en distintos formatos, por lo que están acondicionados para su inserción en el lago de datos. El acondicionamiento se realiza mediante microservicios que funcionan como Azure Functions. Los clientes personalizan los microservicios para que se ajusten a los orígenes de datos y los transforman a un formato CSV normalizado que las canalizaciones de entrenamiento y puntuación consumen.

Arquitectura del sistema

Arquitectura de procesamiento por lotes

El equipo concibió el diseño arquitectónico para admitir un esquema de procesamiento de datos por lotes. Hay alternativas, pero lo que se use debe admitir los procesos de MLOps. El uso completo de los servicios de Azure disponibles era un requisito de diseño. En el siguiente diagrama se muestra la arquitectura:

Información general de la solución

Azure Data Factory hace lo siguiente:

• Desencadena una función de Azure para iniciar la ingesta de datos y una ejecución de la canalización de Azure Machine Learning.
• Inicia una instancia de Durable Functions para sondear la canalización de Azure Machine Learning para su finalización.

Los paneles personalizados de Power BI muestran los resultados. Otros paneles de Azure, conectados a Azure SQL, Azure Monitor y Application Insights a través del SDK de Python para OpenCensus, realizan un seguimiento de los recursos de Azure. Estos paneles proporcionan información sobre el estado del sistema de aprendizaje automático. También proporcionan los datos que el cliente usa para la previsión de pedidos de productos.

Orquestación de modelos

La orquestación de modelos sigue estos pasos:

1. Cuando se envía una solicitud de incorporación de cambios, DevOps desencadena una canalización de validación de código.
2. La canalización ejecuta pruebas unitarias, de calidad del código y de validación del modelo.
3. Cuando se combinan en la rama principal, se ejecutan las mismas pruebas de validación del código y DevOps empaqueta los artefactos.
4. La recopilación de artefactos por parte de DevOps desencadena Azure Machine Learning para lo siguiente:
   1. Validación de datos.
   2. Validación del entrenamiento.
   3. Validación de la puntuación.
5. Una vez completada la validación, se ejecuta la canalización de puntuación final.
6. El cambio de datos y el envío de una nueva solicitud de incorporación de cambios desencadena de nuevo la canalización de validación, seguida de la canalización de puntuación final.

Habilitación de la experimentación

Como se mencionó, el ciclo de vida de aprendizaje automático de la ciencia de datos tradicional no es compatible con el proceso de MLOps sin modificaciones. Utiliza diferentes tipos de herramientas manuales y experimentación, validación, empaquetado y entrega de modelos que no se pueden escalar fácilmente para un proceso de CI/CD efectivo. MLOps exige un alto nivel de automatización de procesos. Tanto si se desarrolla un nuevo modelo de Machine Learning como si se modifica uno anterior, es necesario automatizar el ciclo de vida del modelo de Machine Learning. En el proyecto de la fase 2, el equipo usó Azure DevOps para orquestar y volver a publicar las canalizaciones de Azure Machine Learning para tareas de entrenamiento. La rama principal de larga duración hace pruebas básicas de los modelos y versiones estables insertadas mediante la rama de versión de larga duración.

El control de código fuente se convierte en una parte importante de este proceso. Git es el sistema de control de versiones que se usa para realizar el seguimiento del código del modelo y el cuaderno. También admite la automatización de procesos. El flujo de trabajo básico implementado para el control de código fuente aplica los principios siguientes:

• Use el control de versiones formal para el código y los conjuntos de datos.
• Use una rama para el desarrollo de código nuevo hasta que el código se desarrolle y valide por completo.
• Una vez validado el código nuevo, se puede combinar en la rama principal.
• Para una versión, se crea una rama con versiones permanente independiente de la principal.
• Use versiones y el control de código fuente para los conjuntos de datos que se acondicionaran para el entrenamiento o el consumo, de modo que pueda proteger la integridad de cada conjunto de datos.
• Use el control de código fuente para realizar un seguimiento de los experimentos de Jupyter Notebook.

Integración con orígenes de datos

Los científicos de datos usan muchos orígenes de datos sin procesar y conjuntos de datos procesados para experimentar con diferentes modelos de Machine Learning. El volumen de datos en un entorno de producción puede ser abrumador. Para experimentar con diferentes modelos, los científicos de datos deben usar herramientas de administración como Azure Data Lake. El requisito para la identificación formal y el control de versiones se aplica a todos los datos sin procesar, los conjuntos de datos preparados y los modelos de Machine Learning.

En el proyecto, los científicos de datos acondicionaron los siguientes datos para la entrada en el modelo:

• Datos históricos semanales de envío desde enero de 2017
• Datos meteorológicos diarios históricos y previstos para cada código postal
• Datos de los compradores para cada identificador de tienda

Integración con el control de código fuente

Para que los científicos de datos apliquen los procedimientos recomendados de ingeniería, es necesario integrar convenientemente las herramientas que usan con sistemas de control de código fuente como GitHub. Este procedimiento permite el control de versiones del modelo de Machine Learning, la colaboración entre los miembros del equipo y la recuperación ante desastres, en caso de que los equipos experimenten pérdida de datos o interrupción de los sistemas.

Compatibilidad del conjunto de modelos

El diseño del modelo de este proyecto era un modelo de conjunto. Es decir, los científicos de datos usaron muchos algoritmos en el diseño final del modelo. En este caso, los modelos usaron el mismo diseño de algoritmo básico. La única diferencia era que usaron distintos datos de entrenamiento y de puntuación. Los modelos usaron la combinación de un algoritmo de regresión lineal LASSO y una red neuronal.

Aunque no la implementó, el equipo exploró una opción para hacer avanzar el proceso hasta el punto en que pudiera tener muchos modelos en tiempo real ejecutándose en producción para atender una solicitud determinada. Esta opción puede dar cabida al uso de modelos de conjunto en pruebas A/B y experimentos intercalados.

Interfaces de usuario final

El equipo desarrolló interfaces de usuario final para las operaciones de observabilidad, supervisión e instrumentación. Como hemos mencionado, los paneles muestran los datos del modelo de Machine Learning. Estos paneles muestran los datos siguientes en un formato sencillo:

• Pasos de canalización, incluido el procesamiento previo de los datos de entrada.
• Para supervisar el estado del procesamiento del modelo de Machine Learning:
  • ¿Qué métricas recopila del modelo implementado?
    • MAPE: error de porcentaje absoluto medio (métrica clave para el seguimiento del rendimiento general. El destino es un valor de MAPE <=0,45 para cada modelo).
    • RMSE 0: raíz del error cuadrático medio (RMSE) cuando el valor de destino real = 0.
    • RMSE All: RMSE en todo el conjunto de datos.
  • ¿Cómo se evalúa si el modelo se ejecuta según lo previsto en producción?
  • ¿Hay alguna manera de saber si los datos de producción se desvían demasiado de los valores esperados?
  • ¿El modelo está experimentando un rendimiento deficiente en producción?
  • ¿Tiene un estado de conmutación por error?
• Realizan un seguimiento de la calidad de los datos procesados.
• Muestran las predicciones o puntuaciones generadas por el modelo de Machine Learning.

La aplicación rellena los paneles según la naturaleza de los datos y el modo en que los procesa y analiza. Por tanto, el equipo debe concebir el diseño exacto de los paneles para cada caso de uso. A continuación se muestran dos paneles de ejemplo:

Los paneles se diseñaron para proporcionar información fácil de usar para el usuario final de las predicciones del modelo de Machine Learning.

Componentes

• Azure Machine Learning
  • Proceso de Azure Machine Learning
  • Canalizaciones de Azure Machine Learning
  • Registro de modelos de Azure Machine Learning
• Azure Blob Storage
• Almacén de Azure Data Lake
• Azure Pipelines
• Azure Data Factory
• Azure Functions para Python
• Azure Monitor
  • Registros
  • Application Insights
• Azure SQL Database
• Paneles de Azure
• Power BI

Consideraciones

Aquí encontrará una lista de las consideraciones que se deben explorar. Se basan en las lecciones que el equipo de CSE aprendió durante el proyecto.

Consideraciones sobre el entorno

• Los científicos de datos desarrollan la mayoría de los modelos de Machine Learning con Python, a menudo a partir de cuadernos de Jupyter Notebook. Puede ser un reto implementar estos cuadernos como código de producción. Los cuadernos de Jupyter Notebook son más bien una herramienta experimental, mientras que los scripts de Python son más adecuados para producción. A menudo, los equipos deben dedicar tiempo a refactorizar el código de creación de modelos en los scripts de Python.
• Haga que los clientes que no estén familiarizados con DevOps y el aprendizaje automático sean conscientes de que la experimentación y la producción requieren un rigor diferente, por lo que es recomendable separar los dos.
• Herramientas como el diseñador visual de Azure Machine Learning o AutoML pueden ser eficaces para poner en marcha modelos básicos, mientras el cliente se pone al día con las prácticas de DevOps estándar que aplicar al resto de la solución.
• Azure DevOps tiene complementos que se pueden integrar con Azure Machine Learning para ayudar a desencadenar los pasos de canalización. El repositorio MLOpsPython tiene algunos ejemplos de estas canalizaciones.
• El aprendizaje automático a menudo requiere potentes máquinas de unidades de procesamiento gráfico (GPU) para el entrenamiento. Si el cliente aún no tiene este hardware disponible, los clústeres de proceso de Azure Machine Learning son un método eficiente para el aprovisionamiento rápido de hardware eficaz y rentable que se escala automáticamente. Si un cliente requiere seguridad avanzada o supervisión, existen otras opciones, como el uso de máquinas virtuales estándar, Databricks o un proceso local.
• Para el éxito de un cliente, los equipos de creación de modelos (científicos de datos) y los equipos de implementación (ingenieros de DevOps) deben tener un canal de comunicación sólido. Pueden lograrlo con reuniones diarias o con un servicio de chat en línea formal. Ambos enfoques ayudan a integrar sus esfuerzos de desarrollo en un marco de MLOps.

Consideraciones sobre la preparación de los datos

• La solución más sencilla para usar Azure Machine Learning es almacenar datos en una solución de almacenamiento de datos compatible. Herramientas como Azure Data Factory son eficaces para canalizar los datos hacia y desde esas ubicaciones según una programación.

• Es importante que los clientes capturen datos de reentrenamiento adicionales con frecuencia para mantener los modelos actualizados. Si aún no tienen una canalización de datos, la creación de una será una parte importante de la solución general. El uso de una solución como DataSets en Azure Machine Learning puede ser útil para el control de versiones de los datos a fin de facilitar la trazabilidad de los modelos.

Consideraciones de entrenamiento y de evaluación de modelos

• Es agobiante para un cliente que acaba de empezar a usar el aprendizaje automático intentar implementar a una canalización de MLOps completa. Si es necesario, se puede simplificar mediante Azure Machine Learning para realizar un seguimiento de las ejecuciones del experimento y con el proceso de Azure Machine Learning como destino del entrenamiento. Estas opciones pueden crear una barrera inferior de la solución de entrada para empezar a integrar los servicios de Azure.

• Pasar de un experimento de cuaderno a scripts repetibles es una transición aproximada para muchos científicos de datos. Cuanto antes se pueda empezar a escribir el código de entrenamiento en scripts de Python, más fácil resultará empezar a controlar las versiones del código de entrenamiento y habilitar el nuevo entrenamiento.

  No es el único método posible. Databricks admite la programación de cuadernos como trabajos. No obstante, en función de la experiencia del cliente actual, este enfoque es difícil instrumentarlo con prácticas de DevOps completos debido a las limitaciones de las pruebas.

• También es importante comprender qué métricas se usan para considerar que un modelo es correcto. La precisión por si sola a menudo no es suficiente para determinar el rendimiento general de un modelo comparado con otro.

Consideraciones de proceso

• Los clientes deben considerar la posibilidad de usar contenedores para estandarizar sus entornos de proceso. Casi todos los destinos de proceso de Azure Machine Learning admiten el uso de Docker. Tener un contenedor que controle las dependencias reduce considerablemente la fricción, especialmente si el equipo usa muchos destinos de proceso.

Consideraciones de servicio de modelos

• El SDK de Azure Machine Learning proporciona una opción para la implementación directa en Azure Kubernetes Service desde un modelo registrado, lo que crea límites en las opciones de seguridad o las métricas implementadas. Puede intentar buscar una solución más sencilla para que los clientes prueben el modelo, pero es mejor desarrollar una implementación más sólida en AKS para las cargas de trabajo de producción.

Pasos siguientes

• Obtenga más información sobre MLOps
• MLOps en Azure
• Visualizaciones de Azure Monitor
• Ciclo de vida de Machine Learning
• Extensión de Azure DevOps Machine Learning
• CLI de Azure Machine Learning
• Desencadenar aplicaciones, procesos o flujos de trabajo de CI/CD basados en eventos de Azure Machine Learning
• Configuración del entrenamiento y la implementación de modelos con Azure DevOps

Recursos relacionados

• Modelo de madurez de MLOps
• Orquestación de MLOps en Azure Databricks mediante Databricks Notebook
• MLOps para modelos de Python con Azure Machine Learning
• Ciencia de datos y aprendizaje automático con Azure Databricks
• Inteligencia artificial ciudadana con Power Platform
• Implementación de procesos de inteligencia artificial y aprendizaje automático en el entorno local y en el perímetro