Dans le précédent article de notre Mois de la Data, nous vous avons présenté comment gérer vos projets data avec Azure DevOps. Pour ce troisième article, nous vous invitons à découvrir cet outil de Data Science dont on ne se passe plus :  MLflow.

MLflow est une plateforme open source permettant la gestion du cycle de vie du Machine Learning (ML) de bout en bout. Découvrez aujourd’hui comment MLflow peut vous faire gagner du temps et réduire votre time to market, tout en garantissant des livraisons dans le respect des bonnes pratiques autour de la Datascience et du DevOps.

ML : de nouveaux enjeux

Le Machine Learning est un domaine de plus en plus fascinant, notamment en raison de l’intime relation qui peut exister entre la phase de Build et de Run. Lorsque l’on construit une application classique (site e-commerce, etc.), le Run n’a pas un impact aussi fort sur le Build que lorsqu’on fait du ML. Une application standard, du moment qu’elle est bien construite, peut vivre sa vie de Run sans jamais influencer le Build car il n’existe pas nécessairement de relation de causalité entre les résultats du Run et les contraintes de Build.

A l’inverse, quand on construit un modèle Machine Learning, surveiller le Run est indispensable pour améliorer le Build et donc garantir des livraisons de qualité dans les prochaines itérations. C’est dans cette dynamique que s’inscrit MLflow : cette solution apporte, à travers un outil unique, une réponse technique frôlant l’exhaustivité des besoins du marché.

A la fin de cet article, vous saurez :

  • Quelles sont les principales raisons liées à la création MLflow ?
  • Quels composants utiliser pour livrer de façon itérative ?
  • Comment sécuriser les déploiements ML en production ?
  • Quels indicateurs mettre en place pour fiabiliser vos prédictions ?

Le DevOps appliqué au Machine Learning

Retour sur les premiers pas du Machine Learning

Livrer un modèle ML en Production a longtemps été un vrai challenge car les formats et processus de livraison variaient d’une plateforme à une autre. Par exemple, pour des modèles simples de régression linéaire, certains stockaient les coefficients des variables explicatives (X) dans une table SQL. On est ensuite passé à un repo git centralisé avec du code censé représenter le modèle, ou encore un fichier binaire dans un répertoire partagé. On avait donc du mal à lier le Build et le Run, et à raccourcir les cycles de livraison (et donc le time to market).

C’est pour y remédier que plusieurs initiatives open source, et notamment MLflow, ont vu le jour avec pour objectifs de :

  • Casser cette rigidité dans les process en y intégrant de l’agilité,
  • Standardiser les outils de packaging, de déploiement et de monitoring,
  • Tracker efficacement les expérimentations des data scientistes,
  • Faciliter la reproductibilité des résultats,
  • Faciliter la collaboration au sein des équipes Data Engineer et des différents Downstreams (Bi, data science, etc.).

Les composants du MLflow

La gestion du cycle de vie d’un projet Machine Learning avec MLflow est rendue possible grâce à ses principaux composants qui fournissent un niveau d’abstraction entre les zones de stockage multiformes et la façon d’accéder à la donnée technique (expériences, etc.). On en distingue 4 :

les composants du machine learning

  • MLflow Tracking : permet de sauvegarder et de consulter les expériences ;
  • MLflow Projects : gère le packaging pour garantir la reproductibilité sur toutes les plateformes ;
  • MLflow Models: gère de manière générale le format des modèles afin de simplifier le déploiement ;
  • Model Registry : gère de manière centralisée la collaboration des équipes autour du cycle de vie d’un modèle ML.

L’avantage d’un tel outil se trouve principalement dans sa capacité à s’affranchir des contraintes d’infrastructure par de l’abstraction. Par exemple, voici un modèle de code permettant de lancer une expérience et de logger tous les paramètres associés :

with mlflow.start_run(run_name="Finance Covid Experiment") as run:
    
    # We build and later train
    model = make_pipeline(PolynomialFeatures(2), Ridge())
    ...

    # We saved our fantastic model 
    mlflow.sklearn.log_model(model, "Regression")
    ...

    # some evaluation
    mse = mean_squared_error(y_test, predictions)
    r2 = r2_score(y_test, predictions)


    # And then we log everything we want 
    mlflow.log_metric("mse", mse)
    mlflow.log_metric("r2", r2)
    ...

Une fois votre expérimentation exécutée, tous vos collègues qui partagent le même Tracking Server pourront immédiatement la consulter, déterminer les conditions de réalisation (hyperparamètres, librairies, packaging, etc.) ainsi que les résultats obtenus. On est donc sur du collaboratif.

MLflow et DevOps

A l’image d’une application classique, un modèle ML ne s’affranchit pas des bonnes pratiques en termes de versioning de code, d’environnements de livraison (Dev, QA, Prod…), etc. La grande différence se situe principalement dans la gestion de ce cycle de livraison. Par son abstraction, MLflow offre une souplesse absolument fantastique lorsqu’il s’agit de versionner des modèles, de les distinguer par environnement, etc… grâce au Model Registry.

