
**MLflow** est une plateforme open source qui permet de **gérer le cycle de vie des modèles de Machine Learning**. En particulier, grâce à MLflow, les modèles qui ont été entraînés à une date spécifique ainsi que les hyper-paramètres associés pourront être stockés, monitorés et réutilisés de manière efficace.

Un des principaux avantages est **l'intégration avec des frameworks** Python existants comme Scikit-Learn, XGBoost ou encore TensorFlow, rendant l'outil utilisable dans de nombreuses situations. De plus, son API Python est **simple à utiliser**, permettant de l'intégrer rapidement dans des projets existants.

## Concepts de MLflow

Rappelons tout d'abord le workflow en Data Science : la première étape de **collecte des données** et suivie d'une étape de **transformation des données**, puis de la **modélisation** pour maximiser une métrique de performance qui jugera de la qualité de l'algorithme employé.

Être productif en Data Science n'est pas de tout repos pour les raisons suivantes.

- **Il est difficile de garder une trace des précédentes expériences**. Une chose à laquelle beaucoup de Data Scientists font face, c'est de faire une série d'expérimentations en modifiant algorithmes et paramètres, ce qui peut s'avérer contre-productif si l'on ne dispose pas de l'historique des modèles et de leurs performances. En général, méthode qui consiste à modifier le nom de chaque Notebook peut s'avérer vite contraignante.
- **Il est difficile de reproduire le code**. Dans les projets Data Science, une multitude de fonctions permettent d'arriver à un résultat bien précis : le changement de quelques lignes de code peut grandement affecter le modèle et ses performances.
- **Il n'y a aucun standard sur le packaging et le déploiement de modèles**. Chaque équipe possède son approche pour déployer les modèles, et ce sont souvent les grandes équipes avec un passif dans les projets Machine Learning qui peuvent se le permettre.
- **Il n'y a aucun point central pour gérer les modèles**. En pratique, la solution naïve consiste à sauvegarder les paramètres dans des fichiers sur le même serveur hébergeant l'algorithme, en stockage local. Le problème, c'est que cette solution créé une forte dépendance avec le serveur qui entraîne le modèle, ce qui est contraire à l'approche MLOps.

---

**À lire aussi** : <a href="/formation/mlops">découvrez notre formation MLOps</a>

---

Beaucoup de pain points que MLflow va justement chercher à résoudre.

