Ir al contenido

Blog


Cómo DoorDash actualizó una heurística con ML para salvar miles de pedidos cancelados

10 de enero de 2023

|
Slava Nikitin

Slava Nikitin

Gabriel Lerner

Gabriel Lerner

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. 

En este artículo se explica cómo utilizamos el aprendizaje automático para predecir el estado operativo de una tienda y ofrecer la mejor experiencia posible a comerciantes, usuarios y clientes. 

El reto de disponer de un horario de apertura preciso 

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:

  • Para que los consumidores puedan ser informados rápidamente del problema y obtener el reembolso. 
  • Para asegurarse de que no se pueden hacer más pedidos en un almacén cerrado.

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. 

Cómo funciona el DRSC 

Cuando los Dashers no pueden recoger un pedido en una tienda que parece cerrada, se les pide que hagan una foto de la tienda para iniciar el proceso de notificación. Cuando se sube una foto válida, se compensa al Dasher por el tiempo parcial y el esfuerzo que ha empleado en llegar a la tienda, y se le desasigna la entrega para que pueda continuar su carrera y se le asignen otras entregas. 

Figura 1. La aplicación Dasher genera el informe DRSC automatizado.
Figura 1. La aplicación Dasher genera el informe DRSC automatizado.

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.

Paralelamente, tenemos que ponernos en contacto con el comerciante para confirmar que la tienda está efectivamente cerrada, de modo que podamos ponerla en pausa en la plataforma. Si el comerciante confirma el cierre o no responde, pondremos la tienda en pausa durante un periodo de tiempo determinado. Poner en pausa la tienda evita que los consumidores y los Dashers experimenten innecesariamente otro problema similar cuando ya tenemos información de que la tienda está cerrada. Si el comerciante confirma que la tienda está abierta, se rechaza el informe, buscamos a otro Dasher para que realice este pedido y el comerciante puede seguir recibiendo otros pedidos. 

La existencia de informes inexactos, aunque infrecuentes, es un reto importante para DRSC que nos propusimos minimizar utilizando el ML.

Por qué optamos por el ML

Si no examinábamos detenidamente cada informe DRSC, podíamos cancelar pedidos o poner en pausa a los comerciantes innecesariamente. Necesitábamos una solución basada en ML para automatizar este proceso de revisión a gran escala. Dado que algunos informes DRSC son imprecisos, ya sea porque la imagen no muestra una tienda cerrada o porque el comerciante confirma que en realidad está abierta, disponer de un medio fiable para revisar las validaciones DRSC significaba que estaríamos mejor equipados para reasignar a otro Dasher y completar el pedido, cuando la validez del informe DRSC estuviera en duda. 

A validation step that can categorize reports would need to be accurate and fast, and scale up to thousands of daily reports. Humans could do it, but it would be expensive, time-consuming, and unscalable. A heuristic set of rules could handle the required speed and scale but would be only moderately accurate, with errors in passing inaccurate reports being costly to merchants and painful for customers. Given the inherent uncertainty of the problem, a conditional probability model - a mathematical formula for assigning probabilities to outcomes given varying information - seems especially fit for the job. This is because conditional probability models can pool available information about a store and a Dasher to output inferences about the store status that help us make optimal decisions.

Manténgase informado con las actualizaciones semanales

Suscríbase a nuestro blog de ingeniería para recibir actualizaciones periódicas sobre los proyectos más interesantes en los que trabaja nuestro equipo.

Cómo el modelo ML sustituyó a la heurística

Partimos de la idea de querer calcular la probabilidad de que una tienda determinada esté cerrada cuando se presenta un informe DRSC,

Probabilidad(Tienda cerrada | Informe DRSC).

Aunque se podría construir un modelo más general para inferir el estado de las tiendas, nos hemos limitado a tratar únicamente el caso de uso de DRSC. 

Nuestro primer reto era que la variable dependiente (el estado de una tienda) es desconocida y sería prohibitivamente cara de medir (es decir, no sabemos realmente si una tienda está cerrada o no). Para construir la variable del estado de la tienda, nos fijamos en los informes DRSC anteriores y comprobamos si dichas tiendas cumplían los pedidos o respondían a nuestros mensajes sobre el estado de la tienda en la hora siguiente a un informe DRSC. Por ejemplo, cuando un Dasher es capaz de completar una recogida en los 15 minutos siguientes a un informe DRSC histórico, deducimos que la tienda probablemente seguía abierta, a pesar del informe.

