MLOps, qu'est-ce que c'est, quel lien avec la data science ?

0:15 Bonjour tout le monde, je m'appelle Alexander, je suis Machine Learning Practice Lead chez Google Cloud France. J'aimerais aujourd'hui, on peut introduire le concept MLOps, qu'est-ce qu'on veut dire quand on parle de MLOps, pourquoi nous chez Google on trouve que c'est important et pourquoi on aide nos clients et nos utilisateurs à faciliter toutes les tâches qui sont liées à MLOps. Donc, qu'est-ce que ça veut dire MLOps? C'est Machine Learning Operational. On a déjà les pratiques de DevOps dans le développement de logiciels modernes. Et techniquement, on peut prendre tous ces concepts et on peut réappliquer comment on fait le développement de modèles d'apprentissage automatique. La différence, par contre, que nos modèles, ce n'est pas que le code, ce n'est pas juste l'architecture de modèle et le code qu'on lance, mais aussi il est la question de données. Donc, on peut contrôler très, très bien comment on écrit nos codes, mais si on ne contrôle pas le côté de données et comment c'était entraîné, on peut arriver à la performance qui n'est vraiment pas intéressante.

1:17 Donc, c'est pour ça, en fait, comme on parle de MLO, c'est croisement de plusieurs disciplines. On peut dire ça. Donc, il y a vraiment le côté du développement de logiciels. Donc, c'est CICD, Continuous Integration, Continuous Deployment. Après, il y a toutes les questions de préparation de données, donc c'est le pipeline. Et bien sûr aussi l'expérimentation, l'itération rapide, parce que dans le data science, on veut que notre expérimentation soit la plus rapide possible, comme ça on teste les idées, on trouve ce qui marche et ce qui ne marche pas. Donc si on croise tout ça, on arrive à cette idée de MLOps. Donc nous, chez Google, la définition que nous on utilise, c'est que c'est une culture d'abord, culture d'ingénierie, à but d'unifier les développements de modèles ML, donc c'est côté de dev, et comment on va mettre ces modèles en production, comment on va opérationner après les modèles développés. Donc tout ça, on fait avec les outils d'automatisation et les monitoring. Il faut bien être conscient aussi, comme on a déployé le modèle, ce n'est pas fini. Il faut après vérifier que tout va bien et au cas où, peut-être qu'on a besoin de relancer notre tâche d'apprentissage et redéployer le modèle avec les données qui ont été mises à jour.

2:27 Donc, si on prend les étapes standards de développement de modèles d'apprentissage automatique, d'abord, il faut qu'on prépare nos données, donc on fait l'extract de nos données. Il faut valider quand même que dans les données, il y a les choses qu'on peut utiliser et il y a l'information qu'on peut profiter, le signal qui est là, qu'il ne faut pas que le bruit. Donc, après, on prépare nos données, on fait le feature engineering, après processing, et la phase, en fait, comme on parle de data science, d'apprentissage automatique, on parle souvent de ça, mais en fait, c'est juste milieu de nos pipelines. complète. Donc, on entraîne nos modèles avec l'algo, je ne sais pas, State of the Art, on a développé quelque chose nous-mêmes. Donc, après, il y a toujours l'histoire de vérifier que nos modèles donnent des résultats intéressants. Donc, on fait évaluation à niveau de métriques, de scores qu'on a prédéfinis. Après, il y a le côté de validation. Donc, parfois, les scores qu'on a, ça peut être intéressant de côté de The Science, mais il y a aussi les questions de métier, de domaine, on va utiliser ça. Donc, il faut bien valider que nos modèles...

3:30 Il est intéressant pour mettre en production. Et donc, si cette phase de validation est passée, on fait le diplôme de modèle. Donc, toutes les étapes ici, si on enchaîne vraiment, on parle maintenant de notion de pipeline. Donc, dans l'approche, on va dire, classique, qu'on trouve actuel presque toujours, le résultat final du travail d'équipe de design, ce sera les modèles entraînés, donc ce sera le fichier binaire, le poids de modèle, quelque chose sauvegardé comme le, je ne sais pas, Python Pickle. Mais si on regarde un peu plus large et on essaie d'appliquer ce concept de MLOps, en fait, ce qui nous intéresse maintenant, c'est les artefacts, pas le modèle entraîné, mais comment c'était entraîné et comment les données étaient préparées. Donc, on parle de concept de pipeline. En fait, nos artefacts, maintenant, ce n'est pas juste le résultat final d'apprentissage, mais vraiment le pipeline complet. Donc, en fait, dans la phase de training, expérimentation et les réapprentissages, on parle et on partage comme artefact le pipeline complet, nos codes complets. Et après, par exemple, l'équipe de The Scientist, ils ont fini de travailler, ils ont maintenant approuvé que ce modèle est intéressant, on peut le mettre en production.

4:39 Donc, ils partagent maintenant avec l'équipe d'ingénierie, pas juste le résultat final par l'artifice binaire, mais ils partagent le code de pipeline complet. Et donc, tout ce qu'on verra ici sur ce slide, ça veut dire que nos artefacts sont sur le pipeline. De côté, deux produits qui existent sur le marché. Le numéro un, c'est ce qu'on a. On a mis en open source le Kubeflow. Dans Kubeflow, il y a le SDK pour le Kubeflow Pipelines. Avec ce SDK, vous pouvez définir tous ces composants à façon transparente. Il va utiliser le Kubernetes pour orchestration et pour exécution de chaque étape. Donc ça, c'est la solution open source. Vous pouvez l'utiliser où vous voulez. Et de côté de Google Cloud, on a deux versions de pipelines. Donc, il y a les versions qu'on appelle hosted. Ça, c'est quelque chose qui va créer le cluster Kubernetes pour vous, qui va gérer ce cluster pour vous. Donc, vous pouvez vous concentrer surtout sur le développement de pipeline lui-même. Mais il y a quand même cette histoire de ressources derrière. Il faut penser, si vous voulez utiliser les...

5:40 Les workers avec les GPU, etc. Donc ça, il faut aller échanger cette configuration de Kubernetes. Et il y a deux semaines, donc le 18 mai, on a eu le grand lancement pendant Google I.O. De Vertex AI, c'est notre plateforme de développement de toutes les solutions liées à l'intelligence artificielle. Et parmi les produits qu'on a lancés, c'est le Vertex Pipelines. Donc ça, c'est les versions serverless. Vous utilisez le même Kubeflow SDK qui est open source. Donc, vous avez toujours la possibilité de porter les pipelines vers n'importe quel environnement. Par contre, si vous utilisez ça sur le Vertex Pipeline sur Google Cloud, maintenant, c'est serverless. Donc, vous pensez vraiment à vos codes ML et tous les côtés infra, comment ça va scaler, etc. Vous déléguez à la plateforme. Donc, vous pouvez aller beaucoup plus haut, plus rapidement. Donc, ce qu'on a aussi... Comme avantage, si on utilise les plateformes comme Vertex Pipelines, tous les artefacts de chaque étape de notre pipeline, ils sont sauvegardés dans le ML Meta Data Store. Comme ça, on peut comparer plusieurs lancements de nos pipelines, plusieurs expériment entre eux, et comparer par exemple les performances et choisir quelle version de nos pipelines, les paramètres qu'on avait utilisés pour lancer le pipeline, et plus intéressant.

