Le temps a détruit mon modèle de machine learning !

Nous avons tous entendu les statistiques selon lesquelles 90 %, 88 % 87 %, 85 % ou un pourcentage incroyable de modèles de machine learning n'arrivent jamais en production. Pour être honnête, je n'ai aucune idée de la façon dont quelqu'un a calculé cela et je suis tout aussi perplexe comme cette personne. Mais ce n'est pas la question. Idéalement, ce nombre importe beaucoup moins que pourquoi de nombreuses entreprises ont du mal à tirer parti de l'apprentissage automatique- encore !

Pour comprendre cela, nous avons eu des conversations d'une heure avec plus de 200 personnes dans un cadre personnalisé afin de comprendre le flux de travail lié à la création de modèles de machine learning, y compris la création de exigences métier, traduction en sprints, collecte de données, création de modèles, mise en production, déploiement, reconversion, tests A/B, débogage, surveillance, observabilité etc. et fermez la boucle entre chaque étape et revenez à n'importe quelle étape de cette séquence. Cela inclut des points de vue variés de la part de chefs d'entreprise, de responsables de l'ingénierie, de chefs de produit, de data scientists, de Devops, d'ingénieurs de données et d'ingénieurs ML ! À la suite de ces conversations qualitatives, nous avons également mené une enquête objective pour avoir une idée plus large des problèmes dominants, dont les résultats peuvent être trouvés. ici.

Bien que l'apprentissage automatique appliqué soit un domaine relativement nouveau et que des problèmes existent dans pratiquement tous les aspects du pipeline, un thème retentissant et important est ressorti de nos conversations :

Le décalage entre chaque étape de création et de lancement de modèles ML réduit la confiance et le moral des équipes d'ingénierie et de direction qui détruisent les modèles ML !

Dans le monde des logiciels, nous avons l'habitude de prendre des décisions fondées sur des données. Nous voulons obtenir des résultats rapidement, effectuer des tests A/B, justifier les coûts et si un projet ne génère pas un retour sur investissement suffisant dans un raisonnable temps, on nous apprend à lui tirer une balle dans la tête. Et temps est une chose que le ML demande beaucoup ! Cela est vrai pour les entreprises de tous horizons, bien que pour des raisons différentes :

1. Startups en phase de démarrage (démarrage jusqu'à la série C)
2. Des mastodontes traditionnels comme Walgreens, Target, Siemens
3. Des géants de la technologie comme Uber, Amazon, Netflix, etc.

Laissez-nous étudier cela en détail.

Startups en phase de démarrage

Souvent, la création et le déploiement de pipelines d'apprentissage automatique nécessitent des compétences variées.

1. Comprendre les cas d'utilisation commerciaux, généralement les chefs de produit
2. Pipelines d'enregistrement et de traitement des données — généralement des ingénieurs de données
3. Expérimentation et création de modèles — généralement des data scientists
4. Création d'API d'inférence et déploiement — généralement des ingénieurs ML
5. Mise à l'échelle des modèles, mise en scène, pipelines de production — généralement une équipe DevOps
6. Cadres de tests A/B, surveillance et observabilité, pipelines de reconversion

Très souvent, les startups ne disposent pas des ressources nécessaires pour recruter différentes personnes pour répondre à l'ensemble des compétences. Les startups croient naïvement qu'elles peuvent embaucher 1 à 2 personnes vraiment intelligentes qui auraient ça y est déjà fait et peuvent résoudre tous les problèmes ci-dessus, mais ils ne se rendent pas compte que de telles créatures mythiques n'existent pas vraiment en dehors des rêves du fondateur !

En fin de compte, le data scientist ou l'ingénieur ML qui a été embauché essaie de se conformer au dicton courant : « dans une start-up, vous faites tout ce qu'il faut pour faire avancer les choses ». Mais la courbe d'apprentissage des technologies dans ce domaine (qui évolue rapidement) est très abrupte et elle finit par prendre beaucoup de temps pour apprendre et mettre en œuvre chacune de ces différentes parties. Bien entendu, les pipelines construits par ce débutant ne sont souvent pas infaillibles et commencent à se briser à différents moments, ce qui déclenche une série de projets de réparation, une raison classique pour épuiser les ressources d'ingénierie ! À ce stade, le fondateur frustré prend une décision difficile... »Bien, nous ne sommes pas encore prêts pour l'apprentissage automatique. Créons un système simple, facile à entretenir et basé sur des règles qui fonctionne simplement, revenons à la baseAlors ! »

Des mastodontes traditionnels comme Walgreens & Target

Dans les grandes entreprises, la raison pour laquelle les modèles ML finissent par prendre trop de temps est autant organisationnelle (voire plus) que technique. En général, certains utilisateurs professionnels, qu'ils soient issus d'un service client ou d'une équipe commerciale, répondent à un appel client et proposent une idée de projet d'apprentissage automatique. Cela passe par les traductions effectuées par les chefs de produit, l'allocation des ressources et les réunions de planification des sprints avant que le résultat ne soit finalement confié à un data scientist. Supposons que cette idée soit l'une des plus simples dans laquelle l'organisation disposait déjà des données à intégrer au modèle (par exemple, le flux de clics de l'utilisateur).

