Le guide le plus détaillé sur MLOps : partie 1

Salut Hackernoon ! Dans cet article, je discuterai en détail du concept de MLOps. De plus, je le ferai de 3 manières. Premièrement, théoriquement - via le schéma MLOps le plus judicieux. Ensuite, sur le plan conceptuel, à travers les artefacts qui sont intégrés à la démarche. Et enfin, en comprenant MLOps comme un système d’information.

Alors, commençons.

Qu’est-ce que MLOps ?

Cette question préoccupe depuis longtemps de nombreuses équipes de développement de systèmes ML. Par un tel système dans cet article, j'entendrai un système d'information dont un ou plusieurs composants contiennent un modèle entraîné qui exécute une partie de la logique métier globale.

Comme tout autre composant du système, cette partie de la logique métier doit être mise à jour pour répondre à l’évolution des attentes de l’entreprise et des clients. MLOps concerne cette mise à jour régulière.

Définition et explication MLOps

Il n’existe pas encore de définition unique et convenue du MLOps. De nombreux auteurs ont tenté de le donner, mais il était difficile d’en trouver à la fois une description claire et systématique.

Il y en a un qui pourrait être considéré comme tel :

MLOps est une discipline d'ingénierie qui vise à unifier le développement (dev) de systèmes ML et le déploiement (ops) de systèmes ML pour standardiser et rationaliser la livraison continue de modèles hautes performances en production.

Soulignons les parties critiques de la définition MLOps :

• Discipline d'ingénierie
• Vise à unifier les processus de développement et de déploiement des systèmes ML
• Standardise et optimise la livraison continue des nouvelles versions
• Modèles performants

Ainsi, MLOps est une sorte de DevOps pour les modèles ML.

Histoire de l'émergence du MLOps

Il est facile de croire qu’une telle discipline d’ingénierie est née dans une grande entreprise informatique. Nous pouvons donc faire confiance à la théorie selon laquelle MLOps, en tant qu'approche significative, est originaire de Google, où D. Sculley essayait d'économiser ses nerfs et son temps des tâches banales liées à la sortie de modèles ML vers des extensions. D. Sculley est désormais largement connu sous le nom de « Le parrain des MLOps » - le podcast du même nom est facile à trouver en ligne.

D. Sculley a commencé à considérer le travail avec des modèles du point de vue du devoir technique de l'équipe. Oui, il est possible de publier rapidement de nouvelles versions de modèles, mais le coût de support du système résultant aura un impact significatif sur le budget de l'entreprise.

Son travail a abouti à l'article "Dette technique cachée dans les systèmes d'apprentissage automatique " publié en 2015 lors de la conférence NeurIPS. La date de publication de cet article peut être considérée comme le point de départ de l'existence de MLOps.

Niveaux de maturité MLOps : les modèles les plus connus

Comme la plupart des processus informatiques, les MLOps ont des niveaux de maturité. Ils aident les entreprises à comprendre où elles en sont actuellement et comment elles peuvent passer au niveau suivant (si un tel objectif existe). De plus, les méthodes généralement acceptées de détermination de la maturité vous permettent de déterminer votre place parmi les concurrents.

Modèle de maturité GigaOm MLOps

Le modèle le plus détaillé et le plus compréhensible provient de la société d'analyse GigaOm . Il est le plus proche de l’intégration du modèle de maturité des capacités (CMMI) de tous les modèles. Il s'agit d'un ensemble de méthodologies pour améliorer les processus organisationnels, qui comprend également 5 niveaux - de 0 à 4.

Le modèle de GigaOm présente chaque niveau de maturité à travers 5 catégories : stratégie, architecture, modélisation, processus et gouvernance.

Guidé par ce modèle dès les premières étapes de la construction d’un système ML, vous pouvez réfléchir à l’avance aux aspects essentiels et réduire les risques d’échec. Passer d'un niveau de maturité à un niveau supérieur présente à l'équipe de nouveaux défis dont elle n'avait peut-être pas réalisé l'existence auparavant.

Modèle de maturité Google MLOps

Il convient de noter que Google dispose également de son modèle de niveaux de maturité MLOps . Ce fut l'un des premiers à apparaître. Il est concis et se compose de 3 niveaux :

