Cómo DoorDash mejora las predicciones navideñas mediante un enfoque ML en cascada

En DoorDash, generamos previsiones de oferta y demanda para planificar de forma proactiva operaciones como la adquisición del número adecuado de Dashers (conductores de reparto) y la adición de pagos adicionales cuando prevemos una baja oferta. Es difícil generar previsiones precisas durante las vacaciones porque algunas técnicas de aprendizaje automático (por ejemplo, XGBoost, Gradient Boosting, Random Forest) tienen dificultades para gestionar variaciones elevadas con datos limitados. Aquí explicamos cómo mejoramos la precisión de las previsiones mientras nos preparamos para las vacaciones con la vista puesta en garantizar experiencias de alta calidad tanto para los clientes como para los Dashers en miles de mercados.  

Es imperativo que adoptemos medidas de configuración de la oferta y la demanda para alcanzar un equilibrio que garantice la calidad tanto para los clientes como para Dashers. Las previsiones de oferta y demanda son los principales datos de entrada de nuestros sistemas de movilización proactiva, como se muestra en la Figura 1. Utilizamos un modelo GBM (gradient boosting machine ) para generar nuestras previsiones a partir de miles de puntos de partida: pequeños grupos de códigos postales. Por razones que analizaremos más adelante, la precisión de las previsiones disminuye en torno a acontecimientos extremos poco frecuentes, como las vacaciones. Para mejorar la precisión en torno a estos acontecimientos, adoptamos un enfoque de modelización en cascada que amplía el GBM con un modelo lineal para gestionar el impacto de las vacaciones. Esta arquitectura del modelo mejora notablemente la precisión de las previsiones en días festivos.

Figura 1: Previsiones de demanda y oferta de apoyo a varios componentes de los sistemas de movilización proactiva de DoorDash

Limitaciones de los métodos Random Forest y Gradient Boosting

Los modelos basados en árboles, como random forest y gradient boosting, son populares en la industria por su facilidad de uso y su gran precisión. Para la previsión de series temporales en particular, estos modelos captan la estacionalidad de forma excelente con una codificación de características adecuada, gestionando las no linealidades y, lo que es más importante, evitando el sobreajuste. Sin embargo, estos puntos fuertes dificultan la gestión de anomalías y variaciones elevadas. En concreto, los modelos basados en árboles no consiguen captar la alta variación durante los días festivos, ni siquiera con la codificación de una sola vez, porque cada día festivo sólo aparece una vez al año. Véase un ejemplo simplificado en la Figura 2. 

La figura muestra cómo un árbol asigna diferentes observaciones del nodo raíz a sus nodos finales, u hojas, al intentar minimizar la función de pérdida y evitar el sobreajuste. Supongamos que nuestro conjunto de datos contiene observaciones de días festivos, representados por puntos de colores, en los que el volumen de pedidos disminuye en grandes cantidades; por ejemplo, un descenso del 50% el Día de Acción de Gracias en comparación con los días normales, que se muestran como puntos grises. Cuando entrenamos el modelo para minimizar la función de pérdida y evitar el sobreajuste simultáneamente, las observaciones extremas acabarán bajo el mismo nodo final. En este escenario, la predicción para un día festivo será una media simple de todos los días festivos en el nodo final (es decir, -35%), lo que genera un error significativo del -10% para la festividad del 4 de julio y del +15% para Acción de Gracias. En otras palabras, pronosticamos de más para el 4 de julio y Navidad, mientras que pronosticamos de menos para Acción de Gracias.  

Figura 2: El modelo basado en árboles no puede generar previsiones precisas para las vacaciones

Visión general del método de modelización en cascada

A lo largo de los años, los profesionales del aprendizaje automático han desarrollado arquitecturas y patrones de diseño, incluidos el reencuadre, el reequilibrio y los conjuntos multietiqueta para abordar las limitaciones de los modelos de ML. Un enfoque común es desplegar un patrón de diseño en cascada cuando el problema de ML subyacente puede dividirse en subproblemas de ML (como se ve en el libro Patrones de diseño de aprendizaje automático de Valliappa Lakshmanan, Sara Robinson y Michael Munn). Por ejemplo, cuando se trata de un problema de predicción con dos subgrupos diferentes, un profesional del ML podría construir dos modelos para clientes premium frente a clientes regulares en lugar de un único modelo para todos los clientes. Esperamos que la solución de dos modelos funcione mejor porque cada modelo está adaptado a su subgrupo respectivo.  

