Organiser l'apprentissage automatique : Tous les goûts sont dans la nature !

Les principes et processus de DoorDash pour démocratiser l'apprentissage automatique.

Il y a six mois, j'ai rejoint DoorDash en tant que premier responsable de la science des données et de l'apprentissage automatique. L'une de mes premières tâches a été d'aider à décider de la manière dont nous devrions organiser les équipes d'apprentissage machine (ML) afin de tirer le meilleur parti de cette merveilleuse technologie. Vous pouvez en savoir plus sur certains des cas d'utilisation actuels de l'apprentissage automatique chez DoorDash sur notre blog ici.

Ayant passé du temps dans d'anciennes entreprises technologiques et m'étant entretenu avec de nombreuses autres, j'étais parfaitement conscient des nombreux défis qui se posent.

Défis

1. La notion de ML est mal définie : Une régression linéaire dans Excel est-elle un ML ? Qu'en est-il d'une petite forêt aléatoire dans un carnet Jupyter local ? Où se situe la frontière entre l'analytique et le ML ?
2. La ML a besoin de l'ingénierie et de la science : Dans les entreprises technologiques, la ML nécessite une prise de décision optimale et performante.
3. Le ML progresse rapidement : Même au cours des cinq dernières années, nous avons vu les approches de modélisation, les plateformes et les langages changer presque tous les 18 mois.
4. Le ML est à la mode : de nombreuses personnes considèrent le ML comme magique et tout le monde veut travailler dessus.

In #2 ‘performant’ implies we need low latency, reliability, and scale - typically in a Software Engineer’s wheelhouse, while ‘optimal’ implies we need mathematical and statistical excellence - typically in a Data Scientist’s toolkit. This is often the biggest elephant in the room: who should work on ML? Engineers or Data Scientists? Both? Neither? This debate often leads to friction in teams and employee unhappiness.

Chez DoorDash, nos valeurs fondamentales sont " Une équipe, un combat " et " Faire de la place à la table ". Nous voulons que des personnes de tous horizons et de tous titres, dotées d'une expertise en ML, viennent travailler chez nous et se sentent capables de donner le meilleur d'elles-mêmes. Nous avons donc choisi de faire les choses différemment, de manière plus inclusive. Nous avons rédigé une charte pour le ML, avec la vision et les principes suivants :

Vision

Créer des logiciels axés sur les données pour des mesures et des optimisations avancées

Principes