6:53 Donc ici, par exemple, ça c'est le côté expérimentation, et aussi le pipeline, on peut visualiser le pipeline complet. Comme ça, on peut voir toujours que ce modèle, il était entraîné avec ces données, avec cette version de code, etc. Donc, on a le model lineage, ce qu'on appelle pour avoir les traces et visibilité pour les questions d'audit interne, faire le debug, etc. Donc nos clients qui sont adaptés les pipelines, ils constatent qu'il y a vraiment beaucoup plus de liberté pour lancer l'expérimentation plus rapide. Par exemple, Spotify, dans le test interne, ils ont vu que c'est cette fois, ils ont fait cette fois plus de possibilités expérimentées. Donc ça veut dire qu'ils cherchent des solutions qui marchent mieux, ils ne passent pas moins de temps de gérer l'infrastructure et plus de temps pour vraiment résoudre leur cas d'usage du côté de Data Science et apprentissage automatique. Donc, j'ai mis quelques ressources ici, si vous êtes curieux, si je vous ai motivé assez pour aller regarder c'est quoi MLOps et Pipelines. Donc, le Vertex IA, c'est la plateforme complète, il n'y a pas que les Pipelines.

7:54 Après, à côté des Pipelines, avec ce lien, vous avez la documentation, donc avec le Quick Start. Vous pouvez tester assez facilement. Et on a aussi publié le best practice pour si vous voulez appliquer les concepts MLOps dans votre pratique. Donc, on a quand même pas mal d'expérience avec l'apprentissage automatique en termes et on a avec les clients. Donc, voilà, on a assemblé tout ça dans ce lien-là. Voilà, c'est tout de mon côté. Merci beaucoup. Donc, je quitte la serre. Merci beaucoup, Alexander. C'était très clair et très efficace. Bonjour à tous, je m'appelle Marie. Je suis Head of Data Science and Analytics chez Veepee, le groupe vente privé, et très heureuse d'accueillir aujourd'hui toutes ces personnes pour parler de MLOps. On a vraiment un super programme. Et du coup, pour reprendre un petit peu, ça vient d'être hyper bien expliqué pour Alexander.

8:56 On parle de MLOps. MLOps, c'est finalement Machine Learning plus l'approche DevOps, que vous connaissez sûrement, basée sur tout ce qui est CICD, orchestration, déploiement, améliorer le monitoring de la santé des systèmes, etc. Donc finalement, c'est quoi le but? Le but, c'est de réussir à passer des modèles de machine learning en production, en automatisant un maximum de tâches, en optimisant tous les process en jeu. Tout ça pour faire quoi? Pour finalement améliorer la qualité des systèmes data science qui tournent en production. au global. Et du coup, on va aborder des sujets assez sympas, puisqu'on va avoir maintenant deux représentants pour ce sujet, Mike et Nicolas, qui vont chacun nous parler de comment ça se passe dans leur société, comment ils abordent ce sujet ML Ops et aussi... Quelles équipes, quels outils faut-il mettre en place pour y arriver?

9:58 Donc, sans plus attendre, Je vous propose d'accueillir Mike tout d'abord. Donc Mike, tu peux monter sur la scène. Mike est CTO et CPO de Tiny Clues. Et il va nous dire déjà un petit peu qu'est-ce que Tiny Clues, parce que je ne suis pas sûre que tout le monde connaisse. Et puis après, on parlera du cœur du sujet. Ça marche, merci, je suis ravi d'être là. Donc, Tanniclo, c'est un éditeur de logiciels en mode SaaS à destination des CRM managers, c'est-à-dire le département marketing et plutôt la partie loyauté que la partie acquisition. Au cœur de notre proposition de valeur, on a aidé nos clients à mieux cibler leur communication marketing. Et la manière dont on fait ça, c'est en appliquant des algorithmes de machine learning, d'intelligence artificielle, sur les first parties de nos clients. Donc, on récupère les first parties de tous nos clients, les logs d'achat, les logs d'interaction, web, email, push, le catalogue produit, la table user.

10:58 Et à partir de là, on arrive à créer des modèles. Pour aider à mieux cibler ces communications. Ce que ça veut dire concrètement, ça veut dire qu'on a des centaines de modèles en production, puisqu'on a plusieurs modèles pour chacun de nos clients à un moment donné. Et d'un point de vue de la taille de notre équipe tech, on est entre 30 et 40, suivant quel scope on considère. D'accord que pour Tiny Clues, le machine learning, c'est vraiment au cœur de votre business model. Et du coup, sur l'équipe tech que tu viens de décrire, est-ce que tu peux nous en dire plus sur la place que prend la data science et les rôles? Oui, alors pour expliquer ça, on a eu plusieurs phases dans notre parcours. Peut-être que si tu me laisses quelques minutes, j'explique les trois phases qu'on a eues. Puisqu'en fonction de ça, on a changé un petit peu la manière dont on interagissait entre le rôle de machine learning engineer, DevOps et data scientist. C'est parti pour les phases.

12:00 Je pense qu'en plus, ce sera assez révélateur de l'évolution de la vision des différents rôles en Asie. C'est l'émergence des concepts ML Ops. Bien sûr. Donc, effectivement, Tani Plus a commencé avant que le MLOps, ça existe. Je pense que la première phase, elle va environ de 2014 à 2019. Et donc, on répondait à la même problématique, mais avec assez peu de tooling. Donc, on a fait beaucoup de code custom, purpose-built pour ces usages-là, sur toute la chaîne, Alex, que tu présentais tout à l'heure, depuis la préparation des données jusqu'au train, à l'inférence, etc. C'était donc la préhistoire du ML App, il n'y avait pas grand-chose. Dans cette phase, on a quand même réussi à avoir pas mal d'innovations. Le challenge qu'on avait, c'est qu'en fait, on ne pouvait pas… à participer à ce qui se passait dans l'industrie puisqu'on avait créé notre propre monde. Donc, par exemple, on avait des problématiques sur les data frames qui sont les mêmes qu'on a vu émerger quand les data frames sont devenus populaires et on avait du mal à contribuer ça dans la communauté open source.

13:04 Donc, ça, c'était un vrai challenge. Ce qui nous a amené à se reposer la question à peu près en début 2019 de quel était le futur pour nous. Évidemment, on a besoin de rester en permanence sur notre avantage compétitif, qui est notre expertise sur le domaine de l'AI, sur les first parties. Il y avait des grosses évolutions sur la partie deep learning qui se passaient, auxquelles on était... difficilement, on pouvait difficilement les porter dans notre vieille stack. Et enfin, on était sur une vieille stack sur Python 2. Et donc, ce qu'on a fait à partir de 2019, c'est qu'on a vu l'émergence des frameworks comme PeeFlow, TFX, etc. C'est-à-dire, on y va à fond là-dessus. Et donc, on est parti sur la version... On était chez AWS, donc on est parti sur la version open source de Kubeflow. On a essuyé pas mal de plates, c'était le début de cette partie-là, et on a redéveloppé nos modèles en utilisant les dernières évolutions du deep learning sur du PyTorch, puis ensuite sur du TensorFlow, comme layer de données de l'Athéna.

