Une critique opiniâtre de Deep gestion des stocks

Joannes Vermorel

Fin 2022, une équipe d’Amazon a publié une recherche liée à la supply chain intitulée Deep gestion des stocks¹. Cet article présente une technique d’optimisation de stocks (désignée par DIM ci-après) qui combine à la fois le reinforcement learning et le deep learning. L’article affirme que la technique a été utilisée avec succès sur 10 000 SKUs dans des conditions réelles. Ce papier est intéressant sur plusieurs plans et ressemble en partie à ce que Lokad réalise depuis 2018. Ci-dessous, je discute des avantages et inconvénients de la technique DIM du point de vue spécifique de Lokad, qui a exploré des approches similaires ces dernières années.

The Objective Function and Constraints (p.27, Appendix A), from "Deep Inventory Management", Nov. 2022

Ma première observation est que cet article paraît crédible, et je suis donc enclin à soutenir ses conclusions. L’ensemble de la configuration résonne fortement avec mes propres expériences et observations. En effet, la plupart des articles publiés sur la supply chain sont tout simplement bidons – pour une raison ou une autre. Les supply chains font face à une corruption épistémique assez sévère,² et un scepticisme profond devrait être adopté par défaut lorsqu’on est confronté à une manière soi-disant “meilleure” d’aborder un supply chain problem.

La contribution la plus notable de la technique DIM est de contourner entièrement l’étape de prévision pour passer directement à l’optimisation des stocks. La méthode classique pour aborder l’optimisation des stocks consiste à décomposer le problème en deux étapes. D’abord, prévoir la demande ; ensuite, optimiser la décision relative aux stocks. Lokad suit encore ce processus par étapes (pour de bonnes raisons, voir le action reward ³). Cependant, DIM fusionne les deux grâce à une approche désignée par differentiable simulators.

Fusionner les étapes d’“apprentissage” et d’“optimisation” est une piste prometteuse, non seulement pour la supply chain, mais pour l’informatique en général. Ces deux dernières décennies, il y a eu une convergence progressive entre l’“apprentissage” et l’“optimisation” d’un point de vue algorithmique. En réalité, la principale technique d’“apprentissage” utilisée par Lokad repose sur un algorithme d’“optimisation”. Inversement, une percée récente (non publiée) de Lokad concernant l’optimisation stochastique s’articule autour d’un algorithme d’“apprentissage”.

J’envisage un futur où la prévision autonome sera considérée comme une pratique obsolète, entièrement dépassée par de nouvelles techniques qui fusionnent intégralement les perspectives d’“apprentissage” et d’“optimisation”. Lokad arpente déjà cette voie depuis un certain temps. En fait, depuis notre passage aux probabilistic forecasts en 2015, exporter les prévisions brutes depuis Lokad était jugé impraticable, réduisant ainsi le processus à une approche monophasée du point de vue du client. Cependant, le processus en deux étapes subsiste chez Lokad car certains problèmes profonds, toujours non résolus, empêchent une unification complète.

À présent, abordons les aspects que je considère comme des lacunes de la technique DIM.

Ma première critique est que l’utilisation du deep learning par DIM est décevante.

De la section Featurization (Annexe B), il est clair que le modèle “deep” apprend avant tout à prédire la lead demand future - c’est-à-dire, la demande variable intégrée sur le lead time.

L’estimation (implicitement probabiliste) de la lead demand n’est pas un problème “difficile” nécessitant le deep learning, du moins pas dans les conditions présentées par cette équipe d’Amazon. En fait, j’affirmerais que l’amélioration empirique globale résulte d’une meilleure évaluation de la lead demand. De plus, j’estime qu’une évaluation comparable, voire meilleure, de la lead demand peut être obtenue avec un modèle probabiliste paramétrique de base, comme cela a été fait lors de la compétition M5⁴. Cela éliminerait totalement le deep learning de l’équation, en ne conservant que la partie “shallow” de la solution basée sur differentiable programming.

Si l’on met de côté l’estimation de la lead demand, DIM n’a guère à offrir. En effet, dans les conditions de supply chain présentées dans l’article, tous les SKUs sont traités en quasi-isolation avec des contraintes trop légères appliquées à l’échelle de l’entreprise – à savoir des plafonds sur le volume total, le capital total et le nombre total d’unités. Traiter ces limites supérieures peut se faire assez facilement, en triant les unités à reconstituer⁵ selon leur rendement décroissant en termes de dollars par dollar investi – ou éventuellement leur rendement en dollars par unité – si la capacité du stockage chaotique utilisé par Amazon constitue le véritable goulot d’étranglement.

