Muchos de nosotros, desarrolladores, conoceremos la sensación de luchar por equilibrar el tiempo que pasamos con los usuarios intentando comprender sus necesidades frente al que dedicamos realmente al desarrollo de software. Esto es aún más evidente en la ciencia data, ya que para construir un sistema eficaz se necesita mucho conocimiento del dominio de ese sistema. Durante los dos últimos años trabajando como ingeniero de ML con diferentes data ciencia equipos me he preguntado a menudo cómo puedo separar las responsabilidades de optimizar la precisión de los modelos y construir todo el software necesario para que ese modelo sea funcional. Mi humilde opinión es que los científicos de data deben dar prioridad a la precisión de sus modelos, mientras que los ingenieros de ML deben dar prioridad a asegurarse de que esos modelos puedan ser utilizados por el conjunto de la empresa.

Como regla general en los proyectos científicos data, cuantas más iteraciones realice, mejor. Así que veamos por qué incluir a un ingeniero de ML desde el primer día le ayudará a iterar y, por lo tanto, aumentará sus posibilidades de construir un sistema exitoso. Para cubrir todos los aspectos, desglosaremos cada razón en tres temas principales de los proyectos científicos data: data, modelos y infraestructura.

Antes de entrar en materia, permítame definir lo que entiendo por iteración. En este artículo me refiero a iteraciones de extremo a extremo del producto completo, que a menudo incluyen pasos de: data ingestión, preprocesamiento, formación y evaluación de modelos, infraestructura de aprovisionamiento, etc. Lo que yo no significan es una iteración rápida del modelo en un cuaderno con el retoque de un hiperparámetro. Si está acostumbrado a trabajar en un marco ágil, puede pensar igualmente en estas iteraciones como sprints del proyecto.

Construir un esqueleto sobre el que pueda iterar es la primera prioridad y puede ser un proceso largo. Este esqueleto suele ser un POC que contiene su modelo de base inicial y una demostración de una aplicación o forma de explotar la salida del modelo.

Infraestructura: La selección de recursos cloud compatibles (máquinas virtuales, conexiones a diversas fuentes data) y el diseño de la arquitectura cloud son algunas de las consideraciones iniciales del ingeniero de ML.

Data: Conseguir el data necesario para empezar a construir un modelo y asegurar la disponibilidad de data de varias fuentes con la opción de desarrollar nuevos flujos si es necesario.

Modelos: Garantizar que los modelos que se están probando son de hecho compatibles con la arquitectura cloud propuesta para el despliegue de modelos y los requisitos técnicos (por ejemplo, latencia, computación necesaria, requisitos del entorno de producción).

El ingeniero de ML también puede ayudar en esta fase definiendo las mejores prácticas de ingeniería de software con control de versiones, linting, arquitectura de código, pruebas, etc.

Una vez conseguida esa construcción inicial, el primer par de iteraciones suelen ser difíciles y lentas. Acelerar las iteraciones permitirá realizar iteraciones más pequeñas con un único cambio de característica, una forma mucho más eficaz de desarrollar que cambiar muchas cosas en un modelo antes de obtener retroalimentación.

Infraestructura: Se puede ahorrar tiempo optimizando la infraestructura de almacenamiento y computación. Durante estas iteraciones, un ingeniero de ML puede buscar versionar la propia infraestructura, con herramientas de Infraestructura como Código (IaC) como Terraform. El uso de IaC permite automatizar el despliegue de la infraestructura directamente con los pipelines CI/CD, acelerando la integración de cualquier cambio que deba realizarse en la infraestructura existente, y la creación de diferentes entornos cloud (dev, staging, producción). Asimismo, el uso de componentes específicos de cloud puede acelerar su flujo de trabajo, por ejemplo, la creación de imágenes de forma remota mediante el sistema de GCP Construcción en la nube.

Data: Los equipos científicos de data pueden construir rápidamente pipelines de preprocesamiento para pasar rápidamente a la modelización. Un ingeniero ML puede ayudar en esta fase a agilizar las consultas de procesamiento, ya sean en sql, pandas, pyspark, etc. Hacer esto desde el principio puede ahorrar mucho tiempo en iteraciones a largo plazo, ya que este código se ejecuta mucho.

Modelos: Las complejas arquitecturas de los modelos pueden dar lugar a un largo proceso de entrenamiento. Además, cuando un científico del data se refiere a un “modelo” puede estar refiriéndose en realidad a un grupo de 100 modelos entrenados en diferentes cortes del data, cada uno con un explicador SHAP para derivar la importancia de las características. Un ingeniero de ML puede centrarse en cómo paralelizar el pipeline de entrenamiento, ya sea en una VM con multiprocesamiento en python, o distribuyendo su carga de trabajo entre varios nodos del cloud. Esto en sí mismo puede ser iterado, pero se pueden obtener grandes ganancias aquí con sorprendentemente poco esfuerzo. Automatizar el despliegue de su modelo con un CI/CD/CT pipeline también acelera enormemente sus iteraciones y garantiza la repetibilidad.

