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
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.
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.