Machine Learning et GCP : Expérimentation, déploiement et prédiction

Chayma Mesbahi
neoxia
Published in
7 min readAug 4, 2020

Pour qu’un “produit data” complet puisse voir le jour, un workflow de machine learning (ML) doit être mis en place. Ce workflow inclut les étapes de récupération, préparation & analyse des données, entraînement & évaluation d’un modèle, puis le déploiement en production de ce modèle.

La gestion, le suivi et l’automatisation d’un workflow ML peuvent être difficiles, coûteux et chronophages. Toutefois, à travers AI Platform, Google Cloud fournit un écosystème permettant d’adopter une approche MLOps facile et rapide à mettre en place pour les projets ML.

Dans cet article, nous vous présenterons donc les bonnes pratiques que nous suivons chez Neoxia pour créer un pipeline ML reproductible, facilitant le suivi des différentes expériences menées sur les données et les modèles, et pour mettre un modèle en production.

Étape 1 : pipeline et suivi des expérimentations

Par nature, la phase de développement d’un modèle de machine learning est empirique. L’enjeu d’une approche MLOps est de suivre les différentes étapes de développement, tout en veillant à leur reproductibilité.

Pour répondre à ce challenge, AI Platform propose un système de pipeline hautement reproductible permettant un suivi détaillé de chaque expérience menée par un data scientist à l’aide de ses outils préférés.

Ainsi, AI Platform Pipeline permet l’utilisation de Kubeflow Pipelines pour mettre en place des workflows ML. Kubeflow est une panoplie d’outils open source basés sur Kubernetes qui permet d’orchestrer, de composer et d’automatiser des tâches ML. Kubeflow Pipelines est une de ses fonctionnalités qui permet le déploiement de workflows ML reproductibles et scalables.

Kubeflow Pipelines propose aussi une interface ergonomique qui permet de suivre et de comparer les différentes expériences historisées d’un même workflow ; une “expérience” est définie comme une itération d’un workflow. Les expériences sont reproductibles, et un data scientist pourra donc tester son modèle à plusieurs reprises et décider plus tard quelle expérience était la meilleure afin de l’utiliser comme source principale pour les prochaines étapes.

Cas d’usage : la prédiction du diabète

À titre d’exemple, nous allons créer un workflow ML simple en utilisant AI Platform Pipeline pour mettre en exergue les avantages d’une approche MLOps dans le développement d’un produit data.

Le dataset présente certains diagnostics pour des patients ayant des profils différents. L’objectif est de prédire si un patient souffre ou non de diabète.

Le workflow construit contient trois étapes :

  • Download and split : récupération et nettoyage des données puis division des données entre entraînement et test.
  • Train : entraînement d’un modèle en précisant ses paramètres et les données nécessaires.
  • Test : test et évaluation du modèle entraîné à l’aide des données de test.

Chaque étape est représentée par un “component”. Un component est une tâche ML conteneurisée. Elle est analogue à une fonction dans le sens où elle a un nom, des paramètres, des valeurs de retour et un corps.

Ces components sont ordonnancés dans un pipeline :

À chaque exécution du pipeline, une ligne s’ajoute au tableau de bord de l’historique des expériences :

Tableau de bord des expériences sur Kubeflow Pipelines

Il est possible de rentrer dans les détails d’une expérience en particulier. Le pipeline d’une expérience est présenté sous forme de DAG (directed acyclic graph) indiquant l’état de chaque étape :

DAG de l’experience diabete_pipeline 2020–07–29 09–59–26

Pour avoir plus d’information de l’étape Train (par exemple l’emplacement des entrées et sorties), nous pouvons naviguer dans les onglets qui correspondent à cette étape :

Détails de la tâche Train du pipeline de l’expérience diabete_pipeline 2020–07–29 09–59–26

Une fois le modèle créé et mis en production (nous verrons comment par la suite), ce pipeline peut être réutilisé pour mettre en place un entraînement continu. Le continuous testing (CT) permet de toujours avoir en production un modèle performant et ainsi de prévenir d’un éventuel drifting (phénomène de perte de précision qui peut se produire lors d’une modification des données d’entrée, ou des propriétés statistiques de la variable cible).

En MLOps, on peut ainsi souvent parler de CI/CD/CT permettant de valider la qualité des données, du code, du modèle mais aussi de déployer le pipeline ML et les nouvelles versions du produit data.

