Choisir un environnement technique pour la Data Science

Si vous avez suivi l’un de mes précédents articles, vous avez peut-être embauché un Data Scientist. Il faut maintenant l’équiper avec un environnement permettant de passer les projets de l’étape de développement à la production. C’est-à-dire quitter le laptop du Data Scientist (celui avec les autocollants, souvenez-vous) pour devenir un outil exploité par le métier et générant donc de la valeur.

En début d’année, la société Gartner présentera son traditionnel « cadran magique » des plateformes pour la Data Science et le Machine Learning. Il est donc temps de construire une grille pour décider par vous-même de quel sera l’outil le plus adapté à vos besoins. Je ne dévoilerai pas ici mon opinion personnelle mais vous la devinerez rapidement en parcourant mon blog technique.

Pour organiser nos critères, nous allons distinguer les deux grandes phases que sont le développement et la production, en insistant sur les éléments spécifiques au Machine Learning, principalement dans sa version supervisée, c’est-à-dire expliquant une variable labellisée.

L’environnement de développement

Des données, des packages et du code

Lorsqu’il ne tient pas les poignées du babyfoot — cliché — , le data scientist s’enferme dans son Environnement de Développement Intégré (IDE) ou bien son notebook, souvent Jupyter. Les deux approches ont leurs avantages respectifs :

- Rigueur, suivi des variables pour l’IDE

- Simplicité d’exploration de la donnée et interaction pour le notebook

On ne tranchera pas ici dans un débat digne d’un dîner de famille mais le produit final devra respecter un niveau de qualité du code que l’on exige plus souvent des développeurs traditionnels que des data scientists : factorisation, concision, documentation, etc. Certaines sociétés se réfèrent à raison au manifeste de l’artisanat logiciel (« software craftmanship »). Il faudra peut-être chercher du côté de fonctionnalités d’export et de nettoyage d’un notebook .ipynb en fichier .py.

Puisque nous sommes dans le code Python, donnons l’exemple de l’outil virtualenv dont l’intérêt est de séparer les projets dans des environnements virtuels et donc d’éviter les changements de version inopportuns dus à la réinstallation de packages. La version de Python peut aussi être définie, ce qui est souvent intéressant lorsque l’environnement de production n’évolue pas aussi vite que la distribution du langage. Vous trouverez dans ce blog les commandes de base pour utiliser cet outil.

Dans ce cadre sécurisé, il n’y a plus de raison d’interdire ou de restreindre l’utilisation de packages pour la phase de développement. Veillez toutefois à ce que l’accès aux miroirs de téléchargement ne soit pas bloqué par des règles de firewall ou de certificats.

Partager ou sécuriser

Comment se constitue votre équipe ? Chaque data scientist travaille-t-il sur son propre périmètre, qui doit alors être isolé et sécurisé, ou des accès collaboratifs sont-ils à prévoir, par exemple sur les notebooks ? Dans tous les cas, il sera indispensable de prévoir un outil de versionning du code de type Git.

Les data scientists veulent se concentrer sur leur métier : résoudre des problèmes complexes au moyen des données. Ils n’ont pas envie de perdre du temps à accéder à ces données : facilitez-leur la vie en proposant un outil permettant de définir simplement des data sources (le lac de données, le data warehouse…) et des datasets de référence.

Stratégie de tests

Non, tester son code ne veut pas dire redémarrer le kernel et exécuter la totalité du notebook même si c’est un début. Il faut aller traquer le diable où il se cache, c’est-à-dire dans les détails. Qui n’a jamais exécuté avec succès (et performance !) un traitement sur un dataset… complètement vide ? Ici, c’est surtout un état d’esprit et une méthodologie que l’on recherchera plutôt qu’un outil technique.

Les tests unitaires seront sûrement plus simples à concevoir sur les traitements de préparation des données que sur ceux de Machine Learning. Quelques recherches sur l’expression « test driven data science » montrent que ce champ mérite d’être exploré. De premières pistes concrètes apparaissent dans cet article.

Les interfaces visuelles

Les plaquettes marketing tendent à faire la différence entre les data scientists « développeurs » et les « citizen » data scientists adeptes du low voire no code. Si l’on peut s’interroger sur l’efficacité de l’approche « no code » dans des cadres complexes (i.e. réalistes), il ne faut pas sous-estimer le gain de temps obtenu par une interface qui automatise les contrôles de cohérences et statistiques descriptives sur les jeux de données. Qu’on me donne sur le champ moyenne, médiane, écart-type et un graphe de distribution !

Les spécificités du Machine Learning pendant le développement

L’objectif du Machine Learning est de produire le meilleur modèle au sens des métriques d’évaluation, pondérées par le temps de calcul nécessaire. Il est peu recommandable de travailler sur des données incomplètes (les données sont rarement répliquées avec exactitude sur les environnements de développement ou de qualification) même si une approche intelligente d’échantillonnage peut porter ses fruits. Vous devrez résoudre cette contradiction apparente (pour l’IT traditionnelle !) de développement sur des données de production, en particulier en termes de volumétrie.

