En artículos anteriores ya fue explicado el concepto de MLOps: una combinación entre las áreas de ciencia de datos que desarrollan modelos matemáticos para machine learning y las áreas de operaciones que deben materializarlos para construir a partir de ellos aplicaciones que funcionen. En esta oportunidad nos enfocaremos en las prácticas y errores más frecuentes que se dan en MLOps.

Las cuatro prácticas 

A la hora de convertir esto en acción concreta, emergen cuatro prácticas destacadas que conviene adoptar:

1. Definir un espacio de trabajo común. Es importante acordar un entorno y un conjunto de herramientas, siempre considerando que se trate de soluciones que se utilicen frecuentemente y que faciliten su adopción.

2. Generar entornos reproducibles. Existen estrategias sencillas para que una persona pueda incorporarse al equipo MLOps conociendo los detalles del entorno donde se trabaja o pudiéndolo reproducir. Por ejemplo, los espacios de trabajo en la nube vienen con la especificación de qué herramientas tienen instaladas y en qué versión. Otro modelo es llevar una bitácora de configuración del entorno. Y existe una instancia superadora: el dockerfile. Los contenedores permiten configurar un entorno completo y usarlo como unidad de despliegue.

3. Armar un repositorio de versionados. Que todos puedan trabajar de manera coordinada y en un único repositorio, con idea de qué cambios se hicieron, quiénes los llevaron a cabo y con qué objetivos.

4. Establecer patrones de arquitectura. Es fundamental para interconectar los componentes de las piezas necesarias para resolver los problemas y desacoplar los comportamientos de captura y entrega de datos del cliente.

Los tres errores de MLOps

La experiencia acumulada en MLOps ya permite identificar al menos tres errores que se repiten con frecuencia, como si fueran parte del estado del arte de esta disciplina, y que en todos los casos son fácilmente salvables.

1. Falta de réplicas en el entorno de producción. Ocurre que alguien genera un ejecutable que corre en algún espacio y a la hora de hacerle alguna modificación no se entiende qué versión del software utiliza o no permite ver si el cambio podría perjudicar alguna otra cosa. Para evitar estos inconvenientes existen hoy numerosas herramientas que permiten generar entornos replicables, lo que evita copiar y pegar lo que hay en otro servidor, terminar con las dudas de si lo que estamos haciendo funcionará o no en el entorno de producción y asegurarnos de que las pruebas que hagamos serán adecuadas.

2. Conflictos de estilo de programación. Los científicos de datos suelen venir de las ciencias duras, por lo que conocen prácticas de programación para problemas puntuales y utilizan estilos con código experimental entremezclado o que utiliza scripts más largos. Para hacer una puesta en común, se recomienda un entrenamiento en equipo durante el cual se establezcan prácticas adecuadas. En un paso más avanzado, los expertos en operaciones podrían explicar a los científicos de datos la conveniencia de utilizar estilos asociados a la ingeniería del software.

3. Anti-patrones de diseño. Copiar y pegar código causando problemas de integración y consistencia. La solución: que los equipos puedan probar con más frecuencia y se deshagan tanto del código experimental como del código muerto.

Seguramente, en la medida que se extienda la práctica de MLOps, aparecerán nuevas mejores prácticas y podremos anticipar más errores. Si ya descubriste alguna, nos gustaría que la compartas en nuestras redes LinkedIn o Twitter.