En el post anterior hemos visto lo importante que es comprometerse con los MLOps desde el principio. Las plataformas MLOps ayudan a reducir los pasos manuales, aumentar la colaboración en equipo, cumplir los requisitos normativos y de conformidad y reducir el tiempo de comercialización.

Debido a la complejidad del tema y a las numerosas herramientas, surge la pregunta: ¿por dónde empezar? No todas las herramientas tienen la misma importancia y algunas sólo son relevantes a partir de un determinado tamaño de equipo. Por ello, el siguiente modelo de procedimiento pretende servir de orientación. Ofrece cuatro niveles de desarrollo: Prerrequisitos, Fundamentos, Escala y Madurez. Se da la máxima prioridad a los fundamentos de la ingeniería de software y de datos, lo que permite a los equipos con poca experiencia en ML empezar con buen pie. Con cada nivel se pueden crear productos cada vez más complejos y, sobre todo, operar sobre la base de ML. 

Retos de los modelos ML locales 

El procedimiento más sencillo para ejecutar un modelo ML es entrenar un modelo localmente y almacenarlo en un almacén de objetos. Un trabajo (recurrente) recoge el modelo y lo aplica a un conjunto de datos. Los resultados se almacenan en una base de datos o en un archivo. Este enfoque puede ser rápido, pero conlleva muchos riesgos y no es adecuado para escalar. Ejecutar el entrenamiento y la preparación de los datos localmente, además de la amenaza de una violación de la protección de datos en muchos casos, dificulta mucho el trabajo en equipo. La ejecución de la formación no es visible para los miembros del equipo. No pueden acceder a los detalles de la formación y continuar el desarrollo. El resultado son nuevos desarrollos que requieren mucho tiempo. En el caso de predicciones incorrectas, éstas no pueden rastrearse, ya que sin versionado no es posible rastrear qué versión del modelo se utilizó y cuándo. Auditorías¹ de los modelos con respecto a los datos utilizados, por lo que las cuestiones jurídicas o éticas son imposibles. También existe un alto riesgo de utilizar modelos defectuosos, ya que las pruebas no pueden aplicarse automáticamente. Además, la formación está limitada por la potencia de cálculo del sistema local, por lo que no es suficiente para algunos casos de uso. 

Al cargar el vídeo aceptas la política de privacidad de YouTube.
Más información

cargar Vídeo

Desbloquear siempre YouTube

Aspectos básicos de la operacionalización del ML 

Enfoque:  

• Versionado 
• CI/CD  
• Scripts de Python en lugar de cuadernos 

En la primera fase de expansión, se implementan los fundamentos de la ingeniería de software y la ingeniería de datos modernas. Se trata del versionado, las pruebas y los conductos de despliegue. El versionado del código permite la trazabilidad de los cambios y la colaboración simultánea de varios desarrolladores. Los modelos también se versionan del mismo modo que el código. Los conductos de despliegue crean el trabajo de formación y lo activan. Para ello, el entrenamiento del modelo ya no se ejecuta en Jupyter Notebooks o como un script de Python, sino como un único trabajo. El código para el trabajo de formación se versiona y el trabajo se despliega a través de canalizaciones CI/CD. Las canalizaciones CI/CD ofrecen la posibilidad de ejecutar pruebas automatizadas. Estas pruebas ayudan a detectar errores antes de que se inicie el entrenamiento del modelo, de modo que el modelo o el trabajo de entrenamiento puedan desarrollarse más rápidamente. El modelo entrenado se almacena y versiona en un registro de modelos. El servicio ML para la predicción también se proporciona a través de un canal CI/CD junto con el modelo. La provisión de un nuevo modelo se sigue realizando manualmente, es decir, un desarrollador comprueba la calidad del nuevo modelo utilizando métricas de rendimiento. El servicio de ML suele ser una API que proporciona una predicción a petición o un trabajo por lotes que calcula predicciones en un intervalo. También en este caso pueden realizarse pruebas con el modelo. Las comprobaciones de plausibilidad son una forma de hacerlo. 

El enfoque en el uso de herramientas establecidas, como las canalizaciones y pruebas CI/CD, permite alcanzar rápidamente un mayor nivel de automatización y fiabilidad. 

Descubra en qué consiste MLOps, cómo afecta a las operaciones de las aplicaciones de aprendizaje automático, en qué se diferencia de DevOps y cómo los productos de ML pueden ayudar a abordar los retos de su organización.

¿Por qué MLOps? Los 5 retos del desarrollo de productos ML 

Bases de una plataforma MLOps 

Enfoque: 

• Catálogo de datos 
• Tuberías ML 
• Seguimiento de experimentos 

En la segunda fase de expansión, la formación del modelo debe hacerse reutilizable y automatizarse aún más mediante el uso de pipelines. Además, la gestión de datos debe establecerse en una fase temprana para mantener una visión general de las diferentes fuentes de datos. 

Los pipelines permiten la orquestación de todos los pasos relevantes para el entrenamiento de modelos, así como la disociación de estos pasos. Los trabajos de ML, antes complejos, pueden dividirse en pasos más pequeños y combinarse en pipelines. De este modo, los pasos son más fáciles de entender y mantener y pueden intercambiarse. Como resultado, se pueden reutilizar en diferentes pipelines o compartir fácilmente a través de plantillas. Además, cada paso puede ejecutarse con capacidad de cálculo dedicada, como GPU o RAM. De este modo, sólo se pueden proporcionar los recursos realmente necesarios para reducir costes. A la inversa, esto permite escalar la formación poniendo a disposición más recursos. Los pasos también se crean a través de una canalización CI/CD, donde pueden probarse automáticamente. Las pruebas también pueden cubrir requisitos normativos. Sería posible realizar pruebas que reconocieran datos personales en el conjunto de datos de formación. 

