Una reseña con opinión sobre Deep Inventory Management

Joannes Vermorel

A finales de 2022, un equipo de Amazon publicó una investigación relacionada con supply chain titulada Deep Inventory Management¹. Este artículo presenta una técnica de optimización de inventario (denominada DIM en lo que sigue) que cuenta tanto con reinforcement learning como con deep learning. El artículo afirma que la técnica ha sido utilizada con éxito para más de 10,000 SKUs en entornos reales. Este artículo es interesante en múltiples aspectos y es algo similar a lo que Lokad ha estado haciendo desde 2018. En lo que sigue, 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 exploramos avenidas similares en los últimos años.

La función objetivo y restricciones (p.27, Apéndice A), de "Deep Inventory Management", nov. 2022

Mi primera observación es que este artículo resulta veraz, y por lo tanto me inclino a apoyar sus hallazgos. La configuración general resuena fuertemente con mis propios experimentos y observaciones. De hecho, la mayoría de los artículos publicados sobre supply chain son simplemente falsos - por una razón u otra. Las supply chain enfrentan un caso bastante severo de corrupción epistémica,² y se debería adoptar una postura de escepticismo profundo ante cualquier supuesto método “mejor” para abordar un problema de supply chain.

La contribución más notable de la técnica DIM es eludir por completo la etapa de forecast y pasar directamente a la optimización de inventario. La manera clásica de abordar la optimización de inventario consiste en descomponer el problema en dos etapas. Primero, forecast de la demanda; segundo, optimizar la decisión de inventario. Lokad aún sigue este proceso en etapas (por buenas razones, véase el action reward ³). Sin embargo, DIM fusiona ambos a través de un enfoque denominado differentiable simulators.

Fusionar las etapas de “learning” y “optimization” es un camino prometedor, no solo para supply chain, sino para la informática en su conjunto. Durante las últimas dos décadas, ha habido una convergencia gradual entre learning y optimization desde una perspectiva algorítmica. De hecho, la principal técnica de learning utilizada por Lokad tiene un algoritmo de optimization en su núcleo. Por el contrario, un reciente avance (no publicado) de Lokad sobre optimización estocástica se centra en un algoritmo de learning.

Visualizo un futuro donde el forecast como actividad independiente se trate como una práctica obsoleta, completamente sustituida por nuevas técnicas; técnicas que fusionan por completo las perspectivas de “learning” y “optimization”. Lokad ya ha estado transitando ese camino desde hace algún tiempo. De hecho, desde que nos pasamos a probabilistic forecasts en 2015, exportar los forecast sin procesar de Lokad se ha considerado impráctico, colapsando así el proceso mayormente a una sola etapa desde la perspectiva del cliente. Sin embargo, el proceso de dos etapas sigue existiendo dentro de Lokad porque aún hay algunos problemas profundos, todavía sin resolver, para que se produzca 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 de deep learning por parte de DIM es poco impresionante.

Desde la sección de Featurization (Apéndice B), está claro que lo que el modelo “deep” está aprendiendo, ante todo, es predecir el lead demand futuro - es decir, la demanda variable integrada en el lead time variable.

La estimación (implícitamente probabilística) del lead demand no es un problema “difícil” que requiera deep learning, al menos no en los contextos presentados por este equipo de Amazon. De hecho, apuesto a que toda la mejora empírica es consecuencia de una mejor evaluación del lead demand. Además, también apostaría a que se puede obtener una evaluación comparable, si no mejor, del lead demand 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 ecuación, conservando únicamente la parte “shallow” de differentiable programming de la solución.

Si dejamos de lado la estimación del lead demand, DIM tiene poco que ofrecer. De hecho, en los contextos de supply chain presentados en el artículo, todos los SKUs son procesados en cuasi-aislamiento con restricciones generales excesivamente leves - es decir, límites en el volumen total, el capital total y las unidades totales. Abordar esos límites superiores se puede hacer con bastante facilidad, ordenando las unidades a reordenar⁵ por sus retornos decrecientes dollar-on-dollar - o posiblemente sus retornos dollar-on-unit - si la capacidad del almacenamiento caótico utilizado por Amazon es el verdadero cuello de botella.

