Apprentissage automatique industriel : 10 principes de conception
De nos jours, de nouveaux services, applications et autres programmes importants sont créés chaque jour qui permettent de créer des choses incroyables : du logiciel de contrôle d'une fusée SpaceX à l'interaction avec une bouilloire dans la pièce voisine via un smartphone.
Et, parfois, tout programmeur novice, qu'il soit un startuper passionné ou un Full Stack ou Data Scientist ordinaire, se rend tôt ou tard compte qu'il existe certaines règles de programmation et de création de logiciels qui simplifient grandement la vie.
Dans cet article, je décrirai brièvement 10 principes sur la façon de programmer l'apprentissage automatique industriel afin qu'il puisse être facilement intégré dans une application/un service, sur la base de la méthodologie App à 12 facteurs. . Mon initiative est de faire connaître cette technique, qui peut aider de nombreux développeurs et spécialistes de la science des données.
Cet article est le prologue d’une série d’articles sur le Machine Learning industriel. J'y parlerai plus en détail de la façon de créer un modèle et de le lancer en production, de créer une API pour celui-ci, ainsi que des exemples de divers domaines et entreprises qui ont intégré le ML dans leurs systèmes.
Principe 1 : une base de code
Certains programmeurs au début, par paresse de comprendre (ou pour une raison qui leur est propre), oublient Git. Soit ils oublient complètement le mot, c'est-à-dire qu'ils se lancent des fichiers dans le lecteur/se contentent de lancer du texte/envoient par des pigeons, soit ils ne réfléchissent pas à leur flux de travail et s'engagent chacun dans leur propre branche, puis dans la maître.
Ce principe stipule : avoir une base de code et de nombreux déploiements.
Git peut être utilisé aussi bien en production qu’en recherche et développement (R&D), dans lesquels il n’est pas si souvent utilisé.
Par exemple, dans la phase de R&D, vous pouvez laisser des engagements avec différentes méthodes et modèles de traitement des données, afin de sélectionner ensuite le meilleur et de continuer facilement à travailler avec lui.
Deuxièmement, en production, c'est une chose irremplaçable - vous devrez constamment examiner comment votre code change et savoir quel modèle a produit les meilleurs résultats, quel code a finalement fonctionné et ce qui s'est passé qui l'a empêché de fonctionner ou a commencé à produire des résultats incorrects. . C'est à cela que servent les commits !
Vous pouvez également créer un package de votre projet, en le plaçant, par exemple, sur Gemfury, puis en important simplement des fonctions pour d'autres projets, afin de ne pas les réécrire 1000 fois, mais nous en reparlerons plus tard.
Principe 2 : Déclarer et isoler clairement les dépendances
Chaque projet possède des bibliothèques différentes que vous importez de l'extérieur afin de les appliquer quelque part. Qu'il s'agisse de bibliothèques Python, de bibliothèques d'autres langages à des fins diverses, ou d'outils système, votre tâche est la suivante :
- Déclarez clairement les dépendances, c'est-à-dire un fichier qui contiendra toutes les bibliothèques, outils et leurs versions utilisés dans votre projet et qui doivent être installés (par exemple, en Python, cela peut être fait en utilisant Pipfile ou Requirements.txt. A lien qui permet de bien comprendre : )
- Isolez les dépendances spécifiquement pour votre programme pendant le développement. Vous ne souhaitez pas constamment changer de version et réinstaller, par exemple, Tensorflow ?
De cette façon, les développeurs qui rejoindront votre équipe à l'avenir pourront se familiariser rapidement avec les bibliothèques et leurs versions utilisées dans votre projet, et vous aurez également la possibilité de gérer eux-mêmes les versions et les bibliothèques installées pour un projet spécifique. projet, qui vous aidera à éviter l'incompatibilité des bibliothèques ou de leurs versions.
Votre application ne doit pas non plus s'appuyer sur des outils système pouvant être installés sur un système d'exploitation spécifique. Ces outils doivent également être déclarés dans le manifeste des dépendances. Ceci est nécessaire afin d'éviter les situations où la version des outils (ainsi que leur disponibilité) ne correspond pas aux outils système d'un système d'exploitation particulier.
Ainsi, même si curl peut être utilisé sur presque tous les ordinateurs, vous devez toujours le déclarer dans les dépendances, car lors de la migration vers une autre plate-forme, il se peut qu'il ne soit pas là ou que la version ne soit pas celle dont vous aviez initialement besoin.
Par exemple, votre fichierRequirements.txt pourrait ressembler à ceci :
# Model Building Requirements
numpy>=1.18.1,<1.19.0
pandas>=0.25.3,<0.26.0
scikit-learn>=0.22.1,<0.23.0
joblib>=0.14.1,<0.15.0
# testing requirements
pytest>=5.3.2,<6.0.0
# packaging
setuptools>=41.4.0,<42.0.0
wheel>=0.33.6,<0.34.0
# fetching datasets
kaggle>=1.5.6,<1.6.0
Principe 3 : Configurations
Beaucoup ont entendu des histoires de développeurs qui téléchargent accidentellement du code sur GitHub dans des référentiels publics avec des mots de passe et d'autres clés d'AWS, se réveillant le lendemain avec une dette de 6000 50000 $, voire XNUMX XNUMX $.
Certes, ces cas sont extrêmes, mais très significatifs. Si vous stockez vos informations d'identification ou d'autres données nécessaires à la configuration dans le code, vous faites une erreur et je pense qu'il n'est pas nécessaire d'expliquer pourquoi.
Une alternative consiste à stocker les configurations dans des variables d'environnement. Vous pouvez en savoir plus sur les variables d'environnement .
Exemples de données généralement stockées dans des variables d'environnement :
- Noms de domaine
- URL/URI d'API
- Clés publiques et privées
- Contacts (mail, téléphones, etc.)
De cette façon, vous n'avez pas besoin de modifier constamment le code si vos variables de configuration changent. Cela vous permettra d’économiser du temps, des efforts et de l’argent.
Par exemple, si vous utilisez l'API Kaggle pour effectuer des tests (par exemple, téléchargez le logiciel et exécutez le modèle via celui-ci pour vérifier lors de l'exécution que le modèle fonctionne bien), alors les clés privées de Kaggle, telles que KAGGLE_USERNAME et KAGGLE_KEY, doivent être stocké dans des variables d'environnement.
Principe 4 : Services tiers
L'idée ici est de créer le programme de telle manière qu'il n'y ait aucune différence entre les ressources locales et tierces en termes de code. Par exemple, vous pouvez connecter à la fois MySQL local et tiers. Il en va de même pour diverses API telles que Google Maps ou l'API Twitter.
Afin de désactiver un service tiers ou d'en connecter un autre, il vous suffit de modifier les clés dans la configuration dans les variables d'environnement, dont j'ai parlé dans le paragraphe ci-dessus.
Ainsi, par exemple, au lieu de spécifier à chaque fois le chemin d'accès aux fichiers avec des ensembles de données dans le code, il est préférable d'utiliser la bibliothèque pathlib et de déclarer le chemin d'accès aux ensembles de données dans config.py, de sorte que quel que soit le service que vous utilisez (par exemple exemple, CircleCI), le programme a pu connaître le chemin d'accès aux ensembles de données en tenant compte de la structure du nouveau système de fichiers dans le nouveau service.
Principe 5. Construction, publication, exécution
De nombreuses personnes travaillant dans la science des données trouvent utile d'améliorer leurs compétences en rédaction de logiciels. Si nous voulons que notre programme plante le plus rarement possible et fonctionne sans échec le plus longtemps possible, nous devons diviser le processus de publication d'une nouvelle version en 3 étapes :
- Stage assemblage. Vous transformez votre code nu avec des ressources individuelles en un soi-disant package contenant tout le code et les données nécessaires. Ce package est appelé un assemblage.
- Stage libération — ici nous connectons notre config à l'assembly, sans lequel nous ne pourrions pas publier notre programme. Il s’agit désormais d’une version entièrement prête à être lancée.
- Vient ensuite la scène courir. Ici, nous publions l'application en exécutant les processus nécessaires à partir de notre version.
Un tel système de publication de nouvelles versions d'un modèle ou de l'ensemble du pipeline vous permet de séparer les rôles entre administrateurs et développeurs, vous permet de suivre les versions et d'éviter les arrêts indésirables du programme.
Pour la tâche de publication, de nombreux services différents ont été créés dans lesquels vous pouvez écrire des processus à exécuter vous-même dans un fichier .yml (par exemple, dans CircleCI, il s'agit de config.yml pour prendre en charge le processus lui-même). Wheely est doué pour créer des packages pour des projets.
Vous pouvez créer des packages avec différentes versions de votre modèle d'apprentissage automatique, puis les empaqueter et vous référer aux packages nécessaires et à leurs versions pour utiliser les fonctions que vous avez écrites à partir de là. Cela vous aidera à créer une API pour votre modèle, et votre package pourra être hébergé sur Gemfury, par exemple.
Principe 6. Exécutez votre modèle comme un ou plusieurs processus
De plus, les processus ne devraient pas avoir de données partagées. Autrement dit, les processus doivent exister séparément et toutes sortes de données doivent exister séparément, par exemple sur des services tiers comme MySQL ou autres, selon vos besoins.
Autrement dit, cela ne vaut absolument pas la peine de stocker des données dans le système de fichiers du processus, sinon cela pourrait entraîner l'effacement de ces données lors de la prochaine version/modification des configurations ou du transfert du système sur lequel le programme s'exécute.
Mais il existe une exception : pour les projets de machine learning, vous pouvez stocker un cache de bibliothèques afin de ne pas les réinstaller à chaque lancement d'une nouvelle version, si aucune bibliothèque supplémentaire ou aucune modification n'a été apportée à leurs versions. De cette façon, vous réduirez le temps nécessaire au lancement de votre modèle dans l’industrie.
Pour exécuter le modèle en plusieurs processus, vous pouvez créer un fichier .yml dans lequel vous spécifiez les processus nécessaires et leur séquence.
Principe 7 : Recyclabilité
Les processus exécutés dans votre application modèle doivent être faciles à démarrer et à arrêter. Ainsi, cela vous permettra de déployer rapidement des modifications de code, des modifications de configuration, d'évoluer de manière rapide et flexible et d'éviter d'éventuelles pannes de la version de travail.
Autrement dit, votre processus avec le modèle devrait :
- Réduisez le temps de démarrage. Idéalement, le temps de démarrage (à partir du moment où la commande de démarrage a été émise jusqu'au moment où le processus entre en service) ne devrait pas dépasser quelques secondes. La mise en cache de la bibliothèque, décrite ci-dessus, est une technique permettant de réduire le temps de démarrage.
- Terminez correctement. Autrement dit, l'écoute sur le port de service est effectivement suspendue et les nouvelles demandes soumises sur ce port ne seront pas traitées. Ici, vous devez soit établir une bonne communication avec les ingénieurs DevOps, soit comprendre vous-même comment cela fonctionne (de préférence, bien sûr, cette dernière solution, mais la communication doit toujours être maintenue, dans tout projet !)
Principe 8 : Déploiement/intégration continu
De nombreuses entreprises utilisent une séparation entre les équipes de développement et de déploiement d'applications (ce qui rend l'application disponible aux utilisateurs finaux). Cela peut considérablement ralentir le développement de logiciels et les progrès dans leur amélioration. Cela gâche également la culture DevOps, où développement et intégration sont, en gros, combinés.
Ce principe stipule donc que votre environnement de développement doit être aussi proche que possible de votre environnement de production.
Cela permettra:
- Réduisez le temps de sortie de plusieurs dizaines de fois
- Réduisez le nombre d’erreurs dues à l’incompatibilité du code.
- Cela réduit également la charge de travail du personnel, puisque les développeurs et les personnes déployant l’application forment désormais une seule équipe.
Les outils qui vous permettent de travailler avec cela sont CircleCI, Travis CI, GitLab CI et autres.
Vous pourrez rapidement apporter des ajouts au modèle, le mettre à jour et le lancer immédiatement, tandis qu'il sera facile, en cas de panne, de revenir très rapidement à la version de travail, afin que l'utilisateur final ne s'en aperçoive même pas. Cela peut être fait particulièrement facilement et rapidement si vous disposez de bons tests.
Minimisez les différences !!!
Principe 9. Vos logs
Les journaux (ou « Logs ») sont des événements, généralement enregistrés au format texte, qui se produisent au sein de l'application (flux d'événements). Un exemple simple : "2020/02/02 - niveau système - nom du processus". Ils sont conçus pour que le développeur puisse littéralement voir ce qui se passe lorsque le programme est en cours d'exécution. Il voit la progression des processus et comprend si cela se déroule comme le développeur lui-même l'avait prévu.
Ce principe stipule que vous ne devez pas stocker vos journaux dans votre système de fichiers - vous devez simplement les « afficher » à l'écran, par exemple, sur la sortie standard du système. Et de cette manière, il sera possible de suivre le flux dans le terminal pendant le développement.
Cela signifie-t-il qu’il n’est pas du tout nécessaire de sauvegarder les journaux ? Bien sûr que non. Votre application ne devrait tout simplement pas faire cela : laissez-le à des services tiers. Votre application peut uniquement transférer les journaux vers un fichier ou un terminal spécifique pour une visualisation en temps réel, ou les transférer vers un système de stockage de données à usage général (tel que Hadoop). Votre application elle-même ne doit pas stocker ni interagir avec les journaux.
Principe 10. Testez !
Pour l’apprentissage automatique industriel, cette phase est extrêmement importante, car vous devez comprendre que le modèle fonctionne correctement et produit ce que vous vouliez.
Les tests peuvent être créés à l'aide de pytest et testés à l'aide d'un petit ensemble de données si vous avez une tâche de régression/classification.
N’oubliez pas de définir la même base pour les modèles d’apprentissage profond afin qu’ils ne produisent pas constamment des résultats différents.
Il s'agissait d'une brève description des 10 principes et, bien sûr, il est difficile de les utiliser sans essayer et voir comment ils fonctionnent, donc cet article n'est qu'un prologue à une série d'articles intéressants dans lesquels je vais révéler comment créer modèles d'apprentissage automatique industriel, comment les intégrer dans des systèmes et comment ces principes peuvent nous faciliter la vie à tous.
J'essaierai également d'utiliser des principes sympas que chacun peut laisser dans les commentaires s'il le souhaite.
Source: habr.com