When Reproducible Revenue-Management Simulations Are Still Invalid: Evidence From a Continuation-Value Policy Audit

Imagina un mundo donde cada asiento en un avión es una fruta perecedera. Una vez que el avión despega, cualquier asiento no vendido desaparece para siempre, pudriéndose en el aire. Las aerolíneas enfrentan un rompecabezas constante y de alto riesgo: ¿deberían vender un boleto ahora a un precio más bajo para un viajero de bajo presupuesto, o mantener ese asiento vacío con la esperanza de que un viajero de negocios pague el doble de precio más tarde? Este es el núcleo de la gestión de ingresos de las aerolíneas. Para resolverlo, las aerolíneas utilizan programas informáticos que intentan predecir el valor futuro de un asiento vacío. Estos programas ejecutan miles de simulaciones, creando pasajeros falsos y demanda falsa para probar qué estrategia genera más dinero. Si un nuevo programa informático afirma ganar significativamente más que el anterior, una aerolínea podría gastar millones en comprarlo. Pero, ¿qué pasaría si la prueba misma estuviera amañada, no por malicia, sino por un error sutil en la forma en que la computadora generó su mundo falso?

Un estudio reciente del investigador Zhaorui Zhu investiga precisamente este peligro. El artículo examina un experimento específico donde se comparó una nueva estrategia de precios contra un método estándar y bien conocido llamado EMSR-b. La nueva estrategia utilizaba un "valor de continuación", un término sofisticado para una suposición sobre cuánto valdría un asiento vacío más tarde en el vuelo. El estudio original afirmaba que el nuevo método era casi tan bueno como el estándar y, en algunos aspectos, muy prometedor. Sin embargo, el equipo de Zhu decidió auditar el experimento desde cero, no para ver si el código podía ejecutarse de nuevo, sino para ver si la comparación era realmente justa. Encontraron que, si bien la computadora podía recrear perfectamente los números originales, la lógica detrás de esos números era defectuosa en cuatro formas distintas.

El primer gran problema fue un asunto de tiempo y azar. En el experimento original, la computadora generaba un flujo de eventos aleatorios —como cuándo podría aparecer un pasajero o cuánto podrían pagar—. Ejecutó la primera estrategia, luego la segunda, luego la tercera, utilizando el mismo flujo de números para todas ellas. Pero debido a que las estrategias se ejecutaban una tras otra, no enfrentaron la misma secuencia de eventos. Era como correr una carrera donde el primer corredor recibe un viento a favor, el segundo un viento en contra y el tercero una brisa calma, simplemente porque el viento cambió mientras corrían. Cuando los investigadores reevaluaron los resultados utilizando un método estricto que aseguraba que cada estrategia enfrentara exactamente la misma secuencia de eventos aleatorios al mismo tiempo, los resultados cambiaron. La nueva estrategia, que había parecido competitiva, de repente se quedó atrás del método estándar por casi un dieciséis por ciento. La ventaja aparente del nuevo enfoque había sido una ilusión creada por un mal manejo del tiempo.

El segundo problema involucró cómo la computadora miraba hacia el futuro. La nueva estrategia intentaba estimar el valor de un asiento mirando hacia adelante a la demanda esperada. Sin embargo, el código estaba evaluando este valor futuro en el momento equivco. En lugar de calcular cuánto valdría el asiento después de que se tomara una decisión y un pasajero potencialmente abordara, calculaba el valor basándose en el estado actual antes de que se tomara cualquier acción. Esto significaba que la parte del "valor futuro" en el cálculo era esencialmente un número constante que no cambiaba según la decisión específica que se estuviera tomando. Era como un conductor intentando navegar mirando un mapa que mostraba el mismo destino sin importar qué giro tomara. Debido a que este término no influía realmente en el proceso de toma de decisiones, la estrategia no estaba utilizando realmente la información futura que pretendía usar.

El tercer fallo fue un truco estadístico que ocultó un error masivo. Cuando los investigadores observaron qué tan bien coincidían las predicciones de la computadora con la realidad, incluyeron muchos escenarios en los que el avión ya estaba lleno. En estos casos, el valor de un asiento extra es cero, por lo que el error es cero. Al contar estos asientos vacíos en el promedio, la computadora hizo que su precisión de predicción pareciera mucho mejor de lo que realmente era. Cuando los investigadores eliminaron estos casos de "valor cero" y observaron solo los momentos en que una decisión realmente importaba, la tasa de error era mucho mayor. El modelo subestimaba constantemente el valor de los asientos cuando más importaba, un fallo que el informe original había enmascarado al incluir los casos fáciles de asientos vacíos.

El hallazgo más dañino provino de una prueba de generalización, que es la capacidad de aplicar una lección aprendida en una situación a una completamente nueva. El estudio original entrenó su modelo computacional con un conjunto de escenarios de vuelo específicos y luego lo probó en un conjunto ligeramente diferente de los mismos escenarios. Funcionó bien. Pero el equipo de Zhu cambió la prueba por completo: entrenaron el modelo en un grupo de vuelos y luego lo probaron en un grupo de vuelos completamente diferente que el modelo nunca había visto. El resultado fue un colapso total. Las predicciones del modelo se volvieron peores que simplemente adivinar el promedio. No había aprendido ninguna regla real sobre cómo funciona la demanda; solo había memorizado los patrones específicos de los vuelos de entrenamiento. Incluso cuando los investigadores intentaron usar este modelo roto para tomar decisiones de precios, este seguía siendo peor que el método estándar, perdiendo aproximadamente un tres por ciento de los ingresos potenciales.

El estudio concluye que un programa informático puede producir números idénticos y reproducibles y, aun así, ser completamente inválido. El experimento original era mecánicamente reproducible —el código corría y daba las mismas respuestas—, pero la comparación era científicamente poco sólida. La nueva estrategia no venció a la anterior; de hecho, fue significativamente peor una vez que el azar se alineó correctamente. Los investigadores argumentan que esto no es solo un problema con una pieza de código, sino una advertencia para toda la industria. Cuando las aerolíneas o los proveedores de software presentan resultados de simulación para demostrar que un nuevo sistema funciona, deben asegurar que cada estrategia enfrente exactamente los mismos eventos aleatorios, que las predicciones futuras se calculen en el momento correcto y que el sistema se pruebe en escenarios completamente nuevos y no vistos anteriormente.

Para prevenir este tipo de errores, el artículo propone una lista de verificación de diez pasos para cualquiera que evalúe estos sistemas. Este protocolo exige que los investigadores congelen los eventos aleatorios para que sean idénticos en todas las pruebas, verifiquen que el código realmente esté tomando decisiones basadas en la información correcta y reporten resultados en conjuntos de datos completamente nuevos en lugar de solo re-probar los antiguos. Sugiere que, antes de que una aerolínea gaste dinero en un nuevo motor de precios, debe exigir ver el código fuente, los datos sin alterar y la prueba de que el sistema funciona en vuelos que nunca ha visto. El objetivo es ir más allá de simplemente comprobar si una computadora puede repetir un resultado, para asegurar que el resultado realmente dice la verdad sobre cómo se desempeñará el sistema en el mundo real. En el juego de alto riesgo de los ingresos de las aerolíneas, donde cada asiento no vendido se pierde para siempre, la diferencia entre una buena simulación y una mala no es solo un número; es la diferencia entre la ganancia y la pérdida.