Retenez que :

  • Vos expérimentations sont enregistrées dans le backend store ;
  • Les modèles que vous enregistrez sont versionnés automatiquement ;
  • Les métriques enregistrées sont disponibles via la Tracking UI et peuvent vous servir pour établir des dashboards.

MLflow et Sécurité

Le fonctionnement d’un modèle ML est théoriquement imprévisible car il dépend fortement des données d’entrée, du type de prédiction et de la zone d’incertitude (erreur). Passer un modèle en production doit être un processus extrêmement sécurisé car les enjeux financiers qu’il engendre peuvent être conséquents. Sur Azure Databricks, MLflow intègre un template de gestion de permissions qui vous permet de gérer, à l’instar des Pull Requests, des demandes de mise en production d’un modèle.

Pour les utilisateurs Azure Databricks, la fonctionnalité de validation des modèles ML produits avant une mise en production est intégrée à la solution. Le Tech Lead Data Scientist n’aura plus à mettre en place un process de validation, mais simplement à utiliser cette fonctionnalité native.Un modèle de gestion de permissions assez détaillé a été mis en place pour justement pouvoir contrôler finement les actions dans le registry. Nous vous invitons à consulter la documentation Microsoft « Contrôle d’accès aux objets d’espace de travail ».

Machine learning et Sécurité

MLflow et Data science

La reproductibilité est un critère quasi indispensable lorsqu’on fait du Machine Learning. Par exemple, il est nécessaire de savoir quels ont été les paramètres associés à une expérience, quelles ont été les données d’entrée, les résultats paramétriques, etc. Encore une fois, MLflow vous simplifie toute cette gestion en ne fournissant qu’une seule abstraction qui fait tout. Cela vous évite donc de maintenir plusieurs outils à la fois pour le Build et le Run.

Aussi, cette reproductibilité au niveau expérience est simplifiée si vous stockez vos données au format Delta car vous bénéficierez automatiquement du versioning des données : vous pourrez ainsi associer une expérience ML à une version des données dans le temps.

Pour résumer, que votre backend storage soit sur un serveur interne, sur Azure, AWS ou GCP, votre code sera agnostique et, en quelque sorte, parlera uniquement MLflow. Cela est rendu possible grâce au composant MLflow Tracking.

Schéma composant MLflow tracking

MLflow, un outil de monitoring

“Change is the only constant in life”

Lorsque vous déployez en Production et que vous effectuez des prédictions en batch ou en real time, vous devez vous assurer que le modèle ML, bien qu’alimentant de nouvelles données, remplit bien les attentes business. Pour cela, différents niveaux d’attention sont à prévoir :

  • Concept Drift : focus sur les changements statistiques liés à la Variable cible (Y) ;
  • Data Drift : focus sur les changements statistiques liés aux variables explicatives (X) tels que la saisonnalité, les tendances, etc. ;
  • Upstream Data Changes : focus sur la valeur intrinsèque d’une feature. Par exemple, un changement brutal de devise d’une colonne Prix qui passe de l’euro au franc CFA.

Ces éléments vous permettront de faire du Monitoring actif, c’est-à-dire de déclencher par exemple un “ré-entrainement automatique” du modèle ML lorsqu’un Data Drift se produit. Avec MLflow, il est simple de mettre en place un tel système d’alerting et d’actions en se basant principalement sur des tables delta. Pour approfondir, nous vous invitons à découvrir le tutoriel de Joël Thomas, Architecte Data&AI Senior chez Databricks.

Retours d’expériences sur MLflow

L’expérience a prouvé que toutes les entreprises avec lesquelles nous avons travaillé autour de MLflow ont vu une nette amélioration dans les process de livraison : un changement qui constitue un gain de temps considérable car elles pouvaient alors se concentrer sur ce qui apporte réellement de la valeur et non plus sur les problématiques techniques de livraisons. Une étude intéressante du Forester démontre également que les data scientists ont gagné environ 25% en productivité en utilisant la solution Databricks.

MLflow, ce qu’il faut retenir

Nous avons pu constater quels étaient les challenges techniques à résoudre avant l’arrivée de MLflow et ce qu’on peut aujourd’hui attendre d’un outil moderne autour du Machine Learning.

Voici les points les plus importants à retenir :

  • Avant l’arrivée d’outils tel que MLflow, les itérations étaient longues du fait de la rigidité dans les process.
  • Les résultats du Run agissent sur les contraintes de Build, donc surveillez votre Prod.
  • MLflow vous permet d’aller rapidement en Production : pensez à faire valider les modèles produits par vos data scientists par un Lead Data scientist ou en automatique.
  • MLflow est multiplateforme et peut supporter différents scenarios (Cloud, Hybridation, etc.)
  • Rien n’est permanent, sauf le changement, alors activez le monitoring actif (détection de Drift)

Notre prochain article autour de MLflow vous fera découvrir à travers un cas d’utilisation concret, comment mettre en place cet outil dans un contexte Cloud ou On-Premise.

✍️ Cet article a été co-rédigé par nos experts data : Yann Bilissor (Cellenza) et Pierre Haddad (Databricks)