14:11 C'est la deuxième phase. Dans cette deuxième phase, on a rassemblé les compétences data science et machine learning engineer. Dans la même équipe, en se disant, il y a des gens qui vont savoir ce que c'est que de la prod, et il y a des gens qui vont savoir ce que c'est que des modèles, et qu'est-ce qu'il faut garder pour qu'un modèle ne drift pas, etc. Tout ça a bien cheminé. Je pense que nous, les technologies ont gagné en maturité sur l'offre. Donc, un bon exemple, c'est qu'on avait réimplémenté notre propre Feature Hatcher in Memory dans TFX. Et on s'est rendu compte que ça existait déjà dans TFX. Et donc, on a décidé de dire qu'on y va à fond sur cette nouvelle génération de framework qui va nous permettre d'aller un petit peu plus loin. Maturation aussi dans notre processus à nous. que tu disais Alex, plutôt, c'est notre corps de business, c'est développer des algos pour des clients. Et c'est presque un opportunity cost d'avoir à faire tant d'infras, tant de plomberie pour faire marcher nos pipelines.

15:15 Et la dernière raison, c'est que c'était difficile de trouver des talents avec ces compétences de machine learning. C'est quand même un petit marché en particulier sur la place de Paris. Et que du coup, tout ce qu'on pouvait se dire, on va se faire aider de partenaires, c'est le cœur de métier. Ça va nous permettre de réallouer tout ce temps-là sur aider plus à la problématique de nos clients plutôt que de faire de la pompe. Voilà. Et donc, c'est la phase qui a commencé en 2021. Elle s'est accompagnée d'un move vers JCP avec l'idée d'utiliser les managed pipelines, donc la partie qui s'appelle maintenant Vertex. Et donc d'être cutting edge un peu sur cette partie-là, de faire le pari que la roadmap de Google sur la partie plumbing, elle ira beaucoup plus vite que ce que nous, on serait capable de faire. Ça va dans le sens, mais c'est vraiment un culture shift. On pourra y revenir, si tu veux, dans la partie Q&A, d'accepter, de dire mon cœur de métier, c'est de développer des modèles et ce n'est pas de faire la partie en dessous.

16:17 On reviendra sur le challenge qu'on a. Voilà. Ok. Merci beaucoup, Mickaël, pour cette introduction. Finalement, une évolution qui semble assez logique. On commence par du fait maison à un moment où le marché n'est pas mature. Quand les technos, les frameworks commencent à bien émerger sur les marchés, finalement, on commence à tester ça. Et puis, tu arrives à cette conclusion, en tout cas, ou ce pari, cette stratégie, en tout cas, d'aller encore plus vers du service manager pour dire, OK, moi, mon cœur de métier, il est là. Le reste, je veux que ce soit le plus efficace, le moins coûteux possible. Et bien, super, entre autres, on va maintenant accueillir Nicolas Fiorini de Algolia. Et donc, il va pouvoir rester sur scène et après l'introduction de Nicolas, on pourra passer au Q&A. Bonjour Nicolas, comment ça va? Très bien, merci. Alors, je pense qu'Algolia est encore plus connu que Tiny Clues, mais je te propose quand même d'en dire deux mots et pareil, de nous expliquer un petit peu quelle est la place du machine learning chez vous et l'équipe qu'il y a derrière.

17:24 Ça marche. Donc oui, Algolia, c'est une SaaS aussi. Principalement pour les développeurs, on fournit un moteur de recherche de manière assez flexible pour permettre aux gens d'implémenter un moteur de recherche sur leur site. L'objectif, c'est d'être le plus rapide possible. Ça a été l'objectif depuis le début de la... Et donc, initialement, Algolia n'était pas du tout positionné sur le segment de l'intelligence artificielle. C'est une initiative qui a été très récente, en réalité. Ce qui fait que, du coup, l'équipe dans laquelle je suis actuellement est relativement petite. On est une vingtaine de personnes, dont une dizaine de data scientists, machine learning engineers, ML ops, bref, un petit peu pluridisciplinaires. Et du coup, cette initiative date de fin d'année dernière, début de cette année, ce qui veut dire qu'au niveau des process, on n'est pas aussi mature que Tiny Clues en l'occurrence, ce qui fait qu'on n'a pas eu trois phases et on est plutôt en train d'essayer de prendre le train en cours de route.

18:31 Donc, le fait que l'organisation actuellement est assez pluridisciplinaire fait que... Il y a des challenges principalement sur la mise en production et notamment comment est-ce qu'on est capable de faire passer des modèles de machine learning en production. C'est principalement dû au fait que le métier de la data science est un petit peu différent de celui du machine learning engineering et du MLOps. Et donc, on essaye vraiment de lier tout ça. Il y a des frictions et on essaye de trouver les meilleures solutions d'un point de vue logistique pour ça. Merci beaucoup. Alors justement, c'est intéressant, Alexander a défini MLOps finalement pas comme étant un job, un rôle au sein d'une équipe, mais comme étant une culture. Vous avez tous les deux là pas mal parlé des enjeux de talent, justement, Mike a parlé de la pénurie des talents, et toi tu viens de parler de beaucoup de titres différents, data engineer, ML engineer, data scientist,

19:33 on en a encore d'autres, ML ops, j'en ai encore entendu d'autres récemment, data ops, il y a plein de choses. C'est quoi un petit peu votre vision à tous les deux là-dessus? Est-ce qu'il y a des rôles bien définis dans vos équipes? Comment vous répartissez les tâches? Et qu'est-ce que vous recrutez en priorité aujourd'hui? Je peux commencer. Donc, effectivement, nous, on a un peu fait les différentes étapes. Par moments, on avait... des rôles séparés, dans des équipes séparées. Après, on a eu des rôles séparés, mais dans la même équipe. Et là, on est quand même en train de se rendre compte que dans une entreprise, en particulier une startup où on a une vocation à sortir des choses rapidement, la problématique prod, elle dépasse tout en fait. Et que du coup, dans les profils qu'on va chercher, alors ils peuvent venir de... d'angles différents, on peut avoir des gens qui viennent d'une partie peut-être plus académique, mais on va toujours essayer de les émerger dans une équipe où on va avoir des gens qui apportent cette culture de la prod, puisqu'on a vocation à ce que tout le monde soit capable de faire de la prod et de comprendre ce que c'est que de la prod, et de ne pas dire moi j'ai fait mon petit modèle, et ensuite ce sera le job de quelqu'un d'autre.

20:43 Que de le mettre en prod et de le gérer en prod. J'ai fait ça avant Tally Clues dans la pub en ligne aux Etats-Unis. Et en vrai, le temps qu'on mettait à sortir quelque chose, la partie modèle allait très très vite et la mise en prod prenait un an. Et donc on avait toujours un an de retard. Et donc ça, on se rend bien compte avec la partie MLF que ce n'est plus possible. D'où la nécessité d'embaucher des gens qui ont toujours la sculpture de la prod. Et une des choses qu'on va faire, c'est qu'on a un rôle tournant dans l'équipe qu'on appelle le Moksha Sherif. Le Moksha, c'est le nom de notre engine. Et en fait, c'est d'être compréhensible, de troubleshooter des problèmes de prod de clients. Et ce rôle-là, il est partagé dans toute l'équipe tech, de manière à ce que tout le monde s'imprègne de cette culture de qu'est-ce que c'est que de servir des modèles en prod pour nos clients. D'accord, donc autant... Vraiment un software engineer qu'un data scientist qui est hyper focus sur de la modélisation va prendre ce rôle de moxa sheriff, c'est ça? Alors, c'est un rôle tournant. Donc, c'est une... Oui, oui.

