Apprentissage machine industriel: 10 principes de conception
De nos jours, de nouveaux services, applications et autres programmes importants sont créés chaque jour qui vous 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, chaque programmeur novice, qu'il soit une startup passionnée ou un Full Stack ordinaire ou un Data Scientist, se rend compte tôt ou tard 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 de programmation du machine learning industriel afin qu'il puisse être facilement intégré dans une application / service, sur la base de la méthode App à 12 facteurs proposée par l'équipe Heroku.... Mon initiative est de faire connaître cette technique, qui peut aider de nombreux développeurs et personnes de Data Science.
Cet article est le prologue d'une série d'articles sur l'apprentissage machine industriel. En eux, je continuerai à parler de la façon, en fait, de créer un modèle et de l'exécuter 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 aux premiers stades, par paresse pour le comprendre (ou pour une raison quelconque) oublient Git. Ils oublient complètement le mot, c'est-à-dire qu'ils se lancent des fichiers dans le lecteur / lancent simplement du texte / envoient des colombes, ou ils ne réfléchissent pas à leur flux de travail, et chacun s'engage dans sa propre branche, puis au maître.
Ce principe dit: avoir une base de code et de nombreux déploiements.
Git peut être utilisé à la fois en production et en recherche et développement (R&D), où il est moins souvent utilisé.
Par exemple, dans la phase de R&D, vous pouvez laisser des commits avec différentes méthodes et modèles de traitement de données, afin de choisir ensuite le meilleur et de continuer facilement à travailler avec lui.
Deuxièmement, en production, c'est une chose irremplaçable - vous devrez constamment regarder comment votre code change et savoir quel modèle a donné les meilleurs résultats, quel code a fonctionné à la fin et ce qui s'est passé, à cause de ce qu'il a cessé de fonctionner ou a commencé à générer des problèmes. résultats incorrects. C'est à cela que servent les commits!
Et vous pouvez également créer un package de votre projet en le plaçant, par exemple, sur Gemfury, puis en important simplement des fonctions à partir de celui-ci pour d'autres projets, afin de ne pas les réécrire 1000 fois, mais plus à ce sujet plus tard.
Principe 2. Déclarez et isolez clairement les dépendances
Chaque projet a différentes bibliothèques 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 différentes ou d'outils système, votre tâche est:
- dependencies, , , , , (, Python Pipfile requirements.txt. , : realpython.com/pipenv-guide)
- dependencies . , , Tensorflow?
Ainsi, les développeurs qui rejoindront votre équipe à l'avenir pourront se familiariser rapidement avec les bibliothèques et leurs versions qui sont utilisées dans votre projet, ainsi que vous pourrez contrôler les versions et les bibliothèques elles-mêmes installées pour un projet spécifique, ce qui vous aidera à éviter incompatibilité des bibliothèques ou de leurs versions.
Votre application n'a pas non plus besoin de s'appuyer sur des outils système pouvant être installés sur un système d'exploitation particulier. Ces outils doivent également être déclarés dans le manifeste des dépendances. Ceci est nécessaire pour é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 peut ne pas exister ou la version ne sera pas celle dont vous aviez initialement besoin.
Par exemple, votre requirements.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 parler d'histoires où divers développeurs ont accidentellement téléchargé du code sur GitHub dans des référentiels ouverts avec des mots de passe et d'autres clés d'AWS, se réveillant le lendemain avec une dette de 6 000 $, voire avec les 50 000 $.
Bien sûr, ces cas sont extrêmes, mais très révélateurs. 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 que cela ne vaut pas la peine d'expliquer pourquoi.
Une alternative à cela consiste à stocker les configurations dans des variables d'environnement. Vous pouvez en savoir plus sur les variables d'environnement ici .
Exemples de données généralement stockées dans des variables d'environnement:
- Noms de domaine
- URL / URI de l'API
- Clés publiques et privées
- Contacts (mail, téléphones, etc.)
De cette façon, vous n'avez pas à changer constamment le code si vos variables de configuration changent. Cela vous fera gagner du temps, des efforts et de l'argent.
Par exemple, si vous utilisez l'API Kaggle pour effectuer des tests (par exemple, vous téléchargez et exécutez le modèle à travers elle pour tester que le modèle fonctionne bien au démarrage), alors les clés privées de Kaggle, telles que KAGGLE_USERNAME et KAGGLE_KEY, doivent être stockées dans des variables d'environnement.
Principe 4: Services tiers
L'idée ici est de concevoir le programme de telle manière qu'il n'y ait pas de distinction entre les ressources locales et tierces en termes de code. Par exemple, vous pouvez connecter à la fois MySQL local et un tiers. Il en va de même pour diverses API comme Google Maps ou Twitter API.
Pour désactiver un service tiers ou en connecter un autre, il vous suffit de changer les clés de 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 les ensembles de données à l'intérieur du 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, afin que quel que soit le service que vous utilisez (par exemple, CircleCI), le programme a pu trouver 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. Construire, publier, exécuter
De nombreuses personnes de Data Science trouvent utile d'acquérir des compétences en rédaction de logiciels. Si nous voulons que notre programme plante le plus rarement possible et qu'il fonctionne correctement aussi longtemps que possible, nous devons diviser le processus de publication de la nouvelle version en 3 étapes:
- . , . .
- — config, . .
- . .
Un tel système de publication de nouvelles versions d'un modèle ou de l'ensemble du pipeline permet la division des rôles entre administrateurs et développeurs, permet le suivi des versions et évite 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 excellent pour créer des packages pour des projets.
Vous pourrez créer des packages avec différentes versions de votre modèle de machine learning, puis les mettre en package et vous référer aux packages nécessaires et à leurs versions afin d'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 placé sur Gemfury par exemple.
Principe 6. Nous exécutons votre modèle comme un ou plusieurs processus
De plus, les processus ne doivent pas avoir de données partagées. Autrement dit, les processus doivent exister séparément et tous les types de données doivent exister séparément, par exemple sur des services tiers tels que MySQL ou autres, en fonction de vos besoins.
Autrement dit, il ne vaut certainement pas la peine de stocker des données dans le système de fichiers du processus, sinon cela peut conduire à 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 y a une exception: pour les projets de machine learning, vous pouvez stocker le cache de la bibliothèque afin de ne pas les réinstaller à chaque fois que vous lancez une nouvelle version, si aucune bibliothèque supplémentaire ou aucune modification de leurs versions n'a été effectuée. Ainsi, vous raccourcirez le temps de 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 simplement les processus nécessaires et leur séquence.
Principe 7: Recyclabilité
Les processus qui exécutent le modèle dans votre application doivent être faciles à démarrer et à arrêter. Ainsi, il vous permettra de déployer rapidement les changements de code, les changements de configuration, d'évoluer rapidement et de manière flexible et d'éviter d'éventuelles pannes de la version de production.
Autrement dit, votre processus avec un modèle doit:
- . ( , , ) . , — .
- . , , , . DevOps , , (, , , , !)
Principe 8: Déploiement / intégration continus
De nombreuses entreprises utilisent la séparation entre les équipes de développement et de déploiement d'applications (rendant l'application disponible aux utilisateurs finaux). Cela peut considérablement ralentir le développement du logiciel et progresser vers son amélioration. Cela gâche également la culture DevOps, où développement et intégration sont à peu près combinés.
Par conséquent, ce principe stipule 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 par dix
- Réduisez le nombre d'erreurs dues à l'incompatibilité du code.
- Cela réduit également la charge du personnel, puisque les développeurs et les personnes qui déploient 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 faire des ajouts au modèle, le mettre à jour et démarrer immédiatement, alors qu'il sera facile, en cas d'échec, de revenir très rapidement à la version de travail, afin que l'utilisateur final ne le remarque même pas. Cela peut être fait particulièrement rapidement et facilement si vous avez de bons tests.
Minimisez les différences !!!
Principe 9. Vos journaux
Les journaux (ou "Logs") sont des événements enregistrés, généralement au format texte, qui se produisent dans l'application (flux d'événements). 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 s'il est comme le développeur lui-même l'a prévu.
Ce principe dit que vous ne devez pas stocker vos journaux dans votre système de fichiers - il vous suffit de les «afficher», par exemple, faites-le dans la sortie standard du système stdout. Et de cette manière, le flux peut être surveillé dans le terminal pendant le développement.
Cela signifie-t-il que vous n'avez pas du tout besoin d'enregistrer les journaux? Bien sûr que non. C'est juste que votre application ne devrait pas faire cela - laissez-le aux services tiers. Votre application peut uniquement rediriger les journaux vers un fichier ou un terminal spécifique pour une visualisation en direct, ou les rediriger vers un système de stockage à 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 machine industriel, cette phase est extrêmement importante, car vous devez comprendre que le modèle fonctionne correctement et donne ce que vous voulez.
Les tests peuvent être créés avec pytest et testés avec un petit jeu de données si vous avez une tâche de régression / classification.
N'oubliez pas de placer la même graine pour les modèles d'apprentissage en profondeur afin qu'ils ne produisent pas constamment des résultats différents.
Il s'agissait d'une brève description de 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 des modèles industriels d'apprentissage automatique. comment les intégrer dans les systèmes et comment ces principes peuvent nous faciliter la vie à tous.
J'essaierai également d'utiliser des lignes directrices intéressantes que quelqu'un peut laisser dans les commentaires s'il le souhaite.