A la croisée de plusieurs disciplines, la Data Science s’appuie sur des méthodes et des algorithmes pour tirer des informations et de la connaissances à partir de données structurées et non structurées. Encore inconnus il y a quelques années, les métiers de la Data Science et du Machine Learning évoluent très vite. Compétences, méthodes, outils… dans cette série d’entretiens, nous confrontons notre expérience à celle du marché, avec la participation de Data Scientists et ingénieurs Machine Learning externes à Devoteam Revolve.

Virginie Mathivet a découvert l’IA et l’apprentissage par renforcement en 2003, elle est aujourd’hui directrice de la R&D chez TeamWork, et manager de l’unité « Modern Data ». Virginie est également formatrice et conférencière, AWS Machine Learning Hero, et elle vient de publier son cinquième ouvrage, Machine Learning – Implémentation en Python avec Scikit-learn aux éditions ENI.

Peux-tu te présenter ?

J’ai découvert l’IA en 2003, et j’ai suivi un double cursus d’ingénieur à l’INSA avec en parallèle un DEA sur l’IA. Le sujet m’a plu, j’ai continué en thèse et mon sujet de doctorat était l’apprentissage par renforcement. A cette époque, je travaillais sur des algorithmes génétiques et des réseaux de neurones, j’utilisais les algorithmes génétiques pour modifier la structure du réseau de neurones. Quand j’ai terminé ma thèse, j’ai cherché un poste en entreprise, mais elles n’étaient pas prêtes pour le sujet : ça ne marchera jamais, il n’y pas d’application pour l’entreprise, etc. J’ai donc enseigné pendant plus de 10 ans, sur l’IA et à peu près tous les langages de programmation : Basic, Pascal, Javascript, Silverlight, PHP, Python, C/C++, etc. 

Il y a cinq ans, TeamWork m’a contactée pour lancer une activité autour de l’IA et de la Data au sens moderne de l’advanced analytics. J’ai commencé comme Data Scientist, et aujourd’hui je suis manager de plusieurs équipes : une équipe de Data Science, une équipe de Data engineers et Data architects (Data Flow) et une équipe de Data Integration. Et je travaille encore des projets techniques sur des sujets d’IoT, de data science, d’algorithmique avancée, etc.

Comment définis-tu le métier de la Data Science ?

Le métier a beaucoup évolué au cours du temps. Quand j’ai commencé, le Data Scientist avait de nombreuses casquettes, depuis plusieurs métiers ont été créés, avec des compétences différentes. Un Data Scientist ne peut pas mener un projet de bout en bout, il a besoin de l’aide d’autres profils comme le Data analyst, le Data Architect et le Data Engineer. Idéalement, une entreprise doit avoir dans ses équipes ces 4 profils.

Le Data Scientist travaille sur les modèles, mais il n’a pas les compétences pour les mettre en production. Or, on estime que 85% des projets de machine learning ne vont pas en production, car justement le Data Scientist ne peut pas tout faire seul. Ses compétences principales sont de pouvoir comprendre les données, le métier du client et les algorithmes qu’il utilise. Il ne s’agit pas seulement d’utiliser tous les algorithmes disponibles dans Scikit Learn et de voir lequel fonctionne. Derrière chaque algorithme, il y a des hypothèses, qu’il faut comprendre, et la capacité à pouvoir évaluer le modèle est vitale.

Une bonne accuracy ne suffit pas pour mettre le modèle en production pour autant. Il faut par exemple regarder s’il y a eu des biais dans la création du modèle ou quelles hypothèses ont été utilisées dans la création du modèle. Ainsi, si on utilise une régression linéaire, on doit vérifier que les variables agissent linéairement par rapport à la variable cible. Si l’un est une gaussienne, alors le modèle ne sera pas adapté. Le Data Scientist doit savoir créer ses modèles, mais aussi les évaluer, c’est la partie critique du travail.

Est-ce que les formations de Data Science répondent bien à ces enjeux ?

