Modélisation prédictive structurée pour la Supply Chain - Cours 5.1

00:01 Introduction
02:44 Étude des besoins prédictifs
05:57 Modèles vs. Modélisation
12:26 L’histoire jusqu’à présent
15:50 Un peu de théorie et un peu de pratique
17:41 Programmation différentiable, SGD 1/6
24:56 Programmation différentiable, autodiff 2/6
31:07 Programmation différentiable, fonctions 3/6
35:35 Programmation différentiable, méta-paramètres 4/6
37:59 Programmation différentiable, paramètres 5/6
40:55 Programmation différentiable, particularités 6/6
43:41 Exemple, prévision de la demande en vente au détail
45:49 Exemple, ajustement des paramètres 1/6
53:14 Exemple, partage des paramètres 2/6
01:04:16 Exemple, masquage de la perte 3/6
01:09:34 Exemple, intégration de covariables 4/6
01:14:09 Exemple, décomposition sparse 5/6
01:21:17 Exemple, mise à l’échelle libre 6/6
01:25:14 Boîte blanche
01:33:22 Retour à l’optimisation expérimentale
01:39:53 Conclusion
01:44:40 Prochain cours et questions du public

Description

La programmation différentiable (DP) est un paradigme génératif utilisé pour concevoir une large classe de modèles statistiques, qui se révèlent être particulièrement adaptés aux défis prédictifs de la supply chain. La DP remplace presque toute la littérature “classique” de prévision basée sur des modèles paramétriques. La DP est également supérieure aux algorithmes “classiques” d’apprentissage automatique - jusqu’à la fin des années 2010 - dans pratiquement tous les aspects importants pour une utilisation pratique à des fins de supply chain, y compris la facilité d’adoption par les praticiens.

Transcription complète

Bienvenue dans cette série de cours sur la supply chain. Je suis Joannes Vermorel et aujourd’hui je vais présenter “Modélisation prédictive structurée avec la programmation différentiable dans la supply chain”. Choisir la bonne action nécessite une compréhension quantitative détaillée de l’avenir. En effet, chaque décision - acheter plus, produire plus - reflète une certaine anticipation de l’avenir. Invariablement, la théorie dominante de la supply chain met l’accent sur la notion de prévision pour aborder cette question. Cependant, la perspective de prévision, du moins sous sa forme classique, présente deux lacunes.

Premièrement, elle met l’accent sur une perspective étroite de séries temporelles qui ne parvient malheureusement pas à aborder la diversité des défis tels qu’ils se présentent dans les chaînes d’approvisionnement réelles. Deuxièmement, elle met l’accent sur une focalisation étroite sur la précision des prévisions des séries temporelles qui passe également largement à côté du sujet. Gagner quelques points de pourcentage supplémentaires de précision ne se traduit pas automatiquement par la génération de dollars supplémentaires pour votre chaîne d’approvisionnement.

L’objectif de cette conférence est de découvrir une approche alternative de la prévision, qui est en partie une technologie et en partie une méthodologie. La technologie sera la programmation différentiable et la méthodologie sera les modèles prédictifs structurés. À la fin de cette conférence, vous devriez être en mesure d’appliquer cette approche à une situation de chaîne d’approvisionnement. Cette approche n’est pas théorique ; elle est devenue l’approche par défaut de Lokad depuis quelques années maintenant. De plus, si vous n’avez pas regardé les conférences précédentes, la présente conférence ne devrait pas être totalement incompréhensible. Cependant, dans cette série de conférences, nous atteignons un point où il serait très utile de regarder réellement les conférences dans l’ordre. Dans la présente conférence, nous revisiterons plusieurs éléments qui ont été introduits dans les conférences précédentes.

La prévision de la demande future est le candidat évident lorsqu’il s’agit de l’étude des besoins prédictifs de notre chaîne d’approvisionnement. En effet, une meilleure anticipation de la demande est un ingrédient essentiel pour des décisions très basiques telles que l’achat de plus de produits et la production de plus de produits. Cependant, grâce aux principes de la chaîne d’approvisionnement que nous avons introduits tout au long du troisième chapitre de cette série de conférences, nous avons constaté qu’il existe un ensemble assez diversifié d’attentes que vous pouvez avoir en termes d’exigences prédictives pour piloter votre chaîne d’approvisionnement.

En particulier, par exemple, les délais d’approvisionnement varient et les délais d’approvisionnement présentent des motifs saisonniers. Pratiquement chaque décision liée aux stocks nécessite une anticipation de la demande future mais aussi une anticipation du délai d’approvisionnement futur. Ainsi, les délais d’approvisionnement doivent être prévus. Les retours représentent également parfois jusqu’à la moitié du flux. C’est le cas, par exemple, pour le commerce électronique de mode en Allemagne. Dans ces situations, anticiper les retours devient critique, et ces retours varient assez considérablement d’un produit à l’autre. Ainsi, dans ces situations, les retours doivent être prévus.

Du côté de l’approvisionnement, la production elle-même peut varier et pas seulement en raison des délais supplémentaires ou des délais d’approvisionnement variables. Par exemple, la production peut être accompagnée d’un certain degré d’incertitude. Cela se produit dans des secteurs à faible technologie tels que l’agriculture, mais cela peut également se produire dans des secteurs à haute technologie comme l’industrie pharmaceutique. Ainsi, les rendements de production doivent également être prévus. Enfin, le comportement des clients est également très important. Par exemple, stimuler la demande grâce à des produits qui génèrent une acquisition est très important, et inversement, faire face à des ruptures de stock sur des produits qui entraînent beaucoup de rotation lorsque ces produits sont précisément manquants en raison de ruptures de stock est également très important. Ainsi, ces comportements nécessitent une analyse, une prédiction - en d’autres termes, doivent être prévus. La principale conclusion ici est que la prévision des séries temporelles n’est qu’une pièce du puzzle. Nous avons besoin d’une approche prédictive qui peut englober toutes ces situations et plus encore, car c’est une nécessité si nous voulons avoir une approche qui a une chance de réussir face à toutes les situations auxquelles une chaîne d’approvisionnement réelle nous confrontera.

L’approche privilégiée lorsqu’il s’agit du problème prédictif est de présenter un modèle. Cette approche a guidé la littérature sur la prévision des séries temporelles depuis des décennies et c’est encore, je dirais, l’approche dominante dans les cercles de l’apprentissage automatique de nos jours. Cette approche centrée sur le modèle, c’est ainsi que je vais appeler cette approche, est si omniprésente qu’il peut même être difficile de prendre du recul un instant pour évaluer ce qui se passe réellement avec cette perspective centrée sur le modèle.

Ma proposition pour cette conférence est que la chaîne d’approvisionnement nécessite une technique de modélisation, une perspective centrée sur la modélisation, et qu’une série de modèles, aussi étendue soit-elle, ne sera jamais suffisante pour répondre à toutes nos exigences telles qu’elles se trouvent dans les chaînes d’approvisionnement réelles. Clarifions cette distinction entre l’approche centrée sur le modèle et l’approche centrée sur la modélisation.

L’approche centrée sur le modèle met l’accent avant tout sur un modèle. Le modèle est présenté comme un ensemble de recettes numériques qui se présentent généralement sous la forme d’un logiciel que vous pouvez réellement exécuter. Même lorsqu’aucun logiciel de ce type n’est disponible, l’attente est telle que si vous avez un modèle mais pas le logiciel, alors le modèle est censé être décrit avec une précision mathématique, permettant une réimplémentation complète du modèle. Ce package, le modèle rendu logiciel, est censé être l’objectif final.

D’un point de vue idéalisé, ce modèle est censé se comporter exactement comme une fonction mathématique : entrées en entrée, résultats en sortie. S’il reste une quelconque configurabilité pour le modèle, alors ces éléments configurables sont traités comme des points faibles, comme des problèmes qui restent à résoudre complètement. En effet, chaque option de configuration affaiblit le cas du modèle. Lorsque nous avons une configurabilité et trop d’options du point de vue centré sur le modèle, le modèle a tendance à se dissoudre dans un espace de modèles, et soudainement, nous ne pouvons plus vraiment évaluer quoi que ce soit car il n’y a pas de modèle unique.

L’approche de modélisation adopte une perspective complètement inversée sur l’angle de la configurabilité. Maximiser l’expressivité du modèle devient l’objectif final. Ce n’est pas un bug ; cela devient une fonctionnalité. La situation peut être assez confuse lorsque nous examinons une perspective centrée sur la modélisation, car si nous examinons une présentation d’une perspective centrée sur la modélisation, ce que nous allons voir est une présentation de modèles. Cependant, ces modèles ont une intention très différente.

Si vous adoptez la perspective de modélisation, le modèle présenté n’est qu’une illustration. Il ne prétend pas être complet ou être la solution finale au problème. Il s’agit simplement d’une étape dans le parcours pour illustrer la technique de modélisation elle-même. Le principal défi de la technique de modélisation est que soudainement, il devient très difficile d’évaluer l’approche. En effet, nous perdons l’option naïve de benchmarking car, avec cette perspective centrée sur la modélisation, nous avons des potentialités de modèles. Nous ne nous concentrons pas spécifiquement sur un modèle par rapport à un autre ; ce n’est même pas la bonne façon de penser. Ce que nous avons, c’est un avis éclairé.

Cependant, je tiens à souligner immédiatement que ce n’est pas parce que vous avez un benchmark et des chiffres associés à votre benchmark que cela se qualifie automatiquement comme de la science. Les chiffres peuvent être tout simplement absurdes, et inversement, ce n’est pas parce que c’est simplement un avis éclairé que cela est moins scientifique. En quelque sorte, c’est simplement une approche différente, et la réalité est que parmi les différentes communautés, les deux approches coexistent.

Par exemple, si nous examinons l’article “Forecasting at Scale”, publié par une équipe de Facebook en 2017, nous avons quelque chose qui est pratiquement l’archétype de l’approche centrée sur le modèle. Dans cet article, il y a une présentation du modèle Facebook Prophet. Et dans un autre article, “Tensor Comprehension”, publié en 2018 par une autre équipe de Facebook, nous avons essentiellement une technique de modélisation. Cet article peut être considéré comme l’archétype de l’approche de modélisation. Ainsi, vous pouvez voir que même les équipes de recherche travaillant dans la même entreprise, pratiquement au même moment, peuvent aborder le problème d’un angle à un autre, en fonction de la situation.

