Modèle de maturité des opérations de Machine Learning

Azure Machine Learning

L’objectif de ce modèle de maturité est d’aider à clarifier les principes et les pratiques en matière d’opérations de Machine Learning (MLOps). Le modèle de maturité montre l'amélioration continue dans la création et le fonctionnement d'un environnement d'application de machine learning au niveau de la production. Vous pouvez l’utiliser comme mesure pour établir les exigences progressives nécessaires à la mesure de la maturité d’un environnement de production de machine learning et de ses processus associés.

Modèle de maturité

Le modèle de maturité MLOps aide à clarifier les principes et les pratiques de développement DevOps (Development Operations) nécessaires à l’exécution d’un environnement MLOps réussi. Il est destiné à identifier les lacunes dans la tentative d’implémentation d’un tel environnement par une organisation existante. C’est également un moyen de vous montrer comment augmenter la capacité de votre MLOps par incréments au lieu de vous précéder des exigences d’un environnement entièrement mature. Utilisez-le comme guide pour :

Estimer l’étendue du travail pour les nouveaux engagement.
Établir des critères de réussite réalistes.
Identifier les livrables que vous fournirez à la fin de l’engagement.

Comme pour la plupart des modèles de maturité, le modèle de maturité MLOps évalue qualitativement les personnes/culture, les processus/structures et les objets/technologies. Au fur et à mesure que le niveau de maturité augmente, la probabilité augmente, car les incidents ou les erreurs entraînent des améliorations de la qualité des processus de développement et de production.

Le modèle de maturité MLOps englobe cinq niveaux de capacité technique :

Level	Description	Points forts	Technology
0	Non-MLOps	Difficulté à gérer le cycle de vie complet des modèles de machine learning Les équipes sont hétérogènes et les mises en production sont pénibles La plupart des systèmes existent en tant que « boîtes noires », peu de commentaires pendant/après le déploiement	Builds et déploiements manuels Test manuel du modèle et de l’application Aucun suivi centralisé des performances du modèle La formation du modèle est manuelle
1	DevOps mais non-MLOps	Les mises en production sont moins pénibles que non-MLOps, mais s’appuient sur l’équipe de données pour chaque nouveau modèle Le retour sur les performances d’un modèle en production est toujours limité Résultats de trace/reproduction difficiles	Builds automatisés Tests automatisés pour le code de l’application
2	Formation automatisée	L’environnement de formation est entièrement géré et traçable Modèle facile à reproduire Les versions sont manuelles, mais à faible friction	Apprentissage automatisé des modèles Suivi centralisé des performances du modèle de formation Gestion des modèles
3	Nouveaux outils de modèle de déploiement	Les mises en production sont à faible friction et automatiques Traçabilité complète du déploiement vers les données d’origine Ensemble de l’environnement géré : formation > test > production	Test intégré A/B des performances du modèle pour le déploiement Tests automatisés pour tout le code Suivi centralisé des performances du modèle de formation
4	Opérations automatisées MLOps complètes	Système complet automatisé et facilement surveillé Les systèmes de production fournissent des informations sur la façon d’améliorer et, dans certains cas, automatiquement, les nouveaux modèles Approche d’un système sans temps mort	Formation automatisée et test des modèles Commentaires, métriques centralisées à partir d’un modèle déployé

Les tableaux qui suivent identifient les caractéristiques détaillées de ce niveau de maturité des processus. Le modèle continuera à évoluer. La dernière mise à jour de version a été effectuée en janvier 2020.

Niveau 0 : Non-MLOps

Personnes	Création de modèle	Mise en production du modèle	Intégration des applications
Scientifiques des données : en silo, pas en communication régulière avec l'équipe principale Ingénieurs des données (si existe) : en silo, pas en communication régulière avec l'équipe principale Ingénieurs logiciels : en silo, réception du modèle à distance des autres membres de l’équipe	Données collectées manuellement Le calcul n’est probablement pas géré Les expériences ne sont pas suivies de manière prévisible Le résultat final peut être un fichier de modèle unique transmis manuellement avec les entrées/sorties	Procédure manuelle Le script de scoring peut être créé manuellement après les expériences, et non sous contrôle de version Mise en version gérée par un scientifique des données ou un ingénieur de données uniquement	Très tributaire de l’expertise des scientifiques de données pour implémenter Mises en production manuelles à chaque fois