C’est un peu compliqué. Je me suis formée à une époque où il n’y avait ni outil ni librairie, donc pour coder un algorithme il fallait lire des papiers de recherche. Je ne dis pas que c’était mieux avant, mais les possibilités étaient moins nombreuses, le travail de code d’un algorithme ou d’un réseau de neurones était long et complexe, mais on comprenait ce qui se passait derrière l’algorithme.

Aujourd’hui c’est un peu plus simple, mais le fait d’avoir de nombreuses librairies à disposition fait que beaucoup de Data Scientist se contentent d’appeler des fonctions, sans vraiment comprendre les mécanismes derrière les modèles. Les formations de reconversion vers la Data Science passent très rapidement sur ce sujet, elles s’arrêtent à l’usage de TensorFlow ou Scikit Learn, sans aller dans la théorie et comprendre pourquoi utiliser un modèle plutôt qu’un autre. 

Comment évaluer un modèle ?

Il faut vraiment aller au-delà de l’accuracy. Connaître le recall, la précision, le score F1 c’est déjà un bon début mais ça n’est pas encore suffisant pour évaluer un modèle. Les formations de reconversion sont trompeuses sur ce point, on ne peut pas devenir Data Scientist en 6 mois. On ne cherche pas à avoir le meilleur score, mais à s’assurer qu’on peut déployer algorithme en toute confiance, sachant qu’il est bien adapté au cas d’usage. Cependant, il y aussi de très bonnes formations en Data Science, comme les Masters de l’Université Lyon 2. Et les formations de reconversion sont une très bonne première marche, suivies par une formation en entreprise au sein d’équipes pour acquérir les compétences manquantes.

Selon Eugène Yan « The First Rule of Machine Learning: Start without Machine Learning » – peux-tu commenter?

Pour répondre à un problème, il est inutile de se lancer immédiatement dans du Deep Learning ou des réseaux de neurones. On commence par analyser les données, établir des statistiques, voir si une simple corrélation montre un lien évident entre deux variables. L’idée est de commencer par des choses simples, de passer par l’analyse de données, la programmation classique, et si rien de tout cela ne fonctionne, alors le Machine Learning est peut-être la solution. Là encore, on ne partira pas directement sur du Deep Learning ou du CNN, ce sont des solutions à tester quand tout le reste a échoué avant. Nous avons eu par exemple un client qui voulait une solution de Machine Learning, mais de simples statistiques et des scatterplot nous ont permis de faire un arbre de décision très simple et qui suffisait à régler leur problème.

Sur quels cas d’usage travailles-tu ?

Nous travaillons beaucoup sur le secteur de l’industrie, avec trois grands types de cas : la gestion de la qualité, la maintenance prédictive et l’optimisation des flux.

La gestion de la qualité intervient en amont ou en aval de la chaîne de production (dans ce cas par exemple on vérifie que les produits n’ont pas de défaut, avec des photos et du computer vision). La maintenance prédictive permet d’anticiper les pannes ou les pièces cassées, c’est un besoin vital car cela permet de profiter d’un vide de ligne pour faire de la maintenance, plutôt que de casser en pleine production avec les conséquences néfastes que cela peut avoir : perte des produits, coût des machines arrêtées, temps de remise en route, voire risque d’accident humain. La maintenance prédictive peut avoir des conséquences bien plus graves qu’un simple arrêt de production.

Enfin, le dernier cas d’usage est l’optimisation des flux, par exemple comment stocker les matières premières,  comment placer les machines pour gagner en temps de cycle, où mettre les produits en sortie pour expédier le plus vite possible. Dans certains secteurs comme la chimie, il peut y avoir des contraintes supplémentaires comme deux produits qui ne peuvent pas être stockés ensemble, ou ne pas se croiser, sous risque d’explosion. Le Machine Learning nous aide donc à optimiser ces flux en respectant ces contraintes. Un quatrième cas d’usage commence à émerger avec l’IoT : la localisation de produits avec gestion intelligente. Cela permet de suivre en temps réel des produits, marqués par une puce RIFD ou autre, et d’organiser au mieux leurs déplacements, par exemple, un chariot d’échographie dans un hôpital, une palette dans une usine, etc.

