Como sabemos, MLOps es la combinación de machine learning con operaciones. Y haciendo foco en la primera parte, la creación de un modelo de machine learning (ML) no es otra cosa, en definitiva, que el desarrollo de un software.
La diferencia radica en la presencia de un científico de datos como “ideólogo” del modelo y la necesidad de que pueda ser integrada a la infraestructura organizacional. Y de que pueda ser testeada de manera adecuada para ser desplegada rápidamente y luego monitoreada con el objetivo de verificar que funcione como corresponde.
El uso de prácticas de ingeniería de software en todo ese proceso, por lo tanto, juega un papel esencial para eliminar trabas. Estas pueden ser tanto en el trabajo del científico como en todas las instancias posteriores, cuando el modelo deje el ámbito de la investigación y deba transformarse en una aplicación útil para otros perfiles.
En efecto, los conceptos de ingeniería de software le quitan al modelo de ML su cualidad “artesanal”. Los vuelve repetibles y escalables, facilita su puesta en producción y genera estándares para que cualquier científico de datos pueda crear nuevas piezas siguiendo los mismos lineamientos.
MLOps es solo el principio
MLOps es fundamental para alinear equipos tan disímiles como los que se construyen para crear modelos de ML. Estos equipos están formados, por un lado, por los científicos de datos -que pueden ser físicos teóricos, biólogos o geólogos, no siempre vienen del área de sistemas- y los expertos en operaciones por el otro. Esta disciplina también es importante para evitar que éstos queden atorados en la etapa de prueba de concepto (PoC).
Pero si se la rodea con principios de ingeniería de software, los resultados son aún mejores. Por ejemplo, en el uso de repositorios centralizados, para evitar que el código fuente quede en la computadora del científico y que empiecen a difundirse versiones al punto tal que no se sepa cuál es la que está en producción. También por si alguna librería utilizada originalmente no está disponible e impide el normal funcionamiento de la aplicación.
Del mismo modo, habrá que estandarizar la arquitectura, la infraestructura y las herramientas que se utilizan. Un problema común que se enfrentan los modelos de ML es que la forma de implementación depende cada proyecto, con el armado de entornos en el momento. Esto genera como resultado mayores costos y riesgos.
Del testeo al registro de actividades
En el desarrollo de modelos, suele probarse únicamente que prediga lo que se solicita, pero muchas veces se saltean los procesos de testing, tanto formales como informales. Al mismo tiempo, rara vez se establece un registro de estas actividades.
¿Cómo se logra empapar los proyectos con estas prácticas de ingeniería de software? A través de charlas de capacitación o nivelación, que abarcan desde el uso de herramientas específicas hasta las buenas prácticas de programación para los científicos de datos.
Por otra parte, es fundamental promover la comunicación a lo largo de todo el equipo, para que ninguna de las partes intente reinventar la rueda. Un modelo de ML en la notebook del científico de datos no es más que un experimento. Implementado según los estándares y las necesidades de la empresa, es una fuente de potencial valor agregado para el negocio.
¿Qué tan fluida es la integración entre los equipos de ciencia de datos y de operaciones en tu organización? Para saber cómo podemos ayudarte contactanos haciendo CLICK AQUÍ y conoce más sobre nosotros en nuestras redes LinkedIn y Twitter.
