Une critique subjective de la gestion des stocks profonde

Joannes Vermorel

Fin 2022, une équipe chez Amazon a publié une recherche liée à la chaîne d’approvisionnement intitulée Deep Inventory Management¹. Cet article présente une technique d’optimisation des stocks (appelée DIM par la suite) qui combine à la fois l’apprentissage par renforcement et l’apprentissage profond. L’article affirme que la technique a été utilisée avec succès sur plus de 10 000 SKUs dans des environnements réels. Cet article est intéressant à plusieurs égards et est assez similaire à ce que Lokad fait depuis 2018. Dans ce qui suit, je discute de ce que je considère comme les mérites et les défauts de la technique DIM du point de vue spécifique de Lokad, car nous avons exploré des voies similaires ces dernières années.

La fonction objectif et les contraintes (p.27, Annexe A), de "Deep Inventory Management", Nov. 2022

Ma première observation est que cet article est crédible et je suis donc enclin à soutenir ses conclusions. La configuration générale résonne fortement avec mes propres expériences et observations. En effet, la plupart des articles publiés sur la chaîne d’approvisionnement sont tout simplement faux - pour une raison ou une autre. Les chaînes d’approvisionnement sont confrontées à un cas assez grave de corruption épistémique,² et le scepticisme profond devrait être la position par défaut lorsqu’on est confronté à une prétendue “meilleure” façon d’aborder un problème de chaîne d’approvisionnement.

La contribution la plus notable de la technique DIM est de contourner complètement l’étape de prévision et de passer directement à l’optimisation des stocks. La manière classique d’aborder l’optimisation des stocks consiste à diviser le problème en deux étapes. Premièrement, prévoir la demande ; deuxièmement, optimiser la décision de stock. Lokad suit toujours ce processus en deux étapes (pour de bonnes raisons, voir l’action reward ³). Cependant, DIM fusionne les deux étapes grâce à une approche appelée simulateurs différentiables.

Fusionner les étapes “apprentissage” et “optimisation” est une voie prometteuse, non seulement pour la chaîne d’approvisionnement, mais aussi pour l’informatique dans son ensemble. Au cours des deux dernières décennies, il y a eu une convergence progressive entre apprentissage et optimisation d’un point de vue algorithmique. En fait, 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 en matière d’optimisation stochastique repose sur un algorithme d’apprentissage.

J’envisage un avenir où la prévision autonome sera considérée comme une pratique obsolète, entièrement remplacée par de nouvelles techniques ; celles qui fusionnent complètement les perspectives de “l’apprentissage” et de “l’optimisation”. Lokad a déjà emprunté ce chemin depuis un certain temps. En fait, depuis que nous sommes passés aux prévisions probabilistes en 2015, exporter les prévisions brutes hors de Lokad a été considéré comme impraticable, ce qui a principalement réduit le processus à une seule étape du point de vue du client. Cependant, le processus en deux étapes existe toujours chez Lokad car il existe encore des problèmes profonds et non résolus pour que l’unification se produise.

Maintenant, discutons de mes points de vue sur les lacunes de la technique DIM.

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

Dans la section Featurization (Annexe B), il est clair que ce que le modèle “deep” apprend en premier lieu est de prédire la future demande principale - c’est-à-dire, la demande variable intégrée sur le temps d’approvisionnement variable.

L’estimation (implicitement probabiliste) de la demande principale n’est pas un problème “difficile” qui nécessite le deep learning, du moins pas dans les paramètres présentés par cette équipe d’Amazon. En fait, je parie que toute l’amélioration empirique est la conséquence d’une meilleure évaluation de la demande principale. De plus, je parie également qu’une évaluation comparable, voire meilleure, de la demande principale peut être obtenue avec un modèle probabiliste paramétrique de base, comme cela a été fait dans la compétition M5⁴. Cela éliminerait complètement le deep learning de l’équation, ne conservant que la partie “peu profonde” de la solution, la programmation différentiable.

Si nous mettons de côté l’estimation de la demande principale, DIM n’a pas grand-chose à offrir. En effet, dans les paramètres de la chaîne d’approvisionnement tels que présentés dans l’article, tous les SKUs sont traités de manière quasi-isolée, avec des contraintes globales de l’entreprise excessivement légères - à savoir des limites sur le volume total, le capital total et les unités totales. Il est assez facile de traiter ces limites supérieures en triant les unités à réapprovisionner⁵ en fonction de leurs rendements décroissants en dollars - ou éventuellement de leurs rendements en dollars par unité - si la capacité du stockage chaotique utilisé par Amazon est le véritable goulot d’étranglement.

