Le Machine Learning en interne : le chemin vers de meilleures performances

Les projets de Machine Learning internes sont-ils préférables aux solutions sur étagère ? La réponse est évidente : comme pour la plupart des choses, il est préférable d’avoir quelque chose de sur mesure plutôt qu’une solution générique. Mais pourquoi exactement ? Pourquoi l’offre et la demande de pipelines et de modèles sur étagère sont-elles si conséquentes ? Quels sont les pièges des solutions génériques sur étagère, et où et comment se situe la valeur ajoutée du développement en interne ?

Tout d’abord, quelques clarifications. Le Machine Learning est un domaine de l’intelligence artificielle qui étudie et développe des méthodes d’apprentissage à partir de données. Lorsque je parle de projet de Machine Learning, je fais référence au processus complet de définition d’un problème, de sélection du type de modèle approprié, d’extraction et de création de caractéristiques, d’entraînement et d’évaluation des modèles, etc. Un projet terminé doit aboutir soit à un rapport contenant des informations, soit à un pipeline. Un pipeline peut être exécuté en production et rationalise le processus afin que vos modèles puissent être utilisés de manière répétée et sans problème dans votre entreprise. L’intelligence d’un rapport ou d’un pipeline provient des modèles. Un modèle de Machine Learning s’entraîne sur des données et extrait des tendances ou apprend des paramètres (souvent appelés poids) qu’il peut utiliser pour prédire sur de nouvelles données. Afin d’apprendre des poids, un modèle essaiera de satisfaire un objectif, qui est écrit sous forme de formule et est souvent appelé fonction de perte.

Le conte de fées du Machine Learning et l’histoire non racontée

Si vous ne vivez pas au fond d’une grotte, vous avez peut-être remarqué que le Machine Learning fait actuellement l’objet d’un battage médiatique. C’est un mot magique qui fera paraître votre entreprise plus sophistiquée et plus efficace, améliorant ainsi votre image de marque. Dans le même temps, le Machine Learning promet une vitesse plus rapide ou un meilleur ciblage, entraînant des rendements plus importants.

En réaction, certaines entreprises voient tout ce qui est disponible gratuitement sur Internet (modèles déjà entraînés ou bibliothèques faciles à utiliser), et pensent qu’elles peuvent constituer une petite équipe de data scientist.e.s et obtenir rapidement des résultats avec un minimum d’efforts. En parallèle, des milliers d’entreprises ont vu le jour pour répondre au reste de la demande. Elles peuvent fournir des plateformes de données pour vous aider à former et déployer rapidement des modèles de Machine Learning ; elles peuvent proposer leurs services pour mener à bien votre projet ; elles peuvent vous donner accès à leur plateforme pour que vous puissiez utiliser leurs algorithmes.

Mais ces « solutions » reposent sur un conte de fées : le Machine Learning peut être rendu « facile ». L’accent est mis sur la rapidité et la commodité. Ils veulent vous convaincre (et se convaincre eux-mêmes) que le prétraitement des données est toujours le même, qu’une architecture de modèle peut s’adapter à tous les problèmes et qu’un modèle peut être entraîné avec une intervention humaine minimale.

Et, dans une certaine mesure, ils ont raison. Ces pipelines peuvent vous donner des résultats satisfaisants. Mais seulement si vos données sont déjà propres et structurées, si vos informations ont une composante aléatoire importante, si le problème que vous essayez de résoudre est classique, ou si vous vous contentez d’un « assez bon ». Ce n’est pas le cas chez Lucky cart, ni pour toute entreprise qui souhaite sérieusement exercer son métier grâce au Machine Learning. Nous comprenons que, pour trouver le meilleur résultat, le meilleur pipeline, nous devons d’abord nous lancer dans un voyage.

Qu’est-ce qu’un projet sur étagère ? Comprendre la légende de la carte

