True ML Talks #2 - Flux de travail d'apprentissage automatique @ Stitch Fix

Nous avons reçu une réponse très encourageante à notre premier épisode de True ML Talks. Dans cette série, nous examinons en profondeur le pipeline de quelques grandes entreprises de ML, et dans l'épisode d'aujourd'hui, nous discutons avec Stefan Krawczyk.

Stefan développe DAGworks, une plateforme collaborative open source permettant aux équipes de science des données de créer et de gérer des pipelines de modèles, en se connectant aux MLOP et à l'infrastructure de données existantes (lisez leur YC Launch). Il a plus de 15 ans d'expérience dans des entreprises telles que Nextdoor, LinkedIn et Stitch Fix dans le domaine des données et de l'apprentissage automatique. Il a précédemment dirigé l'équipe Model Lifecycle chez Stitch Fix, où il a acquis une vaste expérience dans la création d'outils en libre-service pour une plateforme d'apprentissage automatique MLOps interne. Il donne également régulièrement des conférences et est l'auteur du célèbre framework open source Hamilton.

📌

Nos conversations avec Stefan tourneront autour de quatre thèmes clés :
1. Cas d'utilisation de l'apprentissage automatique pour les entreprises.
2. Comment l'équipe de Stitch Fix est structurée pour optimiser les résultats commerciaux.
3. Les défis rencontrés lors de la mise en place d'une suite de machines learning avec des défis spécifiques liés à l'industrie.
4. Un aperçu des innovations de pointe appliquées au cours du processus de création et de mise à l'échelle de l'infrastructure ML.

Regardez l'épisode complet ci-dessous :

ML Usecases @Stitch Fix : un service de stylisme personnalisé en ligne

1. Recommendation system → Modèles de prévision et de simulation, fournissant une ventilation des tailles et des fourchettes d'allocation.
2. Prevision and Simulation → Lorsque les acheteurs décident du nombre de vêtements à acheter, ils doivent déterminer les tailles et la population à servir. Cela implique une cascade de prévisions d'éléments que les utilisateurs utilisent en interne pour les aider à simuler ou à prévoir. L'équipe chargée des algorithmes de Stitch Fix a construit des modèles à cette fin, fournissant une ventilation des tailles et des plages d'allocation. En savoir plus sur ce sujet ici
3. Système interne de planification des ressources de l'entreprise → Stitch Fix a essentiellement construit son propre système ERP interne à l'aide d'algorithmes. Ce système permet de planifier l'inventaire, l'entreposage et d'optimiser les frais d'expédition. En savoir plus sur ce sujet ici.
4. Optimisation des itinéraires à travers l'entrepôt → Stitch Fix dispose d'une équipe qui optimise les itinéraires à travers l'entrepôt, en veillant à ce que le chemin le plus court soit emprunté pour récupérer les commandes. Cette optimisation permet de minimiser les coûts et les délais de traitement des commandes.
5. Warehouse Logistics → L'équipe des algorithmes de Stitch Fix travaille également à l'optimisation du processus de prélèvement des vêtements dans les poubelles pour satisfaire les commandes. Stitch Fix peut réduire les coûts et minimiser les délais de traitement des commandes en accélérant ce processus.

Flux de travail du système ML chez Stitch Fix

Stitch Fix dispose de deux équipes travaillant sur ses systèmes d'apprentissage automatique (ML) : les équipes de science des données et de plateforme.

• Data Science Team: L'équipe de science des données, organisée en secteurs verticaux qui aident les différents secteurs de l'entreprise, est chargée de créer des modèles pour aider les autres équipes de l'entreprise à prendre des décisions.
• Equipe de la plateforme : L'équipe de la plateforme crée des abstractions et des outils afin que les data scientists n'aient pas besoin d'autant d'ingénierie pour faire leur travail. L'équipe est divisée en plusieurs composants, tels que Spark, Hadoop, Kafka, l'infrastructure, le système d'orchestration et les environnements. Une équipe est également chargée de la pile de recommandations et du déploiement des microservices, ainsi que des tests et des expérimentations A/B. L'équipe se concentre sur les éléments d'opérationnalisation, tels que la facilitation de la formation des modèles, de leur déploiement et de leur maintenance.

