La mise en production des modèles de Machine Learning
Déploiement, mise en production, industrialisation ... ce sont des mots que l'on évoque de plus en plus ces derniers temps avec les modèles de Machine Learning.
Les deux phases des projets
Phase d'expérimentation
La phase d'expérimentation est toujours réalisée dans les projets Data Science : c'est ce qui permet d'obtenir un PoC (Proof-of-Concept).
Phase d'industrialisation
Cette phase est plus difficile. Dans la phase d'industralisation, les objectifs sont complètement différents.
- Le modèle doit être exposé et accessible aux utilisateurs autorisés (collaborateurs, clients, utilisateurs).
- Il doit garder des performances identiques avec le temps.
- Il doit être toujours disponible et pouvoir supporter de fortes charges de travail.
- Il
Les difficultés liées à l'industrialisation
Pourquoi l'industrialisation est-elle si difficile en comparaison avec la phase d'expérimentation ? Il y a, en réalité, plusieurs facteurs qui expliquent pourquoi aussi peu d'entreprises atteignent cette phase.
L'ingénierie logicielle est indispensable
Une des principales difficultés que l'on rencontre lorsqu'une équipe souhaite industrialiser un modèle de Machine Learning, c'est lorsqu'elle doit passer d'un environnement d'expérimentation (souvent un PC) à un environnement de production (plusieurs serveurs, bases de données, collecteurs de journaux dans une infrastructure).
Comme le souligne ce thread Reddit, il y a une grosse différence entre l'environnement du Data Scientist, qui utilise des notebooks Jupyter et des librairies haut-niveau comme pandas, et l'environnement de production, qui nécessite une conception logicielle propre à l'infrastructure et des techniques d'orchestration de processus.
À lire aussi : découvrez notre formation MLOps
Industrialiser un modèle de Machine Learning, c'est tout d'abord produire un code source documenté, optimisé et qui respecte les bonne pratiques. Ensuite, impossible de se soustraire au développement logiciel : le code doit être compréhensible, reproductible sur des environnements isolés et s'intégrer en tant qu'application ou micro-services. Cette intégration implique de créer des connexions avec d'autres services applicatifs déjà existant dans l'infrastructure.
Les performances se dégradent au fil du temps
Très souvent, le modèle construit a pour objectif de modéliser et reproduire un phénomène observé. Qu'il s'agisse de scoring, de tarification, de segmentation ou encore de catégorisation, la temporalité influence les données. Beaucoup de cas d'applications dans une multitude de secteurs ne peuvent se soustraire de cette tendance temporelle.
- Les informations financières (indicateurs boursiers, marchés immobiliers) sont très volatiles et dépendent de la conjoncture actuelle.
- Le scoring nécessite très souvent la temporalité comme variable explicative (la durée d'un trajet pour une application VTC va dépendre de l'heure et du jour de la semaine où l'on réserve un trajet).
- Les données évoluent au cours du temps (une base de clients sera différente d'une année à l'autre).
Pour cela, il est nécessaire de mettre à jour le modèle avec des données plus récentes, puisque dans le cas contraire, l'information relative au temps ne serait plus captée lorsque les données sont de plus en plus éloignées de celles utilisées pour entraîner le modèle.
La solution consiste alors à automatiser les phases d'expérimentation et de production pour mettre à jour le modèle à partir de nouvelles données sans intervention manuelle. Mais cela nécessite des compétences plus poussées, aussi bien sur l'infrastructure hébergeant le modèle que sur le développement de code source.
Le modèle doit être hautement disponible
Lorsque les modèles sont déployés, ils sont amenés à servir des centaines de requêtes sur des intervalles de temps très courts.
Prenons une situation où le modèle nécessite 400 millisecondes pour effectuer une prédiction. En revanche, il reçoit 3 requêtes par seconde.
- À partir de la première seconde, il accusera un retard de 200 millisecondes pour la troisième requête.
- Dès la deuxième seconde, le retard sera monté à 400 millisecondes pour la sixième requête.
- Au bout de 10 secondes d'exécution, le retard accumulé est de 2 secondes.
Cette situation est intenable, puisque le modèle ne serait plus en mesure de prendre en charge de nouvelles requêtes "à temps" et accuserait d'un retard très important.
À lire aussi : découvrez notre formation MLOps
Pour cela, l'infrastructure hébergeant le modèle doit être scalable : les ressources doivent pouvoir s'adapter automatiquement face à l'augmentation des demandes. Ainsi, l'intérêt de la scalabilité et d'exécuter plusieurs serveurs en parallèle
❓ Comment allons-nous être capable d'utiliser en même temps ces serveurs en parallèle ?
Pour être scalable, une méthode particulièrement utilisée est l'équilibrage de charge (ou load-balancing). Avec ces méthodes, chaque requête est redirigé automatiquement vers un des serveur en parallèle.