Cette conférence fait partie d’une série de conférences sur la supply chain. Dans le premier chapitre, j’ai présenté mes points de vue sur la supply chain à la fois en tant que domaine d’étude et en tant que pratique. Dès la première conférence, j’ai soutenu que la théorie dominante de la supply chain ne répond pas à ses attentes. Il se trouve que la théorie dominante de la supply chain s’appuie fortement sur l’approche centrée sur le modèle, et je pense que cet aspect unique est l’une des principales causes de friction entre la théorie dominante de la supply chain et les besoins des supply chains du monde réel.

Dans le deuxième chapitre de cette série de conférences, j’ai présenté une série de méthodologies. En effet, les méthodologies naïves sont généralement vaincues par la nature épisodique et souvent conflictuelle des situations de supply chain. En particulier, la conférence intitulée “Optimisation expérimentale empirique”, qui faisait partie du deuxième chapitre, est le type de perspective que j’adopte aujourd’hui dans cette conférence.

Dans le troisième chapitre, j’ai présenté une série de personae de la supply chain. Les personae représentent une focalisation exclusive sur les problèmes que nous essayons de résoudre, en ignorant complètement toute solution candidate. Ces personae sont essentiels pour comprendre la diversité des défis prédictifs auxquels sont confrontées les supply chains du monde réel. Je pense que ces personae sont essentiels pour éviter de se retrouver piégé dans la perspective étroite des séries temporelles, qui est l’une des caractéristiques d’une théorie de la supply chain exercée en accordant peu d’attention aux détails concrets des supply chains du monde réel.

Dans le quatrième chapitre, j’ai présenté une série de sciences auxiliaires. Ces sciences sont distinctes de la supply chain, mais une maîtrise de base de ces disciplines est essentielle pour la pratique moderne de la supply chain. Nous avons déjà brièvement abordé le sujet de la programmation différentiable dans ce quatrième chapitre, mais je vais réintroduire ce paradigme de programmation en beaucoup plus de détails dans quelques minutes.

Enfin, dans la première conférence de ce cinquième chapitre, nous avons vu un modèle simple, certains diraient même simpliste, qui a atteint une précision de prévision de pointe lors d’une compétition de prévision mondiale qui a eu lieu en 2020. Aujourd’hui, je présente une série de techniques qui peuvent être utilisées pour apprendre les paramètres associés à ce modèle que j’ai présenté dans la conférence précédente.

Le reste de cette conférence se divisera globalement en deux parties, suivies de quelques réflexions finales. Le premier bloc est consacré à la programmation différentiable. Nous avons déjà abordé ce sujet dans le quatrième chapitre ; cependant, nous y jetterons un regard beaucoup plus attentif aujourd’hui. À la fin de cette conférence, vous devriez presque être en mesure de créer votre propre implémentation de programmation différentiable. Je dis “presque” car cela dépendra de la pile technologique que vous utilisez. De plus, la programmation différentiable est un artisanat mineur en soi ; il faut un peu d’expérience pour le faire fonctionner correctement en pratique.

Le deuxième bloc de cette conférence est une présentation détaillée d’une situation de prévision de la demande en vente au détail. Cette présentation fait suite à la conférence précédente, où nous avons présenté le modèle qui a obtenu la première place lors de la compétition de prévision M5 en 2020. Cependant, lors de cette présentation précédente, nous n’avons pas détaillé comment les paramètres du modèle ont été effectivement calculés. Cette présentation détaillera exactement cela, et nous aborderons également des éléments importants tels que les ruptures de stock et les promotions qui n’ont pas été abordés dans la conférence précédente. Enfin, sur la base de tous ces éléments, je discuterai de mes points de vue sur l’adéquation de la programmation différentiable à des fins de supply chain.

La descente de gradient stochastique (SGD) est l’un des deux piliers de la programmation différentiable. La SGD est trompeusement simple, et pourtant il n’est pas encore tout à fait clair pourquoi elle fonctionne si bien. Il est absolument clair pourquoi elle fonctionne ; ce qui n’est pas très clair, c’est pourquoi elle fonctionne si bien.

L’histoire de la descente de gradient stochastique remonte aux années 1950, elle a donc une longue histoire. Cependant, cette technique n’a été reconnue que récemment avec l’avènement de l’apprentissage profond. La descente de gradient stochastique est profondément enracinée dans la perspective de l’optimisation mathématique. Nous avons une fonction de perte Q que nous voulons minimiser, et nous avons un ensemble de paramètres réels, notés W, qui représentent toutes les solutions possibles. Ce que nous voulons trouver, c’est la combinaison de paramètres W qui minimise la fonction de perte Q.

La fonction de perte Q est censée respecter une propriété fondamentale : elle peut être décomposée de manière additive en une série de termes. L’existence de cette décomposition additive permet à la descente de gradient stochastique de fonctionner. Si votre fonction de perte ne peut pas être décomposée de manière additive comme cela, alors la descente de gradient stochastique ne s’applique pas en tant que technique. Dans cette perspective, X représente l’ensemble de tous les termes qui contribuent à la fonction de perte, et Qx représente une perte partielle qui représente la perte pour l’un des termes dans cette perspective d’avoir la fonction de perte comme la somme de termes partiels.

Bien que la descente de gradient stochastique ne soit pas spécifique aux situations d’apprentissage, elle s’adapte très bien à tous les cas d’utilisation de l’apprentissage, et lorsque je parle d’apprentissage, je veux dire l’apprentissage dans les cas d’utilisation de l’apprentissage automatique. En effet, si nous avons un ensemble de données d’entraînement, cet ensemble de données prendra la forme d’une liste d’observations, chaque observation étant une paire de caractéristiques qui représentent l’entrée du modèle et des étiquettes qui représentent les sorties. Essentiellement, ce que nous voulons d’un point de vue d’apprentissage, c’est concevoir un modèle qui fonctionne le mieux sur l’erreur empirique et d’autres choses observées à partir de cet ensemble de données d’entraînement. D’un point de vue d’apprentissage, X serait en fait la liste des observations, et les paramètres seraient les paramètres d’un modèle d’apprentissage automatique que nous essayons d’optimiser pour mieux correspondre à cet ensemble de données.

La descente de gradient stochastique est fondamentalement un processus itératif qui itère de manière aléatoire à travers les observations, une observation à la fois. Nous choisissons une observation, un petit X, à la fois, et pour cette observation, nous calculons un gradient local, représenté par nabla de Qx. C’est juste un gradient local qui s’applique uniquement à un terme de la fonction de perte. Ce n’est pas le gradient de la fonction de perte complète elle-même, mais un gradient local qui s’applique uniquement à un terme de la fonction de perte - vous pouvez le voir comme un gradient partiel.

Une étape de la descente de gradient stochastique consiste à prendre ce gradient local et à ajuster légèrement les paramètres W en fonction de cette observation partielle du gradient. C’est exactement ce qui se passe ici, avec W qui est mis à jour avec W moins eta fois nabla QxW. Cela signifie simplement, de manière très concise, d’ajuster le paramètre W dans la direction du gradient local obtenu avec X, où X est simplement l’une des observations de votre ensemble de données, si nous abordons un problème d’un point de vue d’apprentissage. Ensuite, nous procédons de manière aléatoire, en appliquant ce gradient local et en itérant.

Intuitivement, la descente de gradient stochastique fonctionne très bien car elle présente un compromis entre une itération plus rapide et des gradients plus bruités, jusqu’à une itération plus granulaire et donc plus rapide. L’essence de la descente de gradient stochastique est que nous ne nous soucions pas d’avoir des mesures très imparfaites pour nos gradients tant que nous pouvons obtenir ces mesures imparfaites très rapidement. Si nous pouvons déplacer le compromis vers une itération plus rapide, même au détriment de gradients plus bruités, faisons-le. C’est pourquoi la descente de gradient stochastique est si efficace pour minimiser la quantité de ressources informatiques nécessaires pour atteindre une certaine qualité de solution pour le paramètre W.

Enfin, nous avons la variable eta, qui est appelée taux d’apprentissage. En pratique, le taux d’apprentissage n’est pas une constante ; cette variable varie pendant que la descente de gradient stochastique est en cours. Chez Lokad, nous utilisons l’algorithme Adam pour contrôler l’évolution de ce paramètre eta pour le taux d’apprentissage. Adam est une méthode publiée en 2014 et elle est très populaire dans les cercles de l’apprentissage automatique chaque fois que la descente de gradient stochastique est impliquée.

Le deuxième pilier de la programmation différentiable est la différenciation automatique. Nous avons déjà vu ce concept dans une précédente conférence. Revisitons ce concept en examinant un morceau de code. Ce code est écrit en Envision, un langage de programmation spécifique au domaine développé par Lokad dans le but d’optimiser de manière prédictive les chaînes d’approvisionnement. Je choisis Envision car, comme vous le verrez, les exemples sont beaucoup plus concis et, espérons-le, beaucoup plus clairs également, par rapport à d’autres présentations alternatives si j’utilisais Python, Java ou C#. Cependant, je tiens à souligner que même si j’utilise Envision, il n’y a pas de recette secrète. Vous pourriez entièrement réimplémenter tous ces exemples dans d’autres langages de programmation. Cela multiplierait très probablement le nombre de lignes de code par un facteur de 10, mais dans l’ensemble, c’est un détail. Ici, pour une conférence, Envision nous offre une présentation très claire et concise.

Voyons comment la programmation différentiable peut être utilisée pour résoudre une régression linéaire. Il s’agit d’un problème fictif ; nous n’avons pas besoin de la programmation différentiable pour effectuer une régression linéaire. L’objectif est simplement de se familiariser avec la syntaxe de la programmation différentiable. Des lignes 1 à 6, nous déclarons la table T, qui représente la table d’observations. Lorsque je dis table d’observations, souvenez-vous simplement de l’ensemble de descente de gradient stochastique qui était nommé X. C’est exactement la même chose. Cette table a deux colonnes, une caractéristique notée X et une étiquette notée Y. Ce que nous voulons, c’est prendre X en entrée et être capable de prédire Y avec un modèle linéaire, ou plus précisément, un modèle affine. Évidemment, nous n’avons que quatre points de données dans cette table T. Il s’agit d’un ensemble de données ridiculement petit ; c’est juste pour des raisons de clarté de l’exposition.

