🌈 👼 🙋🏼 Pourquoi avons-nous besoin de DevOps dans le domaine des données ML 🌃 👁️ 🚙

Déployer le machine learning (ML) en production n'est pas une tâche facile, mais en fait, c'est un ordre de grandeur plus difficile que de déployer un logiciel conventionnel. En conséquence, la plupart des projets ML ne verront jamais le jour - et la production - car la plupart des organisations abandonnent et abandonnent en essayant d'utiliser ML pour promouvoir leurs produits et servir les clients.

Pour autant que nous puissions voir, l'obstacle fondamental pour la plupart des équipes à créer et déployer ML en production à l'échelle attendue est que nous n'avons toujours pas pu introduire des pratiques DevOpsdans l'apprentissage automatique. Le processus de création et de déploiement de modèles ML est partiellement divulgué par les solutions MLOps qui ont déjà été publiées, mais elles manquent de support de l'un des aspects les plus difficiles du ML: les données.

Dans cet article, nous expliquons pourquoi l'industrie a besoin de solutions DevOps pour les données ML et comment les difficultés uniques des données ML entravent les efforts pour mettre le ML en pratique et le déployer en production. L'article décrit le vide dans l'écosystème d'infrastructure ML actuel et suggère de le remplir avec Tecton, une plateforme de données centralisée pour l'apprentissage automatique. Cliquez ici pour lire un article de mon co-fondateur Mike pour plus de détails sur le lancement de Tecton.

Tecton a été créé par une équipe d'ingénieurs qui a créé des plateformes ML internes dans des sociétés telles que Uber, Google, Facebook, Twitter, Airbnb, AdRoll et Quora. Les investissements importants de ces sociétés dans le ML ont permis le développement de processus et d'outils pour une large utilisation du ML pour leurs organisations et leurs produits. Les leçons présentées dans cet article, ainsi que la plate-forme Tecton elle-même, sont largement basées sur l'expérience de notre équipe de déploiement ML en production au cours des dernières années.

Rappelez-vous le moment où la version du logiciel a été longue et douloureuse?

Le processus de développement et de déploiement de logiciels il y a vingt ans et le processus de développement d'applications ML de nos jours ont beaucoup en commun: les systèmes de rétroaction se sont révélés incroyablement longs, et au moment où vous êtes arrivé à la sortie du produit, vos exigences et votre conception initiales étaient déjà devenues obsolètes. Et puis, à la fin des années 2000, un ensemble de bonnes pratiques pour le développement de logiciels sous forme de DevOps est apparu , fournissant des méthodes pour gérer le cycle de vie du développement et nous permettant de réaliser des améliorations continues et rapides.

L'approche DevOps permet aux ingénieurs de travailler dans une base de code commune bien définie. Une fois qu'un changement progressif est prêt pour le déploiement, l'ingénieur le valide via un système de contrôle de version. Le processus d'intégration et de livraison continues (CD / CI) prend les modifications les plus récentes, effectue des tests unitaires, crée de la documentation, effectue des tests d'intégration et, par conséquent, de manière contrôlée, publie les modifications de la production ou prépare une version pour la distribution.

Figure. 1: processus DevOps typique Caractéristiques

principales de DevOps:

Les programmeurs possèdent leur code du début à la fin. Ils sont responsabilisés et entièrement responsables de chaque ligne de code en production. Ce sentiment d'appartenance améliore généralement la qualité du code, ainsi que la disponibilité et la fiabilité des programmes.
Les équipes sont capables de répéter rapidement les processus et ne sont pas contraintes par des cycles de plusieurs mois du modèle en cascade. Au lieu de cela, ils sont capables de tester de nouvelles fonctionnalités avec de vrais utilisateurs presque immédiatement.
Les problèmes de performances et de fiabilité sont rapidement détectés et analysés. Si les mesures de performances chutent immédiatement après le dernier déploiement, une restauration automatique est déclenchée et les modifications qui ont provoqué le déploiement dans le code sont très susceptibles d'entraîner la chute des mesures.

De nos jours, de nombreuses équipes de développement ont adopté cette approche intégrée comme base.

... En général, le déploiement du ML est encore long et douloureux

Contrairement au développement de logiciels, il n'existe pas de processus bien définis et entièrement automatisés pour une production rapide dans l'analyse des données. Le processus de création d'une application ML et de déploiement de celle-ci dans un produit comprend plusieurs étapes:

Fig. 2: les spécialistes de l'analyse des données doivent coordonner leur travail entre plusieurs équipes dans différents domaines

