Ramas son todo lo que necesitas nuestro marco de versionado de ML con opinión

Las ramas son todo lo que necesitas en nuestro marco de versionado de ML con opinión

Un enfoque práctico para versionar proyectos de aprendizaje automático utilizando ramas de Git que simplifica los flujos de trabajo y organiza los datos y los modelos

TL;DR

Un enfoque sencillo para versionar proyectos de aprendizaje automático utilizando ramas de Git que simplifica los flujos de trabajo, organiza los datos y los modelos, y une las partes relacionadas del proyecto.

Introducción

Cuando se gestionan soluciones de aprendizaje automático, varios aspectos de las soluciones se distribuyen a menudo en múltiples plataformas y ubicaciones, como GitHub para el código, HuggingFace para los modelos, Weights and Biases para el seguimiento, S3 para una copia de todo, etc.

En cuanto a los datos, tenemos datos de entrenamiento, datos procesados, datos de seguimiento de entrenamiento y datos de monitoreo de modelos. Guardamos modelos para inferencia, incluyendo versiones antiguas y modelos experimentales para pruebas en línea. También tenemos código para el preprocesamiento, entrenamiento, inferencia, experimentación, análisis de ciencias de datos y alertas de monitoreo.

Esto puede salirse fácilmente de control.

• Los repetidores cuánticos utilizan defectos en el diamante para interconectar sistemas cuánticos
• Walmart está considerando la inteligencia artificial para ofrecer una experiencia de compra más personalizada
• La ciudad de Nueva York presenta el plan de acción de IA

El uso de diversas herramientas, entornos y direcciones de activos para realizar un seguimiento de las diferentes partes del ciclo de vida del aprendizaje automático puede resultar en estados dispersos y descoordinados. Esto puede llevar a pérdida de datos, violaciones de seguridad y configuraciones incorrectas que deben gestionarse cuidadosamente.

En un proyecto anterior, utilizamos SageMaker para el entrenamiento diario en una solución en las instalaciones. Esto requería que los clientes descargaran un modelo diariamente y lo entrenaran utilizando diversas combinaciones de conjuntos de datos de los clientes.

Teníamos que gestionar qué modelo binario se entrenaba con qué código de entrenamiento en qué datos de qué cliente, qué modelo se ejecuta en qué cliente con qué código de inferencia, etc.

En este artículo mostraremos cómo utilizar herramientas de versionado de datos para abordar estos problemas utilizando Git.

Las herramientas de versionado de datos le permiten realizar commits de archivos de datos y modelos junto con el código, independientemente de su tamaño. Al versionar todos los archivos de esta manera, puede evitar la molestia de gestionar los activos de datos y modelos.

En un mundo ideal, solo tendría el código, los datos y los modelos relevantes para la tarea específica en cuestión. Ya sea que esté desarrollando o ejecutando el entrenamiento de ML, realizando un seguimiento de experimentos, monitoreando modelos en producción o realizando experimentos en línea.

En lugar de conectar manualmente (o incluso automáticamente) las piezas correctas, cargando los datos adecuados en el código correcto, conectándolos al modelo correcto en HuggingFace en el entorno correcto, imagina que cada vez que hagas checkout de una rama, todas las piezas estén ahí.

En este artículo, presentaré un marco de trabajo que reemplaza la complejidad de malabarismos con herramientas con Git, un sistema que casi todos los equipos de ML ya están utilizando.

El objetivo es simplificar y eliminar barreras para comenzar cada etapa del flujo de trabajo de ML teniendo todo en un solo lugar, gestionado por Git.

Nuestros requisitos

1. Un flujo de trabajo sencillo que sea fácil de pausar, retomar y ajustar para adaptarse a las necesidades cambiantes del negocio y del desarrollo. También debería admitir la reproducibilidad y permitir consultas post-factuales, como “¿Sobre qué datos se entrenó mi modelo?”
2. Uso eficiente de datos y código, con enfoque en la cohesión, gobernabilidad y auditoría. – Busque reutilizar datos y código tanto como sea posible y aprovechar las características de Git como commits, issues y tags.
3. Consolidar todos los diferentes aspectos de la solución de ML es importante. A menudo, el seguimiento de experimentos, el monitoreo de modelos en producción y los experimentos en línea y sin conexión están separados de los lados de entrenamiento e inferencia de la solución. Aquí, buscamos unificarlos bajo un mismo paraguas, facilitando la transición entre ellos.
4. Seguir las mejores prácticas de Git y ML, como divisiones de datos tempranas y compartibles, pruebas y colaboración sencilla, para diferentes ingenieros de ML.

