👨🏼‍🔧 🐸 🕷️ ¿Por qué necesitamos DevOps en el campo de datos ML? 👩🏿‍🌾 🐴 💨

Implementar el aprendizaje automático (ML) en producción no es una tarea fácil, pero de hecho, es un orden de magnitud más difícil que implementar software convencional. Como resultado, la mayoría de los proyectos de ML nunca verán la luz del día, y la producción, ya que la mayoría de las organizaciones se rinden y dejan de intentar usar ML para promocionar sus productos y servir a los clientes.

Hasta donde podemos ver, el obstáculo fundamental para la mayoría de los equipos para crear e implementar ML en la producción en la escala esperada es que todavía no hemos podido incorporar las prácticas de DevOpsen aprendizaje automático El proceso de creación y despliegue de modelos ML está parcialmente revelado por las soluciones MLOps que ya se han lanzado, pero carecen de soporte de uno de los aspectos más difíciles de ML: los datos.

En este artículo, discutimos por qué la industria necesita soluciones DevOps para datos de ML y cómo las dificultades únicas de los datos de ML obstaculizan los esfuerzos para poner en práctica ML y desplegarlos en la producción. El artículo describe el vacío en el ecosistema de infraestructura de ML actual y sugiere llenarlo con Tecton, una plataforma de datos centralizada para el aprendizaje automático. Haga clic aquí para leer un artículo de mi cofundador Mike para obtener más detalles sobre el lanzamiento de Tecton.

Tecton fue creado por un equipo de ingenieros que crearon plataformas internas de ML para empresas como Uber, Google, Facebook, Twitter, Airbnb, AdRoll y Quora. Las importantes inversiones de estas compañías en ML permitieron el desarrollo de procesos y herramientas para el uso extensivo de ML para sus organizaciones y productos. Las lecciones presentadas en este artículo, así como la plataforma Tecton en sí, se basan en gran medida en la experiencia de nuestro equipo de implementación de ML en producción en los últimos años.

¿Recuerdas el momento en que el lanzamiento del software fue largo y doloroso?

El proceso de desarrollo e implementación de software hace veinte años y el proceso de desarrollo de aplicaciones ML de nuestros días tienen mucho en común: los sistemas de retroalimentación resultaron ser increíblemente largos, y cuando llegó el lanzamiento del producto, sus requisitos y diseño iniciales ya habían quedado obsoletos. Y luego, al final de los años noventa, surgió un conjunto de mejores prácticas para el desarrollo de software en forma de DevOps , que proporciona métodos para administrar el ciclo de vida del desarrollo y nos permite lograr mejoras rápidas y continuas.

El enfoque DevOps permite a los ingenieros trabajar en una base de código común bien definida. Una vez que un cambio por fases está listo para su implementación, el ingeniero lo valida a través de un sistema de control de versiones. El proceso de integración y entrega continua (CD / CI) toma los cambios más recientes, realiza pruebas unitarias, crea documentación, realiza pruebas de integración y, como resultado, libera de manera controlada los cambios en la producción o prepara un lanzamiento para su distribución.

Higo. 1: proceso típico de DevOps

Características clave de DevOps:

Los programadores poseen su código de principio a fin. Están capacitados y son totalmente responsables de cada línea de código en producción. Este sentido de propiedad generalmente mejora la calidad del código, así como la disponibilidad y confiabilidad de los programas.
Los equipos pueden repetir procesos rápidamente y no están limitados por ciclos de meses del modelo en cascada. En cambio, pueden probar nuevas características con usuarios reales casi de inmediato.
Los problemas de rendimiento y fiabilidad se detectan y analizan rápidamente. Si las métricas de rendimiento caen inmediatamente después de la última implementación, se desencadena una reversión automática y es muy probable que los cambios que causaron la implementación en el código provoquen la caída de las métricas.

En estos días, muchos equipos de desarrollo han tomado un enfoque tan integrado como base.

... En general, el despliegue de ML todavía es largo y doloroso

Al contrario del desarrollo de software, no existen procesos bien definidos y totalmente automatizados para la producción rápida en el análisis de datos. El proceso de crear una aplicación ML y desplegarla en un producto consta de varios pasos:

Fig. 2: los especialistas en análisis de datos deben coordinar su trabajo entre varios equipos en diferentes áreas