• Niveau 0 : Processus manuel
• Niveau 1 : automatisation du pipeline ML
• Niveau 2 : automatisation du pipeline CI/CD

Il est difficile d'échapper à l'idée que ce modèle ressemble à un manuel d'instructions pour peindre un hibou. Tout d’abord, faites tout à la main, assemblez les pipelines ML et finalisez les MLOps. Cela dit, c'est bien décrit.

Modèle de maturité Azure MLOps

Aujourd'hui, de nombreuses grandes entreprises utilisant le ML ont compilé leurs modèles de maturité. Azur , qui utilise une approche similaire pour distinguer les niveaux, est inclus. Cependant, ils sont plus nombreux que ceux de Google :

• Niveau 0 : pas de MLOps
• Niveau 1 : DevOps mais pas de MLOps
• Niveau 2 : Formation automatisée
• Niveau 3 : Déploiement automatisé de modèles
• Niveau 4 : Opérations automatisées MLOps complètes

Tous les modèles mis en évidence convergent vers une chose. Au niveau zéro, ils n’ont aucune pratique de ML. Au dernier niveau, ils disposent de l'automatisation des processus MLOps. Il y a toujours quelque chose de différent au milieu, lié à l'automatisation incrémentielle des processus. Azure dispose de cette automatisation du processus de formation puis du déploiement du modèle.

Cadre conceptuel MLOps

Comment décrivez-vous tous les processus associés au concept de MLOps ? Étonnamment, trois Allemands - les auteurs de l'article " Opérations d'apprentissage automatique (MLOps) : présentation, définition et architecture " - ont même réussi à les résumer dans un seul diagramme. Ils ont mené une véritable étude et décrit le concept de MLOps de manière très détaillée.

Cela peut être intimidant car de nombreux éléments interagissent les uns avec les autres. Cependant, on y retrouve bon nombre des caractéristiques des niveaux de maturité mentionnés ci-dessus. Au moins les pipelines automatisés, le CI/CD, la surveillance, le registre de modèles, l'orchestration du flux de travail et le composant de service.

Discutons de ce diagramme et parlons de chacun plus en détail.

Processus de base MLOps

Les principales parties du schéma sont des blocs horizontaux, au sein desquels les aspects procéduraux des MLOps sont décrits (les lettres A, B, C et D leur sont attribuées). Chacun d'eux est conçu pour résoudre des tâches spécifiques dans le cadre du bon fonctionnement des services ML de l'entreprise. Pour faciliter la compréhension du schéma, il est préférable de commencer dans le désordre.

Expérimentation

Si une entreprise dispose de services ML, les employés travaillent dans Jupyter. Dans de nombreuses entreprises, il s’agit de l’outil sur lequel sont centrés tous les processus de développement ML. C'est là que commencent la plupart des tâches qui nécessitent la mise en œuvre de pratiques MLOps.

Prenons un exemple. L'entreprise A doit automatiser une partie de certains processus à l'aide de l'apprentissage automatique (supposons qu'il existe un service et des spécialistes correspondants). Il est peu probable que la manière de résoudre le problème soit connue à l’avance. Par conséquent, les exécuteurs doivent étudier l’énoncé du problème et tester les moyens possibles de le réaliser.

Pour ce faire, un ingénieur ML/développeur ML écrit du code pour diverses implémentations de tâches et évalue les résultats obtenus par les métriques cibles. Tout cela se fait presque toujours dans Jupyter Lab. Sous une telle forme, il est nécessaire de capturer manuellement de nombreuses informations importantes, puis de comparer les implémentations entre elles.

Une telle activité est appelée expérimentation. Cela signifie obtenir un modèle ML fonctionnel, qui peut être ensuite utilisé pour résoudre des problèmes pertinents.

Le bloc C présenté dans le diagramme décrit le processus de réalisation d'expériences de ML.

Analyser les données disponibles dans le cadre de la tâche

De nombreuses décisions en matière de développement ML sont prises sur la base de l'analyse des données disponibles dans l'entreprise. Il n'est pas possible d'entraîner un modèle avec des métriques de qualité cibles sur des données de mauvaise qualité ou des données qui n'existent pas.

Il est donc important de déterminer quelles données nous avons obtenues et ce que nous pouvons en faire. Pour ce faire, on peut par exemple :