Un informe DRSC proporciona características básicas como el Id. de la tienda, el Id. del Dasher, la fecha y hora del informe, así como una imagen del escaparate tomada por el Dasher. Los Id. de tienda y de Dasher son útiles para conectar un informe DRSC a un historial de entregas en la tienda y a un historial de entregas entre tiendas por parte del Dasher. Los datos históricos nos permiten crear características como el número de informes recientes para una tienda determinada, la última vez que se produjo una recogida y el número de informes de tienda cerrada no válidos para un Dasher determinado a lo largo de varios meses.

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.

Figura 2. Entradas del modelo DRSC ML y conjunto de acciones de salida
Figura 2. Entradas del modelo DRSC ML y conjunto de acciones de salida

Por último, un único modelo LightGBM puede combinar información histórica y de imágenes para calcular la probabilidad de que una tienda esté cerrada. La probabilidad nos permite tomar decisiones. En la actualidad, utilizamos umbrales para dividir el conjunto de probabilidades 0-1 en intervalos que se corresponden con nuestras acciones:

  • la baja probabilidad de que una tienda esté cerrada lleva a desasignar el pedido y buscar un nuevo Dasher 
  • las probabilidades intermedias nos llevarían a anular la orden
  • altas probabilidades nos llevarían tanto a cancelar el pedido como a poner en pausa la tienda. 

Tras el despliegue de este modelo ML y un experimento AB, confirmamos que la mejora en la toma de decisiones ahora evita que se cancelen miles de entregas cada semana. Evitar cancelaciones produce una mejor experiencia del consumidor, mayores ingresos para nuestros comerciantes asociados, más oportunidades de ganancias para los Dashers y un negocio más sólido para DoorDash. Esta iniciativa es un ejemplo de cómo la toma de decisiones estadística automatizada puede utilizarse para construir una infraestructura logística inteligente y proporcionar valor a todos los participantes en el mercado.

Siguiente paso: crear una función de pérdida dinámica

La siguiente gran iteración es hacer que los umbrales de decisión sean dinámicos. Al incorporar la hora del día, el volumen futuro de la tienda y las posibles cancelaciones futuras, podríamos afinar nuestra toma de decisiones cuando se reciba un informe DRSC. A continuación, podríamos construir una función de pérdidas que nos diera un coste por cada acción y estado de la tienda. Una función de pérdida y un modelo de probabilidad pueden utilizarse para calcular la pérdida esperada y encontrar una acción que la minimice. En efecto, tendremos umbrales dinámicos implícitos que se ajustan al tiempo y a las condiciones de cada tienda. Ser sensibles al coste para cada Dasher y comerciante hará que nuestras decisiones sean aún más eficaces. 

Conclusión

Muchas empresas han construido sus operaciones sobre heurísticas o reglas simples. Las reglas son la vía más rápida para demostrar que un problema tiene solución, pasando de la nada al rendimiento funcional. Sin embargo, puede haber un gran coste de oportunidad en no considerar la actualización de la solución heurística a una solución ML optimizada que aumente el rendimiento a un nivel casi máximo. El uso de herramientas de ML sencillas y de bajo esfuerzo como LightGBM es una excelente forma de iniciar el viaje desde las reglas simples a la infraestructura inteligente y maximizar la eficiencia. 

Sobre los autores

  • Slava Nikitin

    Slava Nikitin is a Data Scientist at DoorDash since October 2021, working on the logistics machine learning team. Slava focuses on improving delivery excellence and efficiency.

  • Gabriel Lerner

    Gabe Lerner has been a Data Scientist at DoorDash since November 2020, working on the logistics analytics team. Gabe focuses on delivery excellence and defect reduction.

Trabajos relacionados

Ubicación
San Francisco, CA; Mountain View, CA; Nueva York, NY; Seattle, WA
Departamento
Ingeniería
Ubicación
San Francisco, CA; Sunnyvale, CA
Departamento
Ingeniería
Ubicación
San Francisco, CA; Sunnyvale, CA; Seattle, WA
Departamento
Ingeniería
ID de trabajo: 3013456
Ubicación
Pune, India
Departamento
Ingeniería
Ubicación
San Francisco, CA; Seattle, WA; Sunnyvale, CA
Departamento
Ingeniería