Conceptos clave

Cada cambio es un commit de Git: Esto incluye subidas de datos, ingeniería de características, anulación de modelos, fusión de resultados de métricas de experimentos, monitoreo de modelos y cambios de código de forma natural.

Ramas activas: Es una práctica común usar ramas diferentes para desarrollo y producción. Sin embargo, podemos llevarlo un paso más allá aquí. Esto significa que puedes hacer checkout de una rama y tener todos los datos, el código, los modelos, los documentos, los readme y las tarjetas de los modelos con métricas en un solo lugar.

🤯 ¡Tu repositorio es tu almacén de blobs! Tu rama funciona como un cubo dentro de tu almacén de blobs, lo cual te permite subir, descargar y almacenar datos y modelos.

Esto te permite usar diferentes ramas para diferentes necesidades de desarrollo, experimentación y producción, en lugar de depender de plataformas y herramientas diferentes.

Merges como flujo de trabajo: Se utilizan para combinar ramas. El código se fusiona normalmente, y un modelo generalmente reemplaza al modelo existente. Cuando se fusionan datos, generalmente se añaden en forma de apéndice. Para recibir datos nuevos, se “extraen” de otra rama al hacer una copia.

La fusión de datos puede ser tan simple como copiar archivos o añadir elementos a una lista JSON. En casos más sofisticados, se pueden fusionar bases de datos sqlite.

Deduplicación, una función comúnmente utilizada en herramientas de versionamiento de datos, evita la creación de copias múltiples de archivos, incluso cuando hay varias ramas que contienen los mismos archivos.

Tipos de Ramas

Rama Principal

En primer lugar, utilizamos la rama principal de nuestro proyecto para almacenar la definición del problema, la documentación, la descripción de los datos y la estructura del proyecto. Esto sirve como espacio de colaboración y discusión.

CONSEJO: Comienza por definir claramente el problema comercial, determinar el resultado deseado, identificar los valores o etiquetas objetivo y cómo se obtienen, y establecer métricas y requisitos de evaluación. Esto te permitirá comenzar el proyecto de manera exitosa y crear un lugar para la incorporación y la colaboración.

También podemos utilizarlo para seguir experimentos, donde se combinan los resultados de tus experimentos. Por ejemplo, la carpeta de ejecución de mlruns de MLflow se puede fusionar allí con este propósito. Cualquier colaborador puede hacer checkout de esta rama y ejecutar la interfaz de usuario.

Alternativamente, el seguimiento se puede realizar en otra rama.

Comenzar de esta manera es muy simple, y a medida que cambian las necesidades con el tiempo, es posible actualizar con cambios mínimos a un servidor de MLflow o a una plataforma de seguimiento como Weights and Biases.

Ramas de Datos

Estas son ramas del proyecto que principalmente incluyen archivos de datos, documentación y scripts de transformación, y permanecen activas. Puedes pensar en ellas como cubos S3, pero en lugar de subir y descargar, haces checkout de una rama y tus archivos están allí.

Se recomienda siempre hacer commit (subir) a la rama raw. Esto crea una fuente de verdad, un lugar que nunca se edita ni se elimina, de modo que siempre se puede rastrear de dónde provienen y dónde pasan los datos. También permite crear nuevos flujos fácilmente, realizar auditorías y hacer cumplir las normas.

💡 Si agregas un mensaje de commit que indique de dónde provienen los datos, puedes tener una observabilidad aún más detallada sobre tus datos.

Puedes utilizar otra rama limpia en la que solo existan datos limpios. Por ejemplo, las imágenes rotas o los archivos de texto vacíos que se subieron a la rama raw no aparecen en la rama limpia.

