Introduction
Jadis, dans des temps très reculés d’un point de vue technologique — en d’autres termes moins de 20 ans en arrière — avoir un smartphone était aussi rare qu’une défaite de Teddy Riner en compétition internationale. De même, il n’y a pas si longtemps, nous percevions l’intelligence artificielle plus comme un sujet de recherche ou de fiction. La seule façon de réellement en voir était donc dans un roman, un bon comics ou devant la télé chez tatie Marguerite le dimanche après-midi. Mais ça c’était avant le gain de popularité (et de faisabilité) du machine learning.
Cela dit, au fil de la popularisation du machine learning, et donc de son implémentation dans des solutions logicielles, il a été confronté à la réalité du parfois rustre et impétueux environnement de production. En effet, l'univers machine learning a certaines particularités. Ainsi, de bonnes pratiques ont fini par émerger. Ces bonnes pratiques sont pensées pour que l'intégration du machine learning dans les applications soit robuste, maintenable et adaptée pour cette bonne vielle et sacrée prod. En effet, les développeurs machine learning se responsabilisent de plus en plus et veulent produire des logiciels de qualité, tout en tenant compte du contexte particulier de cette discipline. Ça ne vous rappelle rien ?
Et oui, c'est bien l'esprit Crafsmanship. Omniprésent le bougre !
Dans cet article, nous allons faire une douce introduction de bonnes pratiques et outils permettant de créer des solutions logicielles basées sur le machine learning de façon robuste et maintenable. Nous allons aborder la route qui mène à la compréhension de ce sujet en montant progressivement les vitesses.
Mais avant toute chose, commençons par les fondamentaux.
Qu'est-ce que le machine learning ? Qui s'en sert ?
➲ Définition
Pour commencer, abordons les fondamentaux en douceur.
Le machine learning (ML pour les intimes) est une sous-discipline de l'intelligence artificielle dans laquelle on construit des programmes qui apprennent à réaliser une tâche à partir d'exemples contenus dans un jeu de données (données d'entraînement). L'algorithme de recommandation de Youtube par exemple est un cas de machine learning. Au fur et à mesure qu'on regarde des vidéos, le programme "apprend" quels types de vidéos nous aimons pour nous recommander du contenu pertinent pour nous.
Pour une tâche donnée, il y a donc naturellement une phase d'apprentissage dans le cycle de vie de machine learning. Sur le principe, c'est un procédé similaire à la manière dont les humains (voire les animaux) apprennent à réaliser une tâche : on comprend de mieux en mieux le sujet au fil des exemples.
Toutefois, la qualité de l'apprentissage dépend des exemples reçus (données d'entraînement) et de la méthode d'apprentissage employée (l'algorithme de machine learning). Cela dit, qu'obtient-on concrètement à l'issue de cette fameuse phase d'apprentissage ?
➲ Modèle de machine learning
Lorsqu'on apprend un sujet, on s'en fait une représentation dans notre cerveau. Et cette représentation dépend de la manière dont on a appris.
Pour un algorithme de machine learning, c'est pareil. A l'issue de la phase d'apprentissage, il se fait une représentation de ce qu'il appris. On appelle cette représentation un modèle de machine learning.
Concrètement, un modèle de machine learning est le résultat de l'application d'un algorithme de machine learning (Régression logistique, SVM, réseaux de neurones artificiels, etc.) sur des données d’entraînement. Il permet notamment de faire des prédictions, d’aider à la prise de décisions ou même de trouver des tendances dans les données.
En pratique, un modèle peut prendre plusieurs formes, du simple objet dans le code au fichier binaire (pickle, PMML, etc.). Généralement, une fois l'entraînement terminé, on sérialise les modèles afin qu'on puisse les réutiliser sans besoin de ré-entraînement. D'ailleurs, vu qu'on fait souvent du ML en Python, sérialiser des modèles sous forme de pickle est une pratique assez répandue. Dans ces cas-là, on effectue généralement la sérialisation soit avec la librairie standard pickle, soit avec la bibliothèque Python joblib.
| Remarque |
|---|
| joblib est plus rapide que la librairie standard pickle pour sauvegarder/restaurer des arrays Numpy volumineux. Par conséquent, lorsqu’un modèle contient des arrays NumPy volumineux (comme la majorité des modèles), joblib est généralement recommandé pour des raisons de performance. |
➲ Cas d'usage du machine learning
On retrouve l'usage du machine learning dans des domaines variés. On pourrait notamment citer la médecine (ex. détection de tumeur), la biologie (analyse d’interaction des molécules, prédiction d’activité d’enzymes, etc.), les banques et finances (détection de fraude, analyse de marché) ou encore le divertissement (coucou Netflix) pour ne citer que ceux-là.
Il y a aussi beaucoup de cas d'usage quotidiens :
- Reconnaissance faciale sur smartphone
- Estimation de temps d'arrivée sur les applications de navigation
- Recommandation de vidéos sur Youtube
- Recherche par image sur les moteurs de recherche
- Assistant vocal (salut Siri, tu vas bien ?)
Il y a même un petit truc qui s’appelle ChatGPT dont vous avez "peut-être" entendu parler. Et pour les plus curieux d'entre vous, j'ai même une liste plus large de cas d'usage du ML.
Les possibilités d'utilisation du ML sont nombreuses. Par contre, comme pour tout domaine qui suscite de l’intérêt, il faut faire très attention à sa pertinence et sa valeur ajoutée dans une situation donnée. Il y a en effet beaucoup de situations où le machine learning est une mauvaise idée.
D’ailleurs, puisqu’on parle de choses auxquelles il faut faire attention, il y a 3 éléments qu’il est important de distinguer pour bien organiser le développement d’une solution de machine learning. Parlons-en 🙂
Il est temps d'enclencher les vitesses !
Vitesse I : Projet, application et modèle
➲ Terminologie
Lorsqu'on fait du développement impliquant du machine learning, il y a généralement trois éléments qui coexistent et qu'il est essentiel de séparer mentalement et logiquement :
-
Le projet de machine learning, qui en somme représente l'effort global pour répondre à un besoin donné à l'aide du machine learning.
ATTENTION !!! Il est fortement recommandé de s'assurer de la valeur ajouté du projet de ML avant de s'engager. Il est possible qu'il soit redondant par rapport à un processus existant plus adapté.
-
Le modèle de machine learning, qui comme mentionné précédemment, représente ce qu'un algorithme de ML a appris sur un sujet donné. En fait, c'est purement un estimateur statistique. Par conséquent, il n'a pas systématiquement raison. D'ailleurs, les exigences par rapport à la "précision" du résultat dépendent du domaine. On attendra par exemple une grande précision d'un modèle de détection de tumeur alors qu'on sera plus tolérant si Netflix ne nous recommande pas la série parfaite 5 fois sur 10.
-
L'application de machine learning, qui sert de point de communication avec le modèle. Dans l'idée, c'est une application au sens traditionnel du terme. Cependant, sa spécificité c'est qu'elle représente l'interface entre le modèle et le monde extérieur. Naturellement, elle intégrera des éléments logiques typiques d'une application, notamment des règles métier, une base de données voire même une interface graphique si nécessaire. Afin de faire profiter de ses prédictions à d'autres applications, elle peut aussi comporter une API. L'image suivante montre un exemple d'architecture d'application de machine learning.
➲ Modèle et application : chacun sa vie
Une architecture micro-service
Très souvent, même quand on fait la distinction mentalement, il arrive que l'application de ML et le modèle soient développés comme un seul bloc. Toutefois, la pratique recommandée est de séparer leurs logiques afin que chacun d'entre eux puisse suivre sa propre évolution. Dit autrement, on recommande de développer l'ensemble modèle/application en suivant une architecture micro-service.
Remarque
Il n'est pas rare que pour une application donnée, on utilise un modèle public réalisé par une autre entité. C'est un peu comme développer avec une librairie tierce. Toutefois, il arrive souvent que ce modèle ait besoin d'être ajusté à nos données. Il faut donc rester vigilants et bien tester ses performances sur notre cas d'usage.
En pratique, si on se réfère rigoureusement au principe I de 12-factor, développer le modèle et l'application avec une architecture micro-service revient implicitement à les développer dans des bases de code (repos) différentes. Procéder ainsi permet de les découpler au maximum et d’éviter qu’ils aient plus d’influence que nécessaire l’un sur l’autre (par exemple dans la gestion des dépendances). Cela dit, ce n’est pas nécessairement une mauvaise chose de les développer dans le même repo. Toutefois, pour maintenir leur indépendance, veiller à ce que le code qui concerne le modèle et le code qui concerne l’application soient dans des répertoires différents, sans dépendances l’un avec l’autre.
| "12-factor" qui maintenant ? |
|---|
| Le Twelve Factor app (12-factor) est un manifeste proposant 12 bonnes pratiques pour le développement d'applications web maintenables, portables, scalables et modernes. Si vous souhaitez en savoir plus sur le sujet, je vous recommande vivement la page du manifeste ainsi que cette excellente vidéo. |
Et si mon modèle et mon appli ne parlent pas la même langue ?
Réponse courte : Il y a toujours moyen de se comprendre 😉
Lorsqu'on développe l'application de ML, on utilise généralement le même langage que le modèle. En pratique, ce sera souvent par exemple Python pour le modèle et un framework Python comme Flask pour l'application de ML qui servira le modèle.
Cependant, on peut rajouter du piment et décider de faire l'application dans un langage différent de celui qu'on a utilisé pour le modèle (si c'est pertinent). Par contre, c'est à condition que le modèle soit sérialisé dans un format plus universel que du pickle. En effet, bien que le pickle soit très pratique pour les développeurs Python (Pythonistas pour les intimes) et très flexible, il n'est pas cross-plateforme. Il ne fonctionne donc qu'avec Python. Pour cette raison, le format de sérialisation PMML (Predictive Model Markup Language) est une alternative très répandue dans ces situations.
Dans tous les cas, lors de la sérialisation du modèle, gardez à l'esprit qu'il s'agit de le mettre sous une forme exploitable par l'application de ML en production mais pouvant être générée par l'environnement qui construit le modèle.
En somme, il est recommandé que l'application de ML et le modèle aient deux cycles de vie distincts. Cela dit, cela n'empêche pas qu'ils fonctionnent bien ensemble. C'est comme une voiture et ses roues, ou comme une salade et de la sauce vinaigrette.
➲ Exemple : Analyse de panier
La théorie, c'est bien. Mais comme dirait tatie Marguerite : "Avec des exemples c'est encore mieux !".
Prenons donc un exemple pour illustrer toutes ces explications. Supposons que nous détenons un commerce de produits alimentaires. Notre commerce grandit et nous avons de plus en plus de produits. Cependant, la quantité et la variété des produits peuvent faire que notre magasin devienne un labyrinthe et donc perdre du temps à nos clients. Ainsi, nous aimerions organiser nos rayons tel que les produits probables d'être achetés ensemble soient proches les uns des autres. De même, nous aimerions que notre plateforme de vente en ligne recommande aux clients les produits qu'ils pourraient vouloir acheter ensemble. Le problème est posé.
Du problème au projet de machine learning
Pour accomplir notre quête, nous disposons de l'historique des ventes de produits réalisées par le magasin et des paniers associés au cours des 6 derniers mois. Nous pourrions ainsi l'analyser pour déterminer comment organiser nos rayons. Par contre, petit hic : il y a vraiment BEAUCOUP de transactions à analyser. En effet, ces 6 derniers mois, le magasin a prospéré et donc il y a une quantité colossale de transactions à analyser. Qui plus est, les produits semblent très variés. On réalise alors qu'analyser tout ça "à la main" sera fastidieux et difficile à maintenir sur la durée. Comme disait Mark Twain : "On n'a pas le temps, si brève est la vie [...]".
Et c'est là que soudain, dans l'obscurité de la nuit, une lueur d'espoir apparaît. Après un travail d'investigation, nous découvrons qu'il est possible d'automatiser cette tâche grâce au machine learning, par exemple l'algorithme A priori. Nous décidons donc de suivre cette piste pour résoudre notre problème : le projet de machine learning est né.
Du projet naissent …
Après plusieurs cycles d'expérimentations et de développement, l'algorithme de ML que nous avons sélectionné génère des règles d'association entre nos produits. Ces règles d'association sont chacune accompagnées de probabilités. Par exemple, nous découvrons que quand un client nous achète du lait, il y a 80% de chance qu'il nous achète du sucre. Ces règles d'association représentent ce que notre algorithme a appris. En d'autres termes, ces règles sont notre modèle de machine learning.
Enfin, de ces règles d'association nous faisons deux choses. En premier lieu, après les avoir analysé et interprété, nous organisons nos rayons de façon intuitive. Ce sont les clients du magasin qui vont être contents !
Deuxième chose, nous faisons profiter notre plateforme de e-commerce de ces règles d'association. Pour ce faire, nous créons un service de prédiction qui expose notre modèle via une API. Notre plateforme de e-commerce envoie alors des requêtes à ce service pour déterminer quel produit recommander à un utilisateur avant et/ou après un achat donné. Le service de prédiction est dans ce cas notre application de machine learning.
En somme, tout commence par un besoin précis. Puis, après mûre réflexion, on décide de se servir du ML pour y répondre. Suite à un travail d'expérimentation et d'évaluation, on sélectionne un algorithme de ML grâce auquel on entraîne un modèle de ML. Enfin, ce modèle est déployé et mis à disposition à travers une application de ML pour répondre au besoin initial.
Et voilà ! Nous venons de poser le décor. Nous venons d'aborder beaucoup de termes et de nuances importantes à prendre en compte pour faire du ML pour la production.
Première étape, validée ✅️
Maintenant nous sommes prêts à passer les vitesses un cran au-dessus. Il est temps de parler ... de MLOps.
Vitesse II : MLOps
➲ ML quoi ?
Étant donné que le développement et le déploiement machine learning constituent un processus complexe, des pratiques sont nées pour l'organiser.
Le MLOps est un ensemble de principes, de pratiques et d'outils qui ont pour but de rendre les tâches et les services de machine learning automatisés, reproductibles et bien intégrés les uns avec les autres.
Fondamentalement, le MLOps est une extension de la philosophie DevOps pour inclure le workflow de machine learning dans le processus. Cela signifie aussi que le MLOps possède essentiellement les mêmes avantages que le DevOps sur un processus de développement impliquant du ML, entre autres :
- Destruction/réduction du mur de la confusion entre les développements (responsables du changement) et les opérations (garantes de la stabilité)
- Accélération des livraisons et des déploiements
- Gestion plus efficace des tâches non planifiées
- Réduction du time-to-market
Qui plus est, les pratiques MLOps prennent en considération deux subtilités spécifiques aux projets de ML : les données d'entraînement et le modèle de machine learning. Ce qui fait donc qu’elles s’intéressent à la fois au code, au modèle et aux données d’entraînement.
➲ Une extension de la philosophie DevOps
Workflow DevOps
Comme nous venons de le mentionner, le workflow de MLOps est une extension de la philosophie DevOps. Afin d'illustrer le rapprochement entre ces deux philosophies, commençons par représenter schématiquement un workflow de DevOps classique :
Petite précision de vocabulaire au passage.
Un workflow c'est toute séquence d'opérations partant d'un point de départ à un point d'arrivée. Il peut être réalisé manuellement ou de façon automatisée. Lorsqu'un workflow est automatisé, on peut alors l'appeler pipeline.
A partir du code, on construit (build) l'application pour ensuite la déployer dans son infrastructure de production. Ensuite, on veille au bon fonctionnement de la sainte et sacrée insfrastructure de production en la monitorant. Vous remarquerez ainsi que dans ce workflow représentant le processus de développement traditionnel, le centre d'intérêt principal est l'application.
Workflow MLOps
En ce qui concerne le workflow de MLOps, il part des mêmes fondations que le celui de DevOps. Cependant, il inclut aussi les données d'entraînement et le modèle. En l'occurrence, on peut schématiser le workflow de MLOps de la manière suivante :
En effet, ce workflow concerne à la fois l'application de ML, le modèle de ML et les données d'entraînement. Les principes DevOps restent valables pour la plupart dans le workflow de MLOps, notamment pour la construction de l’application de ML. En parallèle de la construction de l'application de ML, le modèle de ML est construit à l’aide du code source prévu à cet effet et des données d’entraînement.
Après évaluation et validation, le modèle est déployé dans l’infrastructure prévue pour le rendre exploitable. Le modèle pourrait être stocké et versionné par exemple dans un registre de modèle. De là, l'application de ML peut ensuite l'exploiter.
La phase de déploiement est le point de départ de la vie d'un modèle donné en production. Elle est cruciale pour que le modèle puisse apporter de la valeur aux utilisateurs.
Ne vous en faites pas, nous reviendrons sur les détails pratiques de tout ça assez vite 🙂. Pour l'instant, relaxez-vous et imprégnez-vous du principe. Absorbez-le
| Remarque |
|---|
| Le degré d’automatisation dans le workflow de MLOps est un bon indicateur de son niveau de maturité sur un projet donné. Pour ce faire, il y a plusieurs manières d’y parvenir dont les GitHub Actions, GitLab CI, Jenkins et bien d’autres. Nous reviendrons prochainement sur le sujet. |
➲ Le monitoring : nos yeux et nos oreilles en production
Gare au concept drift !
Une fois en production, c'est important que le modèle de machine learning soit monitoré. Le but est d'assurer qu'il continue d'apporter de la valeur aux utilisateurs au fil du temps.
Concrètement, en plus des indicateurs DevOps usuels (nombre de requêtes, état du CPU en production, etc.), on surveillera aussi des indicateurs spécifiques au ML. On s'intéressera notamment aux performances prédictives.
Le monitoring des performances prédictives est d’autant plus important car au fil de l’utilisation du modèle, il pourrait arriver que le concept sous-jacent qu’il a appris ne soit plus valide. C'est ce qu'on appelle un concept drift. Cela dit, déterminer les performances prédictives en production n’est pas toujours évident. Si vous souhaitez en savoir plus sur comment détecter un concept drift, je vous recommande cet article intéressant comme point de départ => https://deepchecks.com/how-to-detect-concept-drift-with-machine-learning-monitoring/
Pour illustrer tout ça, reprenons l’exemple d’analyse de panier mentionné plus haut. Il peut arriver que les habitudes des clients changent énormément au fil du temps. Conséquence : ce que le modèle a appris ne sera potentiellement plus d’actualité. Dans ce cas, les recommandations d’articles faites par le modèle ne seront plus pertinentes. Monitorer le concept drift permet donc d’être averti relativement tôt du manque de pertinence du modèle.
Monitoring des données et data drift
Le monde extérieur évolue en permanence. Les utilisateurs eux-mêmes évoluent en permanence. De ce fait, il est possible que la distribution des données reçues en entrée de l'application de ML se mette à diverger drastiquement des données d'entraînement.
Prenons le cas d'un projet ML de segmentation de clientèle. Certains attributs des clients évoluent avec le temps. Leurs âges par exemple. La raison, disons, pourrait être simplement que notre produit commence à toucher un public plus varié ou alors qu’on a une base de clients stable qui naturellement prend de l’âge. Il peut ainsi arriver que l'âge moyen de notre clientèle typique devient significativement différent. Et si l'âge était une variable essentielle dans les prédictions de notre modèle, il pourrait donc être induit en erreur parce qu'il a été entraîné sur des données avec une distribution où l'âge moyen était significativement différent.
On appelle cette divergence des données observées en production par rapport aux données d'entraînement un data drift (une dérive de données).
Le data drift est donc l’une des raisons majeures pour lesquelles il est important de monitorer les données. Un data drift peut d’ailleurs être le signe d’un concept drift, qui lui est généralement plus difficile à détecter.
Si vous aimeriez un exemple de mise en place d’un dashboard de data drift en Python, j’ai un lien très intéressant pour vous par ici.
Vitesse III : Quelques outils de MLOps
Tout ce que nous venons de voir nous a permis de poser les bases de l'approche d'un projet de machine learning pour la production.
Cela dit, par définition, le MLOps n'est pas qu'une question de principes et de pratiques. C'est aussi une question d'outils. Alors ici, nous allons parler de quelques outils très utiles sur un workflow de MLOps.
Ces outils interviennent à différents niveaux du cycle de vie de machine learning. Ainsi, il existe des outils pour :
- Le suivi d'expérimentations
- Stocker et versionner des modèles (model registry/registre de modèle)
- La gestion des métadonnées de modèle
- Orchestrer le processus d'apprentissage
- Versionner les données d'entraînement et des pipelines
- Déployer / monitorer des modèles
- etc.
D'ailleurs, parlons de quelques-uns d'entre eux 🙂
➲ MLFlow
MLFlow est un outil open source qui permet de gérer des composantes importantes du cycle de vie machine learning. Il est généralement utilisé pour le suivi d'expérimentations ML. Toutefois, on peut aussi s'appuyer sur lui pour la reproductibilité, le déploiement et même pour avoir un registre de modèle.
Supposons par exemple qu'on travaille sur un projet de ML pour aider les médecins à détecter un AVC sur une IRM. Pour cela, nous avons le choix entre plusieurs approches et algorithmes de ML. MLFlow permet de faire un suivi d'expérimentations pour déterminer la méthode la plus adaptée pour répondre au problème. On pourrait même s'en servir pour stocker et versionner le modèle obtenu dans un registre de modèle.
Une autre de ses forces est le choix varié des interfaces pour gérer les expérimentations et les métadonnées de modèle : CLI, R, Python, Java et même une API REST.
Pour débuter avec MLFlow et en apprendre un peu plus, je vous recommande le tutoriel officiel comme point de départ.
➲ Data Version Control (DVC)
Data Version Control (abrégé DVC) est un outil open source populaire de versioning de données. Il a l'avantage de bien s'intégrer à Git et donc de permettre de combiner versioning de code, données, modèle, métadonnées et pipeline.
DVC donne également le choix sur le lieu de stockage distant des données versionnées (DagsHub, Google Drive, S3, DVC eux-mêmes, votre ordinateur local, etc.).
C'est en réalité plus qu'un outil de suivi et de versioning de données. Il permet entre autres :
- Le suivi d'expérimentation (métriques de modèle, paramètres, versioning)
- De créer, visualiser et lancer des pipelines de machine learning
- De créer un workflow pour le déploiement et la collaboration
- La reproductibilité
- La CI/CD pour le machine learning à l'aide de CML
Pour débuter avec DVC et par la même occasion en savoir plus sur le versioning de données, je vous recommande le tutoriel officiel ainsi que ce tutoriel RealPython.
Et si vous êtes curieux de savoir quels autres outils existent pour versionner les données, je vous recommande cette liste établie par Neptune.ai.
➲ Weight & Biases
Weight & Biases est une plateforme de ML pour le suivi d'expérimentation, le versioning de données et de modèles, l'optimisation d'hyperparamètres et la gestion de modèle.
Qui plus est, on peut s'en servir pour faire des logs sur les artefacts de MLOps (datasets, modèles, dépendances, pipelines et résultats). On peut également y visualiser les datasets (audio, image, texte ou tabulaire).
Il est possible de l'intégrer avec des librairies de machine learning comme Fastai, Keras, PyTorch, Hugging Face, Yolo v5, SpaCy et beaucoup d'autres.
Pour en savoir plus sur l'utilisation de Weight & Biases, je vous recommande ... Bon vous savez ce que je vais dire 👀 => https://docs.wandb.ai/quickstart
➲ AWS SageMaker
AWS SageMaker est une plateforme de MLOps end-to-end conçue pour aider à automatiser et à normaliser les processus tout au long du cycle de vie de machine learning. Il permet d'entraîner, tester, déboguer, déployer et gérer les modèles ML à l'échelle. Il est tout aussi utile pour le suivi et le versioning d'expérimentations, cataloguer les artefacts ML ainsi qu'intégrer des pipelines ML de CI/CD. Pour ce qui est de la collaboration, il propose un environnement pour les équipes de data science. Ce n'est même pas le début de ce qu'il peut faire. C'est un outil très complet.
➲ C'est tout ?
Cette liste d'outils de MLOps est très loin d'être exhaustive. Je m'arrête uniquement pour des raisons de concision 🙂 . D'ailleurs, je vous incite à consulter la liste plus étendue de 17 outils de MLOps proposée par DataCamp. Si vous voulez approfondir le sujet, c'est un très bon point de départ ! Vous en trouverez probablement un qui correspond à un cas d'usage que vous avez rencontré.
Beaucoup de ces outils peuvent s'utiliser conjointement aux outils de DevOps existants. DVC par exemple s'intègre bien avec Git et par extension aux outils de CI/CD comme les GitHub Actions. Après tout, le MLOps est une extension du DevOps, gardons-le à l'esprit 😉 .
Remarque
Avant de décider d'utiliser un outil de MLOps, il est important de s'assurer de sa pertinence sur un cas d'usage donné. En effet, leur mise en place et leur intégration demandent parfois des efforts non négligeables selon les processus en place.
Take Away
Comment ça "take away" ? C'est déjà fini ???? Mais j'ai encore tellement de questions moi 😭
Mais nooooon, ce n'est que la fin de la première partie de ce tutoriel. Je vous l'ai dit, une vitesse à la fois les ami.e.s :). Pour l'instant, faisons un petit bilan de ce que nous avons appris.
En résumé, les projets de ML sont assez singuliers à industrialiser. Nous venons de voir qu'ils comportent des nuances dont il faut avoir conscience (application, modèle et données) ainsi que des pratiques bien à eux (MLOps) afin d'assurer leur qualité. Du Craft pour le ML quoi.
Ceci dit, la différence principale avec le développement conventionnel est surtout au niveau de l'infrastructure et de l'architecture. Pour ce qui est du code, il est toujours aussi important de veiller à sa qualité, de le versionner et même de le tester. En effet, beaucoup de bonnes pratiques de développement logiciel demeurent valides. Le code c'est le code.
Nous avons également parlé d'outils qui peuvent se montrer utiles dans un workflow MLOps. Nous aurons le temps d'y revenir dans d'autres articles ou tutoriels sur le blog d'Arolla. Je vous encourage toutefois à vous documenter convenablement sur ces outils et à tenir compte du contexte de votre projet avant d'en choisir un. L'(in)utilité d'un outil est une question de discernement et l'information est la clé du discernement.
Dans la deuxième partie de ce tutoriel, nous abordons les composantes du MLOps. Alors restez à l'écoute. Comme d'habitude je vous dis à bientôt 😉
Aller plus loin
- L'article sur le CRISP-ML de ml-ops.org
- Machine Learning Lifecycle Explained de DataCamp
- Cours MLOps Concepts et MLOps Deployment and Life Cycling sur DataCamp
