Ciclo de vida de un producto ML de éxito: Reducción de los tiempos de espera

Crear una plataforma de reparto basada en ML como DoorDash es una tarea compleja. Implica la colaboración entre numerosas organizaciones y equipos multifuncionales. Cuando este proceso funciona bien, puede ser una experiencia increíble trabajar en un equipo de desarrollo de productos, enviar modelos de ML a producción y hacer que mejoren un 1 % cada día. 

El proceso suele comenzar con la identificación de un producto que podríamos mejorar utilizando el aprendizaje automático. Una vez que identificamos una oportunidad, solemos empezar probando la hipótesis de ML utilizando una heurística antes de decidir invertir en la creación de los modelos de ML. Si la heurística inicial funciona, desarrollamos y sustituimos la heurística por los modelos de ML. Este paso suele ir seguido de la creación de más herramientas e infraestructura para que podamos seguir experimentando con diferentes modelos de ML y seguir mejorando los modelos en un 1%.

En este artículo, describiremos todo lo que se ha pensado y trabajado para conseguir ese producto final. A modo de ejemplo, analizaremos cómo decidimos optimizar el momento en que los restaurantes deben empezar a preparar los pedidos y el momento en que el Dasher debe ser enviado a recogerlos.

Planteamiento del problema empresarial: optimizar los tiempos de preparación de los alimentos 

Antes de iniciar nuestro viaje de desarrollo de ML, tenemos que analizar el problema empresarial e intentar identificar una oportunidad de mejora. Aunque los distintos equipos se centran en diferentes aspectos de nuestro mercado a tres bandas, a menudo creamos colaboraciones para resolver problemas empresariales conjuntos. 

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. 

¿Cuándo empiezan a preparar la comida los restaurantes?

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. 

Liberación automática de pedidos (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.  

Para que un comerciante se incorpore a este flujo, trabajará directamente con nuestros equipos de comerciantes. Una vez que el comerciante esté incorporado, nuestros equipos de comerciantes y de análisis trabajarán para definir qué tiendas deben definirse como tiendas AOR y cuál debe ser la distancia de liberación para cada tienda. Cuando una tienda se incorpora a AOR, todas sus entregas se realizan en diferido.

Profundizando en el problema del tiempo de espera de Dasher: 

La introducción del AOR redujo los tiempos de espera y de entrega de los Dasher en comparación con la situación anterior, en la que los restaurantes esperaban a que los Dashers llegaran primero, ya que los restaurantes empezaban a preparar la comida un poco antes. Aunque este flujo seguía protegiendo la calidad de la comida, con el tiempo introdujo algunos nuevos retos empresariales:

• La configuración de la liberación retardada se define a nivel de tienda. Esto ofrece muy poca flexibilidad y limita nuestra capacidad para optimizar los tiempos de espera.
• Los equipos de eficiencia comercial empezaron a darse cuenta de que cada vez más comercios nos notificaban que había Dashers esperando en las tiendas.
• La exploración continua de datos identificó que estamos lejos de optimizar el tiempo que los Dasher pasan esperando a que se preparen los pedidos. La varianza real de los tiempos de preparación de los alimentos y de llegada de los Dasher no estaba suficientemente bien representada cuando se confiaba únicamente en las geocercas codificadas.
• Añadir nuevos comercios a AOR se convirtió en un reto a escala, ya que requería definir manualmente geocercas para cada tienda.

Crear una estrategia y un equipo

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. 

Formamos un grupo de trabajo interdisciplinar formado por Estrategia y Operaciones, Ciencia de Datos y Aprendizaje Automático, Producto, Análisis e Ingeniería. Nuestro objetivo final era desarrollar una función que decidiera dinámicamente la hora óptima de entrega de cada pedido y redujera el tiempo de espera de Dasher sin aumentar el tiempo de espera de la comida. 

Definición de hitos mediante la colaboración y la iteración

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: basado en heurística

Empezar con un conjunto sencillo de condiciones nos permite aplicar primero un enfoque simple que creemos que puede funcionar mejor en producción que nuestra solución actual. El MVP está impulsado principalmente por nuestro equipo de estrategia y análisis, y nos apoyamos en ingeniería para realizar las actualizaciones arquitectónicas necesarias.

1. Añadir la capacidad de infraestructura para decidir para cada orden si:

• El pedido debe pasar instantáneamente a la cocina (flujo tradicional)
• El pedido debe realizarse en diferido (flujo AOR original)

2. Definir y probar un conjunto inicial de heurísticas para decidir el tipo de liberación de pedidos. 

Característica final: Basado en ML 

3. Desarrollar un modelo ML para estimar el tiempo necesario para que los comerciantes AOR preparen la comida.
4. Actualizar nuestra arquitectura para llamar a los modelos ML y decidir si un pedido debe realizarse en diferido o al instante.
5. Utilizar modelos ML para definir la geovalla óptima 

Let's go through a few of the main milestones to understand what our main considerations were at each step.  

Nueva función, empezando por lo sencillo

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). 