Además, ahora se capturan metadatos de formación de modelos, como la configuración y el rendimiento del modelo, también conocidos como seguimiento de experimentos. Estos se rastrean durante el entrenamiento y se almacenan en un almacén de metadatos. Esto permite a los miembros del equipo ver en cualquier momento qué modelos se han entrenado ya y cómo se han evaluado. 

La gestión de datos se realiza a través de un catálogo de datos. No es necesario utilizar una herramienta específica para ello. Una visión general en una hoja de cálculo o en Confluence suele ser suficiente. Es crucial crear esto en una fase temprana, ya que también refuerza la reutilización. En cuanto a los requisitos de cumplimiento, también puede ser necesario documentar qué datos utilizan los productos de ML. Al describir las fuentes de datos, incluido su contexto empresarial en particular, los desarrolladores pueden evaluar rápidamente si los datos son adecuados para un modelo. Esto evita la necesidad de reevaluar los datos una y otra vez. 

Centrarse en la ampliación 

Enfoque: 

• Despliegue automatizado
• Supervisión 
• Alerta 

La tercera fase de ampliación tiene por objeto facilitar a los equipos el manejo de varios productos. Para ello, hay que reducir las intervenciones manuales en el sistema. Para ello, la implantación de modelos se realiza ahora automáticamente. Cada modelo entrenado se compara con el modelo actualmente en producción, el llamado modelo campeón. Si un modelo recién entrenado es mejor que el modelo campeón, el nuevo modelo se convierte automáticamente en el nuevo modelo campeón y pasa a estar disponible. Es importante seguir ampliando las pruebas automatizadas. También deben realizarse pruebas de equidad, como la evaluación del rendimiento del modelo para grupos de usuarios específicos. Esto puede evitar que entren en producción modelos que superan al anterior modelo campeón en general, pero que tienen un impacto negativo en grupos de clientes que necesitan una consideración especial. A la vista de la Ley Europea sobre IA, estas pruebas podrían llegar a ser obligatorias. 

Además, la ampliación de la supervisión es crucial. El rendimiento de un modelo debe supervisarse en todo momento. Para ello, se registran todas las predicciones junto con los datos de entrada. Así se puede determinar la calidad de la predicción comparándola con los valores reales. El esfuerzo necesario para obtener los valores reales depende en gran medida del caso de uso. Las predicciones de series temporales se realizan automáticamente, mientras que la clasificación de imágenes requiere trabajo manual. En función del número de predicciones, los valores reales sólo pueden determinarse para una muestra. Esto permite controlar el rendimiento del modelo a lo largo del tiempo. Además, es aconsejable realizar comprobaciones sencillas de verosimilitud. Si se predice una probabilidad, ésta debe situarse entre 0 y 1. En caso de anomalías, se reproduce una alerta para avisar a los desarrolladores. Cuanto mejores sean las pruebas y las alertas, más rápido podrán los desarrolladores corregir los errores. 

El principio modular como Buenas prácticas

Enfoque:

• Reutilización más fácil 
• Mayor automatización 
• Más pruebas 

La última etapa de expansión refuerza aún más la automatización y reutilización de la plataforma. Se utilizan paquetes para los pipelines en lugar de plantillas. Cada paso está representado por un paquete que puede instalarse mediante pip, por ejemplo. Esto facilita la realización de actualizaciones y mantiene los pipelines al día durante un largo periodo de tiempo. Un almacén de características también puede ayudar a aumentar aún más la reutilización. De este modo, las características para la formación de modelos se comparten entre equipos. 

Además de nuevas pruebas para el control del modelo en producción, el tratamiento de las alertas está más automatizado. En lugar de activar manualmente un nuevo entrenamiento del modelo tras una alerta, ahora el entrenamiento se inicia automáticamente.  

Conclusión 

Para el éxito de los productos de ML, es crucial pensar en la operacionalización desde el principio. Este modelo de proceso pretende ofrecer un punto de entrada fácil a una infraestructura avanzada de ML. En vista de la próxima Ley Europea sobre IA, dicha infraestructura es necesaria. Sólo con ella podrán llevarse a cabo comprobaciones y pruebas automatizadas, como es probable que ocurra con los sistemas de alto riesgo.² será obligatorio. Sin estas capacidades para supervisar los modelos y controlar sus resultados, ya no se permitirá el uso del aprendizaje automático en áreas críticas. 

Si también desea que sus casos de uso de aprendizaje automático se ajusten a los requisitos normativos o quiere ponerlos en producción más rápidamente, estaremos encantados de ayudarle. Llevamos a cabo análisis de rendimiento con usted, desarrollamos un plan basado en sus necesidades para cerrar posibles brechas y le apoyamos durante la implementación y el mantenimiento.

¹ La auditoría de modelos ofrece a una organización la posibilidad de comprobar sistemáticamente los modelos utilizados para los riesgos. El marco CRISP-DM es adecuado como guía. Los riesgos jurídicos y éticos, en particular, deben examinarse detenidamente.
² La Ley Europea sobre IA divide los casos de uso de la IA en cuatro niveles de riesgo: riesgo inaceptable, alto riesgo, riesgo limitado y riesgo mínimo. Los sistemas de alto riesgo están sujetos a estrictas especificaciones antes de su comercialización. La comprobación totalmente automatizada de solicitudes de crédito, entre otras cosas, entra dentro del nivel de alto riesgo.