En cuanto a las restricciones, los límites a nivel de empresa son restricciones triviales que no requieren técnicas sofisticadas para abordarlas. Deep learning realmente brillaría si los autores pudieran enfrentar restricciones complejas que abundan en supply chains. Por ejemplo, MOQs (cantidades mínimas de pedido) definidas a nivel de proveedor, cargas completas de truck (camiones), descuentos por volumen de proveedor, productos perishable y otros, son inquietudes que no pueden ser abordadas mediante una técnica ingenua como la priorización que mencioné anteriormente. Para tales restricciones complejas, deep learning realmente sobresaldría como un optimizador estocástico versátil – siempre que alguien logre hacerlo. Sin embargo, DIM elude por completo tales preocupaciones y no está claro si DIM podría extenderse para afrontar tales problemas. Mi opinión es que no puede.

Para crédito de los autores, se mencionan las cross-product constraints en la última línea de su conclusión como una exciting avenue of research. Aunque estoy de acuerdo con el sentimiento, es una afirmación moderada. No apoyar esas omnipresentes restricciones de supply chain es un obstáculo inmediato. Los profesionales de supply chain volverían a sus hojas de cálculo en menos de un mes. Aproximadamente correcto es mejor que exactamente equivocado.

Además, tenemos todo un lío con las acciones en valores reales, es decir, cantidades de pedido fraccionales, tal como produce DIM – véase la ecuación (1) y la Suposición 1 (página 12). De hecho, en supply chain, no se puede reordenar 0.123 unidades, es o 0 o 1. Sin embargo, los autores eluden todo el asunto. La técnica DIM genera cantidades fraccionales y requiere que la función de recompensa se comporte de manera “adecuada”. En la práctica, es claro que este enfoque no funcionará bien si la función de recompensa no es estrictamente monótona con respecto a la cantidad ordenada.

Así, nos quedamos con una característica poco deseable (órdenes fraccionales) y un requisito poco deseable (monotonía de la función de recompensa), siendo la combinación de ambos la piedra angular del simulador diferenciable propuesto. Sin embargo, supply chain se rige por la ley de los números pequeños⁶. Los problemas modernos de inventario están dominado por sus características discretas. Al menos, este aspecto debería haber sido destacado por los autores como una limitación severa de DIM - algo que debe ser investigado en estudios subsiguientes.

La combinación de 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 del gradiente estocástico (SGD) opera sobre parámetros en valores reales y, en consecuencia, no es obvio cómo optimizar políticas que rigen decisiones fundamentalmente discretas.

Operar en espacios fundamentalmente discretos mediante procesos basados en gradientes ciertamente se puede hacer, como lo demuestran de manera brillante los LLMs (large language models), pero se requiere un conjunto completo de técnicas. Hasta que se descubran técnicas equivalentes para la clase de situaciones que enfrentan las supply chains, los simuladores diferenciables son una idea prometedora, pero no una opción a nivel de producción.

Mi segunda crítica es que hay montones de casos atípicos que ni siquiera son mencionados por los autores de DIM.

En particular, los autores se muestran eminentemente vagos respecto a cómo han seleccionado (…elegido a dedo) sus 10,000 SKUs. De hecho, mientras realizaba experimentos en Lokad en 2018 y 2019, he utilizado estrategias de featurization sorprendentemente similares (Apéndice B) para los modelos de deep learning utilizados por Lokad.

De esos experimentos, propongo que:

• Los productos nuevos y recientes no funcionarán bien, ya que el reescalado insinuado por las ecuaciones (13), (30) y (31) se comportará de manera errática cuando los datos históricos sean demasiado escasos.
• Los productos de baja rotación se encontrarán con correcciones inapropiadas de sus pasados faltante de stock, ya que la técnica asume que existe una demanda corregida “razonable” (lo cual no ocurre en el caso de los productos de baja rotación).
• Los productos intermitentes (no publicados o no disponibles durante períodos prolongados, como más de 2 meses) también tropezarán con la supuesta demanda corregida.
• Los SKUs de la competencia, 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 un SKU supera (en precio) a un competidor.

Esos casos atípicos constituyen, de hecho, la mayor parte del reto en supply chain. En un artículo, resulta tentador seleccionar a dedo los SKUs que se comportan bien: no demasiado nuevos, ni demasiado lentos, no tan erráticos, no intermitentes, etc. Sin embargo, si tenemos que recurrir a técnicas sofisticadas, es un tanto irrelevante centrarse en los SKUs fáciles. Aunque se puedan lograr mejoras económicas en esos SKUs, la ganancia absoluta es mínima (modesta en el mejor de los casos) –precisamente porque esos SKUs se comportan bien de todos modos. La mayor parte de las ineficiencias de supply chain radica en los extremos, no en el centro.