• Mener une étude ADHoc à l'aide de Jupyter ou Superset
• EDA standard (analyse exploratoire des données)

Une meilleure compréhension des données ne peut être obtenue qu’en association avec une analyse sémantique et structurelle.

Toutefois, ce n'est que parfois que la préparation des données relève du contrôle de l'équipe de projet. Dans ce cas, des difficultés supplémentaires sont assurées. Parfois, à ce stade, il devient clair qu'il ne sert à rien de développer davantage le projet car les données ne sont pas adaptées au travail.

Constitution d'un ensemble de données de qualité

Lorsqu’on a confiance dans les données disponibles, il est nécessaire de réfléchir aux règles de prétraitement. Même s'il existe un grand nombre de données appropriées, rien ne garantit qu'elles ne contiennent pas d'omissions, de valeurs déformées, etc. Le terme « qualité des données d'entrée » et l'expression bien connue « Garbage in - garbage out » doivent être mentionnés. ici.

Quelle que soit la qualité d’un modèle utilisé, il produira de mauvais résultats sur des données de mauvaise qualité. En pratique, de nombreuses ressources du projet sont consacrées à la création d'un ensemble de données de haute qualité.

Formation et validation du modèle ML

Après l'étape précédente, il est logique de prendre en compte les métriques du modèle formé lors de la réalisation d'expériences. Dans le cadre du bloc considéré, l'expérimentation consiste à lier apprentissage et validation du modèle ML.

L'expérience consiste en le schéma classique de formation de la version souhaitée du modèle avec l'ensemble d'hyperparamètres sélectionné sur l'ensemble de données préparé. À cette fin, l'ensemble de données lui-même est divisé en échantillons de formation, de test et de validation :

• Les deux premiers sont utilisés pour sélectionner l'ensemble optimal d'hyperparamètres
• Le troisième est la vérification finale et la confirmation que le modèle formé sur l'ensemble d'hyperparamètres sélectionné se comporte correctement sur des données inconnues qui n'ont pas participé au processus de sélection et de formation des hyperparamètres.

Vous pouvez en savoir plus sur les échantillons de validation dans Cet article .

Sauvegarde du code et des hyperparamètres dans un référentiel

Si les métriques d'apprentissage du modèle sont bonnes, le code du modèle et les paramètres sélectionnés sont stockés dans un référentiel d'entreprise.

L'objectif fondamental du processus d'expérimentation est l'ingénierie des modèles, ce qui implique la sélection du meilleur algorithme et la sélection du meilleur réglage des hyperparamètres.

La difficulté de mener des expériences est que le développeur doit vérifier de nombreuses combinaisons de paramètres de fonctionnement du modèle ML. Et nous ne parlons pas de différentes variantes de l’appareil mathématique utilisé.

En général, cela demande du travail. Et que faire si les métriques souhaitées ne sont pas atteintes dans le cadre de combinaisons de paramètres de modèle ?

Ingénierie des fonctionnalités

Si les métriques souhaitées du fonctionnement du modèle ML ne peuvent pas être obtenues, vous pouvez essayer d'étendre la description des fonctionnalités des objets de l'ensemble de données avec de nouvelles fonctionnalités. Grâce à eux, le contexte du modèle s'élargira et, par conséquent, les mesures souhaitées pourront s'améliorer.

Les nouvelles fonctionnalités peuvent inclure :

• Pour les données tabulaires : transformations arbitraires d'attributs d'objet déjà existants - par exemple, X^2, SQRT(X), Log(x), X1*X2, etc.
• En fonction du domaine : indice de masse corporelle, nombre de remboursements de prêts en souffrance sur un an, etc.

Examinons la partie du diagramme qui concerne l'ingénierie des fonctionnalités.

Le bloc B1 vise à former un ensemble d'exigences pour transformer les données sources disponibles et en obtenir des fonctionnalités. Le calcul des composants lui-même est effectué à partir de ces données très prétraitées et nettoyées selon les « formules » saisies par le développeur ML.

Il est essentiel de dire que travailler avec des fonctionnalités est itératif. En appliquant un ensemble de fonctionnalités, une nouvelle idée peut venir à l’esprit, réalisée dans un autre ensemble de fonctionnalités, et ainsi de suite, à l’infini. Ceci est explicitement montré dans le diagramme sous forme de boucle de rétroaction.

