Tech.Rocks K2

Meetup : MLOps, c’est quoi et quel est le lien avec la data science ?

Publié le 10 juin 2021

Meetup : MLOps, c’est quoi et quel est le lien avec la data science ?

Dans la famille Ops, on connaît bien DevOps. Et puis, MLOps monte de plus en plus sur le devant de la scène. Quatre tech leaders l’ont présenté durant le meetup Tech.Rocks du 3 juin 2021, en partenariat avec Google Cloud. Replay.
d

Speakers, who’s who :

  • Alexander Usoltsev, Customer Engineer & Machine Learning Specialist chez Google Cloud.
  • Mike Aidane, CTO & CPO chez Tinyclues.
  • Nicolas Fiorini, Senior Machine Learning Engineer chez Algolia.

Ce meetup a été animé par Marie Crappe, Head of Data Science & Analytics chez Veepee.

C’est quoi le MLOps ?

Alexander Usoltsev : MLOps est l’acronyme de Machine Learning Operations. Ce principe s’inspire de celui du DevOps. Techniquement, on applique les mêmes concepts à l’ensemble du développement de l’apprentissage automatique.
ik

Toutefois, le MLOps est un peu différent dans la mesure où il n’est pas seulement question de code ou d’architecture. Il prend aussi en compte les données. Il est ainsi à la croisée de plusieurs disciplines. On a le développement de logiciels d’un côté et le CI/CD. Il y a également toute la préparation des données, l’expérimentation avec l’itération rapide et bien sûr le pipelining.

**Marie Crappe **: Niveau objectifs, ceux du MLOps vise à réussir à passer les modèles de ML en production, à automatiser le maximum de tâches et à optimiser tous les processus. Ça, en vue d’améliorer la qualité des systèmes data science qui tournent en production.

En quoi consiste la notion de pipeline en termes de MLOps ?

Alexander Usoltsev : Chez Google, le MLOps est une culture dont le but est d’unifier le développement de modèles ML. Cette culture cadre la façon de mettre ces modèles en production. Cela se déroule durant plusieurs étapes standards. On commence par préparer les données. On valide ce que l’on exploite. Les modèles sont alors entraînés avec l’algo. Puis, on mesure s’ils atteignent des résultats intéressants. En fonction de scores prédéfinis, on valide ou non la mise en production des modèles.

Le pipeline est cette série d’étapes ainsi que la façon dont elles s’enchaînent. En effet, ce qui est pertinent en MLOps, c’est à la fois la manière dont le modèle est entraîné et toute sa préparation, le pipeline complet. Il est partagé avec toutes les équipes, lors de l’expérimentation, de l'entraînement et du réapprentissage. Ensuite les data scientists prennent le relai, vont le partager avec l’ingénierie.

Comment le ML s’applique dans vos activités ?

Mike Aidane : Tinyclues est l’éditeur d’un logiciel Saas, destiné aux CRM managers essentiellement. À la tech, on est entre 30 et 40 personnes. On amène nos clients à optimiser le ciblage de leurs opérations marketing en appliquant des algorithmes de ML et d’IA. On crée ainsi des modèles. Et concrètement, on en à des centaines en production, plusieurs pour chacun de nos clients.

Nicolas Fiorini : Algolia aussi est une SaaS qui s’adresse principalement aux développeurs. On fournit un moteur de recherche, flexible et qui soit le plus rapide possible. À l’origine, Algolia n’était pas du tout positionné sur le segment de l’IA. Cette initiative est assez récente, date de la fin de l’année dernière. Cela signifie qu’en termes de maturité de processus, nous avons pris le train en route. Maintenant, on s’y emploie avec une équipe d’une vingtaine de personnes composée de data scientist / machine learning engineer / MLOps / etc. Cette organisation pluridisciplinaire amène des challenges, plus particulièrement sur la façon de faire passer des modèles de ML en production. La raison, les métiers de la data science et ceux du machine learning, du MLops sont différents. Il y a parfois des frictions entre ces activités, mais on essaie de lier tout ça et de trouver les meilleures solutions d’un point de vue logistique.

Comment s’est-il installé dans vos entreprises ?