Qu’entendons-nous par « projet sur étagère » ? Comme je l’ai laissé entendre précédemment, un projet sur étagère est une initiative dans laquelle le Machine Learning est rendu « facile ». Les exemples les plus extrêmes sont les moteurs de Machine Learning. Ces plateformes vous permettent de télécharger vos données, de sélectionner éventuellement quelques étapes de prétraitement, de choisir un modèle dans une liste prédéterminée, puis d’entraîner et d’évaluer le modèle. Toutefois, un scientifique inexpérimenté, pressé ou démotivé peut également produire un pipeline très générique. 

En outre, comme pour tout, il y a des degrés. Par exemple, l’utilisation d’un modèle pré-entraîné est différente du réentraînement d’une architecture de modèle connue, qui est également différente de la conception de votre propre modèle. Vous pouvez également vous trouver dans un pipeline avec une extraction de caractéristiques en interne mais un modèle sur étagère, ou toute autre combinaison. Je vais vous parler un peu des différentes étapes d’un projet de Machine Learning et des pièges de la pensée sur étagère dans chacune d’elles.

Définition du projet : la première étape qui définira le parcours

Les problèmes posés par les modèles sur étagère commencent avant même que le développement du projet ne débute : avec la définition de l’objectif. Il existe plusieurs problèmes et algorithmes classiques de Machine Learning (clustering classification, prédiction, segmentation). Les projets qui souhaitent utiliser des modèles sur étagère ont tendance à adapter le problème au modèle, plutôt que l’inverse. La question devient donc : où puis-je utiliser un modèle de prédiction (par exemple) pour mon entreprise ? Alors qu’elle devrait être : voici ce dont mon client a besoin ; comment puis-je utiliser le Machine Learning pour m’aider à y parvenir ?

Ce cadrage est beaucoup plus flexible. Vous pouvez découvrir que plusieurs approches complètement différentes existent, chacune avec des avantages et des inconvénients, ou qu’une combinaison ou un enchaînement de modèles fonctionnerait mieux, ou que vous pouvez adapter un algorithme qui n’est pas généralement utilisé pour votre cas. Vous ne saurez jamais si vous avez choisi la bonne approche si vous ne vous posez même pas la question.

Feature engineering : quand l’interne est la seule voie viable

Certains diront que le feature engineering est l’étape la plus critique du Machine Learning. Elle transforme les données brutes en données significatives et compréhensibles pour nos modèles. Un modèle a besoin de plusieurs entrées (appelées caractéristiques) et celles-ci doivent, collectivement, contenir suffisamment d’informations pour que le modèle puisse identifier des schémas utiles ou prédire des comportements. Il est préférable d’avoir un modèle générique avec de bonnes caractéristiques qu’un modèle complexe ou personnalisé avec des caractéristiques non pertinentes dont il ne tirera aucun enseignement.

Dans le pire des cas, le feature engineering sur étagère ne consistera qu’à remplir les valeurs manquantes avec la moyenne, à supprimer les variables fortement corrélées et à normaliser les entrées. Nous avons déjà un problème car la plupart des données brutes ne peuvent même pas être utilisées comme caractéristiques. Cette approche ne commencera à fonctionner que si vous avez un sujet statique (texte, images, objets) ou si quelqu’un a déjà créé des caractéristiques pour vous. J’entends par là que, souvent, le sujet évolue dans le temps et que vos données consistent en de multiples « instantanés » par sujet. Ces « instantanés » doivent être agrégés ou regroupés afin de construire des caractéristiques significatives et utiles. Par exemple : une seule transaction ne suffit pas à caractériser le comportement d’un acheteur. 

