Le constat : le grand écart entre le POC et le produit Data Science industrialisé
De nombreux chiffres ont été publiés et font du bruit sur le taux de projets data qui échouent à aller en production et ne dépassent pas le stade du POC :
- Un rapport de VentureBeat AI explique que 87% des projets Data Science ne vont pas en production ;
- Gartner estimait en 2019 que 80% des projets d’IA de 2020 allaient rester à l’état de POC, menés par des “sorciers” dont les talents ne sont pas compatibles avec un passage à l’échelle de l’organisation ;
- Ce même rapport Gartner estime que seulement 20% des insights d’analytics vont réellement délivrer de la valeur en 2022.
En voici quelques causes.
Des problèmes d’industrialisation
Il y a en effet toujours une réelle difficulté rencontrée par les entreprises afin d’industrialiser efficacement et rapidement leurs projets d’IA, qui ne vont donc pas au-delà de la phase de Proof Of Concept (POC).
A titre d’exemple, les modèles de Machine Learning sont régulièrement construits en s’appuyant sur un grand nombre de logiciels et projets open source, dont le respect de la version utilisée entre le POC et la production est primordial et peut vite devenir un calvaire sans une réelle méthodologie, voire un danger si un changement de version affecte le comportement du modèle et l’amène à faire de mauvaises prédictions. De même, la stack technique utilisée en POC est parfois difficile à reproduire à l’identique en environnement de production.
Des objectifs business mal définis
Au-delà des aspects purement techniques, le risque d’avoir des objectifs business peu ou mal définis en amont est une porte ouverte à des objectifs changeants ou une solution peu adaptée pour la problématique des utilisateurs.
Des problèmes de passage à l’échelle
Réussir à mettre en production un modèle de Machine Learning semble donc déjà être un accomplissement en soi. Mais ce n’est en réalité que le début de l’histoire !
Il y a en effet tout le cycle de vie de ce modèle qu’il va falloir gérer. Quand le réentraîner avec des données plus fraîches ? Que faire si ses performances se dégradent ? Comment savoir qu’il continue de m’apporter de la valeur ? Comment faire si je veux le remplacer par une nouvelle version ?
Mais au-delà de cela, il y a le fait d’être capable de passer d’un seul modèle en production à plusieurs dizaines voir centaines. S’il peut sembler gérable de suivre dans le temps un ou quelques modèles mis en production, devoir gérer toute une flotte de modèles sans aucune automatisation pourrait vite devenir mission impossible, voire mission très dangereuse ! Nous reviendrons sur les principales raisons à cela plus loin dans l’article.
L’existant : les méthodologies DevOps
Ces constats ne sont pas sans rappeler les difficultés régulièrement rencontrées dans le monde du développement logiciel et du Software Craftsmanship. Et c’est pour cela qu’existent les pratiques du DevOps, un mouvement ayant pour objectif de supprimer les barrières entre les équipes d’Opérations et les équipes de Développement.
Les grands principes du DevOps
Le DevOps est composé d’un ensemble de pratiques techniques et d’organisation ayant pour objectif d’augmenter la vélocité d’une entreprise à livrer du logiciel de haute qualité, de manière fiable, sécurisée et adaptable à l’échelle.
Les grands principes du DevOps peuvent classiquement se résumer via l’acronyme CALMS :
- Culture - les pratiques DevOps impliquent un changement culturel et organisationnel, notamment au travers de la collaboration, la communication et l’agilité.
- Automatisation - Automatiser tout ce qui doit l’être (notamment via de la Continuous Integration & Continuous Delivery)
- Lean - Rationalisation des processus, afin d’optimiser et fluidifier l’ensemble de la chaîne de livraison (vous pouvez vous en référer au principe du razoir d’Ockham pour aller plus loin)
- Measurement - Afin de suivre un principe d’amélioration continue, tout doit être mesurable afin de prendre des décisions, et pivoter si besoin (se référer à la notion de Kaizen pour aller plus loin)
- Sharing - Aligner toutes les parties prenantes sur les mêmes objectifs afin de pousser dans la même direction
Afin d’alimenter tous ces principes, de nombreuses pratiques sont régulièrement mises en place : Continuous Integratin & Continous Delivery, Infrastructure As Code, Monitoring & Observabilité, microservices, etc.
Un air de famille qui peut aider…
Lever les barrières techniques pour gérer efficacement les livraisons logicielles à l’échelle de l’entreprise, ainsi que les barrières de communication afin que toutes les équipes poussent dans la même direction, voilà ce dont nous avons aussi grandement besoin pour le Machine Learning !
Sur de nombreux aspects, les méthodologies DevOps devraient donc permettre d’aider à lever les barrières à l’industrialisation et au déploiement à l’échelle de projets de Machine Learning.
… mais plus “cousin éloigné” que “frère jumeau”
Oui … mais … ce n’est pas tout à fait suffisant. Si les méthodologies DevOps ne sont pas immédiatement transposables aux équipes Data Science, c’est parce qu’il existe quelques différences fondamentales entre le déploiement de code et le déploiement de modèles de Machine Learning en production.
La première d’entre elles est qu’en Machine Learning, le code n’est pas la seule chose qui change et qui doit être versionné : les données, les hyperparamètres, les métadonnées (ainsi que le modèle en lui-même qu’il faut bien mettre quelque part) doivent l’être aussi afin d’assurer une reproductibilité des résultats.
Deuxième différence majeure : le monitoring. En effet, un logiciel n’est pas censé se dégrader dans le temps (enfin, en théorie), alors que ce sera très probablement le cas concernant les performances d’un modèle de Machine Learning. Un modèle déployé en production a été entraîné sur un set spécifique de données. Mais ces données continuent d’évoluer dans le temps (reflet des comportements des utilisateurs qui peuvent évoluer par exemple), ce qui résultera en une dégradation des performances du modèle qui continuera d’effectuer des prédictions basées sur les anciens patterns qu’il a appris.
La solution : MLOps = ML + Dev + Ops
Une définition du MLOps
C’est donc là que le terme MLOps entre en jeu et prend toute son importance. Basé sur tout ce que l’on vient de se dire, on peut alors définir le MLOps comme le processus d’automatisation du Machine Learning en utilisant les méthodologies DevOps.
L’objectif du MLOps est donc de faire en sorte que le déploiement et la gestion en production des modèles de Machine Learning se fassent de la manière la plus simple, efficace, fiable et automatisée que possible.
MLOps et le double mur de la confusion
Cependant, le terme peut de notre point de vue porter à confusion. En effet, le terme DevOps désigne le fait de briser le mur souvent existant entre les équipes de Dev et les équipes Ops. En appliquant cette même logique à MLOps, on pourrait penser que le but est de briser le mur qui se dresse entre les équipes de ML et les équipes Ops. Et c’est en partie vrai.
Sauf que, étant donné que très souvent, les Data Scientists sont (au moins en partie) déconnectés des équipes de Dev & Data Engineering, ce n’est pas un, mais deux murs qu’il faut savoir briser : celui entre ML et Dev ET celui entre Dev et Ops. La tâche s’avère donc encore plus ardue, car il devient nécessaire de faire communiquer beaucoup plus d’interlocuteurs aux backgrounds différents !
Les grands principes du MLOps
En se concentrant sur les spécificités inhérentes au MLOps par-dessus les principes DevOps, nous pouvons référencer 5 piliers fondamentaux : reproductibilité, déploiement, monitoring, gestion du cycle de vie et gouvernance.
Développement de modèles & Reproductibilité
Les Data Scientists doivent être capables de reproduire leurs expérimentations, que ce soit pour en construire de nouvelles par-dessus, ou bien pour qu’un environnement de production soit capable de la refaire automatiquement. La reproductibilité concerne les configurations qui ont amené à tel ou tel modèle entraîné, mais aussi l’environnement nécessaire pour le faire (ex: versions des packages utilisés).
Tout ceci passe donc par un versionning adapté, qui va au-delà du versionning du code : versionning de la donnée d’entraînement, des hyperparamètres du modèle et autres métadonnées.
Mise en production et déploiement de modèles
Être capable de reproduire les conditions d’entraînement d’un modèle est une chose, mais être capable de créer les bonnes conditions de son déploiement et utilisation en production en est une autre.
En effet, beaucoup de questions sont à considérer et débattre sur la bonne manière d’utiliser un modèle : quelles sont les restrictions nécessaires pour s’assurer qu’il soit utilisé à bon escient ? Sera-t-il utilisé en batch ou en streaming ? Faut-il l’envisager sous forme de Model-As-A-Service (via une API notamment) ou bien directement incorporé dans un produit ? Faut-il le convertir dans un format interopérable entre plusieurs environnements (cf des projets comme ONNX par exemple) ? Autant de questions qui nécessitent une vraie entente et collaboration en amont entre les différents acteurs.
Monitoring
Le monitoring et l’observabilité ne sont pas spécifiques au MLOps, et toutes les métriques classiquement monitorées dans le développement logiciel classique (entendre: sans ML) doivent aussi l’être dans un contexte MLOps. Après tout, un produit à base de ML reste un logiciel, et doit être traité comme tel.
Cependant, d’autres informations doivent être monitorées en continu. La performance du modèle est bien entendu un élément essentiel à mesurer afin de vérifier toute éventuelle détérioration des performances visées et agir dessus.
Mais ce n’est pas la seule spécificité. Il est en effet notamment primordial de monitorer chaque étape de transformation des données, à commencer par les données d’entrée elles-même, afin d’être alerté de toute déviance dans les distributions de données par rapport aux conditions d’entraînement du modèle. C’est ce qu’on appelle le data drift. Ces déviances peuvent être dues à des erreurs (mauvaises conversions d’unités par exemple), ou bien tout simplement être le reflet de changement de comportements d’utilisateurs.
Gestion du cycle de vie des modèles
Déployer un modèle en production est certainement une belle étape de franchie, mais ce n’est certainement pas la dernière. Le cycle de vie d’un modèle est fortement itératif. Les Data Scientists vont notamment vouloir déployer de nouvelles versions de ce modèle régulièrement, soit parce qu’ils y ont apporté des modifications qui pourraient améliorer ses performances, soit parce qu’il a été nécessaire de ré-entraîner ce même modèle sur des données plus récentes.
Ce dernier point peut d’ailleurs être géré automatiquement, mais doit être soumis à une forte rigueur. On ne peut pas en effet simplement remplacer un ancien modèle par un plus récent sans prendre quelques précautions (via des pratiques de blue-green deployment ou de canary deployment par exemple).
Au final, ré-entraîner et déployer automatiquement une nouvelle version d’un modèle de Machine learning doit pouvoir se faire avec le moins d’effort possible.
Gouvernance
La gouvernance autour de l’IA est souvent un aspect négligé, mais est pourtant un élément fondamental pour une entreprise souhaitant gérer du Machine Learning à l’échelle, et a un impact fort sur la manière dont on va dimensionner et gérer la mise en production des modèles.
On l’aura compris, un projet incorporant du Machine Learning est un projet impliquant énormément de rôles différents, bien au-delà du Data Scientist. Et il est nécessaire de s’organiser et d’avoir une réelle gouvernance d’entreprise afin de gérer les aspects business, légaux et éthiques autour de la gestion de l’Intelligence Artificielle. La gestion des risques et des responsabilités en cas de problème causé par un produit incorporant de l’IA doit être pensée en amont avant qu’un éventuel problème n’arrive afin de ne pas être dans le gestion de l’urgence.
Comment gérer un rollback en cas de défaillance d’un modèle ? Que faire si on se rend compte a posteriori que certains résultats d’un modèle sont discriminants envers telle ou telle population ? Quels sont les risques financiers associés à ce projet en cas de mauvaises prédictions ?
S’il est déjà dangereux de ne pas se poser ces questions lors de la mise en production de son premier modèle, imaginez lorsque vous devez en gérer des dizaines, centaines voire milliers.
Conclusion : Le MLOps n’est pas qu’une histoire d’outils, ce sont avant tout des comportements
Un logiciel à base de Machine Learning reste un logiciel, et toutes les bonnes pratiques de développement qui l’entourent doivent donc s’appliquer aussi. Avec quelques subtilités supplémentaires liées au monde particulier de la data.
Experts métier, Data Scientists, Data Engineers, Développeurs, Architectes, équipes d’Opérations, Product Managers : tout le monde est concerné par une démarche MLOps.
L’un des piliers du DevOps est de garantir une meilleure collaboration entre les différents acteurs dans le développement logiciel, et il en est de même pour le MLOps, peut-être avec encore plus d’interlocuteurs aux intérêts et backgrounds différents.
Le MLOps est donc avant tout un ensemble de comportements et une réelle stratégie d’entreprise afin de gérer de manière fiable et sécurisée la gestion de ses projets de Machine Learning à l’échelle.
A vos modèles, prêts ? Déployez !
Quelques lectures complémentaires sur le sujet :
