Les projets de ML nécessitent des équipes dont les membres possèdent un éventail de compétences, d'expertises et de responsabilités liées au machine learning. Ce sont les plus courantes les rôles attribués aux équipes de ML typiques:
| Rôle | Connaissances et compétences | Principal produit livrable |
|---|---|---|
| Responsable produit de ML | Les chefs de produit de ML ont une connaissance approfondie de leurs points forts et de et le processus de développement du ML. Elles permettent d'aligner les problèmes métier aux solutions de ML en collaborant directement avec l'équipe ML, les utilisateurs finaux et les autres partenaires. Ils définir la vision du produit, définir les cas d'utilisation les exigences, et planifier et hiérarchiser les projets. |
Document de spécifications techniques (PRD) |
| Responsable ingénierie | Les responsables de l’ingénierie atteignent les objectifs de l’entreprise en définissant, en communiquant et d’atteindre les priorités de l'équipe. Comme le ML ils adaptent les solutions de ML aux problèmes métier. Il définit des attentes claires pour les membres de l'équipe, mener des évaluations de performance, et aider à la gestion de carrière et de développement professionnel. |
Documents de conception, plans de projet et évaluations de performances. |
| Data scientist | Les data scientists utilisent l'analyse quantitative et statistique pour extraire des insights et de la valeur des données. Ils aident à identifier et à tester des fonctionnalités, à créer des prototypes de modèles et à améliorer l'interprétabilité des modèles. | Rapports et visualisations des données qui répondent aux questions commerciales grâce à une analyse statistique. |
| Ingénieur en ML | Les ingénieurs en ML conçoivent, compilent, passent en production et gèrent des modèles de ML. Ce sont de solides ingénieurs logiciel ayant une connaissance approfondie du ML technologies et bonnes pratiques. | Modèle déployé avec une qualité de prédiction suffisante pour répondre aux besoins métier objectifs. |
| Ingénieur de données | Les ingénieurs de données créent des pipelines de données pour stocker, agréger et de grandes quantités de données. Ils développent l'infrastructure et des systèmes de collecte et de transformation des données brutes utiles pour l'entraînement et l'inférence du modèle. Les ingénieurs de données sont des données tout au long du processus de développement de ML. | Pipelines de données entièrement mis en production avec les fonctionnalités de surveillance et des alertes. |
| Ingénieur DevOps (Developer Operations) | Les ingénieurs DevOps développent, déploient, étendent et surveillent l'infrastructure de diffusion des modèles de ML. | Un processus automatisé de diffusion, de surveillance, de test et d'alerte sur le comportement d'un modèle. |
Les projets de ML réussis comportent des équipes dans lesquelles chaque rôle est bien représenté. Dans les petites équipes, les membres doivent assumer les responsabilités de plusieurs rôles.
Établir les pratiques d’équipe
Étant donné que les rôles, les outils et les frameworks varient considérablement dans le domaine du ML, il est essentiel d'établir des pratiques communes une excellente documentation sur les processus. Par exemple, un ingénieur peut penser qu'il suffit d'obtenir les bonnes données pour commencer à entraîner un modèle, tandis qu'un ingénieur plus responsable vérifiera que l'ensemble de données est correctement anonymisé, et documentera ses métadonnées et sa provenance. En veillant à ce que les ingénieurs partagent des définitions communes pour les processus et les modèles de conception, vous réduisez la confusion et augmentez la vitesse de l'équipe.
Documentation des processus
Les documents de processus doivent définir les outils, l'infrastructure et les processus dont l'équipe dispose que vous utiliserez pour le développement du ML. De bonnes documentations de processus aident à aligner les nouveaux et les anciens membres de l'équipe. Elles doivent répondre aux types de questions suivants :
- Comment les données sont-elles générées pour le modèle ?
- Comment examinons-nous, validons-nous et visualisons-nous les données ?
- Comment modifier une caractéristique d'entrée ou une étiquette dans les données d'entraînement ?
- Comment personnaliser le pipeline de génération de données, d'entraînement et d'évaluation ?
- Comment modifier l'architecture du modèle pour prendre en compte les changements d'entrée caractéristiques ou étiquettes ?
- Comment obtenons-nous des exemples de tests ?
- Quelles métriques utiliserons-nous pour évaluer la qualité du modèle ?
- Comment lancer nos modèles en production ?
- Comment savoir si notre modèle présente un problème ?
- De quels systèmes en amont nos modèles dépendent-ils ?
- Comment rendre mon code SQL maintenable et réutilisable ?
Autres questions possibles
ModèlePuis-je entraîner des modèles sur différents ensembles de données au sein du même (par exemple, pour l'ajustement) ?
Comment ajouter un nouvel ensemble de données de test à mon pipeline ?
Comment vérifier la prédiction du modèle sur un exemple créé manuellement ?
Comment trouver, examiner et visualiser des exemples où le modèle a commis des erreurs ?
Comment déterminer quelle caractéristique a été la plus responsable d'une prédiction donnée ?
Comment identifier les fonctionnalités qui ont le plus d'impact sur des prédictions dans un échantillon donné ?
Comment calculer ou représenter les prédictions du modèle sur un ensemble de données ou un échantillon choisi ?
Comment calculer les métriques standards pour les prédictions de mon modèle sur un ensemble de données choisi ?
Comment développer et calculer des métriques personnalisées ?
Comment comparer mon modèle à d'autres modèles hors connexion ?
Puis-je effectuer une méta-analyse pour plusieurs évaluations de modèles dans un seul environnement de développement ?
Puis-je comparer le modèle actuel à celui d'il y a 10 mois ?
Je pense avoir créé un bon modèle. Comment puis-je le lancer en production ?
Comment vérifier que mon nouveau modèle fonctionne correctement en production ?
Puis-je obtenir l'historique des évaluations de modèle au fil du temps ?
Comment savoir si le modèle présente un problème ?
Une page ou un bug m'a été affecté et m'ont indiqué quelque chose concernant le modèle. Que dois-je faire ?
Comment puis-je personnaliser le pipeline de génération/entraînement/évaluation des données ?
Quand et comment créer un pipeline entièrement nouveau ?
J'ai besoin de SQL pour générer des données. Où dois-je le placer ?
Comment fonctionne l'inférence du modèle ? Existe-t-il un schéma ?
Quels systèmes en amont mon modèle dépend-il et que dois-je savoir à ce sujet ?
Je n'arrive pas à comprendre. Qui dois-je contacter (et comment) ?
À retenir
En quoi consistent les "bonnes pratiques de ML" ? peuvent différer entre les entreprises, les équipes des personnes. Par exemple, certains membres de l'équipe peuvent considérer les Colabs expérimentaux comme le principal livrable, tandis que d'autres voudront travailler en R. Certains pourraient avoir une passion pour en ingénierie logicielle, quelqu'un d'autre pense que la surveillance est mais quelqu'un d'autre connaît les bonnes pratiques de production des caractéristiques, souhaite utiliser Scala. Chacun a "raison" de son point de vue, et si le mix est bien dirigé, il sera puissant. Si ce n'est pas le cas, il peut être désordonné.
Établir les outils, les processus et l'infrastructure que l'équipe utilisera avant l'écriture d'une ligne de code peut être la différence entre un projet défaillant deux ans ou avec succès un trimestre en avance sur le calendrier.
Évaluations des performances
En raison de l'ambiguïté et de l'incertitude inhérentes au ML, les responsables du personnel doivent définir des attentes claires et de définir les produits livrables dès le début.
Lorsque vous déterminez les attentes et les livrables, réfléchissez à la façon dont ils seront évalués si un projet ou une approche ne sont pas couronnés de succès. En d’autres termes, il s’agit important que les performances d'un membre de l'équipe ne soient pas directement liées la réussite du projet. Par exemple, il n'est pas rare que les membres de l'équipe passent des semaines à examiner des solutions qui finissent par échouer. Même dans ces cas, leur code de haute qualité, leur documentation approfondie et leur collaboration efficace devraient contribuer positivement à leur évaluation.