La Grosse Conf 2024 - La paralysie des équipes ML en run, nouvel ennemi au bestiaire

Aurélien Massiot - ML Engineer chez OCTO Technology à la Grosse Conf

Aurélien, ML engineer chez OCTO Technology, débute son intervention en nous invitant à observer deux images : celle du gyroplane conçu par Louis-Charles Bréguet et celle d'un drone moderne. Certes, ces deux engins ne remplissent pas exactement les mêmes fonctions, car contrairement au gyroplane, un drone moderne n'est pas destiné au transport de passagers. Cependant, ils partagent une caractéristique fondamentale : la capacité à voler.

En confrontant ces deux appareils, il attire notre attention sur les différences de conception. D’un côté le processus de conception complexe du gyroplane de Bréguet qui, pour stabiliser l'appareil, ajoutait des hélices a chaque déséquilibre qu’il constatait, créant ainsi une solution complexe et peu efficace. De l’autre, l'évolution de la conception des drones modernes est caractérisée par sa simplicité et son épurage. Un siècle après le gyroplane de Bréguet, la transformation de ces engins a adopté un design bien plus simple et plus stable.

Un parallèle peut-être fait avec les projets de Machine Learning (ML) et les projets data en général qui suivent une logique similaire. Comme pour la conception d'aéronefs, la complexité excessive dans les projets data peut rendre leur maintenance à long terme impossible. La simplicité est essentielle pour garantir la pérennité d'un projet, même si atteindre cette simplicité est un défi en soi.

Le périple du MLOps

Dans cette première partie, nous explorerons les différentes phases du MLOps, en mettant en lumière les défis rencontrés à chaque étape.

Dans nos projets MLOps on peut distinguer 3 phases :

• Lors de la conception, nous devons avoir une compréhension des besoins des utilisateurs, définir précisément des sources de données et le choix méticuleux de métriques adaptées au problème à résoudre. On cherche à répondre à la question : Comment concevoir des modèles de Data Science ?
• Une fois les bases posées, la phase de build entre en jeu. Les défis ici résident dans la création d'un code robuste selon les principes du software craftsmanship, ainsi que dans l'automatisation du déploiement sur un environnement de production. Ici, on répond à la question : comment industrialiser et déployer des modèles de Data Science ?
• Enfin l’étape du run, c'est-à-dire lorsqu’on a au moins un utilisateur qui utilise le produit. Il faut s'assurer que les performances ne se dégradent pas, réagir efficacement en cas d'incident, garantir une efficience opérationnelle et standardiser l'architecture. La gestion de ces challenges peut rapidement devenir complexe, surtout lorsque plusieurs produits sont développés simultanément et que l'objectif est de standardiser les approches et les technologies utilisées.

“Il y a un moment où vous vous dites “ca fait beaucoup de choses” [...] et vous allez être pétrifiés par le toil.”

Mais alors c’est quoi le toil ? Terme emprunté aux équipes SRE de Google, il se caractérise par sa nature répétitive, manuelle et souvent non-scalable des tâches. Il se distingue ainsi des deux autres types de tâches qui occupent une équipe que sont le développement de nouvelles fonctionnalités et l'overhead administratif.

Concrètement, le toil englobe l'ensemble des tâches liées à l'exploitation d'un service en production. Ces tâches peuvent être automatisables mais sont souvent exécutées manuellement, n'apportant pas de valeur ajoutée directe au produit. De plus, elles ont tendance à croître de façon linéaire avec le nombre d'utilisateurs du service. Leur exécution peut rapidement devenir incontrôlable et entraîner des conséquences désastreuses, notamment en termes de coûts :

• Coût dû aux erreurs humaines : La nature manuelle et répétitive du toil expose les équipes à un risque accru d'erreurs, pouvant entraîner des incidents coûteux et des perturbations du service.
• Coût humain : Le temps et les ressources investis dans l'exécution du toil peuvent avoir un impact significatif sur le bien-être et la motivation des membres de l'équipe.
• Coût de retard : L'attention portée au toil peut nous détourner de nos autres tâches, retardant ainsi le développement et l'amélioration du produit.

Afin de prévenir les effets néfastes du toil, les équipes SRE de Google ont établi une règle d'or : ne pas consacrer plus de 50% de leur temps à des tâches de ce type.

Aurélien nous propose donc de réaliser un jeu : toil ou pas toil ? Le jeu du toil

Les réponses :

1. Toil
2. Développement
3. Toil
4. Overhead
5. Toil
6. Overhead

Deux chemins existent alors pour maîtriser le toil : le combattre ou l’éviter.

Combattre le toil

Mais est-ce que c’est normal d’avoir du toil en phase de run ?

Oui c’est tout à fait normal, car dans des projets MLOps, nous devons gérer 3 dimensions interdépendantes : le code, le modèle et les données. Par exemple, si les données changent ça peut impacter le modèle, si le code change, le modèle et les données peuvent être impactés etc. Par ailleurs, en début de projet, on va passer du temps à cadrer avec nos utilisateurs et on va mettre moins d’énergie dans la conception d’un produit parfaitement carré. Et lorsqu’on est en phase de build, l’environnement reste mouvant et il est nécessaire de continuer à valider des hypothèses sur les fonctionnalités du produit et les performances du modèle. Le contexte continue d’évoluer et on n'aura pas forcément envie de tout automatiser dès le début car ce sera souvent une perte de temps.