À la ligne 8, nous introduisons le bloc autodiff. Le bloc autodiff peut être considéré comme une boucle en Envision. C’est une boucle qui itère sur une table, dans ce cas, la table T. Ces itérations reflètent les étapes de la descente de gradient stochastique. Ainsi, ce qui se passe lorsque l’exécution d’Envision entre dans ce bloc autodiff, c’est que nous avons une série d’exécutions répétées où nous choisissons des lignes de la table d’observations, puis appliquons des étapes de la descente de gradient stochastique. Pour cela, nous avons besoin des gradients.

D’où viennent les gradients ? Ici, nous avons écrit un programme, une petite expression de notre modèle, Ax + B. Nous introduisons la fonction de perte, qui est l’erreur quadratique moyenne. Nous voulons avoir le gradient. Pour une situation aussi simple que celle-ci, nous pourrions écrire le gradient manuellement. Cependant, la différenciation automatique est une technique qui vous permet de compiler un programme sous deux formes : la première forme est l’exécution avant du programme, et la deuxième forme est la forme d’exécution inverse qui calcule les gradients associés à tous les paramètres présents dans le programme.

Aux lignes 9 et 10, nous avons la déclaration de deux paramètres, A et B, avec le mot-clé “auto” qui indique à Envision de faire une initialisation automatique des valeurs de ces deux paramètres. A et B sont des valeurs scalaires. La différenciation automatique se produit pour tous les programmes contenus dans ce bloc autodiff. Essentiellement, c’est une technique au niveau du compilateur pour compiler ce programme deux fois : une fois pour le passage avant et une deuxième fois pour un programme qui fournira les valeurs des gradients. La beauté de la technique de différenciation automatique est qu’elle garantit que la quantité de CPU nécessaire pour calculer le programme régulier est alignée avec la quantité de CPU nécessaire pour calculer le gradient lorsque vous effectuez le passage inverse. C’est une propriété très importante. Enfin, à la ligne 14, nous imprimons les paramètres que nous venons d’apprendre avec le bloc autodiff ci-dessus.

La programmation différentiable brille vraiment en tant que paradigme de programmation. Il est possible de composer un programme arbitrairement complexe et d’obtenir la différenciation automatisée de ce programme. Ce programme peut inclure des branches et des appels de fonctions, par exemple. Cet exemple de code revisite la fonction de perte pinball que nous avons introduite dans la précédente leçon. La fonction de perte pinball peut être utilisée pour dériver des estimations de quantiles lorsque nous observons des écarts par rapport à une distribution de probabilité empirique. Si vous minimisez l’erreur quadratique moyenne avec votre estimation, vous obtenez une estimation de la moyenne de votre distribution empirique. Si vous minimisez la fonction de perte pinball, vous obtenez une estimation d’une cible de quantile. Si vous visez un quantile de 90, cela signifie que c’est la valeur dans votre distribution de probabilité où la valeur future à observer a 90% de chances d’être inférieure à votre estimation si vous avez une cible de 90 ou 10% de chances d’être supérieure. Cela rappelle l’analyse des taux de service qui existe dans la supply chain.

Aux lignes 1 et 2, nous introduisons une table d’observations peuplée de déviations échantillonnées de manière aléatoire à partir d’une distribution de Poisson. Les valeurs de la distribution de Poisson sont échantillonnées avec une moyenne de 3, et nous obtenons 10 000 déviations. Aux lignes 4 et 5, nous déployons notre implémentation sur mesure de la fonction de perte pinball. Cette implémentation est presque identique au code que j’ai présenté dans la précédente leçon. Cependant, le mot-clé “autodiff” est maintenant ajouté à la déclaration de la fonction. Ce mot-clé, lorsqu’il est attaché à la déclaration de la fonction, garantit que le compilateur Envision peut différencier automatiquement cette fonction. Bien que, en théorie, la différenciation automatique puisse être appliquée à n’importe quel programme, en pratique, il y a beaucoup de programmes qui n’ont pas de sens à être différenciés ou de nombreuses fonctions où cela n’aurait pas de sens. Par exemple, considérez une fonction qui prend deux valeurs textuelles et les concatène. Du point de vue de la différenciation automatique, il n’a pas de sens d’appliquer une différenciation automatique à ce type d’opération. La différenciation automatique nécessite que des nombres soient présents en entrée et en sortie pour les fonctions que vous essayez de différencier.

Aux lignes 7 à 9, nous avons le bloc autodiff, qui calcule l’estimation du quantile cible pour la distribution empirique reçue par le biais de la table d’observations. Sous le capot, il s’agit en réalité d’une distribution de Poisson. L’estimation du quantile est déclarée comme un paramètre nommé “quantile” à la ligne 8, et à la ligne 9, nous effectuons un appel de fonction à notre propre implémentation de la fonction de perte pinball. La cible du quantile est fixée à 0,5, nous recherchons donc en réalité une estimation médiane de la distribution. Enfin, à la ligne 11, nous imprimons les résultats pour la valeur que nous avons apprise grâce à l’exécution du bloc autodiff. Ce morceau de code illustre comment un programme que nous allons différencier automatiquement peut inclure à la fois un appel de fonction et une branche, et tout cela peut se faire complètement automatiquement.

J’ai dit que les blocs autodiff peuvent être interprétés comme une boucle qui effectue une série d’étapes de descente de gradient stochastique (SGD) sur la table d’observations, en choisissant une ligne de cette table d’observations à la fois. Cependant, je suis resté assez évasif sur la condition d’arrêt pour cette situation. Quand est-ce que la descente de gradient stochastique s’arrête dans Envision ? Par défaut, la descente de gradient stochastique s’arrête après 10 époques. Une époque, en terminologie d’apprentissage automatique, représente un passage complet à travers la table d’observations. À la ligne 7, un attribut nommé “epochs” peut être attaché aux blocs autodiff. Cet attribut est facultatif ; par défaut, la valeur est de 10, mais si vous spécifiez cet attribut, vous pouvez choisir un nombre différent. Ici, nous spécifions 100 époques. Gardez à l’esprit que le temps total de calcul est presque strictement linéaire par rapport au nombre d’époques. Ainsi, si vous avez deux fois plus d’époques, le temps de calcul durera deux fois plus longtemps.

Cependant, à la ligne 7, nous introduisons également un deuxième attribut nommé “learning_rate”. Cet attribut est également facultatif et par défaut, il a la valeur 0,01, attachée au bloc autodiff. Ce taux d’apprentissage est un facteur utilisé pour initialiser l’algorithme Adam qui contrôle l’évolution du taux d’apprentissage. Il s’agit du paramètre eta que nous avons vu dans l’étape de descente de gradient stochastique. Il contrôle l’algorithme Adam. Essentiellement, il s’agit d’un paramètre que vous n’avez pas souvent besoin de modifier, mais parfois, en ajustant ce paramètre, vous pouvez économiser une partie significative de la puissance de traitement. Il n’est pas surprenant qu’en affinant ce taux d’apprentissage, vous puissiez économiser environ 20% du temps de calcul total pour votre descente de gradient stochastique.

L’initialisation des paramètres appris dans le bloc autodiff nécessite également un examen plus approfondi. Jusqu’à présent, nous avons utilisé le mot-clé “auto”, et dans Envision, cela signifie simplement qu’Envision initialisera le paramètre en tirant aléatoirement une valeur d’une distribution gaussienne de moyenne 1 et d’écart-type 0,1. Cette initialisation diverge de la pratique habituelle en apprentissage profond, où les paramètres sont initialisés de manière aléatoire avec des gaussiennes centrées autour de zéro. La raison pour laquelle Lokad a adopté cette approche différente deviendra plus claire plus tard dans cette leçon lorsque nous aborderons une situation réelle de prévision de la demande en vente au détail.

Dans Envision, il est possible de remplacer et de contrôler l’initialisation des paramètres. Le paramètre “quantile”, par exemple, est déclaré à la ligne 9 mais n’a pas besoin d’être initialisé. En effet, à la ligne 7, juste au-dessus du bloc autodiff, nous avons une variable “quantile” à laquelle est attribuée la valeur 4,2, et donc la variable est déjà initialisée avec une valeur donnée. Il n’est plus nécessaire de l’initialiser automatiquement. Il est également possible d’imposer une plage de valeurs autorisées pour les paramètres, ce qui est fait avec le mot-clé “in” à la ligne 9. Essentiellement, nous définissons que “quantile” doit être compris entre 1 et 10, inclus. Avec ces limites en place, si une mise à jour obtenue à partir de l’algorithme Adam devait pousser la valeur du paramètre en dehors de la plage acceptable, nous limitons le changement provenant d’Adam de manière à ce qu’il reste dans cette plage. De plus, nous mettons également à zéro les valeurs de momentum qui sont généralement attachées à l’algorithme Adam sous le capot. L’imposition de limites aux paramètres diverge de la pratique classique de l’apprentissage profond ; cependant, les avantages de cette fonctionnalité deviendront évidents lorsque nous commencerons à discuter d’un exemple réel de prévision de la demande en vente au détail.

La programmation différentiable repose fortement sur la descente de gradient stochastique. L’aspect stochastique est littéralement ce qui rend la descente très rapide. C’est une arme à double tranchant ; le bruit obtenu par les pertes partielles n’est pas seulement un bug, mais aussi une fonctionnalité. En ayant un peu de bruit, la descente peut éviter de rester bloquée dans des zones avec des gradients très plats. Ainsi, ce gradient bruité rend non seulement l’itération beaucoup plus rapide, mais il aide également à pousser l’itération à sortir des zones où le gradient est très plat et ralentit la descente. Cependant, il faut garder à l’esprit que lorsque la descente de gradient stochastique est utilisée, la somme des gradients n’est pas le gradient de la somme. Par conséquent, la descente de gradient stochastique présente de légères biais statistiques, notamment en ce qui concerne les distributions de queue. Cependant, lorsque ces préoccupations se posent, il est relativement facile de bricoler les recettes numériques, même si la théorie reste un peu floue.