Niveau 1 : DevOps Non-MLOps

Personnes	Création de modèle	Mise en production du modèle	Intégration des applications
Scientifiques des données : en silo, pas en communication régulière avec l'équipe principale Ingénieurs des données (le cas échéant) : en silo, as en communication régulière avec l'équipe principale Ingénieurs logiciels : en silo, réception du modèle à distance des autres membres de l’équipe	Le pipeline de données collecte des données automatiquement Le calcul peut être géré ou pas Les expériences ne sont pas suivies de manière prévisible Le résultat final peut être un fichier de modèle unique transmis manuellement avec les entrées/sorties	Procédure manuelle Le script de scoring peut être créé manuellement après les expériences, probablement sous contrôle de version Est transmis aux ingénieurs logiciels	Des tests d’intégration de base existent pour le modèle Très tributaire de l’expertise des scientifiques de données pour implémenter le modèle Mises en production automatisées Le code d’application contient des tests unitaires

Niveau 2 : Formation automatisée

Personnes	Création de modèle	Mise en production du modèle	Intégration des applications
Scientifiques des données : Travailler directement avec les ingénieurs de données pour convertir le code expérimentation en scripts/travaux reproductibles Ingénieurs de données : Travailler avec les ingénieurs de données Ingénieurs logiciels : en silo, réception du modèle à distance des autres membres de l’équipe	Le pipeline de données collecte des données automatiquement Calcul géré Suivi des résultats de l’expérience Le code de formation et les modèles résultants sont contrôlés par version	Version manuelle Le script de score est contrôlé par la version avec les tests Mise en production gérée par l’équipe d’ingénierie logicielle	Des tests d’intégration de base existent pour le modèle Très tributaire de l’expertise des scientifiques de données pour implémenter le modèle Le code d’application contient des tests unitaires

Niveau 3 : Modèle de déploiement automatisé

Personnes	Création de modèle	Mise en production du modèle	Intégration des applications
Scientifiques des données : Travailler directement avec les ingénieurs de données pour convertir le code expérimentation en scripts/travaux reproductibles Ingénieurs de données : Collaboration avec les scientifiques des données et les ingénieurs logiciels pour gérer les entrées/sorties Ingénieurs logiciels : Collaboration avec les ingénieurs des données pour automatiser l’intégration de modèle dans le code d’application	Le pipeline de données collecte des données automatiquement Calcul géré Suivi des résultats de l’expérience Le code de formation et les modèles résultants sont contrôlés par version	Mise en production automatique Le script de score est contrôlé par la version avec les tests Mise en production gérée par le pipeline de livraison continue (CI/CD)	Tests d’unité et d’intégration pour chaque mise en production de modèle Moins tributaire de l’expertise des scientifiques de données pour implémenter le modèle Le code d’application contient des tests unitaires/d’intégration

Niveau 4 : Reformation automatisée MLOps complète

Personnes	Création de modèle	Mise en production du modèle	Intégration des applications
Scientifiques des données : Collaboration directe avec les ingénieurs de données pour convertir le code expérimentation en scripts/travaux reproductibles. Collaboration avec des ingénieurs logiciels pour identifier des marqueurs pour les ingénieurs des données Ingénieurs de données : Collaboration avec les scientifiques des données et les ingénieurs logiciels pour gérer les entrées/sorties Ingénieurs logiciels : Collaboration avec les ingénieurs des données pour automatiser l’intégration de modèle dans le code d’application. Implémentation de la collecte des métriques après le déploiement	Le pipeline de données collecte des données automatiquement Reformation déclenchée automatiquement en fonction des mesures de production Calcul géré Suivi des résultats de l’expérience Le code de formation et les modèles résultants sont contrôlés par version	Mise en production automatique Le script de scoring est contrôlé par la version avec les tests Mise en production gérée par le pipeline d’intégration continue et CI/CD	Tests d’unité et d’intégration pour chaque mise en production de modèle Moins tributaire de l’expertise des scientifiques de données pour implémenter le modèle Le code d’application contient des tests unitaires/d’intégration

Modèle de maturité des opérations de Machine Learning