En phase de run, le toil tend à s'accroître avec l'ajout de nouvelles fonctionnalités et l'augmentation du nombre d'utilisateurs. Si aucune mesure n'est prise pour le contrôler, le toil peut rapidement devenir un obstacle majeur, paralysant ainsi le projet dans son évolution.

Pour contrer efficacement le toil, la première étape va être de le mesurer, que ce soit manuellement ou à l'aide d’un Kanban et de tickets, nous pouvons identifier les tâches répétitives. Une fois que nous avons pris conscience de ces tâches, il faut définir des actions pour permettre l'automatisation s'avère être l'outil le plus puissant.

Les principales stratégies pour tacler le toil incluent :

• Supprimer la tâche en transformant un processus. Par exemple, plutôt que d’envoyer tous les jours à la main un fichier de prédictions à des utilisateurs, on pourrait leur mettre à disposition une interface pour qu’ils puissent consulter les prédictions directement.
• Automatiser tout ou partie de la tâche pour en réduire la charge.

Le processus est donc simple : on mesure, on améliore et on mesure de nouveau pour voir si la situation s’est améliorée, et cela à chaque itération.

Éviter d’affronter le toil

Dans cette dernière étape, nous explorons une voie alternative pour éviter de se confronter directement au toil. Trois constats soulignent les pratiques à adopter pour prévenir son apparition. Constat 1 : Réutilisation limitée de l'existant Les équipes data ont tendance à sous-utiliser les ressources existantes, privilégiant souvent des solutions rapides, comme du shadow IT, au détriment d'une intégration harmonieuse dans l'écosystème IT existant. Cette approche peut entraîner des compromis en termes d'infrastructure et de code, susceptibles d'avoir un impact négatif lors de l'intégration ultérieure du projet. Constat 2 : La partie déterministe n'est pas automatisée Dans un projet de Machine Learning, la majeure partie des briques est déterministe, offrant ainsi un potentiel d'automatisation considérable. Seules quelques parties du code de machine learning sont véritablement non-déterministes, ce qui implique que de nombreuses tâches répétitives peuvent être automatisées, telles que la gestion de l'infrastructure, la CI/CD et même le feature engineering. Constat 3 : Choix parfois non idéaux Les décisions prises lors de la conception d'un projet ML peuvent parfois être sous-optimales, soit en raison d'une sur-anticipation, soit d'un manque de recul sur l'état de l'art du domaine. Par exemple, le recours à des modèles de Deep Learning ou à des technologies à l’état de l’art peut entraîner une complexité inutile et une maintenance accrue. Plus tôt dans cette journée de la Grosse Conf, Julien Simon nous parlait justement de “choisir le plus petit modèle qui fait le taff” et non le dernier modèle à la mode.

Dans nos choix face au toil, nous pouvons adopter différentes attitudes, allant de la témérité à la prudence, et de la conscience à l'inconscience.

“Il faut beaucoup de courage pour supprimer du code [ou] décommissionner une fonctionnalité qui a coûté un millions d’euros et qui n’est pas utilisée”

En conclusion, pour éviter le toil et naviguer avec succès dans le monde complexe du MLOps, il est essentiel de concevoir avec soin, conscientiser nos choix et de supprimer le superflu et donc de réaliser des choix prudents et conscients.

“Fut un temps où les développeurs étaient payés au nombre de lignes de code qu'ils écrivaient... On devrait maintenant penser à les payer pour en supprimer, car la suppression c'est la simplification.”

Cette simplification énoncée par Aurélien fait écho à la loi d’erooM, mentionnée plus tôt dans le talk de Tristan Nitot. Dans cette démarche, chaque décision compte et contribue à façonner un environnement opérationnel plus efficace et plus pérenne pour les projets de Machine Learning. Les historiser à travers des ADR peut être une pratique efficace pour les conscientiser et les communiquer à votre équipe.

Takeway

En conclusion, le MLOps est un périple jalonné de défis et d'opportunités, où la gestion du toil et la simplification des produits ML émergent comme des axes essentiels. Aurélien nous invite à être attentif aux points suivants :

• Conscientisons le toil. La phase de run n'est pas une fin en soi. Développer de nouvelles fonctionnalités tout en maintenant l'existant est comparable à changer le moteur d'un hélicoptère en plein vol. Il est crucial de garder une vigilance constante face au toil, qui peut rapidement devenir une entrave au projet s’il est sous-estimé.
• Simplifions nos Produits ML. Simplifier nos produits de ML est un impératif pour éviter les écueils et les impasses. Parfois, il est nécessaire de rebrousser chemin ou même de repartir de zéro pour atteindre une solution plus élégante et efficace. Inspirons-nous de la nature et de ses principes d'optimisation, tout en gardant à l'esprit que la simplicité est un idéal à atteindre, nécessitant persévérance et expérience.

“Ce dessin m'a pris cinq minutes, mais j'ai mis soixante ans pour y arriver”.

En définitive, comme l'a si bien exprimé Auguste Renoir à travers cette phrase, la simplicité peut sembler facile, mais elle est le résultat d'années d'efforts et d'apprentissage. Dans notre quête vers des produits ML plus simples et plus efficaces, gardons cette citation en tête, rappelant que le chemin vers la perfection est un voyage continu, façonné par notre engagement et notre expérience.