MLOps está sobreajustando. Aquí está la razón
MLOps está sobreajustando. Razón
Las encuestas de VC muestran que hoy en día hay cientos de empresas activas que se autodefinen como parte de la categoría de MLOps.
Los sistemas de MLOps proporcionan la infraestructura que permite a los profesionales de ML gestionar el ciclo de vida de su trabajo desde el desarrollo hasta la producción de manera robusta y reproducible. Las herramientas de MLOps pueden cubrir necesidades de extremo a extremo o centrarse en una fase específica (por ejemplo, Investigación/Desarrollo) o artefacto (por ejemplo, Características) en el proceso.
El mundo de los datos involucra un continuo de profesionales de datos, desde analistas que utilizan principalmente consultas SQL ad hoc hasta doctores que ejecutan algoritmos propietarios.
¿Existe un enfoque de DevOps que pueda aplicarse a todos, o es ML una práctica única que requiere su propio enfoque de mejores prácticas y una infraestructura correspondiente?
Para responder a esta pregunta, analizaremos las bases de DevOps y cómo DataOps es una habilidad natural dentro de DevOps que se adapta a las necesidades de los profesionales de datos. Luego, analizaremos las necesidades de ML y trataremos de comprender si y cómo pueden diferir de DataOps.
- 5 habilidades que todos los profesionales de marketing analítico y ...
- Investigadores de Google y Georgia Tech presentan DiffSeg un método...
- Análisis de series temporales VARMAX como un servicio
Por último, pero no menos importante, analizaremos la pregunta de cuánta infraestructura debe manejar un profesional de ML. ¿Es diferente de cualquier otro profesional de datos? ¿En qué posición se encuentra en comparación con los ingenieros de software?
Esta pregunta es relevante para el tema en cuestión, ya que determina la necesidad de la infraestructura proporcionada al profesional.
¿Qué es DevOps?
**”DevOps** es una metodología en la industria del desarrollo de software y TI. Utilizado como un conjunto de prácticas y herramientas, DevOps integra y automatiza el trabajo de desarrollo de software (Dev) y las operaciones de TI (Ops) como un medio para mejorar y acortar el ciclo de vida del desarrollo de sistemas.”
DevOps es complementario al desarrollo ágil de software; varios aspectos de DevOps provienen de la forma ágil de trabajar.”
Vamos a analizarlo. La metodología ágil es parte de la metodología DevOps; se basa en la capacidad de mantener un ciclo de retroalimentación corto entre los diseñadores de productos y los usuarios.
Para mantener un ciclo de retroalimentación corto, es necesario tener un ciclo de vida eficiente de entrega de software desde el desarrollo hasta la producción. La infraestructura y las herramientas requeridas para mantener este proceso son responsabilidad del equipo de DevOps.
Entonces, la eficiencia es el objetivo principal.
En resumen, los principales componentes serían:
- Entorno de desarrollo: Un entorno de desarrollo que permite la colaboración y la prueba de código nuevo o modificado.
- Integración continua: La capacidad de agregar continuamente código nuevo o modificado a la base de código mientras se mantiene su calidad.
- Staging: para garantizar la calidad del sistema, incluida la funcionalidad nueva o modificada, antes de implementarla en producción mediante la configuración y ejecución de pruebas de calidad en un entorno similar a la producción.
- Implementación continua: La capacidad de implementar funcionalidades nuevas o modificadas en entornos de producción.
- Monitoreo: Observar la salud de la producción y la capacidad de recuperarse rápidamente de problemas mediante la reversión.
- Modularidad: La capacidad de agregar fácilmente componentes, como nuevos servicios, a producción manteniendo la estabilidad y el monitoreo de la producción.
Puede haber muchos títulos de trabajo, según la estructura organizativa (DevOps/SRE/Ingeniería de Producción), pero su responsabilidad sigue siendo la misma.
Esta función es responsable de proporcionar una infraestructura para mover el código desde el desarrollo hasta la producción. Los equipos de ingeniería de productos pueden participar en la elección de algunas herramientas que sean más específicas para su experiencia, como aspectos de su entorno de desarrollo.
Para apoyar este objetivo y permitir esos procesos ágiles, los ingenieros de software reciben capacitación en una variedad de herramientas, incluido el Control de Fuente, como Git, y herramientas de automatización, como Jenkins, Unit y plataformas de pruebas de integración.
Cualquier ingeniero de software sabe que la capacitación más importante que los ingenieros de software reciben en el trabajo es comprender la gestión del ciclo de vida de la aplicación y trabajar con las herramientas que la respaldan. La productividad es mucho mayor una vez que dominas eso y, una vez que lo haces, es parte natural de tu trabajo diario.
Fuente: AWS
¿Qué es DataOps?
DataOps es DevOps para aplicaciones intensivas en datos. Estas aplicaciones se basan en Tuberías de Datos para producir los derivados de los datos que son el corazón de las aplicaciones.
Ejemplos de aplicaciones intensivas en datos incluyen:
- Sistemas internos de inteligencia empresarial,
- Aplicaciones de salud digital que se basan en grandes conjuntos de datos de pacientes para mejorar el diagnóstico y tratamiento de enfermedades,
- Capacidades de conducción autónoma en automóviles,
- Optimización de líneas de producción,
- Motores de IA generativos,
- y muchos más…
El objetivo de un equipo de DataOps es similar al de un equipo de DevOps, pero su conjunto de tecnologías incluye experiencia en las tecnologías que permiten a los profesionales de datos lograr un ciclo de retroalimentación corto.
Estas tecnologías incluyen almacenamiento distribuido, motores de cálculo distribuido, sistemas de ingestión distribuida, herramientas de orquestación para gestionar flujos de datos y herramientas de observabilidad de datos para permitir pruebas de calidad y monitoreo de producción de los aspectos de datos de una aplicación intensiva en datos.
En pocas palabras, esta experiencia permitirá:
- Entorno de Desarrollo: Un entorno de desarrollo que permita la colaboración y la capacidad de probar tuberías de datos nuevas o modificadas. La infraestructura no solo incluirá la gestión del código funcional, sino también el código de la tubería y los datos.
- Integración Continua del Código: La capacidad de agregar continuamente código nuevo/modificado a la base de código.
- Integración Continua de Datos: La capacidad de agregar continuamente datos nuevos/modificados al conjunto de datos.
- Puesta en Escena: para garantizar la calidad del sistema con nueva/funcionalidad modificada antes de implementarlo en producción. Esto incluirá pruebas tanto de código como de datos.
- Implementación Continua: La capacidad de implementar automáticamente en entornos de producción nueva/funcionalidad modificada o datos.
- El monitoreo de la salud de la producción y la capacidad de recuperarse rápidamente de problemas. Esto incluirá tanto la aplicación como los datos incorporados en ella.
- La capacidad de agregar fácilmente componentes, como nuevos servicios/artefactos de datos, en producción mientras se mantiene la estabilidad de producción y el monitoreo de salud.
MLOps vs. DataOps
En el contexto de DevOps y DataOps, MLOps es el caso de DataOps que se enfoca en el ciclo de vida de ML.
Aquí, se nos pide responder la pregunta principal de este artículo. ¿Es MLOps realmente diferente de DataOps? Y si es así, ¿cómo?
Dado que las aplicaciones basadas en ML requieren control de versiones de código, datos y entorno, orquestación y aprovisionamiento de tecnologías de datos, sus necesidades en esos dominios son similares a las de otros profesionales de datos y se encuentran dentro de DataOps tal como se define aquí.
Lo mismo ocurre con las herramientas de calidad de datos y las herramientas de monitoreo de datos. Si bien esas herramientas pueden ser específicas de ML en algunas partes de las pruebas, eso no es diferente de la diferencia entre las herramientas de un desarrollador de C++ y las herramientas de un desarrollador de JavaScript.
No definimos esas categorías como diferentes de DevOps, ¿verdad?
Es importante tener en cuenta que la necesidad de tales herramientas no está en duda y las categorías de calidad de datos y monitoreo de datos tendrán éxito, pero no cambian el paradigma de DevOps ni convierten a MLOps en una categoría de producto real.
Esto nos lleva a donde realmente radica la diferencia: en el entorno de desarrollo. Esta diferencia es conocida en DevOps y es real.
Cada profesional en ingeniería de software tiene requisitos específicos para su entorno de desarrollo. Estas necesidades se suman al control básico de versiones de código y datos y al cuaderno bien configurado que se requiere para todos.
Por ejemplo, los profesionales de ML requieren un buen sistema de gestión de experimentos, una buena forma de optimizar hiperparámetros y una buena forma de crear sus conjuntos de entrenamiento.
¡El conjunto de entrenamiento! ¡Oh, eso sí es una diferencia! Los científicos de datos requieren la infraestructura para almacenar y gestionar el etiquetado de los datos en los que confían para entrenar sus modelos.
Aunque parte de esta infraestructura es general para datos, como el almacenamiento o la base de datos utilizada para guardar los metadatos del etiquetado, parte de ella es extremadamente específica del proceso de etiquetado en sí y de la gestión de los conjuntos de entrenamiento.
¿Justifica esto una nueva categoría de Ops? No creo que sí. Sería lo mismo que decir que una aplicación que requiere una base de datos de gráficos necesitaría una nueva categoría de Ops.
¿Por qué hicimos Overfit a MLOps?
En muchas discusiones sobre las necesidades de infraestructura de los científicos de datos, se plantea la pregunta sobre sus habilidades básicas de software. Frases como “No esperes que un científico de datos entienda los conceptos de Git” o “Los científicos de datos no pueden crear código con un registro adecuado, no son ingenieros de software”, etc.
Me siento incómodo con ese pensamiento y creo que nos ha llevado a hacer Overfit a MLOps.
Los científicos de datos son individuos altamente capacitados que pueden comprender rápidamente los conceptos de control de versiones y dominar las complejidades de trabajar con servidores de automatización para CI/CD. Como mencioné anteriormente, los ingenieros de software junior aprenden esto en el trabajo y creo que los científicos de datos que pretenden aportar valor a una empresa comercial también deberían hacerlo. Siento que estamos creando una categoría de herramientas para solucionar una falta de formación para los científicos de datos. Esta encuesta respalda esta opinión.
Dicho esto, la cuestión de cuánto deben estar expuestos los ingenieros de software de operaciones a Ops todavía está abierta, y diferentes organizaciones tienen diferentes puntos de vista sobre cómo se implementa DevOps dentro de la organización.
Lo común a todos es la comprensión de que el equipo de DevOps es responsable de proporcionar infraestructura, y los ingenieros de software deben entenderla, usarla y aportar requisitos para asegurarse de que mejore continuamente.
Cuando se trata de ingenieros de datos, la expectativa sigue siendo la misma. ¿Por qué debería cambiar para ingenieros de ML/Científicos de Datos?
Conclusión
Las organizaciones con vastas operaciones de datos (pronto todas las organizaciones) deben asegurarse de que sus equipos de DevOps tengan experiencia en datos para proporcionar infraestructura de datos de alta calidad y mejores prácticas para todos los profesionales de datos, al mismo tiempo que se aseguran de que todos los profesionales de datos estén bien educados en cómo utilizar esta infraestructura para gestionar óptimamente sus flujos de trabajo. En las empresas, esto podría ser definitivamente un departamento dedicado.
Las buenas prácticas y la educación interna pueden eliminar la necesidad de herramientas demasiado especializadas que eventualmente limitan el acceso de los profesionales de datos a la flexibilidad tan necesaria que ofrecen las herramientas generales de Ops.
La ventaja de una herramienta demasiado especializada es que, a corto plazo, para un sistema muy simple, brinda una solución integral para todas las necesidades.
¿Por qué trabajar con nuestro equipo de DevOps si podemos simplemente comprar esta herramienta de extremo a extremo? Pero a largo plazo, las necesidades evolucionan desde casos de uso simplificados, y se requiere la profundidad de los sistemas expertos. Por ejemplo, para la orquestación, en lugar de utilizar herramientas de extremo a extremo que ofrecen orquestación simplificada, entre otras cosas, las empresas se moverán hacia sistemas de orquestación potentes como Airflow, Prefect o Dagster.
