Version 1.5 de MLflow lors de l’écriture, certaines informations peuvent ne plus être valide dans les versions futures.

Depuis sa sortie en juin 2018, MLflow n’arrête pas de faire parler de lui. Outil open source, développé par Databricks, qui se définit comme une plateforme permettant de gérer le cycle de vie des projets de machine learning. Cette série d’articles vous est proposée pour faire un tour d’horizon des possibilités de MLflow et ainsi comprendre sa place dans l’écosystème grandissant des projets de machine learning, et surtout apprendre à l’utiliser.

MLflow est un regroupement d’APIs répondant aux diverses problématiques que l’on rencontre lors de la réalisation d’un projet de machine learning :

Tracking, pour le suivi des expériences
Models, pour le packaging des modèles
Projects, pour reproduire des expériences

De plus, MLflow est agnostique aux technologies qui l’entourent, et ne contraint pas à l’utilisation d’une technologie ou d’un framework en particulier. Bien employé, il peut s’avérer être un atout de choix !

Pour ce premier article, le focus sera mis sur l’API Trackin g.

Découvrons l’API Tracking

À haut niveau, cette API se base sur deux notions : Experiments et Runs.

Une Experiment est un rassemblement de Runs. La notion d’Experiment est subjective et peut être utilisée de diverses façon, autant pour faire du grid search, que pour représenter un projet. La raison d’être d’une Experiment étant de permettre la comparaison entre les différents Runs la composant.

Un Run se compose, lui, de métadonnées, tels que les paramètres utilisés, les métriques observées, ainsi que des artifacts générés/archivés lors du Run. Il est également possible d’ajouter des tags aux Runs.

Les paramètres et les métriques sont similaires en termes de format, mais il existe une différence majeure entre ces deux entités :

une métrique est une valeur qui peut évoluer dans le temps, tel qu’une loss
un paramètre ne peut évoluer, comme par exemple le nombre d’epoch d’entrainement ou le learning rate initial

Les artifacts sont des données binaires pouvant être aussi bien les poids d’un modèle Tensorflow (.h5), que le jeu de données utilisé pour l’entrainement, ou bien encore une image représentant une matrice de confusion. Il n’y a pas de limitation quant aux éléments pouvant être stockés comme des artifacts.

Que ce soit les paramètres, les métriques, les tags ou les artifacts, chacune de ces notions est abstraite et peut être utilisée selon le besoin.

A titre d’exemple, dans le cadre du tuning d’hyperparameters tels que le learning rate et le batch size, ces notions peuvent être utilisées de la façon suivante :

L’Experiment représente le grid search
Chaque Run est représenté par un learning rate et un batch size (paramètres) qui ont produit un modèle entrainé (artifact) associé à une loss (métrique)
Et enfin, le Run correspondant aux paramètres d’entrainement optimaux aura un tag pour l’identifier

Comment utiliser cette API ?

L’API Tracking de MLflow est disponible à travers différents languages : Python, Java, R, et également via une API Rest.

De nombreux exemples d’utilisation de l’API Tracking sont présents dans le github de MLflow : https://github.com/mlflow/mlflow/tree/master/examples

[py]import mlflow
import math
import tempfile

content = "my first run"
epochs = 10
# Utilisation de l’Experiment par défaut
mlflow.set_experiment("Default")
# Création d’un nouveau Run
with mlflow.start_run():
# Log un paramètre
mlflow.log_param("epochs", epochs)
for i in range(epochs):
# Log d’une métrique
mlflow.log_metric("epoch_exp", math.exp(i))
with tempfile.NamedTemporaryFile("w") as f:
f.write(content)
f.flush()
# Log d’un fichier texte en tant qu’artifact
mlflow.log_artifact(f.name)[/py]

Par défaut, MLflow stocke les informations dans le système de fichiers local, dans un dossier mlruns, avec l’arborescence ./mlruns//. C’est la configuration la plus simple pour débuter et commencer le développement en local.

run_id est un id unique généré lors de la création d’un Run. Un Run est créé lors de l’appel à la fonction mlflow.start_run() ou bien encore lors du premier appel à une fonction mlflow.log_*.

experiment_id correspond à l’id de l’Experiment. Il peut être changé via la fonction mlflow.set_experiment(""), la variable d’environnement MLFLOW_EXPERIMENT_NAME ou MLFLOW_EXPERIMENT_ID, sinon MLflow utilise l’Experiment par défaut.

Astuce pour le développement en local

Si vous souhaitez centraliser l’ensemble des vos Experiments et Runs dans un dossier mlruns unique en local, vous pouvez changer le chemin par défaut grâce à la variable d’environnement MLFLOW_TRACKING_URI ou bien via du code mlflow.set_tracking_uri("") en précisant local://chemin/vers/un/dossier/mlruns.

Pour des usages plus avancés, il est fortement conseillé de s’orienter vers d’autres espaces de stockage.

Les Stores du tracking

De part leur nature, les métadonnées et les artifacts sont stockés dans des espaces de stockage spécifique. Ces espaces de stockage seront appelés stores dans la suite de l’article, alors que dans MLflow ils sont appelés respectivement backend store et artifact store.

Pour les métadonnées, le store peut avoir plusieurs formes, système de fichier, base de données, Workspace Databricks ou bien une API Rest MLflow.

