Plusieurs outils existent dans le but d’essayer de résoudre les problèmes évoqués dans la première partie de l’article et nous faciliter la vie. Certains de ces outils sont open source et d’autres sont payants, chacun apportant des solutions à différents problèmes (souvent les mêmes). Dans la deuxième partie, nous avons présenté la solution open source DVC qui, accompagnées de Git, et combiné à MLFLOW, permet de résoudre la plupart des problèmes de versionning que nous, data scientists, rencontrons au quotidien. Malheureusement DVC ne gère pas l’aspect déploiement, tout comme la comparaison des modèles de manière graphique, du moins pas actuellement. Place donc à la troisiéme partie de Data Science – DevOps : MLflow.
Data Science – DevOps : MLflow
MLflow (actuellement en version bêta) est une plate-forme open source permettant de gérer le cycle de vie d’un projet machine learning, y compris l’expérimentation, la reproductibilité et le déploiement. Il comporte actuellement trois volets :
- MLflow Tracking
- MLflow Project
- MLflow Models
Dans cet article on s’intéresse aux deux composant qui sont MLflow Tracking et MLflow Models, que nous allons combiner à DVC pour pallier aux manquements actuels de DVC.
MLflow fonctionne mieux avec anaconda
Installation :
pip install mlflow
MLflow Tracking
C’est le composant de MLflow qui permet de gérer les expérimentations, ces expérimentations peuvent contenir différentes exécutions avec bien sûr différents paramètres. Nous allons principalement l’utiliser pour comparer les métriques issues de différentes expérimentations. Pour être honnête, DVC permet de comparer des métriques issues de différentes branches/tags Git, mais c’est en mode commande et c’est pas encore très complet.
De l’autre côté avec MLflow nous avons une interface graphique avec des courbes et des filtres pour avoir une analyse poussée des métriques et une meilleures comparaison de nos différents modèles.
Deux méthodes seront principalement utilisées pour traquer les paramètres et les métriques :
mlflow.log_param(« alpha », alpha)
mlflow.log_metric(« mae », mae)
MLflow sauvegarde ces métriques/paramètres dans des fichiers groupés par dossier. Chaque dossier contenant les résultats d’une exécution qui sont à leur tour regroupés dans des dossier d’expérimentations qui sont placés dans un dossier mlrun.
Pour lancer l’interface graphique qui affiche les métriques il suffit de se placer dans le dossier contenant le répertoire mlrun et d’exécuter la commande : mlflow ui, puis de visiter la page web : http://127.0.0.1:5000. Les figures 6 et 7 montrent un aperçu de cette interface web.


MLflow Models
Il permet entre autre de sauvegarder des modèles dans un format compatible avec différents outils tels que SPARK ou le déploiement automatique avec MLflow via un web service REST.
Pour sauvegarder un modèle dans le format MLflow, il suffit d’importer l’API associée à la librairie utilisée pour créer le modèle (e.g scikit learn, TensorFlow …) et sauvegarder le modèle avec la méthode log_model précédée de la librairie utilisée pour la construction du modèle.
Exemple : mlflow.sklearn.log_model(mon_model, « model »)
Une petite remarque à faire ici, il faut explicitement importer la librairie en question pour qu’elle soit reconnue. Par exemple importer mlflow ne suffit pas pour appeler mlflow.sklearn.*. il faut utiliser l’instruction : import mlflow.sklearn
mlflow pyfunc serve -m /home/thierno/mlflow/examples/sklearn_elasticnet_wine/mlruns/0/f0e5c0304ca544f48175411f66799d6c/artifacts/model/ -p 1234 –no-conda
Cette commande lance un API rest local créé avec Flask, le web service est disponible via le port 1234 indiqué lors de l’exécution de la commande et utilise le modèle donné via l’option m.
Pour les gens qui veulent escalader des montagnes, Ces modèles peuvent aussi être déployés dans le cloud avec amazon sage maker, azure ml.
Pour plus de détail sur le fonctionnement de MLflow, veuillez consulter la documentation, cependant on est loin de celle de DVC en terme de clarté.
Conclusion
Dans cette série de trois articles, nous avons essayé d’analyser ensemble l’autre côté de la pièce du métier d’un data scientist(DevOps data science) souvent négligé mais indispensable. Nous avons d’abord illustré quelques difficultés rencontrées par les data scientist liées à la gestion technique de leurs projets.
Suite à cela, deux solutions open source(DVC et MLflow) très convoitées ont été explorées dans le but de voir comment elles participent à la résolution des problèmes de versionning que rencontrent les magiciens de la donnée tout en montrant leurs limites respectives.
Cependant ces solutions sont en plein développement et devraient subir des changements majeurs dans un futur proche en espérant qu’elles vont devenir plus complètes et plus robustes.
Références :
http://www.linux-france.org/article/sys/fichiers/fichiers-1.html
https://mlflow.org/docs/latest/index.html