En nuestro caso, este planteamiento podría significar construir dos modelos distintos: uno para los días festivos y otro para los días normales. Sin embargo, esta solución no se ajusta a nuestro marco porque nuestro problema es la previsión de series temporales, que depende en gran medida de las observaciones históricas más recientes, como se ve en el gráfico 3. En otras palabras, si tuviéramos dos modelos distintos, el modelo para los días normales no podría generar previsiones para la semana después de Navidad porque no dispondría de la información de los rezagos más recientes. Para evitar que se pierda la información más reciente, aplicamos una versión aumentada de un patrón de diseño en cascada adaptado a la previsión de series temporales. Como se muestra en la Figura 3, en lugar de construir dos modelos, corregimos las series reales eliminando el impacto de las vacaciones para disponer de información histórica reciente al elaborar previsiones tras una festividad.  

Figura 3: Diseño en cascada para datos de series temporales con el objetivo de conservar las observaciones más recientes tras eliminar el impacto de las vacaciones

Previsión de la oferta y la demanda en cascada

Utilizamos el modelo GBM para generar previsiones de oferta y demanda para los puntos iniciales; sin embargo, experimentamos descensos significativos en la precisión durante las vacaciones. Como se observa en la figura 4, la precisión del modelo GBM, medida en términos de error porcentual absoluto medio ponderado (wMAPE), se deteriora en torno al día de Navidad.  

Figura 4: Rendimiento de GBM con ingeniería de rasgos tradicional en periodos vacacionales

Para mejorar la precisión, aplicamos el enfoque en cascada en varios pasos.

1. Cálculo de los multiplicadores de vacaciones: Realizamos una regresión lineal con variables ficticias de días festivos para cada par punto de partida-día-parte de nuestros datos y calculamos los multiplicadores de días festivos como los coeficientes de las variables ficticias de días festivos. Por ejemplo, podríamos tener un multiplicador de 1,5 para el Día de Acción de Gracias en Springfield (Illinois), lo que implica que el volumen de pedidos disminuirá un 50% entre semana para ese punto de partida en el par festivo-día-parte dado. Tenemos que ajustar miles de regresiones lineales al calcular el multiplicador de días festivos para cada par punto de partida-día-parte. Para mejorar la velocidad y la reutilización, hemos creado un marco independiente para este paso. En este marco, aprovechamos la computación paralela en Spark y almacenamos los multiplicadores de vacaciones en una tabla para que el modelo GBM los utilice en el paso de preprocesamiento.  

2. Preprocesamiento de los multiplicadores de vacaciones y entrenamiento del modelo: Preprocesamos la serie de entrada -por ejemplo, el número de pedidos- mediante los multiplicadores de días festivos para convertirla en cifras "libres de días festivos", lo que es similar a convertir los valores reales en corregidos en la Figura 3 anterior. Por ejemplo, si el número de pedidos del Día de Acción de Gracias en Springfield fue de 100 en 2022, el número de pedidos se convierte en 150, dado que el multiplicador es 1,5. Tras el preprocesamiento para obtener las cifras no festivas, entrenamos y almacenamos el modelo GBM.  

3. Generación de previsiones y posprocesamiento: En primer lugar, generamos previsiones para fechas futuras utilizando el modelo GBM entrenado. Como el modelo GBM se entrenó con datos no festivos, nuestras previsiones iniciales no tienen en cuenta los días festivos. Para obtener la previsión final de días festivos, utilizamos los multiplicadores de días festivos que se calcularon en el paso 1 para el postprocesamiento. Por ejemplo, si la previsión no festiva para el Día de Acción de Gracias es 150 y el multiplicador asociado es 1,5 para un punto de partida dado, la previsión final es 100 (=150/1,5).  

Figura 5: Aplicamos el modelo en cascada en varias etapas: [1] cálculo de multiplicadores, [2] preprocesamiento y entrenamiento, y [3] generación de previsiones y postprocesamiento.

Sistema de movilización

