Una revisión parcializada de Deep Inventory Management

Joannes Vermorel

A finales de 2022, un equipo de Amazon publicó una investigación relacionada con la cadena de suministro titulada Deep Inventory Management¹. Este artículo presenta una técnica de optimización de inventario (llamada DIM a continuación) que combina el aprendizaje por refuerzo y el deep learning. El artículo afirma que la técnica se ha utilizado con éxito en más de 10,000 SKUs en entornos del mundo real. Este artículo es interesante desde varios puntos de vista y es algo similar a lo que Lokad ha estado haciendo desde 2018. A continuación, discuto lo que considero los méritos y deméritos de la técnica DIM desde el punto de vista específico de Lokad, ya que hemos explorado vías similares en los últimos años.

La Función Objetivo y las Restricciones (p.27, Apéndice A), de "Deep Inventory Management", Nov. 2022

Mi primera observación es que este artículo es convincente y, por lo tanto, tiendo a respaldar sus conclusiones. La configuración general resuena bastante con mis propios experimentos y observaciones. De hecho, la mayoría de los artículos publicados sobre la cadena de suministro son simplemente falsos, por una razón u otra. Las cadenas de suministro enfrentan un caso bastante grave de corrupción epistémica,² y el escepticismo profundo debería ser la posición predeterminada cuando se enfrenta a cualquier supuesta forma “mejor” de abordar un problema de cadena de suministro.

La contribución más notable de la técnica DIM es evitar por completo la etapa de pronóstico y pasar directamente a la optimización del inventario. La forma clásica de abordar la optimización del inventario consiste en descomponer el problema en dos etapas. Primero, pronosticar la demanda; segundo, optimizar la decisión de inventario. Lokad todavía sigue este proceso escalonado (por buenas razones, ver el action reward ³). Sin embargo, DIM fusiona los dos a través de un enfoque denominado simuladores diferenciables.

Fusionar las etapas de “aprendizaje” y “optimización” es un camino prometedor, no solo para la cadena de suministro, sino también para la informática en general. Durante las últimas dos décadas, ha habido una convergencia gradual entre el aprendizaje y la optimización desde una perspectiva algorítmica. De hecho, la técnica de aprendizaje principal utilizada por Lokad tiene un algoritmo de optimización en su núcleo. Por otro lado, un avance reciente (inédito) de Lokad en la optimización estocástica se centra en un algoritmo de aprendizaje.

Visualizo un futuro en el que el pronóstico independiente se trate como una práctica obsoleta que ha sido completamente reemplazada por nuevas técnicas; aquellas que fusionan por completo las perspectivas de “aprendizaje” y “optimización”. Lokad ya ha estado siguiendo este camino durante algún tiempo. De hecho, desde que nos mudamos a los pronósticos probabilísticos en 2015, exportar los pronósticos brutos de Lokad se considera poco práctico, por lo que en su mayoría se colapsa el proceso a una sola etapa desde la perspectiva del cliente. Sin embargo, el proceso de dos etapas todavía existe dentro de Lokad porque hay algunos problemas profundos y aún no resueltos para que ocurra la unificación.

Ahora, discutamos mis puntos de vista sobre las deficiencias de la técnica DIM.

Mi primera crítica es que el uso del deep learning por parte de DIM es decepcionante.

Desde la sección de Featurización (Apéndice B), queda claro que lo que el modelo “deep” está aprendiendo en primer lugar es predecir la futura demanda de tiempo de entrega - es decir, la demanda variable integrada durante el tiempo de entrega variable.

La estimación (implícitamente probabilística) de la demanda de tiempo de entrega no es un problema “difícil” que requiera deep learning, al menos no en la configuración presentada por este equipo de Amazon. De hecho, apuesto a que toda la mejora empírica es consecuencia de una mejor evaluación de la demanda de tiempo de entrega. Además, también apostaría a que se puede obtener una evaluación comparable, si no mejor, de la demanda de tiempo de entrega con un modelo probabilístico paramétrico básico, como se hizo en la competencia M5⁴. Esto eliminaría por completo el deep learning de la imagen, manteniendo solo la parte de “programación diferenciable” “superficial” de la solución.

Si dejamos de lado la estimación de la demanda de tiempo de entrega, DIM tiene poco que ofrecer. De hecho, en la configuración de la cadena de suministro presentada en el artículo, todos los SKU se procesan en cuasi-aislamiento con restricciones excesivamente suaves en toda la empresa, es decir, límites en el volumen total, el capital total y las unidades totales. Abordar esos límites superiores se puede hacer bastante fácilmente, ordenando las unidades a reordenar⁵ según sus retornos decrecientes de dólar a dólar, o posiblemente sus retornos de dólar por unidad, si la capacidad del almacenamiento caótico utilizado por Amazon es el verdadero cuello de botella.