En outre, pour réaliser une extraction de caractéristiques remarquables, il est impératif de posséder à la fois une expertise métier et une bonne compréhension de l’objectif du projet. Cela vous aidera à déterminer quelles informations il serait intéressant que le modèle possède et comment combiner les fonctionnalités existantes. Cela devrait vous guider dans l’identification des différentes sources de données que vous pouvez utiliser, et pourrait également vous aider à déterminer la meilleure granularité avec laquelle travailler. De plus, cela vous dira s’il est important de normaliser, d’atténuer ou de mettre en évidence certains aspects des données. Par exemple, si nous voulons regrouper les acheteurs en fonction de leurs préférences d’achat, il est important de normaliser en fonction de la taille du panier. Sinon, vous risquez de ne trouver que les groupes de consommateurs « grands » et « petits », évidents et peu utiles. Dans l’ensemble, il est clair qu’il s’agit d’un processus qui dépend à la fois du secteur et du projet, et qui ne peut être réalisé sur étagère.

Modèles : utiliser la sagesse pour traverser la forêt

Contrairement aux sections précédentes, je ne vais pas essayer de dire que les modèles sur étagère sont mauvais, nous savons tous qu’ils ne le sont pas. Il existe des modèles exceptionnels en ligne, qui ont été entraînés avec des milliers d’exemples. S’ils répondent à vos besoins, il est probablement préférable de les utiliser tels quels ou de procéder à un léger réentraînement, plutôt que d’essayer de les entraîner à partir de zéro. Il existe également de superbes modèles dotés d’une base mathématique solide, des implémentations propres et bien structurées pour ces mêmes modèles, et des architectures de modèles spécifiques qui ont fait leurs preuves dans de nombreux domaines. Ces modèles donnent généralement d’excellents résultats après quelques réglages d’hyper paramètres. Mieux encore, un data scientist peut essayer plusieurs modèles bien établis, évaluer leurs performances et choisir le meilleur.

Cependant, un bon data scientist ne devrait jamais utiliser un modèle qu’il ne comprend pas. D’une part, il peut essayer des modèles qui ne sont pas adaptés à vos données ou à votre problème. Ils changeront aussi aveuglément les hyper paramètres sans comprendre ce qui pourrait fonctionner ou pourquoi. Ils pourraient choisir un modèle qui semble avoir un bon score, sans vérifier correctement pourquoi et s’il y a des biais (l’histoire de l’excellente classification d’images qui différencie les chiens des loups par la présence de neige est bien connue). À l’inverse, ils peuvent rapidement abandonner un bon modèle, alors qu’une légère modification de l’entrée ou un hyper paramètre rarement utilisé aurait permis de le corriger. Ceci sans même parler de l’évaluation des modèles et de la manière dont ils doivent être adaptés au projet, et comment une méthode d’évaluation inadaptée conduira à choisir un modèle qui ne répond pas à vos besoins.

En même temps, comprendre comment ou pourquoi un modèle ne fonctionne pas est impératif pour proposer une meilleure approche. Cette proposition peut être simplement un changement d’hyper paramètre, ou un autre modèle sur étagère. Il peut également s’agir, si nécessaire, d’une modification du modèle afin qu’il puisse mieux gérer la distribution de vos données. Ces changements peuvent se concrétiser par une modification de la fonction de perte, l’ajout d’une régularisation ou l’adaptation de l’algorithme d’optimisation.

Jusqu’à présent, je pars également du principe qu’un modèle classique sert l’objectif de votre projet. Et que, tout au plus, nous devons l’affiner ou l’adapter à votre distribution de données. Cependant, il se peut que le modèle ne réponde pas à votre problème. Dans ce cas, une fonction de perte ad-hoc et/ou des couches doivent être implémentées, créant ainsi un véritable modèle interne. Pour ne citer que quelques exemples que nous avons rencontrés chez Lucky cart :
• Vous devrez peut-être ajouter à votre modèle des connaissances et des contraintes propres à votre secteur d’activité. Par exemple, si le modèle prédit l’absence d’achat, le montant prédit doit également être de 0.
• Vous pouvez avoir besoin d’isoler et de mesurer l’effet d’une entrée spécifique. Cet achat peut-il être attribué au comportement normal, ou à la promotion ? Une promotion différente aurait-elle un autre effet ?
• L’utilisation finale de votre modèle peut demander des exigences plus strictes ou plus souples que le problème initial pour lequel le modèle a été créé. Pour un projet spécifique, nous avons prédit les achats futurs, mais nous étions plus intéressés par le fait de trier correctement le consommateur, plutôt que de prédire le montant lui-même.
• Vous pouvez également chercher à utiliser un modèle prédictif pour apprendre des paramètres, plutôt que de vous intéresser à la sortie elle-même. C’est ainsi que l’on mesure l’élasticité (une mesure qui reflète la sensibilité d’un individu à un changement de prix).