Contar con un ingeniero que controle el presupuesto cloud de su proyecto es fundamental, especialmente para aplicaciones data intensivas.

Infraestructura: El coste es una variable importante en la ecuación de selección de la infraestructura. Una vez elegida la infraestructura, se pueden poner en marcha alertas presupuestarias para garantizar que los componentes costosos se vigilan de cerca.

Data: Las consultas inteligentes y el almacenamiento de data también pueden reducir significativamente los costes de cada iteración. Por ejemplo, la agregación de data debe hacerse con moderación durante las iteraciones del modelo.

Modelos: La paralelización de su canal de formación también puede ahorrarle tiempos de funcionamiento de máquinas costosas o tiempo de ejecución de componentes sin servidor.

Conseguir iteraciones rápidas con un bucle de retroalimentación de calidad en su proyecto es estupendo, pero si no puede replay cada uno de esos escenarios, no sirve de mucho. Tener una canalización repetible significa implícitamente que debe tener alguna forma de supervisar las ejecuciones de la canalización, para identificar las ejecuciones basadas en parámetros específicos o métricas de rendimiento a las que volver si es necesario. Configurar esto de forma robusta durante el desarrollo ayuda a los científicos data a experimentar libremente (sin necesidad del infame Untitled12.ipynb) y prepara el pipeline para la monitorización en producción.

Infraestructura: Vincular la versión del código de entrenamiento a la versión del código de infraestructura es la “milla extra” aquí, pero es necesario para proporcionar capacidades completas de retroceso a una ejecución anterior. Garantizar la repetibilidad y la supervisión sobre la base de una ejecución de pipeline es para mí el primer nivel esencial de ML Ops por el que deben esforzarse los equipos. Las plataformas en la nube disponen de servicios (GCP's Vértice AI por ejemplo) que pueden ser rápidas de configurar, pero también puede considerar adoptar el enfoque de “lo mejor de lo mejor” utilizando herramientas de código abierto. El compromiso en este caso es equilibrar la mayor funcionalidad de las herramientas específicas de código abierto frente a la mayor complejidad de la infraestructura general del sistema.

Data: guardar todos los objetos data en cada etapa del proceso. Dependiendo de los volúmenes, la prioridad es guardar los conjuntos de tren / prueba de cada ejecución.

Modelos: como en el caso anterior, guardando todos los modelos para cada ejecución con todos los parámetros y métricas necesarios. Otro consejo es registrar un comentario en cada ejecución con lo que se ha cambiado para esa ejecución específica para registrar todos los experimentos durante el desarrollo, como haría con un git commit mensaje.

Cuando surgió la ciencia data era muy exploratoria y requería un esfuerzo masivo con un grupo de ingenieros de software para desplegar cualquier modelo una vez que hubiera demostrado buenas prestaciones en data históricos. Esta fase de “industrialización” es una experiencia muy dolorosa, ya que el entorno de desarrollo (archivos planos y cuaderno python) es muy diferente del entorno de producción (flujos data automatizados con data de producción y entorno de codificación de producción). Los proyectos más exitosos en los que he trabajado son aquellos en los que hemos podido copiar el entorno de producción lo más fielmente posible en dev desde el principio. Esto reducirá el tiempo de producción y le permitirá iterar con seguridad en dev, desplegando a prod cuando esté contento con una iteración.

Infraestructura: Emular la infraestructura de producción necesaria en dev no siempre es fácil y puede resultar costoso. Aquí es donde la infraestructura como código resulta útil y puede permitirle intercambiar fácilmente entre entornos.

Data: Algo que separa el desarrollo científico data de la ingeniería de software tradicional o incluso de la ingeniería data es que los científicos data requieren data de producción en dev. Sandbox data (excluyendo algunos data o incluyendo algunos data sintéticos de prueba) para la ingeniería data regular es una buena práctica durante el desarrollo, pero puede ser una gran pérdida de tiempo para la ciencia data y puede tener grandes impactos en todo el pipeline científico data. Por lo tanto, tener acceso de sólo lectura a las tablas de producción es algo que debe empezar a negociar con su equipo data desde el primer día.

Modelos: Desde el inicio del proyecto, sólo un modelo (o enfoque de modelado) debe estar presente en su código de producción. Todos los experimentos deben permanecer en cuadernos o scripts temporales separados en otra carpeta. Esto evita que acumule código muerto en su base de código de producción, y es más fácil de mantener o de incorporar a otros desarrolladores.

En resumen, construir modelos y construir el software que rodea a esos modelos deberían ser dos prioridades desde el principio de cada proyecto. Por lo tanto, tener corrientes separadas con responsabilidades diferentes puede ayudar a los equipos a concentrarse en ambas en paralelo. El papel del ingeniero de ML evoluciona día a día, ¡y me encantaría conocer su opinión sobre cualquier cosa que se me haya pasado por alto!