La programmation différentiable (DP) ne doit pas être confondue avec un solveur d’optimisation mathématique arbitraire. Le gradient doit circuler à travers le programme pour que la programmation différentiable fonctionne. La programmation différentiable peut fonctionner avec des programmes arbitrairement complexes, mais ces programmes doivent être conçus en gardant à l’esprit la programmation différentiable. De plus, la programmation différentiable est une culture ; c’est un ensemble de conseils et de astuces qui fonctionnent bien avec la descente de gradient stochastique. Tout bien considéré, la programmation différentiable se situe du côté facile du spectre de l’apprentissage automatique. C’est une technique très accessible. Néanmoins, il faut un peu de savoir-faire pour maîtriser ce paradigme et l’utiliser efficacement en production.

Nous sommes maintenant prêts à entamer le deuxième bloc de cette leçon : la démonstration. Nous allons effectuer une démonstration pour notre tâche de prévision de la demande en vente au détail. Cet exercice de modélisation est aligné sur le défi de prévision que nous avons présenté dans la leçon précédente. En bref, nous voulons prévoir la demande quotidienne au niveau des SKU dans un réseau de vente au détail. Un SKU, ou unité de gestion des stocks, est techniquement le produit cartésien entre les produits et les magasins, filtré en fonction des entrées de l’assortiment. Par exemple, si nous avons 100 magasins et 10 000 produits, et si chaque produit est présent dans chaque magasin, nous obtenons 1 million de SKU.

Il existe des outils pour transformer une estimation déterministe en une estimation probabiliste. Nous avons vu l’un de ces outils dans la leçon précédente grâce à la technique ESSM. Nous aborderons à nouveau cette préoccupation spécifique - transformer les estimations en estimations probabilistes - en détail dans la prochaine leçon. Cependant, aujourd’hui, nous nous intéressons uniquement à l’estimation des moyennes, et tous les autres types d’estimations (quantiles, probabilistes) viendront plus tard en tant qu’extensions naturelles de l’exemple de base que je présenterai aujourd’hui. Dans cette démonstration, nous allons apprendre les paramètres d’un modèle simple de prévision de la demande. La simplicité de ce modèle est trompeuse car cette classe de modèle permet d’obtenir des prévisions de pointe, comme le montre la compétition de prévision M5 en 2020.

Pour notre modèle de demande paramétrique, introduisons un seul paramètre pour chaque SKU. Il s’agit d’une forme absolument simpliste de modèle ; la demande est modélisée comme une constante pour chaque SKU. Cependant, ce n’est pas la même constante pour chaque SKU. Une fois que nous avons cette moyenne quotidienne constante, elle aura la même valeur pour tous les jours de l’ensemble du cycle de vie du SKU.

Voyons comment cela se fait avec la programmation différentiable. Des lignes 1 à 4, nous introduisons le bloc de données fictives. En pratique, ce modèle et toutes ses variantes dépendraient d’entrées obtenues à partir des systèmes d’entreprise : ERP, WMS, TMS, etc. Présenter une leçon où je brancherais un modèle mathématique dans une représentation réaliste des données, telle qu’elle est obtenue à partir de l’ERP, introduirait des complications accidentelles qui sont sans rapport avec le sujet de la présente leçon. Ainsi, ce que je fais ici, c’est introduire un bloc de données fictives qui ne prétend même pas être réaliste de quelque manière que ce soit, ou le genre de données que l’on peut observer dans une situation de vente au détail réelle. Le seul objectif de ces données fictives est d’introduire les tables et les relations entre les tables, et de s’assurer que l’exemple de code donné est complet, peut être compilé et peut être exécuté. Tous les exemples de code que vous avez vus jusqu’à présent sont complètement autonomes ; il n’y a pas de parties cachées avant ou après. Le seul but du bloc de données fictives est de s’assurer que nous avons un morceau de code autonome.

Dans chaque exemple de cette démonstration, nous commençons par ce bloc de données fictives. À la ligne 1, nous introduisons la table des dates avec “dates” comme clé principale. Ici, nous avons une plage de dates qui correspond à environ deux ans et un mois. Ensuite, à la ligne 2, nous introduisons la table des SKUs, qui est la liste des SKUs. Dans cet exemple minimaliste, nous n’avons que trois SKUs. Dans une situation de vente au détail réelle pour un réseau de vente au détail de taille importante, nous aurions des millions, voire des dizaines de millions, de SKUs. Mais ici, pour l’exemple, je prends un nombre très réduit. À la ligne 3, nous avons la table “T”, qui est un produit cartésien entre les SKUs et les dates. Fondamentalement, ce que vous obtenez à travers cette table “T” est une matrice où vous avez chaque SKU et chaque jour. Elle a deux dimensions.

À la ligne 6, nous introduisons notre bloc autodiff réel. La table d’observation est la table des SKUs, et la descente de gradient stochastique ici choisira un SKU à la fois. À la ligne 7, nous introduisons le “niveau”, qui sera notre unique paramètre. C’est un paramètre vectoriel, et jusqu’à présent, dans nos blocs autodiff, nous n’avons introduit que des paramètres scalaires. Les paramètres précédents étaient juste un nombre ; ici, “SKU.level” est en réalité un vecteur. C’est un vecteur qui a une valeur par SKU, et c’est littéralement notre demande constante modélisée au niveau du SKU. Nous spécifions une plage, et nous verrons pourquoi cela importe dans un instant. Elle doit être d’au moins 0,01, et nous fixons 1 000 comme limite supérieure de la demande moyenne quotidienne pour ce paramètre. Ce paramètre est automatiquement initialisé avec une valeur proche de un, ce qui est un point de départ raisonnable. Dans ce modèle, nous avons juste un degré de liberté par SKU. Enfin, aux lignes 8 et 9, nous mettons réellement en œuvre le modèle en lui-même. À la ligne 8, nous calculons “dot.delta”, qui est la demande prédite par le modèle moins l’observation, qui est “T.sold”. Le modèle n’est qu’un seul terme, une constante, puis nous avons l’observation, qui est “T.sold”.

Pour comprendre ce qui se passe ici, il y a des comportements de diffusion qui se produisent. La table “T” est une table croisée entre SKU et date. Le bloc autodiff est une itération qui parcourt les lignes de la table d’observation. À la ligne 9, nous sommes dans le bloc autodiff, donc nous avons choisi une ligne pour la table des SKUs. La valeur “SKUs.level” n’est pas un vecteur ici ; c’est juste un scalaire, une seule valeur car nous avons choisi une seule ligne de la table d’observation. Ensuite, “T.sold” n’est plus une matrice car nous avons déjà choisi un SKU. Ce qui reste, c’est que “T.sold” est en réalité un vecteur, un vecteur qui a une dimension égale à la date. Lorsque nous faisons cette soustraction, “SKUs.level - T.sold”, nous obtenons un vecteur qui est aligné avec la table des dates, et nous l’assignons à “D.delta”, qui est un vecteur avec une ligne par jour, soit deux ans et un mois. Enfin, à la ligne 9, nous calculons la fonction de perte, qui est simplement l’erreur quadratique moyenne. Ce modèle est très simpliste. Voyons ce qui peut être fait concernant les motifs calendaires.

Le partage de paramètres est probablement l’une des techniques de programmation différentiable les plus simples et les plus utiles. Un paramètre est dit partagé s’il contribue à plusieurs lignes d’observation. En partageant les paramètres entre les observations, nous pouvons stabiliser la descente de gradient et atténuer les problèmes de surajustement. Prenons en compte le motif du jour de la semaine. Nous pourrions introduire sept paramètres qui représentent les différents poids pour chaque SKU. Jusqu’à présent, un SKU n’avait qu’un seul paramètre, qui était simplement la demande constante. Si nous voulons enrichir cette perception de la demande, nous pourrions dire que chaque jour de la semaine est associé à son propre poids, et comme nous avons sept jours de la semaine, nous pouvons avoir sept poids et appliquer ces poids de manière multiplicative.

Cependant, il est peu probable que chaque SKU ait son propre motif de jour de la semaine unique. La réalité est qu’il est beaucoup plus raisonnable de supposer qu’il existe une catégorie ou une sorte de hiérarchie, comme une famille de produits, une catégorie de produits, une sous-catégorie de produits, voire un département dans le magasin, qui capture correctement ce motif du jour de la semaine. L’idée est que nous ne voulons pas introduire sept paramètres par SKU ; ce que nous voulons, c’est introduire sept paramètres par catégorie, le niveau de regroupement où nous supposons qu’il y a un comportement homogène en termes de motifs du jour de la semaine.

Si nous décidons d’introduire ces sept paramètres avec un effet multiplicatif sur le niveau, c’est exactement l’approche qui a été adoptée dans la conférence précédente pour ce modèle, qui s’est classé numéro un au niveau SKU dans la compétition M5. Nous avons un niveau et un effet multiplicatif avec le motif du jour de la semaine.

Dans le code, dans les lignes 1 à 5, nous avons le bloc de données fictives comme précédemment, et nous introduisons une table supplémentaire appelée “category”. Cette table est une table de regroupement des SKUs, et conceptuellement, pour chaque ligne dans la table SKU, il y a une et une seule ligne qui correspond dans la table category. Dans le langage Envision, nous disons que la catégorie est en amont de la table SKUs. La ligne 7 introduit la table du jour de la semaine. Cette table est instrumentale, et nous l’introduisons avec une forme spécifique qui reflète le motif cyclique que nous voulons capturer. À la ligne 7, nous créons la table du jour de la semaine en agrégeant les dates en fonction de leur valeur modulo sept. Nous créons une table qui aura exactement sept lignes, et ces sept lignes représenteront chacun des sept jours de la semaine. Pour chaque ligne de la table des dates, chaque ligne de la base de données a une et une seule correspondance dans la table du jour de la semaine. Ainsi, selon le langage Envision, la table du jour de la semaine est en amont de la table “date”.