Le bloc B2 décrit le processus immédiat d'ajout de nouvelles fonctionnalités aux données.

La connexion et la récupération des sources de données sont des opérations techniques qui peuvent s'avérer assez compliquées. Pour simplifier l'explication, je supposerai qu'il existe plusieurs sources auxquelles l'équipe a accès et des outils pour décharger les données de ces sources (au moins des scripts Python).

Nettoyage et transformation des données. Cette étape correspond presque à l'étape similaire du bloc d'expériences (C) - préparation des données. Dès le début des premières expériences, on comprend quelles données et dans quel format sont nécessaires pour entraîner les modèles ML. Il ne reste plus qu'à générer et tester correctement les nouvelles fonctionnalités, mais le processus de préparation des données à cet effet doit être automatisé autant que possible.

Calcul de nouvelles fonctionnalités. Comme indiqué ci-dessus, ces actions peuvent consister simplement à transformer quelques éléments d'un tuple de données. Une autre option consiste à exécuter un grand pipeline de traitement distinct pour ajouter une seule fonctionnalité au même tuple de données. Quoi qu’il en soit, il existe un ensemble d’actions exécutées séquentiellement.

Ajout du résultat. Le résultat des actions précédentes est ajouté à l'ensemble de données. Le plus souvent, les fonctionnalités sont ajoutées à l’ensemble de données par lots pour réduire la charge de la base de données. Mais il est parfois nécessaire de le faire à la volée (streaming) pour accélérer l’exécution des tâches métiers.

Il est essentiel d'utiliser les fonctionnalités obtenues le plus efficacement possible : sauvegardez-les et réutilisez-les dans les tâches d'autres développeurs ML de l'entreprise. Le programme dispose d'un magasin de fonctionnalités à cet effet. Il doit être disponible au sein de l'entreprise, administré séparément et versionné pour toutes les fonctionnalités qui y sont intégrées. Le magasin de fonctionnalités comprend 2 parties : en ligne (pour les scripts de streaming) et hors ligne (pour les scripts par lots).

Flux de travail de ML automatisé

Au début de l'article, j'ai indiqué que par système ML, j'entends un système d'information dont un ou plusieurs composants contiennent un modèle entraîné qui exécute une partie de la logique métier globale. Plus le modèle ML obtenu grâce au développement est bon, plus l'effet de son fonctionnement est important. Un modèle entraîné traite le flux de demandes entrant et fournit des prédictions en réponse, automatisant ainsi certaines parties du processus d'analyse ou de prise de décision.

Le processus d'utilisation d'un modèle pour générer des prédictions est appelé inférence, et la formation d'un modèle est appelée formation. Une explication claire de la différence entre les 2 peut être empruntée à Gartner. Ici, je vais m'entraîner sur des chats.

Pour le fonctionnement efficace d’un système ML de production, il est essentiel de garder un œil sur les métriques d’inférence du modèle. Dès qu'ils commencent à tomber, le modèle doit être recyclé ou remplacé par un nouveau. Le plus souvent, cela se produit en raison de modifications des données d’entrée (dérive des données). Par exemple, il existe un problème commercial dans lequel le modèle peut reconnaître des cupcakes sur des photos, et cela lui est fourni en entrée. Les chiens Chihuahua de l'exemple sont pour l'équilibre :

Le modèle de l'ensemble de données d'origine ne sait rien des chiens Chihuahua, il fait donc des prédictions incorrectes. Il est donc nécessaire de modifier l’ensemble de données et de mener de nouvelles expériences. Le nouveau modèle devrait être en production dès que possible. Personne n'interdit aux utilisateurs de télécharger des images de chiens Chihuahua, mais ils obtiendront de mauvais résultats.

Passons maintenant à des exemples plus concrets. Considérons le développement d'un système de recommandation pour une place de marché.

Sur la base de l'historique des achats de l'utilisateur, des achats d'utilisateurs similaires et d'autres paramètres, un modèle ou un ensemble de modèles génère un bloc avec des recommandations. Il contient des produits dont les revenus d'achat sont régulièrement comptabilisés et suivis.