👉

L'équipe Data Science est responsable de la propriété des modèles et des résultats. L'équipe de la plateforme garantit la disponibilité de l'infrastructure de déploiement et de ses composants.

Il n'y a pas eu de « transfert » du modèle entre l'équipe de science des données et l'équipe de la plateforme. Cela permet d'obtenir de nombreuses autres itérations avec le modèle.

Gestion de l'allocation des infrastructures

L'allocation de l'infrastructure est gérée par l'équipe de la plateforme, qui détenait généralement les quotas de ce qui était disponible. Les data scientists pouvaient demander des nœuds ou d'autres clusters Spark sur une interface utilisateur. Une certaine comptabilité est effectuée pour s'assurer que les coûts n'augmentent pas sans justification. L'équipe de la plateforme a essayé de permettre aux utilisateurs d'obtenir facilement ce qu'ils voulaient sans trop de main-d'œuvre, et certaines équipes détenaient les quotas et veillaient à ce que les coûts soient maîtrisés.

Des défis uniques en matière d'apprentissage automatique et de MLOps chez Stitch Fix

1. Chez Stitch Fix, plus de 100 data scientists travaillent au développement de modèles. Chaque data scientist possédant un modèle dont la durée de vie moyenne est d'au moins deux ans, de nombreuses équipes ont créé de nombreux modèles, et permettre l'appropriation d'une équipe représentait un défi de taille. L'équipe de la plateforme de StitchFix a développé de nombreuses solutions en interne et n'a acheté que peu de choses en raison de l'hétérogénéité des bibliothèques et des frameworks utilisés. La standardisation aurait facilité certaines plateformes, mais différentes équipes avaient des problèmes différents et les bibliothèques étaient mieux adaptées à ces problèmes. L'équipe chargée de la plateforme de StitchFix a dû créer ses propres solutions, comme Model Envelope et Hamilton, car aucune solution open source ne répondait bien à ses besoins.
2. Bien qu'il soit facile de créer des modèles, quelqu'un doit gérer tous les ETL, et si quelqu'un quitte l'entreprise, cela peut entraîner des problèmes. Jeter du code est une perte de temps, et les nouveaux membres de l'équipe sont ralentis jusqu'à ce qu'ils puissent comprendre ce qui existait avant eux. De plus, étant donné que les utilisateurs s'appuient souvent sur les modèles d'autres équipes pour les utiliser comme fonctionnalités, il existe des interdépendances entre les ETL qui doivent être prises en compte.

« L'une des raisons pour lesquelles je suis resté si longtemps chez Stitch Fix était précisément à cause de ces défis et de la recherche de solutions pour les résoudre. » - Stefan

Innovations apportées à la plateforme Stitch Fix ML

1. Modèles d'enveloppes : L'équipe chargée de la plateforme de Stitch Fix a développé un système qui a permis aux data scientists de regrouper leurs modèles avec les autres composants nécessaires et de les expédier facilement. Il s'agit d'un système basé sur une API qui capture de nombreuses choses. Grâce à un seul bouton et à une configuration supplémentaire, les data scientists peuvent déployer leurs modèles en production en moins d'une heure. Le système a également activé les tâches par lots et a facilité l'exécution de modèles de manière distribuée sur Spark.
2. ETL piloté par la configuration : L'équipe chargée de la plateforme de Stitch Fix a utilisé YAML et Jinja pour permettre aux data scientists de décrire le processus ETL, qui comprenait du code SQL et Python pour l'ajustement des modèles. L'idée était d'abstraire le système d'orchestration et de permettre à l'équipe de la plateforme d'échanger différents composants hors du conteneur Docker, ce qui a facilité la gestion et la maintenance de la base de code.
3. Hamilton : Hamilton est un micro-framework déclaratif permettant de décrire les flux de données. L'équipe chargée de la plateforme de Stitch Fix l'a développée pour faciliter l'ingénierie des fonctionnalités, en particulier pour la prévision des séries chronologiques, où il est facile de sélectionner des milliers de fonctionnalités. Hamilton aide à structurer le problème, de la même manière que DBT pour SQL, mais pour les transformations Python. Il permet de décrire le flux de données sans gérer de scripts Python. Les fonctions déclarent un flux de données et les définitions peuvent être facilement partagées et exécutées dans des contextes hors ligne et en ligne.

