PORTALITE
New! Démarquez-vous en passant des tests de personnalité gamifiés. Lancez-vous dès maintenant, en découvrant les trois tests disponibles gratuitement!
MISSION
recetter le fonctionnement de la plateforme MLOps en mode portage : fonctionnalités détaillées ci-dessous
- démarrer la migration des projets de data science analytics sur la plateforme de portage. Par migration des projets de data science existants, on entend le portage des étapes
- d'analyse
- d'entraînement/test/validation des modèles
- de mise en production
- et de monitoring des modèles
ces deux objectifs peuvent être menés conjointement, la migration des use-cases existants représentant une opportunité de recette en elle-même.
La recette inclut notamment les points suivants :
- recette de la workstation :
- de ses configurations et containers préparamétrés, qui doivent notamment :
- proposer :
- un ide fonctionnel : Rstudio server, jupyterlab ou code-oss au choix du datascientist
- tout le socle permettant l'utilisation des binaires métiers (Python, R, Java, git) ainsi que l'installation / compilation des packages requis par le projet
- être démarrés avec :
- un montage fuse d'un ou plusieurs buckets GCS en guise de stockage persistant non rattaché à la VM sous-jacente
- une authentification GCP héritée de la connexion aux workstations via la console GCP, 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)
Environnement de travail
les technologies utilisées par la plateforme seront :
- GCP Workstations : l'environnement de développement - notebooks/Rstudio Server/codeOSS Server
PROFIL RECHERCHÉ
Non renseigné
PORTALITE
Technologies de l'Information et de la Communication
Paris
Temps partiel (≤ 32 heures)
Non renseigné
26/08/2025
Freelance