**Mike Aidane **: En ce qui nous concerne, ça s’est passé en plusieurs phases, bien avant que le MLOps n’existe. Pour situer, en 2014, on répondait déjà à notre problématique métier actuelle, mais avec peu de tooling. Pour autant, on a réussi pas mal d’innovations. Mais, on était un peu dans notre monde avec nos propres solutions. En 2019, on s’est posé la question de notre futur sachant que l’idée était de conserver l’avance de notre avantage compétitif, notre expertise IA notamment. Il y avait, à l’époque, de belles évolutions dans le domaine du deep learning qu’il était difficile d’importer dans notre stack. Toutefois, dans le même temps, il y a l’émergence de framework et on s’y est lancé à fond. On est alors parti sur la version open source de Kubeflow. On a essuyé pas mal de plâtre et on a redéveloppé nos modèles. Durant cette phase, on a rassemblé les compétences data science et ML Engineer dans la même équipe. Les technologies, notre processus ont gagné en maturité. Mais, comme il était difficile de trouver des talents compétents dans le ML on a commencé à se faire aider de partenaires.

Une nouvelle phase a ainsi démarré début 2021. Elle a été marquée par un moov vers GCP avec l’utilisation de Vertex. L’idée est d’aller plus vite pour mieux nous concentrer sur notre cœur de métier, à savoir la création de modèles.

Comment sont organisées vos équipes ?

Mike Aidane : On est passé par différents modes. Un où les rôles sont séparés avec des équipes séparées. Puis, un autre avec des rôles séparés dans la même équipe. Comme toutes startups, notre vocation est de sortir des solutions rapidement, la problématique production dépasse tout. Il est ainsi primordial que tout le monde puisse la comprendre et en faire. A ce propos, on a un rôle tournant - le Moscha Schérif - partagé dans toute l’équipe qui permet de s’imprégner de la culture prod et de shooter les éventuels problèmes dans ce domaine.

Nicola Fiorini : C'est capital d'avoir un overlap entre les disciplines. Que des data scientist aient conscience de la façon dont ça tourne en prod même si d’autres l’opèrent. Ça permet d’assurer le transfert end to end. On gagne du temps sur la mise en production des modèles. Ceci étant, la vélocité est beaucoup plus élevée mais en contrepartie on est obligé de trouver des talents avec une culture MLOps et l’envie de faire de la prod.

Data scientist, data engineer, quel est le profil le plus compliqué à recruter ?

Nicolas Fiorini : Difficile à dire. J’ai tendance à penser que c’est data scientist par rapport à la définition qu’on en a. D’ailleurs, on l’a rebaptisé Machine Learning Engineer pour incorporer résolument l’ingénierie.
q

Data engineer est un profil rare par défaut mais qui comprend directement l’ensemble des enjeux. Le rôle est mieux défini. J’ai eu moins de mauvaises surprises lors de recrutements. On était rapidement aligné, alors que, côté machine learning, le screening est beaucoup plus complexe.

**Mike Aidane **: Pour nous, c’est pareil. On parle plus de Machine Learning Engineer que de data scientist.

Data engineer est un rôle qui existe depuis un peu plus longtemps. Il est un peu plus structuré. De la même manière, data product management ça n’existe pas trop en France, c’est pourtant un rôle indispensable à bien des égards.

Un profil « couteau suisse » du machine learning, est-ce envisageable ?

Mike Aidane : Je suis assez tranché sur la question. Le scope de ce qu’on doit faire est hyper large. Employer des gens qui peuvent tout faire ne se tient pas complètement. Il faut se spécialiser. On a eu des data guys sur la partie modèle. Ils pouvaient les gérer sans vraiment comprendre ce qu’il y avait dedans et du coup ça faisait des trucs bizarres.
s

Nicolas Fiorini : Un data scientist doit avoir une compétence sur la mise en prod des modèles et doit avoir de la compétence sur la partie recherche aussi. Il y a une part de couteau suisse dans chaque rôle de la data. Pour autant, je doute que quelqu’un soit vraiment complet end to end, au point d’être bon sur chacune des briques. Je pense qu’il vaut mieux avoir un niveau d’expertise autour duquel on a une zone un peu floue. Cela permet d’être capable de communiquer en dehors de notre zone de confort, puis de se reposer sur des experts.