En ce qui concerne les contraintes, les plafonds appliqués à l’échelle de l’entreprise sont des contraintes triviaux qui ne nécessitent pas de techniques sophistiquées pour être gérés. Le deep learning brillerait vraiment si les auteurs parvenaient à aborder des contraintes épineuses, lesquelles abondent dans les supply chains. Par exemple, les MOQs (quantités minimales de commande) définies au niveau du fournisseur, les chargements complets de truck, les remises de prix fournisseurs, les produits perishable, etc., sont des problématiques qui ne peuvent être résolues par une technique naïve telle que la priorisation mentionnée ci-dessus. Pour de telles contraintes épineuses, le deep learning excellerait en tant qu’optimiseur stochastique polyvalent – à condition que quelqu’un parvienne à y parvenir. Toutefois, DIM contourne entièrement ces préoccupations et il est totalement incertain que DIM puisse être étendu pour y répondre. Mon avis est que ce n’est pas possible.

À leur crédit, les auteurs mentionnent les cross-product constraints dans la toute dernière ligne de leur conclusion comme une voie de recherche passionnante. Bien que je partage ce sentiment, c’est un euphémisme. Ne pas prendre en compte ces contraintes ubiquistes de la supply chain constitue un obstacle immédiat. Les praticiens de la supply chain retourneraient à leurs tableurs en moins d’un mois. Être approximativement correct vaut mieux qu’être exactement faux.

De plus, nous avons tout un paquet de problèmes avec les actions à valeurs réelles, c’est-à-dire les quantités de commande fractionnées, produites par DIM – voir l’équation (1) et l’Assomption 1 (page 12). En effet, dans la supply chain, vous ne pouvez pas reorder 0,123 unités : c’est soit 0, soit 1. Pourtant, les auteurs négligent tout le problème. La technique DIM génère des quantités fractionnées et exige que la fonction de récompense soit “bien comportée”. En pratique, il est évident que cette approche ne fonctionnera pas bien si la fonction de récompense n’est pas strictement monotone par rapport à la quantité commandée.

Ainsi, nous nous retrouvons avec une caractéristique peu désirable (les commandes fractionnées) et une exigence tout aussi peu désirable (la monotonie de la fonction de récompense), la combinaison des deux étant la pierre angulaire du simulateur différentiable proposé. Pourtant, la supply chain est régie par la loi des petits nombres⁶. Les problèmes modernes d’optimisation des stocks sont _dominé_s par leurs caractéristiques discrètes. À tout le moins, cet aspect aurait dû être souligné par les auteurs comme une lourde limitation de DIM – un point à approfondir lors de recherches ultérieures.

Mélanger les gradients et les politiques discrètes est une problématique fondamentale pour l’optimisation stochastique, et pas seulement pour les simulateurs différentiables proposés. En effet, la descente de gradient stochastique (SGD) opère sur des paramètres à valeurs réelles, et, par conséquent, il n’est pas évident d’optimiser des politiques qui régissent des décisions fondamentalement discrètes.

Opérer dans des espaces fondamentalement discrets via des processus guidés par gradients est certes faisable, comme le démontrent brillamment les LLM (large language models), mais cela requiert tout un arsenal de techniques. Jusqu’à ce que des astuces équivalentes soient découvertes pour la classe de situations auxquelles font face les supply chains, les simulateurs différentiables restent une idée prometteuse, sans être une option prête pour la production.

Ma deuxième critique est qu’il existe une multitude de cas particuliers qui ne sont même pas mentionnés par les auteurs de DIM.

En particulier, les auteurs restent extrêmement vagues sur le choix (…sélection biaisée) de leurs 10 000 SKUs. En effet, alors que je menais des expérimentations chez Lokad en 2018 et 2019, j’utilisais des stratégies de featurization (Annexe B) étrangement similaires pour les modèles de deep learning utilisés par Lokad.

D’après ces expérimentations, je propose que :

• Les produits nouveaux et récents ne fonctionneront pas bien, car la rescaling suggérée par les équations (13), (30) et (31) se comportera de manière erratique lorsque les données historiques sont trop maigres.
• Les produits à rotation lente rencontreront d’impropriées remédiations de leurs stock-outs, car la technique suppose qu’une demande corrigée “raisonnable” existe (ce qui n’est pas le cas pour ces produits).
• Les produits intermittents (non publiés ou indisponibles pendant de longues périodes, comme 2+ mois) trébucheront également face à la demande supposément corrigée.
• Les SKUs des concurrents, où les clients choisissent agressivement le prix le plus bas, seront sous-évalués, car le modèle ne peut refléter l’impact drastique lorsque des SKUs surpassent (en termes de prix) ceux d’un concurrent.

Ces cas particuliers représentent en fait l’essentiel du défi en supply chain. Dans un article, il est tentant de sélectionner des SKUs bien comportés : pas trop récents, pas trop lents, ni trop erratiques, ni intermittents, etc. Pourtant, si nous devons recourir à des techniques sophistiquées, se concentrer sur les SKUs “faciles” perd un peu de sa pertinence. Bien que des améliorations économiques puissent être réalisées sur ces SKUs, le gain absolu est minime (modeste au mieux) – précisément parce que ces SKUs se comportent déjà correctement. L’essentiel des inefficacités en supply chain se trouve dans les extrêmes, et non dans le centre.

