Les branches sont tout ce dont vous avez besoin notre cadre de versionnement ML plein d’opinions

Les branches sont tout ce dont vous avez besoin dans notre cadre de versionnement ML riche en opinions

Une approche pratique de la gestion des versions des projets d’apprentissage automatique à l’aide de branches Git qui simplifie les flux de travail et organise les données et les modèles

TL;DR

Une approche simple de la gestion des versions des projets d’apprentissage automatique à l’aide de branches Git qui simplifie les flux de travail, organise les données et les modèles, et regroupe les parties connexes du projet.

Introduction

Lors de la gestion de solutions d’apprentissage automatique, différents aspects des solutions sont souvent répartis sur plusieurs plates-formes et emplacements tels que GitHub pour le code, HuggingFace pour les modèles, Weights and Biases pour le suivi, S3 pour une copie de tout, etc.

Côté données, nous avons des données d’entraînement, des données traitées, des données de suivi de l’entraînement et des données de surveillance du modèle. Nous sauvegardons des modèles pour l’inférence, y compris les versions plus anciennes et les modèles expérimentaux pour les tests en ligne. Nous avons également du code pour le prétraitement, l’entraînement, l’inférence, l’expérimentation, l’analyse des données scientifiques et les alertes de surveillance.

Cela peut facilement devenir ingérable.

• Faire des erreurs en tant qu’analyste – et stratégies pour y faire face
• Les répéteurs quantiques utilisent des défauts dans le diamant pour interconnecter les systèmes quantiques.
• Comment l’IA peut aider les personnes atteintes de handicaps moteurs – comme mon cousin

En utilisant divers outils, environnements et adresses d’actifs pour suivre différentes parties du cycle de vie de l’apprentissage automatique, on peut obtenir des états dispersés et non coordonnés. Cela peut entraîner des pertes de données, des violations de sécurité et des erreurs de configuration qui doivent être gérées avec soin.

Dans un projet précédent, nous avons utilisé SageMaker pour l’entraînement quotidien dans une solution sur site. Cela nécessitait que les clients téléchargent un modèle quotidiennement et l’entraînent en utilisant différentes combinaisons d’ensembles de données de clients.

Nous devions gérer quel modèle binaire était entraîné avec quel code d’entraînement sur quelle donnée de quel client, quel modèle fonctionne chez quel client avec quel code d’inférence, etc.

Dans cet article, nous montrerons comment utiliser des outils de gestion des versions des données pour résoudre ces problèmes à l’aide de Git.

Les outils de gestion des versions des données vous permettent de valider les fichiers de données et de modèles avec le code, quelle que soit leur taille. En versionnant tous les fichiers de cette manière, vous pouvez contourner l’inconvénient de la gestion des actifs de données et de modèles.

Dans un monde idéal, vous n’auriez que le code, les données et les modèles pertinents pour la tâche spécifique en cours. Que vous développiez ou exécutiez l’entraînement ML, suiviez des expériences, surveilliez des modèles en production ou meniez des expériences en ligne.

Au lieu de connecter manuellement (ou même automatiquement) les bonnes pièces – charger les bonnes données dans le bon code, les connecter au bon modèle dans HuggingFace dans le bon environnement – imaginez que chaque fois que vous passez à une branche, toutes les pièces sont là.

Dans cet article, je présenterai un cadre qui remplace la complexité de jongler avec des outils par Git, un système que presque toutes les équipes d’apprentissage automatique utilisent déjà.

L’objectif est de simplifier et de supprimer les obstacles pour démarrer chaque étape du flux de travail d’apprentissage automatique en ayant tout au même endroit, géré par Git.

Nos exigences

1. Un flux de travail simple facile à mettre en pause, à reprendre, et à ajuster pour s’adapter aux besoins changeants de l’entreprise et du développement. Il devrait également prendre en charge la reproductibilité et permettre des requêtes post-factuelles, telles que “Sur quelles données mon modèle a-t-il été formé ?”
2. Une utilisation efficace des données et du code, en mettant l’accent sur la cohésion, la gouvernance et l’audit. – Visez à réutiliser autant que possible les données et le code, et tirez parti des fonctionnalités Git telles que les validations, les problèmes et les balises.
3. Consolider tous les aspects différents de la solution ML est important. Souvent, le suivi des expériences, la surveillance des modèles en production et les expériences en ligne et hors ligne sont séparés des côtés formation et inférence de la solution. Ici, nous visons à les unifier sous un même ensemble, facilitant la transition entre eux.
4. Suivre les meilleures pratiques Git et ML, telles que les découpes de données précoces et partageables, les tests et la collaboration simple, pour différents ingénieurs ML.