En dehors du secteur industriel, nous avons deux domaines principaux : la détection d’objets (trouver quelque chose sur une image), et le Natural Language Processing. Nous travaillons par exemple sur le question answering : on pose une question, et l’IA doit donner une bonne réponse, en formulant une phrase, à partir d’un corpus documentaire.

Quels sont les principaux pain points ?

S’il a longtemps été compliqué d’industrialiser, ce n’est plus le cas aujourd’hui. On dispose de nombreux outils (Databricks, Dataiku, Sagemaker…) pour déployer les modèles et gérer les pipelines de Machine Learning comme on le fait avec les pipelines de données. Cela inclut le ré-entraînement des modèles et les boucles de feedback, même si je crois qu’il faut toujours garder un humain dans le process : le ré-entraînement et le déploiement automatisé, c’est une faille de sécurité.

La difficulté principale, c’est l’évaluation des modèles. Ce sujet doit être traité avec attention, surtout quand le modèle peut avoir des conséquences. De nombreux Data Scientists préfèrent les gros modèles car l’accuracy est meilleure, j’aurais tendance à privilégier des modèles plus simples, dont la compréhension est meilleure. C’est un point qui est souvent sous-évalué et qui peut amener de mauvaises surprises une fois en production : l’actualité nous a montré de nombreux exemples où l’IA était discriminante. On ne fait pas consciemment un modèle misogyne ou raciste. L’accuracy dans les dataset est peut-être bonne, mais c’est différent quand on confronte le modèle au monde réel, d’où la question de l’évaluation : comment s’assurer que le modèle est vraiment bon ? 

Évaluer les données en entrée et les contraintes du modèle sera le prochain sujet vital dans l’IA. Toutes les grandes entreprises ont été confrontées à ce problème. Amazon, Facebook et Google ne sont pas les plus mauvais sur le sujet, donc nous sommes tous soumis à ce genre d’erreurs.

Comment s’assurer que l’algorithme n’a pas de biais ?

La première difficulté du biais, c’est qu’il faut le reconnaître. Pour le découvrir, il faut le connaître, et donc apprendre les biais potentiels pour pouvoir les rechercher. Sinon, c’est comme chercher une faille de sécurité dans un code sans savoir ce qu’est une faille de sécurité. La plupart du temps, le modèle n’a pas de biais, c’est le dataset qui a été utilisé en amont. Il existe des outils pour rechercher des biais dans un dataset, mais là encore c’est toujours à l’humain de décider s’il y a un biais ou pas. Ensuite, on changera les features, et donc les caractéristiques, pour ne conserver que celles qui ont du sens, et une vraie raison d’être. Par exemple, s’il n’y a que 10% de femmes dans la dataset, alors il faut le rééquilibrer, et voir comment le modèle va apprendre avec ça. Le projet de réglementation européenne de l’IA (dit “AI Act”) aborde d’ailleurs dans son article 5 la question des biais et des discriminations potentielles.

Est-ce que cette réglementation va dans le bon sens ?

Oui, elle va peut être provoquer une prise de conscience, même si a priori elle ne s’applique que dans les cas où l’humain peut être impacté directement par le modèle. C’est en tous cas un pas dans la bonne direction, cela permettra de faire émerger le métier de Data auditeur auquel je crois beaucoup, et dont la mission sera d’analyser les biais dans les datasets et dans les modèles.

Est-ce que selon toi il manque encore des outils dans la plateforme ML Ops ?

On manque encore de fluidité entre les différents métiers. Il y a des plateformes pour les Data Scientist, pour les Data Engineers, et une convergence vers une seule plateforme pourrait aider. Techniquement les plateformes ont vraiment progressé, mais il y a encore à faire sur la facilité de prise en main, sur les mises à disposition de statistiques de base sur chaque champ, etc. 