Découverte et accès aux données sources. Les spécialistes de la science des données de la plupart des entreprises passent jusqu'à 80% de leur temps à rechercher des données sources pour modéliser leur problème. Cela nécessite souvent une coordination interfonctionnelle avec les ingénieurs de données et l'équipe de réglementation.
. , . , , .
. . ( ).
Déploiement et intégration du modèle. Cette étape implique généralement l'intégration avec un service qui utilise le modèle de prévision. Par exemple, l'application mobile d'un détaillant en ligne qui utilise un modèle de recommandation pour prédire les offres de produits.
Configuration de la surveillance. Encore une fois, pour vous assurer que le modèle ML et les processus de données fonctionnent correctement, l'aide des programmeurs est requise.

En conséquence, les équipes ML sont confrontées aux mêmes problèmes que les programmeurs ont rencontrés il y a vingt ans:

Les experts en science des données n'ont pas la pleine propriété du cycle de vie des modèles et des fonctionnalités. Pour déployer leurs montages et les accompagner dans la production, ils doivent compter sur les autres.
data science . . . , , data science, , , , , .

. 3: ,

. data science, . , , , .

DevOps ML . DevOps ML data

De telles plateformes MLOps comme Sagemaker Kubeflow et vont dans la bonne direction pour aider les entreprises à simplifier la production de ML, afin que nous puissions observer comment MLOps introduit les principes et les outils DevOps en ML. Pour commencer, ils ont besoin d'investissements initiaux assez décents, mais après une bonne intégration, ils sont en mesure d'étendre les capacités des spécialistes de la science des données dans le domaine de la formation, de la gestion et de la production de modèles ML.

Malheureusement, la plupart des outils MLOps ont tendance à se concentrer sur le flux de travail autour du modèle lui-même (formation, mise en œuvre, gestion), ce qui crée un certain nombre de difficultés pour les ML existants. Les applications ML sont définies par du code, des modèles et des données.. Leur succès dépend de la capacité de créer des données ML de haute qualité et de les livrer à la production assez rapidement et de manière stable ... sinon, c'est un autre "garbage in, garbage out". Le diagramme suivant, spécialement sélectionné et adapté des travaux de Google sur la dette technique en ML, illustre les éléments "centrés sur les données" et "centrés sur le modèle" dans les systèmes ML. Aujourd'hui, les plateformes MLOps aident avec de nombreux éléments «centrés sur le modèle», mais seulement avec quelques éléments «centrés sur les données» ou ne les affectent pas du tout:

Fig. 4: Modèle et éléments atacentriques des systèmes ML. Aujourd'hui, les éléments centrés sur le modèle sont largement couverts par les systèmes MLOps.

La section suivante présente certains des tests les plus difficiles que nous ayons rencontrés pour simplifier la production de ML. Ce ne sont pas des exemples complets, mais ils sont conçus pour montrer les problèmes que nous rencontrons lors de la gestion du cycle de vie des données ML (fonctions et étiquettes):

Accès aux sources de données source correctes
Création de fonctions et d'étiquettes à partir des données source
Combinaison de fonctions dans les données d'entraînement
Calcul et délivrance des fonctions en production
Suivi de production

Un petit rappel avant de plonger plus loin: la fonction ML est les données qui servent d'entrée au modèle pour prendre une décision. Par exemple, un service de livraison de nourriture souhaite indiquer le délai de livraison prévu dans son application. Pour ce faire, il est nécessaire de prévoir la durée de préparation d'un plat particulier, dans un restaurant particulier, à un moment précis. L'un des signaux pratiques pour créer une telle prévision - un indicateur de l'occupation du restaurant - sera le «compte final» des commandes entrantes au cours des 30 dernières minutes. La fonction est calculée en fonction du flux de données d'entrée sur les commandes:

Fig. 5: Les données initiales sont modifiées par la transformation de la fonction en valeurs de fonction

Date de test n ° 1: Accéder aux bonnes données source

Pour créer une fonction ou un modèle, un spécialiste de la science des données doit d'abord trouver la bonne source de données et y accéder. Il y a plusieurs obstacles en cours de route:

Découverte de données: les professionnels doivent savoir où se trouvent les données source. Les systèmes de catalogage de données (comme Amundsen de Lyft ) constituent une excellente solution , mais ils ne sont pas encore utilisés de manière aussi universelle. Souvent, les données nécessaires n'existent tout simplement pas et doivent donc d'abord être créées ou cataloguées.
Approbation de l'accès: se déplacer souvent entre les autorités pour obtenir des autorisations d'accès aux données qui résoudront les problèmes est une étape obligatoire sur le chemin des experts en science des données.
: , , . , .