Quelque chose se produit et les besoins des clients changent. Leurs recommandations ne sont donc plus pertinentes. La demande pour les produits recommandés diminue. Tout cela entraîne une diminution des revenus.

Les dirigeants suivants hurlent et exigent que tout soit restauré d'ici demain, ce qui ne mène à rien. Pourquoi? Les données sur les nouvelles préférences des clients sont insuffisantes, vous ne pouvez donc même pas créer un nouveau modèle. Vous pouvez utiliser certains algorithmes de base de génération de recommandations (filtrage collaboratif basé sur les éléments) et les ajouter à la production. De cette façon, les recommandations fonctionneront d’une manière ou d’une autre, mais il ne s’agit que d’une solution temporaire.

Idéalement, le processus devrait être mis en place de telle manière que le processus de recyclage ou d’expérimentation de différents modèles démarre sur la base de mesures sans que les managers ne leur disent de le faire. Et le meilleur finirait par remplacer celui actuellement en production. Dans le diagramme, il s'agit du pipeline de flux de travail automatisé ML (bloc D), qui est démarré par des déclencheurs dans un outil d'orchestration.

Il s’agit de la section la plus chargée du schéma. Plusieurs composants tiers clés interviennent dans le fonctionnement du bloc D :

• Le composant Orchestrator de workflow, responsable du lancement du pipeline selon une planification ou un événement spécifié.
• Feature Store, à partir duquel les données sur les fonctionnalités nécessaires au modèle sont extraites
• Registre des modèles et magasin de métadonnées ML, où sont placés les modèles et leurs métriques, obtenus après le travail du Pipeline lancé.

La structure du bloc lui-même combine les étapes des blocs d’expérimentation et de développement de fonctionnalités (B2). Ce n’est pas surprenant, étant donné que ce sont ces processus qui doivent être automatisés. Les principales différences se situent dans les 2 dernières étapes :

• Modèle d'exportation
• Transférer vers le registre des modèles

Les étapes restantes sont identiques à celles décrites ci-dessus.

Séparément, je souhaite mentionner les artefacts de service requis par l'orchestrateur pour exécuter les pipelines de recyclage de modèles. Il s'agit du code stocké dans le référentiel et exécuté sur les serveurs sélectionnés. Il est versionné et mis à niveau selon toutes les règles du développement logiciel. Ce code implémente les pipelines de recyclage du modèle et le résultat dépend de son exactitude.

Le plus souvent, divers outils de ML sont exécutés dans le code, au sein desquels s'effectue l'exécution des étapes des pipelines, par exemple :

• L'orchestrateur de flux d'air exécute le code pour exécuter les étapes des pipelines
• Feast décharge les données sur les fonctionnalités de l'ensemble de données sur commande
• ClearML crée ensuite un nouvel ensemble de données et exécute une expérience avec l'ensemble nécessaire de mesures de performances du modèle, qu'il extrait de son propre référentiel.
• Une fois l'enquête terminée, ClearML enregistre le modèle et ses mesures de performances sur le stockage.

Il convient de noter ici qu’il est généralement impossible d’automatiser les expériences. Il est bien entendu possible d’ajouter le concept AutoML au processus. Cependant, il n’existe actuellement aucune solution reconnue pouvant être utilisée avec les mêmes résultats pour n’importe quel sujet de l’expérience.

Dans le cas général, AutoML fonctionne comme ceci :

1. Génère d'une manière ou d'une autre un ensemble de nombreuses combinaisons de paramètres de fonctionnement du modèle
2. Exécute une expérience pour chaque combinaison résultante. Corrige les métriques pour chaque expérience sur la base desquelles le meilleur modèle est sélectionné
3. AutoML effectue toutes les manipulations qu'un Data Scientist Junior/Middle ferait dans un cercle de tâches plus ou moins standards

L'automatisation a été un peu abordée. Ensuite, nous devons organiser la livraison d'une nouvelle version du modèle en production.

Modèles de service et de surveillance

Un modèle ML est requis pour générer des prédictions. Mais le modèle ML lui-même est un fichier qui ne peut pas être créé pour les générer aussi rapidement. Vous pouvez souvent trouver une telle solution sur Internet : une équipe prend FastAPI et écrit un wrapper Python autour du modèle afin que vous puissiez « suivre les prédicats ».

