Forecast Congruencia y toma de decisiones en supply chain (con Nikolaos Kourentzes) - Ep 161

00:00:00 Introducción de la entrevista
00:00:47 Antecedentes y trabajo de Nikos Kourentzes
00:03:25 Comprendiendo la congruencia de forecast
00:04:44 Limitaciones de la precisión en forecast
00:06:14 Congruencia en forecasts de series de tiempo
00:08:02 Consideraciones del modelado de inventario en supply chain
00:09:03 Congruencia y consistencia de forecast
00:10:29 Métricas matemáticas en producción
00:12:08 Consideraciones de inventario para relojero de lujo
00:14:47 Fluctuación ascendente que desencadena la producción
00:16:03 Optimizando el modelo para la demanda de un SKU
00:17:41 Investigación en estimadores de shrinkage y jerarquías temporales
00:19:05 Mejores modelos para todos los horizontes
00:21:32 Controversia en torno a la congruencia de forecast
00:24:05 Calibrando políticas de inventario
00:26:27 Equilibrando precisión y congruencia
00:31:14 Trucos de la agregación temporal que suavizan los forecasts
00:32:54 Importancia de los gradientes en la optimización
00:35:28 Correlaciones en supply chain
00:38:10 Más allá del forecast de series de tiempo
00:40:27 Honestidad del forecast probabilístico
00:42:32 Similitudes entre congruencia y la ratio bullwhip
00:45:18 Importancia del análisis de la toma de decisiones secuencial
00:47:27 Beneficios de mantener las etapas separadas
00:49:34 Interacción humana con los modelos
00:52:05 Mantener el elemento humano en forecast
00:54:35 Confianza en expertos y analistas
00:57:28 Situación realista de gestionar millones de SKUs
01:00:01 Ajustes de modelo a nivel alto
01:02:13 Decisiones guiadas por la probabilidad de eventos raros
01:04:44 La opinión de Nikos sobre los ajustes
01:07:14 Perdiendo tiempo en ajustes menores
01:09:08 En contra de ajustes manuales diarios
01:11:43 Beneficios a nivel de empresa de ajustar el código
01:13:33 Papel del equipo de data science
01:15:35 Los forecasts probabilísticos disuaden la interferencia manual
01:18:12 La pregunta de un millón de dólares sobre la IA
01:21:11 Importancia de entender los modelos de IA
01:24:35 Valor y costo de los modelos de IA
01:26:02 Abordando problemas en el inventario

Acerca del invitado

Nikolaos Kourentzes es profesor en analítica predictiva e IA en el Lab de IA de la Universidad de Skövde en Suecia. Sus intereses de investigación se centran en el forecast de series de tiempo, con trabajos recientes en el modelado de la incertidumbre, jerarquías temporales y modelos jerárquicos de forecast. Su investigación se enfoca en traducir los forecasts en decisiones y acciones, en áreas tales como gestión de inventario, modelado de liquidez para operaciones monetarias y salud. Tiene amplia experiencia trabajando tanto en la industria como en el sector público y es autor de varias bibliotecas open-source para facilitar el uso de avanzados métodos de forecast en la práctica.

Resumen

En una reciente entrevista en LokadTV, Nikos Kourentzes, profesor en la Universidad de Skövde, y Joannes Vermorel, CEO de Lokad, discutieron la congruencia de forecast en el toma de decisiones en supply chain. Enfatizaron la importancia de alinear los forecasts con las decisiones, reconociendo que los modelos pueden estar mal especificados. Distinguiron entre la precisión de forecast y la congruencia, argumentando que el forecast más preciso puede no ser el mejor para la toma de decisiones si no se alinea con el objetivo de la decisión. También discutieron la aplicación práctica de la congruencia de forecast en la toma de decisiones de inventario y su potencial para mitigar el efecto látigo. También se discutió el rol de la IA y la participación humana en la congruencia de forecast.

Resumen Extendido

En una reciente entrevista presentada por Conor Doherty, Jefe de Comunicación en Lokad, Nikos Kourentzes, profesor en la Universidad de Skövde, y Joannes Vermorel, CEO y fundador de Lokad, discutieron el concepto de congruencia de forecast en el contexto de la toma de decisiones en supply chain.

Kourentzes, quien dirige un equipo enfocado en la investigación de IA en la Universidad de Skövde, explicó que su trabajo gira principalmente en torno al riesgo del modelo y a la especificación del mismo. Enfatizó la importancia de alinear los forecasts con las decisiones que respaldan, un concepto al que se refiere como la congruencia de forecast. Este enfoque tiene como objetivo mejorar la precisión reconociendo que los modelos pueden estar mal especificados.

Kourentzes distinguió además entre la precisión de forecast y la congruencia de forecast. Mientras que la precisión es una medida de la magnitud de los errores de forecast, la congruencia describe la consistencia de los forecasts a lo largo del tiempo. Argumentó que el forecast más preciso puede no ser necesariamente el mejor para la toma de decisiones si no se alinea con la función objetivo de la decisión.

Vermorel, en acuerdo con Kourentzes, señaló que las métricas matemáticas a menudo se quedan cortas cuando se ponen en práctica. Dio ejemplos de cómo diferentes decisiones pueden tener diversos costos asimétricos, como la venta de productos perecederos frente a artículos de lujo. Vermorel también discutió el efecto de trinquete en la gestión de supply chain, donde las fluctuaciones en los forecasts de demanda pueden llevar a decisiones irreversibles.

Kourentzes compartió su cambio de centrarse únicamente en la precisión a considerar otros factores en forecast. Enfatizó la importancia de comprender el funcionamiento subyacente de los modelos y las suposiciones en las que se basan. Sugerió que, una vez que se encuentra una colección de forecasts precisos, se debe elegir el que sea más congruente.

Vermorel, por otro lado, compartió que en Lokad optimizan directamente los resultados financieros, en lugar de enfocarse en métricas matemáticas. Explicó que los gradientes son cruciales para la optimización, ya que proporcionan la dirección en la que se deben ajustar los parámetros para minimizar los errores. También discutió la importancia de los forecasts probabilísticos, que consideran todos los futuros posibles, no solo para la demanda, sino también para diferentes tiempos de entrega e incertidumbres.

Luego, la discusión se trasladó a la aplicación práctica de la congruencia de forecast en la toma de decisiones de inventario y su potencial para mitigar el efecto látigo. Kourentzes explicó que la congruencia y la ratio bullwhip tienen muchas similitudes, y que diseñar forecasts con la congruencia en mente puede ayudar a reducir el efecto látigo.

También se discutió el rol de la participación humana en la congruencia de forecast. Kourentzes cree que la intervención humana no debe ser eliminada, sino guiada para agregar valor donde pueda. Vermorel, sin embargo, compartió que en Lokad ya no se permite el ajuste de forecast por parte de humanos, ya que conducía a mejores resultados.

La conversación concluyó con una discusión sobre el rol de la IA en la congruencia de forecast y la toma de decisiones en supply chain. Tanto Kourentzes como Vermorel estuvieron de acuerdo en que, si bien la IA tiene un rol en abordar los desafíos de forecast, no debe reemplazar todos los métodos existentes y es crucial comprender el proceso.

En sus comentarios finales, Kourentzes llamó a un cambio alejándose de los métodos tradicionales de forecast y hacia un enfoque más integrado con la toma de decisiones. Enfatizó la necesidad de actualizar nuestra forma de pensar, el software y los libros de texto, y dio la bienvenida a la inclusión de personas de diversos campos en el área de forecast. Concluyó subrayando la importancia de la colaboración y las perspectivas diversas para abordar estos desafíos.

Transcripción Completa

Conor Doherty: Bienvenidos de nuevo. Típicamente, las discusiones sobre forecast se centran en la idea de precisión. El invitado de hoy, Nikos Kourentzes, tiene una perspectiva diferente. Es profesor en el Laboratorio de Inteligencia Artificial de la Universidad de Skövde. Hoy, hablará con Joannes Vermorel y conmigo sobre el concepto de congruencia de forecast. Ahora, Nikos, ¿puedes confirmar en cámara que pronuncié Skövde correctamente?

Nikos Kourentzes: Eso es lo mejor que puedo hacer.

Conor Doherty: Bueno, entonces no tengo más preguntas. Muchas gracias por acompañarnos.

Nikos Kourentzes: Es un placer.

Conor Doherty: En serio, trabajo en la Universidad de Skövde, en el Laboratorio de Inteligencia Artificial. Suena muy impresionante. ¿A qué te dedicas exactamente y cuál es tu trayectoria en general?

Nikos Kourentzes: Bien, permíteme primero presentar un poco sobre el laboratorio y luego hablaré un poco de mi trayectoria. Somos un equipo diverso de académicos interesados en la investigación de IA. El enfoque está principalmente en data science, pero el ámbito de aplicación es bastante diverso. Por ejemplo, como ya mencionaste, probablemente estaré hablando sobre forecast y modelado de series de tiempo. Pero, por ejemplo, otros colegas están interesados en temas como fusión de información, analítica visual, coches autónomos y aspectos cognitivos de la IA. Eso es lo grandioso del equipo, porque tenemos una polifonía de investigaciones y, ya sabes, cuando se tienen las discusiones, surgen muchas ideas diversas que van más allá de la literatura típica. Al menos, me parece un espacio muy agradable para estar. La universidad es, ya sabes, lo que usualmente comento a mis colegas: al no ser sueco yo mismo, cuando se usan nombres suecos internacionalmente, pueden ser de cualquier tipo. Así que, probablemente sería útil decir que la universidad, en términos de data science e IA, tiene bastante tradición, aunque su nombre no sea ampliamente conocido. Pero, ya sabes, estoy muy contento de haberme unido al equipo. En cuanto a mí, he estado trabajando en forecast y modelado de series de tiempo, ya sea con estadísticas, econometría o IA, durante más o menos 20 años. Hice mi doctorado en la Universidad de Lancaster en inteligencia artificial. Eso fue en la escuela de negocios. Y mi formación originalmente es en gestión. Pero en algún momento, dije: “está bien, eso es bastante bueno. Sé qué preguntas hacer, pero no sé cómo resolverlas”. Entonces, me dediqué a trabajar en investigación operativa, de ahí mis intereses en supply chain, y eventualmente realicé mi doctorado en inteligencia artificial. Posteriormente, me interesé más en econometría. Así, logré diversificarme un poco en la comprensión de las series de tiempo. Conor Doherty: Gracias, Nikos. Y en realidad, la primera vez que Joannes y yo nos topamos con tu perfil –o al menos la forma en que yo lo descubrí– fue cuando un Supply Chain Scientist, que sigue parte de tu trabajo en LinkedIn, me envió un artículo en el que habías escrito sobre la congruencia de forecast e incluías un enlace a tu documento de trabajo sobre el tema. El eje de la conversación de hoy girará en torno a forecast y su aplicación en supply chain. Pero antes de entrar en detalles, ¿podrías darnos un poco de contexto sobre qué es la congruencia de forecast y cómo surgió como área de investigación para ti?