1. Démocratie : tout le monde peut construire et exécuter un modèle de ML s'il dispose d'un outillage et de conseils suffisants.
2. Talent : nous voulons attirer et développer les meilleurs praticiens de la ML axés sur l'impact sur les entreprises.
3. Rapidité : s'il existe déjà une solution ML tierce rentable, nous devrions l'utiliser.
4. Suffisance : si une fonction (généralement l'ingénierie) peut mettre en œuvre une solution de ML suffisamment bonne sans aide, elle doit le faire.
5. Incrémentalité : si une fonction (typiquement la science des données) peut ajouter suffisamment de valeur incrémentale à une solution de ML, elle doit le faire.
6. Responsabilité : chaque solution de ML a un responsable technique unique qui agit en tant que décideur technique.

The idea behind the vision is that we only want to build ML where it is actually needed - not where it might be interesting. We look for business opportunities where simple analytics or rules only get you 10-40% of the impact. This ensures the return on an ML practitioner’s time is super high for the business.

Ces principes nous permettent de recruter les meilleures personnes et d'utiliser nos talents de la manière la plus efficace possible. L'appropriation et la responsabilisation sont essentielles pour motiver les employés et leur permettre de donner le meilleur d'eux-mêmes. Notez que ces principes sont assez généraux et qu'ils pourraient probablement être appliqués à la plupart des outils.

An important corollary of these principles is that we do not pigeon-hole any function i.e. we do not say what a Data Scientist can or cannot work on, or what an Engineer can or cannot work on. We believe in blurry lines and helping ML practitioners grow in whichever areas they want to - so it is fine for a Data Scientist to work on production code or an ML Engineer to  build features.

What enables this flexibility while maintaining a high standard is principle #6, which states that we have a single person accountable for a project. That does not mean that this person must do the work, only that they must ensure it is done correctly - and they may choose to have it done by a Data Scientist or an Engineer or someone else.

Il n'y a pas de structure ou de processus unique qui adhère à la vision et aux principes, mais toute structure choisie doit être clairement articulée pour garantir sa réussite. Chez DoorDash, nous avons choisi les structures et processus suivants pour répondre aux principes :

Organisation

1. Rattachement hiérarchique : Les ingénieurs ML sont rattachés aux responsables de l'ingénierie et les Data Scientists ML aux responsables de la DS. L'infrastructure ML relève de l'équipe centrale de la plate-forme de données.
2. Recrutement : Les descriptions de poste et les processus d'embauche des ingénieurs ML et des scientifiques de données ML sont examinés et approuvés par le Conseil ML.
3. Technologie : Fort investissement dans une plateforme ML centralisée par la plateforme de données (flux de travail, provisionnement, orchestration, magasins de fonctionnalités, préparation commune des données, validation, contrôles de qualité, surveillance, etc.) ). Les décisions potentielles relatives à la technologie de l'infrastructure de ML (construction/achat) sont examinées et approuvées par le ML Council.
4. Exécution :
   1. Toute personne de l'entreprise peut identifier un cas d'utilisation du ML et rédiger une proposition (problème commercial, impact estimé par rapport au coût de construction/maintenance, solution, composition de l'équipe, responsable technique unique).
   2. La proposition est examinée, modifiée et approuvée par les responsables interfonctionnels du pod ou du secteur vertical (PM, EM, DS Manager, Analytics Manager, etc.). Les responsables doivent approuver le problème commercial, l'ordre de priorité et l'impact/le coût.
   3. La proposition est examinée, amendée et approuvée par le Conseil du ML.
   4. Toutes les étapes de la révision seront transparentes : Le Conseil de la ML et les praticiens de la ML se réuniront chaque semaine dans le cadre de la "révision de la ML" afin d'examiner les éléments et de débattre des prochaines étapes. Des décisions seront prises lors de cette révision du ML et des notes seront prises et envoyées par courriel à toutes les personnes intéressées.

Une caractéristique clé de DoorDash est que nous n'utilisons pas les lignes hiérarchiques comme mécanisme pour renforcer l'alignement et la collaboration. Les lignes hiérarchiques ne s'adaptent pas bien, en particulier lorsqu'une entreprise se développe et attire différents types d'ingénieurs et de scientifiques des données. Au lieu de cela, nous forçons la collaboration et la prise de décision interfonctionnelle par le biais d'un ML Council :

Conseil ML

1. Composition : le ML Council est composé d'un groupe de praticiens expérimentés en ML au sein de l'entreprise, généralement des cadres supérieurs de l'ingénierie ML, de la science des données ML et de l'infrastructure ML. Il est dirigé par le président du ML Council, qui prend les décisions en cas d'escalade. Rotation selon une certaine cadence, par exemple tous les 12 mois.
2. Rôle : le rôle du Conseil du ML est de :
   1. assurer un équilibre entre la variabilité spécifique à un projet et l'uniformité à l'échelle de l'entreprise, de manière à ce que nous soyons efficaces en tant qu'entreprise
   2. examiner toutes les nouvelles demandes de ML et fournir un retour d'information à leur sujet
   3. faciliter la pollinisation croisée des idées et des solutions
   4. créer une meilleure visibilité des pièces communes (pour alimenter l'infra)
   5. encourager une communication plus proactive des sources de données et des solutions.
3. Responsabilité : En règle générale, le ML Council doit s'assurer que si les performances de production sont le principal obstacle à la réussite, le responsable technique est un ingénieur en ML. Dans le cas contraire, si les performances statistiques sont le principal obstacle à la réussite, le responsable technique est un scientifique des données. Le ML Council doit vérifier que les solutions bénéficient d'un soutien suffisant et, si possible, qu'elles font partie de l'investissement à long terme dans la plateforme de ML.
4. Autonomie : Si le ML Council n'est pas d'accord sur la solution / l'équipe / le chef de file, le président du ML Council départage et prend une décision.

Le ML Council est le ciment qui maintient ensemble les différentes fonctions (ingénierie, science des données, infrastructure, etc.) et qui permet à toutes les équipes utilisant la ML (recherche, expédition, marketing, prévision, fraude, etc.) de collaborer et d'apprendre les unes des autres.

At DoorDash we have had this organization in place for about five months and things seem to be going well. We will no doubt hit stumbling blocks and have to adjust our processes or clarify certain pieces - but this is part of the excitement of working in a fast-moving dynamic technology startup like DoorDash.

Going forward we will be writing many more blog posts about our problems, failures, and successes with ML, and how we use advanced experimentation methodology to test and iterate. We are committed to sharing our insights and learnings so that the wider ML community can benefit - please check back at our blog regularly to read the latest posts.

Si vous êtes passionné par la résolution de problèmes difficiles dans ce domaine, nous recrutons pour nos équipes de ML et vous pouvez postuler ici. Si vous souhaitez travailler dans d'autres domaines chez DoorDash, consultez notre page carrières.