Aller au contenu principal

Process MLOps

Le MLOps est une approche qui combine Machine Learning DevOps et ingénierie logicielle afin d'automatiser, industrialiser et fiabiliser le déploiement, suivi et amélioration continue des modèles IA en production. Ce document décrit l'intégralité du processus MLOps sur la plateforme.

Ceci inclut la récupération des jeux de données bruts, leur préparation et leur annotation, puis l'entraînement et la mise en place du modèle pour l'inférence.

Les applications concernées par le MLOps sont :

Étapes principales​

  1. Récupération des jeux de données bruts
  2. Préparation pour l'annotation (ETL classique)
  3. Annotation avec Label Studio
  4. Préparation des annotations pour l'entraînement
  5. Démarrage de l'entraînement avec le suivi mlflow activé
  6. Facultatif Déploiement du modèle vers le registre mlflow si l'entraînement est satisfaisant
  7. Facultatif Copie du modèle d'un registre mlflow à un autre (exemple: bas vers prod)
  8. Déploiement sur un serveur d'inférence avec KServe. Les modèles personnalisés nécessiteront un conteneur personnalisé, mais seront tout de même déployés avec KServe.
  9. Facultatif Utilisation d'Open WebUI pour interagir avec le modèle déployé avec KServe.
  10. Suivi des utilisateurs pour détecter les points faibles du modèle.
  11. Mise à jour des jeux de données avec de nouvelles données lorsque le modèle présente des lacunes. 11. Revenez à l'étape 1 pour réentraîner le modèle.

Récupération des jeux de données​

Les jeux de données bruts doivent être stockés dans S3. Ils seront déposés dans un EDS 'source'.

La plateforme permet d'importer des données dans des EDS 'sources' par le biais du composant de data ingestion : import de données utilisateur ou import depuis une source externe.

Processus Data Ingestion

Préparation des données​

La plupart du temps, les jeux de données sont inutilisables tels quels, car ils ne sont pas adaptés à votre cas d'utilisation d'entraînement spécifique.

Exemples de préparation des données :

  • Adaptation des tâches et des pré-annotations au format Label Studio. Conversion de XML en JSON
  • Prétraitement des images étiquetées pour extraire leurs cadres de délimitation dans un fichier JSON afin de rendre les étiquettes utilisables par le script d'entraînement
  • Supprimez les étiquettes qui ne sont pas nécessaires à nos cas d'utilisation (par exemple, si nous avons des modèles de détection de voitures mais que nous ne sommes pas intéressés par les SUV, nous pouvons supprimer toutes les images et étiquettes de SUV)

Processus Data Preparation

Par exemple : un traitement du datapipeline (ou Dataiku) tranforme des données brutes pour en faire un jeu de données préparées dans un autre EdS s3 = un dataset.

Annotation avec labelStudio​

Prérequis

Une ou plusieurs instances de labelStudio peuvent être déployées, suivant les accès que l'on souhaite donner aux utilisateurs sur les projets et les données. Sachant qu'un utilisateur qui accède à un labelStudio est administrateur et peut donc tout faire dans son labelStudio ! Le bémol est que seul les utilisateurs ayant accès aux comptes technique des EDS (crédentials) pourront configurer les datasets (donc l'accès aux données - le cas échéant avec BEC).

Les données devant être annotées (données préparées) sont des fichiers disponibles dans un EdS de type s3.

L'administrateur accès et l'Administrateur données préparent l'environnement "labelStudio" dans lequel l'utilisateur qui doit annoter pourra travailler.

Procédure Déclarer projet & dataset

L'utilisateur peut ensuite annoter le dataset dans labelStudio.

Les consignes d'annotations, le contrôle des annotations et la validation des annotations sont réalisées en utilisant l'outil de gestion des taches.

Annotations

Un dataset annoté peut être représenté par 1 unique EdS s3 si les données et les annotations sont déposées dans le meme EdS (possible dans le bac a sable). Sinon, un dataset annoté et représenté par 1 EdS s3 contenant les données et 1 EdS s3 contenant les annotations.

Versions des datasets

La gestion des versions des datasets se fait via la création de différents EdS s3. Ces gestes sont réalisés par l'Administrateur données.

Les versions des annotations sont elles aussi gérées via la création des différents EdS S3.

Une copie du contenu d'un EdS est possible via les fonctions de sauvergardes et restauration des EdS. C'est l'Administrateur données qui doit gérer la cohérence des sauvegardes et restaurations quand cela est demandé par l'utilisateur qui effectue les annotations, ou le data X qui prépare les données.

Entrainement des modèles​

Les modèles sont mis au point et entrainés via du code exécuté dans Jupyter ou dans le datapipeline (brique Python Inline) par les utilisateurs dataXX en utilisant les API MLFlow (les projets d’entraînement MLFlow sont accessibles par tous les utilisateurs en lecture et en modification uniquement par le créateur du projet - selon les droits affectés - voir la note "Instances de MLFlow" ci-dessous).

Procédure Utiliser un notebook

Les commandes utilisées dans le code d'entrainement vont déposer les résultats des entrainements dans MLFlow. Le data X peut alors consulter les résultats de ses entraînements dans l’IHM MLFlow et optimiser son modèle en réalisant des itérations (les modèles créés sont enregistrés dans la registry de modèle MLFLow). Le Data X publie le modèle le plus abouti dans MLFlow, candidat au déploiement depuis son JupyterHub ou un traitement de tests.

Il est possible de trouver des exemple complet d'entrainement d'un modèle puis son chargement dans MLflow ici

remarque

Pour interagir avec une instance de MLFlow, l'URI du service MLFlow doit être précisée. Elle est connue de l'administrateur système qui a déployé l'instance.

Copie du modèle d'un registre mlflow​

Si l'on souhaite séparer les modèles en cours de mise au point dans le bac à sable des modèles de production, il faut instancier 2 MLFlow pour notre zone métier. 1 instance qui servira pour le bac a sable et une instance qui servira pour la production. L'accès à ces instances sera donnée aux utilisateurs qui en ont besoin via l'affectation des groupes keycloak associés (groupes créés au moment du déploiement de l'instance).

Pour copier un modèle MLFlow d'une instance à une autre un Helm chart mlflow-migrate-model est disponible et peut-être exécuté depuis rancher par un administrateur, son utilisation est décrite ici

Mise en service d'un modèle​

  • L'Administrateur Traitements importe le modèle depuis le Bac à sable vers la registry de modèle de prod :
    • Il faut utiliser le Helm chart inference-service comme décrit ici
  • L'Intégrateur instancie l’application avec le modèle dans l’EID
  • Le Développeur teste son modèle (avec l’aide d’un data scientist dans Jupyter ou d’une application métier)
  • L'Administrateur Applications déploie en production l’application une fois le modèle validé par l'Intégrateur

Import d'un modèle​

  • Administrateur Données créé un espace de stockage S3 dans le bac à sable (utilisable avec l’IDU)
  • Administrateur Traitements importe avec l’IDU le modèle d’IA :
  • Data Ingénieur avec Jupyter, créé un projet dans MLFlow et importe le modèle depuis S3 avec les API MLFlow

Export d'un modèle​

Export d'un modèle