Encore plus qu’avant, un modèle interne a besoin d’un data scientist expérimenté et compétent. Pire encore, un data scientist non qualifié pourrait essayer d’adapter un modèle ou une méthodologie, sans comprendre les principes mathématiques qui le sous-tendent, et aboutir à un pipeline qui n’est pas cohérent dans ses hypothèses. 

Enfin, il convient de noter que les pipelines ne sont pas toujours constitués d’un seul modèle. Il est possible de construire des systèmes plus complexes où différents modèles s’exécutent en séquence ou en parallèle et où leurs entrées et sorties interagissent les unes avec les autres. Là encore, chacun de ces modèles peut être disponible sur étagère ou en interne.

Après la production : ne jamais s’arrêter

Le travail d’un data scientist n’est pas terminé une fois que le pipeline est en production. Le réentraînement périodique des modèles est important pour maintenir de bonnes performances. Il faut rendre à César ce qui appartient à César, certaines plateformes sur étagère proposent un réentraînement facile de leurs modèles. Cependant, au fil du temps, d’autres projets peuvent donner lieu à de nouvelles idées ou fonctionnalités qui peuvent être utilisées pour améliorer les pipelines existants. En outre, à mesure que votre produit évolue, vos besoins changent également et les pipelines doivent être adaptés.

En parallèle, il est également important de mesurer l’impact du pipeline sur votre activité. Pour Lucky cart, nous voulons établir si nos promotions personnalisées sont plus performantes que les promotions aléatoires ou uniformes. De même, chaque fois que nous proposerons un changement à nos systèmes, nous procéderons d’abord à un A/B test pour nous assurer qu’il s’agit bien d’une amélioration. En outre, les pipelines de data science n’existent pas de manière isolée. Ils font souvent partie de processus de calcul plus vastes, comme les simulations, l’optimisation financière, etc., et il est important de comprendre et de surveiller l’impact que le pipeline aura sur le reste du système.

Machine Learning interne : le voyage détermine la destination

L’apprentissage automatique n’est pas facile, et ce n’est pas une bonne idée de prétendre le contraire. L’engouement pour le Machine Learning a conduit de nombreuses entreprises à tenter de mettre en œuvre des pipelines de Machine Learning. Pourtant, tout le monde n’est pas prêt ou capable de s’engager et d’affronter les difficultés de cette entreprise. Un projet précipité, sur étagère, peut vous conduire rapidement à un pipeline fonctionnel, mais rien ne garantit que ce logiciel soit adapté ou optimal pour vos besoins. Plutôt que d’utiliser des solutions génériques, chaque ligne de code doit être choisie avec soin. Ces choix doivent être guidés à la fois par une compréhension approfondie du contexte (les besoins de votre produit, les données, etc.) et par des connaissances techniques sur le Machine Learning.

Chez Lucky cart, nous sommes convaincus de la puissance du Machine Learning en interne. C’est pourquoi l’équipe DATA constitue une part importante de notre entreprise, et nous recrutons constamment de nouveaux Data Scientists. Nous avons de nombreux projets de Machine Learning actifs, nous avons réalisé divers rapports et nous avons développé des pipelines pour, entre autres, la détection des fraudes, la prédiction du contenu du panier d’un acheteur et l’optimisation des promotions.

Tout bien considéré, pourquoi quelqu’un ferait-il affaire avec vous si votre produit est facile à mettre en œuvre et à reproduire ?