Rassembler une équipe de ML
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
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. Voici les rôles les plus courants dans les équipes de ML:
| Rôle |
Connaissances et compétences |
Livrable principal |
| Responsable produit ML |
Les responsables produit ML ont une connaissance approfondie des forces et des faiblesses du ML, ainsi que du processus de développement du ML. Ils alignent les problèmes métier sur les solutions de ML en travaillant directement avec l'équipe de ML, les utilisateurs finaux et les autres personnes concernées. Ils créent la vision du produit, définissent les cas d'utilisation et les exigences, et planifient et hiérarchisent les projets.
|
Document sur les exigences du produit (PRD)
|
| Responsable ingénierie |
Les responsables techniques atteignent les objectifs commerciaux en définissant, en communiquant et en atteignant les priorités de l'équipe. Comme les responsables produit ML, ils alignent les solutions ML sur les problèmes métier.
Ils définissent des attentes claires pour les membres de l'équipe, effectuent des évaluations des performances et aident au développement professionnel et de carrière.
|
Documents de conception, plans de projet et évaluations des 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 de données qui répondent à des questions commerciales grâce à une analyse statistique
|
| Ingénieur en ML |
Les ingénieurs en ML conçoivent, compilent, mettent en production et gèrent des modèles de ML.
Il s'agit d'ingénieurs logiciels expérimentés qui possèdent une connaissance approfondie des technologies et des bonnes pratiques du ML.
|
Modèle déployé avec une qualité de prédiction suffisante pour atteindre les objectifs commerciaux.
|
| Ingénieur de données |
Les ingénieurs de données créent des pipelines de données pour stocker, agréger et traiter de grandes quantités de données. Ils développent l'infrastructure et les systèmes permettant de collecter et de transformer les données brutes en formats utiles pour l'entraînement et le traitement des modèles. Les ingénieurs de données sont responsables des données tout au long du processus de développement du ML.
|
Pipelines de données entièrement mis en production avec la surveillance et les alertes nécessaires.
|
| Ingénieur DevOps |
Les ingénieurs DevOps développent, déploient, étendent et surveillent l'infrastructure de diffusion des modèles de ML.
|
Processus automatisé d'exécution, 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 des pratiques d'équipe
Étant donné que les rôles, les outils et les frameworks varient considérablement dans le développement du ML, il est essentiel d'établir des pratiques courantes grâce à une excellente documentation des 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 du processus
Les documents de processus doivent définir les outils, l'infrastructure et les processus que l'équipe utilisera 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 ou une étiquette d'entrée 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 tenir compte des modifications apportées aux fonctionnalités ou aux libellés d'entrée ?
- Comment obtenir des exemples de tests ?
- Quelles métriques allons-nous utiliser pour évaluer la qualité du modèle ?
- Comment lancer nos modèles en production ?
- Comment saurons-nous 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èle
Puis-je entraîner des modèles sur différents ensembles de données dans le même pipeline, par exemple pour un réglage fin ?
Comment ajouter un nouvel ensemble de données de test à mon pipeline ?
Formation
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 savoir quelles caractéristiques ont le plus d'impact sur les 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 ?
Productionnalisation, surveillance et maintenance
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 ?
On m'a attribué une page/un bug faisant référence au modèle.
Que dois-je faire ?
Pipelines
SQL
Infrastructure
Communication
À retenir
Les bonnes pratiques en matière de ML peuvent varier d'une entreprise à l'autre, d'une équipe à l'autre et d'une personne à l'autre. 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 peuvent être passionnés par l'ingénierie logicielle, d'autres pensent que la surveillance est la chose la plus importante, et d'autres encore connaissent de bonnes pratiques de production de fonctionnalités, mais souhaitent utiliser Scala. Chacun a "raison" de son point de vue, et si le mix est bien dirigé, il sera puissant. Sinon, cela peut être un désordre.
Établir les outils, les processus et l'infrastructure que l'équipe utilisera avant d'écrire une ligne de code peut faire la différence entre un échec du projet au bout de deux ans ou un lancement réussi un trimestre en avance sur le calendrier.
En raison de l'ambiguïté et de l'incertitude inhérentes au ML, les responsables des ressources humaines doivent définir des attentes claires et définir les livrables à l'avance.
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 est important que les performances d'un membre de l'équipe ne soient pas directement liées au succès 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.
Testez vos connaissances
Quelle est la raison principale d'avoir une excellente documentation des processus et d'établir des pratiques communes ?
Accélérer la vitesse du projet.
Bonne réponse. Une bonne documentation des processus et l'établissement de bonnes pratiques réduisent la confusion et simplifient le processus de développement.
Établir des bonnes pratiques dans l'ensemble de l'entreprise
Étant donné que le développement de ML varie d'un projet à l'autre, les équipes établissent généralement leurs propres ensembles de bonnes pratiques pour travailler efficacement et accélérer leur vitesse.
Assurez-vous que tous les ingénieurs de l'équipe ont le même niveau d'expertise.
Les équipes de ML comptent généralement des ingénieurs possédant diverses compétences et connaissances. La documentation du processus aide les ingénieurs à s'aligner sur les bonnes pratiques pour accélérer leur vitesse.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[null,null,["Dernière mise à jour le 2025/07/27 (UTC)."],[[["\u003cp\u003eMachine learning projects necessitate diverse teams with specialized roles like ML product managers, data scientists, and ML engineers, to address various aspects of development and deployment.\u003c/p\u003e\n"],["\u003cp\u003eComprehensive process documentation is crucial for ML teams to establish common practices, ensure smooth collaboration, and enhance project velocity by reducing confusion and streamlining workflows.\u003c/p\u003e\n"],["\u003cp\u003eProcess documentation should cover key questions regarding data handling, model development, training, evaluation, and productionization to guide the team's approach and decision-making.\u003c/p\u003e\n"],["\u003cp\u003eEstablishing clear expectations, deliverables, and evaluation criteria for team members is essential, emphasizing contributions beyond project success due to the inherent uncertainties in ML development.\u003c/p\u003e\n"],["\u003cp\u003eSuccessful ML teams foster a collaborative environment where diverse perspectives and expertise are valued, enabling efficient problem-solving and innovative solutions.\u003c/p\u003e\n"]]],[],null,["# Assembling an ML team\n\nML projects require teams with members who have a range of skills, expertise,\nand responsibilities related to machine learning. These are the most common\nroles found on typical ML teams:\n\n| Role | Knowledge and skills | Main deliverable |\n|----------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|\n| ML product manager | ML product managers have a deep understanding of ML strengths and weaknesses and the ML development process. They align business problems to ML solutions by working directly with the ML team, end-users, and other stakeholders. They create the product vision, define use cases and requirements, and plan and prioritize projects. | Product requirements document (PRD). |\n| Engineering manager | Engineering managers achieve business goals by setting, communicating, and achieving team priorities. Like ML product managers, they align ML solutions to business problems. They set clear expectations for team members, conduct performance evaluations, and assist with career and professional development. | Design docs, project plans, and performance evaluations. |\n| Data scientist | Data scientists use quantitative and statistical analysis to extract insights and value from data. They help to identify and test features, prototype models, and help with model interpretability. | Reports and data visualizations that answer business questions through statistical analysis. |\n| ML engineer | ML engineers design, build, productionize, and manage ML models. They are strong software engineers with a deep understanding of ML technologies and best practices. | Deployed model with sufficient prediction quality to meet business goals. |\n| Data engineer | Data engineers build data pipelines for storing, aggregating, and processing large amounts of data. They develop the infrastructure and systems for collecting and transforming raw data into useful formats for model training and serving. Data engineers are responsible for the data across the entire ML development process. | Fully productionized data pipelines with the necessary monitoring and alerting. |\n| Developer operations (DevOps) engineer | DevOps engineers develop, deploy, scale, and monitor the serving infrastructure for ML models. | An automated process for serving, monitoring, testing, and alerting on a model's behavior. |\n\nSuccessful ML projects have teams with each role well\nrepresented. In smaller teams, individuals will need to handle the\nresponsibilities for multiple roles.\n\n\nEstablish team practices\n------------------------\n\nBecause the roles, tools, and frameworks vary widely in ML\ndevelopment, it's critical to establish common practices through\nexcellent process documentation. For example, one engineer might\nthink that just getting the right data is sufficient to begin training a model,\nwhile a more responsible engineer will validate that the dataset is anonymized\ncorrectly and document its metadata and provenance. Making sure engineers share\ncommon definitions for processes and design patterns reduces confusion and\nincreases the team's velocity.\n\n### Process documentation\n\nProcess docs should define the tools, infrastructure, and processes the team\nwill use for ML development. Good process docs help align new and current\nteam members. They should answer the following types of questions:\n\n- How is the data generated for the model?\n- How do we examine, validate, and visualize the data?\n- How do we modify an input feature or label in the training data?\n- How do we customize the data generation, training, and evaluation pipeline?\n- How do I change the model architecture to accommodate changes in input features or labels?\n- How do we obtain testing examples?\n- What metrics will we use to judge model quality?\n- How do we launch our models in production?\n- How will we know if something is wrong with our model?\n- What upstream systems do our models depend on?\n- How do I make my SQL maintainable and reusable?\n\n#### More potential questions\n\n**Model**\n\n-\n Can I train models on different datasets in the same\n pipeline, like for fine-tuning?\n\n-\n How do I add a new test dataset to my pipeline?\n\n**Training**\n\n-\n How do I check the model's prediction on a hand-crafted example?\n\n-\n How do I find, examine, and visualize examples where the model made\n mistakes?\n\n-\n How do I determine which feature was most responsible for a given\n prediction?\n\n-\n How do I understand which features have the most impact on\n predictions within a given sample?\n\n-\n How do I compute or plot model predictions on a chosen dataset or\n sample?\n\n-\n How do I compute standard metrics for my model's predictions on a\n chosen dataset?\n\n-\n How do I develop and compute custom metrics?\n\n-\n How do I compare my model with other models offline?\n\n-\n Can I perform meta-analysis for multiple model evaluations in a single\n development environment?\n\n-\n Can I compare the current model with the one from 10 months ago?\n\n**Productionization, monitoring, and maintenance**\n\n-\n I think I created a good model. How can I launch it in production?\n\n-\n How do I verify that my new model is running in production correctly?\n\n-\n Can I get the history of model evaluations over time?\n\n-\n How will I know when something is wrong with the model?\n\n-\n I got assigned a page/bug mentioning something about the model.\n What should I do?\n\n**Pipelines**\n\n-\n How could I customize the data generation/training/evaluation\n pipeline?\n\n-\n When and how should I create a completely new pipeline?\n\n**SQL**\n\n-\n I need SQL to generate some data. Where should I put it?\n\n**Infrastructure**\n\n-\n How does our model serving work? Is there a diagram?\n\n-\n What upstream systems does my model depend on that I should be\n aware of?\n\n**Communication**\n\n-\n I can't figure something out. Who (and how) should I contact?\n\n### Keep in mind\n\nWhat constitutes \"ML best practices\" can differ between companies, teams, and\nindividuals. For\nexample, some team members might consider experimental Colabs as the main\ndeliverable, while others will want to work in R. Some might have a passion for\nsoftware engineering, someone else thinks monitoring is the most important\nthing, yet someone else is aware of good feature productionization practices but\nwants to use Scala. Everyone is \"right\" from their own perspective and if\nsteered correctly, the mix will be a powerhouse. If not, it can be a mess.\n\nEstablishing the tools, processes, and infrastructure the team will use before\nwriting a line of code can be the difference between the project failing after\ntwo years or successfully launching a quarter ahead of schedule.\n\nPerformance evaluations\n-----------------------\n\nDue to the ambiguity and uncertainty inherent in ML, people managers need to set\nclear expectations and define deliverables early.\n\nWhen determining expectations and deliverables, consider how they'll be\nevaluated if a project or approach isn't successful. In other words, it's\nimportant that a team member's performance isn't directly connected to the\nsuccess of the project. For example, it's not uncommon for team members to spend\nweeks investigating solutions that are ultimately unsuccessful. Even in these\ncases, their high-quality code, thorough documentation, and effective\ncollaboration should contribute positively toward their evaluation.\n\n### Check Your Understanding\n\nWhat is the primary reason for having excellent process documentation and establishing common practices? \nIncrease project velocity. \nCorrect. Having good process documentation and establishing common practices reduces confusion and streamlines the development process. \nEstablish best practices across a company. \nBecause ML development varies from project to project, teams typically establish their own sets of best practices to work effectively and increase their velocity. \nEnsure all engineers on the team have the same level of expertise. \nML teams typically have engineers with a variety of skills and knowledge. Process documentation helps engineers align on best practices to increase their velocity."]]