Descubrimiento y acceso a datos de origen. Los especialistas en ciencia de datos en la mayoría de las empresas dedican hasta el 80% de su tiempo a buscar datos fuente para modelar su problema. Esto a menudo requiere una coordinación interfuncional con los ingenieros de datos y el equipo regulador.
. , . , , .
. . ( ).
Despliegue e integración del modelo. Este paso generalmente implica la integración con un servicio que utiliza el modelo para pronosticar. Por ejemplo, la aplicación móvil de un minorista en línea que utiliza un modelo de recomendación para predecir las ofertas de productos.
Configuración de monitoreo. Una vez más, para asegurarse de que el modelo ML y los procesos de datos funcionen correctamente, se requiere la ayuda de los programadores.

Como resultado, los equipos de ML enfrentan los mismos problemas que los programadores enfrentaron hace veinte años:

Los expertos en ciencia de datos no tienen plena propiedad del ciclo de vida de los modelos y la funcionalidad. Para implementar sus ediciones y apoyarlos en la producción, tienen que confiar en otros.
data science . . . , , data science, , , , , .

. 3: ,

. data science, . , , , .

DevOps ML . DevOps ML data

Tales plataformas MLOps como Sagemaker Kubeflow y se mueven en la dirección correcta en el camino para ayudar a las empresas a simplificar la producción de ML, para que podamos observar cómo MLOps introduce principios y herramientas DevOps en ML. Para comenzar, necesitan inversiones iniciales bastante decentes, pero después de una integración adecuada pueden expandir las capacidades de los especialistas en ciencia de datos en el campo de la capacitación, la gestión y la producción de modelos ML.

Desafortunadamente, la mayoría de las herramientas MLOps tienden a enfocarse en el flujo de trabajo alrededor del modelo en sí (capacitación, implementación, administración), lo que crea una serie de dificultades para los NM existentes. Las aplicaciones de ML se definen por código, modelos y datos.. Su éxito depende de la capacidad de crear datos ML de alta calidad y entregarlos a la producción de manera bastante rápida y estable ... de lo contrario, esta es otra "basura en la basura". El siguiente diagrama, especialmente seleccionado y adaptado del trabajo de Google sobre deuda técnica en ML, ilustra los elementos "centrados en datos" y "centrados en modelos" en los sistemas de ML. Hoy en día, las plataformas MLOps ayudan con muchos elementos "centrados en el modelo", pero solo con unos pocos "centrados en los datos" o no los afectan en absoluto:

Fig. 4: Modelo y elementos atacéntricos de sistemas ML. Hoy en día, los elementos centrados en el modelo están cubiertos en gran medida por los sistemas MLOps.

La siguiente sección muestra algunas de las pruebas más difíciles que hemos encontrado para simplificar la producción de ML. No son ejemplos completos, pero están diseñados para mostrar los problemas que encontramos durante la gestión del ciclo de vida de los datos de ML (funciones y etiquetas):

Acceso a fuentes de datos de origen correctas
Crear funciones y etiquetas a partir de los datos de origen
Combinando funciones en datos de entrenamiento
Cálculo y emisión de funciones en producción.
Seguimiento de producción

Un pequeño recordatorio antes de profundizar: la función ML son los datos que sirven como entrada para que el modelo tome una decisión. Por ejemplo, un servicio de entrega de alimentos quiere mostrar el tiempo de entrega esperado en su aplicación. Para hacer esto, es necesario predecir la duración de cocinar un plato en particular, en un restaurante en particular, en un momento específico. Una de las señales convenientes para crear tal pronóstico, un indicador de cuán ocupado está el restaurante, será la "cuenta final" de los pedidos entrantes en los últimos 30 minutos. La función se calcula en función del flujo de los datos iniciales de la orden de pedido:

Fig. 5: la transformación de la función cambia los datos iniciales a valores de función

Fecha de prueba n.º 1: acceso a los datos de origen correctos

Para crear cualquier función o modelo, un especialista en ciencia de datos primero necesita encontrar la fuente de datos correcta y obtener acceso a ella. Hay varios obstáculos en el camino:

Descubrimiento de datos: los profesionales necesitan saber dónde están los datos de origen. Una gran solución son los sistemas de catalogación de datos (como el Amundsen de Lyft ), pero aún no se utilizan de manera tan universal. A menudo, los datos necesarios simplemente no existen y, por lo tanto, primero deben crearse o catalogarse.
Aprobación del acceso: a menudo, correr entre las autoridades para obtener permisos para acceder a datos que resolverán problemas es un paso obligatorio en el camino de los expertos en ciencias de datos.
: , , . , .