Plus spécifiquement, lorsque l’environnement de production sera basé sur le framework Spark, il est impératif de développer dès le départ un code appelant des méthodes distribuées, au risque de devoir tout faire recoder par un Data Engineer dont la patience, elle, ne passera pas à l’échelle. On recherchera donc une plateforme de développement disposant simplement et nativement d’un « Spark context » et on surveillera le projet Koalas.

La phase de production

Les impondérables

Commençons par le plus simple, un traitement doit être :

- déposé sur l’environnement de production

- avec les paramètres propres à cet environnement (chaînes de connexion, URI, clés, etc.)

- ordonnancé

- supervisé

Dans notre panier de courses, nous mettrons donc des fonctionnalités de Continuous Integration / Continuous Deployment pouvant packager en « artifact » le livrable disponible dans un repository Git.

Parce qu’on ne lance pas les traitements manuellement à 3h du matin sur la production, l’ordonnanceur devra prendre en charge ce travail souvent nocturne mais surtout s’intégrer dans toute une foule de traitements vraisemblablement dépendants mais issus d’autres périmètres d’activités. Pensez à pouvoir piloter le tout du même endroit, sans doute au travers d’APIs.

La supervision devra permettre a minima remonter des alertes et nous verrons par la suite les spécificités du monitoring en Machine Learning.

La gestion des packages

Le critère le plus important en Data Science (mais sera-t-il un jour résolu de manière satisfaisante ?) est la gestion des packages qui ont permis le développement des traitements. On pourrait se fier aux miroirs de téléchargement et lancer, qui un pip install, qui un install.packages, mais votre environnement de production bénéficiera-t-il d’un accès Internet ? Sauf à trouver le Graal dans une plateforme de Data Science, il faudra peut-être affronter les images Docker ou bien ressortir ce projet PEX initié par Twitter.

Puisque nous en sommes à évoquer les langages qui ont servi au développement, aurez-vous besoin de faire grimper vos traitements sur la grande échelle de la volumétrie des données ? Si c’est le cas, mieux vaut que le développement autorise la parallélisation des calculs. Mais c’est ici tout une réflexion d’architecture qui sera nécessaire.

Les spécificités du Machine Learning pendant la production

Répétons-le encore une fois, tout l’intérêt du Machine Learning supervisé est de produire des prévisions. Si celles-ci peuvent être générées en mode batch (ainsi, la liste des clients susceptibles de churn), il est encore plus intéressant de produire des prévisions au plus tôt de l’arrivée de la donnée (ainsi, dès la production d’une analyse médicale). Pour cela, nous exploiterons efficacement une API REST. Mais attention, les ressources qui supporteront ce service devront pouvoir aussi passer à l’échelle. Le principe des conteneurs sera encore ici une piste intéressante mais d’autres approches de « serving » sont évoquées dans ce post Medium.

Pour autant, un modèle prédictif, une fois qu’il est entrainé, n’est pas autre chose qu’une série de pondérations. C’est donc un tout petit fichier binaire, accompagné d’une fonction de scoring (…et de tous ces *%?**#$ de packages spécifiques !). Ce n’est donc pas ce qui va demander le plus de ressources mais celles-ci devront tout de même être élastiques.

Le monitoring du Machine Learning va plus loin que le simple statut OK/KO d’un traitement. En effet, un modèle prédictif peut dériver, c’est-à-dire fournir des éléments qui ne sont plus aussi justes que lors de la phase d’évaluation du modèle. La principale raison tient souvent dans l’évolution du monde réel depuis la phase d’entrainement. Pour détecter la dégradation d’un modèle, il sera nécessaire de mettre en place plusieurs actions :

- Calcul des métriques d’évaluation sur les nouvelles données lorsque la valeur prédite est connue

- Entrainement d’un nouveau modèle sur des données plus récentes et « A/B testing » de ce modèle contre l’ancien

- Recueil des impressions des utilisateurs métiers sur les prévisions

Au niveau fin, ce dernier point se traduit par la mise en place d’une « feedback loop » que l’on pourra réinjecter dans les données d’apprentissage. Cette fonctionnalité nécessitera vraisemblablement un développement spécifique mais il ne faut surtout pas la négliger. N’oubliez que si elle est intelligence, elle est avant tout artificielle !

Critères de choix pour la phase de production

Conclusion ?

En conclusion… eh bien non, c’est à vous d’apporter la conclusion en choisissant un outil et en expérimentant car il n’existera pas de baguette magique (seul le cadran est magique !) mais la pratique vous donnera sans doute de nouveaux critères, voire de nouvelles exigences. L’erreur sera certainement d’attendre qu’un produit fasse la synthèse de tous les besoins car les pratiques évoluent très vite. Le courant de l’Automated Machine Learning risque par exemple de retirer bientôt toute phase de sélection fine de modèles au profit d’une approche par force brute. La législation pourra contraindre (c’est déjà le cas, en théorie) à donner l’explication d’une prévision, ce qui pourrait demander de retrouver les hyper paramètres d’un algorithme, son jeu d’entrainement voire la seed intervenant dans un tirage aléatoire… Alors, lancez-vous et partagez vos expériences, vos réussites comme vos déceptions. Evaluez vos erreurs et recommencez afin de les réduire. Du Machine Learning en quelque sorte.