Maintenant, nous avons la table “CD”, qui est un produit cartésien entre la catégorie et le jour de la semaine. En termes de nombre de lignes, cette table aura autant de lignes qu’il y a de catégories multiplié par sept car le jour de la semaine a sept lignes. À la ligne 12, nous introduisons un nouveau paramètre nommé “CD.DOW” (DOW signifie jour de la semaine), qui est un autre paramètre vectoriel appartenant à la table CD. En termes de degrés de liberté, nous aurons exactement sept valeurs de paramètre multipliées par le nombre de catégories, ce que nous recherchons. Nous voulons un modèle capable de capturer ce motif du jour de la semaine mais avec un seul motif par catégorie, pas un motif par SKU.

Nous déclarons ce paramètre, et nous utilisons le mot-clé “in” pour spécifier que la valeur de “CD.DOW” doit être comprise entre 0,1 et 100. À la ligne 13, nous écrivons la demande telle qu’exprimée par le modèle. La demande est “SKUs.level * CD.DOW”, représentant la demande. Nous avons la demande moins l’observation “T.sold”, ce qui nous donne un delta. Ensuite, nous calculons l’erreur quadratique moyenne.

À la ligne 13, il y a beaucoup de magie de diffusion qui se produit. “CD.DOW” est une table croisée entre la catégorie et le jour de la semaine. Comme nous sommes dans le bloc autodiff, la table CD est une table croisée entre la catégorie et le jour de la semaine. Étant donné que nous sommes dans le bloc autodiff, le bloc itère sur la table SKUs. Essentiellement, lorsque nous choisissons un SKU, nous avons effectivement choisi une catégorie, car la table de catégories est en amont. Cela signifie que CD.DOW n’est plus une matrice, mais plutôt un vecteur de dimension sept. Cependant, il est en amont de la table “date”, de sorte que ces sept lignes peuvent être diffusées dans la table de dates. Il n’y a qu’une seule façon de diffuser cela car chaque ligne de la table des jours de la semaine a une affinité avec des lignes spécifiques de la table des dates. Nous avons une double diffusion en cours, et à la fin, nous obtenons une demande qui est une série de valeurs cycliques au niveau du jour de la semaine pour le SKU. C’est notre modèle à ce stade, et le reste de la fonction de perte reste inchangé.

Nous voyons une façon très élégante d’aborder les cyclicités en combinant les comportements de diffusion obtenus à partir de la nature relationnelle d’Envision avec ses capacités de programmation différentiable. Nous pouvons exprimer les cyclicités du calendrier en seulement trois lignes de code. Cette approche fonctionne bien même si nous traitons des données très dispersées. Cela fonctionnerait très bien même si nous examinions des produits qui ne vendent en moyenne qu’une unité par mois. Dans de tels cas, l’approche judicieuse serait d’avoir une catégorie qui inclut des dizaines, voire des centaines de produits. Cette technique peut également être utilisée pour refléter d’autres motifs cycliques, tels que le mois de l’année ou le jour du mois.

Le modèle introduit dans la conférence précédente, qui a obtenu des résultats de pointe lors de la compétition M5, était une combinaison multiplicative de trois cyclicités : le jour de la semaine, le mois de l’année et le jour du mois. Tous ces motifs étaient enchaînés par une multiplication. La mise en œuvre des deux autres variantes est laissée à l’attention du public attentif, mais il suffit de quelques lignes de code par motif cyclique, ce qui le rend très concis.

Dans la conférence précédente, nous avons présenté un modèle de prévision des ventes. Cependant, ce ne sont pas les ventes qui nous intéressent, mais la demande. Nous ne devons pas confondre les ventes nulles avec la demande nulle. Si aucun stock n’était disponible pour que le client puisse acheter en magasin un jour donné, la technique de masquage des pertes est utilisée chez Lokad pour faire face aux ruptures de stock. Il s’agit de la technique la plus simple utilisée pour faire face aux ruptures de stock, mais ce n’est pas la seule. À ma connaissance, nous avons au moins deux autres techniques qui sont utilisées en production, chacune ayant ses avantages et ses inconvénients. Ces autres techniques ne seront pas abordées aujourd’hui, mais elles seront traitées dans des conférences ultérieures.

En revenant à l’exemple de code, les lignes 1 à 3 restent inchangées. Examinons ce qui suit. À la ligne 6, nous enrichissons les données simulées avec le drapeau booléen “in-stock”. Pour chaque SKU et chaque jour, nous avons une valeur booléenne qui indique s’il y a eu une rupture de stock à la fin de la journée pour le magasin. À la ligne 15, nous modifions la fonction de perte pour exclure, en les mettant à zéro, les jours où une rupture de stock a été observée à la fin de la journée. En mettant ces jours à zéro, nous nous assurons qu’aucun gradient n’est rétropropagé dans des situations qui présentent un biais dû à la survenue de la rupture de stock.

L’aspect le plus déconcertant de la technique de masquage de la perte est qu’elle ne modifie même pas le modèle. En effet, si nous examinons le modèle exprimé à la ligne 14, il est exactement le même ; il n’a pas été modifié. Seule la fonction de perte elle-même est modifiée. Cette technique peut sembler simple, mais elle diverge profondément d’une perspective centrée sur le modèle. C’est, en essence, une technique centrée sur la modélisation. Nous améliorons la situation en reconnaissant le biais causé par les ruptures de stock, en le reflétant dans nos efforts de modélisation. Cependant, nous le faisons en modifiant la métrique de précision, et non le modèle lui-même. En d’autres termes, nous modifions la perte que nous optimisons, rendant ce modèle non comparable à d’autres modèles en termes d’erreur numérique pure.

Pour une situation comme celle de Walmart, comme discuté dans la conférence précédente, la technique de masquage de la perte est adéquate pour la plupart des produits. En règle générale, cette technique fonctionne bien si la demande n’est pas si rare que vous n’avez qu’une seule unité en stock la plupart du temps. De plus, vous devriez éviter les produits où les ruptures de stock sont très fréquentes, car c’est la stratégie explicite du détaillant de se retrouver en rupture de stock à la fin de la journée. Cela se produit généralement pour certains produits ultra-frais où le détaillant vise une situation de rupture de stock à la fin de la journée. Des techniques alternatives remédient à ces limitations, mais nous n’avons pas le temps de les aborder aujourd’hui.

Les promotions sont un aspect important de la vente au détail. Plus généralement, il existe de nombreuses façons pour le détaillant d’influencer et de façonner la demande, telles que la tarification ou le déplacement des marchandises sur une gondole. Les variables qui fournissent des informations supplémentaires à des fins prédictives sont généralement appelées covariables dans les cercles de la supply chain. Il y a beaucoup de vœux pieux concernant des covariables complexes comme les données météorologiques ou les données des médias sociaux. Cependant, avant de se plonger dans des sujets avancés, nous devons aborder l’éléphant dans la pièce, telles que les informations sur les prix, qui ont évidemment un impact significatif sur la demande qui sera observée. Ainsi, à la ligne 7 de cet exemple de code, nous introduisons pour chaque jour à la ligne 14, “category.ed”, où “ed” signifie élasticité de la demande. Il s’agit d’un paramètre vectoriel partagé avec un degré de liberté par catégorie, destiné à représenter l’élasticité de la demande. À la ligne 16, nous introduisons une forme exponentielle de l’élasticité-prix sous la forme exponentielle de (-category.ed * t.price). Intuitivement, avec cette forme, lorsque le prix augmente, la demande converge rapidement vers zéro en raison de la présence de la fonction exponentielle. Inversement, lorsque le prix converge vers zéro, la demande augmente de manière explosive.

Cette forme exponentielle de réponse aux prix est simpliste, et le partage des paramètres assure un degré élevé de stabilité numérique même avec cette fonction exponentielle dans le modèle. Dans des contextes réels, en particulier pour des situations comme celle de Walmart, nous aurions plusieurs informations sur les prix, telles que des remises, la différence par rapport au prix normal, des covariables représentant des actions marketing exécutées par le fournisseur, ou des variables catégorielles qui introduisent des éléments tels que des gondoles. Avec la programmation différentiable, il est facile de créer des réponses aux prix arbitrairement complexes qui correspondent étroitement à la situation. L’intégration de covariables de presque tous types est très simple avec la programmation différentiable.

Les produits à rotation lente sont une réalité dans le secteur de la vente au détail et dans de nombreux autres secteurs. Le modèle introduit jusqu’à présent a un paramètre, un degré de liberté par SKU, avec plus si l’on compte les paramètres partagés. Cependant, cela pourrait déjà être trop, surtout pour les SKU qui ne tournent qu’une fois par an ou seulement quelques fois par an. Dans de telles situations, nous ne pouvons même pas nous permettre un degré de liberté par SKU, donc la solution consiste à s’appuyer uniquement sur des paramètres partagés et à supprimer tous les paramètres avec des degrés de liberté au niveau du SKU.

Aux lignes 2 et 4, nous introduisons deux tables nommées “products” et “stores”, et la table “SKUs” est construite comme une sous-table filtrée du produit cartésien entre les produits et les magasins, ce qui est la définition même de l’assortiment. Aux lignes 15 et 16, nous avons introduit deux paramètres vectoriels partagés : un niveau avec une affinité avec la table des produits et un autre niveau qui a une affinité avec les tables des magasins. Ces paramètres sont également définis dans une plage spécifique, de 0,01 à 100, qui est la valeur maximale.

Maintenant, à la ligne 18, le niveau par SKU est composé de la multiplication du niveau du produit et du niveau du magasin. Le reste du script reste inchangé. Comment cela fonctionne-t-il ? À la ligne 19, SKU.level est un scalaire. Nous avons le bloc autodesk qui itère sur la table SKUs, qui est la table d’observation. Ainsi, SKUs.level à la ligne 18 est simplement une valeur scalaire. Ensuite, nous avons products.level. Étant donné que la table des produits est en amont de la table des SKUs, pour chaque SKU, il y a un et un seul tableau de produits. Ainsi, products.level est simplement un nombre scalaire. Il en va de même pour la table des magasins, qui est également en amont de la table des SKUs. À la ligne 18, il n’y a qu’un seul magasin attaché à ce SKU spécifique. Par conséquent, ce que nous avons, c’est la multiplication de deux valeurs scalaires, ce qui nous donne le SKU.level. Le reste du modèle reste inchangé.

