Les ingénieurs en machine learning déplorent souvent que, d’une manière générale, la mise en production des applications de machine learning (ML), de deep learning (DL) et d’IA soit problématique. Nombre d’entre eux attesteraient qu’un pourcentage important — estimé à 90 % — des modèles de ML ne voient jamais le jour en production.
Examinons quatre bonnes pratiques pour éviter ces problèmes. Fondées sur les tendances du secteur, la littérature professionnelle et les bonnes pratiques MLOps codifiées, ces quatre bonnes pratiques amélioreront le processus de déploiement des modèles en production.
À lire aussi : Top AI Software
1) Préparer correctement sa stratégie de données
Les données sont complexes et imparfaites. Elles sont complexes parce qu’elles varient par leur forme et leur format : par lots ou en flux, structurées, non structurées ou semi-structurées. Elles sont imparfaites car elles comportent souvent des valeurs manquantes ou erronées. Aucun modèle de deep learning ou d’IA n’a de valeur sans des données volumineuses, nettoyées et enrichies par la création de variables.
Vous avez besoin d’un stockage de données robuste pour traiter les big data nécessaires à la construction de modèles précis. Un data lake moderne stocke à la fois les données structurées et non structurées. Il possède les propriétés suivantes :
- Fournit des transactions ACID afin que plusieurs lecteurs et rédacteurs puissent mettre à jour et lire les données sans contention ni conflit, ce qui permet l’exécution simultanée de tâches ETL (extraction, transformation et chargement), ainsi que des insertions et mises à jour constantes.
- Stocke les données dans un format ouvert tel que Parquet, JSON, ou CSV, ce qui permet aux frameworks populaires de deep learning d’accéder aux données de manière ouverte et efficace.
- Conserve les données structurées sous forme de tables qui peuvent être versionnées et respecter un schéma, ce qui garantit la reproductibilité et la traçabilité des modèles.
- Offre un accès rapide et interrogeable aux différents types de données (étiquettes, images, vidéos, texte, etc.), permettant aux ingénieurs en machine learning d’extraire les bons jeux de données pour le problème métier approprié.
Un data lake moderne comme système de stockage des données.
Sans un stockage de données cohérent servant de source canonique, fiable et nettoyée, pour l’ensemble de vos modèles de ML destinés à l’entraînement et à l’inférence, vous vous heurterez à votre premier écueil lié aux « données ». Cela vaut quel que soit le framework de deep learning utilisé — ce qui nous amène à la considération suivante.
À lire aussi : DevOps, Low-Code et RPA : avantages et inconvénients
2) Utiliser des frameworks éprouvés et largement adoptés
De même que de bonnes données produisent de bons modèles, les boîtes à outils et frameworks de deep learning largement adoptés favorisent aussi de bons résultats. Aucun professionnel du ML/DL ne contesterait que PyTorch, PyTorch Lightning, TensorFlow, HuggingFace, Horovod, XGBoost, ou MXNet sont des frameworks populaires pour construire des modèles de deep learning évolutifs. En plus d’être largement utilisés, ils sont devenus les frameworks de référence pour créer des applications sophistiquées de deep learning et d’IA.
Adoptez ces frameworks parce que :
- Ils disposent d’une vaste communauté d’utilisateurs, d’une documentation abondante, ainsi que de tutoriels et d’exemples pour apprendre.
- Ils prennent en charge l’entraînement et l’inférence sur du matériel moderne accéléré (processeurs, GPU, etc.).
- Ils ont été éprouvés en production (et sont utilisés par des entreprises reconnues).
- Ils sont intégrés nativement à Ray, un framework open source généraliste émergent destiné à créer et mettre à l’échelle des applications d’IA distribuées.
- Ils disposent de liaisons API Python, le langage de facto du deep learning.
- Ils s’intègrent à MLflow, KubeFlow, TFX, SageMaker, et à Weights & Biases pour le provisionnement et le déploiement des modèles, ainsi que pour l’orchestration des pipelines de modèles en production.
Intégrations des frameworks ML/DL avec Ray et les registres de modèles.
Ne pas utiliser les frameworks éprouvés, bien intégrés aux outils open source populaires pour le cycle de développement et la gestion des modèles ou pour l’entraînement distribué à grande échelle, est le meilleur moyen de tomber dans un nouvel écueil : les mauvais outils et frameworks. La nécessité d’un cycle de vie du développement des modèles nous conduit à expliquer pourquoi il faut suivre l’entraînement des modèles à l’aide d’un registre de modèles.
À lire aussi : Techniques de data mining
3) Suivre l’entraînement des modèles avec un registre de modèles
Le paradigme du cycle de vie du développement des modèles diffère de celui du cycle de vie général du développement logiciel. Le premier est itératif, expérimental, fondé sur les données et guidé par les métriques. Plusieurs facteurs influencent la réussite du modèle en production :
- Les métriques mesurées du modèle sont-elles exactes ? Un registre de modèles suivra toutes les métriques et tous les paramètres pendant l’entraînement et les tests, afin que vous puissiez les examiner et les évaluer.
- Puis-je utiliser plusieurs frameworks de DL pour obtenir le meilleur modèle ? Aujourd’hui, les registres de modèles prennent en charge plusieurs frameworks afin d’enregistrer les modèles comme artefacts pour les déploiements.
- Les sources de données étaient-elles fiables et leur volume suffisant pour représenter un échantillon général ? C’est le résultat d’une bonne stratégie de données.
- Pouvons-nous reproduire le modèle avec les données utilisées pour l’entraînement ? Le registre de modèles peut stocker des métadonnées sous forme de références vers les tables de données du stockage de données. L’accès aux données d’entraînement originales et aux métadonnées permet de reproduire un modèle.
- Pouvons-nous suivre la lignée d’évolution d’un modèle — du développement au déploiement — à des fins de traçabilité et de responsabilité ? Les registres de modèles suivent le versionnage de chaque exécution d’expérience, afin que vous puissiez extraire une version exacte du modèle entraîné avec tous ses paramètres et métriques d’entrée et de sortie.
Le suivi des expériences menées sur les modèles et la conservation de tous les aspects de leurs résultats — métriques, paramètres, tables de données et artefacts — vous donnent l’assurance de déployer le bon modèle, et le meilleur, en production. Ne pas disposer d’un modèle de production fondé sur les données et les métriques constitue un autre écueil à éviter. Mais cela ne suffit pas : observer le comportement et les performances des modèles en production est aussi important que le suivi des expériences.
À lire aussi : Techniques de data mining
4) Observer le modèle en production
L’observabilité des modèles en production est impérative. Elle est souvent reléguée au second plan — mais c’est prendre le risque de rencontrer un nouvel écueil. Elle devrait être prioritaire. Les modèles de ML et de DL peuvent se dégrader ou dériver au fil du temps pour plusieurs raisons :
- Dérive des données et du concept du modèle au fil du temps : Les données sont complexes et jamais statiques. Les données avec lesquelles le modèle a été entraîné peuvent évoluer au fil du temps. Par exemple, une image particulière utilisée pour entraîner une classification ou une segmentation peut présenter des caractéristiques supplémentaires qui n’ont pas été prises en compte. En conséquence, le concept d’inférence du modèle peut dériver, ce qui entraîne des erreurs et l’éloigne de la vérité terrain. La détection de telles dérives nécessite de réentraîner et de redéployer un modèle.
- Les inférences des modèles échouent au fil du temps : Les prédictions du modèle deviennent erronées au fil du temps en raison de la dérive des données décrite ci-dessus.
- Les systèmes se dégradent sous une forte charge : Même si vous tenez compte de la fiabilité et de l’évolutivité dans le cadre de votre infrastructure de données, il est essentiel de surveiller attentivement l’état de votre infrastructure — en particulier celui de vos serveurs de modèles dédiés lors des pics de trafic intense.
À lire aussi : Prévisions technologiques pour 2022 : cloud, données, cybersécurité, IA et plus encore
À propos de l’auteur :
Robert Nishihara est le cofondateur et CEO d’Anyscale. Il est titulaire d’un doctorat en machine learning et en systèmes distribués.