Concepts clés

Chaque changement est un commit Git : Cela inclut les téléversements de données, l’ingénierie des fonctionnalités, la substitution des modèles, la fusion des résultats des métriques des expériences, la surveillance des modèles et naturellement les modifications du code.

Branches actives : Il est courant d’utiliser différentes branches pour le développement et la production. Cependant, nous pouvons aller encore plus loin ici. Cela signifie que vous pouvez passer à une branche et avoir toutes les données, le code, les modèles, les documents, les fichiers readme et les cartes de modèle avec les métriques au même endroit.

🤯 Votre dépôt est votre magasin de blobs! Votre branche fonctionne comme un seau à l’intérieur de votre magasin de blobs, vous permettant de télécharger, de télécharger et de stocker des données et des modèles.

Cela vous permet d’utiliser différentes branches pour différents besoins de développement, d’expérimentation et de production, plutôt que de vous fier à différentes plateformes et outils.

Les fusions en tant que flux de travail: Elles sont utilisées pour combiner les branches. Le code est fusionné normalement, et un modèle remplace généralement le modèle existant. Lorsque les données sont fusionnées, elles sont généralement ajoutées. Pour recevoir de nouvelles données, elles sont “tirées” d’une autre branche par copie.

La fusion des données peut être aussi simple qu’une copie de fichiers ou un ajout à une liste JSON. Dans des cas plus sophistiqués, vous pouvez fusionner des bases de données SQLite.

Déduplication, une fonctionnalité couramment utilisée dans les outils de versionnage des données, empêche la création de copies multiples de fichiers, même lorsque plusieurs branches contiennent les mêmes fichiers.

Types de branches

Branche principale

Tout d’abord, nous utilisons la branche principale de notre projet pour stocker la définition du problème, la documentation, la description des données et la structure du projet. Cela sert d’espace pour la collaboration et les discussions.

CONSEIL : En commençant par définir clairement le problème commercial, déterminer le résultat souhaité, identifier les valeurs ou les étiquettes cibles et comment les obtenir, et établir des métriques d’évaluation et des exigences, nous pouvons garantir un bon départ à notre projet et offrir un lieu d’intégration et de collaboration.

Nous pouvons également l’utiliser pour suivre des expériences, où les résultats de vos expériences sont combinés. Par exemple, le dossier mlruns de MLflow peut être fusionné à cet effet. N’importe quel collaborateur peut basculer sur cette branche et exécuter l’interface utilisateur.

Alternativement, le suivi peut être fait dans une autre branche.

Commencer de cette manière est très simple, et au fur et à mesure que les besoins changent, il est possible de passer à un serveur MLflow ou à une plateforme de suivi comme Weights and Biases avec des changements minimaux.

Branches de données

Il s’agit de branches du projet, qui comprennent principalement des fichiers de données, de la documentation et des scripts de transformation, et elles restent actives. Vous pouvez les considérer comme des compartiments S3, mais au lieu de les télécharger et de les télécharger, vous basculez sur une branche et vos fichiers sont là.

Il est recommandé de toujours valider (télécharger) dans la branche raw. Cela crée une source de vérité, un endroit jamais modifié ou supprimé, afin que nous puissions toujours suivre l’origine et le passage des données. Cela permet également de créer facilement de nouveaux flux, d’auditer et de gouverner.

💡 Si vous ajoutez un message de validation indiquant l’origine des données, vous pouvez obtenir une observabilité encore plus détaillée de vos données.

Vous pouvez utiliser une autre branche propre où seules les données propres existent. Par exemple, les images cassées ou les fichiers texte vides qui ont été téléchargés dans la branche brute n’apparaissent pas dans la branche propre.

Une branche de division où les données sont divisées pour l’entraînement, la validation et les tests peut garantir que toutes les équipes et collaborateurs travaillent sur un pied d’égalité.