Nikos Kourentzes: Una gran parte de mi trabajo ha girado en torno al riesgo del modelo y a la especificación del mismo. A menudo, en el forecast de series de tiempo, identificamos un modelo y decimos, “está bien, vamos a utilizarlo”. Pero realmente no reconocemos que cada modelo estará equivocado en ciertos aspectos. Quiero decir, es el mantra habitual en forecast: siempre escuchamos, “todos los modelos están equivocados, algunos son útiles”. Pero creo que podemos ir más allá de eso, porque podemos empezar a cuantificar cuán equivocados están los modelos. Además, en la literatura a menudo no se va tan lejos, y esto está cambiando; debo decir que esto está cambiando, no soy el único en decirlo, hay muchos colegas que sostienen que debemos conectar el forecast con la decisión que se está apoyando.

Así que la congruencia surgió de estas dos ideas. He trabajado con mi colega de la Universidad de Lancaster, Kandrika Pritularga, quien también es coautor en el artículo que mencionaste. Y estábamos bastante interesados en decir, “está bien, si ambos partimos del punto de vista de que los modelos están, en cierto sentido, mal especificados –es decir, que simplemente estamos aproximando la demanda que enfrentamos o las ventas, según se interprete–, ¿cuál es entonces el costo real de eso?” Y la congruencia de forecast esencialmente lleva a la idea de decir, ¿podemos hacer algo mejor que la precisión? Porque la precisión, en muchos sentidos, asume que estás haciendo un buen trabajo en la aproximación de tus datos.

Y ya sabes, sí, estamos intentando hacerlo con toda seriedad, pero puede que simplemente no estemos utilizando el modelo adecuado. Por ejemplo, puedes tener un software que te ofrece una selección de X modelos, pero la aproximación correcta sería un modelo que falta en tu conjunto de modelos. Ahí es donde todo esto se presenta como una motivación: intentar conectar el forecast con una decisión una vez que reconocemos que probablemente nuestros modelos estarán mal especificados. So that’s a bit the background.

Si quiero ser más científico al respecto, una cosa que debo decir es que, generalmente, con mis colegas, siempre iniciamos nuestros temas de investigación con una idea un poco más tonta. Así que, ya sabes, estamos haciendo otra cosa y decimos, oh, aquí hay un gancho interesante, vamos a explorarlo un poco más. Y a menudo, una vez que haces eso, terminas teniendo algo que puede ser una idea útil. La razón por la que menciono esto es porque pienso que la congruencia del forecast, lo que ofrece en la mesa, es un tipo de pensamiento algo diferente. Y por eso creo que es originalmente agradable, ya que al empezar como una broma, en cierto sentido, nos permitió ver todo el asunto desde una perspectiva distinta.

Conor Doherty: Joannes, llegaré a eso en un momento, pero ¿podrías ampliar un poco más? Una vez más, cuando dices precisión del forecast, todo el mundo tiene una idea más o menos de lo que eso significa. Pero cuando dices congruencia o congruencia del forecast que ayuda a la gente a ver las cosas desde una perspectiva diferente, ¿podrías explicar un poco más esa distinción para que la gente entienda exactamente a qué te refieres con congruencia en el contexto de los forecast de series temporales?

Nikos Kourentzes: Primero que nada, el nombre no es el más directo y hay una razón para ello. Lo que intentamos describir con esa congruencia del forecast es, esencialmente, cuán similares son los forecast a lo largo del tiempo. Ahora, esta es una forma más sencilla de decirlo, pero aquí hay algunos problemas. Muchas de las palabras que uno podría usar para ello, por ejemplo, estabilidad, ya se utilizan en el forecasting estadístico, por lo que no queremos causar confusión allí.

Y el otro problema es que, como probablemente se desarrollará un poco más adelante en la discusión, existen dificultades técnicas para medir cuán similares son los forecast a lo largo del tiempo. Porque, por ejemplo, si piensas en una serie temporal estacional y una serie temporal no estacional, implican algo muy diferente, ya que la estacionalidad impondría por sí sola una variación en el forecast a lo largo del tiempo. Ese es el patrón que hay que gestionar. Así que ese no es el tipo de disimilitud que nos interesa. Y es eso lo que implica, si se quiere, un poco de gimnasia matemática para definir la congruencia. Pero aquí radica la diferencia con la precisión. Precisión, normalmente la entendemos, independientemente de la métrica que vayas a usar, como un resumen de la magnitud de tus errores de forecast.

Ahora, asumiríamos, por supuesto, que si obtenemos el forecast más preciso, eso implicaría que proporcionamos la mejor información para las decisiones apoyadas. Sin embargo, eso implica que las decisiones apoyadas tienen el mismo tipo de función objetivo que el forecast más preciso, digamos, minimizar tus errores al cuadrado. Pero ese no es el caso. Quiero decir, si piensas en un modelado de inventario de supply chain, puede que tengamos que considerar costos debido a la agrupación de pedidos, puede que tengamos que pensar en costos de exceso y de faltante que puedan cambiar tu posición respecto al forecast más preciso. Puede que tengamos que considerar otros aspectos, como por ejemplo restricciones provenientes de nuestros proveedores u otras limitaciones de capacidad de las líneas de producción o de nuestro almacenamiento, y así sucesivamente. Así que, una vez que piensas en el verdadero coste de inventario o en la supply chain de forma más general, de repente ves que el forecast más preciso no es necesariamente el que está mejor alineado con la decisión. Y ese es, realmente, el punto más interesante acerca de la congruencia.

Entonces, por un lado, existe una línea de investigación, y mis coautores y yo hemos publicado bastante en esa dirección, evidenciando que la mayoría de las métricas de precisión no se correlacionan bien con buenas decisiones. Eso no significa que sean inútiles o algo por el estilo, es simplemente que no cuentan toda la historia. Así que eso impulsa un poco hacia la congruencia. La congruencia, por otro lado, intenta decir que si los forecast no cambian demasiado con el tiempo, entonces probablemente haya cierta confianza, por un lado, en los forecast. Pero, por otro, también habrá un forecast sobre el cual la gente puede planificar con cierta consistencia. No tengo que actualizar toda mi planificación en cada ciclo de forecast porque el forecast será bastante similar. Así que, incluso si no son los forecast más precisos, están fallando de una manera predecible que podría facilitar la toma de decisiones. Y eso es, de hecho, lo que encontramos en nuestro trabajo también. Encontramos que las decisiones que se apoyan en forecast más congruentes son decisiones que también son más consistentes a lo largo del tiempo. Por lo tanto, se requiere menos esfuerzo para tomar esas decisiones.

Conor Doherty: Bueno, gracias, Nikos. Y Joannes, ahora te cedo la palabra. Siento que parte de eso probablemente resuena bastante contigo. Los forecast más precisos no se traducen necesariamente en una mejor toma de decisiones de inventario.

Joannes Vermorel: Sí, quiero decir, exactamente. Nuestra perspectiva general hoy en día es que, de hecho, prácticamente todas las métricas matemáticas, en el sentido de que eliges una fórmula y dices que esta es la fórmula matemática que caracteriza tu métrica que intentas optimizar, cuando esta fórmula básicamente cae del cielo o simplemente se inventa, incluso si viene con buenas intenciones, digamos la norma uno, norma dos, algo que tiene algunas propiedades matemáticas asociadas, suele resultar muy decepcionante una vez puesta en producción por una variedad de razones.

Hace más de una década, Lokad comenzó a evangelizar la idea de que la gente no debería estar haciendo lo que ahora llamamos naked forecasts. Fundamentalmente, apoyo a Nikos en su proposición de que un forecast es un instrumento para una decisión y que solo se puede evaluar la validez del forecast a través del lente de la validez de las decisiones.

Y eso es algo extraño, porque si tienes 10 decisiones diferentes, podrías terminar con forecast inconsistentes para apoyar esas decisiones. Y se siente bizarro, pero la realidad es que está bien, incluso si es contraintuitivo. ¿Y por qué está bien? Pues, porque tienes un conjunto de decisiones que pueden tener costos asimétricos muy diversos en términos de sobreestimación o subestimación.

Y así, si tienes una decisión en la que, si sobreestimas, es una catástrofe. Digamos, por ejemplo, que estás vendiendo fresas. Así que, con las fresas, lo que no vendas al final del día, prácticamente lo echas a perder. Entonces, todo lo que sobreestimes es catastrófico en el sentido de que es una pérdida inmediata garantizada o una baja de inventario.

Por el contrario, si eres un fabricante de relojes de lujo y tus artículos están hechos de oro, platino y otros metales y piedras elegantes, si no los vendes, el stock no caduca. Incluso si lo que forjas e incorporas en los artículos pasa de moda, siempre puedes recuperar los materiales y remodelar algo que esté más en sintonía con el deseo actual del mercado.

Así que, fundamentalmente, si te dedicas a la joyería, nunca tienes bajas de inventario. Puede que tengas algún costo para remodelar tus productos, pero es un juego muy, muy diferente.

Uno de los problemas básicos que casi nunca se menciona en los libros de texto de supply chain es simplemente el efecto de trinquete. Digamos que estás en un juego de reabastecimiento de existencias. Cada día tienes un SKU, tienes un forecast de demanda y, si la demanda supera cierto umbral, emites un reorden.

Pero resulta que, si tu forecast está un tanto fluctuante, significa que tu inventario siempre se establece, capturando el punto más alto de tu fluctuación. Quiero decir, considerando, ya sabes, un mes, por ejemplo, si tu ciclo típico de reorden es de aproximadamente un mes, entonces tu forecast fluctúa durante ese mes. Y digamos que cada día, es decir, 30, 31 días del mes, simplemente vuelves a ejecutar la lógica de forecast y, de manera invariable, emitirás una orden de compra en el día en que tu forecast sea el más alto.

Es un efecto de trinquete porque, una vez que tu forecast fluctúa hacia arriba o hacia abajo —y en términos de precisión puede ser bastante bueno tener esas fluctuaciones, ya que captura de manera adecuada la variación a corto plazo—, el precio que tienes que pagar es que cada vez que activas una decisión, quedas comprometido con esa decisión.

Y cuando tienes esas fluctuaciones, lo que típicamente sucede es que vas a capturar la fluctuación ascendente. La fluctuación descendente no es tan mala; simplemente retrasas algo por un día más, pero la fluctuación ascendente desencadena el lote de producción, el reabastecimiento de inventario, la asignación de inventario, y la bajada de precios.

Porque, de nuevo, es lo mismo. Si bajas tu precio y luego tienes un aumento de la demanda causado por esa bajada, pero has subestimado la demanda, y ahora pensaste que tenías demasiado stock, cuando en realidad no era así, y ahora que has bajado el precio, accidentalmente te colocas en una posición de faltante de stock.