El sistema de movilización de DoorDash que se muestra en la Figura 1 es un esfuerzo de colaboración entre los equipos de operaciones, finanzas, ingeniería y aprendizaje automático. A medida que DoorDash crece, deseamos producir soluciones de ML e IA escalables que requieran intervenciones manuales mínimas por parte de los equipos de operaciones y finanzas. Sin embargo, la degradación del rendimiento de las previsiones navideñas nos obliga a realizar cambios ad hoc en la canalización de ML, lo que consume recursos informáticos adicionales y sobrecarga a los equipos de operaciones y ML. Para funcionar a la perfección, nuestro sistema de movilización necesita previsiones fiables para todos los días del año, incluidos los festivos. En este sentido, el diseño en cascada elimina otro obstáculo en el camino hacia un sistema de movilización totalmente automatizado. 

Estimación del impacto de las vacaciones en acción

DoorDash suele seguir dos pasos antes de poner en producción una nueva función o modelo:

• Dimensionamos la oportunidad y, si el movimiento en las métricas es lo suficientemente fuerte, lanzamos un experimento para asegurarnos de que los aspectos positivos superan a los negativos. 
• La decisión final se toma tras analizar los resultados experimentales; las partes interesadas de varios equipos deben estar de acuerdo en que la nueva función añade valor sin degradar las métricas empresariales. 

En la siguiente sección, repasaremos las mejoras en el rendimiento del modelo, cómo dimensionamos el impacto del estimador del impacto de las vacaciones en nuestros sistemas de producción, los problemas que encontramos con el experimento de medición de ese impacto y cómo finalmente superamos los retos y conseguimos la aceptación de las partes interesadas. 

Medición del rendimiento de los modelos

El enfoque en cascada para modelar el impacto de las vacaciones demuestra ser una mejora significativa con respecto a un simple enfoque de ingeniería de características. Como muestra la figura 6, wMAPE disminuyó de entre el 60% y el 70% a entre el 10% y el 20% en Navidad. Acción de Gracias tuvo un impacto similar. Promediando los días festivos de todo un año, observamos una mejora absoluta del wMAPE del 10%.

El modelo en cascada también obtuvo mejores resultados en los días posteriores a las vacaciones en comparación con los GBM con ingeniería de características simple, ya que el GBM simple traslada los cambios extremos durante las vacaciones a las semanas siguientes. El modelo en cascada genera predicciones a partir de un modelo GBM entrenado con datos sin vacaciones y sin movimientos extremos (véase el paso 2 de la figura 5).

Figura 6: El enfoque en cascada reduce el wMAPE en comparación con GBM con ingeniería de características tradicional

Medición del impacto empresarial

Aunque una clara mejora del rendimiento del modelo parece una decisión de despliegue directa sin necesidad de experimentación, hay algunas consideraciones tácticas importantes. Los datos de entrada pueden interactuar con los sistemas de formas inesperadas, dando lugar a resultados contradictorios. Tomemos, por ejemplo, un sistema de asignación de retribuciones diseñado para cubrir situaciones con una elevada varianza de las previsiones, es decir, si no somos capaces de prever bien la demanda debido a una elevada varianza subyacente, siempre añadimos retribuciones para compensar los fallos de previsión. Mejorar la precisión de las previsiones significaría reducir la varianza de las previsiones, lo que a su vez podría llevar al cese de la cobertura (paga adicional). En consecuencia, existe la posibilidad de que la experiencia del cliente se resienta debido a un suministro inadecuado. Esto subraya la necesidad esencial de realizar análisis para evaluar eficazmente los cambios propuestos e introducir modificaciones en el sistema si es necesario.

Las previsiones de oferta y demanda influyen directamente en lo que gastamos durante las fiestas para mantener la calidad del suministro, como ya hemos dicho. Hemos realizado pruebas retrospectivas para Acción de Gracias y Navidad con el fin de estimar los costes y las posibles repercusiones en la calidad. Nuestras pruebas retrospectivas mostraron que podríamos reducir el volumen perdido por mala calidad en un ~25% durante Acción de Gracias y Navidad. Nuestro próximo paso sería poner en marcha un experimento para consolidar estas estimaciones y conseguir que las partes interesadas se adhieran al nuevo modelo.

Las limitaciones de un experimento 