À partir du moment où le fichier de modèle ML est reçu, les choses peuvent se dérouler de plusieurs manières. L'équipe peut partir :

• Écrivez tout le code pour créer un service RESTfull
• Mettre en œuvre tout l'emballage qui l'entoure
• Intégrez le tout dans une image Docker
• Et puis quelque part à partir de cette image, vous allez créer un conteneur
• Mettez-le à l'échelle d'une manière ou d'une autre
• Organiser la collecte des métriques
• Configurer les alertes
• Mettre en place des règles de déploiement des nouvelles versions du modèle
• Beaucoup d'autres choses

Faire cela pour tous les modèles et maintenir l'intégralité de la base de code à l'avenir représente une tâche fastidieuse. Pour faciliter les choses, des outils de service spéciaux sont apparus, qui ont introduit 3 nouvelles entités :

• Instance/service d'inférence
• Serveur d'inférence
• Moteur de service

Une instance d'inférence, ou service d'inférence , est un modèle de ML spécifique préparé pour recevoir des requêtes et générer des prédictions de réponse. Une telle entité peut représenter un sous dans un cluster Kubernetes avec un conteneur avec le modèle ML nécessaire et les outils techniques pour l'exécuter.

Le serveur d'inférence est le créateur des instances/services d'inférence. Il existe de nombreuses implémentations d'Inference Server. Chacun peut fonctionner avec des frameworks ML spécifiques, convertissant les modèles formés en modèles prêts à l'emploi pour traiter les requêtes d'entrée et générer des prédictions.

Le moteur de serveur exécute les principales fonctions de gestion. Il détermine quel serveur d'inférence sera utilisé, combien de copies de l'instance d'inférence résultante doivent être démarrées et comment les mettre à l'échelle.

Dans le schéma considéré, il n'existe pas de tels détails sur les composants servant de modèle, mais des aspects similaires sont soulignés :