Son todo ese tipo de situaciones en las que se producen esos efectos de trinquete: si tienes esas fluctuaciones, actuarás, y luego el desempeño de tu empresa reflejará la variación extrema de tu modelo estadístico, modelo estadístico predictivo, o lo que sea. No es bueno, porque, en términos de decisiones, estás capturando el ruido del modelo predictivo.

Nikos Kourentzes: ¿Puedo añadir algo? Primero que nada, estoy de acuerdo. Pero puede ayudar ver también el mismo argumento desde la perspectiva de un tipo de series temporales como yo, que fue educado para pensar en precisión.

Donde eventualmente cambié de opinión fue porque, supongamos, tienes cierta demanda de una unidad de mantenimiento de inventario, un SKU, y luego encuentras tu mejor modelo y lo optimizas en algo como una verosimilitud o minimizando tu error cuadrático medio.

Ahora, el supuesto detrás de hacer eso es que has hecho una buena aproximación del modelo, y, típicamente, tu error es una predicción de un paso adelante. Eso es lo que usualmente hacemos, al menos en el error in-sample que minimizamos.

Si tu modelo no es el modelo correcto —y el modelo correcto implica que, de alguna manera, conoces el proceso generador de datos, lo cual nunca es cierto—, si minimizaras ese error, entonces tu forecast sería perfecto para todos los horizontes de forecast. Pero ese no es el caso, porque tu modelo es solo una aproximación.

Entonces, supongamos que minimizas tus errores para una predicción de un paso adelante, como usualmente hacemos; tu modelo puede funcionar muy bien para esta predicción, pero no para el lead time. El lead time requiere pasos adicionales.

Si entonces dijeras, “Oh, puedo ajustar mi modelo para que sea muy bueno, tal vez, a 3 meses a partir de ahora, digamos tres pasos adelante”, pues terminas teniendo el efecto opuesto. Tu modelo es muy bueno ajustado a ese horizonte de forecast, pero no al horizonte que es más corto. Así que, de nuevo, en el lead time, te quedas sin información.

Así que lo que intento decir con esto es que la forma tradicional de pensar, cómo optimizamos los modelos, invariablemente conducirá a forecasts efectivamente inexactos en el sentido de que siempre estarán calibrados para el error que el optimizador busca y no para la decisión real que intentamos apoyar. Tiene un horizonte diferente.

Es aquí, por ejemplo, donde mucha investigación en estimadores de shrinkage o el trabajo que mis colegas y yo hemos realizado sobre jerarquías temporales han ayudado un poco, porque estas técnicas siempre piensan: “No sobreajustemos los datos. No obsesionémonos con minimizar alguna estadística de error.”

Entonces, ya sabes, lo que Joannes describió es esencialmente que se puede ver desde dos perspectivas. Una es el efecto en la supply chain, y la otra es la base estadística de por qué invariablemente tendrás esto.

Joannes Vermorel: Sí, de hecho. En Lokad, nuestra práctica hoy en día, y ha sido así durante bastante tiempo como parte del marco de Supply Chain Quantitativa, realizamos una optimización puramente financiera. Así que optimizamos directamente en euros o dólares.

Y, de hecho, estas métricas se descubren. Incluso tenemos una metodología específica para ello llamada optimización experimental, donde, debido a que los sistemas de supply chain son muy opacos y muy complejos, y por lo tanto la métrica no es algo dado, es todo un tema descubrir eso.

Ahora, lo interesante es acerca de los horizontes de forecast y cómo varía el forecast con ello. He estado pensando en esa línea durante mucho tiempo, pero, esencialmente, la última competencia de forecast de Makridakis, M4, M5, M6, ha demostrado que, prácticamente, los mejores modelos son los mejores para todos los horizontes, sin importar cuál elijas.

Lokad, en 2020, alcanzó el primer lugar a nivel de SKU para Walmart, y fuimos los mejores para forecast de un día, de 7 días, todo. Durante mucho tiempo he trabajado con la posibilidad de que podrías tener modelos que funcionen mejor en ciertos horizontes.

Pero si observas los modelos modernos, como los de differentiable programming, por ejemplo, esas clases modernas de modelos de forecast ahora son bastante uniformes. Es muy raro hoy en día encontrar modelos que funcionen mejor un paso adelante en lugar de seis meses adelante.

Y, esencialmente, hay modelos que tienen horizonte indefinido, hacen forecast hasta el fin del tiempo, y simplemente paras para ahorrar recursos computacionales porque de lo contrario sería un desperdicio. Pero, no obstante, el punto es que, en general, no se debe asumir que la métrica que se está optimizando sea conocida.

No se debe asumir que sea una de las elegantes métricas matemáticas, como la log likelihood si quieres ir por el camino bayesiano, o el error cuadrático medio, o lo que sea. Eso es muy bueno si quieres demostrar teoremas en artículos, pero demostrar teoremas y propiedades de modelos no se traduce en resultados operativos.

Puede crear muchos defectos sutiles en el comportamiento que no son inmediatamente evidentes desde la perspectiva matemática.

Conor Doherty: Bueno, gracias. Nikos, solo para retomar algo que dijiste antes y avanzar, dijiste que te consideras un experto en series temporales y que anteriormente te habías centrado en la exactitud, y luego dijiste: “Oh, cambié de opinión y fui más allá de la exactitud o de enfocarme en la exactitud de manera aislada.” ¿Podrías describir ese proceso? Porque cada vez que tengo conversaciones sobre forecast, resulta bastante difícil convencer a la gente de no ver la exactitud del forecast como un fin en sí mismo. Recuerdo que incluso en tu artículo dijiste: “El objetivo del forecast no es la exactitud.” Esa afirmación es bastante controvertida, dependiendo de a quién se le diga. Entonces, ¿cómo recorriste exactamente ese camino?

Nikos Kourentzes: Sí, quiero decir, es controvertido, tienes mucha razón. Pero creo que es un argumento que las personas del mundo de las series temporales aceptan con mayor facilidad que quienes usan forecasts, si se puede decir así. Permíteme comenzar retomando algo que acabas de mencionar sobre los horizontes de forecast.

Creo que esta comprensión, de que los modelos son capaces de producir buenos forecasts para todos los horizontes, radica en cómo comparamos los propios modelos. Como sabes, retomando nuevamente las competiciones M que mencionaste. Esta es una lectura útil de las competiciones M, pero todos estos modelos están optimizados de maneras similares. Incluso si tomas un suavizado exponencial simple y cambias tu función objetivo, la forma en que estimas tus parámetros, en realidad puedes lograr que funcione mucho mejor o mucho peor en diferentes objetivos o horizontes.

Así que, para mí, esto fue también un punto de partida para decir: bueno, tal vez hay algo sucediendo aquí. Y es aquí donde, por ejemplo, soy algo crítico con simplemente usar métodos estándar… déjame reformularlo. Cuando tengo que trabajar con estudiantes de doctorado o de maestría en sus tesis, a veces les pido que hagan la implementación de la manera difícil en lugar de usar una biblioteca, porque quiero que entiendan lo que realmente ocurre bajo el modelo. Y es allí donde se pueden encontrar algunos de los detalles y cuestionarse: ¿tiene esto sentido?

Una de las cosas que ya se había mencionado antes es que disfrutamos de fórmulas y expresiones que son fáciles de manejar matemáticamente. Quiero decir, “fáciles” entre comillas, ya que a veces son bastante complejas, pero sí, siguen siendo fáciles en el sentido de que, con los supuestos adecuados, aún se puede trabajar la matemática. Pero aquí es donde radica el problema para mí, porque al hacer eso terminamos teniendo una buena comprensión de lo que ocurre bajo los supuestos, y eso es muy útil. Pero a menudo luego olvidamos plantear: ¿y si este supuesto se viola? ¿Qué sucede si tenemos una especificación del modelo diferente?

Así que, para mí, la especificación del modelo es el punto de partida. Una vez que introduces eso, muchas de estas expresiones se vuelven problemáticas. Debo tener cuidado aquí y, ya sabes, siendo yo mismo académico, eso no hace que esta investigación sea de ninguna manera inútil. Pero es un peldaño. Tenemos que entender todas las propiedades y luego decir: bien, ahora introduzcamos la especificación del modelo.

Tengo algunos colegas de España con quienes he trabajado en la calibración de políticas de inventario. Y en un artículo en el que estamos tratando de completar la revisión —esto siempre es un aspecto complicado para los académicos—, se trata exactamente de eso: decir, ya sabes, supongamos que tenemos una política muy simple, como una política de order up to, esto es lo que obtendríamos si asumimos que el modelo es correcto, y esto es lo que obtendríamos si decimos que el modelo está mal especificado. Porque puedes ver que hay riesgos adicionales en el supply chain, y riesgos adicionales al establecer el inventario.

Para mí, el momento de decir que la exactitud no es suficiente es cuando empiezo a pensar: bueno, el modelo está mal especificado, ¿qué implica este riesgo adicional? Si lo piensas en términos de políticas de inventario estocásticas, lo que estamos diciendo es que, bueno, existe un riesgo estocástico proveniente del proceso de la demanda, lo cual está bien. Pero ese no es el único riesgo. Y no estoy sugiriendo de ninguna manera que esté capturando todos los riesgos de la forma en que lo concibo, pero al menos la lógica dicta que tiene que haber algo más que un único objetivo de exactitud.

Eso no significa que debamos abandonar ese objetivo; debe haber, ya sabes, alguna correlación entre ese objetivo y otros objetivos, incluso si dejas de perseguirlo completamente. Porque si ignoras por completo tener un forecast exacto, en el sentido más amplio, entonces no estarás haciendo bien tu trabajo, al menos según mi experiencia.

Puedes cambiar el objetivo por completo, por ejemplo, en congruencia encontramos incluso teóricamente que existe una conexión con la exactitud. No es una conexión del 100%, pero sí hay una conexión débil. Así que, para mí, eso no significa que, de acuerdo, descartemos la exactitud. Pero sin duda no es el fin de la discusión. Ahora bien, si puedes reemplazarla por una métrica mejor que aún tenga propiedades similares, o por una colección de métricas, genial. Yo estoy de acuerdo con ello. No me importa si llamamos a la métrica de una forma u otra, o si es mi métrica o la de otra persona. Pero realmente creo que, cuando avanzamos con la especificación del modelo y se implican los riesgos de ello en el proceso, no podemos aferrarnos a las métricas tradicionales.

Conor Doherty: Gracias, Nikos. Joannes, volveré contigo en un momento, pero quiero subrayar un par de puntos. Uno, creo que me equivoqué al expresarme. Debería haber dicho que la exactitud no es el objetivo del forecast. Creo que lo dije al revés. Pero, para retomar un punto que acabas de mencionar, y que considero clave en el artículo, es que no estás abogando —corrígeme si me equivoco— por perseguir el forecast más congruente. Es una mezcla entre exactitud y congruencia. ¿Es una interpretación justa? Y de ser así, ¿podrías ampliar sobre eso para alguien que quizá no entienda cómo se persigue una combinación de estas dos métricas?