En ce qui concerne les contraintes, les limites globales de l’entreprise sont des contraintes triviales qui ne nécessitent pas de techniques sophistiquées pour être traitées. Le deep learning serait vraiment utile si les auteurs étaient capables de traiter des contraintes épineuses qui abondent dans les chaînes d’approvisionnement. Par exemple, les MOQs (quantités minimales de commande) définies au niveau du fournisseur, les chargements complets de camions, les paliers de prix des fournisseurs, les produits périssables, etc., sont des préoccupations qui ne peuvent pas être traitées par une technique naïve comme la priorisation que j’ai mentionnée ci-dessus. Pour de telles contraintes épineuses, le deep learning serait vraiment excellent en tant qu’optimiseur stochastique polyvalent - à condition que quelqu’un réussisse à le faire. Cependant, DIM contourne complètement de telles préoccupations et il n’est pas du tout clair si DIM pourrait être étendu pour faire face à de tels problèmes. À mon avis, ce n’est pas possible.

À leur crédit, les contraintes inter-produits sont mentionnées dans la dernière ligne de leur conclusion comme une piste de recherche passionnante. Bien que je sois d’accord avec ce sentiment, c’est un euphémisme. Ne pas prendre en charge ces contraintes omniprésentes de la chaîne d’approvisionnement est un arrêt immédiat. Les praticiens de la chaîne d’approvisionnement reviendraient à leurs feuilles de calcul en moins d’un mois. Approximativement correct est mieux qu’exactement faux.

De plus, nous avons toute une série de problèmes avec les actions à valeurs réelles, c’est-à-dire les quantités d’ordre fractionnaires, telles que produites par DIM - voir l’équation (1) et l’Hypothèse 1 (page 12). En effet, dans la chaîne d’approvisionnement, vous ne pouvez pas réapprovisionner 0,123 unités, c’est soit 0 soit 1. Pourtant, les auteurs évitent complètement toute la question. La technique DIM produit des quantités fractionnaires et nécessite que la fonction de récompense soit “bien comportée”. En pratique, il est clair 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 moins souhaitable (les commandes fractionnaires) et une exigence moins souhaitable (la monotonie de la fonction de récompense), la combinaison des deux étant la pierre angulaire du simulateur différentiable proposé. Pourtant, la chaîne d’approvisionnement est régie par la loi des petits nombres⁶. Les problèmes d’inventaire modernes sont dominés par leurs caractéristiques discrètes. À tout le moins, cet aspect aurait dû être souligné par les auteurs comme une limitation sévère de DIM - quelque chose à poursuivre dans des recherches ultérieures.

Mélanger les gradients et les politiques discrètes est un problème fondamental pour l’optimisation stochastique, pas seulement pour les simulateurs différentiables proposés. En effet, la descente de gradient stochastique (SGD) fonctionne sur des paramètres à valeurs réelles et, à ce titre, il n’est pas évident d’optimiser les politiques qui régissent des décisions fondamentalement discrètes.

Opérer sur des espaces fondamentalement discrets à travers des processus pilotés par des gradients peut certainement être fait, comme brillamment démontré par les LLM (large language models), mais cela nécessite tout un ensemble de techniques. Jusqu’à ce que les techniques équivalentes soient découvertes pour la classe de situations auxquelles sont confrontées les chaînes d’approvisionnement, les simulateurs différentiables sont une idée prometteuse, mais pas une option de production.

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

En particulier, les auteurs restent éminemment vagues sur la façon dont ils ont sélectionné (…choisi à la carte) leurs 10 000 SKUs. En effet, alors que je menais des expériences chez Lokad en 2018 et 2019, j’ai utilisé des stratégies de caractérisation étrangement similaires (Annexe B) pour les modèles d’apprentissage profond utilisés par Lokad.

À partir de ces expériences, je propose que :

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

Ces cas particuliers sont en fait la majeure partie du défi de la supply chain. Dans un article, il est tentant de sélectionner des SKUs qui se comportent bien : pas trop récents, pas trop lents, pas trop erratiques, pas intermittents, etc. Pourtant, si nous devons recourir à des techniques sophistiquées, il est un peu futile de se concentrer sur les SKUs faciles. Bien que des améliorations économiques puissent être réalisées sur ces SKUs, le gain absolu est mineur (au mieux modeste) - précisément parce que ces SKUs se comportent déjà bien. La majeure partie des inefficacités de la supply chain se trouve dans les extrêmes, pas dans le milieu.

S’attaquer frontalement à ces SKUs mal comportés est précisément là où le deep learning devrait venir à la rescousse. Hélas, DIM fait l’inverse et s’attaque aux SKUs bien comportés qui peuvent être abordés avec des techniques beaucoup moins sophistiquées avec peu ou pas d’inconvénients.