Una rama dividida en la que los datos se dividen para entrenamiento, validación y pruebas puede asegurar que todos los equipos y colaboradores trabajen en un mismo terreno de juego.

Este enfoque ayuda a prevenir fugas de datos y permite un desarrollo de características más sólido y una colaboración más eficiente. Al minimizar la posibilidad de que ejemplos del conjunto de pruebas se incluyan en las etapas de entrenamiento, se reduce el riesgo de introducir sesgos. Además, al tener a todos los colaboradores en la misma división, se garantiza resultados consistentes e imparciales en un experimento.

En un proyecto de clasificación anterior, formé parte de un equipo de colaboradores individuales en el que cada persona ejecutaba todo el flujo de trabajo desde cero; cada uno de nosotros había utilizado diferentes porcentajes y semillas para dividir los datos, lo que llevó a modelos más débiles en producción debido a errores y sesgos en los datos.

💡 Consejo de ML: Mejores prácticas para el desarrollo del modelo en tres fases Utilizamos los conjuntos de datos de “entrenamiento” y “validación” para entrenar y optimizar los hiperparámetros del modelo. Luego, utilizamos el conjunto de entrenamiento más validación como conjunto de entrenamiento para entrenar nuestro modelo ajustado y evaluarlo con el conjunto de pruebas solo una vez. Por último, entrenamos el modelo con todos los datos y lo guardamos como nuestro modelo final.

Ramas Estables

Estas ramas son ramas activas para entrenamiento e inferencia. Aquí puedes ejecutar tu entrenamiento, guardar tu modelo, checkpoints y tarjeta de modelo, ejecutar pruebas, construir y probar la imagen de Docker, hacer commit de todo al final de un ciclo de entrenamiento, y luego etiquetar. Deben ser capaces de manejar la recuperación de nuevos datos y re-entrenamiento. Aquí es donde tiene lugar la automatización.

⚠️ No se escribe código en estas ramas.

Esto asegura que un modelo esté acoplado a los datos en los que fue entrenado, el código utilizado para entrenarlo y ejecutarlo en producción (incluyendo la ingeniería de características), y las métricas de resultado. Todos estos componentes se combinan en una sola “instantánea” unificada. Cada vez que revisas una etiqueta, todas las piezas necesarias para ese modelo están presentes.

💡 Consejo: Al elegir el nombre de la etiqueta de antemano, puedes agregar información de rastreo durante el entrenamiento como parámetro. Esto asegura que siempre puedas recuperar la “instantánea” de modelo-datos-código dada la información de rastreo utilizando cualquier herramienta de rastreo.

Después del entrenamiento, sólo los datos de rastreo se fusionan (copian) a tu rama principal para el seguimiento.

En el caso más simple, puede ser un archivo de texto JSON que contiene los hiperparámetros y los resultados de evaluación. Este archivo se añade a una lista en la rama principal. En el caso de MLflow, implica copiar los experimentos de la carpeta de mlruns a la rama principal.

Ramas de Codificación

Estas ramas son para desarrollo de código y exploración de datos, entrenando con datos muestreados o pequeños hasta tener un programa funcional. Mientras desarrollas, puedes utilizar todas las mejores prácticas de Git. Sin embargo, sólo bifurcate a una rama estable cuando ya no se requieran más cambios en el código, incluso si se añaden datos adicionales. Estas ramas deben incluir el código de inferencia, el servidor, el archivo Dockerfile y pruebas.

Siempre hay al menos una rama de desarrollo que permanece activa, donde se fusionan todas las nuevas características, correcciones de errores y otros cambios.

💡 Los ingenieros de ML y MLOps pueden colaborar tanto en el entrenamiento como en la inferencia.

Por ejemplo, puedes crear una rama dev/modelo donde desarrollas un modelo base. Esto puede ser la clase más popular para clasificación o la media/mediana para regresión. El enfoque se centra en configurar el código mientras se comprenden a fondo los datos.

Cuando sea estable y las pruebas pasen, bifurcamos a estable/modelo donde entrenamos y hacemos commit del modelo, código y datos juntos al repositorio y los etiquetamos. Esto es rápido y fácil de compartir y permitirá que los equipos de DevOps, backend y frontend inicien el desarrollo e intercambien comentarios. También facilitará la validación de los nuevos requisitos descubiertos en un entorno real lo antes posible.