Étape 2 : déploiement sur AI Platform

Une fois le modèle créé et exporté au bon format, il faut le déployer pour pouvoir l’utiliser lors d’une prédiction.

Pour ce faire, AI Platform propose un outil permettant de déployer rapidement et simplement le modèle. Ainsi, sur Google Cloud Platform (GCP), il est possible de créer un modèle en tant que ressource AI Platform, qui servira à exposer notre classificateur pour pouvoir l’utiliser grâce à l’API d’AI Platform.

Chaque modèle AI Platform peut posséder plusieurs versions. L’objectif des versions d’un modèle est de pouvoir garder une trace de tous les modèles utilisés dans un projet, et réutiliser une ancienne version si elle possède de meilleures performances que la dernière en date.

Par exemple, si la dernière version a connu un drift qui a détérioré ses performances ou un problème lors de l’entraînement, le système de versionnage permet de revenir à un modèle antérieur qui sera peut-être plus juste dans ses précisions.

Tableau de bord des versions de modèles sur AI Platform

Dans la pratique, le déploiement d’un modèle sur AI Platform se déroule en plusieurs étapes :

  • Télécharger vers Google Cloud Storage (GCS) de l’export du modèle créé lors de l’entraînement ;
  • Lors du premier déploiement, créer une ressource “modèle” AI Platform ;
  • Créer une nouvelle version du modèle en indiquant le chemin vers le modèle.
Description de la v2 du modèle

Dans notre exemple, le déploiement d’une nouvelle version a été fait manuellement pour faciliter la compression, mais dans un véritable cadre MLOps la création de nouvelle version doit être réalisée de manière automatisée grâce à un planificateur.

Étape 3 : effectuer des prédictions

Notre modèle étant à présent déployé sur AI Platform, nous pouvons l’utiliser pour effectuer des prédictions. Il existe plusieurs types de prédiction, dont les prédictions en ligne et par lot.

Prédiction en ligne

La prédiction en ligne permet d’effectuer des prédictions sur un petit volume de données grâce à un appel API. Le seul prérequis est de formater correctement les données d’entrée dans le corps de la requête de prédiction.

Prédiction par lot

Lorsque la volumétrie devient trop importante, la prédiction en ligne atteint ses limites. AI Platform permet alors de créer des tâches de prédiction sur des données volumineuses stockées dans Google Cloud Storage. Pour ce faire, il suffit de créer un job en utilisant l’API AI Platform sachant qu’un job de prédiction par batch possède plusieurs arguments obligatoires :

  • Le chemin GCS vers les données d’entrée
  • Le chemin GCS où stocker les prédictions
  • Le modèle et la version à utiliser.

Prédictions personnalisées

Dans certains cas, il peut être nécessaire de faire des prédictions plus personnalisées ; on peut alors utiliser des routines personnalisées. Une routine personnalisée est un type de modèle qui permet à la fois de spécifier la méthode de chargement du modèle, mais aussi la méthode de prédiction. Ainsi, pour créer une routine personnalisée, on doit implémenter une classe Python qui va définir l’output d’une prédiction. Cela permet par exemple de renvoyer le pourcentage d’une classe, relier une classe à un mapping, etc.

En conclusion

Un produit data est le fruit d’un workflow ML qui peut être entièrement géré dans l’écosystème AI Platform proposé par Google Cloud Platform.

La phase d’expérimentation se fait sur Kubeflow Pipelines qui permet de composer, orchestrer et automatiser les tâches ML. AI Platform assure aussi la phase de déploiement et de mise en production rapidement et à moindre coût.

Toutefois, le déploiement et la mise en production ne sont que le début d’une nouvelle mission qui est la maintenance et le suivi de la performance mais aussi de l’efficacité du produit data. En effet, les modèles ML peuvent perdre en précision et en pouvoir prédictif avec le temps. Une détection automatique de ce drifting et un rafraîchissement du modèle deviennent donc indispensables ; des défis grandement simplifiés par l’usage d’AI Platform.

Article écrit par Chayma Mesbahi et Florent Geslin

Références:

https://databricks.com/fr/blog/2019/09/18/productionizing-machine-learning-from-deployment-to-drift-detection.html

https://www.kubeflow.org/docs/

https://cloud.google.com/ai-platform/pipelines/docs/introduction?hl=fr

Données de: https://www.niddk.nih.gov/

--

--