Nikos Kourentzes: Primero debo enfatizar que esto es un trabajo en curso, así que aún no tengo la respuesta completa. Pero parece que una heurística simple sería algo así como: una vez que encuentres tu colección de forecasts exactos, de entre esos escoge el más congruente. No es recomendable elegir directamente el forecast más congruente, ya que podría ser un forecast muy inexacto, si se entiende lo que quiero decir.

Así que veo estos dos objetivos —si lo formulo de una manera u otra— existe una región en la que ambos mejoran juntos y, luego, terminas teniendo una compensación. Cuando alcanzas esa compensación, entonces debes ponderar más el lado congruente.

Conor Doherty: Bien, esa iba a ser la pregunta de nuevo. Utilizas el término compensación y, nuevamente, es algo en lo que nos enfocamos mucho, las compensaciones. ¿Cómo es que tú —y entiendo que es un trabajo en curso—, o cómo es que una empresa, valora nuevamente esas compensaciones, es decir, exactitud versus congruencia? Y sé que, de nuevo, estás tratando de reducir la inestabilidad, la fluctuación entre todos los forecasts congruentes. Pero aun así, quiero decir, la exactitud del forecast es simple. Podemos admitir que puede tener fallos, pero es fácil de comprender. Solo quiero que sea más exacto, que el número suba. Pero ahora estamos introduciendo otra dimensión. Así que, de nuevo, la ponderación de ello, ¿cómo lo aborda una empresa? Eso es a lo que me refiero específicamente.

Nikos Kourentzes: Sí, entonces me cuesta dar una respuesta clara porque aún no la tengo. Pero tal vez pueda dar un ejemplo de la lógica.

Anteriormente hice el punto sobre las series temporales estacionales. Entonces, cuando surge la dificultad de definir la congruencia como una métrica —y esta es una discusión que tuve con otros colegas que decían: “oh, pero podrías hacer esto o aquello en su lugar”—, se trata esencialmente de la idea de la media condicional del forecast. ¿Qué es eso? Supongamos que la demanda es realmente estacional, por lo que existe alguna estructura subyacente. Esa estructura subyacente, que es desconocida, es la media condicional.

Si dijera que quiero el forecast que sea el más estable, o, como lo llamamos, el más congruente, en principio sería una línea recta, una línea plana. Esa línea plana no transmitiría ninguna información sobre la estacionalidad. Así que, efectivamente, el forecast más congruente sería un forecast determinista que asume la ausencia de estocasticidad, de estructura en la serie, nada de eso. Claramente, se trataría de un mal forecast.

Entonces, el acto de equilibrio surge porque queremos el forecast más congruente en términos de esta media condicional. Es decir, queremos que intente ser estacional, que intente seguir esta estructura. Pero no lo vamos a forzar hasta el punto de intentar captar cada detalle. Se podría decir que hay cierta conexión con overfitting y underfitting, pero no es una conexión al 100% porque todos podemos estar de acuerdo en que el overfitting es algo malo.

Pero cuando analizamos el mismo aspecto en términos de sobre congruencia y sub congruencia, es fácil demostrar que la sub congruencia es algo malo, como esa línea plana que mencionamos antes. Sin embargo, la sobre congruencia no es necesariamente algo malo. Y ese “no necesariamente” es donde las cosas se vuelven interesantes y complicadas. El “no necesariamente” se conecta mucho con los puntos que Joannes ha planteado antes, es decir, que hay otros aspectos en la gestión del inventario en el supply chain que nos interesan. Así que, al tener esta congruencia adicional en los forecasts, efectivamente estamos facilitando la vida de los que toman decisiones posteriormente. Desde una perspectiva estadística, este no será el forecast más exacto, pero proporcionará información suficiente para que el tomador de decisiones actúe. De modo que las decisiones siguientes serán, ya sea financieramente o en cualquier otra métrica de inventario que se utilice —por ejemplo, generar menos desperdicio o algo por el estilo—, más fáciles de obtener.

Estoy siendo un poco vago aquí porque no tengo algo mejor que la heurística que mencioné anteriormente para ofrecer en este momento. Esto es, como dije, con la esperanza de que el próximo artículo proporcione la expresión matemática completa para decir: “ah, en realidad es un problema trivial.” Aún no lo tengo. Así que diría que, en la práctica, lo que sugiero a las personas hacer es identificar su colección de forecasts exactos y, de esos forecasts, escoger el que maximice la congruencia. Es decir, en cierto sentido, una selección en dos pasos: primero obtener un grupo de forecasts exactos y luego optar por el congruente.

Lo interesante es que resulta que, en la mayoría de nuestros experimentos, este resulta ser un modelo que utiliza ya sea algún tipo de truco de estimadores de shrinkage o algún tipo de truco de agregación temporal, y así sucesivamente, porque estos tienden a suavizar los forecasts. Debo enfatizar que hay otros colegas que también han propuesto ideas similares. Pueden modificar la función de pérdida para incluir, por ejemplo, un término que intente minimizar también la variabilidad del forecast, etc. Donde creo que la métrica de congruencia se diferencia un poco es en que tratamos de mostrar también la conexión con la exactitud, es decir, proporcionar las expresiones para decir que es exactamente ahí donde se conectan y ahí donde divergen.

Conor Doherty: Gracias, Nikos. Joannes, ¿cuáles son tus pensamientos?

Joannes Vermorel: Sí, quiero decir, en Lokad abordamos esto desde un ángulo algo diferente. Seguimos la ruta radical que literalmente plantea “dólares de error, euros de error”, y asumimos que las métricas van a ser descubiertas, es decir, que son completamente arbitrarias. Es tan directo como para optimizar algo en lo que la métrica puede ser cualquier cosa. Entonces, ¿cómo abordamos eso? Bueno, resultó que si la métrica es cualquiera, es efectivamente un programa, ya sabes, un programa de computadora. Puedes tener métricas que ni siquiera pueden representarse como programas de computadora; en matemáticas puedes inventar cosas que incluso escapan a las computadoras. Pero, para dar fundamento a la discusión, asumimos que no estamos entrando en espacios matemáticos súper extraños o hiper abstractos. Así que, tenemos algo que al menos se puede calcular. Es decir, se trata de un programa, un programa arbitrario.

Lo bueno es que si quieres optimizar prácticamente cualquier cosa, lo que necesitas es tener gradientes. Tan pronto como tienes gradientes, puedes dirigirlos. Para el público, tan solo con tener la pendiente, significa que puedes orientar tus parámetros en la dirección correcta para minimizar aquello que intentas minimizar. Así que, siempre que quieras optimizar, obtener algo mayor o menor con una intención específica, si puedes obtener los gradientes, eso te da la dirección en la que debes ir, lo cual ayuda enormemente.

Ahí es donde la Differentiable Programming realmente ayuda, porque Differentiable Programming es literalmente un paradigma de programación que Lokad utiliza ampliamente. Te permite tomar cualquier programa y obtener los gradientes, y eso es sumamente poderoso. Típicamente, es así como conectamos esta perspectiva financiera. Vamos a descubrir esos elementos financieros. Será un proceso desordenado, muy caótico, y lo que obtendremos será un programa algo extraño que simplemente refleje las peculiaridades, las rarezas del supply chain de interés.

Podemos diferenciar cualquier programa, así que podemos diferenciar eso y luego optimizar, basándonos en ello, cualquier modelo que tengamos, siempre y cuando el modelo en sí sea diferenciable. Eso restringe nuestro enfoque a modelos que tienen una estructura diferenciable, pero, he aquí, en realidad es la mayoría. En esta competición, la M5 —para la competición de Walmart— básicamente hemos sido clasificados en el nivel SKU como número uno con un modelo diferenciable.

Así que, imponer la diferenciabilidad no es algo que te impida obtener resultados de última generación. Ahora, avanzando rápidamente, esa es simplemente la esencia de lo que sucede cuando abandonas tus métricas, ya que, típicamente, terminas equilibrando montones y montones de cosas.

Ahora, otra cosa es que el probabilistic forecasting es la idea de que miramos todos los posibles futuros, pero no solo para la demanda. Por ejemplo, mencionaste los lead times con horizontes posibles y demás, pero la realidad es que el lead time varía, y también existe incertidumbre.

Peor aún, el lead time que observarás está ligado a la cantidad que ordenas. Si ordenas, por ejemplo, 100 unidades, podría llegar más rápido que si ordenas 1000 unidades, simplemente porque, bueno, la fábrica que produce los productos va a necesitar más tiempo.

Así que terminas con toneladas de correlaciones que configuran y estructuran la incertidumbre. Por lo tanto, la perspectiva unidimensional de la serie temporal es insuficiente, incluso si hablamos de solo un SKU, porque tenemos que añadir algunas capas de incertidumbre extra, al menos con los tiempos de entrega, al menos con las devoluciones con ecommerce, y así sucesivamente.

Usaré el término congruencia de manera laxa porque ya lo acabas de introducir, pero nuestra observación práctica, cuando recurrimos a modelos probabilísticos, fue que dichos modelos, numéricamente hablando, eran muchísimo más estables.

Eso fue muy interesante porque la mayoría de esas inestabilidades, incongruencias, o lo que sean, simplemente reflejan que tienes mucha incertidumbre ambiental. Y tienes áreas de probabilidades relativamente planas. Entonces, según prácticamente cualquier métrica, mientras tengas, por ejemplo, un forecast puntual, el modelo puede fluctuar ampliamente.

Y en términos de métricas, prácticamente cualquier métrica que elijas será prácticamente la misma. Entonces, terminas con la extraña propiedad de que, nuevamente, si te quedas con forecasts puntuales, es que si tienes una situación de alta incertidumbre, alta incertidumbre ambiental, terminas con el tipo de problemas en los que puedes tener forecasts muy, muy diferentes que son, según tus métricas, casi iguales.

Y así, terminas con este temblor y demás. Y es cuando pasas a esos forecasts probabilísticos que entras en un ámbito donde, bueno, el buen modelo será aquel que exprese esta dispersión, que exprese esta alta incertidumbre ambiental. Y eso en sí mismo es mucho más, diría, constante.

Eso es muy extraño, pero terminamos con, tuvimos toneladas de situaciones en las que estábamos luchando tanto para obtener un poco de estabilidad numérica, y luego, cuando pasas al ámbito de los forecasts probabilísticos, de inmediato tienes algo que es muchísimo más estable, donde esos problemas que realmente dolían pasan a ser secundarios.

Entonces, eso es algo interesante. Y luego podemos vincular todo eso con otras cosas. Cuando vamos más allá del forecast de series temporales, lo hemos discutido un poco en este canal, pero eso sería una digresión, ya que la mayoría de los problemas de supply chain vienen con mucha interconexión entre SKUs, interconexión entre productos.