• Composant CI/CD, qui déploie des modèles prêts à fonctionner en production (il peut être considéré comme l'une des versions de Serving Engine)
• Model Serving, au sein de l'infrastructure dont il dispose, organise le schéma de génération de prédictions pour les modèles ML, à la fois pour les scénarios de streaming et par lots (il peut être considéré comme l'une des versions d'Inference Server)

Pour un exemple de stack complète pour Serving, on peut se référer à la stack de Seldon :

• Seldon Core est le moteur de service
• Seldon ML Server est le serveur d'inférence, qui prépare l'accès au modèle via REST ou gRPC
• Seldon MLServer Custom Runtime est l'instance d'inférence, une instance de shell pour tout modèle ML dont l'exemple doit être exécuté pour générer des prédictions.

Il existe même un protocole standardisé pour la mise en œuvre de Serving, dont la prise en charge est de facto obligatoire dans tous ces outils. Il s'appelle V2 Inference Protocol et a été développé par plusieurs acteurs importants du marché : KServe, Seldon et Nvidia Triton.

Servir ou déployer

Dans divers articles, vous pouvez trouver des références aux outils de service et de déploiement en tant qu'entité unique. Cependant, il est essentiel de comprendre la différence entre les objectifs des deux. C’est une question discutable, mais cet article le présentera ainsi :

• Servir - la création d'un modèle API et la possibilité d'en obtenir des prédictions. En fin de compte, vous obtenez une seule instance de service avec un modèle à l’intérieur.
• Déployer - distribuer l'instance de service dans la quantité nécessaire pour traiter les demandes entrantes (peut être représenté comme un jeu de réplicas dans le déploiement Kubernetes).

De nombreuses stratégies peuvent être utilisées pour déployer des modèles , mais celles-ci ne sont pas spécifiques au ML. À propos, la version payante de Seldon prend en charge plusieurs stratégies, vous pouvez donc simplement sélectionner cette pile et profiter de la façon dont tout fonctionne.

N'oubliez pas que les mesures de performances du modèle doivent être suivies. Sinon, vous ne pourrez pas résoudre les problèmes à temps. La grande question est de savoir comment suivre exactement les métriques. Arize AI a construit toute une entreprise là-dessus, mais personne n'a annulé Grafana et VictoriaMetrics.

Lancement du projet

Compte tenu de tout ce qui est écrit ci-dessus, il s'avère que la commande ML :

• Génère des ensembles de données
• Effectue des expériences sur eux sur des modèles ML
• Développe de nouvelles fonctionnalités pour étendre les ensembles de données et améliorer la qualité des modèles
• Enregistre les meilleurs modèles dans le registre des modèles pour une réutilisation future
• Personnalise le service et le déploiement des modèles
• Personnalise le suivi des modèles en production et le recyclage automatique des modèles actuels ou la création de nouveaux modèles

Cela semble coûteux et parfois justifié. Par conséquent, il existe un bloc distinct d’initiation du projet MLOps (A) dans le diagramme responsable de la définition d’objectifs rationnels.

Un exemple du raisonnement du directeur informatique peut illustrer la façon de penser ici. Un chef de projet inspiré vient vers lui et lui demande une nouvelle installation de plateforme pour construire un système ML. Si tous deux agissent dans le meilleur intérêt de l’entreprise, des questions de clarification suivront de la part du directeur informatique :

• Quel problème commercial allez-vous résoudre avec le nouveau système ML ?
• Pourquoi avez-vous décidé que le nouveau système ML devrait résoudre ce problème ?
• Serait-il plus facile et moins coûteux de modifier les processus ou d’embaucher davantage de personnes pour le support technique ?
• Où pouvez-vous voir une analyse comparative des composants du système ML qui ont constitué la base de votre sélection actuelle ?
• Comment l’architecture du système ML choisie aidera-t-elle à résoudre un problème commercial ?
• Êtes-vous sûr que ML dispose de l’appareil mathématique nécessaire pour résoudre le problème identifié ?
• Quel est l'énoncé du problème pour la solution ?
• Où obtiendrez-vous les données pour entraîner les modèles ? Savez-vous de quelles données vous avez besoin pour préparer les modèles ?
• Avez-vous déjà examiné les données disponibles ?
• La qualité des données est-elle suffisante pour résoudre le modèle ?

Le directeur informatique sera déclassé en tant qu'enseignant dans une université mais permettra d'économiser l'argent de l'entreprise. Si toutes les questions ont trouvé réponse, il existe un réel besoin d’un système ML.

Question suivante : dois-je y faire du MLOps ?

Cela dépend du problème. Si vous avez besoin de trouver une solution ponctuelle, par exemple PoC (Proof of Concept), vous n'avez pas besoin de MLOps. S’il est indispensable de traiter de nombreuses requêtes entrantes, alors MLOps est requis. Essentiellement, l’approche est similaire à l’optimisation de n’importe quel processus d’entreprise.

Pour justifier le besoin de MLOps auprès de la direction, vous devez préparer des réponses aux questions :

• Qu’est-ce qui va s’améliorer ?
• Combien d’argent allons-nous économiser ?
• Devons-nous augmenter nos effectifs ?
• Que devons-nous acheter ?
• Où acquérir une expertise ?

La prochaine chose à faire est de repasser l'examen de directeur informatique.

Les défis persistent car l'équipe doit également être convaincue de la nécessité de modifier ses processus de travail et sa pile technologique. Parfois, c’est plus difficile que de demander un budget à la direction.

Pour convaincre l'équipe, il convient de préparer des réponses aux questions :

• Pourquoi l’ancienne façon de travailler n’est plus possible ?
• Quel est le but du changement ?
• Quelle sera la pile technologique ?
• Quoi et de qui apprendre ?
• Comment l’entreprise va-t-elle aider à mettre en œuvre les changements ?
• Combien de temps faut-il pour effectuer le changement ?
• Qu’arrive-t-il à ceux qui n’y parviennent pas ?

Comme vous pouvez le constater, ce processus n'est pas simple.

Petite conclusion

J'en ai terminé ici avec une étude détaillée du schéma MLOps. Il ne s’agit cependant que d’aspects théoriques. La mise en œuvre pratique révèle toujours des détails supplémentaires qui peuvent changer beaucoup de choses.

Dans le prochain article, je discuterai de :

• Artefacts MLOps
• MLOps comme système d'information
• Open Source pour MLOps : Kubeflow contre MLflow contre Pachyderm

Merci pour votre attention!