21:43 Toujours, on a la casquette de shérif. Et puis, ensuite, ça tourne dans les équipes. Et du coup, on va être capable d'être la première ligne de défense dès qu'il y a un problème de prod chez un compte. Et donc, de vraiment comprendre qu'est-ce que ça veut dire de faire de la prod. Ok. Ah, mais c'est... Sûrement une bonne idée à tenter dans plein d'équipes. Est-ce que, Nicolas, chez Algolia, cette pluridisciplinarité au sein des équipes Data Science est aussi importante? Ou est-ce que vous avez une autre approche? Non, c'est globalement la même vision, effectivement. Je pense que c'est capital d'avoir un overlap entre les disciplines. En l'occurrence, le fait d'avoir des data scientists qui ont une certaine conscience de comment ça tourne en prod, même si ce n'est pas eux qui vont le mettre en prod, ça permet d'assurer le transfert end-to-end. C'est quelque chose qui... J'ai eu l'expérience ici dans le passé où j'étais exclusivement data scientist et je fournissais mon modèle à des gens. Qui n'avaient aucune compétence là-dedans, et moi, je n'avais pas vraiment de compétence dans le back-end engineering ou infra.

22:45 Et même postulat, au final, ça a duré un an pour mettre un modèle en prod. Là, on est dans une vélocité qui est beaucoup plus élevée. Mais la contrepartie de ça, c'est qu'on est obligé de trouver des talents qui sont, Comme disait Alexander, dans une culture M&OPS, qui ont envie de faire de la prod, ce qui fait que du coup, on se retrouve dans une discipline qui est déjà rare à la base. Comme tu le disais, Mike, sur le plateau parisien, il y a... Moins de personnes qui font de la data science ou du machine learning. En plus de ça, on vient de rajouter une contrainte qui est que finalement, ces personnes-là doivent en plus être capables de comprendre les enjeux qu'il y a dans la production, ce qui veut dire comprendre la scalabilité des algos et pouvoir interagir avec des gens qui vont les mettre en production derrière. Si je peux me permettre même d'ajouter quelque chose, moi qui recrute et gère pas mal aussi de data scientists, data engineers, etc., difficulté qui est accentuée par le modèle académique, alors sans vouloir critiquer le modèle académique français, que j'aime bien par ailleurs,

23:51 le souci qu'en tout cas moi je constate beaucoup quand on recrute de jeunes data scientists, c'est qu'ils ont une formation mathématique, statistique très poussée, mais souvent ce ne sont pas des software engineers en fait. Et donc non seulement, soit on fait le pari de les recruter et du coup il y a beaucoup de formations à faire derrière pour leur permettre d'avoir cette culture générale et cette capacité à intervenir, à aller jusqu'à la production. Mais en plus, souvent, ils n'en ont pas envie. En fait, souvent, ils ont vraiment bossé sur peu de la modélisation. Ils sont intéressés par le cœur des algos et ils se voient faire ça en entreprise, peut-être pas 100% de leur temps, mais 80 ou 90. Et comme on l'a vu sur le schéma d'Alexander avec les différentes étapes d'un peu le ML lifecycle, on se rend bien compte que cette modélisation, c'est un petit bout au milieu. Et dans les faits, ça va peut-être être 5%, 10% de leur temps, peut-être un peu plus en fonction des entreprises, ce qui peut générer beaucoup de frustration. Donc, en tout cas, je trouve que c'est un vrai challenge à la fois de recrutement, mais aussi de rétention des talents, pour qu'ils ne soient pas déçus par rapport à comment ils s'étaient projetés dans ce job.

24:57 Alors justement, en parlant de recrutement, On a une question de Charles Axel. Quel est le rôle le plus difficile à recruter pour vous, data scientist ou data engineer? Nicolas? C'est difficile à dire. J'ai tendance à penser que ce serait le rôle de data scientist, encore une fois avec cette définition-là. Du coup, on l'a rebaptisé Machine Learning Engineer pour cette raison, pour vraiment incorporer l'engineering à l'intérieur du titre. La raison étant que pour les data engineers, c'est un profil qui est plus rare par défaut, mais qui incorpore directement l'ensemble des enjeux. En tout cas, je trouve que le rôle de data engineer est mieux défini et j'ai moins eu souvent de mauvaises surprises lors du recrutement de data engineering. On était rapidement alignés, alors que le screening côté machine learning est beaucoup plus complexe.

25:57 Donc au final, c'est difficile à dire parce que je ne sais pas si les deux sont vraiment comparables dans la mesure où il y en a un où on a plus de choix. Mais on est plus strict dans ce recrutement. Et dans l'autre cas, on a moins de choix, mais très souvent, on a un alignement plus rapide. Ok. Tu as le même sentiment, Mickaël? Oui. Donc, nous, dans la description Data Sciences, pareil, on parle de Machine Learning Engineer. Quand on a embauché des gens qui viennent avec la casquette Data Scientist, On leur dit, vous allez être projeté dans des équipes qui font des problèmes de préparation, de la productisation du travail de ML, au moins 50% de votre temps. Ensuite, il y a des initiatives qui seront un peu plus research, discovery, qui vont nourrir le backlog, évidemment. Mais de toutes les manières, il y a au moins cette partie-là qui est faite. Data Engineer, c'est un rôle qui existe depuis un petit peu plus longtemps, donc je trouve qu'il est un petit peu plus structuré. Alors, moi en France qu'aux États-Unis, moi j'ai fait la plupart de ma carrière aux États-Unis, et de la même manière que Data Product Management, ça n'existe pas, et c'est un rôle en France, et c'est un rôle qui est indispensable pour pouvoir challenger

27:12 la priorisation de certains sujets. Donc, c'est un rôle qui est en évolution, mais je pense qu'il a un peu plus de maturité que la partie Data Scientist. Mais on voit bien, il change. Tu disais, Nicolas, tout à l'heure, et Marie aussi, que tu avais des gens qui arrivaient sur le marché en disant« moi, je ne veux faire que du modèle» et qu'on est en train de vivre cette transformation tous en même temps et que j'ai l'impression qu'on partage un peu le même constat, c'est-à-dire que les rôles sont en train de se nerguer entre eux. Alors, on va peut-être parler un peu plus techno avec une question, je ne peux pas dire de qui, il y a un petit bug d'interface, je ne vois plus les noms. Mais la question, c'est quels outils utilisez-vous aujourd'hui pour chacune des étapes? Chacune des étapes de ce fameux ML Lifecycle. Mike, tu en as déjà cité plusieurs tout à l'heure. Tu as cité Kubeflow, TFX, etc. Est-ce que tu arriverais à nous refaire un peu la chaîne pour donner une idée de où vous en êtes aujourd'hui? Alors, là où on est en prod aujourd'hui et là où on souhaite aller dans les mois qui viennent, grâce à ce choix qu'on a fait de faire un pari du manage.

