ML Ops: Machine Learning como disciplina de ingeniería

A medida que el ML madura desde la investigación hasta las soluciones comerciales aplicadas, también debemos mejorar la madurez de sus procesos operativos.

11 min readJan 21, 2020

Entonces, su empresa decidió invertir en aprendizaje automático. Tiene un equipo talentoso de científicos de datos que producen modelos para resolver problemas importantes que estaban fuera del alcance hace solo unos años. Todas las métricas de rendimiento se ven geniales, las demostraciones hacen que los directivos se suban al proyecto y los ejecutivos preguntan qué tan pronto puede tener un modelo en producción.

Debería ser bastante rápido, usted piensa. Después de todo, ya resolvió todos los problemas avanzados de ciencias y matemáticas, por lo que todo lo que queda es el trabajo de TI de rutina. ¿Qué tan difícil puede ser?

Pues resulta bastante difícil. Deeplearning.ai informa que “solo el 22 por ciento de las empresas que utilizan el ML han implementado con éxito un modelo”. ¿Qué lo hace tan difícil? ¿Y qué debemos hacer para mejorar la situación?

Comencemos mirando las causas raíz.

Desafíos

En el mundo del desarrollo de software tradicional, un conjunto de prácticas conocidas como DevOps ha permitido enviar software a producción en minutos y mantenerlo funcionando de manera confiable. DevOps se basa en herramientas, automatización y flujos de trabajo para abstraer la complejidad accidental y permitir a los desarrolladores centrarse en los problemas reales que deben resolverse. DevOps ayuda a romper la barrera entre desarrollo (Cambios constantes) y operaciones (la necesidad de mantener estable el sistema). Este enfoque ha tenido tanto éxito que muchas compañías ya son expertas en él, entonces, ¿por qué no podemos simplemente seguir haciendo lo mismo para ML?

La causa raíz es que hay una diferencia fundamental entre ML y el software tradicional: ML no es solo código, es código más datos . Un modelo ML, el artefacto que terminas poniendo en producción, se crea aplicando un algoritmo a una gran cantidad de datos de entrenamiento, lo que afectará el comportamiento del modelo en producción. De manera crucial, el comportamiento del modelo también depende de los datos de entrada que recibirá en el momento de la predicción, que no puede saber de antemano.

Si bien el código está cuidadosamente diseñado en un entorno de desarrollo controlado, los datos provienen de esa fuente de entropía interminable conocida como “el mundo real”. Nunca deja de cambiar, y no puedes controlar cómo va a cambiar. Una forma útil de pensar en su relación es como si el código y los datos vivieran en planos separados, que comparten la dimensión del tiempo pero son independientes en todos los demás. El desafío de un proceso de ML es crear un puente entre estos dos planos de forma controlada.

El código y los datos evolucionan independientemente. Podemos pensar en ellos como planos separados con una dimensión de tiempo común.

Esta desconexión fundamental provoca varios desafíos importantes que deben ser resueltos por cualquiera que intente poner un modelo ML en producción con éxito, por ejemplo:

● Despliegue lento, inestable e inconsistente

● Falta de reproducibilidad

● Reducción del rendimiento (sesgo de servicio)

Dado que la palabra “datos” ya se ha usado varias veces en este artículo, es posible que esté pensando en otra disciplina que podría rescatarnos: Ingeniería de datos . Y estaría en lo cierto: Data Engineering o ingeniería de Datos proporciona herramientas y conceptos importantes que son indispensables para resolver el rompecabezas de ML en la producción. Para descifrarlo, necesitamos combinar prácticas de DevOps e Ingeniería de Datos, agregando algunas que sean exclusivas de ML.

Por lo tanto, ML Ops se puede definir por esta intersección:

ML Ops es la intersección de Machine Learning, DevOps y Data Engineering

Por lo tanto, podríamos definir ML Ops de la siguiente manera:

ML Ops es un conjunto de prácticas que combinan Machine Learning, DevOps e Ingeniería de datos, cuyo objetivo es implementar y mantener sistemas ML en producción de manera confiable y eficiente.

Veamos ahora lo que esto realmente significa con más detalle, al examinar las prácticas individuales que se pueden utilizar para lograr los objetivos de ML Ops.

Practicas

Equipos híbridos

Como ya hemos establecido que la producción de un modelo ML requiere un conjunto de habilidades que hasta ahora se consideraban separadas, para tener éxito necesitamos un equipo híbrido que, en conjunto, que cubra ese rango de habilidades. Por supuesto, es posible que una sola persona sea lo suficientemente buena en todos ellos, y en ese caso podríamos llamar a esa persona un ingeniero de ML Ops . Pero el escenario más probable en este momento es que un equipo exitoso incluiría un científico de datos o un ingeniero de ML, un ingeniero de DevOps y un ingeniero de datos.