Para empezar, definimos un nuevo conjunto de condiciones sencillas (heurísticas) para desencadenar la decisión de cada pedido. Por ejemplo, sabemos que los pedidos más grandes a determinadas horas requieren más tiempo de preparación. De este modo, aunque una tienda se coloque en AOR, si creemos que el tiempo de preparación necesario será superior a un umbral, la liberación inmediata de la comida permitirá disponer de más tiempo y, por tanto, reducir los tiempos de espera de Dasher. Nuestros equipos de análisis y de comerciantes identificaron algunas tiendas con altos tiempos de espera de Dasher y se asociaron con algunos comerciantes para lanzar un experimento para examinar si podemos reducir los tiempos de espera de Dasher sin degradar ninguna de nuestras principales métricas de calidad de los alimentos. Una vez que el MVP estuvo listo, pudimos empezar a experimentar en producción. 

Poner en marcha experimentos lo antes posible

Poner en marcha la experimentación lo antes posible nos permite empezar a recopilar información y mantener el desarrollo al mismo tiempo. La incorporación de ML requirió un desarrollo adicional, tanto en el aspecto arquitectónico como en el de la investigación (necesitamos conectarnos a más servicios para realizar llamadas con el fin de obtener nuestras predicciones ML y necesitamos desarrollar y añadir nuevos modelos a nuestros canales de formación y predicción). Adoptar este sencillo enfoque basado en la heurística nos permitió empezar a recopilar información y responder a preguntas como las siguientes: 

• ¿Funciona la función en el entorno de producción como se esperaba?
• ¿Siguen los comerciantes el nuevo proceso según lo previsto?
• ¿Podemos observar la reducción prevista del tiempo de espera en el entorno de producción? ¿Hay alguna incógnita que no hayamos tenido en cuenta? 

En nuestro caso, vimos inmediatamente una reducción en los tiempos de espera que los Dashers estaban experimentando. Al añadir la posibilidad de decidir una estrategia de liberación para cada entrega frente a a nivel de tienda, los pedidos con mayor tiempo de preparación se liberaban antes, lo que daba a los comerciantes más tiempo para preparar la comida. Esta predisposición a la acción dio sus frutos, y al concluir este experimento, ya los teníamos: 

• Un MVP sencillo y funcional que pueda ponerse en producción (el resultado de nuestros experimentos iniciales).

Además, aprovechamos el tiempo que duró el experimento para seguir desarrollando una solución más dinámica con la que también estábamos preparados:

• Un sistema comprobable que puede conectarse a múltiples servicios para obtener predicciones en tiempo real. 
• Un conjunto de modelos ML que son buenos candidatos para sustituir a nuestra heurística inicial

Y más allá de los avances técnicos, sacar el MVP lo antes posible nos atrapó:

• Mejora de nuestras métricas básicas
• La aceptación de las partes interesadas nos ha permitido disponer de más tiempo para incorporar modelos ML a nuestras funciones.

Añadir una capa ML para optimizar mejor los tiempos de espera de Dasher

Una vez establecido nuestro MVP y puesto en producción, empezamos a introducir gradualmente más complejidad y sofisticación en nuestro sistema. 

Construir un conjunto de nuevos predictores

Para decidir cuándo enviar un pedido a la cocina, desarrollamos un conjunto de nuevos predictores para estimar el tiempo necesario para que el restaurante prepare la comida y el tiempo necesario para que un Dasher llegue al restaurante y recoja la comida. Para estimar el tiempo de llegada del Dasher nos basamos en algunos modelos existentes. Aunque ya contamos con varios modelos de tiempo de preparación, tuvimos que desarrollar un nuevo predictor para el propósito de AOR, ya que hay algunas características únicas en este caso que no fueron capturadas en los modelos generales del mercado. Utilizamos un modelo LightGBM que alcanzó un gran rendimiento fuera de línea y demostró funcionar y escalar bien en casos de uso similares en 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.

A través de la línea de meta

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.  

Conclusión

En este post describimos cómo aplicamos algunas prácticas importantes para diseñar y lanzar una nueva función: empezar de forma sencilla, dividirla en hitos y trabajar de forma iterativa. Aunque se trata de prácticas relativamente comunes, en DoorDash hay algunas características de trabajo únicas que han hecho posible nuestro éxito: 

• 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
• Proporcionar resultados incrementales era el combustible que necesitábamos para conseguir tiempo y aceptación para alcanzar nuestro objetivo a largo plazo. Construir una infraestructura de ML y desarrollar modelos que puedan funcionar en producción lleva tiempo y puede suponer un riesgo. Mantenemos constantemente cierto equilibrio entre estas apuestas a corto y largo plazo
• Building out the necessary tooling to support the feature as it grows - operations tooling for easily onboarding stores, tooling for faster debugging, and frameworks for rapid experimentation

Esperamos que estos pasos y enfoque puedan allanar el camino para otros que se enfrentan a retos similares y arrojar algo de luz sobre el desarrollo de ML en DoorDash.