L'équipe IA SFR Analytics se dote d'un nouvel outil d'entraînement, de serving et de monitoring de ses modèles. Cet outil, nommé "Plateforme MLOps" en interne, doit être livré en juin et s'appuyer sur un panel de services proposés à la fois par GCP et par l'IT SFR. Plus précisément, les technologies utilisées par la plateforme seront : - GCP Workstations : l'environnement de développement - notebooks/Rstudio Server/codeOSS Server - GCP Bigquery - GCP GCS - GCP Vertex - SFR Gitlab - SFR Harbor (container registry) - SFR Nexus (package manager) - SFR Airflow (ordonnanceur) La plateforme MLOps comprendra deux modes d'utilisation : - Portage d'applications existantes - MLOps mainstream GCP La mission actuelle vise à : - recetter la plateforme dans son volet de portage - démarrer la migration des projets de Data Science SFR Analytics sur cette plateforme de portage A date, l'équipe administre trois serveurs physiques on-prem et y fait tourner l'ensemble de ses projets de data science. Les technos utilisées pour chaque étape du workflow de ML sont détaillées ci-dessous : - Analyse exploratoire / entraînement de modèles : - Le data scientist démarre un container docker sur l'un des serveurs linux. - Ce container expose un Rstudio server (équivalent notebook) auquel le data scientist se connecte. - A partir de cet environnement de travail, le data scientist peut : - installer de manière persistante les packages R/Python dont il a besoin pour son projet - se connecter à notre DWH Bigquery pour requêter, récupérer ou y remonter des données - exploiter de manière non capée les cpus et la ram de la machine hôte - entraîner des modèles - analyser leur performance - sauvegarder sur disque persistant le ou les modèles retenus ainsi que la base d'apprentissage et les fichiers de QOD associés (distributions des variables de la base d'apprentissage) - préparer le ou les scripts d'inférence du modèle, qui, au sein d'un container similaire, loaderont le modèle sauvegardé, réaliseront l'inférence en batch, et remonteront les outputs du modèle (probas et métriques de QOD des variables d'entrée notamment) sur Bigquery et/ou sur fichiers locaux - pusher son code sur un serveur Gitlab on-prem pour partage et versioning - Inférence du modèle : - Un container identique au container d'apprentissage mais dépourvu de Rstudio server est démarré de manière automatique par un worker Airflow afin de réaliser un batch d'inférence. Les dossiers contenant les packages, les scripts et les artefacts nécessaires à l'inférence sont montés au run dans le container. - Le container exporte ses résultats (probas et métriques de QOD des variables d'entrée notamment) sur BigQuery et/ou sur disque. - Monitoring : - Une application R shiny portée par un shiny-server accède aux fichiers locaux et/ou aux données remontées sur Bigquery par les jobs d'inférence et affiche : - le suivi des distributions des inputs du modèle - l'évolution des performances à froid du modèle (dans le cas des modèles supervisés et une fois que l'on dispose de suffisamment de recul temporel) Dans le fonctionnement en mode "portage", les modifications sont les suivantes : - Analyse exploratoire / entraînement de modèles : - le container de développement / exploration / training ne tourne plus sur nos machine on-premise mais sur GCP workstations - il ne sert plus uniquement une interface Rstudio Server mais également un jupyterlab et un code-oss (au choix du data scientist) - les artefacts, dont les binaires de modèles entraînés, les packages installés et les autres fichiers créés depuis notre IDE web ne sont plus stockés sur nos serveurs mais sur un bucket GCS - le lien vers Gitlab demeure fonctionnel pour le versioning des codes, mais Gitlab devient également responsable du déploiement du traitement d'inférence : - dans un projet GCP "lab" dédié au prototypage, accessible depuis les workstations et depuis la chaîne de ci Gitlab. - dans un projet GCP "run" dédié à la production, accessible uniquement par la ci/cd Gitlab. - Inférence du modèle : - le container exécutant le traitement batch reste démarré par un appel du serveur Airflow, mais le service Airflow SFR Analytics est remplacé par le service Airflow de l'IT SFR - le container n'est donc plus démarré sur nos serveurs mais sur un Cloud Run en mode job - ce Cloud Run peut être rattaché aux environnements "lab" ou "run" - Monitoring : - l'application shiny de monitoring n'est plus servie par un shiny-server on prem mais est conteneurisée et portée par un Cloud Run tournant en mode service - l'application shiny de monitoring ne lit plus ses données depuis les disques de nos serveu