- #2:

Les données sources peuvent provenir de nombreuses sources, chacune avec ses propres propriétés importantes qui affectent les types de fonctions qui en sont extraites. Ces propriétés incluent la prise en charge des sources de données pour les types de transformation , la pertinence des données et la quantité d'archives de données disponibles :

Fig. 6: Différentes sources de données ont différentes approches pour différents types de transformation de données et donnent accès à différentes quantités de données en fonction de la pertinence.

Il est important de prendre en compte ces propriétés, car les types de sources de données déterminent les types de fonctions qu'un spécialiste de la science des données peut obtenir à partir des données sources:

( Snowflake Redshift) ( ). , , « ».
( MongoDB MySQL) . , 24 .
( Kafka) ( ). . , « 30 ».
Les données de requête de prédiction sont les données initiales des événements qui se produisent en temps réel juste avant qu'une prévision ML soit faite, par exemple, une requête qui vient d'être entrée par l'utilisateur dans la barre de recherche. Même si ces données sont limitées, elles sont souvent «fraîches» autant que possible et contiennent un signal facilement prévisible. Ces données sont fournies avec une demande de prédiction et peuvent être utilisées dans des calculs en temps réel tels que la recherche d'estimations de similitude entre la requête de recherche d'un utilisateur et des documents dans un tableau de recherche.

Pour l'avenir, nous attirons l'attention sur: la combinaison de données provenant de différentes sources avec des caractéristiques complémentaires vous permet de créer de très bonnes fonctions. Une telle approche nécessite la mise en œuvre et la gestion de transformations de fonctions plus avancées.

Date de test n ° 3: Combinaison de fonctions en données de formation

La formation d'ensembles de données de formation ou de test nécessite de combiner les données des fonctions correspondantes. Dans ce cas, il est nécessaire de suivre de nombreux détails qui peuvent avoir des effets critiques sur le modèle. Les deux plus insidieuses sont:

Fuite de données: les spécialistes de la science des données doivent s'assurer que leur modèle est formé sur les informations correctes et ne pas permettre la «fuite» d'informations indésirables dans les données de formation. De telles données peuvent être: des données d'une suite de tests, des données de la vérité du terrain, des données du futur ou des informations qui violent des processus préparatoires importants (par exemple, l'anonymisation).
: — . ( ). , data science , .

- #4:

Une fois le modèle mis en service en temps réel, afin de créer des prévisions correctes et pertinentes, il doit constamment fournir de nouvelles données de fonction - souvent à grande échelle et avec un temps d'attente minimum.

Comment transmettre ces données aux modèles? Directement à la source? La réception et le transfert de données depuis le stockage peuvent prendre des minutes, des jours, des heures, voire des jours, ce qui est trop long pour la sortie de données en temps réel et, par conséquent, dans la plupart des cas, il est impossible.

Dans de tels cas, le calcul des fonctions et la consommation des fonctions doivent être désactivés. Pour le calcul préliminaire (pré-calcul)et leur expédition vers l'entrepôt de données de production optimisé pour la livraison, il est nécessaire d'utiliser des processus ETL. Ces processus créent des difficultés supplémentaires et nécessitent de nouveaux coûts de maintenance:

Recherche du compromis optimal entre pertinence et rentabilité: Le déblocage du calcul et de la consommation des fonctions donne la priorité à la pertinence. Souvent, en raison de l'augmentation des coûts, les processus de fonctions peuvent être exécutés plus souvent et, par conséquent, produire des données plus pertinentes. Le bon compromis varie selon la fonction et le cas d'utilisation. Par exemple, la fonction d'agrégation d'une fenêtre de facture finale de livraison de trente minutes aura un sens si elle est mise à jour plus souvent qu'une fonction similaire avec une fenêtre de facture finale de deux semaines.

Intégration des processus fonctionnels:Accélérer la production de fonctions nécessite d'obtenir des données de plusieurs sources différentes, et par conséquent, résoudre les problèmes associés à cela est plus compliqué que lorsque vous travaillez avec une seule source de données, dont nous avons discuté précédemment. La coordination de tels processus et l'intégration de leurs résultats dans un seul vecteur de fonctions nécessite une approche sérieuse de l'ingénierie des données.