28:24 Donc aujourd'hui, on a du cup flow avec des... Dans toute la partie préparation de données, c'est principalement des job pay spark qui prennent la donnée depuis Athena ou S3 en fonction des use cases. La partie learning, training, le modèle est fait sur TensorFlow. C'est un choix qu'on a fait relativement rapidement quand on a fait cette bascule en 2019 en se disant que l'écosystème TensorFlow a l'air de fournir plus de choses autour de la partie modèle et on veut essayer de capitaliser là-dessus. On n'a pas fini la partie préparation de données, je vais y revenir dans deux secondes. Et ensuite, sur la partie inférence, nous, notre problème, c'est qu'on doit faire de la batch inférence sur toute la base utilisateur. Du coup, on a dû faire un peu de trucs custom pour faire ça. Ça tourne sur un cluster OK. Et sur la partie vers laquelle on se projette, c'est plutôt de dire, toute la partie préparation de données, elle va être faite soit dans BQ, soit sur TFX.

29:32 Et qu'ensuite on va pouvoir, à la suite de ça, créer le modèle. Le modèle va être sérialisé et ensuite on va pouvoir appliquer le modèle. Alors on l'espère sur BQML nativement. On tire un petit peu les limites de ce qu'on peut faire aujourd'hui avec BQML puisque ça nous permettra d'avoir la paralysation du scoring sur toute la base d'utilisateurs gratos. Donc de réduire drastiquement les temps d'inférence. Et évidemment, l'idée c'est de prendre ces pipelines qui vont du coup être... penser en moins d'étapes que ce qu'on fait aujourd'hui. Je pense que si on regarde nos pipelines de training, ils doivent avoir 80, 100 étapes. On va pouvoir condenser ça de manière drastique en utilisant TFX. Et du coup, ces pipelines qui sont plus petits, on a vocation à les faire tourner sur du QPLO Manage dans le Vertex. Ok, merci. Je pense que ça fait beaucoup de termes à aller googler pour ceux qui ne connaissent pas encore trop ces technos, ces frameworks et les services managés. Nicolas, chez Algolia, où est-ce que vous en êtes d'un point de vue techno?

30:34 Oui, alors du coup, je vais repartir depuis le début. Au tout début, on fait du Jupiter. Comme pas mal de monde, et on utilise notamment les notebooks fournis par Google Cloud, qui permettent de partager ces notebooks-là de manière un petit peu plus collaborative. Un grand sujet qu'il y a actuellement, c'est comment on passe justement de ces notebooks-là à du code de production. Parce qu'il y a toute une phase de versionning et de test sur plusieurs datasets, et donc on explore un petit peu les outils qu'il y a à ce niveau-là, notamment il y a des solutions qui sont proposées par Databricks, par Weighted Bases, qu'on est en train de regarder, qui permettent de versionner les datasets, de versionner le code, et de faciliter un petit peu plus la mise en production, puisque finalement le code, une fois qu'on a vraiment fait le proof of concept dans un notebook, On peut commencer déjà à basculer sur du code de production, même s'il n'est pas encore en prod, à condition qu'on puisse le faire. versionner et le maintenir comme il faut. Donc actuellement, c'est quelque chose qu'on est en train d'investiguer.

31:36 Ensuite, côté production, actuellement, on fait tout par batch. On n'a pas de machine learning real-time. On regarde un petit peu les solutions à ce niveau-là. Et comme je disais, on n'est pas très mature encore sur la stack de production. Donc en fait, ce qu'on fait, c'est qu'on a... Du calcul par batch en offline des prédictions, qu'on va ensuite... Oui, je ne sais pas, ça n'a l'air d'être que chez moi. Tu as perdu pendant les deux dernières années. Ah, deux minutes carrément. Non, non, non, pas deux minutes, pas deux minutes. Non, 20-30 secondes. Ça marche. Je reprends du coup, j'essaye de voir. Donc du coup, on calcule tout par batch. On utilise des workers Kubernetes pour faire ces calculs par batch. Et ensuite, on va essayer de cacher tous ces résultats pour les fournir sous la forme d'API.

32:42 Donc, c'est relativement custom actuellement comme infra, puisqu'au final, on n'a rien de managé. Et on est justement en train d'explorer un petit peu les solutions managées. La grande problématique qu'on a actuellement, c'est que comme on est nouveau sur le terrain de l'IA, on sait que le choix de... l'architecture va être un choix fort et on n'a pas envie de se planter, surtout quand le paysage est assez mouvant, puisqu'actuellement, il y a des nouvelles solutions proposées par Google Cloud, il y en a par d'autres acteurs. Et du coup, s'engager sur une des solutions, c'est aussi faire le pari que cette solution-là est une solution pérenne. Donc, pour l'instant, on est un petit peu à tâtons là-dessus et en attendant, on utilise des solutions un petit peu maison. Ok, très clair. Et tu viens de partiellement répondre à la question suivante, justement, qui est comment gérez-vous la scalabilité et le déploiement à large échelle de vos modèles, si c'est une problématique que vous avez? Tu viens de citer du caching que vous faites, j'imagine, notamment pour des raisons de performance.

33:44 Tu viens de citer Kubernetes. Est-ce que tu as d'autres éléments à apporter sur ce sujet du passage à l'échelle? Non, mais principalement du contexte que je n'ai pas mentionné jusqu'à maintenant, donc il peut toujours aider à là où on en est. Donc, il faut savoir qu'on a plusieurs milliers de clients et les modèles de ML qu'on va déployer, on risque d'avoir potentiellement un modèle par client. Donc typiquement, si on a un modèle de ranking en particulier, où on veut optimiser le ranking du moteur de recherche pour un client, il va falloir entraîner ce modèle-là une dizaine de milliers de fois. Pour chaque client, ce qui veut dire aussi le stocker, ce qui veut dire le déployer, le cacher, etc. Donc, c'est pour ça qu'on part sur du distribué, principalement. Mais niveau techno, c'est tout ce qu'on utilise actuellement. Kubernetes et du caching ensuite. Et Mike, Tiny Clues, le côté scaling, c'est important pour vous ou pas? Alors oui, comme je le disais au tout début, on a peut-être des centaines de modèles.

34:45 On a plusieurs modèles pour chacun de nos clients puisqu'on a des modèles qui prédisent l'achat spontané, on a des modèles qui prédisent l'achat sachant que j'ai cliqué, on a des modèles qui vont prédire l'engagement. Et donc, on doit traîner tous ces modèles pour chacun de nos clients de manière à ce qu'au moment de l'inférence, ils soient disponibles dans l'intérêt. pour l'interface utilisateur. Donc nous, un des paris qu'on a fait relativement early stage, quand on a recréé la stack en 2019, c'était de dire, en fait, on va essayer de paramétriser le maximum de choses. Et on a écrit des blog posts dessus sur Medium sur comment gérer de la conf... Une seule base de code, un modèle ou plusieurs modèles pour clients, dépendant de la conf qui est gérée par GitHub. uh, C'est une problématique particulière aux gens qui sont multi-tenant. Nico, tu risques d'avoir ce problème un de ces jours. On pourra en discuter avec plaisir. Ce n'est pas simple, cette partie-là. L'autre partie qui vaut le coup de faire un petit disclaimer, c'est qu'on est encore dans la phase de ramp-up de notre migration vers cette nouvelle stack Kubeflow.

