One challenge in running our platform is being able to accurately track Merchants' operational status and ability to receive and fulfill orders. For example, when a Merchant's location is physically closed but marked as open on our platform, we might create a bad experience for all of our users; a Dasher cannot complete their accepted delivery, the Consumer cannot receive their ordered food, and the Merchant could see lower future revenues. Similarly, when a Merchant who is open but marked as closed on our platform results in similarly negative outcomes; Consumers can not make an order, the Merchant loses potential revenue, and Dashers lose potential delivery opportunities as well.
Cet article explique comment nous avons utilisé l'apprentissage automatique pour prédire l'état opérationnel d'un magasin et offrir la meilleure expérience possible aux commerçants, aux caissiers et aux clients.
Le défi de l'exactitude des heures d'ouverture des magasins
On the DoorDash marketplace stores operate independently, which means that we do not always get the most up-to-date information on merchant's business hours and operational status. Not having accurate operational hours is an acute problem when merchants are dealing with staffing and supply-chain shortages. Therefore, in a small percentage of deliveries, the Dasher might find that the store is actually closed. With tens of millions of deliveries being fulfilled each week, quickly and efficiently confirming such merchant closures and reacting to them is key for these reasons:
- Permettre aux consommateurs d'être rapidement informés du problème et d'être remboursés.
- Pour s'assurer qu'aucune commande ne peut plus être passée dans un magasin fermé.
However, leveraging our support team to act on these Dasher-reported closures is both costly and inefficient, given the thousands of closed store cases that are reported each day. To help Dashers quickly resolve closed merchant issues with maximum efficiency, we built a "Dasher reports store closed" feature [DRSC for short] directly in the Dasher app. In the rest of the article, we will walk through how this feature works and how we augmented it with ML to improve its performance and automation.
Fonctionnement du CSDDR
Lorsque les Dashers se trouvent dans l'impossibilité de récupérer une commande dans un magasin qui semble fermé, ils sont invités à prendre une photo du magasin pour lancer le processus de signalement. Lorsqu'une photo valide est téléchargée, le Dasher est indemnisé pour le temps partiel et l'effort qu'il a consacrés à se rendre au magasin, et il est désaffecté de la livraison afin de pouvoir poursuivre sa course et se voir confier d'autres livraisons.
When a DRSC report is received, a set of actions can be taken on the order: we could either cancel the delivery and reimburse the customer, or alternatively when we have reason to doubt the report's accuracy we could reassign the order to a new Dasher to re-attempt the pickup.
Parallèlement, nous devons contacter le commerçant pour confirmer que le magasin est effectivement fermé, afin de pouvoir le mettre en pause sur la plateforme. Si le commerçant confirme la fermeture ou ne répond pas, nous mettrons le magasin en pause pendant une période déterminée. La mise en pause du commerçant évite aux consommateurs et aux Dashers d'être confrontés inutilement à un autre problème similaire alors que nous disposons déjà d'informations indiquant que le magasin est fermé. Si le commerçant confirme que le magasin est ouvert, la déclaration est rejetée, nous trouvons un autre Dasher pour exécuter cette commande et le commerçant peut continuer à recevoir d'autres commandes.
L'existence de rapports inexacts, bien que peu fréquents, constitue un défi majeur pour le DRSC, que nous nous sommes efforcés de minimiser à l'aide du ML.
Pourquoi nous avons choisi la voie du ML
Sans examiner attentivement chaque rapport DRSC, nous risquions d'annuler inutilement des commandes ou de mettre des marchands en pause. Nous avions besoin d'une solution basée sur le ML pour automatiser ce processus d'examen à grande échelle. Étant donné que certains rapports DRSC sont inexacts, soit parce que l'image ne montre pas un magasin fermé, soit parce que le commerçant confirme qu'il est en fait ouvert, le fait de disposer d'un moyen fiable d'examiner les validités DRSC signifiait que nous serions mieux équipés pour réaffecter un autre Dasher et terminer la commande, lorsque la validité du rapport DRSC est remise en question.
Une étape de validation permettant de catégoriser les rapports devrait être précise et rapide, et s'adapter à des milliers de rapports quotidiens. Les humains pourraient s'en charger, mais cela serait coûteux, prendrait beaucoup de temps et ne serait pas extensible. Un ensemble de règles heuristiques permettrait d'atteindre la vitesse et l'échelle requises, mais ne serait que modérément précis, les erreurs commises en transmettant des rapports inexacts étant coûteuses pour les commerçants et pénibles pour les clients. Compte tenu de l'incertitude inhérente au problème, un modèle de probabilité conditionnelle - une formule mathématique permettant d'attribuer des probabilités aux résultats en fonction d'informations variables - semble particulièrement adapté à cette tâche. En effet, les modèles de probabilités conditionnelles peuvent regrouper les informations disponibles sur un magasin et un Dasher pour en déduire l'état du magasin, ce qui nous aide à prendre des décisions optimales.
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é !
Comment le modèle ML a remplacé l'heuristique
Nous sommes partis de l'idée qu'il fallait calculer la probabilité qu'un magasin donné soit fermé lorsqu'une déclaration de CRDS est déposée,
Probabilité (le magasin est fermé | rapport du CSDH).
Bien qu'il soit possible d'élaborer un modèle plus général pour déduire l'état des magasins, nous nous sommes limités au cas d'utilisation du DRSC.
Notre premier défi était que la variable dépendante (le statut d'un magasin) est inconnue et qu'il serait excessivement coûteux de la mesurer (c'est-à-dire que nous ne savons pas réellement si un magasin est fermé ou non). Pour construire la variable de l'état du magasin, nous avons examiné les rapports DRSC antérieurs et vérifié si ces magasins honoraient les commandes ou répondaient à nos messages sur l'état du magasin dans l'heure qui suivait un rapport DRSC. Par exemple, lorsqu'un Dasher est en mesure d'effectuer un retrait dans les 15 minutes suivant un rapport DRSC historique, nous en déduisons que le magasin est probablement toujours ouvert, malgré le rapport.
Un rapport DRSC présente des caractéristiques de base telles que l'identifiant du magasin, l'identifiant de l'effaceur, l'horodatage du rapport, ainsi qu'une image de la devanture du magasin prise par l'effaceur. Les identifiants du magasin et du Dasher sont utiles pour relier un rapport DRSC à l'historique des livraisons effectuées dans le magasin et à l'historique des livraisons effectuées par le Dasher dans les différents magasins. Les données historiques nous permettent d'élaborer des fonctionnalités telles que le nombre de rapports récents pour un magasin donné, la dernière fois qu'un enlèvement a eu lieu et le nombre de rapports de fermeture de magasin non valides pour un Dasher donné sur plusieurs mois.
Additionally, an image of the storefront might contain valuable information about its status by capturing a sign on the door indicating that it's closed or showing that lights are off. By converting images into a summary signal such as the probability that a "store is closed" or a "store is open" we can process and use hundreds of thousands of images quickly. We accomplished this by training an image classifier using our internal image processing platform. The image classifier compresses the image information into a single number which we then use as one of our model features.
Enfin, un modèle LightGBM unique peut combiner des informations historiques et des images pour calculer la probabilité qu'un magasin soit fermé. La probabilité nous permet de prendre des décisions. Aujourd'hui, nous utilisons des seuils pour diviser l'ensemble des probabilités 0-1 en intervalles qui correspondent à nos actions :
- la faible probabilité de fermeture d'un magasin conduit à annuler la commande et à trouver un nouveau Dasher
- des probabilités intermédiaires nous amèneraient à annuler l'ordre
- des probabilités élevées nous amèneraient à annuler la commande et à mettre le magasin en pause.
Suite au déploiement de ce modèle de ML et à une expérience AB, nous avons confirmé que l'amélioration de la prise de décision permet désormais d'éviter l'annulation de milliers de livraisons chaque semaine. Le fait d'éviter les annulations se traduit par une meilleure expérience pour le consommateur, une augmentation des revenus pour nos commerçants partenaires, davantage d'opportunités de gains pour les Dashers et une activité plus robuste pour DoorDash. Cette initiative est un exemple de la manière dont la prise de décision statistique automatisée peut être utilisée pour construire une infrastructure logistique intelligente et apporter de la valeur à tous les participants du marché.
Prochaine étape : construction d'une fonction de perte dynamique
La prochaine itération majeure consiste à rendre les seuils de décision dynamiques. En intégrant l'heure de la journée, le volume futur du magasin et les futures annulations potentielles, nous pourrions affiner notre prise de décision lorsqu'un rapport DRSC est reçu. Nous pourrions alors construire une fonction de perte qui produirait pour chaque action et chaque état du magasin un coût que nous paierions. Une fonction de perte et un modèle de probabilité peuvent être utilisés pour calculer la perte attendue et trouver une action qui la minimise. En fait, nous aurons des seuils dynamiques implicites qui s'adapteront au temps et aux conditions de chaque magasin. Le fait d'être sensible au coût pour chaque Dasher et chaque Merchant rendra nos décisions encore plus efficaces.
Conclusion
De nombreuses entreprises ont construit leurs opérations sur des heuristiques ou des règles simples. Les règles sont le moyen le plus rapide de prouver qu'un problème peut être résolu en passant de rien à une performance fonctionnelle. Cependant, il peut y avoir un coût d'opportunité important à ne pas envisager de transformer la solution heuristique en une solution de ML optimisée qui augmentera les performances à un niveau proche du maximum. L'utilisation d'outils de ML simples et peu contraignants comme LightGBM est un excellent moyen de passer de simples règles à une infrastructure intelligente et de maximiser l'efficacité.