Foto por juliana malta on Unsplash

Introducción

 
Los patrones de diseño son un conjunto de mejores prácticas y soluciones reutilizables para problemas comunes. La ciencia de datos y otras disciplinas como el desarrollo de software, la arquitectura, etc. están constituidas por una gran cantidad de problemas recurrentes y, por lo tanto, tratar de categorizar los más comunes y proporcionar diferentes formas de planos para reconocerlos fácilmente y resolverlos podría brindar un inmenso beneficio. a la comunidad más amplia.

La idea de usar patrones de diseño en el desarrollo de software fue presentada por primera vez por Erich Gamma et. Alabama. en "Patrones de Diseño: Elementos de Software Orientado a Objetos Reutilizables” [ 1 ] y recientemente aplicado a procesos de Machine Learning gracias a Sara Robinson et. Alabama. en "Patrones de diseño de aprendizaje automático” [2].

Como parte de este artículo, ahora vamos a descubrir los diferentes patrones de diseño que constituyen MLOps. MLOps (Machine Learning -> Operations) es un conjunto de procesos diseñados para transformar modelos experimentales de Machine Learning en servicios productivos listos para tomar decisiones en el mundo real. En esencia, MLOps se basa en los mismos principios de DevOps pero con un enfoque adicional en la validación de datos y la capacitación/evaluación continua (Figura 1).

Figura 1: DevOps y MLOps (Imagen del autor).

Algunos de los principales beneficios de MLOps son:

• Mejor tiempo de comercialización (implementaciones más rápidas).
• Mayor robustez del modelo (más fácil de identificar la deriva de datos, modelos de reentrenamiento, etc.).
• Más flexibilidad para entrenar/comparar diferentes modelos de ML.

Por otra parte, DevOps enfatiza dos conceptos claves para el desarrollo de software: Integración Continua (CI) y Entrega Continua (CD). La integración continua se enfoca en usar un repositorio central como un medio para que los equipos colaboren en un proyecto y automatizar tanto como sea posible el proceso de agregar, probar y validar código nuevo a medida que lo agregan los diferentes miembros del equipo. De esta manera, es posible probar en cualquier momento si las diferentes partes de una aplicación pueden comunicarse correctamente entre sí e identificar lo antes posible cualquier forma de error. La entrega continua se centra en cambio en la actualización fluida de las implementaciones de software, tratando de evitar en la medida de lo posible cualquier forma de tiempo de inactividad.

Patrones de diseño de MLOps

Canalización de flujo de trabajo

 
Los proyectos de Machine Learning (ML) se construyen mediante muchos pasos diferentes (Figura 2).

Figura 2: Pasos clave del proyecto ML (Imagen del autor).

Al crear prototipos de un nuevo modelo, puede ser bastante común comenzar usando un solo script (monolítico) para codificar todo el proceso, pero como el proyecto puede aumentar en complejidad y más miembros del equipo pueden comenzar a involucrarse, podría ser necesario dividir cada paso diferente del proyecto en un script separado (microservicio). Algunos de los beneficios de adoptar este enfoque podrían ser:

• Más fácil experimentar con cambios en la orquestación de los diferentes pasos.
• Haga que el proyecto sea escalable por definición (los nuevos pasos se pueden agregar y eliminar fácilmente).
• Cada miembro del equipo puede concentrarse en un paso diferente en el flujo.
• Se pueden crear artefactos separados para cada paso diferente.

El patrón de diseño de Workflow Pipeline tiene como objetivo definir un modelo para crear ML Pipelines. ML Pipelines se puede representar como un Gráfico acíclico dirigido (DAG), en el que cada uno de sus pasos está caracterizado por un contenedor (Figura 3).

Figura 3: Ejemplo de gráfico acíclico dirigido (imagen del autor).

Siguiendo esta estructura, entonces podría ser posible crear procesos de ML reproducibles y manejables. Algunos de los beneficios de usar Workflow Pipelines podrían ser:

• Al agregar y eliminar pasos en el flujo, se pueden crear experimentos complejos para probar diferentes técnicas de preprocesamiento, modelos de aprendizaje automático e hiperparámetros.
• Guardando individualmente la salida de cada paso diferente, puede ser posible evitar volver a ejecutar los pasos al comienzo de la canalización si se ha aplicado algún cambio solo en los pasos finales (por lo tanto, se ahorra tiempo y potencia de cálculo).
• En caso de errores, puede ser fácil identificar qué paso debe actualizarse.
• Una vez implementadas en producción mediante CI/CD, las canalizaciones se pueden programar para volver a ejecutarse en función de diferentes factores, como: intervalo de tiempo, activadores externos, cambios en las métricas de ML, etc.

Tienda de características

 
Los almacenes de funciones son una capa de gestión de datos diseñada para los procesos de aprendizaje automático (Figura 4). El uso principal de este patrón de diseño es simplificar la forma en que las organizaciones administran y usan las funciones de aprendizaje automático. Esto se hace mediante la creación de algún tipo de repositorio central utilizado por una empresa para almacenar todas las funciones que se han creado para los procesos de ML. De esta manera, si los científicos de datos pudieran necesitar el mismo subconjunto de funciones para diferentes proyectos de ML, no tendrían que pasar por el proceso de convertir datos sin procesar en funciones procesadas varias veces (lo que podría resultar costoso). Dos de las soluciones Feature Store de código abierto más comunes son Fiesta y fábricas de lúpulo.

Figura 4: Patrón de diseño de la tienda de funciones (Imagen del autor).