La composición exacta, la organización y los títulos del equipo pueden variar, pero la parte esencial es darse cuenta de que un Científico de Datos por sí solo no puede lograr los objetivos de ML Ops. Incluso si una organización incluye todas las habilidades necesarias, no tendrá éxito si no trabajan en estrecha colaboración.

Otro cambio importante es que los científicos de datos deben ser competentes en habilidades básicas de ingeniería de software como la modularización, reutilización, prueba y control de versiones de código; lograr que un modelo funcione bien en un cuaderno desordenado no es suficiente. Es por eso que muchas compañías están adoptando el título de Ingeniero ML, que enfatiza estas habilidades. En muchos casos, los ingenieros de ML están, en la práctica, realizando muchas de las actividades requeridas para ML Ops.

Flujos de ML

Uno de los conceptos centrales de la ingeniería de datos es el flujo de datos . Un flujo de datos es una serie de transformaciones que se aplican a los datos entre su origen y un destino. Por lo general, se definen como un gráfico en el que cada nodo es una transformación y los bordes representan dependencias u orden de ejecución. Existen muchas herramientas especializadas que ayudan a crear, administrar y ejecutar estos flujos. Los flujos de datos también se pueden denominar flujos de ETL (extraer, transformar y cargar en ingles).

Los modelos de ML siempre requieren algún tipo de transformación de datos, que generalmente se logra a través de código o incluso celdas en un cuaderno de Jupyter, lo que hace que sean difíciles de administrar y ejecutar de manera confiable. Cambiar a flujos de datos adecuados ofrece muchas ventajas en la reutilización de código, la visibilidad del tiempo de ejecución, la administración y la escalabilidad.

Dado que el entrenamiento de ML también puede considerarse como una transformación de datos, es natural incluir los pasos de ML específicos en el flujo de datos en sí, convirtiéndolo en un flujo de ML . La mayoría de los modelos necesitarán 2 versiones de la tubería: una para entrenamiento y otra para servir. Esto se debe a que, por lo general, los formatos de datos y la forma de acceder a ellos son muy diferentes entre cada momento, especialmente para los modelos que se sirven en solicitudes en tiempo real (a diferencia de las ejecuciones de predicción por lotes).

*Representación visual de un flujo ML en* *Kubeflow Pipelines*

Un flujo de ML es un artefacto de código puro, independiente de instancias de datos específicas. Esto significa que es posible rastrear sus versiones en el control de origen y automatizar su implementación con una canalización de CI / CD regular , una práctica central de DevOps. Esto nos permite conectar el código y los planos de datos de manera estructurada y automatizada:

*ML pipelines conectan datos y código para producir modelos y predicciones*

Tenga en cuenta que hay dos flujos de ML distintos: el flujo de entrenamiento y el flujo de servicio. Lo que tienen en común es que las transformaciones de datos que realizan necesitan producir datos en el mismo formato, pero sus implementaciones pueden ser muy diferentes. Por ejemplo, el flujo de capacitación generalmente se ejecuta sobre archivos por lotes que contienen todas las funciones, mientras que el flujo de servicio a menudo se ejecuta en línea y recibe solo una parte de las funciones en las solicitudes, recuperando el resto de una base de datos.

Sin embargo, es importante asegurarse de que estos dos flujos sean consistentes, por lo que uno debe intentar reutilizar el código y los datos siempre que sea posible. Algunas herramientas pueden ayudar con ese objetivo, por ejemplo:

● Los marcos de transformación como TensorFlow Transform pueden garantizar que los cálculos basados en estadísticas del conjunto de entrenamiento, como promedios y desviaciones estándar para la normalización, sean consistentes.

● Los Almacenes de funciones son bases de datos que almacenan valores que no forman parte de una solicitud de predicción, por ejemplo, funciones que se calculan sobre el historial de un usuario.

Versionado de modelos y de datos

Para tener reproducibilidad, el seguimiento de versiones consistentes es esencial. En un mundo de software tradicional, el código de versiones es suficiente, porque todo el comportamiento está definido por él. En ML, también necesitamos rastrear las versiones del modelo, junto con los datos utilizados para entrenarlo, y alguna metainformación como hiper-parámetros de entrenamiento.

Los modelos y metadatos se pueden rastrear en un sistema de control de versiones estándar como Git, pero los datos a menudo son demasiado grandes y mutables para que sean eficientes y prácticos. También es importante evitar vincular el ciclo de vida del modelo con el ciclo de vida del código, ya que la capacitación del modelo a menudo ocurre en un horario diferente. También es necesario versionar los datos y vincular cada modelo entrenado a las versiones exactas de código, datos e hiper-parámetros que se usaron. La solución ideal sería una herramienta especialmente diseñada, pero hasta ahora no existe un consenso claro en el mercado y se utilizan muchos esquemas, la mayoría basados en convenciones de almacenamiento de archivos / objetos y bases de datos de metadatos.