Ces techniques apportent un tout nouvel éclairage sur l’affirmation selon laquelle il n’y a parfois pas assez de données ou que les données sont trop dispersées. En effet, du point de vue différentiable, ces affirmations n’ont même pas vraiment de sens. Il n’y a pas de notion de trop peu de données ou de données trop dispersées, du moins pas en termes absolus. Il existe simplement des modèles qui peuvent être modifiés vers la parcimonie et éventuellement vers une parcimonie extrême. La structure imposée est comme des rails de guidage qui rendent le processus d’apprentissage non seulement possible mais aussi numériquement stable.

Par rapport à d’autres techniques d’apprentissage automatique qui tentent de laisser le modèle d’apprentissage automatique découvrir tous les motifs ex nihilo, cette approche structurée établit la structure même que nous devons apprendre. Ainsi, le mécanisme statistique en jeu ici a une liberté limitée quant à ce qu’il doit apprendre. Par conséquent, en termes d’efficacité des données, cela peut être incroyablement efficace. Naturellement, tout cela repose sur le fait que nous avons choisi la bonne structure.

Comme vous pouvez le voir, faire des expériences est très simple. Nous faisons déjà quelque chose de très compliqué, et en moins de 50 lignes, nous pourrions gérer une situation assez complexe similaire à celle de Walmart. C’est tout à fait une réalisation. Il y a un peu de processus empirique, mais en réalité, ce n’est pas tant que ça. Nous parlons de quelques dizaines de lignes. Gardez à l’esprit qu’un ERP comme celui qui gère une entreprise, un grand réseau de vente au détail, a généralement mille tables et 100 champs par table. Donc, clairement, la complexité des systèmes d’entreprise est absolument gigantesque par rapport à la complexité de ce modèle prédictif structuré. Si nous devons passer un peu de temps à itérer, c’est presque rien.

De plus, comme le démontre la compétition de prévision M5, la réalité est que les praticiens de la supply chain connaissent déjà les motifs. Lorsque l’équipe M5 a utilisé trois motifs calendaires, qui étaient le jour de la semaine, le mois de l’année et le jour du mois, tous ces motifs étaient évidents pour tout praticien expérimenté de la supply chain. La réalité de la supply chain est que nous n’essayons pas de découvrir un motif caché. Le fait que, par exemple, si vous baissez massivement le prix, la demande va augmenter massivement, ne surprendra personne. La seule question qui reste est quelle est exactement l’ampleur de l’effet et quelle est la forme exacte de la réponse. Ce sont des détails relativement techniques, et si vous vous donnez la possibilité de faire un peu d’expérimentation, vous pouvez résoudre ces problèmes relativement facilement.

En guise de dernière étape de cette démonstration, je tiens à souligner une particularité mineure de la programmation différentiable. La programmation différentiable ne doit pas être confondue avec un solveur générique d’optimisation mathématique. Nous devons garder à l’esprit qu’il y a une descente de gradient en cours. Plus précisément, l’algorithme utilisé pour optimiser et mettre à jour les paramètres a une vitesse de descente maximale égale au taux d’apprentissage fourni par l’algorithme ADAM. Dans Envision, le taux d’apprentissage par défaut est de 0,01.

Si nous examinons le code, à la ligne 4, nous avons introduit une initialisation où les quantités vendues sont échantillonnées à partir d’une distribution de Poisson avec une moyenne de 50. Si nous voulons apprendre un niveau, techniquement, nous aurions besoin d’avoir un niveau qui serait de l’ordre de 50. Cependant, lorsque nous effectuons une initialisation automatique du paramètre, nous commençons avec une valeur d’environ un, et nous ne pouvons augmenter que par incréments de 0,01. Il faudrait environ 5 000 époques pour atteindre réellement cette valeur de 50. Étant donné que nous avons un paramètre non partagé, SKU.level, ce paramètre par époque n’est touché qu’une seule fois. Ainsi, nous aurions besoin de 5 000 époques, ce qui ralentirait inutilement le calcul.

Nous pourrions augmenter le taux d’apprentissage pour accélérer la descente, ce qui serait une solution. Cependant, je déconseillerais d’augmenter le taux d’apprentissage, car ce n’est généralement pas la bonne façon d’aborder le problème. Dans une situation réelle, nous aurions des paramètres partagés en plus de ce paramètre non partagé. Ces paramètres partagés seront touchés plusieurs fois par la descente de gradient stochastique à chaque époque. Si vous augmentez considérablement le taux d’apprentissage, vous risquez de créer des instabilités numériques pour vos paramètres partagés. Vous pourriez augmenter la vitesse de déplacement du niveau SKU, mais créer des problèmes de stabilité numérique pour les autres paramètres.

Une meilleure technique consisterait à utiliser une astuce de mise à l’échelle et à envelopper le paramètre dans une fonction exponentielle, ce qui est exactement ce qui est fait à la ligne 8. Avec cet enveloppement, nous pouvons maintenant atteindre des valeurs de paramètre pour le niveau qui peuvent être très faibles ou très élevées avec un nombre beaucoup plus petit d’époques. Cette particularité est essentiellement la seule particularité que je devrais introduire pour avoir un exemple réaliste de cette situation de prévision de la demande de vente au détail. Tout bien considéré, c’est une particularité mineure. Néanmoins, cela rappelle que la programmation différentiable nécessite une attention particulière au flux des gradients. La programmation différentiable offre une expérience de conception fluide dans l’ensemble, mais ce n’est pas de la magie.

Quelques réflexions finales : les modèles structurés permettent d’atteindre une précision de prévision de pointe. Ce point a été largement abordé lors de la conférence précédente. Cependant, sur la base des éléments présentés aujourd’hui, je soutiendrais que la précision n’est même pas le facteur décisif en faveur de la programmation différentiable avec un modèle paramétrique structuré. Ce que nous obtenons, c’est la compréhension ; nous n’obtenons pas seulement un logiciel capable de faire des prédictions, mais nous obtenons également des informations directes sur les motifs mêmes que nous essayons de capturer. Par exemple, le modèle présenté aujourd’hui nous donnerait directement une prévision de la demande qui est accompagnée de pondérations explicites pour chaque jour de la semaine et d’une élasticité explicite de la demande. Si nous devions étendre cette demande, par exemple, pour introduire une augmentation associée au Black Friday, un événement quasi-saisonnier qui ne se produit pas à la même période chaque année, nous pourrions le faire. Il suffirait d’ajouter un facteur, et nous aurions alors une estimation de l’augmentation du Black Friday isolée de tous les autres motifs, tels que le motif du jour de la semaine. Cela est d’un intérêt primordial.

Ce que nous obtenons grâce à l’approche structurée, c’est la compréhension, et c’est bien plus que le simple modèle brut. Par exemple, si nous obtenons une élasticité négative, une situation où le modèle vous dit que lorsque vous augmentez le prix, vous augmentez la demande, dans une situation à la Walmart, c’est un résultat très douteux. Il est très probable que cela reflète un problème dans la mise en œuvre de votre modèle, ou qu’il y ait des problèmes profonds en cours. Peu importe ce que vous dit la mesure de précision, si vous vous retrouvez dans une situation à la Walmart avec quelque chose qui vous dit qu’en rendant un produit plus cher, les gens en achètent plus, vous devriez vraiment remettre en question l’ensemble de votre pipeline de données, car il y a très probablement quelque chose de très faux. C’est cela, la compréhension.

De plus, le modèle est ouvert au changement. La programmation différentiable est incroyablement expressive. Le modèle que nous avons n’est qu’une itération dans un parcours. Si le marché se transforme ou si l’entreprise elle-même se transforme, nous pouvons être assurés que le modèle que nous avons sera capable de capturer cette évolution naturellement. Il n’y a pas de telle chose qu’une évolution automatique ; cela demandera des efforts de la part d’un Supply Chain Scientist pour capturer cette évolution. Cependant, cet effort peut être attendu comme relativement minimal. Cela revient au fait que si vous avez un modèle très petit et bien structuré, alors lorsque vous devrez revoir ce modèle ultérieurement pour ajuster sa structure, cela sera une tâche relativement petite par rapport à une situation où votre modèle serait un monstre d’ingénierie.

Lorsqu’ils sont conçus avec soin, les modèles produits avec la programmation différentiable sont très stables. La stabilité dépend du choix de la structure. La stabilité n’est pas garantie pour n’importe quel programme que vous optimisez grâce à la programmation différentiable ; c’est quelque chose que vous obtenez lorsque vous avez une structure très claire où les paramètres ont une sémantique spécifique. Par exemple, si vous avez un modèle où, chaque fois que vous réentraînez votre modèle, vous obtenez des poids complètement différents pour le jour de la semaine, alors la réalité de votre entreprise ne change pas si rapidement. Si vous exécutez votre modèle deux fois, vous devriez obtenir des valeurs pour le jour de la semaine qui sont assez stables. Si ce n’est pas le cas, alors il y a quelque chose de très faux dans la façon dont vous avez modélisé votre demande. Ainsi, si vous faites un choix judicieux pour la structure de votre modèle, vous pouvez obtenir des résultats numériques incroyablement stables. En faisant cela, nous évitons les pièges qui ont tendance à affecter les modèles d’apprentissage automatique complexes lorsque nous essayons de les utiliser dans un contexte de supply chain. En effet, d’un point de vue de la supply chain, les instabilités numériques sont mortelles car nous avons des effets de cliquet partout. Si vous avez une estimation de la demande qui fluctue, cela signifie que de manière aléatoire, vous allez déclencher une commande d’achat ou une commande de production pour rien. Une fois que vous avez déclenché votre commande de production, vous ne pouvez pas décider la semaine suivante que c’était une erreur et que vous n’auriez pas dû le faire. Vous êtes coincé avec la décision que vous venez de prendre. Si vous avez un estimateur de la demande future qui fluctue constamment, vous vous retrouverez avec des stocks de réapprovisionnement et des commandes de production gonflés. Ce problème peut être résolu en assurant la stabilité, ce qui relève de la conception.

