Intelligence artificielle

Préparer les modèles d'apprentissage automatique pour la production

Préparer les modèles d'apprentissage automatique pour la production


Comment une équipe Data Science d'une banque a mis en production des modèles d'apprentissage automatique

Le voyage vers la production

En tant que scientifique, il est incroyablement gratifiant de pouvoir expérimenter librement en appliquant de nouvelles recherches et en créant rapidement des prototypes. Cette satisfaction peut être assez bien maintenue dans un environnement de laboratoire mais peut diminuer rapidement dans un environnement d'entreprise. C’est en raison de la valeur commerciale sous-jacente à laquelle la science s’appuie dans un contexte commercial - si elle n’ajoute pas de valeur ajoutée aux employés ou aux clients, elle n’a pas sa place! Toutefois, la valeur commerciale ne se limite pas à une simple expérience qui montre une valeur potentielle pour les employés ou les clients. Dans le contexte des modèles d’apprentissage automatique, le seul [business] modèles précieux, sont des modèles en production!

Dans ce billet de blog, je vais vous expliquer le parcours de mon équipe et de moi-même en passant des modèles d’apprentissage automatique à la production, ainsi que quelques leçons importantes apprises en cours de route.

Après avoir construit plusieurs PoC sans pivoter dans les MVP, nous avons réalisé qu’il nous fallait 3 choses pour réussir:

  • Hyper-focus - Les membres de l'équipe ne peuvent pas travailler sur plusieurs projets à la fois. La concentration diluée et les fréquents changements de contexte déconnectent les personnes de leur énoncé de problème (manque d’immersion dans la résolution d’un problème) et entraînent également beaucoup de dettes techniques.
  • Génie logiciel ET Data Science - Tirer parti des modèles d’apprentissage automatique est autant un problème de génie logiciel qu’un problème de Data Science. L'analogie entre le pain aux raisins et les raisins sonne très fort: l'IA, ce sont les raisins, l'ingénierie logicielle et l'intégration système, c'est le pain. Ensemble, ils forment un produit savoureux et précieux, mais ils ne sont ni spéciaux ni désirables par eux-mêmes.
  • Se rapprocher de notre entreprise !! L’alignement avec votre partenaire commercial peut faire ou défaire votre projet - Je ne peux insister assez sur ce point!

Donc, afin de bien concilier ces trois choses, nous avons élaboré un plan de sprint de huit semaines qui ressemblait à celui-ci (du point de vue de Data Science).

Remarque: cet article de blog ne traitera pas des détails techniques impliqués dans le déploiement de production réel. Je vais garder ça pour un autre post.

Plan de cycle de production de 8 semaines

L'intelligence artificielle est un domaine extrêmement accablant! De nouvelles technologies, algorithmes et approches sont développés et publiés chaque jour. Pour cette raison, la recherche est la clé!

Dans notre contexte, nous nous attaquions à un problème de détection d'anomalie et chaque scientifique de données de l'équipe a donc passé le premier sprint à rechercher différentes approches de la détection d'anomalie pouvant être appliquées à notre problème. Ce processus de recherche a consisté à lire des articles, des blogs, à regarder des vidéos, à cloner des dépôts de Github et à jouer avec du code. Toutes ces recherches ont abouti à une vision consolidée du paysage technique nécessaire à la résolution de notre problème.

À la fin de la semaine, chaque scientifique des données devait rédiger une brève revue de la littérature et restituer les résultats de ses recherches à l'équipe.

C’est comme ça que ça se passe pour la modélisation! Donc, pour éviter cela, il est essentiel que vous comprendre les données vous travaillez avec! Pour acquérir cette compréhension, EDA est la voie à suivre!

Pour nous, ce processus était relativement agnostique envers les modèles - nous voulions simplement comprendre nos données. Ce processus impliquait de vérifier la propreté de nos données, de tracer les distributions de données, de mettre en corrélation les résultats et d'extraire des champs potentiellement utiles pour l'ingénierie des caractéristiques. Il existe une tonne de ressources pour aider avec EDA, y compris des bibliothèques vraiment impressionnantes telles que Profil de pandas.