Y así, muy frecuentemente tenemos que subir a una perspectiva que no es de series temporales, una perspectiva de mayor dimensionalidad. Pero de nuevo, eso es una digresión sobre una digresión.

Nikos Kourentzes: Estoy completamente de acuerdo. El forecast probabilístico es absolutamente necesario. He llegado al punto en que, cuando miro algunos de los artículos inconclusos que han estado en el tintero durante algunos años y veo que no hay forecast probabilístico, pienso que necesito rehacerlo todo. Tiene que tener forecast probabilístico, ya es 2024. Pero aquí está la cosa, me gusta el forecast probabilístico, especialmente la forma en que Joannes lo ha explicado, porque me da otra manera de enfatizar el punto sobre la especificación del modelo.

Cuando observas la incertidumbre alrededor de tu forecast, normalmente asumimos que esta incertidumbre se debe a la estocasticidad de la serie temporal. Pero una buena parte de esa incertidumbre se debe a que el modelo es incierto. Tienes la incertidumbre proveniente de los datos, la incertidumbre proveniente de tu estimación, y la incertidumbre del propio modelo. Puede que le falten algunos términos, o que tenga más términos, o que simplemente esté completamente equivocado. Dividir esa incertidumbre sigue siendo un gran problema.

Si no divides esa incertidumbre, de hecho encontrarás a menudo que muchos modelos diferentes, a menos que sean sustancialmente diferentes, terminarán enmascarando la incertidumbre con la incertidumbre de su modelo. Te darán una mayor incertidumbre, al menos empíricamente hablando, y una buena parte de esa incertidumbre parecerá ser similar porque lo que intenta decirte es que todos estos modelos son problemáticos.

No estás llegando a la verdadera profundidad de tener esta incertidumbre debido a los elementos estocásticos de la demanda. Todavía no he logrado encontrar una buena manera de solucionarlo y no he visto nada en la literatura. Pero al menos el forecast probabilístico es honesto al decir, bueno, esta es tu incertidumbre. Es un poco mayor de lo que pensábamos si partíamos del forecast puntual. Ese es un buen paso hacia la solución.

Conor Doherty: Gracias a ambos. Se me ocurre que tengo aquí tanto a dos académicos como a dos practicantes. Creo que en este punto me conviene dirigirlo hacia lo práctico. Todo el impulso de lo que hace Lokad, pero ciertamente tu artículo y tu investigación en general, Nikos, se está aplicando a la toma de decisiones de inventario. Hablando de eso, Joannes, cuando hablaste sobre las peculiaridades y rarezas de supply chain, tiempos de entrega variables y el efecto látigo, todos estos conceptos, tu posición, Nikos, en el artículo en preparación del que estamos hablando, era que perseguir la congruencia en el forecast puede ayudar a lidiar o mitigar los efectos del efecto látigo. ¿Podrías esbozar eso para que la gente entienda cómo esta idea puede ayudar a enfrentar lo que es un problema serio, el efecto látigo?

Nikos Kourentzes: Presumo que tu audiencia es bastante consciente de eso. El problema que tengo con mucha de la investigación sobre el efecto látigo es que se trata más de describirlo en lugar de proporcionar acciones para remediarlo. Al menos, viniendo especialmente desde el punto de vista de series temporales, donde decimos, oh mira, aquí está tu relación de efecto látigo. Pero eso en muchos aspectos es solo una descripción del problema. No te dice cómo lidiar con él una vez que lo has medido.

Aquí es donde digo, bueno, de acuerdo, si quiero conectar el forecast con la decisión en lugar de mantenerlos separados, entonces necesariamente necesito tener algo que me pueda decir, bueno, si tomas esa dirección, vas a reducir tu efecto látigo. Resulta que, sin entender eso desde el principio, si trabajas las ecuaciones, la congruencia y la relación de efecto látigo al menos parecen tener muchas similitudes. Esta imposición de similitud a lo largo de los periodos, o congruencia como simplemente lo decimos, parece estar muy alineada con la idea de tener un efecto látigo bajo proveniente de tus forecasts. Por supuesto, hay muchas otras razones por las que vas a tener un efecto látigo.

Entonces, si vamos a usar una métrica congruente o algo similar para seleccionar o especificar tus modelos de forecast, ya puedes orientar una solución que será más favorable en términos del efecto látigo. Aquí creo que, al menos, dado que estoy trabajando en la esfera del forecast, tengo que reconocer que el efecto látigo es mucho más amplio que el forecast. El forecast es solo una parte de ello. Hay tantos otros elementos que entran en juego. Pero al menos para el forecast, puedes diseñar, si piensas en congruencia y formas de pensar similares, forecasts que sean al menos favorables hacia ello.

Joannes Vermorel: Cuando empezamos a tocar el efecto látigo, cuando dije que observamos la decisión y optimizamos euros y dólares, en realidad estaba simplificando. Porque la realidad es que en realidad estamos observando el proceso de toma de decisiones secuencial. Y aquí estamos tocando, esencialmente, la optimización estocástica de procesos de toma de decisiones secuenciales, que fue un tema discutido con el Profesor Warren Powell.

Estamos optimizando no solo la siguiente decisión, sino todas las demás que vienen después. Necesitamos tener un mecanismo para traer toda esta información del futuro, donde hemos representado las decisiones futuras que se generarán a través de esos forecasts, al presente. Ahí es donde la programación diferenciable brilla, porque, esencialmente, tienes un programa que representa, simula si lo deseas, las decisiones del futuro y necesitas ser capaz de retropropagar el gradiente para poder reinyectar esos resultados financieros futuros en la ingeniería de tu forecast actual.

La forma en que normalmente miramos eso es que, si volvemos al efecto látigo, no te sorprendas por el efecto látigo. No hay nada en tu marco de optimización que siquiera reconozca los euros de costo que generará con el tiempo. No hay nada que realice este análisis de toma de decisiones secuencial simplemente repitiendo la decisión a lo largo del tiempo y viendo si vas a tener problemas de efecto látigo.

La solución no es tan complicada. Es simplemente optimizar no solo la siguiente decisión que estamos analizando, sino todo lo que sigue. Implícitamente, lo que estamos optimizando es una especie de política. Pero, típicamente, la gente piensa en la optimización de políticas como algo estrictamente independiente del forecast. Tendrían la optimización de políticas que solo consume el forecast. La manera en que Lokad lo ve es que no, esas cosas están realmente entrelazadas.

El forecast superior viene de la mano con la política superior. Ambos están muy conectados. Incluso hay un artículo reciente de Amazon, “Deep Inventory Optimization”, donde literalmente eliminan por completo la distinción. Directamente tienen algo que unifica la perspectiva de modelado predictivo y la de investigación operativa, que suelen estar separadas. Dicen: no, simplemente vamos a hacer las dos cosas al mismo tiempo y cuentan con un modelo de optimización predictiva simultáneamente a través de deep learning.

Eso es muy interesante porque literalmente significa que la decisión se optimiza de forma predictiva, pero el forecast mismo se vuelve completamente latente. Es solo otra manera de ver el problema, pero es muy futurista y crea otros problemas. Pero al mirarlo, aún tenemos la parte de modelado predictivo y la parte de optimización estocástica como dos etapas, pero dos etapas que están altamente acopladas y habrá mucho ir y venir entre las dos etapas.

Nikos Kourentzes: En realidad, creo que mantener las etapas separadas tiene sus beneficios. Sin embargo, no deberían estar aisladas y hay una razón para ello. Estoy completamente de acuerdo en que una debería guiar a la otra. He trabajado en el pasado con la idea de tener una optimización conjunta tanto para la política de inventario como para el forecast. El artículo ya está publicado, así que los detalles están ahí para que la gente los consulte si quiere ver lo que está pasando. Mi preocupación con este trabajo fue que no pude hacerlo escalable. No tenía una manera de hacer la optimización de forma que me permitiera manejar una gran cantidad de SKUs. Esto podría deberse a mis limitaciones en optimización más que al propio sistema.

Creo que mantener los dos pasos separados ayuda a tener más transparencia en el proceso. Si tengo una solución conjunta y de repente digo que tu inventario para tus pedidos del próximo periodo debería ser 10 y alguien dice, bueno, creo que debería ser 12, es muy difícil justificar por qué 10 tiene más mérito que 12. Si entiendes el forecast y la política impulsada por el forecast, puedes tener una discusión más transparente. “Está bien, aquí está mi forecast, estos son los detalles del forecast, aquí está mi política impulsada por un buen forecast o potencialmente incluso ajustada debido a las opciones de forecast que tengo o viceversa”, puedes decir, “Si me quedo con estas políticas, tal vez solo deberían estar en juego este tipo de opciones de forecast.” Pero aun así tienes la transparencia y dices, “Puedo ver elementos de forecast problemático aquí, puedo ver elementos de pedidos problemáticos aquí.”

Y el otro elemento con el que tengo un problema es con que la gente se adentre completamente en optimizaciones o forecasts oscuros donde tienes una gran confianza en deep learning. No importa cómo hagamos el modelado, en algún momento los humanos interactuarán con el modelo y las salidas. La investigación y mi experiencia sugieren que, si la gente entiende lo que está pasando, su interacción con el modelo y los números, y los ajustes que puedan hacer para incorporar información contextual, serán más exitosos.

Si se trata de un número muy oscuro, esta caja negra, muchas personas tienden a decir que entonces o no sabrán qué hacer con dicho número o interactuarán de manera destructiva con él. Me gusta mantener la separación porque ayuda a la transparencia. Compone el problema, diciendo: esta es la contribución que viene de aquí, esta contribución viene de allá. Así que me inclino a estar bastante de acuerdo con el enfoque que está describiendo Johannes. Tenemos que unir de alguna manera las tareas, una tiene que conducir a la otra, pero también tenemos que ser capaces de describir lo que cada paso está haciendo.

Conor Doherty: Gracias, Nikos. Volveré a ti, pero quiero dar seguimiento a un punto allí. Mencionaste la intervención humana y anulación un par de veces. ¿Cuál es el papel de la intervención humana en términos de la congruencia del forecast? La tendencia a menudo es que, si solo se mide la precisión, se diga: “el modelo está equivocado, yo sé mejor, déjame intervenir”, y, por supuesto, entonces simplemente estás aumentando el ruido en muchos casos. ¿Cómo maneja la congruencia del forecast como concepto eso? ¿Implica muchas anulaciones o no?

Nikos Kourentzes: Este forecast conductual o ajustes juiciosos, distintos nombres en la literatura, creo que aún no sabemos lo suficiente, aunque es un área de investigación muy activa. Algunos artículos sostienen que deberíamos eliminar estos ajustes porque son contraproducentes o incluso destructivos en términos de precisión o del resultado final. El problema con este pensamiento es que tienes que tener una métrica. Si uso el error porcentual absoluto medio, obtendré una respuesta. Si uso el error cuadrático medio, obtendré otra respuesta. Si uso congruencia, obtendré otra respuesta.