Abordar frontalmente esos SKUs mal comportados es exactamente donde se esperaría que deep learning acudiera al rescate. Lamentablemente, DIM hace lo contrario y aborda los SKUs que se comportan bien, los cuales se pueden tratar con técnicas mucho menos sofisticadas, con poco o ningún inconveniente.

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

Este es probablemente uno de los problemas menos valorados en la comunidad de data science. La complejidad es el enemigo de la fiabilidad y la eficiencia. Aunque deep learning es fantástico, pocas empresas pueden permitirse los ingenieros necesarios para operar una configuración como la de DIM. Esto no es como ChatGPT, donde todas las artimañas de ingeniería se mutualizan entre toda la base de clientes del proveedor de software. Aquí, considerando la cantidad de especificidades que conlleva DIM, cada empresa cliente tiene que asumir los costos operativos completos asociados a su propia instancia de la solución.

En el lado del hardware, contamos con una máquina virtual EC2 p3.16xlarge⁷, actualmente valorada en 17k USD / mes en AWS. Para 10,000 SKUs, eso es… elevado.

Lokad tiene muchos clientes que operan individualmente millones de SKUs, y la mayoría de ellos tienen una facturación inferior a 1 mil millones de USD. Aunque podría ser posible reducir un poco esta VM y apagarla cuando no se use, en Lokad hemos aprendido que esas opciones rara vez son viables para producción.

Por ejemplo, las plataformas de computación en la nube se enfrentan a sus propias carencias: a veces, la VM que se suponía debía estar disponible bajo demanda tarda horas en activarse. Además, nunca asumas que esos modelos pueden simplemente ser “pretrained”, llegará un día -como el próximo martes- en que todo tendrá que ser reentrenado desde cero por razones imperativas⁸. Además, una configuración a nivel 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 deep learning. Consideremos que el training dataset -con 80,000 SKUs agregados semanalmente durante apenas 104 semanas- debería pesar menos de 100MB (si los datos se representan de forma sensata).

Aunque los autores de DIM se muestran hábilmente vagos, refiriéndose a una “gran cantidad de datos” (página 32), es obvio que la estrategia de featurization inflaciona la huella de los datos originales en 3 órdenes de magnitud (alrededor de 1000 veces). Tengan en cuenta que la EC2 p3.16xlarge cuenta con nada menos que 488 GB de RAM, lo cual debería ser suficiente para procesar un dataset de 100MB (aproximadamente 100 GB después de aplicada la inflación)… Bueno, ya he estado allí, lo he hecho y he enfrentado el mismo problema.

Por ejemplo, un dataset de supply chain de tamaño realista usualmente excedería 1 terabyte después de la inflación de datos - como lo requiere el enfoque DIM. En este caso, un data scientist típico no puede reproducir un error localmente porque su estación de trabajo solo tiene 64GB de RAM. Además, está la cuestión de la frontera Python/Plasma donde las cosas pueden salir mal.

Más allá de las críticas primarias anteriores, existen preocupaciones secundarias. Por ejemplo, la programación dinámica⁹ - mencionada en la introducción y conclusión como la línea base y competidora de DIM - es simplemente una línea base pobre. La programación dinámica es una técnica antigua (data de la década de 1950) y no refleja el estado del arte en lo que se refiere a la integración de optimization y learning.

Es cierto que la literatura de supply chain es deficiente en este aspecto, pero eso significa que los autores deben encontrar líneas base relevantes fuera de sus campos de estudio. Por ejemplo, AlphaGo Zero¹⁰ es una línea base intelectual mucho mejor cuando se trata de una aplicación notable de deep learning para fines de optimización -ciertamente en comparación con técnicas de programación dinámica que tienen casi 80 años.

En conclusión, contrariamente a lo que mi crítica podría sugerir, es un artículo mejor que la mayoría y absolutamente digno de ser analizado. La differentiable programming es un gran instrumento para supply chains. 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 lo 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 dominante de la supply chain, tal como lo hacemos nosotros. En Lokad, tenemos el proyecto de, de alguna manera, mezclar montecarlo y autodiff¹¹ de formas que encajarían muy bien con esos simuladores diferenciables.

¡Mantente atento!