Le data scientist construit ensuite le modèle mais n'a aucun moyen d'obtenir un retour rapide de la part de l'utilisateur professionnel car :

1. Le bloc-notes est trop technique pour les hommes d'affaires
2. Les résultats enregistrés dans des feuilles Excel ne sont pas interactifs
3. Les data scientists n'ont généralement pas les compétences nécessaires pour héberger rapidement le modèle et exposer une API.

Sans les commentaires de l'utilisateur professionnel, comment le DS peut-il savoir...

• Leur modèle résout-il le problème demandé par l'utilisateur professionnel ou dont l'intention a été perdue lors de la traduction ?
• Est-ce qu'ils ne respectent pas certaines conditions limites critiques qui, si elles ne sont pas respectées, rendraient le client furieux ?
• Utilisent-ils des sources de données susceptibles d'introduire des biais dans le modèle ou de nuire à certains segments d'utilisateurs ?

Même si tout ce qui précède est mis en place, qui sait avec certitude si l'intuition initiale de l'utilisateur professionnel était bonne ? Le feedback ultime ne viendrait que de l'utilisateur final. Mais comment mettre le modèle entre les mains de l'utilisateur final ?

Oui, vous l'avez bien deviné. Vous devez impliquer l'équipe d'ingénierie et de produit. Il y aura à nouveau des réunions d'allocation des ressources, la planification des sprints et, à terme, le modèle sera intégré au produit. Cela peut prendre des mois et l'utilisateur professionnel pourrait alors se rendre compte que la priorité du produit a changé ! Et puis la terrible déclaration arrive... »Inutile d'investir davantage de ressources dans ce projet. Ne mettons pas l'argent après le mauvais argent ! »

Des géants de la technologie comme Uber et Amazon

Inutile de dire que ces entreprises sont les plus en avance et qu'elles ne mettent souvent pas de temps, de l'ordre de plusieurs mois, à lancer des modèles ML en production. Mais ce n'est pas rare, même pour ces grandes entreprises. Et ils sont confrontés à un problème tout à fait unique dans ce contexte.

Très fréquemment, les grands géants de la technologie créent leur propre plateforme MLOps qui s'occupe de tout, de la création de magasins de fonctionnalités à la mise en œuvre d'algorithmes, en passant par la gestion des dépendances, le déploiement, l'inférence de modèles et bien plus encore. Construire de telles plates-formes génériques qui fonctionnent pour tous les cas d'utilisation est un problème d'ingénierie difficile et ces systèmes finissent par faire des hypothèses de la forme

1. Voici les bibliothèques les plus courantes que nous attendons des data scientists qu'ils utilisent
2. Tant que le Data Scientist utilise des algorithmes « prêts à l'emploi », tout fonctionne parfaitement, mais s'il souhaite développer son propre modèle, il devra suivre les étapes X, Y et Z.