Sin embargo, la pregunta que tengo es, volviendo a nuestro punto inicial de la discusión, ¿por qué no me quedo solo con la precisión? Quiero decir, lo mismo para ustedes, no se están quedando solo con la precisión. Siempre y cuando reconozcamos que esto es importante, entonces, obviamente, necesitaríamos ajustar o evaluar los aspectos conductuales del proceso de forecast o del proceso de inventario con una métrica que sea más consciente que solo la precisión. No creo que debamos eliminar la intervención humana. Creo que hay suficiente evidencia de que, cuando la información contextual que pueden usar es rica, pueden hacerlo mejor que la mayoría de los modelos. Sin embargo, no pueden agregar valor de manera consistente. Hay muchos casos en los que simplemente sienten que necesitan hacer algo o pueden estar sobrerreaccionando ante el bombo o ante una información que es muy difícil de entender cómo impactaría en tu inventario. En esos casos, es una interacción destructiva con el modelo o los forecasts.

Necesitamos mantener el elemento humano porque puede agregar valor, pero debemos orientar cuándo deben agregar valor. Es un proceso que consume mucho tiempo. Si puedo decirles a los analistas que dejen ciertas tareas a la automatización completa y concentren su atención en acciones específicas, entonces también puedo hacer su trabajo más efectivo. Pueden dedicar más tiempo y recursos a hacer mejor aquello en lo que son buenos. La congruencia entra en esta discusión al decir que, si tenemos que ir más allá de la precisión, entonces al evaluar qué pasos aportan valor, puede ayudar a discriminar aquellos en la configuración de inventario o en la toma de decisiones de manera más general.

Una discusión similar aplicaría para los pedidos. Los modelos o políticas te proporcionarán, probablemente, una buena base si estás haciendo bien tu trabajo como analista. Sin embargo, no puedo ver que este sea universalmente el número más informativo. Siempre habrá algunos elementos, algunas disruption que acaban de suceder esta mañana en el supply chain, por ejemplo, algo que es difícil de evaluar. Esto no tendrá el problema de si se mantiene bien con el tiempo o no. Hay algún conflicto sucediendo en el mundo. Típicamente, siempre hay algún conflicto ocurriendo en el mundo. A veces afectará tu supply chain, y a veces no. A veces puede ejercer presiones, digamos, sobre la inflación y así sucesivamente, de modo que tus consumidores pueden empezar a comportarse de manera diferente. Estas son cosas que son extremadamente difíciles de modelar.

Así que aquí es donde confío en los expertos y analistas que tienen el tiempo para hacer esto, su trabajo propiamente. Y quizá pueda concluir con eso, en cuanto a los ajustes, diciendo que la investigación sugiere que descomponer tus ajustes, es decir, si vas a decir, “Está bien, voy a refinar el número en 100,” diciendo, “¿Por qué 100? Porque 20 por esta razón y 80 por esta razón,” se correlaciona mucho con lo que decíamos antes: descomponer, si se quiere, o mantener separados los dos pasos del forecast y del inventario, pero no aislados.

Porque si vas a decir, “Está bien, voy a cambiar mi pedido en un x%,” si le preguntamos a la persona que está haciendo eso, “¿Puedes explicar qué parte de eso se debe a tu comprensión del riesgo proveniente del modelo del forecast o de las realidades del supply chain?” potencialmente, podrán proponer un mejor ajuste.

Conor Doherty: Gracias, Nikos. Johannes, te pasaré la palabra. Eres un gran fanático de la anulación humana, ¿estoy en lo cierto?

Joannes Vermorel: No, durante los primeros cinco años en Lokad, permitíamos que la gente hiciera ajustes al forecast y fue un error terrible. El día en que empezamos a ser un poco dogmáticos y lo prohibimos por completo, los resultados mejoraron dramáticamente. Así que, prácticamente, ya no lo permitimos.

Así que primero, consideremos el rol de los humanos. Quiero decir, la gente piensa en un SKU y piensa, pero eso no es típico. Un supply chain típico tiene millones de SKUs. Y entonces, cuando la gente dice que quiere hacer ajustes, en realidad están microgestionando un sistema increíblemente super complejo. Y, literalmente, es un poco como si estuvieras entrando en la memoria aleatoria de tu computadora y trataras de reordenar la forma en que se almacenan las cosas en tus computadoras, mientras tienes gigabytes de memoria y disco y lo que sea. Simplemente estás eligiendo algunas cosas que llamaron tu atención y no es un buen uso de tu tiempo.

Y no importa cuánta información obtengas, la información que recibes casi nunca es a nivel de SKU. Entonces sí, hay algo sucediendo en el mundo, pero ¿es algo que ocurre a nivel de SKU? Porque si tu interacción con un sistema consiste en modificar algo como un SKU, ¿en qué base tienes esa información de alto nivel que se traduzca en algo remotamente relevante a nivel de SKU? Así que tenemos esta desconexión masiva.

La gente pensaría que cuando, por ejemplo, consideras un caso de juguete, una situación realista sería pensar en 10 millones de SKUs, que es la base para una empresa que ni siquiera es super grande. Ese es mi problema y es ahí donde en Lokad hemos visto que se ha mejorado enormemente, y es que eso es mayormente tonterías. Simplemente estás eligiendo el 0.5% de los SKUs para hacer cosas y no tiene sentido, y generalmente crea muchos problemas. Y más aún, crea mucho código porque la gente no se da cuenta de que permitir interacción significa que necesitas escribir mucho código para soportarlo, y mucho código que puede tener errores. Ese es el problema del enterprise software. La gente lo ve típicamente como si fueran solo propiedades matemáticas, pero el enterprise software tiene errores, incluso el que escribe Lokad, desafortunadamente.

Y cuando tienes una empresa grande, quieres tener interacción humana, necesitas tener workflows, aprobaciones, revisiones, auditabilidad. Así que terminas con tantas características que, básicamente, comienzas con un modelo que tiene como mil líneas de código, es decir, el modelo estadístico, y terminas con un workflow que tiene como un millón de líneas de código solo para hacer cumplir todo.

Así que sí, la intención es bastante buena y creo que hay valor en la interacción humana, pero absolutamente no de la manera típica en que se produce. La forma típica en que Lokad aborda la interacción humana es decir: está bien, algo está sucediendo en el mundo, sí. Ahora, revisemos la estructura misma del modelo. Verás, de nuevo, del modelo predictivo y la optimización. Y, nuevamente, la postura clásica en la literatura es pensar en los modelos como algo dado. Tienes un artículo, está publicado, entonces operas con eso. En Lokad, no operamos de esa manera. Solo nos enfocamos esencialmente en el modelado predictivo y la optimización a través de paradigmas de programación. Así que Lokad no tiene ningún modelo, solo tenemos una larga serie de paradigmas de programación. Esencialmente, siempre es completamente hecho a la medida y ensamblado en el acto.

Y esencialmente es código, con los paradigmas de programación adecuados. Y cuando sucede algo, entonces, esencialmente, esos paradigmas de programación te dan una forma de expresar tus modelos predictivos o modelos de optimización de manera muy compacta, muy ágil, muy concisa. Es literalmente: reduzcamos esas 1,000 líneas de código, hagámoslas en 20 con la notación adecuada, si quieres.

Entonces, realmente puedes volver a tu código y pensar, “está bien, tengo algo y necesito intervenir.” No es a nivel de SKU, es muy raro que tengas información a ese nivel. La información que recibes del mundo exterior es, típicamente, algo mucho más de alto nivel. Y, por lo tanto, normalmente ajustarás algún aspecto de alto nivel de tu modelo. Y esa es la belleza: no necesariamente necesitas tener mucha información muy precisa.

Por ejemplo, si piensas, digamos, que estás en la industria de semiconductores y te preocupa que China y Taiwán se calienten, lo que dirías es: bueno, voy a tomar los tiempos de entrega y voy a añadir una cola en la que, por ejemplo, diré que hay un 5% de probabilidad de que los tiempos de entrega se dupliquen. Normalmente, los tiempos de entrega en la industria de semiconductores son muy largos, como 18 meses, pero aquí agregas de la nada un aspecto, digamos, un 5% de probabilidad anual de que los tiempos de entrega se dupliquen por cualquiera que sea la razón.

No necesitas ser preciso, ya sabes, al final puede ser un conflicto, puede ser una serie de confinamientos, puede ser una gripe que cierre puertos, puede ser cualquier tipo de cosa. Pero esa es la belleza de este tipo de enfoque probabilístico: combinado con paradigmas de programación, te permite inyectar una intención de alto nivel en la estructura misma de tus modelos. Va a ser muy burdo, pero también te permitirá, de forma direccional, hacer lo que deseas en lugar de microgestionar las anulaciones a nivel de SKU.

Y lo interesante es que, si vuelvo a este ejemplo donde agregamos ese 5% de probabilidad de que se dupliquen los tiempos de entrega, lo interesante es que literalmente puedes nombrar este factor. Dirías: “Este es nuestro Fear Factor” y eso es todo. Simplemente dices, está bien, es mi fear factor de las cosas, ya sabes, de lo realmente malo que puede suceder, y está bien. Y ahí es donde está la belleza: una vez que tienes eso, todas tus decisiones se orientan suavemente hacia esa probabilidad extra de un evento raro y no tienes que microgestionar SKU por SKU y hacer todo tipo de cosas que no se mantendrán con el tiempo.

Y si, seis meses después, te das cuenta de que tu miedo no estaba justificado, entonces es muy fácil deshacerlo. ¿Por qué? Porque tienes código en el que aparece este Fear Factor que viene con un comentario que dice, “este es mi término que es el Fear Factor.” Así que, en términos de documentación, traceability, reversibilidad, terminas, cuando abordas un problema a través de paradigmas de programación, con algo que es súper mantenible. Porque ese también es uno de los problemas que tuvimos en el pasado cuando la gente hacía intervenciones manuales, y que en realidad representaba la mayor parte del costo, era el pobre mantenimiento de las anulaciones.

A veces la gente, no siempre, pero a veces tiene la idea correcta, pone una anulación y luego se olvida de ella. Y entonces la cosa se queda y se vuelve radicalmente mala. Y ese es el problema, porque ya ves, una vez que introduces una anulación, dirías, “oh, ¿pero por qué tienes eso?” Bueno, el problema de las anulaciones es que cuando eres un proveedor de software como Lokad, vas a regenerar tu forecast cada día. Así que la gente no puede simplemente anular tu forecast y ya, porque mañana vas a regenerar todo.