Puede encontrar información adicional sobre las tiendas de características en mi artículo anterior.

Transformar

 
El patrón de diseño Transform tiene como objetivo facilitar la implementación y el mantenimiento de modelos de Machine Learning en producción al mantener las entradas, las características y las transformaciones como entidades separadas (Figura 5). De hecho, los datos sin procesar generalmente deben pasar por diferentes pasos de preprocesamiento para luego usarse como entrada para un modelo de aprendizaje automático y algunas de estas transformaciones deben guardarse para reutilizarse cuando se preprocesan los datos para la inferencia.

Figura 5: Relación Entradas y Características (Imagen por Autor).

Por ejemplo, las técnicas de normalización/estandarización se aplican comúnmente a los datos numéricos antes de entrenar un modelo de ML para tratar los valores atípicos y hacer que los datos se parezcan más a una distribución gaussiana. Estas transformaciones deben guardarse para poder reutilizarlas en el futuro cuando haya nuevos datos disponibles para la inferencia. Si estas transformaciones no se guardaran, crearíamos un sesgo de datos entre el entrenamiento y el servicio con los datos de entrada proporcionados para la inferencia que tienen una distribución diferente en comparación con los datos de entrada usados ​​para entrenar el modelo de ML.

Una solución alternativa para evitar cualquier tipo de sesgo entre el entrenamiento y el servicio es hacer uso del patrón de diseño Feature Store.

Entrada multimodal

 
Se pueden usar diferentes tipos de datos como imágenes, texto, números, etc. para entrenar modelos ML, aunque algunos tipos de modelos solo pueden aceptar un tipo específico de datos de entrada. Por ejemplo, el Resnet-50 puede tomar solo imágenes como datos de entrada, mientras que otros modelos ML como KNN (K Nearest Neighbor) pueden tomar solo datos numéricos como entrada.

Para tratar de resolver un problema de ML, puede ser necesario utilizar diferentes formas de datos de entrada. En este caso, es necesario aplicar algún tipo de transformación para crear una representación común de todos nuestros diferentes tipos de datos de entrada (patrón de diseño de entrada multimodal). Como ejemplo, imaginemos que se nos proporciona una combinación de datos de texto, numéricos y categóricos. Para entrenar un modelo de ML, podríamos utilizar técnicas como análisis de sentimientos, bolsa de palabras o incrustaciones de palabras para convertir los datos de texto en un formato numérico y una codificación en caliente para convertir también los datos categóricos. De esta forma, tendríamos todos nuestros datos en el mismo formato (numérico), listos para ser utilizados para el entrenamiento.

cascada

 
En algunos escenarios, no es posible resolver un problema de ML utilizando solo un único modelo de ML. En este caso, entonces sería necesario crear una serie de modelos ML que sean dependientes entre sí para lograr un objetivo final. Como ejemplo, imaginemos que estamos tratando de predecir qué tipo de artículos recomendar a un usuario (Figura 6). Para resolver este problema, primero queremos crear un modelo capaz de predecir si el usuario tiene más o menos de 18 años y luego, dependiendo de la respuesta de este modelo, enrutar nuestro flujo a uno de los dos motores de recomendación de ML diferentes (uno diseñado para recomendar productos para usuarios mayores de 18 años y otro para recomendar productos a usuarios menores de 18 años).

Figura 6: Patrón de diseño en cascada (Imagen del autor).

Para crear este cascada de modelos ML, entonces tendríamos que asegurarnos de entrenarlos juntos. De hecho, debido a su dependencia entre sí, si el primer modelo cambiara (sin actualizar los otros modelos), esto podría generar inestabilidad en los modelos posteriores. Este tipo de proceso podría luego automatizarse utilizando el patrón de diseño de canalización de flujo de trabajo.

Conclusión

 
En este artículo, exploramos algunos de los patrones de diseño más comunes que sustentan MLOps. En caso de que esté interesado en obtener más información sobre patrones de diseño en aprendizaje automático, hay información adicional disponible en esta charla por Valliappa Lakshmanan en AIDevFest20 y el libro "Machine Learning Design Patterns" público Repositorio GitHub.

Contacto

 
Si quieres mantenerte actualizado con mis últimos artículos y proyectos sígueme en Medium y suscríbete a mi lista de envío. Estos son algunos de mis datos de contacto:

Bibliografía

 
[1] “Patrones de diseño: elementos de software orientado a objetos reutilizable” (Addison-Wesley, 1995). Accedido en: www.uml.org.cn/c%2B%2B/pdf/DesignPatterns.pdf

[2] "Patrones de diseño de aprendizaje automático" (Sara Robinson et. al., 2020) Consultado en: https://www.oreilly.com/library/view/machine-learning-design/9781098115777/

 
 
Pier Paolo Ippolito es un científico de datos y un máster en Inteligencia Artificial de la Universidad de Southampton. Tiene un gran interés en los avances de la inteligencia artificial y las aplicaciones de aprendizaje automático (como finanzas y medicina). Conéctate con él en LinkedIn.

Original. Publicado de nuevo con permiso.
 

• Coinsmart. El mejor intercambio de Bitcoin y criptografía de Europa.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. ACCESO LIBRE.
• CriptoHawk. Radar de altcoins. Prueba gratis.
• Fuente: https://www.kdnuggets.com/2022/02/design-patterns-machine-learning-mlops.html?utm_source=rss&utm_medium=rss&utm_campaign=design-patterns-in-machine-learning-for-mlops