Examinons ces hypothèses et montrons qu'elles ne sont pas pratiques. Les algorithmes et outils de machine learning s'améliorent constamment et des solutions de pointe sont nécessaires pour résoudre les problèmes de pointe sur lesquels ces entreprises travaillent. Cela signifie que plus l'entreprise essaie de miser sur le ML, plus elle aura besoin de solutions personnalisées et plus elle devra faire appel à des ressources d'ingénierie dédiées !

C'est précisément pour cette raison que très fréquemment, les équipes de data science optent pour des solutions prêtes à l'emploi, ce qui présente un coût d'opportunité énorme. Si le data scientist ou l'entreprise décide d'emprunter la voie la plus difficile, c'est-à-dire de faire progresser sa plateforme et de permettre la création de solutions avancées personnalisées, devinez quoi, vous devez présenter une analyse de rentabilisation, obtenir les bonnes ressources, parler à des personnes de nombreuses organisations. Que cela se traduise par une plate-forme améliorée ou non, cela ajoute certainement des retards !

Et si, après une grande partie de ces investissements, les choses ne se passent pas comme prévu, une fois lancé à l'utilisateur, un renfort est prévu pour emprunter la voie la plus simple pour le prochain projet.

Conclusion et prochaines étapes

Ce thème du ML prend des « modèles »trop de temps», pour diverses raisons, est ressorti clairement de toutes nos conversations avec les utilisateurs.

1. Une start-up qui ne dispose pas de toutes les ressources humaines et de toutes les boîtes à outils nécessaires et qui n'a pas trop de temps pour itérer et trouver la solution optimale, optez pour des systèmes basés sur des règles lorsque vous abandonnez des projets de ML !
2. Les grandes entreprises traditionnelles confrontées à des défis organisationnels abandonnent les projets de ML parce qu'ils ont mis trop de temps à se concrétiser et ne parviennent souvent pas à créer un impact commercial justifiable.
3. Des entreprises technologiques modernes avec Plateformes MLOps optimisés pour la production, mais pas tant pour les expériences ouvertes, finissent par se contenter d'algorithmes et de bibliothèques pris en charge « prêts à l'emploi ». Dans le cas contraire, exploiter tout le potentiel de l'apprentissage automatique prendra trop de temps.

Nous avons été étonnés de constater ce thème commun à un si large éventail d'entreprises...

Les modèles de machine learning prennent trop de temps et retardent l'impact commercial et les cycles de feedback sont l'une des principales raisons pour lesquelles de nombreux modèles de machine learning ne voient pas le jour.

Nous pensons que si nous pouvons mettre en place une solution qui permet une communication fluide entre les utilisateurs professionnels et les data scientists, un feedback rapide des consommateurs pour vérifier l'impact commercial avant de dépenser de nombreuses ressources organisationnelles pour des solutions de machine learning, cela augmentera la confiance et les investissements dans l'apprentissage automatique, et rendra ces investissements beaucoup plus fructueux.

Nous ne prétendons pas avoir encore de solution complète au problème, mais nous y travaillons. Nous discutons avec des personnes intelligentes et cherchons comment nous pouvons atténuer, voire résoudre complètement, ce problème.

Nous sommes convaincus qu'un problème d'une telle ampleur nécessite des points de vue différents. Si vous êtes concerné par ce problème, si vous avez des idées à partager, si vous avez des idées sur la façon de résoudre le problème ou si vous souhaitez connaître nos idées, nous vous invitons à nous faire part de vos commentaires ou à venir nous parler.

Je peux être contacté personnellement à l'adresse suivante : nikunjbjj@gmail.com. Et voici le LinkedIn pour moi et mes cofondateurs...

• Nikunj Bajaj
• Abhishek Choudhary
• Anuraag Gutgutia

Ce blog a été publié pour la première fois sur Medium à l'adresse https://medium.com/@nikunjbajaj/time-killed-my-ml-model-48521fad6c4 le 30 août 2021