DÉPLOIEMENT DE SOLUTIONS BASÉES SUR L'APPRENTISSAGE AUTOMATIQUE

L'évolution du paysage technologique ces dernières années a fait que les data scientists ne se contentent plus de communiquer leurs analyses via des présentations PowerPoint mensuelles ; ils doivent désormais les déployer sur des applications web en production. De ce fait, la frontière entre les deux disciplines s'estompe.

Récemment, j'ai assuré la liaison data science sur un projet avec l'une des quatre plus grandes banques d'investissement. La banque avait affecté une petite équipe de data scientists à ce projet. Data scientist expérimenté dans le déploiement de solutions, je suis également un ingénieur logiciel compétent. Malgré cela, j'ai tiré de nombreux enseignements sur la gestion de l'interface entre deux équipes afin de créer un produit final de qualité.

Le projet dans un monde idéal

Généralement, dans un projet logiciel d'envergure, on trouve des ingénieurs logiciels, des data scientists ou des spécialistes de l'expérience utilisateur qui ignorent comment la solution est mise en ligne et interconnectée. C'est là qu'interviennent le chef de projet et le responsable de l'infrastructure (déploiement), qui maîtrisent le déploiement des solutions.

Dans un monde idéal, ils auraient tous accès à d'immenses ensembles de données brutes, claires et vérifiées, prêtes à être intégrées à Amazon Web Services (AWS). Un expert du domaine serait disponible pour les aider à comprendre les subtilités du problème et à affiner leurs données afin d'en extraire des caractéristiques hautement corrélées.

Ils déploieraient une multitude de machines gigantesques pour modéliser les pétaoctets de données en parallèle. Ils utiliseraient des conteneurs AWS SageMaker dès le départ, afin que les artefacts du modèle final soient déployés en continu et sans accroc sur les mêmes conteneurs à mise à l'échelle automatique. Le besoin métier consisterait à traiter de petits volumes de données et à obtenir des réponses encore plus petites. Aucune heuristique au niveau des lignes ne pourrait être exprimée comme une fonctionnalité.

Et la vie serait belle : les papillons voltigeraient légèrement autour de Bambi tandis qu'il gambade dans la forêt.

Le projet dans le monde réel

En réalité, la majorité de la communauté « science des données » a une compréhension limitée des méthodologies de développement logiciel. Généralement, ils produisent des analyses ponctuelles pour des présentations PowerPoint stratégiques et décisionnelles, plutôt que les modèles à haut débit et en temps réel nécessaires à un utilisateur en ligne.

Nombreux sont ceux qui disposent d'une suite d'outils performante, ce qui rend difficile la compréhension de l'intérêt d'adopter une autre suite d'outils plus facilement déployable. Le déploiement étant un concept abstrait en science des données, il est difficile de justifier pourquoi consacrer du temps, qui pourrait être dédié à la compréhension du problème, à l'apprentissage d'un outil remplaçant un outil existant.

Résultat : ils investissent énormément de travail dans un système qui ne fonctionne que sur leur machine. Cette situation est impraticable.

Comment concilier ces deux réalités ?

Les projets innovants (plutôt que des refontes, des réécritures ou des mises à jour) sont excellents car ils ne nécessitent pas de gestion de systèmes existants. Vous avez la liberté de concevoir le projet dès le départ. Cependant, même si, en tant que consultant, vous pouvez parfois éviter de travailler avec des systèmes existants, il subsistera toujours une part de pensée héritée qui exigera un renforcement attentif de l'équipe.

Lorsque vous êtes ingénieur logiciel et que vous travaillez avec une équipe de data scientists, quelques étapes sont nécessaires pour éviter que ces derniers ne se sentent isolés et submergés par des processus et des exigences inédits, tout en garantissant la reproductibilité et la fiabilité du déploiement en production.

1. Échanger et former

Faire intervenir un consultant qui se met à donner des leçons ne fonctionne pas toujours. En réalité, on a beaucoup à apprendre de la plupart des clients sur leur domaine d'activité. Et on a aussi beaucoup à leur transmettre.

La plupart de ces chercheurs expérimentés souhaitent vraiment voir leurs travaux utilisés à grande échelle. C'est bien plus gratifiant qu'une simple mention dans une présentation PowerPoint.

