Votre processus MLOps est probablement interrompu

Nov 30 2022
Même avec une pile parfaite d'outils MLOps, les équipes ont encore du mal à fournir des produits ML. Donc, si les outils ne sont pas la seule pièce du puzzle, que reste-t-il ? Dans mon dernier message, je soutiens que les éléments restants sont la culture et le processus.

Même avec une pile parfaite d'outils MLOps, les équipes ont encore du mal à fournir des produits ML. Donc, si les outils ne sont pas la seule pièce du puzzle, que reste-t-il ? Dans mon dernier message , je soutiens que les éléments restants sont Culture et Processus.

Plongeons-nous dans le processus MLOps - en particulier, certains des éléments fondamentaux que la plupart des équipes se trompent . À quoi ressemble un processus MLOps réussi et comment les praticiens du ML individuels peuvent-ils aider à construire ce processus ?

En bref - préparez-vous à abattre des murs (image générée par DALL-E)

TL; DR

  • Commencez par un produit, pas un modèle
  • Étudiez les données en production , pas dans votre entrepôt
  • Commencez simplement - avec des données et des modèles
  • Partenaire avec des ingénieurs

Commencez avec un produit ML

La pratique la plus importante qui permet aux projets ML de réussir consiste peut-être à concevoir un produit , pas un modèle . L'un des plus gros pièges que j'ai vus dans des dizaines d'entreprises est de confier des « projets » à des équipes de données, au lieu de les impliquer dans la phase de conception du produit.

Pour créer un produit ML réussi, trois parties prenantes doivent être impliquées dans la conception du produit :

  • PM / Business Stakeholder : A quoi ressemble le succès ?
  • ML Person : Qu'est-ce qui est (probablement) possible avec le ML ?
  • Ingénieur Produit : Qu'est-ce qui est faisable, et quelles sont les contraintes ?

Quelques exemples d'équipes mal alignées :

  • La personne ML optimise la précision du modèle (au lieu des résultats commerciaux !)
  • Projets lancés qu'il n'est peut-être pas possible de résoudre avec ML
  • Le modèle ne respecte pas les contraintes de performance en production
  • Les fonctionnalités sont difficiles ou impossibles à calculer en production
  • La personne ML comprend les compromis entre précision et délai de mise sur le marché
  • Surveillance basée sur le jour zéro pour s'assurer que les résultats commerciaux sont mesurés de manière cohérente
  • L'ingénieur aide la personne ML à comprendre le paysage des données de production
  • Les modèles de SLA sont clairement définis et mesurés

Ceci est un exemple de "bon alignement" dans la dernière section, mais il mérite sa propre section. Presque tous les constructeurs de ML que j'ai vus commencent leurs projets de ML par une enquête sur les données disponibles. Le problème? Ils étudient généralement les données disponibles pour la formation , et non les données qui seront disponibles en production.

Certains pourraient se demander : toutes les données disponibles pour la formation ne devraient-elles pas être disponibles dans un système de production ?

La plupart du temps, la réponse est oui , mais avec un tas d'astérisques. À quelle vitesse ces données sont-elles disponibles ? À quel point ces données sont-elles récentes ? Quelle quantité de prétraitement doit être effectuée sur les données de production pour les rendre consommables ? À qui appartiennent ces données ?

Tant de projets de ML sont bloqués en raison de problèmes avec les données de production. J'ai vu maintes et maintes fois qu'il y a un énorme décalage entre la personne ML et l'ingénieur produit. Un exemple de deux fonctionnalités anodines avec des exigences radicalement différentes :

  • Code postal du domicile d'un utilisateur : probablement très simple à utiliser en production. Interroger une base de données.
  • La position moyenne d'un utilisateur au cours des cinq dernières minutes : probablement un PITA ! Les données de localisation de l'utilisateur sont sur un flux Kafka ? À quel point doit-il être frais ? Les agrégations de streaming sont difficiles ! Probablement des problèmes d'entraînement / de service !
La production n'est jamais aussi facile à naviguer qu'un entrepôt de données (image générée par DALL-E)

Commencez simplement

Probablement le conseil ML le plus courant, mais c'est un bon conseil. Commencez par une solution simple.

Mon ajout — la plupart des gens vous diront de commencer avec un modèle simple , mais il est tout aussi important de commencer avec des données simples ! Pour jouer à partir de l'exemple ci-dessus :

  • Position moyenne d'un utilisateur au cours des cinq dernières minutes : difficile
  • L'emplacement le plus récent d'un utilisateur : probablement beaucoup plus facile !

Vous prenez probablement ce commerce à chaque fois. Vous pouvez toujours créer une V2 avec la fonctionnalité la plus sophistiquée, et il sera beaucoup plus facile de créer des améliorations incrémentielles que de livrer quelque chose de compliqué la première fois.

Rapide et simple est toujours le bon point de départ (image générée par DALL-E)

Partenaire avec des ingénieurs

Il y a de fortes chances que si vous êtes un scientifique des données, il ne soit pas évident de répondre à toutes les questions posées ci-dessus. La dernière fois que j'ai travaillé sur la construction de modèles ML, je n'avais aucune idée de ce qu'étaient les données en continu (et encore moins comment y penser).

La solution consiste à se lier d'amitié avec des ingénieurs et à travailler avec eux tout au long du développement d'un modèle ML. La création de tout projet logiciel ne peut se faire en silo, et le ML en silo est encore pire. Les ingénieurs peuvent aider avec « quelles données sont disponibles », « quelles contraintes dois-je connaître », « quels SLA sont réalisables », et plus encore.

Travaillez avec un ingénieur tôt et souvent. Vous construirez des projets beaucoup plus rapidement.

Conclusion

Ces étapes ne sont pas une vue complète d'un processus MLOps — il y a beaucoup d'éléments mobiles qui mènent au succès (revues de code, CI/CD, surveillance, …). C'est un point de départ. Comme mentionné ci-dessus, la plupart des échecs ML que j'ai vus sont des problèmes d'alignement. Ces directives de processus sont principalement destinées à vous aider à aligner votre équipe pour réussir.

Vous avez besoin d'une base solide pour construire une pratique MLOps exceptionnelle.

David Hershey est investisseur chez Unusual Ventures , où il investit dans l'apprentissage automatique et l'infrastructure de données. David a commencé sa carrière chez Ford Motor Company, où il a créé son équipe d'infrastructure ML. Récemment, il a travaillé chez Tecton et Determined AI , aidant les équipes MLOps à adopter ces technologies. Si vous créez une entreprise d'infrastructure de données ou de ML, contactez David sur LinkedIn .