Aborder frontalement ces SKUs défaillants est exactement là où l’on pourrait s’attendre à ce que le deep learning vienne à la rescousse. Hélas, DIM fait le contraire en s’attaquant aux SKUs bien comportés qui peuvent être traités avec des techniques bien moins sophistiquées, avec peu ou pas d’inconvénients.

Ma troisième critique est que DIM présente une configuration technique quelque peu alambiquée.

Cela constitue probablement l’une des problématiques les moins appréciées dans la communauté data science. La complexité est l’ennemie de la fiabilité et de l’efficacité. Bien que le deep learning soit fantastique, peu d’entreprises peuvent se permettre les ingénieurs nécessaires pour faire fonctionner une configuration telle que DIM. Ce n’est pas comme ChatGPT où toutes les complications d’ingénierie sont mutualisées à l’échelle de toute la base de clients du fournisseur de logiciels. Ici, vu le nombre de spécificités impliquées dans DIM, chaque entreprise cliente doit supporter l’intégralité des coûts d’exploitation liés à sa propre instance de la solution.

Du côté matériel, nous disposons d’une machine virtuelle EC2 p3.16xlarge⁷, actuellement tarifée à 17k USD par mois sur AWS. Pour 10 000 SKUs, c’est… exorbitant.

Lokad compte de nombreux clients qui gèrent individuellement millions of SKUs, et la plupart d’entre eux réalisent un chiffre d’affaires inférieur à 1 milliard USD. Bien qu’il soit peut-être possible de réduire un peu cette VM et de l’éteindre lorsqu’elle n’est pas utilisée, chez Lokad, nous avons appris que ces options se qualifient rarement pour la production.

Par exemple, les plateformes de cloud computing rencontrent leurs propres pénuries : parfois, la VM censée être disponible à la demande met des heures à se lancer. De plus, n’assumez jamais que ces modèles peuvent simplement être “pretrained”, il y aura un jour – comme mardi prochain – où l’ensemble devra être réentraîné à partir de zéro pour des raisons impératives⁸. Par ailleurs, une configuration de niveau production requiert non seulement de la redondance mais aussi des environnements supplémentaires (test, pré-production, etc.).

Du côté logiciel, le besoin de quelque chose comme le Plasma Object Store est l’archétype de ces complications fortuites qui accompagnent le deep learning. Considérons par exemple que le training dataset – avec 80 000 SKUs agrégés chaque semaine sur seulement 104 semaines – devrait peser moins de 100 Mo (si les données sont raisonnablement représentées).

Alors que les auteurs de DIM restent habilement vagues, évoquant une “grande quantité de données” (page 32), il est évident que la stratégie de featurization amplifie l’empreinte de données originale d’environ 3 ordres de grandeur (soit environ 1000 fois). N’oublions pas que l’EC2 p3.16xlarge dispose d’au moins 488 Go de RAM, ce qui devrait suffire pour traiter un dataset de 100 Mo (environ 100 Go après application de l’amplification)… Bref, je connais la chanson, j’ai déjà fait face au même problème.

Par exemple, un dataset de supply chain réalistiquement dimensionné excéderait généralement 1 téraoctet après inflation des données – comme l’exige l’approche DIM. Dans ce cas, un data scientist typique ne peut reproduire un bug localement parce que sa station de travail ne dispose que de 64 Go de RAM. Au-delà, il y a également la question de la frontière Python/Plasma, où tout peut mal tourner.

Au-delà des critiques principales évoquées ci-dessus, il existe des préoccupations secondaires. Par exemple, la programmation dynamique⁹ – mentionnée dans l’introduction et la conclusion comme le baseline et le concurrent de DIM – est tout simplement une médiocre référence de base. La programmation dynamique est une technique ancestrale (datant des années 1950) et ne reflète pas l’état de l’art en matière de fusion entre optimisation et apprentissage.

Il est vrai que la littérature en supply chain est lacunaire sur ce point, mais cela signifie que les auteurs doivent trouver des références pertinentes en dehors de leur(s) domaine(s) d’étude. Par exemple, AlphaGo Zero¹⁰ constitue une bien meilleure référence intellectuelle lorsqu’il s’agit d’une application remarquable du deep learning dans un but d’optimisation – bien sûr, comparé aux techniques de programmation dynamique âgées d’environ 80 ans.

En conclusion, contrairement à ce que pourrait laisser penser ma critique, c’est un meilleur article que la plupart et il mérite amplement d’être critiqué. La differentiable programming est un excellent outil pour les supply chains. Lokad l’utilise depuis des années, mais nous n’avons pas encore épuisé toutes les possibilités offertes par ce paradigme programmatique.

Il y a encore beaucoup à explorer, comme le démontre DIM. Les simulateurs différentiables sont une idée intéressante, et cela semble moins solitaire lorsque des géants de la technologie comme Amazon remettent en cause les dogmes fondamentaux de la théorie de la supply chain grand public – tout comme nous le faisons. Chez Lokad, nous avons le projet de, d’une manière ou d’une autre, combiner montecarlo et autodiff¹¹ de manière à s’adapter parfaitement à ces simulateurs différentiables.

Restez à l’écoute !