Prévention des distorsions dans la formation ( formation / service-biais ):Les écarts entre les résultats de l'apprentissage et les processus de travail peuvent entraîner des distorsions dans l'apprentissage. Les distorsions pendant l'entraînement sont assez difficiles à détecter et leur présence peut rendre les prévisions du modèle inutilisables. Le modèle peut se comporter de manière chaotique lorsqu'il tire des conclusions basées sur des données générées différemment de celles sur lesquelles il a été formé. En soi, la question de la distorsion et de travailler avec eux mérite une série d'articles distincts. Cependant, il convient de souligner deux risques typiques:

: ( ) , . Null? ? . .

. 7 ,

́ : - ( ). , , , . , , . — , , , .

Figure. 8: Le graphique montre le décompte final des commandes: sur (1) les valeurs de la fonction émise pour la prévision et mise à jour toutes les 10 minutes sont affichées; sur (2) les données de formation sont affichées qui affichent incorrectement les vraies valeurs beaucoup plus clairement en comparaison avec les fonctions émises pour la production

Date de test n ° 5: Suivi des fonctionnalités en production

Quelque chose va casser, malgré toutes les tentatives pour contourner correctement les problèmes ci-dessus. Lorsqu'un système ML tombe en panne, cela se produit presque toujours en raison d'une «violation de l'intégrité des données». Ce terme peut indiquer de nombreuses raisons différentes, chacune nécessitant un suivi. Exemples de violations de l'intégrité des données:

: , , . , , . , .
: , . , , (, ), .
: . , (, , ) .
Responsabilité peu claire de la qualité des données: dans le cas où les fonctions peuvent recevoir des données source de plusieurs sources de distribution différentes, qui est ultimement responsable de la qualité de la fonction? Le spécialiste de la science des données qui a créé la fonction? Spécialiste en science des données qui a formé le modèle? Propriétaire du canal de transmission de données? Le programmeur qui a réalisé l'intégration du modèle en production? Dans les cas où les responsabilités ne sont pas claires, les problèmes ne sont pas résolus trop longtemps.

De tels tests créent un parcours du combattant presque insurmontable, même pour les équipes les plus avancées dans le domaine de la science des données et de l'ingénierie ML. Les résoudre nécessite quelque chose de mieux que le statu quo inchangé de la plupart des entreprises, lorsque des solutions individuelles sur mesure restent la seule réponse à un sous-ensemble de ces problèmes.

Présentation de Tecton: une plate-forme d'apprentissage de machine à datter

Chez Tecron, nous créons une plate-forme de datation pour l'apprentissage automatique afin de fournir une assistance pour les problèmes les plus courants et les plus difficiles dans le domaine de la science des données.

À un niveau élevé, la plateforme Tecron a:

Processus de fonction pour transformer vos données source en fonctions et étiquettes
Référentiel de fonctions pour stocker les données de fonction et de balise archivées
Serveur de fonctions pour l'émission des dernières valeurs de fonction en production
SDK pour la formation des données et la manipulation des processus de fonction
Interface Web pour surveiller et suivre les entités, les étiquettes et les jeux de données
Moteur de surveillance pour déterminer la qualité des données ou les problèmes de dérive et alertes

Figure. 9: Étant la plate-forme centrale de données pour ML, Tecton fournit des fonctions dans les environnements de développement et de production.

La plate-forme permet aux équipes ML d'apporter des pratiques DevOps aux données ML:

Planification: les fonctionnalités de Tecron sont stockées dans un référentiel central. Cela permet aux spécialistes de la science des données de partager, de trouver et d'utiliser les travaux de chacun.
Code: Tecton permet aux utilisateurs de mettre en place des processus de transformation de fonctions simples et flexibles.
Build: Tecton compile les fonctions en tâches de traitement de données hautes performances.
Tests: Tecton prend en charge les tests fonctionnels et d'intégration des fonctions.
Sortie: Tecton s'intègre étroitement avec git. Toutes les descriptions de fonctions ont un contrôle de version et sont faciles à reproduire.
: Tecton ( Spark). Tecron.
: Tecton data science , .
: Tecton .

Bien sûr, les données ML sans modèle ML ne vous donneront pas une implémentation pratique de ML. Par conséquent, Tecton fournit des API flexibles et s'intègre aux plates-formes ML existantes. Nous avons commencé avec Databricks, SageMaker et Kuberflow, et continuons à nous intégrer à des composants d'écosystème complémentaires.

Pourquoi avons-nous besoin de DevOps dans le domaine des données ML