![La gestion de versions en Delivery de Machine Learning | OCTO Talks !](https://blog.octo.com/wp-content/uploads/2021/04/tracking-ui-vierge.png)

MLflow cherche à améliorer la productivité en offrant la possibilité de ré-entraîner, réutiliser et déployer des modèles en agissant sur un point central (plateforme MLflow) où tout l'historique du modèle sera conservé.

Tout d'abord, MLflow est _language-agnostic_, c'est-à-dire que les modèles peuvent être codés en Python, R, Java ou encore C++ et envoyés sur MLflow. Ensuite, il n'y a aucun pré-requis concernant la librairie de Machine Learning : que vous soyez adeptes de `scikit-learn` ou de `tensorflow`, tout sera compatible.

Quatre composants résident sous MLflow.

- **MLflow Tracking** est l'API et l'interface utilisateur pour logger les hyper-paramètres, le versioning de code et les _artifacts_ (configuration du modèle, fichier de poids, ...).
- **MLflow Projects** est un format standard pour package un code source et le réutiliser dans plusieurs projets.
- **MLflow Models** est un format de packaging pour les modèles de Machine Learning.
- **MLflow Registry** est le registre de modèle (comme un git de modèles) qui permet de s'assurer que les modèles respectent certaines contraintes.

## Prise en main de MLflow

Pour installer <a href="https://github.com/mlflow/mlflow" target="_blank">MLflow</a> en local, il suffit juste d'exécuter `pip install mlflow` .

Dans cet exemple Python, nous chargeons des fichiers CSV qui correspondent aux sous-ensembles d'entraînement et de test.

```
import os
import numpy as np
import pandas as pd

import mlflow
import mlflow.sklearn # Wrapper pour scikit-learn

from lightgbm.sklearn import LGBMClassifier
from sklearn.metrics import f1_score

X_train = pd.read_csv("~/data/X_train.csv")
X_test = pd.read_csv("~/data/X_test.csv")
y_train = pd.read_csv("~/data/y_train.csv").values.flatten()
y_test = pd.read_csv("~/data/y_test.csv").values.flatten()
```

Ensuite, nous pouvons définir l'URL de tracking MLflow avec `set_tracking_uri`, puis définir l'expérience avec `set_experiment`. Une expérience MLflow correspond à tous les modèles pour un même projet.

Ensuite, nous pouvons démarrer une exécution avec `start_run` : tout ce qui sera produit (configuration, métriques, modèle, etc) sera associé à cette exécution, améliorant grandement le tracking.

```
# Identification de l'interface MLflow
mlflow.set_tracking_uri("file://" + os.path.expanduser('~/mlruns'))
# Identification du nom du projet MLflow
mlflow.set_experiment("experiment_blent")

with mlflow.start_run() as run:
    model = LGBMClassifier(**hyp_params, objective="binary", verbose=-1)
    model.fit(X_train, y_train)

    # On calcule le score du modèle sur le test
    score = f1_score(y_test, model.predict(X_test))

    mlflow.log_params(hyp_params)
    mlflow.log_metric("f1", score)

    print(mlflow.get_artifact_uri())
    mlflow.sklearn.log_model(model, "model")
```

En exécutant ce code, nous avons déclenché un **run** avec `mlflow.start_run()`. L'intérêt d'utiliser `with` est qu'en sortant de l'indentation, le run MLflow sera automatiquement terminé. Nous allons envoyer plusieurs informations vers MLflow.

- Les hyper-paramètres du modèle avec `log_params`.
- La ou les métriques obtenues sur un échantillon avec `log_metric`.
- Le modèle au format de `scikit-learn` avec `log_model`.

En visualisant l'interface web MLflow, nous voyons le modèle apparaître avec les informations associées.

![](https://blent-learning-user-ressources.s3.eu-west-3.amazonaws.com/training/ml_engineer_facebook/img/mlflow1.png)

En cliquant sur la date d'exécution, nous avons accès à plus de détails ainsi qu'aux fichiers stockés (ici le modèle), que l'on appelle des **artifacts**.

![](https://blent-learning-user-ressources.s3.eu-west-3.amazonaws.com/training/ml_engineer_facebook/img/mlflow2.png)

MLflow peut également stocker des images, notamment des graphiques qui permettront de contrôler la qualité d'un modèle de Machine Learning.

![](https://blent-learning-user-ressources.s3.eu-west-3.amazonaws.com/training/ml_engineer_facebook/img/mlflow4.png)

## Registre de modèle

Le **Model Registry** (registre de modèles) est un composant de MLflow qui permet de gérer des versions de modèles de Machine Learning, en proposant également des **stages** (états).

- Le tag **staging** correspond à un modèle considéré comme pré-production.
- Le tag **production** correspond à un modèle qui serait en environnement de production.
- Le tag **archived** pour les anciens modèles archivés.

---

**À lire aussi** : <a href="/formation/mlops">découvrez notre formation MLOps</a>

---

C'est un composant particulièrement utile pour gérer le cycle de vie des modèles, car le cycle _staging_, _production_ et _archive_ est couramment appliqué lorsque des modèles sont mis à jour régulièrement. Sous MLflow, l'onglet Models permet d'afficher tous les modèles enregistrés.

![MLflow Model Registry — MLflow 1.22.0 documentation](https://www.mlflow.org/docs/latest/_images/oss_registry_3_overview.png)

Là-aussi, il est très facile d'interagir avec MLflow en Python.

```
# On envoie le modèle vers le registry
result = mlflow.register_model(
	"runs:/{}/artifacts/model".format(run.run_id), "model_blent"
)
print(result.version)

# On tag le modèle en verison staging
client = MlflowClient()
client.transition_model_version_stage(
	name="model_blent", version=int(version), stage="Staging"
)
```

## Quand utiliser MLflow ?

De manière générale, MLflow peut être utilisé aussi bien dans les environnements de production, qu'en développement local. En effet, nous avons vu qu'il est très facile d'installer MLflow en local, ce qui permet de l'utiliser dès la création d'un projet jusqu'à sa mise en production.

- En local, **lorsque l'on travaille seul sur un projet** et que l'on cherche à optimiser un modèle de Machine Learning. Cela permet d'utiliser le composant Tracking pour historiser toutes les expérimentations réalisées.
- Sur un **serveur partagé**, lorsque l'on travaille à plusieurs sur un projet. Dans cette situation, on évite d'envoyer les modèles et les paramètres entre les utilisateurs : on utilise directement MLflow à la place, qui va historiser au niveau du projet l'ensemble des expérimentations de chaque utilisateur.
- Sur un **serveur Cloud ou On-Premise**, dans les pipelines d'automatisation MLOps. Ce cas de figure permet d'utiliser MLflow pour héberger des modèles qui seraient produits via des pipelines d'automatisation : en séparant le pipeline qui entraîne le modèle de celui qui le déploie, on assure une bien meilleure livraison sur plusieurs aspects (maintenance, sécurité, fiabilité).

![](https://blent-learning-user-ressources.s3.eu-west-3.amazonaws.com/training/ml_engineer_facebook/img/pipeline_prod6.png)

## Se former sur MLflow

**De plus en plus de Data Scientists utilisent MLflow**, que ce soit pour historiser les itérations du cycle Machine Learning, ou pour utiliser le registre de modèles en environnement de production. Cet **outil devient indispensable** dans les entreprises qui souhaitent améliorer leur efficacité opérationnelle sur la gestion des projets ML.

La <a  href="https://blent.ai/formation/mlops">formation MLOps de Blent</a> utilise MLflow en tant que **plateforme de tracking et de registre de modèles** de Data Science. Elle est utilisée dans différents environnements, en pré-production et en production.

Cette formation couvre également de nombreux aspects de l'approche MLOps, comme la **création de projets code source** adaptés à la Data Science, **l'automatisation de pipelines de Machine Learning** ou **l'exposition de modèles** scalables sur Kubernetes.


MLflow est une plateforme open source qui permet de **gérer le cycle de vie des modèles de Machine Learning. En particulier, grâce à MLflow, les modèles qui ont été entraînés à une date spécifique ainsi que les hyper-paramètres associés pourront être stockés, monitorés et réutilisés de manière efficace.

MLflow est une plateforme open source qui permet de gérer le cycle de vie des modèles de Machine Learning. Temps de lecture 6 min.

MLflow : tout savoir sur l’outil indispensable du MLOps


Tu as probablement déjà entendu parler de **Kubernetes** : c'est un outil extrêmement populaire dans le Cloud et qui est devenu, en quelques années, la référence en terme de déploiement d'applications dans le Cloud. Mais pourquoi (et surtout comment) Kubernetes est devenu la solution incontournable ? Et surtout, pour un Data Scientist, quel est le rapport avec Kubernetes et le Machine Learning ?

<center><img style="margin-top: 20px;" src="https://upload.wikimedia.org/wikipedia/commons/thumb/6/67/Kubernetes_logo.svg/1280px-Kubernetes_logo.svg.png" alt="Kubernetes Logo" width="600" /></center>

## C'est quoi Kubernetes ?

Kubernetes est un projet qui a été à l'origine développé chez Google. Initialement, cela fait plus de 15 ans que Google utilise en interne son propre orchestrateur de conteneurs, qui à l'époque s'appelait **Borg**. Les besoins de Google en terme de gestion de conteneurs était clair : délivrer quotidiennement des centaines de milliers de conteneurs au sein de leur infrastructure globale. Borg, écrit en Go, était donc leur propre solution.

Au final des années, les besoins d'orchestration de conteneurs se sont ressenties au sein d'autres entreprises. Bien qu'il y avait Docker Swarm, l'orchestrateur de conteneurs développé par les créateurs de Docker, ce dernier ne remplissait pas globalement sa mission. Il fallut attendre 2014 pour que Google développe son propre orchestrateur en se basant sur sa forte expérience de gestion des conteneurs acquise avec Borg. Rendu open-source et légué à la <a href="https://www.cncf.io/" target="_blank">CNCF</a>, Kubernetes est aujourd'hui la référence incontournable et détrône les autres solutions telles que AWS ECS ou Docker Swarm.

---

**À lire aussi** : <a href="/formation/mlops">découvrez notre formation MLOps</a>

---

Pour bien comprendre la très forte popularité de Kubernetes, il nous faut bien comprendre son fonctionnement et son écosystème.

### L'écosystème Kubernetes

Tout d'abord, l'écosystème est un point central lorsque l'on parle d'un projet open-source. Outre ses nombreuses mises à jours et améliorations, le système de configuration de Kubernetes est très flexible et permet à tout moment de mettre à jour des applications en continu sans perturber leur fonctionnement. Ensuite, Kubernetes est présent dans la plupart des fournisseurs Cloud, aussi bien chez Google que AWS, Azure ou encore Digital Ocean. Enfin, de nombreuses applications de références et des _templates_ sont disponibles pour déployer très rapidement des solutions puissantes.

### Cluster Kubernetes

Avant toute chose, il faut bien évidemment présente le **cluster Kubernetes** dans son ensemble. Il s'agit de l'environnement constitué de serveurs physiques sur lesquels se base Kubernetes. Par l'intermédiaire de commandes systèmes, nous pouvons agir sur les différents objets du cluster par des opérations de lecture (_get_), de création (_create_), de mise à jour (_patch_) ou de suppression (_delete_). Ces 4 opérations, qui rappellent fortement les opérations <a href="https://fr.wikipedia.org/wiki/CRUD" target="_blank">CRUD</a>, sont **essentielles** sous K8s (pour Kubernetes). Et c'est justement `kubectl` qui va nous permettre d'interagir avec l'ensemble du cluster en communiquant avec l'API de K8s appelée **API Objects**.

Par exemple, `kubectl get` signifie que l'on souhaite voir/lister des informations sur une ou plusieurs ressources, alors que `kubectl patch` permettra de mettre à jour lesdites ressources.

### Objets K8s

Une des difficultés de K8s est qu'il y a **beaucoup d'objets** qui peuvent être difficiles à appréhender. Tout d'abord, commençons par les trois objets élémentaires.

Un **Node** (noeud) est un serveur/une machine virtuelle du cluster K8s qui exécute des conteneurs. Très souvent, ce n'est pas à nous de gérer les serveurs dans les Clouds publics. En revanche, nous devons plusieurs paramètres, dont la taille du cluster (nombres de noeuds), les ressources allouées à chaque noeud et les interfaces réseaux.

![](https://blent-learning-user-ressources.s3.eu-west-3.amazonaws.com/training/ml_engineer_facebook/img/kubernetes1.png)

Un **Pod** est un objet central sous K8s. Il s'agit d'une isolation logique d'un ou de plusieurs conteneurs au sein d'un seul noeud. Un pod peut contenir un ou plusieurs conteneurs. Par exemple, supposons qu'une entreprise propose un environnement isolé contenant une application et une base de données pour chaque client, alors un pod serait attribué à chaque client et chaque pod contiendrait deux conteneurs : l'application et la base de données.

![](https://blent-learning-user-ressources.s3.eu-west-3.amazonaws.com/training/ml_engineer_facebook/img/kubernetes2.png)

Ce sont notamment les pods qui vont être crées lorsqu'il y aura des montées en charge ou lorsque de nouvelles applications seront développées et déployées avec K8s.

Un **Volume** est un système de gestion de fichier qui peut être partagé entre les pods. C'est notamment utile lorsque des conteneurs, exécutés sur des pods différents (et potentiellement des noeuds différents), souhaitent partager des données sous forme de fichiers. Attention tout de même, la notion de volume sous K8s **n'est pas persistante** : le volume et les données seront détruits si le pod associé est supprimé. Pour cela, on utilise plutôt des **PersistentVolume**, bien qu'il ne soit tout de même pas conseillé d'y stocker des données de types relationnelles ou sensibles.

Pour récapituler :

- un **noeud** est un serveur/VM du cluster.
- un **pod** est un groupe d'un ou plusieurs conteneurs dans les noeuds.
- un **volume** est un système de fichiers rattaché à un ou plusieurs pods.

Mais alors, à quoi sert Kubernetes en Machine Learning ?

## Kubernetes pour entraîner des modèles

En général, entraîner des modèles de Machine Learning nécessite de la puissance de calcul. Qu'il s'agisse d'un algorithme d'Ensemble Learning comme XGBoost ou d'un réseau de neurones TensorFlow, l'entraînement prend du temps pour plusieurs raisons.

- Les hyper-paramètres d'un modèle de Machine Learning sont optimisés par des <a href="https://app.livestorm.co/blent-ai/boost-your-skills-comment-optimiser-les-modeles-de-machine-learning" target="_blank">méthodes de recherche par grille ou d'optimisation bayésienne</a>.
- Pour obtenir des scores cohérents et réalistes, on utilise des méthodes de <a href="https://scikit-learn.org/stable/modules/cross_validation.html" target="_blank">validation croisée</a> qui nécessitent d'entraîner de nombreuses fois un même modèle sur des ré-échantillonnage d'un jeu de données.
- Pour terminer, il est souvent obligatoire de devoir auditer le comportement du modèle avec des résultats attendus à l'aide de <a href="https://app.livestorm.co/blent-ai/bys-linterpetablite-des-algorithmes-un-enjeu-de-societe" target="_blank">méthodes de validation de modèles et d'interprétabilité</a>.

Autrement dit, avec toutes ces étapes, entraîner un modèle de Machine Learning type XGBoost **pourrait prendre plusieurs heures** sur son ordinateur. Or, avec Kubernetes, nous avons à la fois la possibilité d'obtenir des serveurs beaucoup plus puissants, mais aussi la capacité à paralléliser cette étape en profitant de tous les noeuds d'un cluster.

![](https://cdn.static-media.blent.ai/photos/blog/jupyterhub_k8s.png)

<a href="https://jupyterhub.readthedocs.io/en/stable/" target="_blank">JupyterHub</a> est un projet développé par l'équipe Jupyter, qui permet de créer des serveurs Jupyter Notebook à la demande, chaque serveur ayant ses propres ressources (nombre de processeurs, mémoire, carte graphique) et son environnement. Il est donc possible, par exemple, d'avoir accès à de la puissance de calcul avec un environnement Spark déjà installé, ce qui permet par exemple, pour un Data Scientist, de manipuler des données volumineuses directement depuis le cluster.

Kubernetes est particulièrement efficace ici, car il va **proposer de la puissance de calcul** à des utilisateurs, des **environnements spécifiques** et une capacité à monter en charge : si plusieurs Data Scientists ont besoin de serveurs Jupyter avec beaucoup de ressources, Kubernetes sera capable d'ajouter de nouveaux serveurs pour répondre à la demande.

## Kubernetes pour exposer des modèles

Une fois le modèle entraîné, se pose la question de son exposition, ou plutôt des questions.

- Comment proposer mon modèle de Machine Learning sous forme de service ?
- Comment garantir la haute disponibilité de mon service en cas de panne partielle ?
- Comment être _scalable_ en s'adaptant automatiquement à la charge ?

En temps normal, ces problèmes sont difficiles à solutionner, car il nécessite tout une équipe qui dispose à la fois des compétences techniques et du temps pour pouvoir mettre en place des solutions et surveiller les systèmes.

Kubernetes est dès le départ conçu pour **s'abstraire de toutes ces tâches techniques**, nécessaires mais à faible valeur ajoutée, pour se **concentrer sur la partie applicative**, qui représente une forte valeur ajoutée pour l'entreprise. Ainsi,

- Kubernetes utilise des **Services** qui permettent d'exposer des applications (API, agents, etc) accessible à l'intérieur du cluster ou en dehors (avec l'aide d'un équilibreur de charge par exemple).
- Kubernetes utilise des **Deployments** et des **ReplicaSets** pour définir, sous forme de configuration, un état désiré du service avec un nombre de réplica déterminé, garantissant ainsi la haute disponibilité de l'application, voir même sa montée en charge.

![](https://nexworld.fr/wp-content/uploads/2019/08/kub5.jpg)

Un modèle de Machine Learning peut être encapsulé sous forme d'une API (avec <a href="https://flask.palletsprojects.com/en/2.0.x/" target="_blank">Flask</a> ou <a href="https://fastapi.tiangolo.com/" target="_blank">FastAPI</a> par exemple), ce qui permet de le considérer comme une application à part entière. Ainsi, il est possible d'utiliser des Services et des Deployments sur une API qui exécute un modèle de Machine Learning, permettant ainsi de **répondre aux questions citées plus haut**.

Pour un Data Scientist, le déploiement est beaucoup plus rapide, car il doit uniquement construire l'API et la configuration de celle-ci sans avoir besoin de gérer l'infrastructure sous-jacente qui l'exécute.

---

**À lire aussi** : <a href="/formation/mlops">découvrez notre formation MLOps</a>

---

En ayant la capacité d'une part d'entraîner des modèles, et d'autre part de les exposer, il n'y a qu'un pas pour **intégrer et automatiser ces deux parties** sous forme de pipeline.

## Kubernetes pour l'approche MLOps

Ce que nous avons abordé jusqu'ici s'intègre en réalité dans la **mouvance MLOps**, qui cherche à appliquer les bonnes pratiques du DevOps au Machine Learning. Autrement dit, on cherche à **garantir une efficacité opérationnelle maximale** de nos pipelines ML tout en **automatisant les processus** d'entraînement et d'exposition.

Récemment, une nouvelle plateforme a fait son apparition : <a href="https://www.kubeflow.org" target="_blank">Kubeflow</a>. Le grande force de cette plateforme, c'est de permettre au Data Scientists et Machine Learning Engineers de créer des projets MLOps basés sur Kubernetes.

<iframe class="youtube" width="560" height="315" src="https://www.youtube.com/embed/cTZArDgbIWw" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

Kubeflow s'exécute et opère sur un cluster Kubernetes. Il vient avec de nombreux composants que l'on peut choisir d'installer ou non, et donc chacun a un rôle précis.

- Le plus populaire et le plus utilisé est <a href="https://www.kubeflow.org/docs/components/pipelines/overview/pipelines-overview" target="_blank">Kubeflow Pipelines</a>, qui permet de **construire, exécuter et administrer des pipelines ML automatisés**. Dans les pipelines, chaque étape exécute un script Python dans un pod particulier : cela nous offre la flexibilité de paramétrer les ressources (CPU, mémoire, GPU) à chaque étape du pipeline. Par exemple, supposons que l'entraînement d'un modèle nécessite un GPU, alors il sera possible d'allouer un GPU à l'étape d'entraînement, sans en avoir besoin lors des étapes précédentes pour la transformation des données par exemple.
- Le composant <a href="https://www.kubeflow.org/docs/components/notebooks" target="_blank">Notebook Servers</a> permet de **créer des serveurs Jupyter à la demande** pour chaque utilisateur, avec des ressources spécifiques et des dépendances déjà installées. Cela permet, par exemple, de provisionner un serveur Jupyter avec Spark déjà installé pour un utilisateur, et un autre serveur Jupyter avec TensorFlow et un GPU pour un autre.
- Le composant <a href="https://www.kubeflow.org/docs/components/kfserving/kfserving" target="_blank">KFServing</a> est utilisé pour **exposer des modèles de Machine Learning**, qu'ils soient construits sur une API de Scikit-Learn, TensorFlow, PyTorch ou encore XGBoost. La principale force de ce composant est qu'il gère lui-même toutes les tâches techniques comme la montée en charge, la haute disponibilité ou la propagation des mises à jour.
- Le composant <a href="https://www.kubeflow.org/docs/components/katib" target="_blank">Katib</a>, utilisé pour **optimiser les hyper-paramètres des modèles de Machine Learning** en profitant de la puissance de calcul et du caractère distribué de Kubernetes.

![An architectural overview of Kubeflow on Kubernetes](https://www.kubeflow.org/docs/images/kubeflow-overview-platform-diagram.svg)

## Conclusion

Comme nous venons de la voir, Kubernetes est un allié de poids pour les Data Scientists et les Machine Learning pour **élaborer des pipelines ML vers un niveau de production**. De plus en plus d'entreprises disposent de clusters Kubernetes qu'elles utilisent déjà en tant que plateforme de conteneurs pour exposer des services : il est donc très intéressant, pour les équipes Data, de se greffer à ces clusters existants pour **décharger la partie infrastructure** et se concentrer sur les pipelines ML.

De nouveaux outils voient également le jour, car la maturité autour du MLOps et des plateformes comme Kubernetes commencent à évoluer, permettant ainsi d'imbriquer ensemble des compétences diversifiées.

---


Tu as probablement déjà entendu parler de Kubernetes : c'est un outil extrêmement populaire dans le Cloud et qui est devenu, en quelques années, la référence en terme de déploiement d'applications dans le Cloud. Mais pourquoi (et surtout comment) Kubernetes est devenu la solution incontournable ? Et surtout, pour un Data Scientist, quel est le rapport avec Kubernetes et le Machine Learning ?

Kubernetes, créé par Google, est l'un des orchestrateurs de conteneurs les plus populaires au monde. Temps de lecture 8 min.

Kubernetes et Machine Learning


C'est l'un des profils dont les entreprises ont le plus besoin aujourd’hui. Le **Machine Learning Engineer** s'est imposé comme le profil idéal pour **industrialiser et mettre en production** des projets Data Science. En plus de ses compétences déjà solides en Machine Learning, il utilise les outils et services du Cloud pour déployer des modèles et des API sur des infrastructures complexes.

Mais concrètement, en quoi est-il différent du Data Scientist ? Et lorsque l'on parle du Cloud, que fait-il exactement ?

## Pourquoi le Machine Learning Engineer ?

Pour bien comprendre comment les choses ont évolué pour que ce profil apparaisse, revenons rapidement sur le cycle de vie d'un projet Data. Nous pouvons distinguer ces projets en deux phases.

- La **phase d'expérimentation**, où l'on cherche à construire un algorithme de Machine Learning permettant de répondre à une problématique spécifique. Cette phase contient non seulement les opérations de collecte et de transformation de données, mais aussi les étapes de modélisation (comprenant l'optimisation des modèles, leur validation et leur interprétation).
- La **phase de déploiement**, où l'on souhaite exposer le modèle (régulièrement sous forme d'API) sur un serveur distant dans le Cloud. Cette phase, beaucoup plus orienté développement, est plus complexe à appréhender pour des profils n'ayant pas ou peu pratiqué d'administration système et Cloud.

---

**À lire aussi** : <a href="/formation/mlops">découvrez notre formation MLOps</a>

---

Et c'est là une des premières difficultés que rencontre un Data Scientist : il y a une **fracture** en terme d'outils et de techniques entre les deux phases. L'une demande des connaissances en Python et en statistiques, alors que l'autre nécessite des compétences en Software Engineering et DevOps.

![](https://cdn.static-media.blent.ai/photos/blog/mle_article1.png)

Intéressons-nous à la phase de déploiement. Afin de fournir des prédictions, l'API exposé a besoin du modèle pour calculer ces prédictions. Mais elle doit également avoir à disposition des transformations des données qui avaient été utilisées pour entraîner ce même modèle. En effet, pour que le modèle puisse correctement calculer les prédictions, le format des données fournies en entrée doit être identique au format des données utilisé pour entraîner le modèle, sinon, nous aurons au mieux des erreurs de prédictions, ou au pire **un crash de l'API** !

Il est donc **indispensable** d'avoir exactement les même transformations entre la phase d'expérimentation et la phase de déploiement. En voyant ces deux phases, plusieurs questions surviennent.

- Comment **mettre à jour** le modèle et l’insérer dans le pipeline de production ?
- Comment stocker le modèle et comment garder une **traçabilité** ?
- Comment s’assurer que les données vont subir **les mêmes transformations** dans les deux phases ?
- Comment **automatiser** ces deux phases tout en gardant une cohérence ?

Pour avoir toutes ces fonctionnalités, il faut intégrer les bonnes pratiques de développement logiciel et gérer le cycle de vie des modèles pour déployer en continu. C'est justement ce qu'on appelle **l'approche MLOps** !

## L'approche MLOps

Formellement, le MLOps est une adaptation des pratiques DevOps aux problématiques spécifiques des projets Data Science. L'objectif est d'utiliser les outils DevOps que les développeurs ont l'habitude de manipuler pour les applications, et les transposer dans le contexte de la Data Science.

![enter image description here](https://cdn.static-media.blent.ai/photos/blog/mle_article4.png)

### Centralisation

Étant donné que les phases d'expérimentation et de déploiement sont potentiellement des codes sources différents, il est important de pouvoir **centraliser** les artifacts (modèle, graphiques, paramètres, etc) du projet dans un seul dépôt. L'intérêt de cette centralisation est double : pouvoir assurer une traçabilité des différentes expérimentations réalisées, et faciliter la lecture/écriture des artifacts entre les différents pipelines.

![](https://cdn.static-media.blent.ai/photos/blog/mle_article2.png)

Cette réalisation permet un fonctionnement **asynchrone** entre les deux pipelines : nous pouvons tout à fait exécuter plusieurs fois le pipeline ML sans mettre en production les modèles générés tant que ces derniers n'obtiennent pas une certaine performance minimale. Aujourd'hui, un des outils les plus populaires pour centraliser les modèles de Machine Learning est **MLflow**.

<center><img style="margin: 20px 0 20px 0" src="https://cdn.static-media.blent.ai/photos/blog/mle_article5.png" width="200" /></center>

Cet outil dispose de plusieurs composantes pertinentes pour centraliser les artifacts et les modèles.

- **MLflow Tracking** est l'API et l'interface utilisateur pour logger les hyper-paramètres, le versioning de code et les artifacts.
- **MLflow Projects** est un format standard pour package un code source et le ré-utiliser dans plusieurs projets.
- **MLflow Models** est un format de packaging pour les modèles de Machine Learning.
- **MLflow Registry** est le registre de modèle qui permet de s'assurer que les modèles respectent certaines contraintes.

Cette gestion des versions permet de garantir une cohérence entre les versions associées aux données (date d'extraction), du modèle et de l'API.

![](https://cdn.static-media.blent.ai/photos/blog/mle_article3.png)

### Software Engineering

Hérité des principes DevOps, le Software Engineering permet de construire un projet Data sous forme applicative, non plus avec des Jupyter Notebooks, mais avec des fichiers et une architecture de code modulaire. Plusieurs outils et frameworks existent pour gérer un projet Data Science en tant que Software Engineer, dont **Kedro** qui est de plus en plus utilisé. Créer un projet sous forme d'application requiert l'utilisation des bonnes pratiques.

- Construire un projet **code source**, pouvant être répliqué dans n'importe quel environnement.
- Respecter des **normes** (PEP 8) en appliquant du _linting_ et du _reformating_.
- Utiliser **un outil de versioning** (Git) et mettre à jour régulièrement ses fichiers.
- Rédiger une **documentation** de ses pipelines et de son code pour améliorer la productivité en collaboration.
- Réaliser des **tests** unitaires, d’intégration et de modèles.

Toutes ces bonnes pratiques visent toujours à s'assurer de la bonne exécution des phases dans des environnements distribués. Et c'est encore plus le cas lorsque cet environnement est automatisé.

![](https://cdn.static-media.blent.ai/photos/blog/mle_article7.jpg)

## Déploiement

Une des autres facettes très importantes pour le Machine Learning Engineer et qui est l'aboutissement du MLOps est le **déploiement de modèles**. Déployer un modèle de Machine Learning, c’est le rendre accessible aux utilisateurs autorisés depuis un serveur distant. Mais déployer un modèle de Machine Learning est difficile, et ce pour plusieurs raisons.

- Cela nécessite des compétences très orientées système/DevOps, qui ne sont pas toujours facile à acquérir.
- Le modèle doit est constamment « mis-à-jour » : un des phénomènes observés en production est le **model drifting**, où le modèle perd en pouvoir prédictif au fur et à mesure. Cela est en partie du à une dépendance temporelle présente dans les données, qui fait que les prédiction sont de moins en moins précises avec le temps.
- Il faut garantir une **haute disponibilité** en fournissant des réponses avec de faibles latences.
- Le modèle doit être **scalable**, c'est-à-dire pouvoir s'ajuster lorsque les charges deviennent importantes.
- Du **monitoring** doit être mis en place pour vérifier la bonne exécution de l'API et du modèle tout au long de son fonctionnement.

---

**À lire aussi** : <a href="/formation/mlops">découvrez notre formation MLOps</a>

---

Le Machine Learning Engineer doit donc s'armer d'outils adaptés qui améliorent l’efficacité opérationnelle. Pour cela, il va devoir mettre en place des méthodes d'automatisation et déterminer des plateformes cibles adapter pour héberger l'API. L'automatisation, déjà très présente pour l'approche DevOps,

![](https://cdn.static-media.blent.ai/photos/blog/mle_article8.png)

Pour le déploiement, le Machine Learning Engineer dispose de plusieurs possibilités.

- Les **instances de machines virtuelles** (ou Bare Metal), adaptées pour un déploiement pour tester le fonctionnement de l'API. Bien que plutôt facile à mettre en place, elles présentent beaucoup de défauts qui ne permettent pas une mise en production efficace.
- Le **serverless** est une méthode de déploiement de plus en plus privilégiée, car elle est rapide à mettre en place et peut s'automatiser facilement.
- Enfin, les **plateformes d'orchestration** dont Kubernetes est sûrement le plus populaire, sont les solutions les plus efficaces lorsque les charges deviennent très élevées. Il y a, en théorie, aucune limite en termes de ressources disponibles, permettant par d'exemple d'obtenir des clusters avec des centaines de processeurs et des milliers de Go de mémoire vive !

Pour résumer, le Machine Learning Engineer est aussi bien un Data Scientist qu'un DevOps sensible aux contraintes des projets Data.

![](https://cdn.static-media.blent.ai/photos/blog/mle_article9.png)

Pour avoir plus détails, nous avions également <a href="https://app.livestorm.co/blent-ai/le-metier-de-machine-learning-engineer/live" target="_blank">organisé un Workshop</a> sur le métier de Machine Learning Engineer.

## Concrètement, par où commencer ?

On peut se sentir rapidement perdu lorsque l'on souhaite se former au ML Engineering. Et pour cause, difficile de s'y retrouver avec tous les outils disponibles !

Le plus important, c'est d'abord de **consolider les bases** en développement. Il faut maîtriser le langage Python, et pas uniquement l'utiliser. Pour cela, une bonne connaissance des concepts avancés tels que les opérateurs lambda, la gestion des exceptions ou les décorateurs de fonctions est indispensable.

Ensuite, le Software Engineering est une étape incontournable : il faut **adapter les bonnes pratiques** de développement dans les projets Data. Cela passe par l'élaboration d'une architecture de code en y intégrant les pratiques de collaboration, de tests et de documentation. L'utilisation d'un éditeur de code (IDE) type <a href="https://visualstudio.microsoft.com/fr/" target="_blank">Visual Studio</a> ou <a href="https://www.jetbrains.com/fr-fr/pycharm/" target="_blank">PyCharm</a> te permettra d'être plus efficace, alors adopte-en un si ce n'est déjà pas le cas. 😉

Et enfin, il y a toute la chaîne MLOps. Du déclenchement automatisé avec des pipelines CI/CD en passant par du déploiement sur des plateformes d'orchestration, en ne négligeant pas la surveillance continue et la journalisation, c'est tout un nouveau monde à découvrir.

Si tu as aimé cet article, alors tu vas sûrement adorer la Blent Family où tu trouveras plein de bons conseils pour te former sur des sujets aussi technique que le MLOps !


C'est l'un des profils les plus demandés par les entreprises depuis quelques années. Le Machine Learning Engineer s'est imposé comme le profil idéal pour industrialiser et mettre en production des projets Data Science. En plus de ses compétences déjà solides en Machine Learning, il utilise les outils et services du Cloud pour déployer des modèles et des API sur des infrastructures complexes.

Le Machine Learning Engineer est un profil capable d'industrialiser des modèles de Machine Learning. Temps de lecture 8 min.

Machine Learning Engineer : définition, comment se former


L'AutoML est une pratique courante dans les projets Data Scientist qui consiste à **automatiser le création des modèles de Machine Learning**. Cela va permettre de gagner du temps puisque cette pratique va tester à la fois plusieurs méthodes de transformations des données, mais aussi plusieurs modèles de Machine Learning pour ensuite les comparer et conserver le plus performant.

En voyant ceci, beaucoup sont tentés de dire que cette pratique va remplacer à terme les Data Scientists. Mais est-ce réellement le cas ? Peut-on faire confiance à l'AutoML au point de ne plus toucher au pipeline ML ? Et plus précisément, c'est quoi le pipeline ML ?

## Les étapes d'un projet de Machine Learning

Pour bien comprendre comment fonctionne l'AutoML et pourquoi il peut se révéler utile, revenons en détails sur les étapes qui constituent un projet de Machine Learning.

![Pipeline ML](https://cdn.static-media.blent.ai/photos/blog/pipeline_ml_auto_ml.jpg)

Avant même de démarrer le développement, il faut tout d'abord **déterminer l'expression du besoin**, qu'est-ce que l'on souhaite résoudre/optimiser avec le modèle prédictif. Une fois établi, vient ensuite **l'identification des sources de données**, qui consiste à se poser la questions suivante :

> Quelles sont les sources de données qui vont me permettre de résoudre mon problème en les utilisant pour un algorithme prédictif ?

Ces données encapsulent la réalisation d'un phénomène à un instant donné (scoring, tarification, comportement) : si c'est ce dernier que l'on souhaite reproduire, les données permettront de le modéliser.

---

**À lire aussi** : <a href="/formation/mlops">découvrez notre formation MLOps</a>

---

Enfin, c'est le **pipeline ML** qui est véritablement le cœur du sujet pour le Data Scientist. Ce pipeline, dont l'objectif est d'aboutir à un modèle de Machine Learning optimal, est constitué de plusieurs étapes.

1. La collecte des données, qui consiste à **récupérer les données** depuis les sources renseignées.
2. Le nettoyage des données va permettre de **supprimer les valeurs aberrantes**, corriger les valeurs manquantes mais aussi **apporter de la connaissance** sur les données. Savoir de quoi on parle est extrêmement important pour la suite du pipeline.
3. Plus technique, la partie appelée _Feature Engineering & Selection_ a deux objectifs. Tout d'abord, il s'agit de **construire les variables explicatives**, appelées _features_, qui vont être fournies à l'algorithme en entrée et qui sont supposées apporter de l'information sur le phénomène. Ensuite, la **sélection des variables** va, quant à elle, permettre de sélectionner uniquement les variables qui nous paraissent pertinentes dans le sens où elles vont nous apporter de l'information sur le phénomène cible. À titre d'exemple, si l'on souhaite calculer la durée d'un trajet automobile, l'heure de départ va fortement influencer le résultat, contrairement au nombre de passagers qui semble être moins impactant.
4. La phase d'entraînement du modèle, c'est l'art de **calibrer un modèle de Machine Learning** à partir des variables explicatives calculées et sélectionnées dans l'étape précédente. En règle général, le Data Scientist privilégie un modèle en particulier en fonction de la problématique (prédiction d'une quantité, d'une catégorie, regroupement) ainsi que du format des données (tabulaires, images, texte).
5. La dernière étape doit s'assurer que **le modèle est optimal** : elle se définit par de bonnes performances quantitatives (évaluation par une métrique) mais aussi par une interprétabilité pertinente du modèle (peut-on expliquer pourquoi le modèle a calculée une telle prédiction ?).

Pour terminer, le déploiement est la dernière étape pour exposer le modèle sur un serveur afin qu'il puisse être accessible et consommé par des utilisateurs (authentifiés ou non) ou des services.

![Word Embedding : une méthode d'encodage pour le texte](https://adriancolyer.files.wordpress.com/2018/02/evolving-word-embeddings-fig-1.jpeg)

## L'automatisation du pipeline ML

Faisons maintenant un focus de la deuxième étape à la dernière. Toutes ces étapes doivent être **exécutées séquentiellement**, la sortie d'une étape est l'entrée de la suivante. Ainsi, l'on souhaite effectuer une modification sur une étape, il faut au moins relance toutes celles qui en découlent : c'est une **tâche redondante** qui va justement être automatisée dans le cas où l'on souhaite tester plusieurs modèles et plusieurs méthodes d'encodage (_feature engineering_).

Il existe une multitude de librairies permettant de faire de l'AutoML. Les plus connues, en Python, supportent les frameworks connus comme `scikit-learn`, `tensorflow` ou `pytorch`.

- La plus facile à mettre en place est <a href="https://automl.github.io/auto-sklearn/master/" target="_blank">auto-sklearn</a>, qui se base sur la très populaire librairie `scikit-learn` pour automatiser l'entraînement des modèles natifs à cette dernière. En combinant avec les <a href="https://blent.ai/blog/a/les-pipelines-de-scikit-learn" target="_blank">pipelines de scikit-learn</a>, il est possible d'automatiser le pipeline ML dans son intégralité avec peu de modifications du code source.
- Sur des sujets plus spécifiques, comme les réseaux de neurones par exemple, nous pouvons citer <a href="https://autokeras.com" target="_blank">AutoKeras</a>, une librairie AutoML spécialement conçue pour la librairie `keras` avec les réseaux de neurones.
- Si l'on se base sur des produits ou services intégrées, un des plus utilisé est <a href="https://cloud.google.com/automl" target="_blank">Cloud AutoML</a> de Google Cloud, qui permet très rapidement et à l'aide d'une interface visuelle d'automatiser le pipeline ML. D'autres solutions, comme <a href="https://www.dataiku.com" target="_blank">Dataiku</a>, intègre des solutions d'AutoML, ayant également des contraintes spécifiques sur l'interprétabilité ou le rapport temps de calcul sur performances.

![Un exemple d'optimisation des hyper-paramètres](https://miro.medium.com/max/2508/1*SzrEmTzro2kdvy_7cVunvw.png)

## Quels sont les avantages et les inconvénients de l'AutoML ?

Bien entendu, l'AutoML n'est pas une solution miracle qui va remplacer les Data Scientists. Au contraire, il va être un **puissant allié** pour se concentrer à l'essentiel. Profitant de l'automatisation du pipeline ML, les avantages sont multiples.

- Le premier avantage de l'AutoML est **le gain de temps** comparé à l'approche classique où le Data Scientist doit lui-même développer les différentes expérimentations sur les modèles.
- Le second est la **cohérence des traitements** appliqués sur le jeu de données : un des problèmes majeurs dans les projets Machine Learning est le manque de centralisation des étapes de traitement de données, qui aboutissent à des difficultés pour reproduire les expérimentations.
- Le dernier avantage la **facilité d'utilisation** puisqu'il n'est plus nécessaire de connaître les détails de fonctionnement de chaque algorithme que l'on va utiliser, les librairies d'AutoML étant justement adaptées pour les modèles qu'elles implémentent.

À l'inverse, l'AutoML va aussi présenter quelques inconvénients.

---

**À lire aussi** : <a href="/formation/mlops">découvrez notre formation MLOps</a>

---

- Même si l'automatisation va tout de même apporter des modèles avec de bonnes performances, elles **ne seront pas optimales** comparé à un modèle maîtrisé par un Data Scientist qui sait parfaitement comment l'optimiser.
- L'autre problématique est **l'effet boîte noire** : puisque l'on sélectionne le modèle qui maximise des performances quantitatives, ce dernier peut ne pas correspondre au modèle souhaité s'il n'est pas facilement interprétable (comme cela peut être demandé en assurance ou en médecine).
- Enfin, les solutions AutoML **ne sont pas toujours adaptées** à certaines problématiques spécifiques où le traitement des données doit nécessiter une intervention humaine.

![AutoML en bref](https://miro.medium.com/max/2136/0*J0EeFcKHs772-qYE)

Bien que l'AutoML peut être utile dans certains cas, cela **ne remplacera pas le Data Scientist** : bien souvent, la créativité humaine est meilleure pour déterminer les meilleures méthodes d'encodage et l'AutoML ne remplacera pas une connaissance fine et précise d'un modèle puissant.

En somme, il est préférable de garder l'AutoML sur des sujets qui ne permettent pas d'investir beaucoup de temps dans la phase de construction du modèle : dans ce cadre précis, il s'agit d'une pratique parfaitement adapté.


L'AutoML est une pratique courante dans les projets Data Scientist qui consiste à automatiser le création des modèles de Machine Learning. Cela va permettre de gagner du temps puisque cette pratique va tester à la fois plusieurs méthodes de transformations des données, mais aussi plusieurs modèles de Machine Learning pour ensuite les comparer et conserver le plus performant.

L'AutoML est une pratique qui consiste à automatiser le création des modèles de Machine Learning. Temps de lecture 7 min.

Articles MLOps

Data Engineering

IA Générative

MLOps

Cloud & DevOps

À propos