L’un des plus grands obstacles à la mise en production de l’apprentissage automatique est la confiance. Lorsque vous travaillez avec des millions d’euros ou de dollars, il est essentiel de comprendre ce qui se passe dans votre recette numérique. Les erreurs de la chaîne d’approvisionnement peuvent être extrêmement coûteuses, et il existe de nombreux exemples de catastrophes de la chaîne d’approvisionnement causées par une mauvaise application d’algorithmes mal compris. Bien que la programmation différentiable soit très puissante, les modèles qui peuvent être conçus sont incroyablement simples. Ces modèles pourraient en fait être exécutés dans une feuille de calcul Excel, car ce sont généralement des modèles multiplicatifs simples avec des branches et des fonctions. Le seul aspect qui ne pourrait pas être exécuté dans une feuille de calcul Excel est la différenciation automatique, et évidemment, si vous avez des millions de références, ne tentez pas de le faire dans une feuille de calcul. Cependant, en termes de simplicité, cela est tout à fait compatible avec quelque chose que vous mettriez dans une feuille de calcul. Cette simplicité contribue grandement à établir la confiance et à intégrer l’apprentissage automatique dans la production, au lieu de les garder comme des prototypes sophistiqués auxquels les gens n’arrivent jamais vraiment à faire confiance complètement.

Enfin, lorsque nous combinons toutes ces propriétés, nous obtenons une technologie très précise. Cet aspect a été abordé dans le tout premier chapitre de cette série de conférences. Nous voulons transformer tous les efforts investis dans la chaîne d’approvisionnement en investissements capitalistiques, plutôt que de considérer les experts et les praticiens de la chaîne d’approvisionnement comme des consommables qui doivent faire les mêmes choses encore et encore. Avec cette approche, nous pouvons considérer tous ces efforts comme des investissements qui généreront et continueront de générer un retour sur investissement au fil du temps. La programmation différentiable s’accorde très bien avec cette perspective capitaliste de la chaîne d’approvisionnement.

Dans le deuxième chapitre, nous avons présenté une conférence importante intitulée “Optimisation expérimentale”, qui apportait une réponse possible à la question simple mais fondamentale : que signifie réellement améliorer ou faire mieux dans une chaîne d’approvisionnement ? La perspective de la programmation différentiable offre un éclairage très spécifique sur de nombreux problèmes auxquels sont confrontés les praticiens de la chaîne d’approvisionnement. Les éditeurs de logiciels d’entreprise rejettent souvent la faute sur les mauvaises données pour expliquer les échecs de la chaîne d’approvisionnement. Cependant, je pense que c’est simplement la mauvaise façon de voir le problème. Les données sont ce qu’elles sont. Votre ERP n’a jamais été conçu pour la science des données, mais il fonctionne parfaitement depuis des années, voire des décennies, et les personnes de l’entreprise parviennent à gérer la chaîne d’approvisionnement malgré tout. Même si votre ERP qui collecte des données sur votre chaîne d’approvisionnement n’est pas parfait, ce n’est pas grave. Si vous vous attendez à ce que des données parfaites soient disponibles, c’est simplement de la pensée magique. Nous parlons de chaînes d’approvisionnement ; le monde est très complexe, donc les systèmes sont imparfaits. En réalité, vous n’avez pas un seul système commercial ; vous en avez une demi-douzaine, et ils ne sont pas complètement cohérents les uns avec les autres. C’est un fait de la vie. Cependant, lorsque les éditeurs de logiciels d’entreprise rejettent la faute sur les mauvaises données, la réalité est qu’un modèle de prévision très spécifique est utilisé par l’éditeur, et ce modèle a été conçu avec un ensemble spécifique d’hypothèses sur l’entreprise. Le problème est que si votre entreprise viole l’une de ces hypothèses, la technologie s’effondre complètement. Dans cette situation, vous avez un modèle de prévision qui repose sur des hypothèses déraisonnables, vous alimentez les données, elles ne sont pas parfaites, et donc la technologie s’effondre. Il est tout à fait déraisonnable de dire que l’entreprise est en faute. La technologie en faute est celle poussée par l’éditeur qui fait des hypothèses complètement irréalistes sur les données pouvant être présentes dans un contexte de chaîne d’approvisionnement.

Je n’ai présenté aucun benchmark pour une quelconque mesure de précision aujourd’hui. Cependant, ma proposition est que ces mesures de précision sont principalement insignifiantes. Un modèle prédictif est un outil pour prendre des décisions. Ce qui importe, c’est si ces décisions - quoi acheter, quoi produire, augmenter ou diminuer votre prix - sont bonnes ou mauvaises. Les mauvaises décisions peuvent être attribuées au modèle prédictif, c’est vrai. Cependant, la plupart du temps, ce n’est pas un problème de précision. Par exemple, nous avions un modèle de prévision des ventes, et nous avons corrigé l’angle de rupture de stock qui n’était pas géré de manière appropriée. Cependant, lorsque nous avons corrigé l’angle de rupture de stock, ce que nous avons fait, c’est corriger la mesure de précision elle-même. Donc, corriger le modèle prédictif ne signifie pas améliorer la précision ; très fréquemment, cela signifie littéralement revoir le problème et la perspective dans lesquels vous opérez, et ainsi modifier la mesure de précision ou quelque chose de plus profond. Le problème avec la perspective classique est qu’elle suppose que la mesure de précision est un objectif valable. Ce n’est pas tout à fait le cas.

Les chaînes d’approvisionnement opèrent dans un monde réel, et il y a beaucoup d’événements inattendus, voire même étranges. Par exemple, vous pouvez avoir une obstruction du canal de Suez due à un navire ; c’est un événement complètement étrange. Dans une telle situation, cela invaliderait immédiatement tous les modèles de prévision des délais existants qui regardaient cette partie du monde. Évidemment, cela n’était pas vraiment arrivé auparavant, donc nous ne pouvons pas vraiment tester quoi que ce soit dans une telle situation. Cependant, même si nous avons cette situation complètement exceptionnelle avec un navire bloquant le canal de Suez, nous pouvons quand même corriger le modèle, au moins si nous avons cette approche de boîte blanche que je propose aujourd’hui. Cette correction va impliquer une part de conjecture, ce qui est acceptable. Il vaut mieux être approximativement juste que précisément faux. Par exemple, si nous regardons le canal de Suez bloqué, vous pouvez simplement dire : “ajoutons un mois au délai de livraison pour toutes les fournitures qui étaient censées passer par cette voie”. C’est très approximatif, mais il vaut mieux supposer qu’il n’y aura aucun retard du tout, bien que vous ayez déjà l’information. De plus, le changement vient souvent de l’intérieur. Par exemple, considérons un réseau de vente au détail qui a un ancien centre de distribution et un nouveau centre de distribution approvisionnant quelques dizaines de magasins. Disons qu’il y a une migration en cours, où essentiellement les fournitures pour les magasins sont migrées du vieux centre de distribution vers le nouveau. Cette situation se produit presque une seule fois dans l’histoire de ce détaillant spécifique, et elle ne peut pas vraiment être testée en arrière. Pourtant, avec une approche comme la programmation différentiable, il est tout à fait simple de mettre en œuvre un modèle qui s’adapterait à cette migration progressive.

En conclusion, la programmation différentiable est une technologie qui nous donne une approche pour structurer nos connaissances sur l’avenir. La programmation différentiable nous permet de façonner, littéralement, notre vision de l’avenir. La programmation différentiable se situe du côté de la perception de cette image. Sur la base de cette perception, nous pouvons prendre de meilleures décisions pour les chaînes d’approvisionnement, et ces décisions entraînent les actions qui se trouvent de l’autre côté de l’image. Une des plus grandes incompréhensions de la théorie dominante de la chaîne d’approvisionnement est que l’on peut traiter la perception et l’action de manière isolée, comme des composants strictement isolés. Cela prend la forme, par exemple, d’avoir une équipe en charge de la planification (c’est la perception) et une équipe indépendante en charge du réapprovisionnement (c’est l’action).

Cependant, la boucle de rétroaction perception-action est très importante ; elle est d’une importance primordiale. C’est littéralement le mécanisme même qui vous guide vers une forme correcte de perception. Si vous n’avez pas cette boucle de rétroaction, il n’est même pas clair si vous regardez la bonne chose, ou si la chose que vous regardez est vraiment ce que vous pensez qu’elle est. Vous avez besoin de ce mécanisme de rétroaction, et c’est grâce à cette boucle de rétroaction que vous pouvez réellement orienter vos modèles vers une évaluation quantitative correcte de l’avenir qui est pertinente pour les actions de votre chaîne d’approvisionnement. Les approches dominantes de la chaîne d’approvisionnement négligent presque entièrement ce cas, car, essentiellement, je pense qu’elles sont bloquées avec une forme très rigide de prévision. Cette forme de prévision centrée sur le modèle peut être un vieux modèle, comme le modèle de prévision de Holt-Winters, ou un modèle récent comme Facebook Prophet. La situation est la même : si vous êtes coincé avec un modèle de prévision, alors tous les retours que vous pouvez obtenir du côté action de l’image sont inutiles car vous ne pouvez rien faire de ce retour à part l’ignorer complètement.

Si vous êtes coincé avec un modèle de prévision donné, vous ne pouvez pas reformater ou restructurer votre modèle au fur et à mesure que vous obtenez des informations du côté action. En revanche, la programmation différentiable, avec son approche de modélisation structurée, vous offre un paradigme complètement différent. Le modèle prédictif est entièrement jetable - tout le modèle. Si le retour que vous obtenez de votre action appelle à des changements radicaux dans votre perspective prédictive, il vous suffit de mettre en œuvre ces changements radicaux. Il n’y a pas d’attachement spécifique à une itération donnée du modèle. Garder le modèle très simple permet de s’assurer que, une fois en production, vous conservez la possibilité de continuer à changer ce modèle. Parce que, encore une fois, si ce que vous avez conçu est comme une bête, un monstre d’ingénierie, alors une fois en production, il devient incroyablement difficile de le changer. Un des aspects clés est que si vous voulez pouvoir continuer à changer, vous devez avoir un modèle qui est très parcimonieux en termes de lignes de code et de complexité interne. C’est là que la programmation différentiable brille. Il ne s’agit pas d’atteindre une plus grande précision ; il s’agit d’atteindre une plus grande pertinence. Sans pertinence, toutes les mesures de précision sont complètement inutiles. La programmation différentiable et la modélisation structurée vous permettent d’atteindre la pertinence et de la maintenir dans le temps.