Le résultat de cet exercice a été une compréhension des données à utiliser et de leur utilisation pour l’ingénierie des caractéristiques et la création de modèles.

L'ingénierie des fonctionnalités est sans doute l'étape la plus importante dans la création de modèles d'apprentissage automatique. Peu importe combien de données vous avez ou quelle architecture de modèle que vous appliquez, Mauvaises caractéristiques = mauvais modèle!

Nous avons décidé d'une règle: 1 Data Scientist par modèle. Chaque scientifique de données a consacré ce sprint à l'ingénierie des caractéristiques dans le contexte d'un algorithme d'apprentissage automatique particulier. Il y a eu pas mal d'expérimentation en matière de Feature Engineering, mais l'EDA réalisée lors du sprint précédent, ainsi que l'intuition de nos partenaires commerciaux, nous ont fourni un bon point de départ. Nous nous sommes vite rendu compte qu'il est assez difficile de décider quelles fonctionnalités fonctionnent le mieux pour un modèle particulier. Pour prendre une décision, nous avons exécuté des modèles de base (hyper-paramètres par défaut) sur diverses permutations d’entités et mesuré les performances du modèle par rapport à des mesures de réussite appropriées.

Le résultat de ce sprint était une reproduction de notre sélection de fonctionnalités pour les entreprises et l'équipe, leur montrant les résultats de performances des modèles de base et expliquant l'intuition des fonctionnalités utilisées.

"Les trucs sexy!"

Une idée fausse commune est que le développement de modèle représente la majorité du temps de Data Scientists. Comme nous l’avons découvert, les scientifiques de données consacrent une grande partie de leur temps à nettoyer, explorer et manipuler des données de manière à ce qu’elles puissent être utilisées par un algorithme d’apprentissage automatique et non par le développement de cet algorithme lui-même.

Le but de ce sprint était clair pour nous: Trouvez le cornichon parfait!

Le cornichon parfait

Chaque scientifique de données a développé ses modèles de base en essayant différentes architectures de modèles et hyper-paramètres. Il est important que les mesures de succès appropriées, par exemple Le score F1, la précision, etc. doivent être sélectionnés avant ce sprint, car c’est ce qui détermine les performances de votre modèle.

Le livrable à la fin de ce sprint était Le cornichon parfait - un fichier modèle formé pouvant être amené à la production.

Une fois que nous avons eu un modèle formé qui a produit des résultats avec lesquels nous et notre entreprise étions à l'aise, nous avons poursuivi l'optimisation des modèles. Pour nous, le processus d’optimisation des modèles s’est largement concentré sur l’amélioration des vitesses de prévision de nos modèles. Nous avions une contrainte d'intégration système unique qui nous obligeait à effectuer des prévisions de bout en bout en moins de 100 ms.

À ce stade, la plupart des scientifiques de données s’arrêteraient pour dire «eh bien, mon travail est terminé ».

Data Scientist: «Très bien, j’ai formé mon modèle. Voici…"

Ingénieur logiciel: “Que dois-je faire avec ça?”

Data Scientist: «En production?»

Ingénieur logiciel: “Comment?”

Data Scientist: «Je ne sais pas. C’est ton travail, non?

Une conversion légèrement exagérée, mais le message est clair: Data Science doit rencontrer le génie! C'est ici qu'intervient le refactoring de code.

Chaque modèle doit avoir un code de service (code qui prend les données de production, les transforme de manière appropriée, charge un fichier de modèle et les utilise pour faire des prédictions). Pour nous, un modèle de serveur standard a été créé dans lequel notre code de service a été placé. Ce code serveur est ensuite conditionné en tant que module, conteneurisé et déployé dans un environnement de développement. Une partie intégrante de ce processus de refactoring était une exigence selon laquelle les tests unitaires devaient être écrits pour les méthodes de traitement et tous les tests unitaires devaient réussir avant que votre code ne puisse être fusionné dans Master.