Y entonces necesitan hacer persistente la anulación de alguna manera. Y el problema es que ahora tienes una configuración persistente que va a estar ahí, ¿y quién se encarga de mantenerla? Y terminas con un workflow aún más complejo para mantener las anulaciones, la eliminación gradual de la anulación, etc. Y todas esas cosas nunca se discuten en la literatura. Es muy interesante, pero desde la perspectiva de un proveedor de software enterprise, es simplemente una situación muy dolorosa y terminas teniendo como 20 veces o incluso 100 veces más líneas de código para lidiar con eso, lo cual es un aspecto muy poco interesante en comparación con enfrentarse al aspecto más fundamental de la optimización predictiva.

Nikos Kourentzes: En principio, la posición que adopta Joannes es una posición con la que no creo que muchas personas discrepen, o al menos aquellas que han enfrentado ambos lados. Mi opinión es que los ajustes no tienen que hacerse de esta manera. Aún no tengo una solución para ello, porque es un área de investigación muy activa. Como dije, sé que mucha gente ha trabajado en discutir si deberíamos eliminar este tipo de ajustes o aquel tipo de ajustes.

También podrías pensar en el problema de una manera muy diferente. Permíteme intentar responder, en cierto modo, retomando una investigación análoga con uno de mis colegas, Ive Sager. Él está en Bélgica. Hemos estado trabajando mucho para tratar de descubrir cómo podemos transferir la información que existe a nivel estratégico o a nivel de la empresa al nivel de SKU.

Así que, potencialmente, eso podría ofrecer una forma en la que podrías decir: “Mira, no voy a ir y ajustar cada SKU.” Estoy completamente de acuerdo en que la microgestión no es una buena idea, ya sea para tu SKU o en general, diría yo. Pero esa es una discusión diferente. Si dejas que la gente se descontrole con sus ajustes, la mayoría de las veces, debido a sesgos humanos, sentido de propiedad, etc., típicamente perderán tiempo. Si serán destructivos o constructivos con los ajustes está por verse, pero seguramente perderán tiempo.

En cuanto al aspecto del software que mencionó Joannes, tengo que aceptar tu opinión tal como es. No estoy en la misma área, aunque estoy de acuerdo en que los errores están en todas partes, en mi código, seguro. Pero puedo ver que hay una forma diferente en que alguien podría pensar en los ajustes como un proceso en su totalidad.

No creo que sea valioso ir y decir, “ya sabes, ahora necesito gestionar X número de series de tiempo.” Sería más como, “ya sabes, estratégicamente hacemos un cambio de dirección o nuestro competidor hizo X.” Estas son acciones muy difíciles de cuantificar, por lo que quizá sea mejor decir que la inacción es mejor que cuantificar de forma aleatoria.

Pero también puedo ver que esa información no está en los modelos. Entonces, si yo agregara al modelo algún riesgo adicional que el usuario pudiera calibrar o si pudiera preguntarle al usuario, “¿puedes idear una forma diferente de ajustar tu output?” sigue permaneciendo un elemento de juicio, de una forma u otra. ¿Cuál es la mejor manera de introducir ese elemento de juicio? Creo que es una cuestión abierta.

No veo la forma habitual de hacer ajustes como la ruta productiva. No es sólo el aspecto de complicar el proceso que menciona Joannes, sino también que veo a la gente perdiendo su tiempo. Se obsesionan tanto con ello que dicen que su trabajo es ir a la oficina y revisar cada serie de tiempo una por una, mirar los números o los gráficos. Eso no es lo que debería hacer un analista.

Especialmente hoy en día, cuando las empresas comienzan a tener equipos de data science, hay experiencia, hay personas bien capacitadas en el mercado. No deberíamos malgastar su tiempo de esa manera; deberíamos usarlas para mejorar el proceso. Por eso, pienso que hay lugar para los ajustes, pero no de la manera tradicional. Creo que la investigación es bastante concluyente en ese sentido: debido a inconsistencias, a sesgos, en promedio, no obtendrás el beneficio.

Conor Doherty: No hay nada en la búsqueda de la congruencia del forecast como métrica que impida la capacidad de tener automatización. La automatización aún podría ser parte del proceso de forecast en busca de congruencia, ¿verdad? ¿O lo he entendido mal?

Nikos Kourentzes: En cierto sentido, tienes razón. Mi comprensión de la congruencia, tal como se define y como la hemos visto empíricamente en los datos de la empresa, en realidad señalaría al usuario que elimine todos los ajustes menores. Porque los ajustes causarían fluctuaciones adicionales que serían incongruentes. Así que, naturalmente, impulsaría la eliminación de muchos ajustes.

Pero soy un poco escéptico porque necesitaríamos entender en qué punto estamos siendo excesivamente congruentes, en qué punto la información que tendrían los expertos sería crítica. Eso sigue siendo una cuestión abierta. Pero si pensamos en el proceso habitual que tanto Joannes como yo criticamos, las métricas de congruencia te ayudarían a ver el problema.

Conor Doherty: Entonces, ninguno de ustedes opina que debería haber una intervención manual día a día tomando cada SKU y ajustándolo. Eso sería simplemente un fatuo desperdicio de dinero. Así que hay un acuerdo total allí.

Joannes Vermorel: Pero esa es una práctica de facto en la mayoría de las empresas. Estoy de acuerdo cuando dices que quieres traducir la intención estratégica. Estoy completamente de acuerdo. Y cuando digo que uso la palabra paradigmas de programación, simplemente me refiero al tipo de instrumentos que te permiten hacer eso. Entonces, esencialmente, lo que quieres es, como no quieres que la gente se vea atrapada en la microgestión de SKUs, no quieres que quien esté en el equipo de data science tratando de traducir la intención estratégica se vea atrapado escribiendo código largo e inelegante que, más que la mayoría, probablemente tenga aún más errores y problemas.

Por ejemplo, tienes una distribución de probabilidad para la demanda, tienes una distribución de probabilidad para los tiempos de entrega, y simplemente quieres combinar ambas. ¿Tienes un operador para hacer eso? Si tienes un operador, Lokad tiene uno; literalmente puedes tener una línea de código que te proporciona el lead demand. Esa es la demanda integrada sobre un tiempo de entrega variable. Si no lo tienes, entonces puedes usar Monte Carlo para salir de la situación, sin problema. No es muy difícil. Sabes, con Monte Carlo, muestrearás tu demanda, muestrearás tus tiempos de entrega, y he aquí, lo harás, sin problema. Pero en lugar de tener algo que tome una línea, tomará tiempo, y tendrás un bucle. Así que, si tienes un bucle, significa que puedes tener excepciones de índice fuera de rango, puedes tener excepciones de desbordamiento en uno, y tienes todo tipo de problemas. Nuevamente, puedes solucionarlo haciendo pair programming, test unitarios, y demás, pero eso añade código.

Mi punto era, y realmente te sigo, creo que aquí, ves, esa era la idea que mencionabas. Tienen un equipo de data science. El objetivo es desplazar la solución, y estoy completamente de acuerdo contigo: se trata de desplazar la solución de “ajusto un número” a “ajusto un trozo de código”. Y creo que es exactamente, creo que aquí en ese aspecto, estamos algo alineados. Si esencialmente trasladamos la intervención humana de “ajusto un número y escojo a dedo una constante en mi sistema y lo ajusto” a “vale, voy a tratar con el código y repensar un poco cuál es la intención y hacer este ajuste”, entonces puedo aprobarlo y eso funciona.

Mi punto era desplazar la solución de ajustar un número a ajustar un trozo de código. Si trasladamos la intervención humana de ajustar un número a lidiar con el código y repensar un poco cuál es la intención y hacer este ajuste, entonces puedo aprobarlo y eso funciona.

Y de hecho, si volvemos al desperdicio de tiempo, lo interesante es que cuando ajustas el código, sí, toma mucho más tiempo cambiar una línea de código. Puede que tome una hora, mientras que cambiar un número toma como un minuto. Pero esa hora se va a aplicar a toda la empresa. Sabes, cuando se hace al nivel correcto, es que tienes esa hora de codificación que te brinda un beneficio a nivel de toda la empresa, en contraposición a ese minuto en un SKU que quizás te brinde un beneficio, pero solo para el SKU.

Conor Doherty: Entonces, ¿estás hablando de la diferencia entre ajustar manualmente un resultado, lo que el forecast dijo, versus ajustar la receta numérica que produce el forecast?

Joannes Vermorel: Exactamente, hay una información en este mundo, la premisa básica creo que es que hay una información que está en las noticias o tal vez es información privada a la que tienes acceso a través de la red de la propia empresa. Así que, tienes una pieza extra de información que no está en el modelo, que no está en los datos históricos.

Así que estoy de acuerdo con la afirmación, y estoy de acuerdo con la idea de que sí, aún no tenemos superinteligencia, inteligencia general todavía. No podemos tener a ChatGPT simplemente, ya sabes, procesando todo el correo electrónico de la empresa y haciendo eso por nosotros. Entonces, no tenemos ese grado de inteligencia disponible. Así que deben ser las mentes humanas las que realicen este proceso de selección. Y coincido en que hay valor en tener personas que piensen críticamente sobre esta información y traten de reflejarla con exactitud en la supply chain.

Y realmente sigo a Nikos en el sentido de que él dice, y luego data science, porque sí, en última instancia, debería ser el rol del equipo de data science cada día de decir: tengo un modelo. ¿Es realmente fiel a la intención estratégica de mi empresa? Lo cual es una pregunta de muy alto nivel: ¿reflejo genuinamente la estrategia tal como la expresa quien elabora la estrategia en la empresa? Lo cual es un problema cualitativo, no cuantitativo.

Nikos Kourentzes: Permítanme agregar algo aquí porque creo que Joannes dijo algo que es muy útil para que la gente entienda por qué somos críticos de los ajustes tradicionales. Mencionó que no se trata de la predicción puntual, sino de la expresión probabilística de la misma. La gente ajusta predicciones puntuales, lo cual no tiene sentido en términos del inventario. Nos importan las probabilidades de toda la distribución.

Así que, si alguien pudiera hacer eso, tal vez podría realmente lograr algo. Pero nadie lo hace, y sabes, he estado trabajando con estadísticas durante, como dije, la mayor parte de 20 años. No puedo hacerlo fácilmente. Y sabes, mi incapacidad no significa que otras personas no puedan hacerlo, pero lo que estoy diciendo es que cuando piensas en sentido probabilístico, la información está tan abstraída que es muy difícil que alguien vaya manualmente y diga, sí, solo ajústalo por 10 unidades. Ese es un proceso muy difícil. Así que, en cierto sentido, muchas personas hacen todos estos ajustes sobre la cantidad equivocada de todas maneras.

Joannes Vermorel: Estoy completamente de acuerdo. Cuando dije que en Lokad dejamos de hacer ajustes hace una década, fue exactamente en el momento en que adoptamos un enfoque probabilístico. La gente decía que necesitábamos hacer ajustes, y entonces les mostrábamos los histogramas de la distribución de probabilidad.

