MLOps.pptx
•Descargar como PPTX, PDF•
0 recomendaciones•379 vistas
MLOps presentation for the workshop at ENC 2021 event organized by Sociedad Mexicana de Computacion
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a MLOps.pptx
Similar a MLOps.pptx (20)
Más de Luis Beltran
Más de Luis Beltran (20)
Último
Último (14)
MLOps.pptx
- 1. MLOps: Machine Learning en Producción Luis Beltrán luis@luisbeltran.mx
- 4. Un proyecto típico de Machine Learning
- 5. Problemas • No hay un seguimiento del trabajo realizado • ¿Qué datos se han utilizado? • ¿Qué código se ha probado en cada ocasión? • ¿Qué combinación de código y datos produjeron X modelo? • ¿Cuáles fueron las métricas del modelo X? • No siempre se generan entregables (“artefactos”) • No se puede reproducir (repetir) un modelo • No es posible pasar el modelo y todas sus variables (código, entorno, datos, etc) con facilidad
- 6. El proceso de ciencia de datos en equipo
- 8. ¿Qué es DevOps? DevOps es la unión of personas, procesos y productos para habilitar la entrega continua de valor a tus usuarios finales. “ ”
- 10. MLOps
- 11. MLOps • MLOps permite a los científicos de datos y a los desarrolladores de aplicaciones ayudar a llevar los modelos de machine learning a producción. • MLOps le permite realizar un seguimiento / gestionar versiones / auditar / certificar / reutilizar cada activo en su ciclo de vida de ML y proporciona servicios de orquestación para agilizar la gestión de este ciclo de vida.
- 15. MLOps: Objetivo
- 16. Beneficios MLOps • Reproducibilidad • El código impulsa las implementaciones • Los pipelines son reproducibles y verificables • Todos los artefactos se pueden etiquetar y auditar • Validación • Mejores prácticas de Ingeniería de Software para el control de calidad • Comparaciones sin conexión de la calidad del modelo • Minimice el bias y habilite la explicabilidad • Automatización • Capacidades de implementación controlada • Comparación en vivo del rendimiento previsto frente al esperado • Resultados retroalimentados para observar la deriva y mejorar el modelo
- 17. Diferencias entre DevOps y MLOps • Control de versiones de datos / modelo! = Control de versiones de código: cómo versionar conjuntos de datos a medida que cambian el esquema y los datos de origen • Los requisitos de seguimiento de auditoría digital cambian cuando se trata de código + datos (potencialmente del cliente) • La reutilización de modelos es diferente a la reutilización de software, ya que los modelos deben ajustarse en función de los datos de entrada / escenario. • Para reutilizar un modelo, es posible que deba ajustar / transferir el aprendizaje en él (lo que significa que necesita un pipeline de entrenamiento) • Los modelos tienden a deteriorarse con el tiempo y necesita la capacidad de volver a capacitarlos a pedido para garantizar que sigan siendo útiles en un contexto de producción.
- 19. Neptune • Neptune es un rastreador de experimentos centrado en Python. Es un servicio alojado. • Los experimentos se rastrean mediante el uso de enlaces de biblioteca para registrar parámetros (modelo), resultados de evaluación y cargar artefactos (como modelos, hashes de datos de entrenamiento o incluso código). La biblioteca puede rastrear el uso del hardware y el progreso del experimento. Proporcionan una API para consultar los resultados del experimento. Esto se puede utilizar para alimentar las canalizaciones de CI / CD para la implementación del modelo. Los resultados se pueden analizar y comparar en un sitio web. También hay opciones colaborativas. Neptune tiene integraciones con portátiles Jupyter, varias bibliotecas ML, visualizadores (HiFlow, TensorBoard), otros rastreadores (MLFlow) y ofertas externas (Amazon Sagemaker).
- 20. MLFlow • MLFlow es un rastreador de experimentos y un servidor de modelos genérico. Puede ser autohospedado. • Los experimentos se rastrean mediante el uso de enlaces de biblioteca para registrar parámetros (modelo), resultados de evaluación y cargar artefactos (como modelos, hashes de datos de entrenamiento o incluso código). Los artefactos se pueden registrar en el almacenamiento local, remoto o en la nube (S3, GFS, etc.). Los resultados se pueden analizar a través de una interfaz de usuario web y la exportación CSV está disponible. Los modelos se empaquetan como un contenedor alrededor del formato subyacente (Sklearn, XGBoost, Torch, etc.). Se pueden enviar a Spark para la inferencia por lotes o se pueden servir a través de REST. Hay API de CLI, Python, R, Java y REST para una mayor integración con las canalizaciones de CI / CD. Los modelos se pueden enviar a servicios en la nube (SageMaker, AzureML, ...).
- 21. Kubeflow • Kubeflow es esencialmente una versión autohospedada de la plataforma de inteligencia artificial de Google. Utiliza Kubernetes para abstraer la infraestructura. • Kubeflow puede implementar cuadernos de Jupyter, ejecutar canalizaciones para el procesamiento de datos y el entrenamiento de modelos (programado, bajo demanda), organizar ejecuciones, archivar modelos y otros artefactos, y exponer modelos a través de puntos finales. Las canalizaciones son gráficos de cálculo y se describen en Python con un DSL. Sus componentes se envuelven como imágenes de Docker. Se integra con GCP para que pueda escalar elásticamente a la computación y el almacenamiento en la nube (p. Ej., Entrenamiento de modelos distribuidos). También se integra con ofertas como BigQuery o Dataproc. La solución es pesada y compleja, pero permite una rápida ampliación. Es especialmente aplicable si la infraestructura ya se administra a través de Kubernetes.
- 22. CML • Continuous Machine Learning es una herramienta CLI de código abierto para implementar (CI / CD) con un enfoque en MLOps. • Permite automatizar los flujos de trabajo de desarrollo, incluido el aprovisionamiento de máquinas, el entrenamiento y la evaluación de modelos, la comparación de experimentos de aprendizaje automático en el historial del proyecto y el monitoreo de conjuntos de datos cambiantes. • CML puede ayudar a entrenar y evaluar modelos, y luego generar un informe visual con resultados y métricas, automáticamente en cada solicitud de extracción. https://github.com/iterative/cml/ https://cml.dev/
- 23. Workshop • Descarga el tutorial https://drive.google.com/drive/folders/1h4tJ6q6VKB1oYCYsuGzR9J0qd 4a5rGHy?usp=sharing
Notas del editor
- MLOps es una práctica de colaboración entre científicos de datos, ingenieros de software y operaciones para automatizar la implementación y la gobernanza de los servicios de ML. Un aspecto crítico de MLOps es la implementación de modelos y pipelines de ML mediante herramientas automatizadas. Este taller describe cómo se puede lograr con varias tecnologías.
- Los sistemas de ML generalmente tienen dos fases clave: entrenamiento e inferencia (predicción). La fase de entrenamiento busca manipular los datos de origen en características que se utilizan para entrenar un modelo y evaluar el modelo entrenado. Entrenamiento La mayor parte de la complejidad de los proyectos de aprendizaje automático se encuentra en la fase de entrenamiento. Con el fin de mitigar esta complejidad, la fase de entrenamiento de los proyectos de ML a menudo se diseñan como una canalización de pasos dependientes (conocido como gráfico acíclico dirigido). Normalmente, una canalización de aprendizaje automático contendrá operaciones que: Preparar e integrar datos Ingeniería de características Entrenamiento / ajuste de modelos Ajuste de hiperparámetros Evaluación del modelo La fase de inferencia generalmente carga el modelo previamente entrenado y lo usa para ofrecer predicciones. En muchos casos, la fase de inferencia servirá al modelo a través de una API REST o mediante un servicio para predicciones por lotes.
- El proceso de ciencia de datos en equipo (TDSP) es una metodología de ciencia de datos ágil e iterativa para proporcionar soluciones de análisis predictivo y aplicaciones inteligentes de manera eficiente. TDSP ayuda a mejorar la colaboración y el aprendizaje en equipo al sugerir cómo los roles de equipo funcionan mejor juntos. TDSP incluye procedimientos recomendados y estructuras de líderes del sector para ayudar a implementar correctamente iniciativas de ciencia de datos. El objetivo es ayudar a las empresas a que se den cuenta de las ventajas de su programa de análisis. TDSP tiene los siguientes componentes principales: Una definición de ciclo de vida de ciencia de datos Una estructura de proyecto estandarizada Infraestructura y recursos recomendados para proyectos de ciencia de datos Herramientas y utilidades recomendadas para la ejecución de proyectos El proceso de ciencia de datos en equipo (TDSP) proporciona un ciclo de vida para estructurar el desarrollo de los proyectos de ciencia de datos. En el ciclo de vida se describen todos los pasos que siguen los proyectos correctos que se enviarán como parte de aplicaciones inteligentes. Estas aplicaciones implementan modelos de aprendizaje o inteligencia artificial de máquina para realizar un análisis predictivo. Los proyectos de ciencia de datos exploratorios o proyectos de análisis improvisados también se pueden beneficiar del uso de este proceso. Pero, en estos casos, puede que algunos de los pasos descritos no sean necesarios. El ciclo de vida describe las fases principales por las que pasan normalmente los proyectos, a menudo de forma iterativa: Conocimiento del negocio Adquisición y comprensión de los datos Modelado Implementación
- En el tema Team Data Science Process lifecycle (Ciclo de vida del proceso de ciencia de datos en equipo) se describen los objetivos, las tareas y los artefactos de documentación de cada fase del ciclo de vida de TDSP. Estas tareas y artefactos están asociados con roles de proyecto: Arquitecto de soluciones Jefe de proyecto Ingeniero de datos Científico de datos Desarrollador de aplicaciones Responsable de proyecto
- DevOps (acrónimo inglés de development -desarrollo- y operations -operaciones-) es un conjunto de prácticas que agrupan el desarrollo de software ( Dev ) y las operaciones de TI ( Ops ). Su objetivo es hacer más rápido el ciclo de vida del desarrollo de software y proporcionar una entrega continua de alta calidad. CI / CD significa "Integración continua / Entrega continua" y es un concepto clave de DevOps. En su nivel más básico, CI / CD Pipelines son solo scripts que se activan cada vez que se cambia el código (por ejemplo, como resultado de una inserción o fusión), creando automáticamente activos de software, ejecutando pruebas e implementando código.
- El nivel de automatización de las canalizaciones de datos, modelo de aprendizaje automático y código determina la madurez del proceso de aprendizaje automático. Con una mayor madurez, también aumenta la velocidad para el entrenamiento de nuevos modelos. El objetivo de un equipo de MLOps es automatizar la implementación de modelos ML en el sistema de software central o como un componente de servicio. Esto significa automatizar los pasos completos del flujo de trabajo de ML sin ninguna intervención manual. Los desencadenantes de la implementación y el entrenamiento de modelos automatizados pueden ser eventos de calendario, mensajes, eventos de monitoreo, así como cambios en los datos, el código de entrenamiento del modelo y el código de la aplicación. Las pruebas automatizadas ayudan a descubrir problemas rápidamente y en las primeras etapas. Esto permite corregir errores rápidamente y aprender de los errores. Para adoptar MLOps, vemos tres niveles de automatización, comenzando desde el nivel inicial con el entrenamiento y la implementación del modelo manual, hasta ejecutar las canalizaciones de ML y CI / CD automáticamente. Proceso manual. Este es un proceso típico de ciencia de datos, que se realiza al comienzo de la implementación de ML. Este nivel tiene un carácter experimental e iterativo. Cada paso de cada canal, como la preparación y validación de datos, el entrenamiento y las pruebas de modelos, se ejecutan manualmente. La forma común de procesar es utilizar herramientas de desarrollo rápido de aplicaciones (RAD), como Jupyter Notebooks. Automatización de la canalización de ML. El siguiente nivel incluye la ejecución del entrenamiento de modelos de forma automática. Introducimos aquí la formación continua del modelo. Siempre que hay nuevos datos disponibles, se activa el proceso de reentrenamiento del modelo. Este nivel de automatización también incluye pasos de validación de datos y modelos. Automatización de canalizaciones CI / CD. En la etapa final, presentamos un sistema CI / CD para realizar implementaciones de modelos ML rápidas y confiables en producción. La principal diferencia con el paso anterior es que ahora creamos, probamos e implementamos automáticamente los datos, el modelo de aprendizaje automático y los componentes de la canalización de capacitación de aprendizaje automático.
- ML Ops encapsula aspectos de la ingeniería de datos, la ingeniería de software y la ciencia de datos para proporcionar una vista de un extremo a otro de la aplicación de la inteligencia de los datos a un caso de uso empresarial. La mayoría de los proyectos de ciencia de datos permanecen en los laboratorios porque la integración con los entornos de producción es extremadamente complicada, manual y propensa a errores. El proceso completo de MLOps incluye tres fases amplias de "Diseño de la aplicación impulsada por ML", "Experimentación y desarrollo de ML" y "Operaciones de ML". La primera fase está dedicada a la comprensión empresarial, la comprensión de los datos y el diseño del software basado en ML. En esta etapa, identificamos a nuestro usuario potencial, diseñamos la solución de aprendizaje automático para resolver su problema y evaluamos el desarrollo posterior del proyecto. Principalmente, actuaríamos dentro de dos categorías de problemas, ya sea aumentando la productividad del usuario o aumentando la interactividad de nuestra aplicación. Inicialmente, definimos los casos de uso de ML y los priorizamos. La mejor práctica para los proyectos de ML es trabajar en un caso de uso de ML a la vez. Además, la fase de diseño tiene como objetivo inspeccionar los datos disponibles que serán necesarios para entrenar nuestro modelo y especificar los requisitos funcionales y no funcionales de nuestro modelo ML. Deberíamos utilizar estos requisitos para diseñar la arquitectura de la aplicación ML, establecer la estrategia de servicio y crear un conjunto de pruebas para el futuro modelo ML. La fase de seguimiento “Experimentación y Desarrollo de ML” está dedicada a verificar la aplicabilidad de ML para nuestro problema mediante la implementación de Prueba de Concepto para el Modelo de ML. Aquí, ejecutamos pasos iterativamente diferentes, como identificar o pulir el algoritmo ML adecuado para nuestro problema, ingeniería de datos e ingeniería de modelos. El objetivo principal en esta fase es ofrecer un modelo de aprendizaje automático de calidad estable que ejecutaremos en producción. El enfoque principal de la fase de “Operaciones de ML” es entregar el modelo de ML desarrollado previamente en producción mediante el uso de prácticas de DevOps establecidas, como pruebas, control de versiones, entrega continua y monitoreo. Las tres fases están interconectadas y se influyen entre sí. Por ejemplo, la decisión de diseño durante la etapa de diseño se propagará a la fase de experimentación y finalmente influirá en las opciones de implementación durante la fase de operaciones final.
- ML a escala empresarial es complejo. Las empresas que no cuentan con equipos dedicados para construir la infraestructura de ML no están logrando llevar sus modelos a producción y resolver sus necesidades comerciales. Afortunadamente, las principales empresas de tecnología como Uber, LinkedIn, Twitter, Facebook y Google ya han desarrollado y abierto parte de su infraestructura de ML que podemos utilizar. En esta publicación, quiero compartir nuestras experiencias en la creación de una solución MLOps empresarial usando Kubeflow, que Google abrió hace poco más de un año.
- La siguiente lista de conceptos, que creo que deberían considerarse como parte de un marco MLOps: Plataforma de desarrollo: una plataforma colaborativa para realizar experimentos de aprendizaje automático y potenciar la creación de modelos de aprendizaje automático por parte de científicos de datos debe considerarse parte del marco de MLOps. Esta plataforma debe permitir un acceso seguro a las fuentes de datos (por ejemplo, desde los flujos de trabajo de ingeniería de datos). Queremos que el traspaso de la capacitación de ML a la implementación sea lo más fluido posible, que es más probable que sea el caso de una plataforma de este tipo que los modelos de ML desarrollados en diferentes entornos locales. Prueba unitaria del modelo: cada vez que creamos, cambiamos o reentrenamos un modelo, deberíamos validar automáticamente la integridad del modelo, p. Ej. - debe cumplir con el rendimiento mínimo en un equipo de prueba - debería funcionar bien en conjuntos de datos sintéticos específicos de casos de uso Control de versiones: debería ser posible retroceder en el tiempo para inspeccionar todo lo relacionado con un modelo determinado, por ejemplo, qué datos y código se utilizó. ¿Por qué? Porque si algo se rompe, debemos poder retroceder en el tiempo y ver por qué. Registro de modelos: debe haber una descripción general de los modelos de AA implementados y retirados, su historial de versiones y la etapa de implementación de cada versión. ¿Por qué? Si algo se rompe, podemos revertir una versión previamente archivada a producción. Gobierno del modelo: solo determinadas personas deberían tener acceso para ver la formación relacionada con un modelo determinado. Debe haber control de acceso para quién puede solicitar / rechazar / aprobar las transiciones entre las etapas de implementación (p. Ej., Desarrollo a prueba y producción) en el registro del modelo. Implementaciones: la implementación puede ser muchas cosas, pero en esta publicación, considero el caso en el que queremos implementar un modelo en la infraestructura de la nube y exponer una API, que permite a otras personas consumir y usar el modelo, es decir, no estoy considerando casos en los que queremos implementar modelos de AA en sistemas integrados. Las implementaciones de modelos eficientes en la infraestructura adecuada deben: - admite múltiples marcos de ML + modelos personalizados - tener especificaciones de API bien definidas (por ejemplo, Swagger / OpenAPI) - soporte de servidores modelo en contenedores
- Supervisión: seguimiento de las métricas de rendimiento (rendimiento, tiempo de actividad, etc.). ¿Por qué? Si de repente un modelo comienza a mostrar errores o a ser inesperadamente lento, debemos saberlo antes de que el usuario final se queje para poder solucionarlo. Retroalimentación: necesitamos enviar información al modelo sobre su rendimiento. ¿Por qué? Por lo general, ejecutamos predicciones en nuevas muestras en las que aún no conocemos la verdad básica. Sin embargo, a medida que aprendemos la verdad, debemos informar al modelo para informar sobre qué tan bien está funcionando. Pruebas A / B: no importa cuán sólida sea la validación cruzada que pensamos que estamos haciendo, nunca sabemos cómo funcionará el modelo hasta que realmente se implemente. Debería ser fácil realizar experimentos A / B con modelos en vivo dentro del marco MLOps. Detección de deriva: normalmente, cuanto más tiempo se implementa un modelo determinado, peor se vuelve a medida que cambian las circunstancias en comparación con cuando se entrenó el modelo. Podemos intentar monitorear y alertar sobre estas diferentes circunstancias o "desviaciones" antes de que se vuelvan demasiado graves: - Deriva de concepto: cuando la relación entre entrada y salida ha cambiado – Deriva de predicción: cambios en las predicciones, pero el modelo aún se mantiene – Desviación de la etiqueta: cambio en los resultados del modelo en comparación con los datos de entrenamiento – Deriva de características: cambio en la distribución de los datos de entrada del modelo Detección de valores atípicos: si un modelo implementado recibe una muestra de entrada que es significativamente diferente de cualquier cosa observada durante el entrenamiento, podemos intentar identificar esta muestra como un valor atípico potencial, y la predicción devuelta debe marcarse como tal, lo que indica que el usuario final debe tenga cuidado al confiar en la predicción. Detección de ataques adversarios: debemos ser advertidos cuando las muestras adversarias atacan nuestros modelos (por ejemplo, alguien que intenta abusar / manipular el resultado de nuestros algoritmos). Interpretabilidad: las implementaciones de ML deben admitir puntos finales que devuelvan la explicación de nuestra predicción, por ejemplo, a través de valores SHAP. ¿Por qué? para muchos casos de uso, una predicción no es suficiente y el usuario final necesita saber por qué se realizó una predicción determinada. Gobernanza de las implementaciones: no solo necesitamos restricciones de acceso sobre quién puede ver los datos, modelos entrenados, etc., sino también sobre quién puede eventualmente usar los modelos implementados. Estos modelos implementados a menudo pueden ser tan confidenciales como los datos en los que fueron entrenados. Centrado en los datos: en lugar de centrarse en el rendimiento y las mejoras del modelo, tiene sentido que un marco MLOps también permita un mayor enfoque en cómo el usuario final puede mejorar la calidad y la amplitud de los datos.
- MLOps solution using Kubeflow, that Google open sourced a little over a year ago. "Kubeflow is an open source Kubernetes-native platform for developing, orchestrating, deploying, and running scalable and portable machine learning workloads" Its a Machine Learning Infrastructure Kubeflow is a Cloud Native Machine Learning Toolkit.