Mon expérience à ce jour a montré qu'il est difficile, mais pas impossible, de faire écrire des scientifiques de données. Il y a beaucoup de friction entre les ingénieurs et les scientifiques des données à ce stade, mais il existe des stratégies pour lisser les choses (je garderai cela pour un autre article de blog).

La sortie de ce sprint servait du code et un fichier de modèle déployé et exécuté dans Dev!

Les deux derniers sprints de notre cycle de production de 8 semaines ont été les suivants:

  • Modèle de formation finale
  • Test de bout en bout

Dans notre contexte, nous avions un jeu de données extrêmement volumineux (> 200 000 000 lignes). Expérimenter sur un si grand ensemble de données n'est pas faisable et pour cette raison, nous avons eu des modèles de base (formés sur de plus petits sous-ensembles de données) déployés pour Dev. L'objectif était de s'assurer que le code et les modèles déployés dans l'environnement de développement fonctionnaient comme prévu par rapport aux environnements locaux.

Plusieurs tests d'intégration ont été exécutés pour vérifier que chaque composant de notre architecture fonctionnait comme prévu dans Dev.

Une fois satisfaits de la performance en développement, nous avons lancé la formation sur l’ensemble de données. Les modèles de cette formation finale étaient les modèles qui devaient être mis en production.

BOOM! Nous étions maintenant prêts pour la production!

De nombreux défis ont été rencontrés sur le chemin de la production. Vous trouverez ci-dessous un résumé de certains de ces défis et des disciplines à suivre pour atteindre notre objectif de livraison:

  • [Actually] exécuter Agile - Des relevés quotidiens, des retros hebdomadaires et une planification de sprint avec les entreprises garantissaient le maintien de l'hyper-focus, le génie logiciel respectait Data Science et l'alignement des activités existait.
  • Outils DevOps - Une solide discipline Git était essentielle au succès de notre déploiement. Oui, les scientifiques de données doivent aussi utiliser Git, il n’ya pas moyen de s’en sortir! Nous avons utilisé JIRA pour gérer nos histoires de sprint, Bitbucket pour gérer notre base de code et Confluence pour gérer la documentation.
  • Documentation - Afin d'assurer la reproductibilité et la continuité, chaque membre de l'équipe devait documenter son code. Cela empêche la formation de dépendances homme-clé. Un exemple de documentation simple comprendrait brièvement les étapes nécessaires au lancement de la formation pour un modèle particulier.
  • L'optimisation prématurée est la racine de tous les maux - nous nous sommes d'abord concentrés sur les performances de base et sur le code pour qu'il fonctionne! Il ne sert à rien d’affecter des ressources à l’optimisation si la base de code ne fonctionne pas en premier lieu. Nous avons aussi rapidement compris que les détails techniques n’intéressaient guère les entreprises. Ils veulent voir des résultats. Montrez-leur des résultats chaque semaine avec des améliorations graduelles et vous gagnerez leur confiance.
  • Automatisation - Le montant de la dette technique liée à la présence de code dans des centaines de blocs-notes Untitled.ipynb devant être exécutés manuellement est effrayant! En général, si quelque chose doit être répété plusieurs fois, automatisez-le! Cela inclut des activités telles que l'extraction de données, la formation de modèles et les tests d'intégration. L'automatisation vous fait gagner beaucoup de temps et peut être aussi simple que de paramétrer un script Python.

Comme je l’ai mentionné au début de ce post, la satisfaction tirée de l’expérimentation est excellente! La satisfaction de voir son travail se dérouler en temps réel est tout aussi géniale, ou du moins pour moi!

Mettre en production des modèles d’apprentissage automatique n’est pas chose facile! Il est important de reconnaître qu’il s’agit bien d’un voyage - un voyage qui demande de la patience, de l’engagement, de la discipline et de la résilience, mais qui vous conduit à une destination peut être extrêmement enrichissant!

Show More

SupportIvy

SupportIvy.com : Un lieu pour partager le savoir et mieux comprendre le monde. Meilleure plate-forme de support gratuit pour vous, Documentation &Tutoriels par les experts.

Related Articles

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Close
Close