Validación de Modelos

Otra práctica estándar de DevOps es la automatización de pruebas, generalmente en forma de pruebas unitarias y pruebas de integración. Pasar estas pruebas es un requisito previo para que se implemente una nueva versión. Tener pruebas automatizadas completas puede dar una gran confianza a un equipo, acelerando drásticamente el ritmo de las implementaciones de producción.

Los modelos ML son más difíciles de probar, porque ningún modelo da resultados 100% correctos. Esto significa que las pruebas de validación del modelo deben ser necesariamente de naturaleza estadística, en lugar de tener un estado binario de pasa / falla. Para decidir si un modelo es lo suficientemente bueno para la implementación, uno debe decidir las métricas correctas para rastrear y el umbral de sus valores aceptables, generalmente de forma empírica, y a menudo en comparación con modelos o puntos de referencia anteriores.

Tampoco es suficiente rastrear una sola métrica para la totalidad del conjunto de validación. Así como las buenas pruebas unitarias deben probar varios casos, la validación del modelo debe hacerse individualmente para segmentos relevantes de los datos, conocidos como cortes. Por ejemplo, si el género podría ser una característica relevante de un modelo, directa o indirectamente, rastrear métricas separadas para hombres, mujeres y otros géneros. De lo contrario, el modelo podría tener problemas de equidad o tener un rendimiento inferior en segmentos importantes.

Si logra que los modelos sean validados de manera automatizada y confiable, junto con el resto de la línea de ML, incluso podría cerrar el ciclo e implementar la capacitación de modelos en línea, si tiene sentido para el caso de uso.

Validación de datos

Un buen flujo de datos generalmente comienza validando los datos de entrada. Las validaciones comunes incluyen formato y tamaño de archivo, tipos de columna, valores nulos o vacíos y valores no válidos. Todo esto es necesario para el entrenamiento y la predicción de ML, de lo contrario, podría terminar con un modelo que se porta mal y rascarse la cabeza buscando la razón. La validación de datos es análoga a las pruebas unitarias en el dominio de código .

Además de las validaciones básicas que realiza cualquier flujo de datos, los flujos de ML también deben validar las propiedades estadísticas de nivel superior de la entrada. Por ejemplo, si la desviación promedio o estándar de una característica cambia considerablemente de un conjunto de datos de entrenamiento a otro, probablemente afectará el modelo entrenado y sus predicciones. Esto podría ser un reflejo del cambio real en los datos o podría ser una anomalía causada por la forma en que se procesan los datos, por lo que es importante verificar y descartar errores sistémicos como causas que podrían contaminar el modelo, y corregirlos si es necesario

*Un ejemplo de perfil de datos estadísticos en* *TensorFlow Data Validation*

Supervisión

El monitoreo de los sistemas de producción es esencial para mantenerlos funcionando bien. Para los sistemas de ML, el monitoreo se vuelve aún más importante, porque su rendimiento depende no solo de factores sobre los que tenemos algún control, como la infraestructura y nuestro propio software, sino también de los datos, sobre los cuales tenemos mucho menos control. Por lo tanto, además de monitorear métricas estándar como latencia, tráfico, errores y saturación , también necesitamos monitorear el desempeño de predicción del modelo.

Un desafío obvio con el monitoreo del desempeño del modelo es que generalmente no tenemos una etiqueta verificada para comparar las predicciones de nuestro modelo, ya que el modelo funciona con datos nuevos. En algunos casos, podríamos tener alguna forma indirecta de evaluar la efectividad del modelo, por ejemplo, midiendo la tasa de clics para un modelo de recomendación. En otros casos, podríamos tener que depender de comparaciones entre períodos de tiempo, por ejemplo, calculando un porcentaje de clasificaciones positivas por hora y alertando si se desvía en más de un pequeño porcentaje del promedio de ese tiempo.

Al igual que al validar el modelo, también es importante monitorear las métricas en los segmentos, y no solo globalmente, para poder detectar problemas que afectan a segmentos específicos.

Resumen

A medida que el ML madura desde la investigación hasta las soluciones comerciales aplicadas, también debemos mejorar la madurez de sus procesos operativos. Afortunadamente, podemos extender muchas prácticas de disciplinas anteriores a ML.

La siguiente tabla resume las prácticas principales de ML Ops y cómo se relacionan con las prácticas de DevOps y Data Engineering:

Esta es una disciplina nueva y emocionante, con herramientas y prácticas que probablemente evolucionen muy rápidamente. Ciertamente, hay muchas oportunidades para desarrollar y aplicar técnicas de producción a ML.

Un agradecimiento especial a CrispinV por revisar la traducción al español de este artículo.