MLflow : Databricks passe le flambeau à la Fondation Linux

Une croissance rapide en neuf mois

Depuis octobre 2019 fait des émules. Il y a 9 mois, Databricks comptabilisait 800 000 téléchargements mensuels et 140 contributeurs. Aujourd’hui, MLflow est téléchargé deux millions de fois par mois.

Selon Matei Zaharia, il y a deux raisons à cela. « Quand les entreprises commencent à utiliser davantage le machine learning et essaient de construire des applications qui ont de véritables impacts sur leurs activités, elles réalisent qu’elles ont besoin de s’assurer que ces applications soient fiables et robustes aujourd’hui et à l’avenir », remarque-t-il.

La deuxième raison est d’ordre technique. « Les premières versions de MLflow en tant que projet open source n’étaient que des bêta et n’avaient pas les fonctionnalités disponibles aujourd’hui. L’une d’entre elles, présentée en octobre dernier, se nomme Model Registry. […] Pour certains, sa disponibilité a été cruciale dans l’adoption de MLflow », constate Matei Zaharia.

Model Registry, c’est le composant qui a permis à Databricks d’accomplir son objectif : faire de MLflow une solution de gestion de bout en bout pour les modèles de machine learning. Model Registry, permet de versionner et gérer les modèles en production. Les trois autres composants, Tracking, Projects et Models, doivent faciliter l’expérimentation, le développement, la reproduction et le déploiement des modèles.

 La croissance de ce projet se mesure également en nombre d’exécutions. Selon le CTO de Databricks, MLflow a déjà servi pour exécuter plus d’un million de modèles ML et plus de 100 000 modèles seraient ajoutés au Model Registry disponible dans Databricks « chaque semaine ».

De nouvelles fonctionnalités pour tester les modèles et les passer en production

Afin de poursuivre cette croissance, Databricks a annoncé quelques ajustements à MLflow. L’un d’entre eux consiste à adapter la fonction autologging qui permet d’enregistrer des paramètres, des métriques, les notebooks et les fichiers associés à des modèles à l’aide d’une seule ligne de code. Cette solution doit permettre de reproduire exactement les conditions d’exécution des modèles lors des phases d’entraînement et de test. Maintenant, il est possible de collecter les données provenant d’Apache Spark et de Delta Lake. Autologging est compatible avec six frameworks : TensorFlow, Keras, Gluon, LightGBM, XGBoost et Spark. Facebook s’apprête à ajouter une intégration avec Pytorch et Databricks une autre avec scikit-learn.

Dans le composant Models, la version 1.9 offre un moyen de spécifier automatiquement les types de données d’entrées et de sortie pour un modèle. Cette fonction nommée Model Schema permet de vérifier si le schéma de données correspond aux types de modèles à appliquer. Par exemple, si un algorithme doit calculer un prix en sortie, les données en entrées ne peuvent pas être des codes postaux.

Par ailleurs, les étiquettes associées aux modèles dans Registry peuvent être lues par des outils CI/CD comme GitLab et Jenkins via des API dédiés. Ainsi, il est plus aisé pour les data scientists et les data engineers de gérer les modèles depuis une chaîne d’outils complète.  

Les outils d’entraînements d’algorithme sont nombreux. Ceux de gestion d’inférence, un peu moins. L’éditeur simplifie la manière de déployer un modèle sur plusieurs plateformes. Il a conçu pour cela une API qui permet d’utiliser une seule commande pour le faire. Pour l’instant, deux endpoints sont disponibles pour RedisAI et Google Cloud Platform. Des portages sont prévus pour SageMaker, AzureML et Kubernetes. Cela doit réduire le volume de code personnalisé à écrire pour lancer un workload en production.

Une meilleure intégration entre Databricks et MLflow

Bien évidemment, Databricks veut renforcer l’intégration de MLflow avec sa plateforme de data science dans le cloud.

Parmi les ajouts à noter, l’éditeur octroie aux utilisateurs de cloner leur environnement, un snapshot d’un notebook, pour le conserver ou l’appliquer à certaines données. Une fonctionnalité directement héritée d’autologging.

L’autre nouveauté à retenir, c’est l’intégration de Model Registry dans Databricks. Cela permet de rendre disponible la fonctionnalité « MLflow Model Serving ». Comme avec la version open source, le composant doit stocker plusieurs versions d’un modèle, permettre de l’évaluer et de le classer selon sa maturité (d’état expérimental, en production à l’archivage). Model Serving s’appuie sur ces informations pour passer en production les dernières versions des modèles ML développés en lançant un cluster dédié, puis les pousser vers des endpoints REST afin de les rendre disponibles dans les applications.

La préversion publique de Model Serving dans Databricks est prévue pour la fin du mois de juillet.

Plusieurs acteurs ont commercialisé des logiciels dits MLOps comme Microsoft Azure, GCP, DataRobot, ou encore Cloudera. Selon Matei Zaharia, le MLOps est l’une des composantes de MfFlow. « Nous n’avons rien vu qui s’étende autant que MLflow […] Les opérations MLOps concernent plutôt la manière dont je déploie et surveille le modèle. Mais pour moi, la plateforme de machine learning [le concept dont est inspiré MLflow, N.D.L.R.] est plus complexe, car elle implique également la préparation de données, la collaboration, ou encore le choix du processus de développement », conclut-il.