Diríamos, “adelante, inténtalo”, y luego la gente se detenía y decía, “no, no vamos a hacer eso”. De hecho, era un mecanismo para evitar que las personas interfirieran en el nivel equivocado. Cuando se les mostraban las distribuciones de probabilidad, se daban cuenta de que hay mucha profundidad. Quiero decir, la gente solía pensar en esas distribuciones de paridad para una supply chain como curvas de campana suaves, ya sabes, gaussianas y demás. Este no es el caso.

Por ejemplo, supongamos que tienes una tienda de bricolaje (DIY). La gente compraría ciertos productos solo en múltiplos de cuatro o ocho o 12, porque hay una cierta lógica en ello. Entonces, tu histograma no es como una curva de campana, tiene picos donde la gente compra uno porque necesita uno de repuesto, o compra cuatro u ocho y nada intermedio. Así que, cuando empiezas a pensar, “vale, ¿debería mover el promedio de 2.5 a 3.5?”, pero miras el histograma, y el histograma tiene como tres picos: una unidad, cuatro unidades, ocho unidades.

De repente, la gente dice, realmente no tiene sentido que intente mover esas cosas. No voy a cambiar la probabilidad que actualmente está asignada de cuatro a cinco porque no va a suceder. Lo que probablemente querría, si quiero aumentar la media, es disminuir la probabilidad de cero y aumentar la probabilidad de todas las otras ocurrencias.

La gente se da cuenta de que hay mucha profundidad en esas distribuciones de probabilidad. Hay muchas trampas, por mencionar esos múltiplos mágicos que existen. Esa fue nuestra observación. Estamos completamente de acuerdo en que, cuando la gente ve esas distribuciones de probabilidad, se da cuenta de que no van a ajustar manualmente este histograma cubo por cubo. Así que esa reacción de impracticidad es real.

Conor Doherty: Bueno, nuevamente, soy consciente de que hemos tomado bastante de tu tiempo, Nikos. Pero tengo una última pregunta. Trabajas en un laboratorio de inteligencia artificial, y parecería negligente no preguntarte cómo podría encajar la IA en todo el contexto de lo que estamos hablando de aquí en adelante. Así que, ya sea esa automatización del forecast o la congruencia con la IA haciendo las sustituciones, no sé, por favor esboza lo que ves como el futuro allí.

Nikos Kourentzes: Esa es una pregunta de un millón de dólares. Puedo responder de la misma manera que uno de los revisores que revisó el artículo tenía algunas preocupaciones. La pregunta era algo así como: “Bien, ¿y qué? Sabes, aquí hay otra métrica, ¿y qué?”

Y yo decía, “Mira, si tienes un modelo estadístico que es bastante sencillo, puedes resolverlo a través de los cálculos, puedes encontrar todo analíticamente, bien. Cuando empiezas a entrar en el machine learning y especialmente con los modelos masivos de IA que estamos usando ahora, esta es una tarea muy difícil. Así que es de gran ayuda si tenemos alguna vara de medir, algo por el estilo, que realmente pueda simplificar un poco descubrir lo que estos modelos están haciendo.”

Si, por ejemplo, tengo un modelo masivo de IA y podemos decir, “mira, este empuja el forecast hacia una mayor congruencia”, entonces podría tener una manera de considerar este modelo de forma más sencilla. Esa forma más sencilla no consiste en reducir la complejidad del modelo de ningún modo, sino en entender cómo afecta esto a mi inventario, cómo afecta a mi proceso de toma de decisiones, cómo afecta a mi supuesto del efecto látigo mencionado anteriormente, en un proceso continuo.

Esto es esencialmente cómo terminamos en realidad el documento de trabajo. Estamos diciendo que el beneficio de esta métrica es entender cómo se pueden comportar los modelos que son cajas negras. No creo que en el futuro veamos modelos que de alguna manera no estén inspirados en la IA. Soy un poco escéptico cuando la gente quiere reemplazar todo con IA, porque algunas cosas pueden ser simplemente más sencillas, más eficientes. Mi preocupación no proviene necesariamente de las matemáticas del problema o incluso de la riqueza de datos, etc. Creo que estos son problemas que podemos resolver. Mi preocupación viene más de un aspecto muy simple del proceso y de la sostenibilidad del tema.

Si tengo un modelo masivo de IA en funcionamiento que eventualmente, una vez que empiece a escalar todo a ese modelo, comience a consumir mucha computación en la nube y mucha electricidad, ¿necesito hacer todo eso si voy a tener solo una diferencia del 1% respecto a un exponential smoothing? A veces tendré mucho más de un 1% de diferencia, hazlo. Pero otras veces no necesito toda esta complicación. Puedo optar por algo más sencillo que también sea más transparente para los no expertos en IA.

La IA es un camino a seguir para muchos de los problemas que tenemos. Creo que en muchos casos los desafíos del forecast que enfrentamos y, especialmente, las decisiones que respaldamos con esos forecasts son un muy buen terreno para las aplicaciones de IA. Pero eso no significa que, de golpe, olvidemos todo lo que sabíamos y nos lancemos a la IA. Eso se refleja un poco también en el artículo. Porque, como mencioné antes, no es el primer artículo que dice, “Oh, modifiquemos un poco el objetivo para que no sea solo la precisión.” Otros colegas también lo han hecho. La diferencia es que nosotros estamos tratando de hacer un poco el álgebra para mostrar, “Bueno, esto es realmente lo que está sucediendo una vez que hacemos eso.” Así que me gusta cuando somos capaces de hacer este tipo de interpretación o de obtener la intuición de esta acción.

La IA es un camino a seguir para muchas cuestiones, pero no debemos olvidar que es útil para nosotros entender qué demonios estamos haciendo. No debemos confiar ciegamente y decir que, de alguna manera, el modelo de IA hará lo que espero que haga. No estoy sugiriendo que los modelos de IA no puedan hacer cosas realmente buenas. Solo digo, “No lo dejemos al azar o a la esperanza de que funcione. Debería ser mejor de lo que simplemente espero.”

Conor Doherty: ¿Qué opinas al respecto?

Joannes Vermorel: Creo que Nikos está absolutamente en lo cierto. Tal como decía, para los ajustes, la cantidad de líneas de código debe ser considerada. La sobrecarga de los modelos de deep learning es absolutamente enorme y complica todo. Pocas personas se dan cuenta de que, para muchas tarjetas GPU, ni siquiera está claro cómo hacer que los cálculos sean deterministas. Hay muchas situaciones donde, literalmente, ejecutas el cómputo dos veces y obtienes dos números diferentes porque el hardware en sí no es determinista.

¿Eso significa que terminas obteniendo los Heisenbugs? Sabes, los Heisenbugs son cuando tienes un error, intentas reproducirlo y desaparece. Así que, en algún momento, dejas de perseguirlo porque dices, “Bueno, estoy tratando de reproducir el caso, no sucede, así que supongo que funciona.” Y luego lo vuelves a poner en producción, y el error vuelve a ocurrir, y no puedes reproducirlo.

Así que estoy completamente de acuerdo. La simplicidad hace que todo sea mejor, cuando está remotamente en la misma liga de rendimiento. Si tienes algo que es masivamente más sencillo, lo simple gana siempre en la práctica. Nunca he visto una situación en la que un modelo que supera por unos pocos puntos porcentuales a otro modelo, según cualquier métrica, supere en el mundo real.

Es una alternativa si la alternativa es de una magnitud de orden más simple para obtener el mismo resultado en la misma liga, incluso si la métrica es esos supuestos dólares o euros que Lokad trató de optimizar. La razón es un poco extraña, pero es que las supply chains cambian, como mencionábamos, por la intervención humana.

Cuando quieres intervenir para cambiar, el tiempo es esencial. Si tienes un programa, un modelo complejo, miles de líneas, significa que solo la logística, por ejemplo, hace algunos años en Lokad, tuvimos docenas de clientes afectados por el Evergreen, el barco que bloqueó el Canal de Suez. Esencialmente, teníamos 24 horas para ajustar todos los tiempos de entrega para prácticamente todos nuestros clientes europeos que importan desde Asia.

Ahí es donde poder responder en cuestión de horas, en lugar de necesitar una semana solo porque mi modelo es muy complicado, resulta crucial. Si quieres que te entregue la solución sin introducir tantos errores en el proceso que simplemente socaven lo que hago, necesitas un modelo más sencillo. Estoy completamente de acuerdo en que hay valor y costo. Para aquellas empresas que han comenzado a jugar con GPT4, el costo es muy elevado.

Conor Doherty: Bueno, Nikos, no tengo más preguntas, pero es costumbre dar la palabra final al invitado. Así que, por favor, ¿algún llamado a la acción o algo que te gustaría compartir con los espectadores?

Nikos Kourentzes: Mi llamado a la acción es que debemos avanzar desde las visiones tradicionales del forecast en aislamiento de la toma de decisiones. En el contexto de nuestra discusión, el inventario, etc., tenemos que intentar ver estas cosas de una manera más conjunta.

Soy un académico, otros colegas tendrán otras opiniones, y Lokad también tiene su perspectiva. Creo que hay valor en todas estas perspectivas porque todas apuntan en la misma dirección. Tenemos que dejar atrás lo que hacíamos hace unas décadas, actualizar nuestra manera de pensar, actualizar nuestro software, actualizar nuestros libros de texto. Hay valor en hacer eso. No se trata solo de cambiar nuestro software o lo que sea, de hecho conducirá a decisiones diferentes.

Invito a la inclusión en el campo del forecast de muchas personas provenientes de Ciencias de la Computación, deep learning, programación y del área de inventario, porque ahora es el momento en el que realmente podemos abordar estos problemas en serio. No quiero dar la impresión de que esto le reste algo al valor del mundo del forecast como campo de investigación. Pertenezco a ese mundo, por lo que también me gustaría decir que no podemos simplemente obtener un montón de bibliotecas, ejecutar algunos códigos y decir que está bien.

Muchas veces, cuando trabajo con la industria o institutos, el valor radica en conseguir el proceso adecuado, abordando la metodología incorrecta, que es todo lo que el campo del forecast puede ofrecer. Me gusta la idea de mantener los pasos en el proceso, pero tenemos que trabajar juntos para idear una solución conjunta. Es un buen espacio.

Volviendo al inicio mismo de la pregunta, donde dije que disfruto trabajar con el equipo de la universidad. Hay polifonía, hay muchas ideas. Plantearé mi pregunta de forecast y otras personas dirán, “¿Qué hay de esto? ¿Has considerado esta perspectiva?” Y yo diré, “Mira esto, nunca había pensado en eso.”

Conor Doherty: Gracias, Nikos. No tengo más preguntas. Joannes, gracias por tu tiempo. Y de nuevo, Nikos, muchas gracias por acompañarnos y muchas gracias a todos por vernos. Nos vemos la próxima vez.