En cuanto a las restricciones, los límites en toda la empresa son restricciones triviales que no requieren técnicas sofisticadas para abordarlas. El deep learning realmente brillaría si los autores pudieran abordar restricciones complicadas que abundan en las cadenas de suministro. Por ejemplo, las cantidades mínimas de pedido (MOQs) definidas a nivel de proveedor, cargas completas de camiones, descuentos en el precio del proveedor, productos perecederos, etc., son preocupaciones que no se pueden abordar mediante técnicas ingenuas como la priorización que mencioné anteriormente. Para tales restricciones complicadas, el deep learning realmente destacaría como un optimizador estocástico versátil, siempre y cuando alguien logre hacerlo. Sin embargo, DIM evita por completo tales preocupaciones y no está claro en absoluto si DIM se podría ampliar para hacer frente a tales problemas. En mi opinión, no se puede.

Para crédito de los autores, las restricciones entre productos se mencionan en la última línea de su conclusión como una vía emocionante de investigación. Si bien estoy de acuerdo con el sentimiento, es una subestimación. No admitir esas restricciones ubicuas de la cadena de suministro es un obstáculo inmediato. Los profesionales de la cadena de suministro volverían a sus hojas de cálculo en menos de un mes. Aproximadamente correcto es mejor que exactamente incorrecto.

Además, tenemos un gran problema con las acciones de valor real, es decir, cantidades de orden fraccionarias, como las producidas por DIM, ver ecuación (1) y Suposición 1 (página 12). De hecho, en la cadena de suministro, no puedes reordenar 0.123 unidades, es o 0 o 1. Sin embargo, los autores evitan por completo todo el problema. La técnica DIM produce cantidades fraccionarias y requiere que la función de recompensa sea “bien comportada”. En la práctica, está claro que este enfoque no funcionará bien si la función de recompensa no es estrictamente monótona con respecto a la cantidad ordenada.

Por lo tanto, nos encontramos con una característica menos deseable (órdenes fraccionarias) y un requisito menos deseable (monotonía de la función de recompensa), la combinación de ambos es la piedra angular del simulador diferenciable propuesto. Sin embargo, la cadena de suministro está gobernada por la ley de los números pequeños⁶. Los problemas modernos de inventario están dominados por sus características discretas. Como mínimo, los autores deberían haber destacado este aspecto como una limitación grave de DIM, algo que se debería investigar en futuras investigaciones.

Mezclar gradientes y políticas discretas es un problema fundamental para la optimización estocástica, no solo para los simuladores diferenciables propuestos. De hecho, el descenso de gradiente estocástico (SGD) opera en parámetros de valor real y, como tal, no es obvio cómo optimizar políticas que gobiernan decisiones fundamentalmente discretas.

Operar en espacios fundamentalmente discretos a través de procesos impulsados por gradientes ciertamente se puede hacer, como lo demuestran brillantemente los LLM (modelos de lenguaje grandes), pero requiere un conjunto completo de trucos. Hasta que se descubran los trucos equivalentes para la clase de situaciones a las que se enfrentan las cadenas de suministro, los simuladores diferenciables son una idea prometedora, no una opción de producción.

Mi segunda crítica es que hay muchos casos extremos que ni siquiera se mencionan por los autores de DIM.

En particular, los autores siguen siendo sumamente vagos sobre cómo han seleccionado (…seleccionado a dedo) sus 10,000 SKU. De hecho, mientras realizaba experimentos en Lokad en 2018 y 2019, he estado utilizando estrategias de caracterización extrañamente similares (Apéndice B) para modelos de aprendizaje profundo utilizados por Lokad.

A partir de esos experimentos, propongo que:

• Los productos nuevos y recientes no funcionarán bien, ya que la reescala insinuada por las ecuaciones (13), (30) y (31) se comportará de manera errática cuando los datos históricos sean demasiado escasos.
• Los productos de movimiento lento tropezarán con remedios inadecuados de sus pasados faltantes de stock, ya que la técnica asume que existe una demanda corregida “razonable” (lo cual no es el caso para los productos de movimiento lento).
• Los productos intermitentes (no publicados o no disponibles durante largos períodos, como 2+ meses) también tropezarán con la demanda supuestamente corregida.
• Los SKU de los competidores, donde los clientes eligen agresivamente el precio más bajo, serán subestimados, ya que el modelo no puede reflejar el impacto drástico cuando los SKU superan (en términos de precio) a un competidor.

Esos casos extremos son, de hecho, la mayoría del desafío de la cadena de suministro. En un artículo, es tentador seleccionar a dedo SKU que se comporten bien: no demasiado recientes, no demasiado lentos, no demasiado erráticos, no intermitentes, etc. Sin embargo, si tenemos que recurrir a técnicas sofisticadas, es un tanto inútil centrarse en los SKU fáciles. Si bien se pueden lograr mejoras económicas en esos SKU, la ganancia absoluta es menor (modesta en el mejor de los casos), precisamente porque esos SKU se comportan bien de todos modos. La mayoría de las ineficiencias de la cadena de suministro se encuentran en los extremos, no en el medio.