Ma troisième critique est que DIM a une configuration technique quelque peu complexe.

C’est probablement l’un des problèmes les plus sous-estimés dans la communauté de la science des données. 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 d’avoir les ingénieurs nécessaires pour exploiter une configuration comme DIM. Ce n’est pas comme ChatGPT où toutes les astuces d’ingénierie sont mutualisées entre l’ensemble de la base de clients de l’éditeur de logiciels. Ici, compte tenu de la quantité de spécificités qui entrent dans DIM, chaque entreprise cliente doit supporter les coûts d’exploitation complets associés à leur propre instance de la solution.

Du côté matériel, nous avons une machine virtuelle EC2 p3.16xlarge[^termes-simples], actuellement au prix de 17 000 USD par mois sur AWS. Pour 10 000 SKUs, c’est… élevé.

Lokad a de nombreux clients qui exploitent individuellement des millions de SKUs, et la plupart d’entre eux ont un chiffre d’affaires inférieur à 1 milliard de dollars. Bien qu’il soit peut-être possible de réduire un peu la taille de cette machine virtuelle et de la mettre hors tension lorsqu’elle n’est pas utilisée, chez Lokad, nous avons appris que ces options sont rarement adaptées à la production.

Par exemple, les plateformes de cloud computing sont confrontées à leurs propres pénuries : parfois, la machine virtuelle qui était censée être disponible à la demande met des heures à être mise en ligne. De plus, ne supposez jamais que ces modèles peuvent simplement être “pré-entraînés”, il y aura un jour - comme mardi prochain - où tout devra être réentraîné à partir de zéro pour des raisons impératives[^urgence]. De plus, une configuration de qualité de production nécessite non seulement de la redondance, mais aussi des environnements supplémentaires (tests, pré-production, etc.).

Du côté logiciel, le besoin d’un outil comme le Plasma Object Store est l’archétype de ces complications accidentelles qui accompagnent le deep learning. Supposons que l’ensemble de données d’entraînement - avec 80 000 SKUs agrégés hebdomadairement sur seulement 104 semaines - devrait peser moins de 100 Mo (si les données sont correctement représentées).

Alors que les auteurs de DIM restent habilement vagues, en parlant d’une “grande quantité de données” (page 32), il est évident que la stratégie de featurization fait gonfler l’empreinte initiale des données de 3 ordres de grandeur (1000x, environ). Gardez à l’esprit que l’EC2 p3.16xlarge dispose de pas moins de 488 Go de RAM, ce qui devrait être suffisant pour traiter un ensemble de données de 100 Mo (environ 100 Go après l’application de l’inflation)… Eh bien, déjà fait, et confronté au même problème.

Par exemple, un ensemble de données de chaîne d’approvisionnement de taille réaliste dépasserait généralement 1 téraoctet après l’inflation des données - comme l’exige l’approche DIM. Dans ce cas, un data scientist de taille moyenne ne peut pas reproduire un bug localement car sa station de travail ne dispose que de 64 Go de RAM. Au-delà de cela, il y a aussi la question de la frontière Python/Plasma où les choses peuvent mal tourner.

Au-delà des principales critiques ci-dessus, il y a des préoccupations secondaires. Par exemple, la programmation dynamique⁷ - mentionnée dans l’introduction et la conclusion comme le point de référence et le concurrent de DIM - est simplement un mauvais point de référence. La programmation dynamique est une technique ancienne (datant des années 1950) et ne reflète pas l’état de l’art en ce qui concerne l’optimisation et l’apprentissage combinés.

Certes, la littérature sur la chaîne d’approvisionnement est lacunaire à cet égard, mais cela signifie que les auteurs doivent trouver des points de référence pertinents en dehors de leur(s) domaine(s) d’étude. Par exemple, AlphaGo Zero⁸ est un point de référence intellectuel bien meilleur lorsqu’il s’agit d’une application remarquable du deep learning à des fins d’optimisation - certainement par rapport aux techniques de programmation dynamique qui ont presque 80 ans.

En conclusion, contrairement à ce que ma critique pourrait suggérer, c’est un meilleur article que la plupart et absolument digne d’être critiqué. La programmation différentiable est un excellent instrument pour les chaînes d’approvisionnement. Lokad l’utilise depuis des années, mais nous n’avons pas épuisé ce qui peut être fait avec ce paradigme programmatique.

Il y a encore plus à 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 question les dogmes fondamentaux de la théorie dominante de la chaîne d’approvisionnement - tout comme nous le faisons. Chez Lokad, nous avons le projet de mélanger d’une manière ou d’une autre le montecarlo et l’autodiff⁹ de manière à ce qu’ils s’intègrent parfaitement à ces simulateurs différentiables.

Restez à l’écoute !