A continuación, desarrollamos el modelo en la rama dev/modelo para un modelo simple como regresión lineal, y cuando esté listo y las pruebas pasen, podemos fusionarlo en estable/modelo donde entrenamos, hacemos commit y etiquetamos una versión para producción.

Este enfoque te da la libertad de mejorar incrementalmente tu modelo preservando el contexto completo de modelos anteriores en la rama estable.

A partir de este punto, tenemos tres opciones:

• Podemos re-entrenar cuando lleguen más datos al traerlos a la rama estable.
• Podemos comenzar la experimentación usando ingeniería de características en la rama dev/regresión-lineal.
• Podemos crear una nueva rama dev/nueva-aproximacion para modelos más sofisticados.

Rama de Monitoreo

En el monitoreo de modelos nos preocupamos por la distribución de datos, los datos atípicos y las distribuciones de predicción.

En la rama de monitoreo, guardamos los datos consultados, hacemos commit de la etiqueta y las predicciones del modelo en producción como archivos.

💡 Puedes usar múltiples ramas de monitoreo para cada entorno: dev, estable y prod.

Podemos configurar alertas en las confirmaciones de datos para probar la desviación en las distribuciones de características, valores atípicos, prueba de calibración de la calibración y guardar el código de las alertas; esto facilita soluciones más avanzadas, como un modelo de detección de valores atípicos, ya que también podemos guardar el modelo en esta rama.

Esta rama generalmente podría pertenecer a otro proyecto que esté desacoplado del código responsable de crear los registros de monitoreo, así como de los datos y el modelo que los generaron.

Rama de análisis

La ciencia de datos y el análisis son otro aspecto del proyecto que a menudo se separa en un proyecto diferente. Aquí es donde se recopila el código de análisis y los datos no relacionados con el entrenamiento de los científicos de datos.

Un científico de datos puede consultar y extraer datos de la rama de monitoreo para ejecutar análisis, pruebas A/B y otros experimentos en línea y fuera de línea. También pueden utilizar datos de la rama cruda para estos propósitos.

Los ejemplos en línea son más simples, ya que cada grupo de experimentos corresponde a una rama.

💡 Consejo: Experimentos en línea comunes:

Prueba ascendente: Comparación entre el modelo actual 99% vs. un modelo candidato 1%.

Prueba posterior: después de fusionar un nuevo modelo, mantener el 1% en el modelo anterior para validar el efecto esperado al revés.

Tener la etiqueta del modelo como un parámetro en los datos de monitoreo te ayuda a identificar cada cambio en la métrica y su posible causa.

Resumen

Este artículo presenta un marco para la versión de proyectos de aprendizaje automático utilizando ramas de Git. El marco simplifica los flujos de trabajo, organiza los datos y modelos, y acopla las partes relacionadas del proyecto. Se enfatiza el uso de ramas como entornos, donde cada rama contiene los datos, el código, los modelos y la documentación necesarios para una tarea específica. El artículo también analiza conceptos clave, como el uso de diferentes categorías de ramas activas. En general, el marco tiene como objetivo mejorar la eficiencia, gobernabilidad y colaboración en los proyectos de aprendizaje automático.

Si deseas chatear o aprender más, únete a nosotros en nuestro discord o sigue nuestro blog.

Epílogo

En cuanto a mi desafío local, manteníamos una rama “estable” para cada combinación relevante de código de entrenamiento y conjunto de datos. Después de completar el entrenamiento, etiquetaríamos la confirmación con una etiqueta adecuada (<id-del-cliente>-<versión-incremental>). Los clientes pueden extraer la etiqueta más reciente, al igual que cualquier otra versión.

Cuando “depuramos” a un cliente, nos referiríamos a la etiqueta en un momento específico para revisar el código y los datos correspondientes. También podríamos hacer coincidir los datos de monitoreo usando la misma etiqueta, que se agregó a los datos de monitoreo. Los cuadernos de análisis se pueden encontrar en nuestras ramas ds/id-del-cliente.

We will continue to update Zepes; if you have any questions or suggestions, please contact us!