Beaucoup d'entre nous, développeurs, connaissent le sentiment de devoir équilibrer le temps passé avec les utilisateurs à essayer de comprendre leurs besoins et le temps passé à développer le logiciel. Cela est encore plus évident dans le domaine de la science data, car pour construire un système efficace, il est nécessaire d'avoir une bonne connaissance du domaine en question. Au cours des deux dernières années, j'ai travaillé en tant qu'ingénieur en ML dans différents domaines de la science. data science Je me suis souvent demandé comment séparer les responsabilités liées à l'optimisation de la précision des modèles et à la création de tous les logiciels nécessaires pour rendre ces modèles fonctionnels. À mon humble avis, les scientifiques de data devraient donner la priorité à la précision de leurs modèles, tandis que les ingénieurs ML devraient s'assurer que ces modèles peuvent être utilisés par l'ensemble de l'entreprise.

En règle générale, dans les projets scientifiques data, plus vous effectuez d'itérations, mieux c'est. Examinons donc les raisons pour lesquelles l'intégration d'un ingénieur en ML dès le premier jour vous aidera à itérer et augmentera donc vos chances de construire un système performant. Pour couvrir tous les aspects, nous allons décomposer chaque raison en trois thèmes principaux des projets scientifiques data : data, modèles et l'infrastructure.

Avant d'entrer dans le vif du sujet, permettez-moi de définir ce que j'entends par itération. Dans cet article, je fais référence à des itérations de bout en bout du produit complet, comprenant souvent des étapes d'ingestion de data, de prétraitement, de formation et d'évaluation de modèles, de fourniture d'infrastructure, etc : data ingestion, prétraitement, formation et évaluation du modèle, mise en place de l'infrastructure, etc. Ce que je ne signifie pas est une itération rapide d'un modèle dans un carnet de notes avec l'ajustement d'un hyper paramètre. Si vous avez l'habitude de travailler dans un cadre agile, vous pouvez également considérer ces itérations comme des sprints de projet.

La construction d'un squelette sur lequel vous pouvez itérer est la première priorité et peut être un processus de longue haleine. Ce squelette est généralement un POC qui contient votre modèle de base initial et une démonstration d'une application ou d'une manière d'exploiter les résultats du modèle.

L'infrastructure : la sélection de ressources cloud compatibles (VM, connexions à diverses sources data) et la conception de l'architecture cloud sont quelques-unes des considérations initiales de l'ingénieur ML.

Data : obtenir les data nécessaires pour commencer à construire un modèle et assurer la disponibilité des data à partir de différentes sources, avec la possibilité de développer de nouveaux flux si nécessaire.