👉

Pour l'échange de composants Docker, l'équipe de la plateforme a essayé de créer une API dorée permettant aux data scientists de décrire ce qu'ils souhaitaient sans avoir à se soucier des dépendances de la plateforme. Cela a été fait par le biais de pipelines de modèles pilotés par la configuration, dans lesquels les data scientists pouvaient fournir du texte contenant des sous-ensembles de modifications. L'équipe de la plateforme pourrait alors changer les choses sans demander à l'équipe de data scientists de mettre à jour ou de mettre à niveau ses conteneurs Docker. L'équipe de la plateforme pourrait également mettre à jour les journaux ou les méta-informations sans que les utilisateurs aient à redéployer ou à réécrire leurs pipelines. Cela a supprimé la nécessité pour les équipes de gérer et de mettre à jour les éléments et a permis à l'équipe de la plateforme de gérer et de mettre à jour les éléments plus efficacement sans nécessiter de migration de la part de l'équipe de data scientists.

Améliorer le temps de création et de débogage des conteneurs Docker dans le cadre du développement à distance : stratégies utilisées par Stitch Fix

1. Mise en cache pour accélérer la création de conteneurs - L'équipe de la plateforme de Stitch Fix a tenté d'accélérer la création de conteneurs Docker en mettant en cache des bibliothèques et des environnements fréquemment utilisés. Par exemple, ils ont ajouté la mise en cache pour s'assurer que si les mêmes exigences étaient à nouveau requises, ils n'auraient pas à être réinstallés. Ils ont également enregistré les fichiers d'environnement, les ont compressés, puis les ont récupérés pour accélérer le processus.
2. Local development for minimiser le temps de création et de débogage des conteneurs - L'équipe chargée de la plateforme de Stitch Fix a encouragé les développeurs à développer localement ou à trouver des moyens d'éviter d'attendre un cycle complet de création, d'exécution et de débogage du conteneur Docker. Ils ont permis à des boucles locales de s'exécuter pour les différentes étapes de l'ETL en extrayant certaines données pour les mettre en cache pour les développeurs, entre autres fonctionnalités d'utilisabilité. Cette approche a permis d'accélérer le processus de développement et de débogage.
3. Explorer de nouvelles approches pour améliorer le temps de création et de débogage des conteneurs - Bien que l'équipe chargée de la plateforme de Stitch Fix ait tenté d'améliorer le temps de compilation et de débogage grâce à la mise en cache et au développement local, elle a reconnu que le processus pourrait être plus rapide. Certains développeurs travaillent sur des modifications à apporter à Docker afin d'améliorer ce processus, en particulier pour les modèles. Cette approche implique de changer Docker et de le redémarrer pour le rendre meilleur et plus efficace.

Recommandations de Stefan Krawczyk en matière d'outillage MLOps

Il est important de choisir des outils en fonction de l'impact commercial et des SLA. Les tâches qui peuvent être effectuées avec un seul nœud doivent être optimisées à l'aide d'un système d'orchestration. Pour le versionnage des données et les registres de modèles, il peut être utile d'enregistrer des éléments dans S3 dans une structure de chemin structurée et d'y stocker des métadonnées. En ce qui concerne le registre de modèles, des outils open source tels que MLflow devraient vous aider, mais il existe également des solutions de gestion hébergées comme TrueFoundry.

Il est important de disposer d'un système de test A/B dans la pile pour comprendre la valeur que leur modèle apporte à leur entreprise. Cela aidera à prendre des décisions quant aux domaines dans lesquels investir dans les pratiques MLOps en fonction de l'impact de leur modèle.

Recommendation on the MLOPS tools