35:55 Et donc, on a plusieurs comptes qui sont live dessus et on est dans une phase où on a besoin d'augmenter ça. Donc, on a investi beaucoup sur la partie monitoring, alerting pour pouvoir gérer dès qu'il y a une situation puisque... L'échelle fait que c'est impossible de la monitorer à la main. On est obligé d'avoir du tooling et des alertes qui vont nous dire attention, le modèle drift, attention, le response time n'est pas bon, etc. Donc on a fait cet effort d'investir là-dessus, donc du coup sur notre partie inférence principalement, relativement... Une partie qu'on n'a pas réussi à... À rentrer dans du management. J'ai beaucoup d'espoir sur BQML, on verra. Oui, affaire à suivre. De toute façon, comme on disait, c'est un domaine en pleine expansion. Il y a toutes sortes de briques qui ne sont pas encore hyper bien gérées aujourd'hui. On voit bien en se baladant sur les blog posts ou dans différents meetups qu'il y a encore plein de choses à développer.

36:58 Alors, une nouvelle question. Avez-vous envisagé l'idée d'avoir des citizen data scientists? Je ne suis pas sûre de bien comprendre ce que c'est, mais la deuxième partie de la question peut peut-être aider. Pensez-vous qu'un modèle fait par quelqu'un de non spécialiste puisse être industrialisé et géré de façon propre? J'imagine que par citizen data scientist, ici, on veut dire monsieur tout le monde qui fait de la data science. En tout cas, c'est comme ça que j'interprète. Alors, la réponse pour moi, c'est que ça dépend en fait. Ça dépend de ce qu'on veut faire. Je trouve que dans le métier de MLE, Data Scientist, il y a beaucoup... Les papiers qui montrent les derniers algos, ils sont publiés en fait. Ils expliquent assez bien comment ça marche, pourquoi ça marche, etc. Ce qui est... Ce qui est plus difficile, c'est comment je vais transformer, comment je vais mettre en place ces composants ensemble de manière à ce que ça produise un résultat cohérent pour des cas de l'entreprise, de la valeur business mesurable pour nos clients.

38:05 Et ça, c'est plutôt de l'expérience. Tu vois, nous, quand on a fait le pari de recréer les modèles sur Cuplo, c'était probablement plus facile pour nous qu'avions fait ça à la main pendant 6-7 ans que de quelqu'un qui serait parti d'une feuille blanche. Puisqu'on sait là où il y a des endroits où il faut faire gaffe, attention, là tu vas avoir trop de... Un des exemples, c'est si tu fais des prédictions sur les achats, dans tes logs, tu n'as que les achats, tu n'as pas les gens qui n'ont pas acheté. Donc, qu'est-ce que tu fais quand tu fais ton modèle de prédiction? Et il y a plein de petites choses comme ça qui, assemblées ensemble, font la performance du modèle et que je trouve qu'il est difficile de... d'assourcer entre guillemets vers du data science. Ensuite, il y a des use cases. Ça sera beaucoup plus facile, évidemment. Chez Algolia, vous avez éventuellement des personnes à data scientist de formation, mais qui sont amenées quand même à proposer des modèles.

39:06 Oui, en réalité, un des objectifs d'Algolia, à part être rapide, c'est aussi d'être pertinent. Ce qui veut dire que les software engineers qui ont travaillé sur ces sujets-là pendant plusieurs années, sont des personnes qui sont quand même relativement familières avec l'intelligence artificielle en général. Et donc typiquement, ce ne sont pas des data scientists, ce ne sont pas des machine learning engineers, mais ils ont quand même une très bonne compréhension de ce qui est faisable. Ils ne vont peut-être pas développer des modèles de ML, mais ils vont avoir une approche avec un minimum de statistiques, un minimum de logique qui déjà rentre dans le cadre de l'IA. Et c'est sur ces approches-là qu'Algolia s'est basé pendant plusieurs années, avant de vraiment décider d'aller sur la branche du ML. Par contre, je rajouterais juste un truc sur cette... aspect-là d'outsourcing, une grosse problématique qu'il peut y avoir sur la mise en prod de modèles qui ont été faits comme ça,

40:09 c'est le fait que les datasets sont beaucoup moins contrôlés quand on est en production, et donc typiquement pour prendre le cas d'Algolia, on repose... Quand on fait des prédictions, on repose sur une donnée d'entrée qui est l'input de l'utilisateur. Donc un utilisateur va faire une requête sur le moteur de recherche. Requête qui potentiellement est complètement nouvelle, jamais vue. Et si on n'a pas de réelle connexion entre le développement du modèle et la mise en production, on risque de se retrouver dans des edge cases qu'on n'a pas du tout identifiés. C'est relativement risqué d'avoir une approche comme celle-ci sans qu'on ait cette connexion-là. Je vois. Et Alexander nous a rejoint, je vois. Je voudrais ajouter quelque chose ici, qu'en fait, nous, on a les produits qui s'appellent AutoML. En fait, toute la promesse de AutoML, qu'on peut être un expert dans le domaine, Donc, on comprend en fait ce qu'on veut faire, on comprend nos jeux de données, mais on n'a pas d'expertise dans l'EML. Et avec l'auto-EML, on peut appliquer notre expertise dans le domaine et déléguer aux plateformes de chercher les meilleures architectures, les meilleurs paramètres, entraîner quelque chose.

41:13 Et mettre en production comme les EPI, et on peut après avoir le batch prediction, Donc, en fait, on peut déléguer pas mal de choses vraiment techniques et très liées à l'infra, aux plateformes. Donc, je trouve qu'on va arriver à cette situation qu'on a beaucoup de gens qui peuvent profiter dans leur métier de tous les algos d'IA. mais ils n'ont pas les compétences, le temps. Ou jusqu'à réussir à aller vraiment dans l'éditeur des techniques, dans les frameworks, comme Tensoflow, Preitor, je ne sais pas. Donc, l'auto-mail, je pense qu'on va voir beaucoup plus, pas que sur Google Cloud, mais n'importe quelle, je pense que la plateforme va proposer plus de choses comme ça. Voilà. Beaucoup pour ce complément, Alexander. Et n'hésitez pas à rester avec nous si tu veux compléter pour les prochaines questions. Alors, il nous reste un petit quart d'heure et je vois qu'il y a eu pas mal de questions ajoutées entre-temps, donc on va essayer de faire des réponses à personne de moins, un petit peu plus condensées pour essayer d'adresser tous les sujets. Alors, la prochaine question, à vrai dire, elle est pour moi, qu'en était chez Veepee pour les technos et autres questions. Alors, c'est difficile, du coup, de répondre à tout.

42:16 Mais concrètement, chez Veepee, la data science a un rôle assez important à jouer, comme vous pouvez l'imaginer, notamment toutes les problématiques de personnalisation, mais aussi tout ce qui est prédictif pour optimiser soit le pricing, soit la supply chain, soit plein d'autres choses. En termes de techno, nous, on a fait le choix d'être full GCP. Donc, on est entièrement sur Google Cloud Platform. On utilise pratiquement toutes les briques techniques qui sont proposées dessus. On n'est pas encore aujourd'hui sur des stacks avec entièrement, enfin que des services managés, notamment, on a parlé là de Kubeflow, de TFX, il y a aussi les nouveaux développements de Google. sur la partie experiments, pour essayer d'historiser des modèles, leurs performances, de créer une sorte de marthe, de algo-marthe, finalement. Donc, on n'en est pas forcément là parce qu'un peu comme Tiny Clues, on a commencé il y a plusieurs années.