Abordar frontalmente esos SKU problemáticos es precisamente donde se esperaría que el deep learning viniera al rescate. Lamentablemente, DIM hace lo contrario y aborda los SKU que se comportan bien y que se pueden abordar con técnicas mucho menos sofisticadas y con poco o ningún inconveniente.

Mi tercera crítica es que DIM tiene una configuración técnica algo complicada.

Este es probablemente uno de los problemas más subestimados en la comunidad de ciencia de datos. La complejidad es enemiga de la confiabilidad y la eficiencia. Si bien el deep learning es fantástico, pocas empresas pueden permitirse los ingenieros necesarios para operar una configuración como DIM. Esto no es como ChatGPT, donde todas las travesuras de ingeniería se mutualizan en toda la base de clientes del proveedor de software. Aquí, considerando la cantidad de detalles que se incluyen en DIM, cada empresa cliente tiene que asumir los costos operativos completos asociados con su propia instancia de la solución.

En el lado del hardware, tenemos una máquina virtual EC2 p3.16xlarge[^términos-sencillos], actualmente con un precio de 17,000 USD / mes en AWS. Para 10,000 SKU, eso es… elevado.

Lokad tiene muchos clientes que operan individualmente millones de SKU, y la mayoría de ellos tienen menos de 1 mil millones de USD en facturación. Si bien podría ser posible reducir un poco el tamaño de esta máquina virtual y apagarla cuando no se use, en Lokad hemos aprendido que esas opciones rara vez califican para producción.

Por ejemplo, las plataformas de computación en la nube también enfrentan escasez: a veces, la máquina virtual que se suponía que estaría disponible bajo demanda tarda horas en estar en línea. Además, nunca asuma que esos modelos simplemente se pueden “preentrenar”, habrá un día, como el próximo martes, en el que todo el sistema tenga que volver a entrenarse desde cero por razones imperativas[^urgencia]. Además, una configuración de calidad de producción no solo requiere redundancia, sino también entornos adicionales (pruebas, preproducción, etc.).

En el lado del software, la necesidad de algo como el Plasma Object Store es el arquetipo de esas complicaciones accidentales que vienen con el deep learning. Consideremos que el conjunto de datos de entrenamiento - con 80,000 SKU agregados semanalmente durante solo 104 semanas - debería pesar menos de 100MB (si los datos están representados de manera razonable).

Si bien los autores de DIM siguen siendo vagos y se refieren a una “gran cantidad de datos” (página 32), es obvio que la estrategia de caracterización infla la huella de datos original en 3 órdenes de magnitud (1000 veces, más o menos). Tenga en cuenta que el EC2 p3.16xlarge cuenta con nada menos que 488 GB de RAM, que debería ser suficiente para procesar un conjunto de datos de 100 MB (aproximadamente 100 GB después de aplicar la inflación)… Bueno, hemos estado allí, hemos hecho eso y nos hemos enfrentado al mismo problema.

Por ejemplo, un conjunto de datos de cadena de suministro de tamaño realista generalmente superaría 1 terabyte después de la inflación de datos, como se requiere en el enfoque DIM. En este caso, un científico de datos típico no puede reproducir un error localmente porque su estación de trabajo solo tiene 64 GB de RAM. Además de eso, también está el tema de la frontera entre Python/Plasma donde las cosas pueden salir mal.

Más allá de las críticas principales mencionadas anteriormente, existen preocupaciones secundarias. Por ejemplo, la programación dinámica⁷ - mencionada en la introducción y conclusión como la línea de base y competidora de DIM - es simplemente una línea de base deficiente. La programación dinámica es una técnica antigua (de la década de 1950) y no refleja el estado del arte en lo que respecta a la optimización y el aprendizaje combinados.

Es cierto que la literatura de la cadena de suministro carece en este aspecto, pero eso significa que los autores tienen que encontrar líneas de base relevantes fuera de su(s) campo(s) de estudio. Por ejemplo, AlphaGo Zero⁸ es una línea de base intelectual mucho mejor cuando se trata de una aplicación notable del aprendizaje profundo con fines de optimización, especialmente en comparación con técnicas de programación dinámica que tienen casi 80 años de antigüedad.

En conclusión, a diferencia de lo que mi crítica podría sugerir, es un artículo mejor que la mayoría y absolutamente digno de ser criticado. La programación diferenciable es un gran instrumento para las cadenas de suministro. Lokad lo ha estado utilizando durante años, pero no hemos agotado lo que se puede hacer con este paradigma programático.

Hay más por explorar, como demuestra DIM. Los simuladores diferenciables son una idea genial, y se siente menos solitario cuando gigantes tecnológicos como Amazon desafían los dogmas fundamentales de la teoría de la cadena de suministro convencional, al igual que nosotros. En Lokad, tenemos el proyecto de combinar de alguna manera montecarlo y autodiff⁹ de manera que se ajusten perfectamente a esos simuladores diferenciables.

¡Manténganse al tanto!