Cela conclut la conférence d’aujourd’hui. La prochaine fois, le 2 mars, à la même heure, 15h heure de Paris, je présenterai la modélisation probabiliste pour la chaîne d’approvisionnement. Nous examinerons de plus près les implications techniques de l’examen de tous les futurs possibles au lieu de simplement choisir un futur et de le déclarer comme le bon. En effet, regarder tous les futurs possibles est très important si vous voulez que votre chaîne d’approvisionnement soit efficacement résiliente face aux risques. Si vous ne choisissez qu’un seul futur, c’est une recette pour finir avec quelque chose d’incroyablement fragile si votre prévision ne s’avère pas parfaitement correcte. Et devinez quoi, la prévision n’est jamais complètement correcte. C’est pourquoi il est très important d’adopter l’idée que vous devez regarder tous les futurs possibles, et nous verrons comment le faire avec des recettes numériques modernes.

Question : On ajoute du bruit stochastique pour éviter les minima locaux, mais comment est-il utilisé ou mis à l’échelle pour éviter de grandes déviations afin que la descente de gradient ne soit pas éloignée de son objectif ?

C’est une question très intéressante, et il y a deux parties à cette réponse.

Tout d’abord, c’est pourquoi l’algorithme Adam est très conservateur en termes d’amplitude des mouvements. Le gradient est fondamentalement non borné ; il peut avoir une valeur de milliers ou de millions. Cependant, avec Adam, la taille maximale du pas est en réalité bornée par le taux d’apprentissage. Ainsi, en pratique, Adam utilise une recette numérique qui impose littéralement une taille maximale du pas, et cela évite, espérons-le, une instabilité numérique massive.

Maintenant, si au hasard, malgré le fait que nous ayons ce taux d’apprentissage, nous pourrions dire que simplement par fluctuation pure, nous allons nous déplacer de manière itérative, un pas à la fois, mais de nombreuses fois dans une direction incorrecte, c’est une possibilité. C’est pourquoi je dis que la descente de gradient stochastique n’est toujours pas complètement comprise. Elle fonctionne incroyablement bien en pratique, mais pourquoi elle fonctionne si bien, pourquoi elle converge si rapidement, et pourquoi nous n’avons pas plus de problèmes qui pourraient survenir, n’est pas complètement compris, surtout si l’on considère que la descente de gradient stochastique se produit dans des dimensions élevées. Typiquement, vous avez littéralement des dizaines, voire des centaines, de paramètres qui sont modifiés à chaque étape. L’intuition que vous pouvez avoir en deux ou trois dimensions est très trompeuse ; les choses se comportent très différemment lorsque vous regardez des dimensions plus élevées.

Donc, en résumé pour cette question : c’est très pertinent. Il y a une partie où c’est la magie d’Adam d’être très conservateur avec l’échelle des pas de gradient, et l’autre partie, qui est mal comprise mais qui fonctionne très bien en pratique. D’ailleurs, je pense que le fait que la descente de gradient stochastique ne soit pas complètement intuitive est également la raison pour laquelle pendant près de 70 ans, cette technique était connue mais pas reconnue comme efficace. Pendant près de 70 ans, les gens savaient qu’elle existait, mais ils étaient très sceptiques. Il a fallu le succès massif de l’apprentissage profond pour que la communauté reconnaisse et admette qu’elle fonctionne très bien, même si nous ne comprenons pas vraiment pourquoi.

Question : Comment comprendre quand un certain motif est faible et doit donc être supprimé du modèle ?

Encore une très bonne question. Il n’y a pas de critère strict ; c’est littéralement une décision du scientifique de la chaîne d’approvisionnement. La raison en est que si le motif que vous introduisez vous apporte des avantages minimes, mais en termes de modélisation, il ne représente que deux lignes de code et l’impact en termes de temps de calcul est négligeable, et si vous voulez supprimer le motif plus tard, cela reste relativement simple, vous pourriez dire : “Eh bien, je peux le garder. Il ne semble pas nuire, il ne fait pas beaucoup de bien. Je peux imaginer des situations où ce motif qui est faible maintenant pourrait devenir fort.” En termes de maintenabilité, c’est bien.

Cependant, vous pouvez également voir l’autre côté de la médaille où vous avez un motif qui ne capture pas grand-chose et qui ajoute beaucoup de calcul au modèle. Ce n’est pas gratuit ; chaque fois que vous ajoutez un paramètre ou une logique, vous allez augmenter la quantité de ressources de calcul nécessaires pour votre modèle, le rendant plus lent et plus difficile à gérer. Si vous pensez que ce motif qui est faible pourrait en fait devenir fort, mais de manière négative, générant de l’instabilité et créant des problèmes dans votre modélisation prédictive, c’est généralement le genre de situation où vous penseriez : “Non, je devrais probablement le supprimer.”

Vous voyez, c’est vraiment une question de jugement. La programmation différentiable est une culture ; vous n’êtes pas seul. Vous avez des collègues et des pairs qui ont peut-être essayé différentes choses chez Lokad. C’est le genre de culture que nous essayons de cultiver. Je sais que cela peut être un peu décevant par rapport à la perspective de l’IA toute-puissante, l’idée que nous pourrions avoir une intelligence artificielle toute-puissante résolvant tous ces problèmes pour nous. Mais la réalité est que les chaînes d’approvisionnement sont si complexes et nos techniques d’intelligence artificielle sont si rudimentaires que nous n’avons aucun substitut réaliste à l’intelligence humaine. Quand je parle de jugement, je veux simplement dire que vous avez besoin d’une bonne dose d’intelligence humaine appliquée au cas, car tous les tours algorithmiques ne sont même pas proches de fournir une réponse satisfaisante.

Néanmoins, cela ne signifie pas que vous ne pouvez pas concevoir une sorte d’outillage. Ce serait un autre sujet ; je verrai si je vais effectivement couvrir le genre d’outillage que nous fournissons chez Lokad pour faciliter la conception. Un motif tangentiel serait, si nous devons prendre une décision, essayons de fournir tous les instruments nécessaires pour que cette décision puisse être prise très rapidement, minimisant ainsi la douleur liée à ce genre d’indécision où le scientifique de la chaîne d’approvisionnement doit décider quelque chose sur le sort de l’état actuel du modèle.

Question : Quel est le seuil de complexité d’une chaîne d’approvisionnement après lequel l’apprentissage automatique et la programmation différentiable apportent des résultats considérablement meilleurs ?

Chez Lokad, nous parvenons généralement à obtenir des résultats substantiels pour les entreprises qui ont un chiffre d’affaires de 10 millions de dollars par an et plus. Je dirais que cela commence vraiment à briller si vous avez une entreprise avec un chiffre d’affaires annuel de 50 millions de dollars et plus.

La raison en est qu’en fin de compte, vous devez établir un pipeline de données très fiable. Vous devez être capable d’extraire toutes les données pertinentes de l’ERP quotidiennement. Je ne veux pas dire que ce seront de bonnes données ou de mauvaises données, simplement les données que vous avez peuvent comporter de nombreux défauts. Néanmoins, cela signifie qu’il y a beaucoup de plomberie juste pour pouvoir extraire les transactions de base au quotidien. Si l’entreprise est trop petite, elle n’a généralement même pas de service informatique dédié et elle ne peut pas parvenir à une extraction quotidienne fiable, ce qui compromet vraiment les résultats.

Maintenant, en termes de secteurs d’activité ou de complexité, la chose est que, dans la plupart des entreprises et des chaînes d’approvisionnement, à mon avis, elles n’ont même pas commencé à optimiser. Comme je l’ai dit, la théorie dominante de la chaîne d’approvisionnement insiste sur le fait que vous devriez rechercher des prévisions plus précises. Avoir un pourcentage réduit d’erreur de prévision est un objectif, et de nombreuses entreprises, par exemple, s’y attaquent en ayant une équipe de planification ou une équipe de prévision. À mon avis, tout cela n’ajoute rien de valeur à l’entreprise car cela fournit fondamentalement des réponses très sophistiquées à un ensemble de questions erroné.

Cela peut surprendre, mais la programmation différentiable brille vraiment non pas parce qu’elle est fondamentalement très puissante - ce qu’elle est - mais parce que c’est généralement la première fois qu’il y a quelque chose de vraiment pertinent pour l’entreprise mis en place dans l’entreprise. Si vous voulez juste un exemple, la plupart de ce qui est mis en œuvre dans la chaîne d’approvisionnement est généralement des modèles comme le modèle de stock de sécurité, qui n’a absolument aucune pertinence pour une chaîne d’approvisionnement réelle. Par exemple, dans le modèle de stock de sécurité, vous supposez qu’il est possible d’avoir un délai de livraison négatif, ce qui signifie que vous commandez maintenant et que vous serez livré hier. Cela n’a aucun sens, et par conséquent, les résultats opérationnels pour les stocks de sécurité sont généralement insatisfaisants.

La programmation différentiable brille en atteignant la pertinence, pas en atteignant une sorte de supériorité numérique grandiose ou en étant meilleure que d’autres techniques d’apprentissage automatique alternatives. L’objectif est vraiment d’atteindre la pertinence dans un monde très complexe, chaotique, adversarial, en constante évolution, et où vous devez faire face à un paysage applicatif semi-cauchemardesque qui représente les données que vous devez traiter.

Il semble qu’il n’y ait plus de questions. Dans ce cas, je suppose que je vous retrouverai le mois prochain pour le cours de modélisation probabiliste pour la chaîne d’approvisionnement.