Réentrainer automatiquement un modèle : fausse bonne idée ?

Le mouvement DevOps n’en finit plus de faire des émules et l’on ne compte plus ses déclinaisons parmi lesquelles DevSecOps, FinOps, DataOps et bien sûr MLOps.

Un aspect prépondérant (mais c’est loin d’être le seul) de la démarche DevOps est la logique de déploiement continu (continuous deployment) dont la promesse est de livrer rapidement et de manière automatique une nouvelle version d’une application. Dans cet objectif d’automatisation totale (qui inclura bientôt la production du code par un outil comme GitHub Copilot…), il serait tentant de vouloir enchainer les étapes suivantes :

• intégration de nouvelles données
• préparation des données (filtres, normalisation, PCA, etc.)
• réentrainement du modèle
• évaluation du nouveau modèle
• enregistrement du modèle (au sein d’un model registry)
• déploiement du modèle, par exemple, sous forme d’API REST portée par une image Docker stockée dans un container registry

L’étape d’évaluation serait alors cruciale et permettrait de décider si oui ou non, il faut remplacer le modèle existant. Une telle règle peut-elle être automatisée ? Savez-vous dire quelle différence entre deux versions d’un score F1 est significative et mérite que l’on déploie un nouveau modèle ? Vous basez-vous sur une seule métrique d’évaluation ? Vraisemblablement non. Une règle de décision de remplacement du modèle peut-elle être alors simplement énoncée ?

Mettons de côté le scénario d’une approche par Active Learning qui demanderait un tagging progressif de nouvelles données dédiées à l’apprentissage. Dans ce cas, le réentrainement est nécessaire et ne pose pas question, au moins jusqu’à obtention d’un “bon” modèle.

D’un point de vue strictement DevOps, un déploiement réussi correspond à l’enchainement des étapes suivantes :

• le script d’entrainement du modèle se termine avec succès
• le modèle est archivé dans un model registry
• le build de l’image d’inférence se termine avec succès
• la stratégie de push ou pull de l’image d’inférence se passe avec succès

Parce que nous sommes dans un cas d’usage du Machine Learning, il faut a minima tester que le point de terminaison d’inférence réponde correctement. Mais attention, le modèle peut aussi nous prédire n’importe quoi ! Et cette détection sera beaucoup plus complexe à automatiser.

Ce sujet correspond à un domaine que l’on nomme la drift detection. Le phénomène de dérive peut se rencontrer à plusieurs niveaux :

• les données en entrée changent de distribution
• la relation entre la cible (target) et les données en entrée (features) a changé (le modèle traduit cette relation, à l’instant de l’entrainement)
• les règles de préparation des données ont été modifiées

De plus, nous pouvons constater une dérive ponctuelle (des données “aberrantes” durant une courte période) mais aussi une tendance de fond progressive, plus délicate à identifier. Si l’on plonge subitement une grenouille dans de l’eau chaude, elle s’échappe d’un bond ; alors que si on la plonge dans l’eau froide et qu’on porte très progressivement l’eau à ébullition… Si l’urgence est dans la détection et l’arrêt des services de production liés à ce modèle, prenons le temps d’analyser cette dérive et d’identifier ses causes.

Imaginons maintenant qu’un nouveau modèle déployé en production ne soit pas satisfaisant (défaut de qualité, absence de réponse, etc.). Un retour arrière s’impose. Heureusement, vous disposez des modèles versionnés, voire encore mieux de l’image d’inférence, prête à être redéployée. Cet article revient en détail sur les éléments indispensables à conserver.

En conclusion (provisoire ?), il ne faut pas viser le buzzword du continuous training, qui ne se justifie pas dans beaucoup de scénarios. Prenez soin de la qualité de vos données, de la qualité et de l’interprétabilité de vos modèles, de la continuité du service d’inférence. Et lorsque le bon moment sera venu… ré-entrainez !