Discutez donc du fonctionnement du cloud, de ses limitations et de ses fonctionnalités. Renseignez-vous sur leurs outils de prédilection et trouvez un compromis. Soyez clair sur les conséquences des décisions que vous prendrez ensemble. Cela compromettra presque certainement l'évolutivité et le déploiement fluides offerts par SageMaker. Vous devrez donc gérer cette situation avec une équipe. Indiquez clairement le coût de ces choix.

2. Définir clairement les responsabilités

Prenez le temps de communiquer. Soyez patient avec les fondamentaux.

La modélisation diffère du développement logiciel classique, mais il s'agit bien d'un logiciel qui doit être développé. On ne peut pas se contenter d'un document de conception et d'écrire des tests imposant un comportement déterministe. Souvent, on observe non pas des progrès incrémentaux, mais plutôt de longues périodes d'accalmie suivies de percées. De nombreux responsables de développement logiciel ne possèdent ni les compétences ni les outils nécessaires pour gérer cette situation.

Définissez la relation entre l'équipe de science des données et les déployeurs de solutions de la même manière que vous définissez une API. Établissez un contrat qui vous permette de collaborer. Cela commence par un engagement de l'équipe de modélisation quant aux livrables. La possibilité de produire quelque chose à partir des données et, le cas échéant, dans quel format.

Une fois cet engagement établi, utilisez des processus de compilation automatisés pour responsabiliser l'équipe de modélisation (nous y reviendrons).

3. Responsabilisation et gestion

Selon votre expérience et vos collègues, cela peut paraître surprenant, mais vous devez former vos data scientists au contrôle de version. Même s'ils prétendent déjà l'utiliser. Réunissez tout le monde. Ouvrez un ticket, demandez-leur de créer une branche et d'ouvrir une pull request (PR). Enfin, demandez-leur de vérifier l'état de la compilation effectuée entre le commit et la PR.

Soyez très prudent à ce stade, car il est facile de perdre l'attention. Basez la leçon sur un exemple fictif pour que tout fonctionne, et surtout, n'utilisez pas de code existant. Ils doivent voir le processus en action. Ils doivent ressentir la liberté que procure le partage de code fonctionnel au sein de l'équipe. Cela en vaut la peine.

L'alternative ? Recevoir un e-mail par semaine avec une « mise à jour du modèle » accompagnée d'une description vague de ses performances, et passer la semaine suivante à essayer de le faire fonctionner. L'équipe de modélisation se déconnecte de plus en plus de l'environnement de production, ce qui engendre une incompatibilité croissante. Vous passez votre temps à bricoler des solutions inefficaces, peu performantes et impossibles à maintenir. Pire encore : vous êtes responsable lorsqu'un modèle ne se comporte pas comme sur le poste de travail Windows 7 de son auteur.

4. Ne soyez pas trop exigeant

Une fois que l'équipe de modélisation maîtrise le flux de travail de gestion de versions, détendez-vous. Aidez-les à finaliser leurs builds et expliquez-leur les raisons des erreurs. À ce stade, c'est simple et nous apprécions tous l'opportunité de comprendre le fonctionnement du matériel de production.

Commencez à ajouter des tests et encouragez-les à faire de même. Montrez-leur comment les tests sont exécutés et pourquoi les erreurs de compilation/tests sont pertinentes.

Testez uniquement les fonctionnalités de bout en bout. Ne cherchez pas à être trop exhaustif dans vos tests. Ils ont déjà du mal avec les règles, alors assurez-vous simplement que le code fonctionne comme prévu. Soyez bienveillant lors des revues de code. Ils apprécieront d'y participer, mais concentrez-vous sur la fonctionnalité, et non sur le style ou la maintenabilité. Ne faites rien qui puisse les démotiver.

Conclusion

Nous devons trouver des moyens d'atteindre des standards élevés dans le déploiement de solutions évolutives, tout en favorisant le développement des compétences logicielles de nos collaborateurs aux profils variés. Chez Kablamo, la plupart de nos projets sont des innovations pour nos clients, et non des refontes, des réécritures ou des mises à jour.

Nous nous sommes forgé une réputation d'équipe capable d'apporter une vision et une expertise précieuses à des projets ambitieux, même lorsque le chemin vers le succès est incertain. C'est le développement ciblé des compétences au sein d'une équipe multidisciplinaire qui nous permet d'occuper cette position.