Et le Cloud ? Tu es AWS ML Hero ?

Au niveau personnel j’ai beaucoup investi sur AWS, et nous travaillons beaucoup avec Sagemaker, mais nous sommes aussi ouverts à d’autres plateformes. Je peux aussi participer à des sujets sur Azure pour la création du modèle, parce qu’un notebook jupyter peut tourner sur les deux plateformes.

Sagemaker reste mon outil préférentiel quand je n’ai pas spécialement de contraintes, car j’y trouve à la fois de nombreux outils et une grande liberté dans ce qui est possible.

Quelle est la maturité des outils de ML sur AWS ?

Je trouve que AWS a toujours un peu d’avance sur Azure, en moyenne on voit arriver les évolutions sur Azure 6 mois après AWS. Je trouve cependant qu’il reste encore beaucoup à faire sur la centralisation des outils. Sagemaker propose beaucoup d’outils, comme Ground Truth pour la labellisation des données, ML Pipeline pour le ML Ops, Sagemaker Studio pour expérimenter, mais il manque encore un point d’accès et une interface uniques. Cela reste un ensemble de briques indépendantes. Mais le domaine bouge très vite, et cette année encore le re:Invent va apporter beaucoup de nouveautés.

Peux-tu nous parler de ton livre “Implémentation en Python avec Scikit-learn” ?

L’objectif est de parler à des personnes qui ne sont pas Data Scientists, ou qui manquent d’expérience et veulent découvrir le domaine à travers un triple approche : le code, la théorie et la méthodologie. Dans la partie code, en Scikit Learn, on détaille comment construire un pipeline, entraîner un modèle et choisir les hyperparamètres. Dans l’approche théorique, on voit ce qui permet de faire fonctionner tout ça, sans aller trop loin dans le détail mathématique mais suffisamment pour comprendre comment fonctionne un arbre de décision, une random forest, ou xgboost, et donc, in fine, permettre de comprendre à quoi correspondent les différents paramètres, comme le nombre d’arbres dans une forêt. Enfin, l’approche méthodologique explique les différentes étapes pour mener à bien un projet.

Cette partie est basée sur CRISP-DM, une méthode qui permet de s’assurer qu’on suit les bonnes étapes dans le bon ordre, d’avoir une documentation et de pouvoir évaluer le modèle. Cette méthode assure de pouvoir passer facilement le projet en production. Pour résumer, on traite le sujet sous l’angle de la programmation, de la théorie et de la méthodologie, dans l’ordre chronologique d’un projet, depuis la compréhension du besoin métier jusqu’au déploiement.

Le mot de la fin ?

Il me semble important de parler du Green AI et donc de l’impact écologique de notre activité. C’est un sujet souvent ignoré bien que l’IA soit avec le mining de cryptomonnaies l’un des plus gros consommateurs d’énergie dans l’IT. On doit se poser la question de la nécessité de produire des modèles toujours plus volumineux, avec toujours plus de paramètres, et entraînés sur des machines toujours plus puissantes.

En passant de GPT2 à GPT3, on multiplie par 100 le nombre de paramètres, est-ce vraiment indispensable ? D’où l’idée de commencer par faire de l’IA sans ML. Commencer par l’analyse des données, cela permet d’orienter sa recherche pour ne lancer que les bons modèles, avec des hyperparamètres réfléchis en amont. L’idée n’est pas de se priver, mais de réfléchir à ce qu’on lance. Comme la puissance de calcul ne coûte pas cher dans le Cloud, on a tendance à faire le contraire et à lancer des modèles sans compter. Oui, nous avons à disposition de plus en plus de puissance, nous avons accès à des machines en quelques secondes, mais nous devons en faire un usage raisonné. Cela ne signifie pas qu’il faut arrêter l’IA, mais il est inutile de dépenser parce qu’on n’a pas pris le temps de mener une réflexion en amont.