Modèles : s'assurer que les modèles testés sont effectivement compatibles avec l'architecture cloud proposée pour le déploiement du modèle et les exigences techniques (par exemple, latence, calcul nécessaire, exigences de l'environnement de production).

L'ingénieur ML peut également contribuer à cette phase en définissant les meilleures pratiques d'ingénierie logicielle avec le contrôle de version, le linting, l'architecture du code, les tests, etc.

Une fois que vous avez réalisé la première version, les deux premières itérations sont souvent difficiles et lentes. L'accélération des itérations permet d'effectuer des itérations plus petites avec une seule modification de fonctionnalité, ce qui constitue une méthode de développement beaucoup plus efficace que de modifier de nombreux éléments d'un modèle avant d'obtenir un retour d'information.

L'infrastructure : on peut gagner du temps en optimisant l'infrastructure de stockage et de calcul. Au cours de ces itérations, un ingénieur en ML peut chercher à versionner l'infrastructure elle-même, avec des outils d'Infrastructure as Code (IaC) tels que Terraform. L'utilisation de l'IaC permet d'automatiser le déploiement de l'infrastructure directement avec les pipelines CI/CD, en accélérant l'intégration de tous les changements qui doivent être apportés à l'infrastructure existante, et la création de différents environnements cloud (dev, staging, production). L'utilisation de composants cloud spécifiques peut également accélérer votre flux de travail, par exemple en construisant des images à distance à l'aide de la solution GCP Création d'un nuage.

Data : Les pipelines de prétraitement peuvent être construits rapidement par les équipes scientifiques de data afin de passer rapidement à la modélisation. Un ingénieur ML peut vous aider dans cette phase à rationaliser vos requêtes de traitement, qu'elles soient en sql, pandas, pyspark, etc. Faire cela dès le début peut vous faire gagner beaucoup de temps sur les itérations à long terme, car ce code est exécuté. beaucoup.

Modèles : les architectures de modèles complexes peuvent rendre le processus de formation très long. En outre, lorsqu'un scientifique du data parle d'un “modèle”, il peut en fait faire référence à un groupe de 100 modèles formés sur différentes tranches du data, chacun avec un explicateur SHAP pour dériver l'importance des caractéristiques. Un ingénieur en ML peut se concentrer sur la manière de paralléliser le pipeline d'entraînement, que ce soit sur une VM avec multiprocessing en python, ou en distribuant votre charge de travail sur plusieurs nœuds sur le cloud. Cette méthode peut être itérée, mais des gains importants peuvent être réalisés avec étonnamment peu d'efforts. Automatiser le déploiement de votre modèle avec un CI/CD/CT accélère également considérablement vos itérations et garantit la répétabilité.

La présence d'un ingénieur chargé de contrôler le budget cloud de votre projet est essentielle, en particulier pour les applications à forte intensité de data.

L'infrastructure : le coût est une variable majeure dans l'équation du choix de l'infrastructure. Une fois l'infrastructure choisie, des alertes budgétaires peuvent être mises en place pour s'assurer que les composants coûteux sont surveillés de près.

Data : Les requêtes intelligentes et le stockage de data peuvent également réduire de manière significative les coûts de chaque itération. Par exemple, l'agrégation de data devrait être effectuée avec parcimonie au cours des itérations du modèle.

Modèles : La parallélisation de votre pipeline de formation peut également vous permettre d'économiser sur les temps de disponibilité des machines coûteuses ou sur les temps d'exécution des composants sans serveur.

Réaliser des itérations rapides avec une boucle de rétroaction de qualité dans votre projet est une excellente chose, mais si vous ne pouvez pas replay chacun de ces scénarios, cela ne sert pas à grand-chose. Avoir un pipeline reproductible signifie implicitement que vous devez disposer d'un moyen de contrôler les exécutions du pipeline, afin d'identifier les exécutions basées sur des paramètres spécifiques ou des mesures de performance sur lesquelles revenir si nécessaire. La mise en place d'une telle procédure au cours du développement aide les scientifiques data à expérimenter librement (sans avoir recours au tristement célèbre Untitled12.ipynb) et prépare le pipeline à la surveillance de la production.

L'infrastructure : L'établissement d'un lien entre la version du code d'entraînement et la version du code d'infrastructure constitue ici un “ effort supplémentaire ”, mais il est nécessaire pour fournir des capacités complètes de retour en arrière à une exécution précédente. Assurer la répétabilité et le suivi d'une exécution de pipeline est pour moi le premier niveau essentiel de ML Ops que les équipes devraient s'efforcer d'atteindre. Les plateformes cloud disposent de services (GCP's Vertex AI par exemple) qui peuvent être rapides à mettre en place, mais vous pouvez également envisager d'adopter l'approche “best of breed” en utilisant des outils open source. Il s'agit ici de trouver un équilibre entre la plus grande fonctionnalité d'un outil open source spécifique et la complexité accrue de l'infrastructure globale du système.

Data : sauvegarder tous les objets data à chaque étape de la chaîne de production. En fonction des volumes, la priorité est de sauvegarder les ensembles d'essais de chaque série.

Modèles : comme ci-dessus, en sauvegardant tous les modèles pour chaque exécution avec tous les paramètres et métriques nécessaires. Une autre astuce consiste à enregistrer un commentaire sur chaque exécution avec ce qui a été modifié pour cette exécution spécifique afin d'enregistrer toutes les expériences pendant le développement, comme vous le feriez avec un fichier git commit message.

Lorsque la science du data est apparue, elle était très exploratoire et nécessitait un effort massif de la part d'un groupe d'ingénieurs logiciels pour déployer un modèle une fois qu'il avait démontré de bonnes performances sur le data historique. Cette phase “d'industrialisation” est une expérience très douloureuse car l'environnement de développement (fichiers plats et cahier python) est très différent de l'environnement de production (flux data automatisés avec data de production et environnement de codage de production). Les projets les plus réussis sur lesquels j'ai travaillé sont ceux où nous avons pu copier l'environnement de production aussi fidèlement que possible dans le développement dès le début. Cela réduira le temps de mise en production et vous permettra d'itérer en toute sécurité en développement, en déployant en production lorsque vous êtes satisfaits d'une itération.

L'infrastructure : Il n'est pas toujours facile d'émuler l'infrastructure de production nécessaire dans le cadre du développement et cela peut s'avérer coûteux. C'est là que l'infrastructure en tant que code est utile et peut vous permettre de passer facilement d'un environnement à l'autre.

Data : Ce qui distingue le développement scientifique de data de l'ingénierie logicielle traditionnelle ou même de l'ingénierie de data, c'est que les scientifiques de data ont besoin de data de production dans le cadre du développement. L'utilisation de data en bac à sable (excluant certaines data ou incluant certaines data de tests synthétiques) pour l'ingénierie data normale est une bonne pratique pendant le développement, mais elle peut représenter une grande perte de temps pour la science data et peut avoir un impact important sur l'ensemble du pipeline de la science data. Par conséquent, l'accès en lecture seule aux tables de production doit être négocié avec votre équipe data dès le premier jour.

Modèles : dès le début du projet, un seul modèle (ou une seule approche de modélisation) doit être présent dans votre code de production. Toutes les expériences doivent rester dans des carnets de notes ou des scripts temporaires séparés dans un autre dossier. Cela vous évite d'accumuler du code mort dans votre base de code de production et facilite la maintenance ou l'intégration d'autres développeurs.

En résumé, la construction de modèles et la construction du logiciel entourant ces modèles devraient être deux priorités dès le début de chaque projet. Le fait d'avoir des flux distincts avec des responsabilités différentes peut aider les équipes à se concentrer sur les deux en parallèle. Le rôle de l'ingénieur en ML évolue de jour en jour, et j'aimerais avoir votre avis sur tout ce que j'ai omis !