Las pruebas de retroceso para modelos de decisión permiten a los equipos de algoritmos comparar un modelo candidato con un modelo de referencia en un entorno de producción real, donde ambos modelos toman decisiones del mundo real para la operación. Con esta forma de prueba, los equipos pueden aleatorizar qué modelo se aplica a las unidades de tiempo y/o ubicación para mitigar los efectos de confusión (como días festivos, eventos importantes, etc.) que pueden afectar los resultados al realizar una prueba previa o posterior al lanzamiento.
Las pruebas de retroceso pueden tener varios nombres (por ejemplo, experimentos de división de tiempo) y, a menudo, se las denomina pruebas A/B. Si bien esta es una comparación útil a modo de orientación, es importante reconocer que las pruebas de retroceso y A/B son similares, pero no iguales. Los modelos de decisión no se pueden probar A/B de la misma manera que las páginas web debido a los efectos de la red. Las pruebas de retroceso le permiten tener en cuenta estos efectos de red, mientras que las pruebas A/B no.
Por ejemplo, cuando realiza una prueba A/B de una página web ofreciendo contenido diferente a los usuarios, la experiencia que tiene un usuario con la página A no afecta la experiencia que tiene otro usuario con la página B. Sin embargo, si intenta realizar una prueba A/B de entrega asignaciones a conductores: simplemente no se puede. No se puede asignar el mismo orden a dos conductores diferentes como prueba de comparación. No existe una manera de aislar el tratamiento y el control en una sola unidad de tiempo o ubicación utilizando las pruebas A/B tradicionales. Ahí es donde entran las pruebas de retroceso.
Exploremos un poco más este tipo de pruebas.
Imagine que trabaja en una empresa agrícola compartida que entrega productos frescos (zanahorias, cebollas, remolachas, manzanas) y productos lácteos (queso, helado, leche) desde las granjas locales hasta los hogares de los clientes. Su empresa invirtió recientemente en mejorar toda la flota de vehículos para que esté lista para la cadena de frío. Dado que todos los vehículos son capaces de manejar artículos sensibles a la temperatura, la empresa está lista para eliminar la lógica empresarial que era relevante para la flota híbrida anterior.
Antes de la actualización de la flota, su granja compartida manejaba artículos sensibles a la temperatura como último en entrar, primero en salir (LIFO). Esto significaba que si se recogía un artículo frío, como un helado, el conductor tenía que dejarlo inmediatamente para evitar un triste desastre derretido. Esta lógica LIFO ayudó con la integridad del producto y la satisfacción del cliente, pero también introdujo ineficiencias en los cambios de ruta y el retroceso.
Después de la actualización de la flota, el equipo quiere eliminar esta limitación, ya que todos los vehículos son capaces de transportar artículos fríos durante más tiempo con refrigeración. Pruebas anteriores utilizando entradas históricas, como experimentos por lotes (pruebas ad hoc utilizadas para comparar uno o más modelos con entradas históricas o fuera de línea [1]) y prueba de aceptacion (pruebas con métricas de pasa/falla predefinidas utilizadas para comparar el modelo actual con un modelo candidato con entradas históricas o fuera de línea antes de “aceptar” el nuevo modelo [2]), han indicado que el tiempo del vehículo en carretera y las paradas no asignadas disminuyen para el modelo candidato en comparación con el modelo de producción que tiene la restricción LIFO. Has ejecutado un prueba de sombra (una prueba en línea en la que uno o más modelos candidatos se ejecuta en paralelo al modelo actual en producción pero “en las sombras”, sin afectar las decisiones [3]) para garantizar la estabilidad del modelo en condiciones de producción. Ahora desea dejar que su modelo candidato pruebe a tomar decisiones para sus sistemas de producción y comparar los resultados con su modelo de producción.
Para esta prueba, decide realizar una aleatorización según el tiempo (cada 1 hora) en dos ciudades: Denver y Nueva York. A continuación se muestra un ejemplo de las unidades experimentales de una ciudad y qué tratamiento se les aplicó.
Después de 4 semanas de pruebas, descubre que su modelo candidato supera al modelo de producción al tener constantemente menos tiempo en la carretera, menos paradas no asignadas y conductores más felices porque no zigzagueaban por la ciudad para adaptarse a la restricción LIFO. Con estos resultados, trabaja con el equipo para implementar completamente el nuevo modelo (sin la restricción LIFO) en ambas regiones.
Las pruebas de retroceso generan comprensión y confianza en los impactos conductuales de los cambios de modelo cuando hay efectos de red en juego. Debido a que utilizan datos en línea y condiciones de producción de una manera estadísticamente sólida, las pruebas de retroceso brindan información sobre cómo la toma de decisiones de un nuevo modelo impacta el mundo real de manera mesurada en lugar de simplemente “enviarlo” al por mayor para estimular y esperar lo mejor. La prueba de retroceso es la forma más sólida de prueba para comprender cómo funcionará un modelo candidato en el mundo real.
Este tipo de comprensión es algo que no se puede obtener con las pruebas paralelas. Por ejemplo, si ejecuta un modelo candidato que cambia una función objetivo en modo sombra, todos sus KPI pueden verse bien. Pero si ejecuta ese mismo modelo como una prueba de retroceso, es posible que vea que los repartidores rechazan pedidos a un ritmo mayor en comparación con el modelo de referencia. Simplemente hay comportamientos y resultados que no siempre se pueden anticipar sin ejecutar un modelo candidato en producción de una manera que le permita observar el modelo tomando decisiones operativas.
Además, las pruebas de retroceso son especialmente relevantes para los problemas de oferta y demanda en el espacio de enrutamiento, como la entrega y el despacho de última milla. Como se describió anteriormente, las técnicas de prueba A/B estándar simplemente no son apropiadas en estas condiciones debido a los efectos de red que no pueden tener en cuenta.
Hay una cita del Principios de la ingeniería del caos“Chaos prefiere experimentar directamente en el tráfico de producción” [4]. Las pruebas de retroceso (y las pruebas de sombra) están diseñadas para enfrentar este tipo de caos. Como se mencionó en la sección anterior: llega un momento en el que llega el momento de ver cómo un modelo candidato toma decisiones que impactan las operaciones del mundo real. Ahí es cuando necesitas pruebas de retroceso.
Dicho esto, no tiene sentido que la primera ronda de pruebas en un modelo candidato sean pruebas en zigzag. Querrá ejecutar una serie de pruebas históricas, como pruebas de lotes, escenarios y de aceptación, y luego pasar a las pruebas paralelas de los datos de producción. Las pruebas de retroceso suelen ser el último paso antes de comprometerse a implementar completamente un modelo candidato en lugar de un modelo de producción existente.
Para realizar pruebas de retroceso, los equipos suelen crear la infraestructura, el marco de aleatorización y las herramientas de análisis desde cero. Si bien los beneficios de las pruebas de retroceso son excelentes, el costo de implementarlas y mantenerlas puede ser alto y, a menudo, requiere una participación dedicada en la ciencia y la ingeniería de datos. Como resultado, este tipo de pruebas no es tan común en el espacio de la ciencia de la decisión.
Una vez que la infraestructura está en su lugar y las pruebas de retroceso están activas, se convierte en un ejercicio de análisis de datos para entrelazar la información para comprender qué tratamiento se aplicó en qué momento y conciliar todos esos datos para realizar un análisis más formal de los resultados.
Algunos buenos puntos de referencia en los que profundizar incluyen publicaciones de blog sobre el tema de DoorDash como este (escriben bastante sobre eso) [5]Además de esto Hacia el puesto de ciencia de datos de un ingeniero de soluciones de Databricks [6]que hace referencia a un artículo de investigación útil de MIT y Harvard [7] eso también vale la pena leerlo.
Las pruebas de retroceso para modelos de decisión son similares a las pruebas A/B, pero permiten a los equipos tener en cuenta los efectos de la red. Las pruebas de retroceso son una pieza fundamental del flujo de trabajo de DecisionOps porque ejecuta un modelo candidato utilizando datos de producción con efectos del mundo real. Seguimos construyendo el experiencia de prueba en Nextmv — y nos gustaría tu aportación.
Si está interesado en obtener más contenido sobre pruebas de modelos de decisión y otros temas de DecisionOps, suscríbase a el blog de Nextmv.
El autor Trabaja para Nextmv como Jefe de Producto.
[1] R. Gough, ¿Qué son los experimentos por lotes para modelos de optimización? (2023), Siguientemv
[2] T. Bogich, ¿Qué sigue para las pruebas de aceptación? (2023), Siguientemv
[3] T. Bogich, ¿Qué son las pruebas paralelas para modelos de optimización y algoritmos de decisión? (2023), Siguientemv
[4] Principios de la ingeniería del caos (2019), Principios del caos
[5] C. Sneider, Y. Tang, Rigor del experimento para el análisis del experimento Switchback (2019), Ingeniería DoorDash
[6] Sr. Berk, Cómo optimizar la configuración de la prueba Switchback A/B (2021), Hacia la ciencia de datos
[7] I. Bojinov, D. Simchi-Levi, J. Zhao, Diseño y análisis de experimentos de retroceso. (2020), arXiv