Quels sont les outils du MLOps ?

Alexander Usoltsev : Parmi ceux qui existent sur le marché, Kubeflow est le numéro 1. Il s’appuie sur Kubernetes pour l’orchestration et l’exécution des étapes. C’est une solution open source que l’on peut utiliser où l’on veut. Du côté de Google Cloud, on a récemment réalisé un grand lancement, Vertex AI, notre plateforme de développement de solution AI. Au sein des nouveaux produits, il y a Vertex Pipelines. L’avantage, tous les artefacts des étapes du pipeline sont sauvegardées au même endroit. Il est ainsi possible d’effectuer plusieurs lancements, de comparer leurs performances et de prendre des décisions. Et puis, cela offre plus de liberté pour lancer de façon rapide.
s

Mike Aidane : Aujourd’hui, on a du Kubeflow pour toute la partie préparation de données. À l’avenir, on projette de la réaliser soit dans Cube ou dans TFX. Les parties training et modèles sont opérées sur Tensorflow.

Nicolas Fiorini : Côté production, on fait actuellement tout sur Batch. On utilise Kubernetes pour faire des calculs. Ensuite, on cache tous ces résultats pour les fournir sous la forme d’API.

Cette infra est custom, on n’a rien de managé pour le moment. On est justement en train d’explorer les solutions en la matière. Il y a bien de nouvelles solutions proposées par Google cloud et d’autres, la problématique est de faire le pari d’une solution pérenne. Pour l’instant, on avance un peu à tâtons avec des solutions maison.

Comment gérez-vous le passage à l’échelle ?

Nicolas Fiorini : On a plusieurs milliers de clients, chez Algolia. Les modèles ML que l’on déploie, on en a potentiellement un par client. Donc, si, par exemple, on doit augmenter le ranking de moteur de recherche pour un client, il faut entraîner ce modèle une dizaine de milliers de fois pour chaque client. Ça veut dire le stocker, le déployer, le cacher… C’est pour ça que l’on part sur du distribué.

Mike Aidane : À Tinyclues, on a plusieurs modèles pour chacun de nos clients. On en a pour prédire l’achat spontané, l’engagement… On doit les entraîner de sorte qu’ils soient bien disponibles au bon moment dans l’interface utilisateurs. Le pari que l’on a fait, en 2019, a été de se dire qu’il fallait paramétrer le maximum de choses. Maintenant qu’on est dans la phase de migration vers une nouvelle stack Kubeflow. On a plusieurs comptes avec le besoin de les augmenter. Donc, on investit beaucoup sur les parties monitoring et alerting pour pouvoir gérer dès qu’il y a un souci. L’échelle fait qu’il est impossible de monitorer à la main. On est obligé d’avoir du tooling et des alertes.
f

Marie Crappe : Chez Veepee, la data science joue un rôle assez important, notamment en matière de personnalisation. C’est le cas, par exemple, pour tout ce qui est prédictif, pour optimiser le pricing ou encore la supply chain. En termes de techno, on a fait le choix d’être full GCP. On utilise pratiquement toutes les briques techniques proposées. On n’est pas encore aujourd’hui sur des stacks avec uniquement des services managés. Pendant plusieurs années, on a d’abord fait beaucoup de choses nous-mêmes. Puis, on s’est mis à utiliser des frameworks. Au fur et à mesure on va maintenant sur du managé. En matière de scaling, on a deux millions de visiteurs uniques par jour. Nos algo doivent répondre en 50 ms. Ainsi, on utilise des techno assez classiques : Tensorflow, des gros clusters kubernetes, etc.

Pour conclure, qu'est-ce qui n'est pas encore automatisable ?

Alexander Usoltsev : Je pense que c’est le traitement de données. On peut automatiser beaucoup de choses aujourd’hui. L’être humain est encore utile aux niveaux de ce que l’on recherche avec les données, ce que l’on va mettre en entrée et ce que l’on veut en sortie.
x

À bientôt, lors du prochain meetup Tech.Rocks ! Restez informés des dates ici : https://www.meetup.com/fr-FR/Meetup-CTO-Tech-Rocks/events/past/