43:18 Donc, on a d'abord fait beaucoup des choses nous-mêmes, puis on s'est mis à utiliser des frameworks. Et au fur et à mesure, on va sur de plus en plus du manager. Ce qui est sûr, c'est qu'on a parlé tout à l'heure de scaling. Alors, chez Veepee, on a évidemment ces problématiques de scaling. On a 2 millions de visiteurs uniques jour qui se connectent à peu près tous en même temps à 7 heures du matin. Nos algos doivent répondre en 50 millisecondes. Et du coup, on utilise des technologies classiques, on utilise du TensorFlow, TensorFlow Serving, des gros clusters Kubernetes, etc. Et je bouclerai avec juste un exemple qui, pour moi, montre la puissance, l'importance et même l'évidence de l'approche ML Ops. C'est que, justement, sur les algos de personnalisation qui doivent répondre en un temps record, si vous faites travailler vos data scientists de manière trop séparée, j'ai vu une question d'ailleurs dans la liste qui demande un petit peu si on peut réussir à bien séparer les choses en disant voilà votre job en tant que data scientist c'est vraiment de fournir des modèles et puis on va fonctionner quasiment en micro-service au sein des équipes et les autres vont mettre ça en prod et faire tourner

44:26 le problème c'est que vous pouvez augmenter la performance de votre personne personnalisation, en faisant par exemple des réseaux de neurones plus profonds, plus complexes, etc. Sauf que chez nous, ce que ça va faire, c'est que de temps en temps, ça va mettre un peu plus que 50 millisecondes. Du coup, on va passer sur un algo de fallback. Ce sera toujours un algorithme, mais beaucoup moins performant, beaucoup moins intéressant. Et donc, votre nouvel algo, soi-disant plus performant, en tout cas en offline, le sera vraiment moins en online à cause de la réalité de la production. Et du coup, voilà, juste avec ce petit exemple qui est tout basique, on voit l'un. de faire travailler tout le monde ensemble et que chacun comprenne les enjeux et les contraintes de chaque brique de notre lifecycle. Sinon, en fait, très, très, très facilement, on pense faire un pas en avant et en fait, on en fait deux en arrière. Alors, on a une question sur justement les rôles, jusqu'où on peut aller dans la pluridisciplinarité. Avec des outils de plus en plus accessibles, Airflow, Kubeflow, TFX, est-ce qu'on n'entendrait pas à avoir des data guys qui puissent tout gérer de bout en bout?

45:34 D'ailleurs, j'ai pu voir passer de plus en plus des offres qui s'appellent... Full stack data. Je ne sais pas si vous en avez vu aussi, mais je pense que c'est l'idée. Alors, qu'est-ce que vous en pensez? À quel point ça vous semble faisable d'avoir finalement le couteau suisse du machine learning? Moi, je suis assez tranché sur l'histoire parce qu'on a eu des data guys et ce que ça a produit sur la partie modèle, c'est de prendre le modèle comme une black box. C'est un peu ce que tu disais tout à l'heure, ça m'a fait bien sourire Marie. C'est qu'en fait, ils étaient des data guys, donc ils pouvaient gérer une modèle, mais sans vraiment comprendre ce qui se passait dedans. Et du coup, ça faisait des choses un petit peu bizarres. Le scope de tout ce qu'on doit faire, il est hyper large. Et je trouve que faire l'hypothèse qu'il y a des gens qui pourront tout faire, comme il y a eu à un moment des full stack engineers qui pouvaient faire du front et du back, Il y a un moment, il faut se spécialiser. Soit on fait du back bien, soit on fait du front bien. Mais être capable de tout faire, de tout faire. Alors, ensuite, ça dépendra des métiers. Nous, la data science, c'est notre métier.

46:36 Donc, on a besoin d'être excellent à ça. Et donc, on ne peut pas se permettre de pêcher sur cette partie. Il y a d'autres parties, par exemple, sur notre layer applicatif, où c'est moins critique peut-être. Quoique, puisqu'on essaie de simplifier ce qui se passe quand même, où là, il y a plus d'opportunités. Mais sur la partie ML, l'écosystème, il est vraiment compliqué. Et savoir tout maîtriser, ça me paraît dur aujourd'hui. compléter ça du coup juste avec le fait que pour moi c'est important d'avoir une certaine appétence pour plusieurs disciplines donc comme on en parlait plus tôt un data scientist doit avoir une certaine compétence sur la mise en prod de ces modèles là et doit avoir une certaine compétence sur la partie recherche aussi c'est à dire si jamais il y a il y a des nouvelles solutions qui sont développées et les comprendre suffisamment bien pour pouvoir les appliquer à des problématiques nouvelles Donc il y a une part de couteau suisse dans chacun des rôles de la data. Je doute pour autant que quelqu'un soit vraiment end-to-end, en tout cas, si, on peut l'être, mais pas en étant bon sur chacune des briques.

47:44 Et en réalité, je pense que c'est mieux d'avoir un niveau d'expertise clair et défini autour duquel on a une zone un petit peu floue et on est juste capable de communiquer et de faire des proof of concept sur ces aspects un petit peu plus en dehors de notre zone de confort. Et ensuite de reposer sur des gens qui sont vraiment experts aussi en infra ou qui sont experts en recherche ou qui sont experts dans d'autres disciplines pour s'assurer en fait que la communication est bonne. Donc ne pas s'y loter, c'est important, pour autant ne pas espérer qu'une seule personne soit capable de faire vraiment du end-to-end avec autant d'efficacité que plusieurs personnes expertes. C'est comme dans plein de domaines finalement. On n'est pas des shivas, mais il faut qu'on arrive à discuter les uns avec les autres pour comprendre les enjeux articulés en fonction de chacune des spécialités. Ça se voit, moi je trouve souvent en interview les gens qui veulent avoir une expertise et de la curiosité à plein d'autres endroits. Et c'est ça qu'on cherche en fait, des gens qui seront capables d'avoir un dialogue avec différentes équipes parce qu'ils ont le même lingo, sans être des experts.

48:53 Ok. Alors, une question qui est peut-être pour Alexander, vous me direz, quelles sont les étapes du workflow de traitement qui sont aujourd'hui les plus difficiles à automatiser? Ou voir, qu'est-ce qui aujourd'hui ne serait pas encore automatisable? Oui, je pense que c'est la base de base, donc c'est le traitement de données, le feature engineering. Donc, on peut automatiser pas mal de choses aujourd'hui. Encore, je parlais de ce auto-TML, il peut aller, par exemple, il comprend que si c'est timestamp, donc comment on peut décortiquer ça pour avoir c'est quoi le jour de la semaine, etc. Mais sinon, quand même, ce principe garbage in, garbage out, il marche toujours. Donc, je pense que... Comment un être humain peut être utile? C'est de qu'est-ce qu'on cherche avec ces données, qu'est-ce qu'on va mettre en entrée et qu'est-ce qu'on veut que sort de nos algos. Donc ça, je ne crois pas trop qu'on peut automatiser beaucoup. Par contre, les questions un peu mécaniques, les recherches des hyperparamètres, l'optimisation de l'architecture, par exemple, on a publié cette recherche Neural Architecture Search.

