Construire une plateforme de livraison alimentée par ML comme DoorDash est une entreprise complexe. Elle implique une collaboration entre de nombreuses organisations et équipes interfonctionnelles. Lorsque ce processus fonctionne bien, travailler au sein d'une équipe de développement de produits, livrer des modèles de ML à la production et les améliorer de 1 % chaque jour peut s'avérer une expérience extraordinaire.
Le processus commence généralement par l'identification d'un produit que nous pourrions améliorer en utilisant l'apprentissage automatique. Une fois l'opportunité identifiée, nous commençons généralement par tester l'hypothèse de l'apprentissage automatique à l'aide d'une heuristique avant de décider d'investir dans l'élaboration de modèles d'apprentissage automatique. Si l'heuristique initiale fonctionne, nous développons et remplaçons l'heuristique par les modèles d'apprentissage automatique. Cette étape est généralement suivie par la mise en place d'outils et d'une infrastructure supplémentaires afin de pouvoir continuer à expérimenter différents modèles de ML et à améliorer les modèles de 1 %.
Dans ce billet, nous décrivons toute la réflexion et le travail nécessaires à la réalisation de ce produit final. À titre d'exemple, nous expliquons comment nous avons décidé d'optimiser le moment où les restaurants doivent commencer à préparer les commandes et le moment où le Dasher doit être envoyé pour les récupérer.
Définir le problème de l'entreprise : optimiser les temps de préparation des aliments
Avant de commencer notre voyage de développement ML, nous devons définir le problème de l'entreprise et essayer d'identifier une opportunité d'amélioration. Bien que différentes équipes se concentrent sur différents aspects de notre marché à trois faces, nous créons souvent des collaborations pour résoudre des problèmes commerciaux communs.
One example is around delayed food prep times that increase Dasher wait times. Long Dasher wait times are a negative experience because it's time Dashers could otherwise be using productively to maximize their earnings, and merchants may not want Dashers waiting for orders to be ready in a possibly small foyer. On the flip side, we don't want premature food prep times which could increase "food wait time," the time prepared food is sitting on the counter getting cold before the Dasher arrives to pick it up.
In order to achieve an optimal meal prep time and optimal Dasher wait time, we rely on both internal and external systems and operations. We aim to time the Dasher's arrival at the store with the food ready time. In most cases, we rely on the restaurants to start preparing the food ahead of the Dasher's arrival. Different restaurants start preparing food at different times - sometimes due to other pending orders, sometimes due to higher sensitivity to food waiting on the counter. In some cases, restaurants may wait for the Dasher's arrival to prepare the food, which may cause higher wait times for the Dashers. With this high-level business problem the next step is to dig into the details and figure out exactly what's going on so we can find an opportunity to optimize.
Quand les restaurants commencent-ils à préparer les aliments ?
Usually, restaurants start preparing an order once it's been confirmed (see Figure 1). At the same time, right after the order is confirmed by the merchant, we kickstart the matching and dispatch process. Once a Dasher accepts the order, they will be en route and notified when the order is ready for pickup.
One of the examples where we adjust our decisions and algorithms to the unique needs of our merchants is in the case of "quick service restaurants" - restaurants that generally require very low food preparation times and are more sensitive to food wait times. Merchants at these types of restaurants used to begin preparing these orders only when the Dasher arrived, to ensure the quality of the food upon delivery. This resulted in higher Dasher wait times and longer delivery times and led us to develop the Auto Order Release (AOR) process.
Validation automatique des commandes (AOR)
We mentioned earlier that in a traditional dispatch flow the restaurants start preparing the food as soon as they confirm the order. In the AOR flow, the merchants confirm the order, but the order is held from being released to the kitchen (Figure 2). The order will be automatically released to the kitchen only when a Dasher is at a certain distance from the store. This distance is determined using geolocation indicators and is called the "release distance." When the Dasher enters this predefined geofence, the order is released to the kitchen so they can start preparing the food.
Pour qu'un commerçant soit intégré à ce flux, il doit travailler directement avec nos équipes de commerçants. Une fois le marchand intégré, nos équipes de marchands et d'analystes travailleront pour définir quels magasins doivent être définis comme des magasins AOR, et quelle doit être la distance de libération pour chaque magasin. Lorsqu'un magasin est intégré à l'AOR, toutes ses livraisons sont placées en livraison différée.
Approfondissement du problème du temps d'attente de Dasher :
L'introduction de l'AOR a permis de réduire les temps d'attente et de livraison des Dashers par rapport à la situation antérieure, où les restaurants attendaient que les Dashers arrivent en premier, puisque les restaurants commençaient à préparer les repas un peu plus tôt. Bien que ce flux ait permis de préserver la qualité des aliments, il a engendré de nouveaux défis commerciaux au fil du temps :
- Le paramètre de libération différée est défini au niveau du magasin. Cela offre très peu de flexibilité et limite notre capacité à optimiser les temps d'attente.
- Les équipes chargées de l'efficacité des commerçants ont commencé à remarquer que de plus en plus de commerçants nous informaient de l'existence de Dashers en attente dans les magasins.
- L'exploration continue des données a permis de constater que nous sommes loin d'optimiser le temps que les Dashers passent à attendre que les commandes soient préparées. La variance réelle des temps de préparation des aliments et d'arrivée des Dashers n'était pas suffisamment bien représentée lorsque l'on s'appuyait uniquement sur des géofences codées en dur.
- L'ajout de nouveaux commerçants à l'AOR est devenu difficile à mettre en œuvre car il fallait définir manuellement des zones géographiques pour chaque magasin.
Construire une stratégie et une équipe
We saw an opportunity to update the AOR flow from a hard-coded heuristic based flow to a more dynamic decision-making system to optimize Dasher wait times at the store without degrading the food quality. This kind of task is hard to achieve without cross-functional collaboration. It requires updating our assignment system and upstream services, as well as maintaining a deep understanding of the merchant's operation and experience.
Nous avons formé un groupe de travail transversal officiel composé de la stratégie et des opérations, de la science des données et de l'apprentissage automatique, du produit, de l'analyse et de l'ingénierie. Notre objectif final était de développer une fonctionnalité qui décide dynamiquement de l'heure optimale de libération de la commande pour chaque livraison et qui réduit les temps d'attente du Dasher sans augmenter les temps d'attente des plats.
Définir des étapes par la collaboration et l'itération
While our goal was to launch a new ML-based feature, to align with our "dream big, start small" mentality we had to define very well-scoped milestones and steps and divide responsibilities efficiently. We wanted to balance reaching faster short-term results and maintaining our long-term vision. To achieve that, we agreed on these high-level milestones:
MVP : basé sur l'heuristique
En commençant par un simple ensemble de conditions, nous avons pu mettre en œuvre une approche simple qui, selon nous, peut être plus performante en production que notre solution actuelle. Le MVP est principalement piloté par notre équipe de stratégie et d'analyse, et nous nous sommes appuyés sur l'ingénierie pour effectuer les mises à jour architecturales nécessaires.
- Ajouter la capacité de l'infrastructure à décider pour chaque commande si.. :
- La commande doit être transmise instantanément à la cuisine (flux traditionnel).
- L'ordre doit être placé sur un appel différé (flux initial de l'AOR).
- Définir et tester un ensemble initial d'heuristiques pour décider du type de lancement de l'ordre.
Caractéristiques finales : Basé sur le ML
- Développer un modèle ML pour estimer le temps nécessaire aux commerçants AOR pour préparer les aliments.
- Mettre à jour notre architecture pour appeler les modèles ML afin de décider si une commande doit être placée sur une version retardée ou une version instantanée.
- Utiliser des modèles ML pour définir la géofence optimale
Let's go through a few of the main milestones to understand what our main considerations were at each step.
Restez informé grâce aux mises à jour hebdomadaires
Abonnez-vous à notre blog d'ingénierie pour recevoir régulièrement des informations sur les projets les plus intéressants sur lesquels notre équipe travaille.
Please enter a valid email address.
Merci de vous être abonné !
Nouvelle fonctionnalité, simple au départ
Our starting point was a flow that's hard coded on a store level. So if a store was put on AOR, we couldn't change the release strategy for an order even if we had indicators that the store needs more time to prepare the food. The first thing that we had to do was to change the architecture and add the ability to dynamically decide for each delivery, if the order should be placed on a delayed release (regular AOR) or released to the kitchen immediately (if we anticipate the store needing more time to prepare the food).
Pour commencer, nous avons défini un nouvel ensemble de conditions simples (heuristiques) pour déclencher la décision pour chaque commande. Par exemple, nous savons que les commandes plus importantes à certains moments nécessitent un temps de préparation plus long. De cette façon, même si un magasin est placé en AOR, si nous pensons que le temps de préparation nécessaire sera supérieur à un certain seuil, la mise à disposition immédiate de la nourriture permettra de gagner du temps et donc de réduire les temps d'attente au Dasher. Nos équipes d'analystes et de commerçants ont identifié certains magasins où les temps d'attente étaient élevés et se sont associés à certains commerçants pour lancer une expérience visant à examiner si nous pouvions réduire les temps d'attente sans dégrader aucun de nos principaux indicateurs de qualité des aliments. Une fois le MVP prêt, nous avons pu commencer à expérimenter en production.
Lancer des expériences dès que possible
Le fait de lancer l'expérimentation dès que possible nous permet de commencer à recueillir des informations et de poursuivre le développement en même temps. L'intégration de la ML a nécessité un développement supplémentaire, tant du point de vue de l'architecture que de la recherche (nous devons nous connecter à davantage de services pour effectuer des appels afin d'obtenir nos prédictions de ML et nous devons développer et ajouter de nouveaux modèles à nos pipelines d'entraînement et de prédiction). L'adoption de cette approche simple, basée sur l'heuristique, nous a permis de commencer à recueillir des informations et à répondre à des questions telles que :
- La fonctionnalité fonctionne-t-elle comme prévu dans l'environnement de production ?
- Les commerçants suivent-ils le nouveau processus comme prévu ?
- Pouvons-nous observer la réduction du temps d'attente prévue dans l'environnement de production ? Existe-t-il des inconnues que nous n'avons pas prises en compte ?
Dans notre cas, nous avons immédiatement constaté une réduction des temps d'attente pour les Dashers. En ajoutant la possibilité de décider d'une stratégie de libération pour chaque livraison plutôt qu'au niveau du magasin, les commandes à temps de préparation élevé ont été libérées plus tôt, ce qui a donné aux commerçants plus de temps pour préparer la nourriture. Ce parti pris pour l'action a porté ses fruits et, au moment de conclure cette expérience, nous étions déjà satisfaits :
- Un MVP simple et fonctionnel qui peut être livré en production (le résultat de nos expériences initiales)
De plus, comme nous avons mis à profit le temps de l'expérience pour continuer à développer une solution plus dynamique, nous étions également prêts :
- Un système testable qui peut se connecter à plusieurs services pour obtenir des prévisions en temps réel
- Un ensemble de modèles ML qui sont de bons candidats pour remplacer notre heuristique initiale
Au-delà des progrès techniques, c'est le fait de sortir le MVP le plus tôt possible qui nous a motivés :
- Amélioration de nos indicateurs de base
- L'adhésion des parties prenantes nous a permis de gagner du temps pour intégrer les modèles de ML dans notre fonctionnalité.
Ajout d'une couche de ML pour mieux optimiser les temps d'attente de Dasher
Une fois que nous avons établi notre MVP et que nous l'avons mis en production, nous avons commencé à introduire progressivement plus de complexité et de sophistication dans notre système.
Construire un ensemble de nouveaux prédicteurs
Afin de décider quand transmettre une commande à la cuisine, nous avons développé un ensemble de nouveaux prédicteurs pour estimer le temps nécessaire au restaurant pour préparer la nourriture par rapport au temps nécessaire à un Dasher pour arriver au restaurant et récupérer la nourriture. Nous nous sommes appuyés sur quelques modèles existants pour estimer l'heure d'arrivée du Dasher. Bien que nous disposions déjà de plusieurs modèles de temps de préparation, nous avons dû développer un nouveau prédicteur pour l'objectif AOR, car il existe quelques caractéristiques uniques dans ce cas qui n'ont pas été prises en compte dans les modèles généraux du marché. Nous avons utilisé un modèle LightGBM qui a atteint d'excellentes performances hors ligne et qui s'est avéré efficace et évolutif dans des cas d'utilisation similaires chez DoorDash.
Evaluating the model's performance against business metrics
One of the main challenges of selecting the best model offline is the limited predictability of the business metric impact. Our core model predicts the food preparation time and the product goals were reducing the Dasher wait times without degrading the end-to-end delivery time and without increasing food wait times. Moving quickly to experiments helped us determine how to tune our loss function to capture these unique business requirements. One of the great advantages of using LightGBM was the ease of adjusting the loss function to bias and tuning the model's performance to our unique business needs.
Franchir la ligne d'arrivée
After a few months of work, we have reached the majority of our original plan - a new feature that leverages ML models to dynamically decide when an order should be released to the kitchen. We had a few more hypotheses we wanted to test and a goal of leveraging the above architecture and models to dynamically define the optimal release distance for each order that was placed on a delayed release. One of the surprising challenges was defining when our work is complete and when we move to a different type of development life cycle - continued maintenance and monitoring. We decided to scope some additional work to test a new Dasher speed estimation model. This new model improved our accuracy and provided another incremental win to wrap up our development work.
Conclusion
Dans cet article, nous avons décrit comment nous avons appliqué quelques pratiques importantes pour concevoir et livrer une nouvelle fonctionnalité : commencer simplement, décomposer en étapes et travailler de manière itérative. Bien qu'il s'agisse de pratiques relativement courantes, il existe quelques caractéristiques de travail uniques chez DoorDash qui ont permis notre succès :
- Strong bias for action: it might be difficult to define what "good enough" actually means and not be paralyzed by all the different ways we can make something better. We are a very experimentation-oriented team and we encourage each other to ship as soon as we can make a positive impact
- We operate in a unique way that allows us to construct teams around great ideas to see them mature and ship them in production. This team was constructed from the bottom up - solid analysis and cross functional collaborations led us to build a formal team
- Fournir des résultats progressifs était le carburant dont nous avions besoin pour obtenir le temps et l'adhésion nécessaires à la réalisation de notre objectif à long terme. La mise en place d'une infrastructure de ML et le développement de modèles capables de fonctionner en production prennent du temps et peuvent représenter un risque. Nous maintenons constamment un certain équilibre entre ces paris à court et à long terme.
- Construire les outils nécessaires pour soutenir la fonctionnalité au fur et à mesure de son développement - outils opérationnels pour faciliter l'intégration des magasins, outils pour un débogage plus rapide, et cadres pour une expérimentation rapide.
Nous espérons que ces étapes et cette approche ouvriront la voie à d'autres personnes confrontées à des défis similaires et qu'elles apporteront un éclairage sur le développement ML chez DoorDash.