CQFV: ce qu’il faut versionner (dans une approche MLOps)

Avant de nous pencher sur le domaine du Machine Learning, imaginons tout d’abord le code d’une application lambda. Ses développeurs auront le réflexe de pousser leur code sur un gestionnaire de versions. Lors d’un processus d’industrialisation, le code d’une s’exécutera successivement, par un processus de déploiement continu (CD), sur une infrastructure composées de différents environnements : qualification, pré-production, production. Pour quitter définitivement le travers du “it works on my laptop”, il est attendu que ce code fonctionne, à l’identique, jusqu’en production.

Imaginons maintenant que l’environnement de production connaisse un désastre (des machines qui partent en fumée, cela n’arrive pas qu’aux autres…), il faudra tout reconstruire et pouvoir reproduire l’état avant désastre. Ceci sera possible si l’on dispose des éléments suivants, accompagné du dernier backup des données :

Cette approche inspire tout naturellement les data scientists et data engineers dans leur démarche d’industrialisation du Machine Learning, avec un objectif (bien connu dans le domaine de la qualité “6 sigma”) : la reproductibilité. Il s’agit en effet de s’assurer qu’un modèle d’apprentissage, interrogé avec certaines valeurs X, donnera toujours la même réponse Y.

La littérature récente autour du MLOps définit le triplet suivant comme les éléments indispensables à versionner :

En effet, il est important de “figer” les données au moment de l’entrainement du modèle. Ceci permettra de revenir sur la compréhension de cet entrainement ou de vérifier les transformations réalisées sur les différentes features du modèle. Un outil comme DVC permettra de répondre à ce besoin. Une autre piste sera d’utiliser le format Delta, qui se compose de fichiers compressés et partitionnés Parquet, accompagnés d’un fichier de logs des évolutions.

Pour réaliser le suivi de versions des modèles, nous pourrons utiliser un outil comme MLFlow (ou l’une de ces alternatives) et son model registry. Nous y retrouverons l’artefact illustré ci-dessous. Le modèle est alors un fichier binaire sérialisé. Il est accompagné des requirements : version (précise !) des packages nécessaires.

Mais pouvons-nous ainsi assurer la reproductibilité parfaite d’une prévision ? Oui, à condition de d’interroger le modèle de manière similaire. Cette interrogation a bien souvent lieu, dans un contexte de production, au travers d’une application telle qu’un service Web, offrant une interaction grâce à de commandes de type (API) REST. Pour un tel mode de serving, nous pourrons par exemple nous pencher sur des outils comme Fast API ou des librairies comme Django ou Flask.

Ce service pourra être déployé au moyen d’un image Docker, qui réalisera la préparation des nouvelles données (transformations préalables comme une standardisation) puis la prévision par le modèle. Cette image va donc contenir le modèle prédictif ainsi que les packages listés dans les requirements. Son processus de build peut prendre du temps et faire appel à des ressources sur Internet, dont la stabilité n’est pas garantie (patchs correctifs, obsolescence, arrêt du fournisseur…). Il est donc fortement recommandé de stocker également ces images qui seront la “touche finale” de notre architecture ML, au sein d’un container registry.

Voici donc le schéma final de notre objectif de versioning :

qui se déclinera de la manière suivante, en intégrant une démarche DevOps :

Nous pouvons alors répondre aux scénarios suivants :

• un modèle développé par un.e Data Scientist pourra être testé et déployé de manière automatique
• un modèle challenger pourra être testé dans un environnement qui ne sera pas celui de production
• le modèle challenger pourra remplacer l’actuel modèle de production sans interruption de service
• le précédent modèle de production pourra être rétabli si le nouveau modèle déployé ne donne pas satisfaction (il suffira de déployer le container versionné !)
• il sera possible de retrouver le modèle à l’origine d’une prévision (par exemple contestée dans le cadre législatif donné par la RGPD…)
• il sera possible de retrouver le jeu de données à l’origine d’un modèle pour constituer la baseline d’une drift detection (référence permettant de comprendre la dérive d’un modèle de Machine Learning : dérive de la distribution des données en entrée, dérive du concept, etc.)

*** Avertissement : la suite de cet article propose une implémentation de cette stratégie dans un cloud public dont la réversibilité ne sera pas garantie. ***

Une plateforme comme Azure Machine Learning propose l’intégralité de ces services, en lien avec un repository d’images dans Azure Container Registry et en interaction avec un repository de code contenu dans Azure DevOps (n’oublions pas l’importance des pipelines de CI/CD). Les jeux de données et artefacts des modèles sont sauvegardés sur un compte de stockage Azure Storage Account.