Cette approche aide à prévenir les fuites de données et permet un génie des fonctionnalités plus robuste et une collaboration accrue. Minimiser la possibilité que des exemples de l’ensemble de test soient inclus dans les phases d’entraînement réduit le risque d’introduction de biais. De plus, avoir tous les collaborateurs sur la même division garantit des résultats cohérents et impartiaux lors d’une expérience.

Dans un ancien projet de classification, j’ai fait partie d’une équipe de contributeurs individuels où chaque personne exécutait le pipeline complet à partir de zéro ; chacun de nous avait utilisé différentes proportions de division des données et différents grains, ce qui a conduit à des modèles plus faibles en production en raison de bugs et de biais des données.

💡 Astuce ML : Le meilleures pratique de développement de modèles en trois phases

Nous utilisons les ensembles de données “train” et “validation” pour former et optimiser les hyperparamètres du modèle. Ensuite, nous utilisons l’ensemble de formation plus validation comme ensemble de formation pour former notre modèle optimisé et évaluer avec l’ensemble de test une seule fois. Enfin, nous entraînons le modèle sur l’ensemble des données et l’enregistrons en tant que notre modèle.

Branches Stables

Ces branches sont des branches actives pour l’entraînement et l’inférence. Ici, vous pouvez exécuter votre entraînement, enregistrer votre modèle, les checkpoints et la carte modèle, exécuter des tests, construire et tester l’image Docker, commettre tout à la fin d’un cycle d’entraînement, puis Tagger. Elles devraient être capables de gérer la récupération de nouvelles données et la ré-entraînement. C’est là que se déroule l’automatisation.

⚠️ Aucun code n’est écrit dans ces branches.

Cela garantit qu’un modèle est couplé avec les données sur lesquelles il a été entraîné, le code utilisé pour l’entraîner et le faire fonctionner en production (y compris l’ingénierie des caractéristiques), et les mesures de résultats. Tous ces composants sont combinés en une seule “capture” unifiée. Chaque fois que vous récupérez un tag, toutes les pièces nécessaires pour ce modèle sont présentes.

💡 Astuce : En choisissant préalablement le nom du tag, vous pouvez ajouter les informations de suivi pendant l’entraînement en tant que paramètre. Cela garantit que vous pouvez toujours récupérer la “capture” modèle-données-code en utilisant n’importe quel outil de suivi en utilisant les données de suivi.

Après l’entraînement, seules les données de suivi sont fusionnées (copiées) dans votre branche principale pour le suivi.

Dans le cas le plus simple, il peut s’agir d’un fichier texte JSON contenant les hyperparamètres et les résultats d’évaluation. Ce fichier est ensuite ajouté à une liste dans la branche principale. Dans le cas de MLflow, cela implique de copier les expériences du dossier mlruns vers la branche principale.

Branches de Codage

Ces branches sont destinées au développement du code et à l’exploration des données, à l’entraînement sur des données échantillonnées ou de petite taille jusqu’à ce que vous ayez un programme fonctionnel. Pendant le développement, vous êtes invité à utiliser les meilleures pratiques de Git. Cependant, ne créez une branche stable que lorsque aucun autre changement de code n’est requis, même si des données supplémentaires sont ajoutées. Ces branches doivent inclure le code d’inférence, le serveur, le Dockerfile et les tests.

Il y a toujours au moins une branche de développement active, où toutes les nouvelles fonctionnalités, corrections de bugs et autres changements sont fusionnés.

💡 Les ingénieurs en ML et MLOps peuvent collaborer sur les aspects apprentissage et inférence.

Par exemple, vous pouvez créer une branche dev/modèle où vous développez un modèle de base. Il peut s’agir de la classe la plus populaire pour la classification ou de la moyenne/médiane pour la régression. L’accent est mis sur la mise en place du code tout en comprenant parfaitement vos données.

Une fois qu’il est stable et que les tests réussissent, nous créons une nouvelle branche stable/modele où nous entraînons et consignons le modèle, le code et les données ensemble sur le serveur distant et nous tagguons cette version. Cela est rapide et facile à partager, et permet aux équipes DevOps, back-end et front-end de lancer le développement et d’échanger des commentaires. Cela facilite également la validation des nouvelles exigences découvertes dans un environnement réel le plus tôt possible.