49:55 Donc on peut déjà bricoler quelque chose de façon assez automatique de ça. Merci beaucoup pour ces réponses, Alexander. On a le temps pour une dernière question, peut-être deux grands maximums. Et c'est une question un peu éthique. Avez-vous envisagé d'appliquer FairML Algorithms pour détecter du biais dans vos modèles? Alors déjà, est-ce que chez TinyClues et Algolia, vous considérez avoir des enjeux particuliers d'éthique qui demandent de faire attention à... À des biais. De commencer clairement clairement la raison étant que pour entraîner nos modèles de machine learning on va reposer principalement sur les logs donc les logs sont les signaux qu'on va utiliser pour savoir si quelque chose a été positif ou négatif on va se baser sur ça pour faire nos entraînements et les logs comme je le disais sont des inputs utilisateurs donc on a absolument aucun contrôle dessus ce sont des gens qui vont sur un site de e-commerce, de news, de tout ce qu'ils veulent, et qui vont taper des recherches pour espérer trouver des résultats.

50:58 C'est sur la base de ces logs-là qu'on va ensuite entraîner des modèles de machine learning. Donc évidemment, il y a des biais. Par contre, actuellement, comme c'est assez récent, on n'a pas de... On n'a pas de pratique automatisée sur l'identification de ces biais-là, donc c'est la responsabilité des gens qui développent les modèles de ML pour les identifier en amont, essayer de voir à quel point les modèles qu'on développe sont propices à ces biais-là, pour pouvoir le détecter à la limite, mais c'est encore assez rudimentaire. De manière à ce que les gens puissent se connecter à ces biais-là. automatisé, c'est beaucoup de manuels et de data analysis qu'on fait pour ça. Mais c'est quelque chose qui est très important, en tout cas, pour l'entreprise. Merci Nicolas. Est-ce que Alexander ou Mickaël, vous avez des choses à ajouter là-dessus? Ou on prend une toute dernière question? Donc nous, on a vraiment un groupe de recherche dédié à Fairness et AI. Et on a pas mal de choses en open source. Par exemple, il y a le What If Tool, où vous pouvez brancher n'importe quelle modèle que vous avez entraîné.

52:01 Et vous pouvez jouer en fait, quel type de caractéristiques ont entré. Vous changez quelque chose et vous voyez comment les prédictions basculent. Comme ça, vous pouvez tester pour les biais. Et au niveau de Google Cloud Platform, on a les outils d'explanabilité qui sont intégrés pour tous les types de données. Donc, pour les images, on peut visualiser, par exemple, quels pixels participaient plus pour la prédiction finale dans la classification d'images. Pour le texte, j'ai vu qu'on a fait en UK, pour une boîte de recherche, en fait, ils ont les essais de médicaments. Et après, à partir de ces médicaments, ils ont cherché, en fait, quels effets secondaires participaient plus par algo pour définir est-ce que ça passe ou pas le test. Donc ça, c'est le Language Interpretable Tools. Je vais mettre quelques liens dans le chat plus tard, comme ça vous pouvez regarder. Donc il y a vraiment le côté open source, vous pouvez utiliser vos volets et s'intégrer aussi dans les outils qu'on propose sur le Vertex AI. Ok, avec plaisir.

53:02 Merci d'avance pour les liens. Et du coup, on va prendre une toute dernière question sur le réentraînement. Une grande question à Machine Learning. Comment vous déterminez le moment de réentraîner vos modèles? Alors, je peux bien commencer. Alors nous, évidemment, la fréquence, elle va dépendre du client, en fait. On a des clients où il y a d'abord beaucoup d'activités saisonnières. Donc, on a beaucoup de clients, par exemple, dans le travel. Et donc là, il ne faut pas louper les... Donc, il y a des moments dans l'année où on va vouloir entraîner de manière un peu plus régulière. Ensuite, la taille du client va avoir un impact. Évidemment, plus on a de données, plus le modèle va être stable. Et du coup, ça marchera pas mal. Chez les petits clients, ensuite, il y a une question de taille de l'offre. C'est-à-dire que chez des petits clients, le réentraîner trop régulièrement ne sera pas un impact foudroyant sur la performance et du coup, on le fait plutôt un peu long. Donc la taille et l'industrie.

54:06 Ok, et côté Algolia, c'est une problématique importante, le rentrainement ou pas? Oui, c'est principalement une problématique produit de notre côté, dans le sens où il va falloir définir un petit peu le problème business à la base, donc ça rejoint ce que disait Mike sur le... Typiquement, on a des clients qui sont dans l'e-commerce où effectivement, il y a des cycles de vente. Et donc forcément, on a envie de mapper un petit peu ça. Mais ces problématiques-là sont systématiquement gérées finalement d'un point de vue, par l'humain. Et donc, on définit un... On définit un cycle, on définit un pattern de réentraînement, mais cette définition-là, qui est ensuite automatisée, la définition même, elle est faite par un humain derrière pour comprendre quel est le rythme de réentraînement qui a le plus de valeur pour nos clients. Pour conclure, si je peux me permettre, pour moi, la... Et puis du coup, par extension ML Ops, il y a une valeur hyper importante derrière qui est le pragmatisme, puisqu'on essaie de faire tourner de manière efficace les systèmes en production.

55:15 Et sur ce sujet du réentraînement, comme sur plein de sujets de machine learning, pour moi, il faut aussi remettre le pragmatisme au centre des développements et des réflexions. On a tendance à penser que plus on réentraîne, mieux c'est, parce qu'il y a plus de données, elle est plus fraîche, etc. Mais vraiment ça vaut le coup pour chaque use case pour chaque algorithme de vérifier ça et on peut vraiment avoir des surprises en l'occurrence vous voyez chez Veepee on en a eu on s'est rendu compte que réentraîner nos systèmes de recommandations ça leur apportait pas du tout de valeur or c'est des entraînements extrêmement coûteux avec 60 millions de membres et un historique de 15 ans vous pouvez bien imaginer ce que représente un entraînement de réseau de neurones. Et en fait, on s'est rendu compte qu'il n'y avait absolument aucune dérive. Ces algos performaient potentiellement pendant 6, 7, 8 mois d'affilée. Sans bénéficier aucunement d'un réentraînement. Ce n'est pas vrai tout le temps.

56:16 N'empêche que du coup, ça mérite un petit test avant d'aller mettre un monstre en production qui vient faire du réentraînement daily, hourly ou même en streaming. Bonne chose à tester. Bon. J'espère que vous avez bien profité des dessins de Tommy Dessine, qui était pas sur le thème police, cow-boy et compagnie aujourd'hui. Je pense que Noémie va nous rejoindre pour un petit mot de conclusion. En tout cas, un très grand merci, Alexander, Mike, Nicolas, pour vos interventions. Il reste plein de questions à droite, mais on a un petit moment de networking, je crois, dans lequel certains pourront peut-être obtenir des réponses supplémentaires.