- #2:

Los datos fuente pueden provenir de muchas fuentes, cada una con sus propias propiedades importantes que afectan los tipos de funciones extraídas de ellas. Estas propiedades incluyen soporte de fuente de datos para tipos de transformación , relevancia de datos y la cantidad de archivo de datos disponible :

Fig. 6: Las diferentes fuentes de datos tienen diferentes enfoques para los diferentes tipos de transformación de datos y proporcionan acceso a diferentes cantidades de datos según la relevancia.

Es importante tener en cuenta estas propiedades, ya que los tipos de fuentes de datos determinan los tipos de funciones que un especialista en ciencias de datos puede obtener de los datos de la fuente:

( Snowflake Redshift) ( ). , , « ».
( MongoDB MySQL) . , 24 .
( Kafka) ( ). . , « 30 ».
Los datos de consulta de predicción son los datos iniciales de eventos que ocurren en tiempo real justo antes de que se realice un pronóstico de ML, por ejemplo, una consulta que el usuario acaba de ingresar en la barra de búsqueda. Incluso si dichos datos son limitados, a menudo son "frescos" tanto como sea posible y contienen una señal fácilmente predecible. Dichos datos vienen con una solicitud de predicción y pueden usarse en cálculos en tiempo real, como la búsqueda de estimaciones de similitud entre la consulta de búsqueda de un usuario y los documentos en una matriz de búsqueda.

Mirando hacia el futuro, llamamos la atención: la combinación de datos de diferentes fuentes con características complementarias le permite crear funciones realmente buenas. Tal enfoque requiere la implementación y gestión de transformaciones más avanzadas de funciones.

Fecha de prueba n.º 3: combinación de funciones en datos de entrenamiento

La formación de conjuntos de datos de entrenamiento o prueba requiere combinar los datos de las funciones correspondientes. En este caso, es necesario rastrear muchos detalles que pueden tener efectos críticos en el modelo. Los dos más insidiosos son:

Fuga de datos: los especialistas en ciencia de datos deben asegurarse de que su modelo esté capacitado en la información correcta y no permitir la "fuga" de información no deseada en los datos de capacitación. Dichos datos pueden ser: datos de un conjunto de pruebas, datos de la verdad básica, datos del futuro o información que viole procesos preparatorios importantes (por ejemplo, anonimización).
: — . ( ). , data science , .

- #4:

Después de que el modelo se ponga en funcionamiento en tiempo real, para crear pronósticos correctos y relevantes, necesita suministrar constantemente nuevos datos de funciones, a menudo a gran escala y con un tiempo de espera mínimo.

¿Cómo deberíamos pasar estos datos a los modelos? Directamente de la fuente? Recibir y transmitir datos desde el almacenamiento puede llevar minutos, días, horas o incluso días, lo cual es demasiado largo para la salida de datos en tiempo real y, por lo tanto, en la mayoría de los casos es imposible.

En tales casos, el cálculo de funciones y el consumo de funciones deben ser desactivados. Para cálculo preliminar (pre-cálculo)funciones y su envío al almacén de datos de producción optimizado para la entrega, es necesario utilizar procesos ETL. Estos procesos crean dificultades adicionales y requieren nuevos costos de mantenimiento:

busque el compromiso óptimo entre relevancia y rentabilidad: desbloquear el cálculo y el consumo de funciones da prioridad a la relevancia. A menudo, debido al aumento en el costo, los procesos de las funciones se pueden ejecutar con mayor frecuencia y, como resultado, producen datos más relevantes. El compromiso correcto varía según la función y el caso de uso. Por ejemplo, la función de agregación de una ventana de factura final de entrega de treinta minutos tendrá sentido si se actualiza con más frecuencia que una función similar con una ventana de factura final de dos semanas.

Integración de procesos de funciones:Acelerar la producción de funciones requiere obtener datos de varias fuentes diferentes y, como resultado, resolver los problemas asociados con esto es más complicado que cuando se trabaja con una sola fuente de datos, lo que discutimos antes. La coordinación de tales procesos y la integración de sus resultados en un solo vector de funciones requiere un enfoque serio de la ingeniería de datos.