El principal reto que encontramos al intentar demostrar valor a través de un experimento fue la limitación en la potencia del experimento. La mayoría de los experimentos en DoorDash utilizan un diseño de experimento switchback basado en unidades geo-temporales para maximizar la potencia(aquí hay más información sobre switchbacks). En este caso, sin embargo, el uso de un switchback era inviable debido a la interferencia potencial a través de efectos de red. Por ejemplo, si nuestras previsiones de tratamiento llevan a una paga extra añadida a una determinada geografía más tarde en el día, los Dashers podrían elegir sólo Dash más tarde, o si nuestras previsiones añaden paga a un punto de partida vecino, los Dashers podrían migrar allí para ganar dinero extra. 

La única opción de diseño factible para eliminar estos efectos de red sería lanzar un mercado A/B en el que un mercado utilizara las previsiones de tratamiento mientras que otro utilizara el control. El diseño de mercado A/B reduce significativamente la potencia debido al pequeño tamaño de las muestras, lo que significa que tenemos que realizar este tipo de experimentos durante periodos de tiempo más largos. Dado el carácter intermitente de las vacaciones, la naturaleza de este experimento exigiría probablemente realizarlo durante al menos un año para obtener la potencia suficiente para medir el impacto, lo que no es factible. 

En consecuencia, tuvimos que replantear el objetivo de nuestro experimento. En lugar de medir con precisión el impacto del enfoque en cascada, decidimos centrarnos en garantizar que no empeorara la calidad. Si podíamos mantener las métricas estables sin que la calidad disminuyera en un conjunto de días festivos seleccionados, podríamos tomar la decisión de realizar el envío. 

Conseguir la participación de las partes interesadas

Por lo general, es más fácil convencer a los equipos financieros y operativos cuando podemos demostrar experimentalmente el valor sin degradar la calidad. Pero como hay pocos días festivos, lo que reduce la potencia de nuestro experimento, tuvimos que adoptar un enfoque diferente. Para tener un argumento sólido, realizamos pruebas retrospectivas en varios días festivos para obtener mejoras estimadas en las métricas de calidad. También utilizamos los resultados de un experimento A/B de mercado realizado el día de la Super Bowl, el Día de San Valentín y el Día del Presidente para demostrar que no había degradación del sistema. Esto ayudó a crear una comparación entre el mejor y el peor de los casos, lo que alivió la preocupación de que el nuevo enfoque pudiera empeorar la calidad y la experiencia de Dasher.

Consideraciones prácticas del enfoque en cascada

Aunque el modelo en cascada funciona mejor durante los días festivos y genera importantes mejoras de precisión, estas se producen a expensas de pasos adicionales, como la adición de nuevos modelos y canalizaciones, como el cálculo de multiplicadores de días festivos y la realización de preprocesamiento y postprocesamiento. Aunque el cálculo de los multiplicadores de vacaciones parece un paso adicional, nos ayudó a explicar las previsiones a nuestras partes interesadas, lo que generó más confianza en nuestros modelos y aceleró la transición a soluciones ML integrales con una intervención manual mínima. 

Los profesionales del ML deben evaluar los pros y los contras antes de decidirse a utilizar el patrón de diseño en cascada. Si el proceso añade una complejidad significativa a la arquitectura del modelo con ganancias limitadas en la pérdida de objetivos, puede que no merezca la pena el esfuerzo.   

Conclusión

Los modelos basados en árboles, como los bosques aleatorios y las máquinas de refuerzo de gradiente, se utilizan ampliamente en el espacio del ML para la previsión, la predicción y la clasificación. Aunque los modelos basados en árboles capturan bien las relaciones no lineales, no tienen en cuenta acontecimientos extremos como las vacaciones. La implementación de patrones de diseño en cascada para la previsión de series temporales durante periodos vacacionales en DoorDash ha generado mejoras significativas en los problemas de previsión. También debatimos las ventajas y dificultades inherentes al uso de un enfoque puramente experimental. Aunque los experimentos siguen siendo el patrón oro para medir el impacto, a veces necesitamos replantear nuestros objetivos o confiar en backtests para tomar decisiones oportunas sobre los envíos. 

Agradecimientos

Muchas gracias a Ryan Schork, Gisselle Xie, Michael Frasco y Tim Burke por sus comentarios sobre la ejecución de las ideas de este artículo. Muchas gracias a Ezra Berger por su continuo apoyo, revisión y edición de este artículo.