Ensuite, nous développons le modèle sur la branche de développement dev/modèle pour obtenir un modèle simple comme une régression linéaire, et lorsque cela est prêt et que les tests réussissent, nous pouvons le fusionner dans la branche stable/modele où nous entraînons, consignons et marquons une version en production.

Cette approche vous permet d’améliorer de manière progressive votre modèle tout en préservant le contexte complet des modèles précédents dans la branche stable.

À partir de ce point, nous avons trois options :

• Nous pouvons ré-entraîner lorsque de nouvelles données arrivent en les ajoutant à la branche stable.
• Nous pouvons commencer des expérimentations en utilisant l’ingénierie des caractéristiques sur la branche dev/régression-linéaire.
• Nous pouvons créer une nouvelle branche dev/nouvelle-approche pour des modèles plus sophistiqués.

Branche de Surveillance

Pour la surveillance du modèle, nous nous soucions de la distribution des données, des valeurs aberrantes et des distributions de prédictions.

Dans la branche de surveillance, nous enregistrons les données interrogées, les consignons ainsi que les prédictions du modèle depuis la production sous forme de fichiers.

💡 Vous pouvez utiliser plusieurs branches de surveillance pour chaque environnement – dev, stable et prod.

Nous pouvons configurer des alertes sur les commits de données pour tester les dérives dans les distributions de fonctionnalités, les valeurs aberrantes, les tests de calibration de la cohérence et enregistrer le code des alertes ; cela permet des solutions plus avancées comme un modèle de détection des valeurs aberrantes que nous pouvons également enregistrer dans cette branche.

Cette branche pourrait appartenir typiquement à un autre projet qui est disjoint du code responsable de la création des journaux de surveillance, ainsi que des données et du modèle qui les ont générés.

Branche d’analyse

Les sciences des données et l’analyse sont un autre aspect du projet qui est souvent séparé en un projet distinct. C’est là où le code d’analyse et les données non d’entraînement des data scientists sont rassemblés.

Un data scientist peut extraire et récupérer des données de la branche de surveillance pour effectuer des analyses, des tests A/B et d’autres expériences en ligne et hors ligne. Ils peuvent également utiliser les données de la branche brute à ces fins.

Les exemples en ligne sont plus simples, car chaque groupe d’expérimentation correspond à une branche.

💡 Astuce : Exemples courants d’expériences en ligne :

Test en avant – Comparer le modèle actuel à 99% vs. un modèle candidat à 1%.

Test en arrière – après fusionner un nouveau modèle, garder 1% sur l’ancien modèle pour valider l’effet attendu en sens inverse.

Avoir le tag du modèle comme paramètre dans les données de surveillance vous aide à identifier chaque changement dans la cause potentielle de la métrique.

Résumé

Cet article présente un framework pour la gestion des versions des projets d’apprentissage automatique à l’aide des branches Git. Le framework simplifie les flux de travail, organise les données et les modèles, et regroupe les parties connexes du projet. Il met l’accent sur l’utilisation des branches en tant qu’environnements, où chaque branche contient les données, le code, les modèles et la documentation nécessaires pour une tâche spécifique. L’article aborde également des concepts clés tels que l’utilisation de différentes catégories de branches actives. Dans l’ensemble, le framework vise à améliorer l’efficacité du flux de travail, la gouvernance et la collaboration dans les projets d’apprentissage automatique.

Si vous souhaitez discuter ou en savoir plus, rejoignez-nous sur notre discord ou suivez notre blog.

Épilogue

Concernant mon défi sur site, nous avons maintenu une branche “stable” pour chaque combinaison pertinente de code de formation et de jeu de données. Après avoir terminé la formation, nous marquerions le commit avec une balise appropriée (<id-client>-<version incrémentale>). Les clients peuvent extraire la balise la plus récente, comme pour n’importe quelle autre publication.

Lors du “débogage” d’un client, nous nous référions à la balise à un moment précis pour examiner le code et les données correspondantes. Nous pouvions également faire correspondre les données de surveillance en utilisant la même balise, qui était ajoutée aux données de surveillance. Les notebooks d’analyse peuvent être trouvés sur nos branches ds/id-client.

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