Prevención de la distorsión en el entrenamiento ( entrenamiento / sesgo de servicio ):Las discrepancias entre los resultados del aprendizaje y los procesos de trabajo pueden conducir a distorsiones en el aprendizaje. Las distorsiones durante el entrenamiento son bastante difíciles de detectar, y su presencia puede hacer que las predicciones del modelo sean inutilizables. El modelo puede comportarse de manera caótica al extraer conclusiones basadas en datos generados de manera diferente a aquellos en los que fue entrenado. En sí mismo, el tema de la distorsión y trabajar con ellos merece una serie separada de artículos. Sin embargo, vale la pena destacar dos riesgos típicos:

: ( ) , . Null? ? . .

. 7 ,

́ : - ( ). , , , . , , . — , , , .

Higo. 8: El gráfico muestra la cuenta final de las órdenes: en (1) se muestran los valores de la función emitida para el pronóstico y actualizada cada 10 minutos; en (2) se muestran datos de entrenamiento que muestran incorrectamente los valores verdaderos mucho más claramente en comparación con las funciones emitidas para la producción

Fecha de prueba # 5: características de seguimiento en producción

Algo se romperá, a pesar de todos los intentos de sortear correctamente los problemas anteriores. Cuando un sistema ML falla, casi siempre ocurre debido a una "violación de integridad de datos". Este término puede indicar muchas razones diferentes, cada una de las cuales requiere seguimiento. Ejemplos de violaciones de integridad de datos:

: , , . , , . , .
: , . , , (, ), .
: . , (, , ) .
Responsabilidad poco clara de la calidad de los datos: en el caso de que las funciones puedan recibir datos de origen de varias fuentes de distribución diferentes, ¿quién es el responsable final de la calidad de la función? ¿El especialista en ciencia de datos que creó la función? ¿Especialista en ciencia de datos que capacitó al modelo? ¿Propietario del canal de alimentación de datos? ¿El programador que llevó a cabo la integración del modelo en la producción? En los casos en que las responsabilidades no están claras, los problemas permanecen sin resolver durante demasiado tiempo.

Tales pruebas crean una carrera de obstáculos casi insuperable incluso para los equipos más avanzados en el campo de la ciencia de datos y la ingeniería de ML. Resolverlos requiere algo mejor que el status quo inmutable de la mayoría de las empresas, cuando las soluciones individuales a medida siguen siendo la única respuesta a un subconjunto de estos problemas.

Presentación de Tecton: una plataforma de aprendizaje automático de fechas

En Tecron, estamos creando una plataforma de fechas para el aprendizaje automático para proporcionar asistencia con los problemas más comunes y más difíciles en el campo de la ciencia de datos.

En un nivel alto, la plataforma Tecron tiene:

Procesos de función para convertir sus datos de origen en funciones y etiquetas
Repositorio de funciones para almacenar funciones archivadas y datos de etiquetas
Servidor de funciones para emitir los últimos valores de función a producción
SDK para formación de datos y manipulación de procesos funcionales.
Interfaz de usuario web para monitorear y rastrear características, etiquetas y conjuntos de datos
Motor de monitoreo para determinar la calidad de los datos o problemas de deriva, y alertas

Higo. 9: Al ser la plataforma central de datos para ML, Tecton proporciona funciones en entornos de desarrollo y producción,

la plataforma permite a los equipos de ML llevar las prácticas de DevOps a los datos de ML:

Planificación: las características de Tecron se almacenan en un repositorio central. Esto permite que los especialistas en ciencia de datos compartan, encuentren y usen los trabajos de los demás.
Código: Tecton permite a los usuarios configurar procesos de transformación de funciones simples y flexibles.
Compilación: Tecton compila funciones en tareas de procesamiento de datos de alto rendimiento.
Pruebas: Tecton admite pruebas funcionales y de integración de funciones.
Lanzamiento: Tecton se integra estrechamente con git. Todas las descripciones de funciones tienen control de versiones y son fáciles de reproducir.
: Tecton ( Spark). Tecron.
: Tecton data science , .
: Tecton .

Por supuesto, los datos de ML sin un modelo de ML no le proporcionarán una implementación práctica de ML. Por lo tanto, Tecton proporciona API flexibles y se integra con las plataformas ML existentes. Comenzamos con Databricks, SageMaker y Kuberflow, y continuamos integrándonos con componentes complementarios del ecosistema.

¿Por qué necesitamos DevOps en el campo de datos ML?