1. Tenez compte de l'hétérogénéité des bibliothèques et des frameworks : s'il existe une hétérogénéité significative dans les bibliothèques et les frameworks utilisés, il peut être nécessaire de créer des solutions internes car il se peut qu'il n'existe pas de solutions prêtes à l'emploi qui répondent à vos besoins.
2. La standardisation peut faciliter certaines plateformes : si différentes équipes peuvent rencontrer des problèmes différents, la standardisation de certains outils et processus peut faciliter Plateformes MLOps plus facile à construire et à entretenir.
3. Aucune solution open source adaptée à vos besoins ? Créez les vôtres : s'il n'existe pas de solutions open source qui répondent bien à vos besoins, il peut être nécessaire de créer vos propres solutions, comme Model Envelope et Hamilton, pour atteindre vos objectifs MLOps.

Les défis liés à l'ETL dans l'apprentissage automatique

Dans le domaine de l'apprentissage automatique, Extract, Transform, Load (ETL) est un processus essentiel pour transformer les données brutes en informations précieuses. Cependant, l'ETL dans les systèmes d'apprentissage automatique pose plusieurs défis qui doivent être relevés.

Les ETL des systèmes d'apprentissage automatique peuvent rester silencieuses en raison de changements en amont, ce qui rend difficile pour les professionnels des données de retracer les entrées du modèle, ce qui complique la gestion des ETL. La complexité des ETL augmente également au fil du temps, ce qui rend difficile pour les équipes de suivre le rythme.

DagWorks : une plateforme ETL open source pour les équipes de science des données

Pour relever les défis mentionnés dans la section précédente, DagWorks développe une plateforme ETL open source pour les équipes de science des données qui a réduit leur dépendance à l'égard de l'ingénierie. L'open source se trouve autour de Hamilton, comme indiqué ci-dessus. Hamilton, permet aux professionnels des données sans formation en génie logiciel d'écrire du code destiné à la production et de gérer les artefacts ETL d'apprentissage automatique sur leur infrastructure existante. Hamilton fournit également un magasin central de définitions de fonctionnalités et un lignage, ce qui facilite le débogage et peut être utilisé pour les cas de conformité.

Hamilton est conçu pour être une couche d'abstraction qui peut être utilisée avec divers outils d'orchestration tels que Airflow ou Argo. Stefan pense que les data scientists ne devraient pas avoir à se soucier de la topologie de l'endroit où les choses s'exécutent et se concentrer plutôt sur la création de modèles et d'itérations. DagWorks essaie de trouver des moyens et des abstractions pour faciliter le changement de fournisseur de qualité des données sans avoir à réécrire les choses.

Hamilton complète des outils tels que Metaflow, mais n'essaie pas de les remplacer. Au contraire, il permet aux utilisateurs d'être plus productifs en utilisant ces systèmes en leur permettant de modéliser le micro au sein d'une tâche. Dans l'ensemble, DagWorks essaie de permettre aux équipes de science des données de gérer et de gérer plus facilement les artefacts ETL d'apprentissage automatique.

Vous trouverez ci-dessous quelques lectures intéressantes de Stefan et de son équipe :

Ce que j'ai appris en créant des plateformes chez Stitch Fix

Free Deploiement : une plateforme d'apprentissage automatique pour les data scientists de Stitch Fix

La fonction, le contexte et les données : activation des opérations de machine learning chez Stitch Fix

Read our previous article of the series

‍

True ML Talks #1 - Machine Learning Workflow @ Gong

Learn how Gong, a revenue intelligence platform, uses machine learning to analyze customer interactions and provide insights to revenue teams. Discover the challenges of managing ML workflows, data privacy, and data security.

TrueFoundry Blog TrueFoundry

‍

Continuez à regarder le TrueML youtube series et en lisant tout le TrueML blog series.

True Foundry est un PaaS de déploiement de machine learning sur Kubernetes destiné à accélérer les flux de travail des développeurs tout en leur offrant une flexibilité totale dans les tests et le déploiement de modèles, tout en garantissant une sécurité et un contrôle complets à l'équipe Infra. Grâce à notre plateforme, nous permettons aux équipes de machine learning de déployer et surveiller des modèles en 15 minutes avec une fiabilité à 100 %, une évolutivité et la possibilité de revenir en arrière en quelques secondes, ce qui leur permet de réduire les coûts et de mettre les modèles en production plus rapidement, ce qui permet de réaliser une véritable valeur commerciale.