Pour les artifacts, de nombreuses options sont proposées, système de fichier, (s)FTP, HDFS, Object storage, …

Pour la liste exhaustive et la configuration de chaque store, lire la documentation de MLflow : https://www.mlflow.org/docs/latest/tracking.html#storage

Le lien entre les métadonnées et les artifacts se situe au niveau des métadonnées des Experiments. Lors de la création d’une Experiment il est possible de spécifier l’artifact_location.

artifact_location est utilisé comme base pour définir un chemin de stockage unique pour chaque nouveau Run de l’Experiment. Ce chemin unique est alors stocké dans les métadonnées du Run.

[bash]# Créer une Experiment en ligne de commande en précisant –artifact-location
mlflow experiments create -n new_experiment –artifact-location <artifact_store_ui>
# Depuis l’API Python
mlflow.create_experiment("new_experiment", artifact_location="<artifact_store_ui>")[/bash]

Attention, cette partie est très importante pour comprendre la philosophie de l’outil.

Information importante pour la compréhension

Pour comprendre l’interaction entre le client et les stores, il faut comprendre que l’ensemble de l’intelligence du projet se trouve côté client au niveau du code de MLflow.

Pour se connecter à ces stores, tout se déroule du côté du client. La partie store n’apporte qu’une solution de stockage. Le client doit alors disposer des informations pour se connecter aux différents stores, et orchestrer les appels pour stocker les informations propres aux Runs.

Interaction entre le client et les stores

Point d’attention, le client se connecte directement aux stores, il n’y a donc aucune surcouche de sécurité, MLflow se repose sur la sécurité proposée par les différents stores.

Comment centraliser les Experiments et les Runs ?

Au niveau de l’environnement de développement de chacun des clients, il faut configurer l’accès à ces stores :

Utiliser la variable d’environnement MLFLOW_TRACKING_URI ou le code mlflow.set_tracking_uri("") pour l’uri du store des métadonnées
Configurer l’accès au store des artifacts : https://www.mlflow.org/docs/latest/tracking.html#artifact-stores
Créer une Experiment avec un artifact_location pointant vers le store des artifacts

L’un des gros avantages de MLflow, une fois l’environnement de développement configuré, le code pour logger les métadonnées et artifacts des Runs ne change pas quels que soient les stores utilisés.

Une interface graphique pour simplifier la consultation

Le client MLflow peut être accompagné d’une interface graphique pour simplifier la recherche et l’exploration des diverses Experiments et Runs. Pour se faire, 2 options : mlflow ui ou mlflow server.

Dans la version 1.5.0 de MLflow, ces 2 options sont très similaire en termes de fonctionnalités, il est possible de changer le store des métadonnées via l’option --backend-store-uri.

La direction que prend actuellement MLflow est d’orienter mlflow ui pour de l’analyse en local, et mlflow server pour un usage à grande échelle. mlflow server est également utilisé pour démarrer l’API Rest de MLflow qui peut être utilisé comme store de métadonnées, pour plus d’informations : https://www.mlflow.org/docs/latest/tracking.html#mlflow-tracking-servers.

L’ensemble des fonctionnalités proposées par la UI de MLflow est également disponible depuis les différentes APIs. Cela permet d’exploiter les capacités de MLflow dans des outils externes, par exemple pour l’intégrer à un outil de dashboard externe ou bien dans une pipeline d’automatisation de déploiement de modèles.

Page de visualisation d’une Experiment

Page de visualisation d’un Run

Mes recommandations

L’API Tracking de MLflow tant une solution générique pouvant s’adapter à de nombreux cas d’usages, il peut sembler compliqué de se lancer dans l’aventure, voici donc mes recommandations si vous souhaitez utiliser cette API.

Dans le cadre d’un PoC où tout le travail est effectué sur un seul poste :

Utilisez MLflow sans configuration
Consultez les Runs depuis la UI avec la commande mlflow ui

Dans le cadre d’un déploiement à plus grande échelle :

Utilisez un store de métadonnées de type base de données à la place du système de fichiers ou de l’API Rest pour vous reposer sur la sécurité mise en place par ce store
Stockez vos artifacts dans un store de type object storage tels que MinIO pour exploiter la sécurité de l’outil
Développez une UI qui correspond à vos besoins pour l’intégrer dans votre écosystème

Dans un cadre plus général, pour intégrer l’API Tracking dans un projet, il est conseillé de le faire au niveau le plus haut possible afin que l’impact sur le programme soit minimal, et que MLflow ne soit pas un blocage dans l’exécution de votre programme.

Conclusion

L’API Tracking de MLflow apporte son lot de concepts permettant ainsi à chacun de l’adapter en fonction de ses besoins. Les différents Stores proposés par MLflow offrent une flexibilité quand à l’utilisation de l’outil en entreprise, et s’adapte facilement au plus grand nombre d’infrastructure.

Cependant, pour des usages plus avancés tel que l’exposition de modèles ou l’intégration avec d’autres outils, on se retrouve assez vite limité en n’utilisant que l’API Tracking.

L’API Model répond justement à ces besoins et le prochain article de cette série sera dédié à cette API.

MLflow et son API Tracking, suivre ses expériences est devenu facile !