Strukturierte prädiktive Modellierung für die Supply Chain - Vorlesung 5.1

00:01 Einführung
02:44 Überblick über prädiktive Anforderungen
05:57 Modelle vs. Modellierung
12:26 Der bisherige Verlauf
15:50 Ein wenig Theorie und ein wenig Praxis
17:41 Differentiable Programming, SGD 1/6
24:56 Differentiable Programming, Autodiff 2/6
31:07 Differentiable Programming, Funktionen 3/6
35:35 Differentiable Programming, Meta-Parameter 4/6
37:59 Differentiable Programming, Parameter 5/6
40:55 Differentiable Programming, Eigenheiten 6/6
43:41 Durchgehen, Einzelhandelsnachfrageprognose
45:49 Durchgehen, Parameteranpassung 1/6
53:14 Durchgehen, Parameterfreigabe 2/6
01:04:16 Durchgehen, Verlustmaskierung 3/6
01:09:34 Durchgehen, Integration von Kovariablen 4/6
01:14:09 Durchgehen, Sparse Decomposition 5/6
01:21:17 Durchgehen, Frei-Skalierung 6/6
01:25:14 Whiteboxing
01:33:22 Zurück zur experimentellen Optimierung
01:39:53 Fazit
01:44:40 Bevorstehende Vorlesung und Fragen des Publikums

Beschreibung

Differentiable Programming (DP) ist ein generatives Paradigma, das verwendet wird, um eine breite Klasse statistischer Modelle zu entwickeln, die sich hervorragend für prädiktive Herausforderungen in der Supply Chain eignen. DP übertrifft nahezu die gesamte “klassische” Prognoseliteratur, die auf parametrischen Modellen basiert. DP ist auch den “klassischen” Machine Learning Algorithmen - bis in die späten 2010er Jahre - in praktisch jeder relevanten Dimension überlegen, die für eine praktische Anwendung in der Supply Chain wichtig ist, einschließlich der Benutzerfreundlichkeit für Praktiker.

Vollständiges Transkript

Willkommen zu dieser Reihe von Vorlesungen zur Supply Chain. Ich bin Joannes Vermorel und heute werde ich “Strukturierte prädiktive Modellierung mit Differentiable Programming in der Supply Chain” präsentieren. Die richtige Handlungsweise erfordert detaillierte quantitative Einblicke in die Zukunft. Jede Entscheidung - mehr kaufen, mehr produzieren - spiegelt eine gewisse Erwartung an die Zukunft wider. Die Mainstream-Theorie der Supply Chain betont unweigerlich den Begriff der Prognose, um dieses Problem zu lösen. Die Prognoseperspektive, zumindest in ihrer klassischen Form, weist jedoch zwei Mängel auf.

Erstens betont sie eine enge Perspektive der Zeitreihen Prognose, die leider nicht die Vielfalt der Herausforderungen in realen Supply Chains berücksichtigt. Zweitens betont sie einen engen Fokus auf die Prognosegenauigkeit von Zeitreihen, der auch weitgehend am Ziel vorbeigeht. Eine geringfügige Verbesserung der Genauigkeit führt nicht automatisch zu einem zusätzlichen Gewinn für Ihre Supply Chain.

Das Ziel der vorliegenden Vorlesung ist es, einen alternativen Ansatz zur Prognose zu entdecken, der teilweise auf Technologie und teilweise auf Methodik basiert. Die Technologie wird Differentiable Programming sein und die Methodik wird strukturierte prädiktive Modelle sein. Am Ende dieser Vorlesung sollten Sie in der Lage sein, diesen Ansatz auf eine Supply Chain-Situation anzuwenden. Dieser Ansatz ist nicht theoretisch; er ist seit einigen Jahren der Standardansatz von Lokad. Wenn Sie die vorherigen Vorlesungen noch nicht gesehen haben, sollte die vorliegende Vorlesung nicht völlig unverständlich sein. In dieser Vorlesungsreihe erreichen wir jedoch einen Punkt, an dem es sehr hilfreich sein sollte, die Vorlesungen tatsächlich in der richtigen Reihenfolge anzusehen. In der vorliegenden Vorlesung werden wir viele Elemente wieder aufgreifen, die in früheren Vorlesungen eingeführt wurden.

Die Prognose der zukünftigen Nachfrage ist der offensichtliche Kandidat, wenn es um die Erfüllung der prädiktiven Anforderungen für unsere Supply Chain geht. Eine bessere Vorhersage der Nachfrage ist in der Tat eine entscheidende Voraussetzung für grundlegende Entscheidungen wie den Kauf von mehr Produkten und die Erhöhung der Produktion. Durch die Supply Chain-Prinzipien, die wir im Verlauf des dritten Kapitels dieser Vorlesungsreihe eingeführt haben, haben wir jedoch gesehen, dass es eine recht vielfältige Palette von Erwartungen gibt, die Sie in Bezug auf prädiktive Anforderungen haben können, um Ihre Supply Chain zu steuern.

Insbesondere variieren zum Beispiel Durchlaufzeiten und Durchlaufzeiten weisen saisonale Muster auf. Praktisch jede einzelne Entscheidung im Zusammenhang mit dem Lagerbestand erfordert eine Vorhersage der zukünftigen Nachfrage, aber auch eine Vorhersage der zukünftigen Durchlaufzeit. Daher müssen Durchlaufzeiten prognostiziert werden. Rücksendungen machen manchmal sogar die Hälfte des Umsatzes aus. Dies ist zum Beispiel bei Fashion-E-Commerce in Deutschland der Fall. In solchen Situationen ist es entscheidend, die Rücksendungen vorherzusagen, und diese Rücksendungen variieren stark von einem Produkt zum anderen. Daher müssen in solchen Situationen Rücksendungen prognostiziert werden.

Auf der Angebotsseite kann sich die Produktion selbst ändern und das nicht nur aufgrund von zusätzlichen Verzögerungen oder variablen Durchlaufzeiten. Zum Beispiel kann die Produktion mit einem gewissen Grad an Unsicherheit verbunden sein. Dies geschieht in Low-Tech-Bereichen wie der Landwirtschaft, kann aber auch in High-Tech-Bereichen wie der Pharmaindustrie vorkommen. Daher müssen auch Produktionsausbeuten prognostiziert werden. Schließlich spielt auch das Verhalten der Kunden eine große Rolle. Zum Beispiel ist es sehr wichtig, die Nachfrage durch Produkte zu steuern, die den Erwerb fördern, und umgekehrt ist es wichtig, mit Lieferengpässen bei Produkten umzugehen, die aufgrund von Lieferengpässen zu einer großen Fluktuation führen, wenn diese Produkte fehlen. Daher erfordern diese Verhaltensweisen Analyse, Vorhersage - mit anderen Worten, sie müssen prognostiziert werden. Die wichtigste Erkenntnis hier ist, dass die Prognose von Zeitreihen nur ein Teil des Puzzles ist. Wir benötigen einen prädiktiven Ansatz, der all diese Situationen und mehr umfassen kann, da dies notwendig ist, wenn wir einen Ansatz haben wollen, der eine Chance hat, erfolgreich mit all den Situationen umzugehen, mit denen eine reale Supply Chain konfrontiert wird.

Der Standardansatz bei prädiktiven Problemen besteht darin, ein Modell zu präsentieren. Dieser Ansatz hat die Literatur zur Zeitreihenprognose seit Jahrzehnten geprägt und ist meiner Meinung nach immer noch der vorherrschende Ansatz in den Kreisen des maschinellen Lernens. Dieser modellzentrierte Ansatz, so werde ich diesen Ansatz nennen, ist so weit verbreitet, dass es vielleicht sogar schwer ist, einen Moment innezuhalten und zu bewerten, was mit dieser modellzentrierten Perspektive wirklich passiert.

Mein Vorschlag für diese Vorlesung ist, dass die Supply Chain eine Modellierungstechnik erfordert, eine modellzentrierte Perspektive, und dass eine Reihe von Modellen, egal wie umfangreich sie sind, niemals ausreichen wird, um alle Anforderungen zu erfüllen, wie sie in realen Supply Chains vorkommen. Lassen Sie uns diese Unterscheidung zwischen dem modellzentrierten Ansatz und dem modellzentrierten Ansatz klären.

Der modellzentrierte Ansatz legt den Schwerpunkt in erster Linie auf ein Modell. Das Modell wird als Paket geliefert, eine Reihe von numerischen Rezepten, die in der Regel in Form einer Software vorliegen, die tatsächlich ausgeführt werden kann. Selbst wenn keine solche Software verfügbar ist, wird die Erwartung so gesetzt, dass das Modell, wenn Sie ein Modell, aber nicht die Software haben, mit mathematischer Präzision beschrieben werden kann, was eine vollständige Neuimplementierung des Modells ermöglicht. Dieses Paket, das aus dem Modell erstellte Software, soll das Endziel sein.

Aus einer idealisierten Perspektive soll dieses Modell genau wie eine mathematische Funktion funktionieren: Eingaben rein, Ergebnisse raus. Wenn für das Modell noch Konfigurierbarkeit übrig ist, werden diese konfigurierbaren Elemente als offene Enden behandelt, als Probleme, die noch vollständig gelöst werden müssen. Tatsächlich schwächt jede Konfigurationsoption den Fall des Modells. Wenn wir Konfigurierbarkeit und zu viele Optionen aus der modellzentrierten Perspektive haben, neigt das Modell dazu, sich in einen Raum von Modellen aufzulösen, und plötzlich können wir nichts mehr wirklich benchmarken, weil es so etwas wie ein einzelnes Modell nicht gibt.

Der modellzentrierte Ansatz nimmt einen völlig umgekehrten Ansatz zum Thema Konfigurierbarkeit ein. Die Maximierung der Ausdruckskraft des Modells wird zum Endziel. Dies ist kein Fehler; es wird zu einem Merkmal. Die Situation kann ziemlich verwirrend sein, wenn wir uns eine modellzentrierte Perspektive ansehen, denn wenn wir uns eine Präsentation einer modellzentrierten Perspektive ansehen, werden wir eine Präsentation von Modellen sehen. Diese Modelle haben jedoch eine ganz andere Absicht.

Wenn Sie die modellzentrierte Perspektive einnehmen, ist das präsentierte Modell nur eine Illustration. Es wird nicht mit der Absicht präsentiert, vollständig oder die endgültige Lösung für das Problem zu sein. Es ist nur ein Schritt in der Reise, um die Modellierungstechnik selbst zu veranschaulichen. Die Hauptherausforderung bei der Modellierungstechnik besteht darin, dass es plötzlich sehr schwierig wird, den Ansatz zu bewerten. Tatsächlich verlieren wir die naive Benchmarking-Option, weil wir mit dieser modellzentrierten Perspektive Potenziale von Modellen haben. Wir konzentrieren uns nicht speziell auf ein Modell im Vergleich zu einem anderen; das ist nicht einmal die richtige Denkweise. Was wir haben, ist eine fundierte Meinung.

Allerdings möchte ich sofort darauf hinweisen, dass es nicht automatisch als wissenschaftlich qualifiziert wird, nur weil Sie einen Benchmark und Zahlen an Ihren Benchmark angehängt haben. Die Zahlen können einfach unsinnig sein, und umgekehrt ist es nicht weniger wissenschaftlich, nur weil es eine fundierte Meinung ist. In gewisser Weise ist es einfach ein anderer Ansatz, und die Realität ist, dass die beiden Ansätze in verschiedenen Gemeinschaften nebeneinander existieren.

Wenn wir uns zum Beispiel das Papier “Forecasting at Scale” ansehen, das 2017 von einem Team bei Facebook veröffentlicht wurde, haben wir etwas, das ziemlich genau das Archetyp des modellzentrierten Ansatzes ist. In diesem Papier wird das Facebook Prophet-Modell vorgestellt. Und in einem anderen Papier, “Tensor Comprehension”, das 2018 von einem anderen Team bei Facebook veröffentlicht wurde, haben wir im Wesentlichen eine Modellierungstechnik. Dieses Papier kann als Archetyp des modellzentrierten Ansatzes angesehen werden. Sie können also sehen, dass selbst Forschungsteams, die in derselben Firma arbeiten, praktisch zur gleichen Zeit das Problem aus unterschiedlichen Blickwinkeln angehen können, je nach Situation.

Diese Vorlesung ist Teil einer Reihe von Vorlesungen zur Lieferkette. Im ersten Kapitel habe ich meine Ansichten zur Lieferkette sowohl als Forschungsfeld als auch als Praxis vorgestellt. Schon von der ersten Vorlesung an habe ich argumentiert, dass die gängige Lieferketten-Theorie nicht den Erwartungen gerecht wird. Es kommt vor, dass die gängige Lieferketten-Theorie stark auf den modellzentrierten Ansatz setzt, und ich glaube, dass dieser Aspekt einer der Hauptgründe für die Reibung zwischen der gängigen Lieferketten-Theorie und den Bedürfnissen realer Lieferketten ist.

Im zweiten Kapitel dieser Vorlesungsreihe habe ich eine Reihe von Methoden vorgestellt. Tatsächlich werden die naiven Methoden in der Regel durch die episodische und häufig konfliktreiche Natur von Lieferketten-Situationen besiegt. Insbesondere die Vorlesung mit dem Titel “Empirische Experimentelle Optimierung”, die Teil des zweiten Kapitels war, ist die Art von Perspektive, die ich heute in dieser Vorlesung einnehme.

Im dritten Kapitel habe ich eine Reihe von Lieferketten-Personae vorgestellt. Die Personae repräsentieren einen exklusiven Fokus auf die Probleme, die wir zu lösen versuchen, ohne jegliche Lösungskandidaten zu berücksichtigen. Diese Personae sind entscheidend, um die Vielfalt der vorhersehbaren Herausforderungen zu verstehen, denen reale Lieferketten gegenüberstehen. Ich glaube, dass diese Personae unerlässlich sind, um nicht in der engen Perspektive der Zeitreihen gefangen zu sein, die ein Kennzeichen einer Lieferketten-Theorie ist, die mit wenig Aufmerksamkeit für die Details realer Lieferketten ausgeübt wird.

Im vierten Kapitel habe ich eine Reihe von Hilfswissenschaften vorgestellt. Diese Wissenschaften sind von der Lieferkette getrennt, aber ein grundlegendes Verständnis dieser Disziplinen ist für die moderne Lieferkettenpraxis unerlässlich. Wir haben in diesem vierten Kapitel bereits kurz das Thema der differenzierbaren Programmierung behandelt, aber ich werde dieses Programmierparadigma in wenigen Minuten noch einmal ausführlicher vorstellen.

Schließlich haben wir in der ersten Vorlesung dieses fünften Kapitels ein einfaches, manche würden sogar sagen simplistisches Modell gesehen, das im Jahr 2020 in einem weltweiten Prognosewettbewerb eine Spitzenprognosegenauigkeit erreicht hat. Heute präsentiere ich eine Reihe von Techniken, die verwendet werden können, um die mit diesem Modell verbundenen Parameter zu erlernen, das ich in der vorherigen Vorlesung vorgestellt habe.

Der Rest dieser Vorlesung wird grob in zwei Teile gegliedert sein, gefolgt von einigen abschließenden Gedanken. Der erste Teil ist der differenzierbaren Programmierung gewidmet. Wir haben dieses Thema bereits im vierten Kapitel behandelt, werden uns jedoch heute genauer damit befassen. Am Ende dieser Vorlesung sollten Sie fast in der Lage sein, Ihre eigene Implementierung der differenzierbaren Programmierung zu erstellen. Ich sage “fast”, weil dies je nach der von Ihnen verwendeten Technologieplattform variieren kann. Außerdem ist die differenzierbare Programmierung an sich eine kleine Kunst; es erfordert etwas Erfahrung, um sie reibungslos in der Praxis zum Laufen zu bringen.

Der zweite Teil dieser Vorlesung ist ein Durchgang für eine Einzelhandelsnachfrageprognose-Situation. Dieser Durchgang baut auf der vorherigen Vorlesung auf, in der wir das Modell vorgestellt haben, das im Jahr 2020 den ersten Platz im M5-Prognosewettbewerb erreicht hat. In dieser vorherigen Präsentation haben wir jedoch nicht detailliert erläutert, wie die Parameter des Modells tatsächlich berechnet wurden. Dieser Durchgang wird genau das liefern, und wir werden auch wichtige Elemente wie Lagerbestände und Promotions, die in der vorherigen Vorlesung nicht behandelt wurden, abdecken. Schließlich werde ich auf der Grundlage all dieser Elemente meine Ansichten zur Eignung der differenzierbaren Programmierung für Lieferkettenzwecke diskutieren.

Der stochastische Gradientenabstieg (SGD) ist einer der beiden Grundpfeiler der differenzierbaren Programmierung. Der SGD ist trügerisch einfach, und doch ist immer noch nicht vollständig klar, warum er so gut funktioniert. Es ist absolut klar, warum er funktioniert; was nicht sehr klar ist, ist, warum er so gut funktioniert.

Die Geschichte des stochastischen Gradientenabstiegs reicht bis in die 1950er Jahre zurück, daher hat er eine ziemlich lange Geschichte. Diese Technik erlangte jedoch erst in den letzten zehn Jahren mit dem Aufkommen des Deep Learning eine breite Anerkennung. Der stochastische Gradientenabstieg ist tief in der mathematischen Optimierungsperspektive verwurzelt. Wir haben eine Verlustfunktion Q, die wir minimieren möchten, und wir haben eine Menge realer Parameter, die mit W bezeichnet werden und alle möglichen Lösungen darstellen. Was wir finden möchten, ist die Kombination der Parameter W, die die Verlustfunktion Q minimiert.

Die Verlustfunktion Q soll eine grundlegende Eigenschaft aufrechterhalten: Sie kann additiv in eine Reihe von Termen zerlegt werden. Das Vorhandensein dieser additiven Zerlegung ermöglicht es dem stochastischen Gradientenabstieg überhaupt zu funktionieren. Wenn Ihre Verlustfunktion nicht additiv wie hier zerlegt werden kann, ist der stochastische Gradientenabstieg keine anwendbare Technik. In dieser Perspektive repräsentiert X die Menge aller Terme, die zur Verlustfunktion beitragen, und Qx repräsentiert einen Teilverlust, der den Verlust für einen der Terme in dieser Perspektive darstellt, in der die Verlustfunktion als Summe von Teilbeträgen betrachtet wird.

Obwohl der stochastische Gradientenabstieg nicht spezifisch für Lernsituationen ist, passt er sehr gut zu allen Lernanwendungsfällen, und wenn ich Lernen sage, meine ich Lernen im Sinne von maschinellem Lernen. Wenn wir tatsächlich einen Trainingsdatensatz haben, hat dieser Datensatz die Form einer Liste von Beobachtungen, wobei jede Beobachtung ein Paar von Merkmalen darstellt, die die Eingabe des Modells repräsentieren, und Labels, die die Ausgabe repräsentieren. Im Wesentlichen möchten wir aus einer Lernperspektive ein Modell entwickeln, das auf dem empirischen Fehler und anderen Dingen basierend auf diesem Trainingsdatensatz am besten abschneidet. Aus einer Lernperspektive wäre X tatsächlich die Liste der Beobachtungen und die Parameter wären die Parameter eines maschinellen Lernmodells, die wir optimieren möchten, um am besten zu diesem Datensatz zu passen.

Der stochastische Gradientenabstieg ist grundsätzlich ein iterativer Prozess, der zufällig durch die Beobachtungen iteriert, eine Beobachtung nach der anderen. Wir wählen eine Beobachtung, ein kleines X, aus und berechnen für diese Beobachtung einen lokalen Gradienten, der als nabla von Qx dargestellt wird. Es handelt sich nur um einen lokalen Gradienten, der nur auf einen Term der Verlustfunktion angewendet wird. Dies ist nicht der Gradient der vollständigen Verlustfunktion selbst, sondern ein lokaler Gradient, der nur auf einen Term der Verlustfunktion angewendet wird - Sie können dies als partiellen Gradienten betrachten.

Ein Schritt des stochastischen Gradientenabstiegs besteht darin, diesen lokalen Gradienten zu nehmen und die Parameter W basierend auf dieser partiellen Beobachtung des Gradienten ein wenig zu verschieben. Genau das passiert hier, wobei W mit W minus eta mal nabla QxW aktualisiert wird. Dies bedeutet einfach, in sehr prägnanter Form, den Parameter W in Richtung des sehr lokalen Gradienten zu verschieben, der mit X erhalten wurde, wobei X nur eine der Beobachtungen Ihres Datensatzes ist, wenn wir ein Problem aus einer Lernperspektive angehen. Dann gehen wir zufällig vor, wenden diesen lokalen Gradienten an und iterieren.

Intuitiv funktioniert der stochastische Gradientenabstieg sehr gut, weil er einen Kompromiss zwischen schneller Iteration und rauschenden Gradienten darstellt, bis hin zu feineren und somit schnelleren Iterationen. Das Wesentliche des stochastischen Gradientenabstiegs besteht darin, dass es uns nicht darum geht, sehr unvollkommene Messungen für unsere Gradienten zu haben, solange wir diese unvollkommenen Messungen sehr schnell erhalten können. Wenn wir den Kompromiss bis hin zu schnellerer Iteration verschieben können, selbst auf Kosten von rauschenden Gradienten, dann machen wir das. Deshalb ist der stochastische Gradientenabstieg so effektiv, um die Menge an Rechenressourcen zu minimieren, die benötigt werden, um eine bestimmte Lösungsqualität für den Parameter W zu erreichen.

Schließlich haben wir die Variable eta, die als Lernrate bezeichnet wird. In der Praxis ist die Lernrate keine Konstante; diese Variable variiert während des Fortschritts des stochastischen Gradientenabstiegs. Bei Lokad verwenden wir den Adam-Algorithmus, um die Entwicklung dieses eta-Parameters für die Lernrate zu steuern. Adam ist eine Methode, die 2014 veröffentlicht wurde und in Machine-Learning-Kreisen sehr beliebt ist, wenn der stochastische Gradientenabstieg involviert ist.

Der zweite Pfeiler für differenzierbare Programmierung ist die automatische Differentiation. Wir haben dieses Konzept bereits in einer früheren Vorlesung gesehen. Lassen Sie uns dieses Konzept erneut betrachten, indem wir uns ein Stück Code ansehen. Dieser Code ist in Envision geschrieben, einer domänenspezifischen Programmiersprache, die von Lokad für die Zwecke der prädiktiven Optimierung von Lieferketten entwickelt wurde. Ich wähle Envision, weil die Beispiele, wie Sie sehen werden, im Vergleich zu alternativen Präsentationen mit Python, Java oder C# viel prägnanter und hoffentlich auch viel klarer sind. Ich möchte jedoch darauf hinweisen, dass selbst wenn ich Envision verwende, kein Geheimrezept involviert ist. Sie könnten alle diese Beispiele problemlos in anderen Programmiersprachen neu implementieren. Dies würde wahrscheinlich die Anzahl der Codezeilen um den Faktor 10 erhöhen, aber im großen Ganzen ist dies eine Kleinigkeit. Hier bietet uns Envision für eine Vorlesung eine sehr klare und prägnante Darstellung.

Schauen wir uns an, wie differenzierbare Programmierung verwendet werden kann, um eine lineare Regression anzugehen. Dies ist ein Spielproblem; wir benötigen keine differenzierbare Programmierung, um eine lineare Regression durchzuführen. Das Ziel ist lediglich, mit der differenzierbaren Programmiersyntax vertraut zu werden. Von Zeile 1 bis 6 deklarieren wir die Tabelle T, die die Beobachtungstabelle darstellt. Wenn ich von Beobachtungstabelle spreche, denken Sie einfach an den Stochastischen Gradientenabstiegssatz, der X genannt wurde. Das ist genau dasselbe. Diese Tabelle hat zwei Spalten, ein Merkmal, das mit X bezeichnet wird, und ein Label, das mit Y bezeichnet wird. Was wir wollen, ist, X als Eingabe zu nehmen und in der Lage zu sein, Y mit einem linearen Modell oder genauer gesagt, einem affinen Modell, vorherzusagen. Offensichtlich haben wir in dieser Tabelle T nur vier Datenpunkte. Dies ist ein lächerlich kleiner Datensatz; es dient nur der Klarheit der Darstellung.

In Zeile 8 führen wir den Autodiff-Block ein. Der Autodiff-Block kann in Envision als Schleife betrachtet werden. Es ist eine Schleife, die über eine Tabelle iteriert, in diesem Fall die Tabelle T. Diese Iterationen spiegeln die Schritte des stochastischen Gradientenabstiegs wider. Was passiert, wenn die Ausführung von Envision diesen Autodiff-Block betritt, ist, dass wir eine Reihe von wiederholten Ausführungen haben, bei denen wir Zeilen aus der Beobachtungstabelle auswählen und dann Schritte des stochastischen Gradientenabstiegs anwenden. Dafür benötigen wir die Gradienten.

Woher kommen die Gradienten? Hier haben wir ein Programm geschrieben, einen kleinen Ausdruck unseres Modells, Ax + B. Wir führen die Verlustfunktion ein, die den mittleren quadratischen Fehler darstellt. Wir möchten den Gradienten haben. Für eine so einfache Situation wie diese könnten wir den Gradienten manuell schreiben. Die automatische Differentiation ist jedoch eine Technik, mit der Sie ein Programm in zwei Formen kompilieren können: die erste Form ist die Vorwärtsausführung des Programms, und die zweite Form ist die Rückwärtsausführung, die die Gradienten für alle in dem Programm vorhandenen Parameter berechnet.

In den Zeilen 9 und 10 haben wir die Deklaration von zwei Parametern, A und B, mit dem Schlüsselwort “auto”, das Envision mitteilt, eine automatische Initialisierung für die Werte dieser beiden Parameter durchzuführen. A und B sind skalare Werte. Die automatische Differentiation erfolgt für alle Programme, die in diesem Autodiff-Block enthalten sind. Im Wesentlichen handelt es sich um eine Technik auf Compiler-Ebene, um dieses Programm zweimal zu kompilieren: einmal für den Vorwärtsdurchlauf und ein zweites Mal für ein Programm, das die Werte der Gradienten liefert. Das Schöne an der automatischen Differentiationstechnik ist, dass sie garantiert, dass die Menge an CPU, die benötigt wird, um das reguläre Programm zu berechnen, mit der Menge an CPU übereinstimmt, die benötigt wird, um den Gradienten zu berechnen, wenn Sie den Rückwärtsdurchlauf durchführen. Das ist eine sehr wichtige Eigenschaft. Schließlich drucken wir in Zeile 14 die Parameter aus, die wir gerade mit dem oben stehenden Autodiff-Block gelernt haben.

Differentiable Programming erstrahlt wirklich als Programmierparadigma. Es ist möglich, ein beliebig komplexes Programm zu komponieren und die automatische Differentiation dieses Programms zu erhalten. Dieses Programm kann zum Beispiel Verzweigungen und Funktionsaufrufe enthalten. Dieses Codebeispiel überarbeitet die Pinball Verlustfunktion, die wir in der vorherigen Vorlesung eingeführt haben. Die Pinball-Verlustfunktion kann verwendet werden, um Quantilschätzungen abzuleiten, wenn wir Abweichungen von einer empirischen Wahrscheinlichkeitsverteilung beobachten. Wenn Sie den mittleren quadratischen Fehler mit Ihrer Schätzung minimieren, erhalten Sie eine Schätzung des Mittelwerts Ihrer empirischen Verteilung. Wenn Sie die Pinball-Verlustfunktion minimieren, erhalten Sie eine Schätzung eines Quantilziels. Wenn Sie auf ein 90. Quantil abzielen, bedeutet dies, dass es der Wert in Ihrer Wahrscheinlichkeitsverteilung ist, bei dem die zukünftigen zu beobachtenden Werte eine 90%ige Chance haben, unter Ihrer Schätzung zu liegen, wenn Sie ein 90. Ziel haben, oder eine 10%ige Chance haben, darüber zu liegen. Dies erinnert an die Service Levels-Analyse, die in der Supply Chain existiert.

In den Zeilen 1 und 2 führen wir eine Beobachtungstabelle ein, die mit Abweichungen gefüllt ist, die zufällig aus einer Poisson-Verteilung gezogen wurden. Die Werte der Poisson-Verteilung werden mit einem Mittelwert von 3 gezogen und wir erhalten 10.000 Abweichungen. In den Zeilen 4 und 5 setzen wir unsere maßgeschneiderte Implementierung der Pinball-Verlustfunktion um. Diese Implementierung ist fast identisch mit dem Code, den ich in der vorherigen Vorlesung vorgestellt habe. Das Schlüsselwort “autodiff” wird jedoch jetzt zur Deklaration der Funktion hinzugefügt. Dieses Schlüsselwort stellt sicher, dass der Envision-Compiler diese Funktion automatisch differenzieren kann. Während in der Theorie automatische Differentiation auf jedes Programm angewendet werden kann, gibt es in der Praxis viele Programme, bei denen es keinen Sinn ergibt, sie zu differenzieren, oder viele Funktionen, bei denen es keinen Sinn ergäbe. Betrachten Sie zum Beispiel eine Funktion, die zwei Textwerte entgegennimmt und sie konkateniert. Aus Sicht der automatischen Differentiation ergibt es keinen Sinn, automatische Differentiation auf diese Art von Operation anzuwenden. Automatische Differentiation erfordert, dass Zahlen in der Eingabe und Ausgabe für die Funktionen vorhanden sind, die Sie zu differenzieren versuchen.

In den Zeilen 7 bis 9 haben wir den Autodiff-Block, der die Zielquantilschätzung für die empirische Verteilung berechnet, die durch die Beobachtungstabelle erhalten wurde. Unter der Haube handelt es sich tatsächlich um eine Poisson-Verteilung. Die Quantilschätzung wird als Parameter mit dem Namen “quantile” in Zeile 8 deklariert, und in Zeile 9 rufen wir unsere eigene Implementierung der Pinball-Verlustfunktion auf. Das Quantilziel ist auf 0,5 festgelegt, daher suchen wir tatsächlich nach einer Median-Schätzung der Verteilung. Schließlich drucken wir in Zeile 11 die Ergebnisse für den Wert aus, den wir durch die Ausführung des Autodiff-Blocks gelernt haben. Dieser Codeausschnitt veranschaulicht, wie ein Programm, das wir automatisch differenzieren möchten, sowohl einen Funktionsaufruf als auch eine Verzweigung enthalten kann, und all das kann vollständig automatisch geschehen.

Ich habe gesagt, dass die Autodiff-Blöcke als Schleife interpretiert werden können, die eine Reihe von stochastischen Gradientenabstiegschritten über die Beobachtungstabelle durchführt und dabei jeweils eine Zeile aus dieser Beobachtungstabelle auswählt. Ich bin jedoch ziemlich vage über die Abbruchbedingung für diese Situation geblieben. Wann stoppt der stochastische Gradientenabstieg in Envision? Standardmäßig stoppt der stochastische Gradientenabstieg nach 10 Epochen. Eine Epoche repräsentiert in der Terminologie des maschinellen Lernens einen vollständigen Durchlauf durch die Beobachtungstabelle. In Zeile 7 kann ein Attribut mit dem Namen “epochs” an die Autodiff-Blöcke angehängt werden. Dieses Attribut ist optional, standardmäßig ist der Wert 10, aber wenn Sie dieses Attribut angeben, können Sie eine andere Anzahl auswählen. Hier geben wir 100 Epochen an. Beachten Sie, dass die Gesamtberechnungszeit nahezu strikt linear zur Anzahl der Epochen ist. Wenn Sie also doppelt so viele Epochen haben, dauert die Berechnungszeit doppelt so lange.

Dennoch führen wir in Zeile 7 auch ein zweites Attribut mit dem Namen “learning_rate” ein. Dieses Attribut ist ebenfalls optional und standardmäßig ist der Wert 0,01, das an den Autodiff-Block angehängt ist. Diese Lernrate ist ein Faktor, der verwendet wird, um den Adam-Algorithmus zu initialisieren, der die Entwicklung der Lernrate steuert. Dies ist der Eta-Parameter, den wir im Schritt des stochastischen Gradientenabstiegs gesehen haben. Er steuert den Adam-Algorithmus. Im Wesentlichen ist dies ein Parameter, den Sie nicht häufig anpassen müssen, aber manchmal kann durch die Feinabstimmung dieser Lernrate ein erheblicher Teil der Rechenleistung eingespart werden. Es ist nicht ungewöhnlich, dass Sie durch die Feinabstimmung dieser Lernrate etwa 20% der Gesamtberechnungszeit für Ihren stochastischen Gradientenabstieg einsparen können.

Die Initialisierung der in dem Autodiff-Block erlernten Parameter erfordert ebenfalls eine genauere Betrachtung. Bisher haben wir das Schlüsselwort “auto” verwendet, und in Envision bedeutet dies einfach, dass Envision den Parameter initialisiert, indem es zufällig einen Wert aus einer Gauß-Verteilung mit einem Mittelwert von 1 und einer Standardabweichung von 0,1 zieht. Diese Initialisierung weicht von der üblichen Praxis im Deep Learning ab, bei der die Parameter zufällig mit Gaussverteilungen um Null herum initialisiert werden. Der Grund, warum Lokad diesen anderen Ansatz gewählt hat, wird später in dieser Vorlesung klarer, wenn wir mit einer tatsächlichen Einzelhandelsnachfrageprognose-Situation fortfahren.

In Envision ist es möglich, die Initialisierung der Parameter zu überschreiben und zu kontrollieren. Der Parameter “quantile” zum Beispiel wird in Zeile 9 deklariert, muss aber nicht initialisiert werden. Tatsächlich haben wir in Zeile 7, direkt über dem Autodiff-Block, eine Variable “quantile”, der der Wert 4,2 zugewiesen wird, und somit ist die Variable bereits mit einem bestimmten Wert initialisiert. Eine automatische Initialisierung ist nicht mehr erforderlich. Es ist auch möglich, einen Wertebereich für die Parameter festzulegen, und dies geschieht mit dem Schlüsselwort “in” in Zeile 9. Im Wesentlichen definieren wir, dass “quantile” zwischen 1 und 10 liegen sollte, einschließlich. Mit diesen Grenzen, wenn es ein Update gibt, das durch den Adam-Algorithmus erhalten wird und den Parameterwert außerhalb des akzeptablen Bereichs verschieben würde, begrenzen wir die Änderung von Adam, damit sie innerhalb dieses Bereichs bleibt. Darüber hinaus setzen wir auch die Momentum-Werte auf Null, die normalerweise mit dem Adam-Algorithmus verbunden sind. Die Durchsetzung von Parametergrenzen weicht von der klassischen Deep Learning-Praxis ab; jedoch werden die Vorteile dieser Funktion deutlich, sobald wir ein tatsächliches Beispiel für die Einzelhandelsnachfrageprognose diskutieren.

Differenzierbare Programmierung basiert stark auf stochastischem Gradientenabstieg. Der stochastische Aspekt ist buchstäblich das, was den Abstieg sehr schnell macht. Es ist ein zweischneidiges Schwert; das Rauschen, das durch die partiellen Verluste entsteht, ist nicht nur ein Fehler, sondern auch ein Merkmal. Durch ein wenig Rauschen kann der Abstieg vermeiden, in Zonen mit sehr flachen Gradienten stecken zu bleiben. Daher macht dieses rauschende Gradientenverfahren nicht nur die Iteration viel schneller, sondern hilft auch dabei, die Iteration aus Bereichen herauszuschieben, in denen der Gradient sehr flach ist und den Abstieg verlangsamt. Eine Sache, die jedoch beachtet werden muss, ist, dass bei Verwendung des stochastischen Gradientenabstiegs die Summe des Gradienten nicht der Gradient der Summe ist. Daher weist der stochastische Gradientenabstieg geringfügige statistische Verzerrungen auf, insbesondere wenn Schwanzverteilungen betroffen sind. Wenn jedoch diese Bedenken auftreten, ist es relativ einfach, die numerischen Rezepte zu beheben, auch wenn die Theorie ein wenig unklar bleibt.

Differenzierbare Programmierung (DP) sollte nicht mit einem beliebigen mathematischen Optimierungslöser verwechselt werden. Der Gradient muss durch das Programm fließen, damit differenzierbare Programmierung überhaupt funktioniert. Differenzierbare Programmierung kann mit beliebig komplexen Programmen arbeiten, aber diese Programme müssen mit differenzierbarer Programmierung im Hinterkopf entwickelt werden. Außerdem ist differenzierbare Programmierung eine Kultur; es ist eine Sammlung von Tipps und Tricks, die gut mit stochastischem Gradientenabstieg funktionieren. Alles in allem gehört differenzierbare Programmierung zu den einfacheren Techniken im Bereich des maschinellen Lernens. Es ist sehr zugänglich als Technik. Dennoch erfordert es ein wenig handwerkliches Geschick, um dieses Paradigma zu beherrschen und reibungslos in der Produktion zu betreiben.

Wir sind nun bereit, den zweiten Teil dieser Vorlesung zu beginnen: den Durchlauf. Wir werden einen Durchlauf für unsere Einzelhandelsnachfrageprognose-Aufgabe durchführen. Diese Modellierungsaufgabe ist mit der Prognoseherausforderung aus der vorherigen Vorlesung abgestimmt. Kurz gesagt möchten wir die tägliche Nachfrage auf SKU-Ebene in einem Einzelhandelsnetzwerk prognostizieren. Ein SKU oder Lagerhaltungseinheit ist technisch gesehen das kartesische Produkt zwischen Produkten und Geschäften, gefiltert entlang der Einträge des Sortiments. Wenn wir zum Beispiel 100 Geschäfte und 10.000 Produkte haben und jedes einzelne Produkt in jedem Geschäft vorhanden ist, erhalten wir 1 Million SKUs.

Es gibt Tools, um eine deterministische Schätzung in eine probabilistische umzuwandeln. Wir haben eines dieser Tools in der vorherigen Vorlesung durch die ESSM-Technik gesehen. Wir werden uns in der nächsten Vorlesung genauer mit diesem speziellen Anliegen befassen - die Umwandlung von Schätzungen in probabilistische Schätzungen. Heute geht es uns jedoch nur um die Schätzung von Durchschnittswerten, und alle anderen Arten von Schätzungen (Quantile, probabilistisch) werden später als natürliche Erweiterungen des Kernbeispiels kommen, das ich heute präsentieren werde. In diesem Durchlauf werden wir die Parameter eines einfachen Nachfrageprognosemodells erlernen. Die Einfachheit dieses Modells ist trügerisch, denn diese Art von Modell erreicht tatsächlich modernste Prognosen, wie sie im M5-Prognosewettbewerb 2020 veranschaulicht wurden.

Für unser parametrisches Nachfragemodell führen wir für jedes einzelne SKU einen einzigen Parameter ein. Dies ist eine absolut vereinfachte Form des Modells; die Nachfrage wird als konstant für jedes SKU modelliert. Es handelt sich jedoch nicht um dieselbe Konstante für jedes SKU. Sobald wir diesen konstanten Tagesdurchschnitt haben, wird er für alle Tage des gesamten Lebenszyklus des SKUs denselben Wert haben.

Schauen wir uns an, wie dies mit differenzierbarer Programmierung gemacht wird. Von Zeile 1 bis 4 führen wir den Mock-Datenblock ein. In der Praxis würde dieses Modell und alle seine Varianten von Eingaben abhängen, die aus den Geschäftssystemen stammen: dem ERP, WMS, TMS usw. Eine Vorlesung zu präsentieren, in der ich ein mathematisches Modell in eine realistische Darstellung von Daten einstecke, wie sie aus dem ERP stammen, würde tonnenweise zufällige Komplikationen einführen, die für das aktuelle Thema der Vorlesung irrelevant sind. Was ich hier also mache, ist die Einführung eines Blocks von Mock-Daten, der nicht einmal vorgibt, auf irgendeine Weise realistisch zu sein oder die Art von Daten, die man in einer tatsächlichen Einzelhandelssituation beobachten kann. Das einzige Ziel dieser Mock-Daten besteht darin, die Tabellen und die Beziehungen innerhalb der Tabellen einzuführen und sicherzustellen, dass das gegebene Codebeispiel vollständig ist, kompiliert und ausgeführt werden kann. Alle bisher gezeigten Codebeispiele sind völlig eigenständig; es gibt keine versteckten Teile davor oder danach. Der einzige Zweck des Mock-Datenblocks besteht darin, sicherzustellen, dass wir ein eigenständiges Stück Code haben.

In jedem Beispiel in diesem Durchlauf beginnen wir mit diesem Mock-Datenblock. In Zeile 1 führen wir die Datentabelle mit “dates” als Primärschlüssel ein. Hier haben wir einen Datumsbereich von ungefähr zwei Jahren und einem Monat. Dann führen wir in Zeile 2 die SKU-Tabelle ein, die die Liste der SKUs ist. In diesem minimalistischen Beispiel haben wir nur drei SKUs. In einer realen Einzelhandelssituation für ein großes Einzelhandelsnetzwerk hätten wir Millionen, wenn nicht sogar zehn Millionen SKUs. Aber hier, zum Zwecke des Beispiels, nehme ich eine sehr kleine Anzahl. In Zeile 3 haben wir die Tabelle “T”, die ein kartesisches Produkt zwischen den SKUs und dem Datum ist. Im Wesentlichen erhalten Sie durch diese Tabelle “T” eine Matrix, in der Sie jedes einzelne SKU und jeden einzelnen Tag haben. Es hat zwei Dimensionen.

In Zeile 6 führen wir unseren eigentlichen Autodiff-Block ein. Die Beobachtungstabelle ist die SKU-Tabelle, und der stochastische Gradientenabstieg wählt hier jeweils eine SKU aus. In Zeile 7 führen wir das “level” ein, das unser einziger Parameter sein wird. Es handelt sich um einen Vektorparameter, und bisher haben wir in unseren Autodiff-Blöcken nur skalare Parameter eingeführt. Die vorherigen Parameter waren nur eine Zahl; hier ist “SKU.level” tatsächlich ein Vektor. Es ist ein Vektor, der einen Wert pro SKU hat, und das ist buchstäblich unsere konstante Nachfrage, die auf SKU-Ebene modelliert wird. Wir geben einen Bereich an, und wir werden sehen, warum es wichtig ist, gleich. Es muss mindestens 0,01 betragen, und wir setzen 1.000 als obere Grenze für die tägliche Durchschnittsnachfrage für diesen Parameter. Dieser Parameter wird automatisch mit einem Wert initialisiert, der nahe bei eins liegt, was ein vernünftiger Ausgangspunkt ist. In diesem Modell haben wir nur einen Freiheitsgrad pro SKU. Schließlich implementieren wir in den Zeilen 8 und 9 tatsächlich das Modell selbst. In Zeile 8 berechnen wir “dot.delta”, das ist die Nachfrage, wie sie vom Modell vorhergesagt wird, minus die beobachtete, die “T.sold” ist. Das Modell besteht nur aus einem einzigen Term, einer Konstanten, und dann haben wir die Beobachtung, die “T.sold” ist.

Um zu verstehen, was hier vor sich geht, haben wir einige Broadcasting-Verhaltensweisen. Die Tabelle “T” ist eine Kreuztabelle zwischen SKU und Datum. Der Autodiff-Block ist eine Iteration, die über die Zeilen der Beobachtungstabelle iteriert. In Zeile 9 befinden wir uns innerhalb des Autodiff-Blocks, daher haben wir eine Zeile für die SKU-Tabelle ausgewählt. Der Wert “SKUs.level” ist hier kein Vektor; es ist nur ein Skalar, nur ein Wert, weil wir nur eine Zeile der Beobachtungstabelle ausgewählt haben. Dann ist “T.sold” nicht mehr eine Matrix, weil wir bereits eine SKU ausgewählt haben. Was bleibt, ist, dass “T.sold” tatsächlich ein Vektor ist, ein Vektor, der die Dimension des Datums hat. Wenn wir diese Subtraktion durchführen, “SKUs.level - T.sold”, erhalten wir einen Vektor, der mit der Datentabelle ausgerichtet ist, und weisen ihn “D.delta” zu, der ein Vektor mit einer Zeile pro Tag ist, zwei Jahre und ein Monat. Schließlich berechnen wir in Zeile 9 die Verlustfunktion, die nur der mittlere quadratische Fehler ist. Dieses Modell ist super vereinfacht. Mal sehen, was mit Kalendermustern gemacht werden kann.

Das Teilen von Parametern ist wahrscheinlich eine der einfachsten und nützlichsten differenzierbaren Programmierungstechniken. Ein Parameter wird als geteilt bezeichnet, wenn er zu mehreren Beobachtungszeilen beiträgt. Durch das Teilen von Parametern über Beobachtungen hinweg können wir den Gradientenabstieg stabilisieren und Überanpassungsprobleme mildern. Betrachten wir das Muster des Wochentags. Wir könnten sieben Parameter einführen, die die verschiedenen Gewichte für jede einzelne SKU repräsentieren. Bisher hat eine SKU nur einen Parameter, der nur die konstante Nachfrage ist. Wenn wir diese Wahrnehmung der Nachfrage bereichern wollen, könnten wir sagen, dass jeder einzelne Wochentag mit seinem eigenen Gewicht kommt, und da wir sieben Wochentage haben, können wir sieben Gewichte haben und diese Gewichte multiplikativ anwenden.

Es ist jedoch unwahrscheinlich, dass jede einzelne SKU ihr eigenes einzigartiges Wochentagsmuster hat. Die Realität ist, dass es viel vernünftiger ist anzunehmen, dass es eine Kategorie oder irgendeine Art von Hierarchie gibt, wie eine Produktfamilie, eine Produktkategorie, eine Produktunterkategorie oder sogar eine Abteilung im Geschäft, die dieses Wochentagsmuster korrekt erfasst. Die Idee ist, dass wir nicht sieben Parameter pro SKU einführen wollen; wir wollen sieben Parameter pro Kategorie einführen, die Art von Gruppierungsebene, in der wir davon ausgehen, dass es ein homogenes Verhalten in Bezug auf Wochentagsmuster gibt.

Wenn wir uns entscheiden, diese sieben Parameter mit einer multiplikativen Wirkung über die Ebene einzuführen, handelt es sich genau um den Ansatz, der in der vorherigen Vorlesung für dieses Modell gewählt wurde, das auf SKU-Ebene den ersten Platz im M5-Wettbewerb belegte. Wir haben eine Ebene und eine multiplikative Wirkung mit dem Wochentagsmuster.

Im Code haben wir in den Zeilen 1 bis 5 den Block mit Mock-Daten wie zuvor, und wir führen eine zusätzliche Tabelle namens “category” ein. Diese Tabelle ist eine Gruppierungstabelle der SKUs, und konzeptionell gibt es für jede einzelne Zeile in der SKU-Tabelle eine und nur eine Zeile, die in der Kategorietabelle übereinstimmt. In der Envision-Sprache sagen wir, dass die Kategorie stromaufwärts der Tabelle SKUs liegt. In Zeile 7 wird die Wochentagstabelle eingeführt. Diese Tabelle ist instrumental, und wir führen sie mit einer spezifischen Form ein, die das zu erfassende zyklische Muster widerspiegelt. In Zeile 7 erstellen wir die Wochentagstabelle, indem wir Daten entsprechend ihrem Wert modulo sieben aggregieren. Wir erstellen eine Tabelle, die genau sieben Zeilen haben wird, und diese sieben Zeilen werden jeweils einen der sieben Wochentage repräsentieren. Für jede einzelne Zeile in der Datentabelle hat jede Zeile in der Datenbank einen und nur einen Gegenpart in der Wochentagstabelle. Somit ist die Wochentagstabelle gemäß der Envision-Sprache stromaufwärts der Tabelle “date”.

Jetzt haben wir die Tabelle “CD”, die ein kartesisches Produkt zwischen Kategorie und Wochentag ist. In Bezug auf die Anzahl der Zeilen wird diese Tabelle so viele Zeilen haben wie Kategorien mal sieben, da der Wochentag sieben Zeilen hat. In Zeile 12 führen wir einen neuen Parameter namens “CD.DOW” ein (DOW steht für Wochentag), der ein weiterer Vektorparameter der Tabelle CD ist. In Bezug auf die Freiheitsgrade haben wir genau sieben Parameterwerte mal die Anzahl der Kategorien, wonach wir suchen. Wir möchten ein Modell, das dieses Wochentagsmuster erfassen kann, aber nur ein Muster pro Kategorie, nicht ein Muster pro SKU.

Wir deklarieren diesen Parameter, und wir verwenden das Schlüsselwort “in”, um anzugeben, dass der Wert für “CD.DOW” zwischen 0,1 und 100 liegen sollte. In Zeile 13 schreiben wir die Nachfrage, wie sie vom Modell ausgedrückt wird. Die Nachfrage ist “SKUs.level * CD.DOW”, was die Nachfrage repräsentiert. Wir haben die Nachfrage minus das beobachtete “T.sold”, und das gibt uns einen Delta-Wert. Dann berechnen wir den mittleren quadratischen Fehler.

In Zeile 13 findet eine ziemlich beeindruckende Broadcasting-Magie statt. “CD.DOW” ist eine Kreuztabelle zwischen Kategorie und Wochentag. Da wir uns innerhalb des Autodiff-Blocks befinden, ist die Tabelle CD eine Kreuztabelle zwischen Kategorie und Wochentag. Da wir uns innerhalb des Autodiff-Blocks befinden, iteriert der Block über die SKUs-Tabelle. Wenn wir also eine SKU auswählen, haben wir effektiv eine Kategorie ausgewählt, da die Kategorietabelle stromaufwärts liegt. Das bedeutet, dass CD.DOW nicht mehr eine Matrix ist, sondern ein Vektor mit sieben Dimensionen. Es liegt jedoch stromaufwärts der Tabelle “date”, sodass diese sieben Zeilen in der Datentabelle übertragen werden können. Es gibt nur eine Möglichkeit, diese Übertragung durchzuführen, da jede Zeile der Wochentagstabelle eine Affinität zu bestimmten Zeilen der Datentabelle hat. Es findet eine doppelte Übertragung statt, und am Ende erhalten wir eine Nachfrage, die eine Reihe von Werten ist, die auf der SKU-Ebene zyklisch auf der Wochentagsebene ist. Das ist unser Modell zu diesem Zeitpunkt, und der Rest der Verlustfunktion bleibt unverändert.

Wir sehen einen sehr eleganten Ansatz, um Zyklen zu behandeln, indem wir das Broadcasting-Verhalten, das sich aus der relationalen Natur von Envision ergibt, mit seinen differentiellen Programmierfähigkeiten kombinieren. Wir können Kalenderzyklen in nur drei Zeilen Code ausdrücken. Dieser Ansatz funktioniert auch gut, wenn wir es mit sehr spärlichen Daten zu tun haben. Es würde auch gut funktionieren, wenn wir uns Produkte ansehen würden, die im Durchschnitt nur eine Einheit pro Monat verkaufen. In solchen Fällen wäre der kluge Ansatz, eine Kategorie zu haben, die Dutzende, wenn nicht Hunderte von Produkten umfasst. Diese Technik kann auch verwendet werden, um andere zyklische Muster abzubilden, wie zum Beispiel den Monat des Jahres oder den Tag des Monats.

Das in der vorherigen Vorlesung vorgestellte Modell, das bei der M5-Wettbewerb state-of-the-art Ergebnisse erzielt hat, war eine multiplikative Kombination von drei Zyklen: Wochentag, Monat des Jahres und Tag des Monats. Alle diese Muster wurden als Multiplikation verkettet. Die Implementierung der beiden anderen Varianten bleibt dem aufmerksamen Publikum überlassen, es handelt sich jedoch nur um ein paar Zeilen Code pro zyklischem Muster, was es sehr prägnant macht.

In der vorherigen Vorlesung haben wir ein Verkaufsprognosemodell vorgestellt. Es sind jedoch nicht die Verkäufe, die uns interessieren, sondern die Nachfrage. Wir sollten null Verkäufe nicht mit null Nachfrage verwechseln. Wenn an einem bestimmten Tag kein Lagerbestand mehr für den Kunden im Geschäft vorhanden war, wird bei Lokad die Verlustmaskierungstechnik verwendet, um mit Lagerbeständen umzugehen. Dies ist die einfachste Technik, um mit Lagerbeständen umzugehen, aber es ist nicht die einzige. Soweit ich weiß, haben wir mindestens zwei weitere Techniken, die in der Produktion verwendet werden, jeweils mit ihren eigenen Vor- und Nachteilen. Diese anderen Techniken werden heute nicht behandelt, aber sie werden in späteren Vorlesungen behandelt.

Wenn wir zum Codebeispiel zurückkehren, bleiben die Zeilen 1 bis 3 unverändert. Schauen wir uns an, was folgt. In Zeile 6 erweitern wir die Mock-Daten um den boolean-Flag “in-stock”. Für jede einzelne SKU und jeden einzelnen Tag haben wir einen booleschen Wert, der angibt, ob am Ende des Tages im Geschäft ein Lagerbestand vorhanden war. In Zeile 15 ändern wir die Verlustfunktion so, dass die Tage, an denen am Ende des Tages ein Lagerbestand beobachtet wurde, durch Nullsetzen ausgeschlossen werden. Durch das Nullsetzen dieser Tage stellen wir sicher, dass kein Gradient in Situationen zurückpropagiert wird, die aufgrund des Auftretens des Lagerbestands eine Verzerrung aufweisen.

Das verwirrendste an der Verlustmaskierungstechnik ist, dass sie das Modell nicht einmal verändert. Tatsächlich ist das Modell, das in Zeile 14 ausgedrückt wird, genau dasselbe; es wurde nicht verändert. Es ist nur die Verlustfunktion selbst, die modifiziert wird. Diese Technik mag einfach sein, aber sie weicht grundlegend von einer modellzentrierten Perspektive ab. Es handelt sich im Kern um eine modellzentrierte Technik. Wir verbessern die Situation, indem wir die durch Lagerbestände verursachte Verzerrung anerkennen und dies in unseren Modellierungsbemühungen reflektieren. Wir tun dies jedoch, indem wir die Genauigkeitsmetrik ändern, nicht das Modell selbst. Mit anderen Worten, wir ändern den Verlust, den wir optimieren, und machen dieses Modell in Bezug auf den reinen numerischen Fehler nicht vergleichbar mit anderen Modellen.

Für eine Situation wie Walmart, wie in der vorherigen Vorlesung besprochen, ist die Verlustmaskierungstechnik für die meisten Produkte geeignet. Als Faustregel funktioniert diese Technik gut, wenn die Nachfrage nicht so spärlich ist, dass Sie die meiste Zeit nur eine Einheit auf Lager haben. Darüber hinaus sollten Sie Produkte vermeiden, bei denen Lagerbestände sehr häufig auftreten, da es die explizite Strategie des Einzelhändlers ist, am Ende des Tages einen Lagerbestand zu haben. Dies tritt typischerweise bei einigen ultrafrischen Produkten auf, bei denen der Einzelhändler auf eine ausverkaufte Situation am Ende des Tages abzielt. Alternative Techniken beheben diese Einschränkungen, aber wir haben heute keine Zeit, um sie zu behandeln.

Promotions sind ein wichtiger Aspekt des Einzelhandels. Im Allgemeinen gibt es viele Möglichkeiten für den Einzelhändler, die Nachfrage zu beeinflussen und zu formen, wie zum Beispiel Preisgestaltung oder das Platzieren von Waren auf einem Regal. Die Variablen, die zusätzliche Informationen für Vorhersagezwecke liefern, werden in der Supply Chain als Kovariablen bezeichnet. Es gibt viele Wunschvorstellungen über komplexe Kovariablen wie Wetterdaten oder Social-Media-Daten. Bevor wir uns jedoch mit fortgeschrittenen Themen befassen, müssen wir das offensichtliche Problem angehen, wie zum Beispiel Preisinformationen, die offensichtlich einen erheblichen Einfluss auf die beobachtete Nachfrage haben. Daher führen wir in diesem Codebeispiel in Zeile 7 für jeden einzelnen Tag in Zeile 14 “category.ed” ein, wobei “ed” für Elastizität der Nachfrage steht. Dies ist ein gemeinsamer Vektorparameter mit einem Freiheitsgrad pro Kategorie, der als Darstellung der Elastizität der Nachfrage gedacht ist. In Zeile 16 führen wir eine exponentielle Form der Preiselastizität als Exponentialfunktion von (-category.ed * t.price) ein. Intuitiv konvergiert die Nachfrage mit dieser Form schnell gegen Null, wenn der Preis steigt, aufgrund der Anwesenheit der Exponentialfunktion. Umgekehrt steigt die Nachfrage explosionsartig an, wenn der Preis gegen Null konvergiert.

Diese exponentielle Form der Preisreaktion ist vereinfacht, und das Teilen der Parameter gewährleistet eine hohe numerische Stabilität, selbst mit dieser exponentiellen Funktion im Modell. In realen Situationen, insbesondere für Situationen wie Walmart, hätten wir verschiedene Preisinformationen, wie Rabatte, den Unterschied zum Normalpreis, Kovariablen, die Marketingaktionen des Lieferanten darstellen, oder kategoriale Variablen, die Dinge wie Regale einführen. Mit differenzierbarer Programmierung ist es einfach, beliebig komplexe Preisreaktionen zu entwickeln, die der Situation nahe kommen. Die Integration von Kovariablen nahezu jeder Art ist mit differenzierbarer Programmierung sehr einfach.

Langsam drehende Artikel sind eine Tatsache des Lebens im Einzelhandel und in vielen anderen Branchen. Das bisher vorgestellte Modell hat einen Parameter, einen Freiheitsgrad pro SKU, mit mehr, wenn man die gemeinsamen Parameter mitzählt. Dies könnte jedoch bereits zu viel sein, insbesondere für SKUs, die nur einmal im Jahr oder nur wenige Male im Jahr rotieren. In solchen Situationen können wir uns nicht einmal einen Freiheitsgrad pro SKU leisten, daher besteht die Lösung darin, sich ausschließlich auf gemeinsame Parameter zu verlassen und alle Parameter mit Freiheitsgrad auf SKU-Ebene zu entfernen.

In den Zeilen 2 und 4 führen wir zwei Tabellen namens “products” und “stores” ein, und die Tabelle “SKUs” wird als gefilterte Teilmenge des kartesischen Produkts zwischen Produkten und Geschäften konstruiert, was die eigentliche Definition der Sortimentsbildung ist. In den Zeilen 15 und 16 führen wir zwei gemeinsame Vektorparameter ein: eine Ebene mit einer Affinität zur Produkttabelle und eine weitere Ebene, die eine Affinität zu den Ladentabellen hat. Diese Parameter sind auch innerhalb eines bestimmten Bereichs definiert, von 0,01 bis 100, was der Maximalwert ist.

Nun, in Zeile 18 wird die Ebene pro SKU als das Produkt der Produktelebene und der Ladenebene zusammengesetzt. Der Rest des Skripts bleibt unverändert. Wie funktioniert das also? In Zeile 19 ist SKU.level ein Skalar. Wir haben den Autodesk-Block, der über die SKUs-Tabelle iteriert, die die Beobachtungstabelle ist. Daher ist SKUs.level in Zeile 18 nur ein Skalarwert. Dann haben wir products.level. Da die Produkttabelle stromaufwärts der SKUs-Tabelle liegt, gibt es für jede einzelne SKU eine und nur eine Produkttabelle. Daher ist products.level nur eine Skalarnummer. Das Gleiche gilt für die Ladentabelle, die ebenfalls stromaufwärts der SKUs-Tabelle liegt. In Zeile 18 ist nur ein Geschäft mit dieser spezifischen SKU verbunden. Daher haben wir die Multiplikation von zwei Skalarwerten, die uns die SKU.level geben. Der Rest des Modells bleibt unverändert.

Diese Techniken werfen ein völlig neues Licht auf die Behauptung, dass manchmal nicht genügend Daten vorhanden sind oder dass die Daten manchmal zu dünn sind. Tatsächlich machen diese Behauptungen aus differenzierbarer Perspektive nicht einmal wirklich Sinn. Es gibt keine solche Sache wie zu wenig Daten oder zu dünne Daten, zumindest nicht in absoluten Begriffen. Es gibt nur Modelle, die in Richtung Sparsamkeit und möglicherweise in Richtung extremer Sparsamkeit modifiziert werden können. Die aufgezwungene Struktur ist wie Führungsschienen, die den Lernprozess nicht nur möglich, sondern auch numerisch stabil machen.

Im Vergleich zu anderen maschinellen Lerntechniken, die versuchen, das maschinelle Lernmodell alle Muster ex nihilo entdecken zu lassen, legt dieser strukturierte Ansatz die Struktur fest, die wir lernen müssen. Daher hat der statistische Mechanismus, der hier zum Einsatz kommt, eine begrenzte Freiheit, was er lernen soll. In Bezug auf die Dateneffizienz kann er daher unglaublich effizient sein. Natürlich beruht all dies darauf, dass wir die richtige Struktur gewählt haben.

Wie Sie sehen können, sind Experimente sehr einfach durchzuführen. Wir machen bereits etwas sehr Komplexes, und in weniger als 50 Zeilen könnten wir eine ziemlich komplexe Situation ähnlich wie bei Walmart bewältigen. Das ist schon eine Leistung. Es gibt einen gewissen empirischen Prozess, aber die Realität ist, dass es nicht viel ist. Wir reden von ein paar Dutzend Zeilen. Bedenken Sie, dass ein ERP wie dasjenige, das ein Unternehmen, ein großes Einzelhandelsnetzwerk, betreibt, in der Regel tausend Tabellen und 100 Felder pro Tabelle hat. Die Komplexität der Geschäftssysteme ist also im Vergleich zur Komplexität dieses strukturierten Vorhersagemodells absolut gigantisch. Wenn wir ein wenig Zeit für Iterationen aufwenden müssen, ist es fast nichts.

Darüber hinaus wissen Supply Chain-Experten bereits aus der M5-Prognosewettbewerb, dass die Realität so aussieht, dass sie die Muster bereits kennen. Als das M5-Team drei Kalendermuster verwendete, nämlich den Wochentag, den Monat des Jahres und den Tag des Monats, waren all diese Muster für jeden erfahrenen Supply Chain-Praktiker offensichtlich. Die Realität in der Supply Chain ist, dass wir nicht versuchen, ein verstecktes Muster zu entdecken. Die Tatsache, dass zum Beispiel bei massiver Preissenkung die Nachfrage massiv steigt, wird niemanden überraschen. Die einzige Frage, die bleibt, ist, was genau die Größenordnung des Effekts ist und wie genau die Form der Reaktion ist. Dies sind relativ technische Details, und wenn Sie sich die Möglichkeit geben, ein wenig zu experimentieren, können Sie diese Probleme relativ einfach angehen.

Als letzter Schritt dieses Durchlaufs möchte ich auf eine kleine Eigenart des differenzierbaren Programmierens hinweisen. Differenzierbares Programmieren sollte nicht mit einem generischen mathematischen Optimierungslöser verwechselt werden. Wir müssen im Hinterkopf behalten, dass ein Gradientenabstieg stattfindet. Genauer gesagt hat der Algorithmus, der zur Optimierung und Aktualisierung der Parameter verwendet wird, eine maximale Abstiegsgeschwindigkeit, die der Lernrate entspricht, die mit dem ADAM-Algorithmus geliefert wird. In Envision beträgt die Standardlernrate 0,01.

Wenn wir uns den Code ansehen, haben wir in Zeile 4 eine Initialisierung eingeführt, bei der die verkauften Mengen aus einer Poisson-Verteilung mit einem Mittelwert von 50 abgeleitet werden. Wenn wir eine Ebene lernen wollen, bräuchten wir technisch gesehen eine Ebene, die in der Größenordnung von 50 liegt. Wenn wir jedoch eine automatische Initialisierung des Parameters durchführen, starten wir mit einem Wert, der ungefähr eins ist, und wir können nur in Schritten von 0,01 vorangehen. Es würde etwa 5.000 Epochen dauern, um diesen Wert von 50 tatsächlich zu erreichen. Da wir einen nicht geteilten Parameter, SKU.level, haben, wird dieser Parameter pro Epoche nur einmal berührt. Daher bräuchten wir 5.000 Epochen, was die Berechnung unnötig verlangsamen würde.

Wir könnten die Lernrate erhöhen, um den Abstieg zu beschleunigen, was eine Lösung wäre. Ich würde jedoch nicht empfehlen, die Lernrate aufzublasen, da dies in der Regel nicht der richtige Ansatz ist, um das Problem anzugehen. In einer realen Situation hätten wir zusätzlich zu diesem nicht geteilten Parameter auch gemeinsam genutzte Parameter. Diese gemeinsam genutzten Parameter werden während jeder Epoche mehrmals vom stochastischen Gradientenabstieg berührt. Wenn Sie die Lernrate stark erhöhen, riskieren Sie numerische Instabilitäten für Ihre gemeinsam genutzten Parameter. Sie könnten die Bewegungsgeschwindigkeit der SKU-Ebene erhöhen, aber numerische Stabilitätsprobleme für die anderen Parameter verursachen.

Eine bessere Technik wäre es, einen Skalierungstrick zu verwenden und den Parameter in eine Exponentialfunktion einzuschließen, was genau in Zeile 8 gemacht wird. Mit diesem Wrapper können wir jetzt Parameterwerte für die Ebene erreichen, die entweder sehr niedrig oder sehr hoch sein können, und das mit einer viel geringeren Anzahl von Epochen. Diese Eigenart ist im Grunde die einzige Eigenart, die ich einführen müsste, um ein realistisches Beispiel für diese Durchführung einer Einzelhandelsnachfrageprognose zu haben. Alles in allem ist es eine kleine Eigenart. Trotzdem ist es eine Erinnerung daran, dass differenzierbare Programmierung Aufmerksamkeit auf den Fluss der Gradienten erfordert. Differenzierbare Programmierung bietet insgesamt ein flüssiges Design-Erlebnis, aber es ist keine Magie.

Ein paar abschließende Gedanken: Strukturierte Modelle erreichen eine erstklassige Genauigkeit bei der Prognose. Dieser Punkt wurde in der vorherigen Vorlesung ausführlich behandelt. Basierend auf den heute vorgestellten Elementen würde ich jedoch argumentieren, dass die Genauigkeit nicht einmal der entscheidende Faktor zugunsten der differenzierbaren Programmierung mit einem strukturierten parametrischen Modell ist. Was wir bekommen, ist Verständnis; wir erhalten nicht nur ein Stück Software, das in der Lage ist, Vorhersagen zu treffen, sondern wir erhalten auch direkte Einblicke in die Muster, die wir erfassen möchten. Zum Beispiel würde uns das heute vorgestellte Modell eine Nachfrageprognose liefern, die mit expliziten Wochentagsgewichten und einer expliziten Elastizität der Nachfrage verbunden ist. Wenn wir diese Nachfrage zum Beispiel erweitern würden, um eine Erhöhung im Zusammenhang mit dem Black Friday einzuführen, einem quasi-saisonalen Ereignis, das nicht jedes Jahr zur gleichen Zeit stattfindet, könnten wir das tun. Wir würden einfach einen Faktor hinzufügen, und dann hätten wir eine Schätzung für die Black Friday-Erhöhung isoliert von allen anderen Mustern, wie dem Wochentagsmuster. Das ist von großem Interesse.

Was wir durch den strukturierten Ansatz erhalten, ist Verständnis, und es ist viel mehr als nur das reine Modell. Wenn wir zum Beispiel eine negative Elastizität haben, eine Situation, in der das Modell Ihnen sagt, dass bei Erhöhung des Preises die Nachfrage steigt, in einer Walmart-ähnlichen Situation, ist dies ein sehr zweifelhaftes Ergebnis. Wahrscheinlich spiegelt es wider, dass Ihre Modellimplementierung fehlerhaft ist oder dass tiefgreifende Probleme vorliegen. Egal, was die Genauigkeitsmetrik Ihnen sagt, wenn Sie in einer Walmart-Situation landen und etwas haben, das Ihnen sagt, dass die Leute mehr kaufen, wenn Sie ein Produkt teurer machen, sollten Sie Ihre gesamte Datenaufbereitung wirklich in Frage stellen, denn höchstwahrscheinlich stimmt etwas nicht. Darum geht es beim Verständnis.

Außerdem ist das Modell offen für Veränderungen. Differenzierbare Programmierung ist unglaublich ausdrucksstark. Das Modell, das wir haben, ist nur eine Iteration in einer Reise. Wenn sich der Markt verändert oder das Unternehmen selbst verändert, können wir sicher sein, dass das Modell, das wir haben, in der Lage sein wird, diese Entwicklung auf natürliche Weise zu erfassen. Es gibt keine automatische Entwicklung; es erfordert Anstrengungen von einem Supply Chain Scientist, um diese Entwicklung zu erfassen. Diese Anstrengungen können jedoch als relativ geringfügig angesehen werden. Es kommt darauf an, dass, wenn Sie ein sehr kleines, ordentliches Modell haben, wenn Sie dieses Modell später überarbeiten müssen, um seine Struktur anzupassen, dies im Vergleich zu einer Situation, in der Ihr Modell ein technisches Monster wäre, eine relativ kleine Aufgabe sein wird.

Wenn sie sorgfältig entwickelt werden, sind Modelle, die mit differenzierbarer Programmierung erstellt werden, sehr stabil. Die Stabilität hängt von der Wahl der Struktur ab. Stabilität ist nicht gegeben für jedes Programm, das Sie durch differenzierbare Programmierung optimieren; es ist etwas, das Sie erhalten, wenn Sie eine sehr klare Struktur haben, in der die Parameter eine spezifische Bedeutung haben. Wenn Sie zum Beispiel ein Modell haben, bei dem Sie jedes Mal, wenn Sie Ihr Modell neu trainieren, völlig unterschiedliche Gewichte für den Wochentag erhalten, dann ändert sich die Realität in Ihrem Unternehmen nicht so schnell. Wenn Sie Ihr Modell zweimal ausführen, sollten Sie relativ stabile Werte für den Wochentag erhalten. Wenn das nicht der Fall ist, dann ist etwas sehr falsch bei der Modellierung Ihrer Nachfrage. Wenn Sie also eine kluge Wahl für die Struktur Ihres Modells treffen, können Sie unglaublich stabile numerische Ergebnisse erzielen. Dadurch vermeiden wir Probleme, die komplexe Machine-Learning-Modelle oft plagen, wenn wir sie in einem Supply-Chain-Kontext verwenden. Tatsächlich sind numerische Instabilitäten aus Sicht der Supply Chain tödlich, weil wir überall Ratscheneffekte haben. Wenn Sie eine Schätzung der Nachfrage haben, die schwankt, bedeutet das, dass Sie zufällig eine Bestell- oder Produktionsanforderung auslösen, nur umsonst. Sobald Sie Ihre Produktionsanforderung ausgelöst haben, können Sie nicht nächste Woche entscheiden, dass es ein Fehler war und dass Sie das nicht hätten tun sollen. Sie sind an der Entscheidung, die Sie gerade getroffen haben, festgehalten. Wenn Sie einen Schätzer für die zukünftige Nachfrage haben, der ständig schwankt, werden Sie mit überhöhten Auffüllungen und überhöhten Produktionsaufträgen enden. Dieses Problem kann durch Sicherstellung der Stabilität gelöst werden, was eine Frage des Designs ist.

Eine der größten Hürden bei der Einführung von maschinellem Lernen in die Produktion ist das Vertrauen. Wenn Sie mit Millionen von Euro oder Dollar arbeiten, ist es entscheidend zu verstehen, was in Ihrem numerischen Rezept passiert. Supply-Chain-Fehler können äußerst kostspielig sein, und es gibt viele Beispiele für Supply-Chain-Katastrophen, die durch eine schlechte Anwendung schlecht verstandener Algorithmen verursacht wurden. Obwohl differenzierbare Programmierung sehr leistungsstark ist, sind die Modelle, die entwickelt werden können, unglaublich einfach. Diese Modelle könnten tatsächlich in einer Excel-Tabelle ausgeführt werden, da es sich in der Regel um einfache multiplikative Modelle mit Verzweigungen und Funktionen handelt. Der einzige Aspekt, der nicht in einer Excel-Tabelle ausgeführt werden könnte, ist die automatische Differentiation, und offensichtlich sollten Sie das nicht in einer Tabelle versuchen, wenn Sie Millionen von SKUs haben. In Bezug auf die Einfachheit ist es jedoch sehr gut mit etwas kompatibel, das Sie in eine Tabelle einfügen würden. Diese Einfachheit trägt wesentlich dazu bei, Vertrauen aufzubauen und maschinelles Lernen in die Produktion zu bringen, anstatt es als ausgefallene Prototypen zu belassen, denen die Menschen nie ganz vertrauen können.

Schließlich erhalten wir, wenn wir all diese Eigenschaften zusammenbringen, ein sehr genaues Stück Technologie. Dieser Aspekt wurde im allerersten Kapitel dieser Vorlesungsreihe diskutiert. Wir möchten alle Anstrengungen, die in die Supply Chain investiert werden, in kapitalistische Investitionen umwandeln, anstatt Supply-Chain-Experten und -Praktiker als Verbrauchsgüter zu behandeln, die immer wieder dasselbe tun müssen. Mit diesem Ansatz können wir all diese Anstrengungen als Investitionen behandeln, die im Laufe der Zeit eine Rendite generieren und aufrechterhalten werden. Differenzierbare Programmierung passt sehr gut zu dieser kapitalistischen Perspektive für die Supply Chain.

Im zweiten Kapitel haben wir eine wichtige Vorlesung mit dem Titel “Experimentelle Optimierung” vorgestellt, die eine mögliche Antwort auf die einfache, aber grundlegende Frage lieferte: Was bedeutet es eigentlich, sich in einer Supply Chain zu verbessern oder besser zu werden? Die Perspektive der differenzierbaren Programmierung bietet einen sehr spezifischen Einblick in viele Herausforderungen, mit denen Supply-Chain-Praktiker konfrontiert sind. Unternehmenssoftwareanbieter geben häufig schlechte Daten für ihre Supply-Chain-Fehler verantwortlich. Ich glaube jedoch, dass dies einfach der falsche Ansatz ist, um das Problem anzugehen. Die Daten sind einfach das, was sie sind. Ihr ERP-System wurde nie für Data Science entwickelt, funktioniert aber seit Jahren, wenn nicht Jahrzehnten, reibungslos, und die Mitarbeiter im Unternehmen schaffen es trotzdem, die Supply Chain zu betreiben. Selbst wenn Ihr ERP-System, das Daten über Ihre Supply Chain erfasst, nicht perfekt ist, ist das in Ordnung. Wenn Sie erwarten, dass perfekte Daten verfügbar gemacht werden, ist dies nur Wunschdenken. Wir sprechen über Supply Chains; die Welt ist sehr komplex, daher sind die Systeme unvollkommen. Realistisch betrachtet haben Sie kein einziges Geschäftssystem; Sie haben etwa ein halbes Dutzend, und sie sind nicht vollständig miteinander konsistent. Das ist einfach eine Tatsache des Lebens. Wenn jedoch Unternehmensanbieter schlechte Daten verantwortlich machen, liegt die Realität darin, dass ein sehr spezifisches Prognosemodell vom Anbieter verwendet wird und dieses Modell mit einer bestimmten Reihe von Annahmen über das Unternehmen entwickelt wurde. Das Problem besteht darin, dass, wenn Ihr Unternehmen eine dieser Annahmen verletzt, die Technologie vollständig zusammenbricht. In dieser Situation haben Sie ein Prognosemodell, das mit unrealistischen Annahmen geliefert wird, Sie geben die Daten ein, die nicht perfekt sind, und daher bricht die Technologie zusammen. Es ist völlig unvernünftig zu sagen, dass das Unternehmen schuld ist. Die Technologie, die schuld ist, ist diejenige, die vom Anbieter vorangetrieben wird und völlig unrealistische Annahmen darüber trifft, welche Daten überhaupt in einem Supply-Chain-Kontext vorhanden sein können.

Heute habe ich keine Benchmark für Metriken zur Genauigkeit vorgestellt. Meine These ist jedoch, dass diese Genauigkeitsmetriken größtenteils unerheblich sind. Ein Vorhersagemodell ist ein Werkzeug, um Entscheidungen zu treffen. Es ist wichtig, ob diese Entscheidungen - was zu kaufen, was zu produzieren, ob Sie Ihren Preis erhöhen oder senken sollen - gut oder schlecht sind. Schlechte Entscheidungen können auf das Vorhersagemodell zurückgeführt werden, das ist wahr. Aber meistens handelt es sich nicht um ein Genauigkeitsproblem. Zum Beispiel hatten wir ein Verkaufsprognosemodell und haben den Lagerbestandsaspekt behoben, der nicht angemessen verwaltet wurde. Wenn wir jedoch den Lagerbestandsaspekt behoben haben, haben wir das Genauigkeitsmaß selbst behoben. Das Beheben des Vorhersagemodells bedeutet also nicht, die Genauigkeit zu verbessern; sehr häufig bedeutet es, das eigentliche Problem und die Perspektive, in der Sie arbeiten, buchstäblich zu überdenken und somit das Genauigkeitsmaß oder etwas noch Tiefergehendes zu ändern. Das Problem mit der klassischen Perspektive besteht darin, dass sie annimmt, dass die Genauigkeitsmetrik ein erstrebenswertes Ziel ist. Das ist nicht ganz der Fall.

Supply Chains operieren in einer realen Welt und es gibt viele unerwartete und sogar außergewöhnliche Ereignisse. Zum Beispiel kann es zu einer Blockade des Suezkanals durch ein Schiff kommen; das ist ein völlig außergewöhnliches Ereignis. In einer solchen Situation würden alle existierenden Vorhersagemodelle für die Lieferzeit sofort ungültig werden, die sich diesen Teil der Welt angesehen haben. Offensichtlich ist dies etwas, das zuvor noch nicht wirklich passiert ist, also können wir nichts in einer solchen Situation rückwirkend testen. Aber selbst wenn wir diese völlig außergewöhnliche Situation mit einem blockierten Suezkanal haben, können wir das Modell immer noch reparieren, zumindest wenn wir diesen Art von White-Box-Ansatz haben, den ich heute vorstelle. Diese Reparatur wird eine gewisse Vermutung beinhalten, was in Ordnung ist. Es ist besser, ungefähr richtig zu sein, als genau falsch. Zum Beispiel, wenn wir uns den blockierten Suezkanal ansehen, können wir einfach sagen: “Lassen Sie uns einen Monat zur Lieferzeit für alle Lieferungen hinzufügen, die durch diese Route gehen sollten.” Das ist sehr ungefähr, aber es ist besser anzunehmen, dass es überhaupt keine Verzögerung geben wird, obwohl Sie bereits die Informationen haben. Zusätzlich kommt der Wandel oft von innen. Betrachten wir zum Beispiel ein Einzelhandelsnetzwerk, das ein altes Verteilungszentrum und ein neues Verteilungszentrum hat, das einige Dutzend Geschäfte beliefert. Angenommen, es findet eine Migration statt, bei der im Wesentlichen die Lieferungen für die Geschäfte vom alten Verteilungszentrum auf das neue übertragen werden. Diese Situation tritt fast nur einmal in der Geschichte dieses bestimmten Einzelhändlers auf und kann nicht wirklich rückwirkend getestet werden. Mit einem Ansatz wie dem Differentiable Programming ist es jedoch völlig unkompliziert, ein Modell zu implementieren, das diese schrittweise Migration berücksichtigt.

Zusammenfassend ist das Differentiable Programming eine Technologie, die uns einen Ansatz bietet, unsere Einsichten in die Zukunft zu strukturieren. Das Differentiable Programming ermöglicht es uns, buchstäblich die Art und Weise zu gestalten, wie wir in die Zukunft schauen. Das Differentiable Programming befindet sich auf der Wahrnehmungsseite dieses Bildes. Basierend auf dieser Wahrnehmung können wir bessere Entscheidungen für Supply Chains treffen, und diese Entscheidungen treiben die Handlungen auf der anderen Seite des Bildes an. Eines der größten Missverständnisse der Mainstream-Supply-Chain-Theorie besteht darin, dass man Wahrnehmung und Handlung isoliert als strikt getrennte Komponenten behandeln kann. Dies nimmt die Form an, dass ein Team für die Planung zuständig ist (das ist die Wahrnehmung) und ein unabhängiges Team für die Wiederbeschaffung zuständig ist (das ist die Handlung).

Die Rückkopplungsschleife zwischen Wahrnehmung und Handlung ist sehr wichtig; sie ist von grundlegender Bedeutung. Dies ist buchstäblich der Mechanismus, der Sie zu einer korrekten Form der Wahrnehmung führt. Wenn Sie diese Rückkopplungsschleife nicht haben, ist es nicht einmal klar, ob Sie das Richtige betrachten oder ob das, was Sie betrachten, wirklich das ist, was Sie denken. Sie benötigen diesen Rückkopplungsmechanismus, und es ist durch diese Rückkopplungsschleife, dass Sie Ihre Modelle tatsächlich auf eine korrekte quantitative Bewertung der Zukunft steuern können, die für den Handlungsverlauf Ihrer Supply Chain relevant ist. Die Mainstream-Supply-Chain-Ansätze vernachlässigen diesen Fall fast vollständig, weil sie im Grunde genommen mit einer sehr starren Form der Prognose stecken geblieben sind. Diese modellzentrierte Form der Prognose kann ein altes Modell sein, wie das Holt-Winters-Prognosemodell, oder ein neueres wie Facebook Prophet. Die Situation ist die gleiche: Wenn Sie mit einem Prognosemodell stecken bleiben, ist das gesamte Feedback, das Sie von der Handlungsseite des Bildes erhalten können, bedeutungslos, weil Sie nichts mit diesem Feedback tun können, außer es vollständig zu ignorieren.

Wenn Sie mit einem bestimmten Prognosemodell stecken bleiben, können Sie Ihr Modell nicht neu formatieren oder umstrukturieren, während Sie Informationen von der Handlungsseite erhalten. Andererseits bietet Ihnen das differenzierbare Programmieren mit seinem strukturierten Modellierungsansatz ein völlig anderes Paradigma. Das Vorhersagemodell ist vollständig austauschbar - alles daran. Wenn das Feedback, das Sie von Ihren Handlungsaufrufen erhalten, radikale Änderungen in Ihrer prognostischen Perspektive erfordert, setzen Sie diese radikalen Änderungen einfach um. Es besteht keine spezifische Bindung an eine bestimmte Iteration des Modells. Die Beibehaltung eines sehr einfachen Modells ist ein langer Weg, um sicherzustellen, dass Sie, sobald Sie in der Produktion sind, die Möglichkeit haben, dieses Modell weiterhin zu ändern. Denn noch einmal, wenn das, was Sie entwickelt haben, wie ein Tier, ein Ingenieursmonster ist, wird es unglaublich schwierig, es zu ändern, sobald Sie in der Produktion sind. Einer der Schlüsselaspekte besteht darin, dass Sie, wenn Sie Änderungen beibehalten möchten, ein Modell haben müssen, das in Bezug auf den Codeumfang und die interne Komplexität sehr sparsam ist. Hier glänzt das differenzierbare Programmieren. Es geht nicht darum, eine höhere Genauigkeit zu erreichen; es geht darum, eine höhere Relevanz zu erreichen. Ohne Relevanz sind alle Genauigkeitsmetriken völlig bedeutungslos. Differenzierbares Programmieren und strukturierte Modellierung ermöglichen Ihnen die Reise, Relevanz zu erreichen und diese dann im Laufe der Zeit aufrechtzuerhalten.

Damit schließe ich den Vortrag für heute ab. Nächste Woche, am 2. März, zur gleichen Zeit, um 15 Uhr Pariser Zeit, werde ich probabilistische Modellierung für die Supply Chain vorstellen. Wir werden uns genauer mit den technischen Auswirkungen befassen, wenn wir uns alle möglichen Zukunftsszenarien ansehen, anstatt nur eine Zukunft auszuwählen und sie als die richtige zu erklären. Tatsächlich ist es sehr wichtig, sich alle möglichen Zukunftsszenarien anzusehen, wenn Sie möchten, dass Ihre Supply Chain effektiv gegen Risiken widerstandsfähig ist. Wenn Sie nur eine Zukunft auswählen, ist dies ein Rezept dafür, dass Sie etwas erhalten, das unglaublich fragil ist, wenn Ihre Prognose nicht perfekt korrekt ist. Und raten Sie mal, die Prognose ist nie vollständig korrekt. Deshalb ist es sehr wichtig, die Idee zu akzeptieren, dass Sie sich alle möglichen Zukunftsszenarien ansehen müssen, und wir werden uns ansehen, wie das mit modernen numerischen Rezepten gemacht werden kann.

Frage: Stochastisches Rauschen wird hinzugefügt, um lokale Minima zu vermeiden, aber wie wird es genutzt oder skaliert, um große Abweichungen zu vermeiden, damit der Gradientenabstieg nicht weit von seinem Ziel entfernt wird?

Das ist eine sehr interessante Frage, und es gibt zwei Teile zu dieser Antwort.

Erstens ist dies der Grund, warum der Adam-Algorithmus in Bezug auf die Größenordnung der Bewegungen sehr konservativ ist. Der Gradient ist grundsätzlich unbeschränkt; Sie können einen Gradienten haben, der Tausende oder Millionen wert ist. Mit Adam ist der maximale Schritt jedoch durch die Lernrate nach oben begrenzt. Daher kommt Adam mit einem numerischen Rezept, das buchstäblich einen maximalen Schritt erzwingt, und hoffentlich vermeidet dies massive numerische Instabilität.

Wenn wir jedoch zufällig trotz dieser Lernrate sagen könnten, dass wir einfach aufgrund von reinen Schwankungen iterativ einen Schritt nach dem anderen in eine falsche Richtung machen, ist dies eine Möglichkeit. Deshalb sage ich, dass der stochastische Gradientenabstieg immer noch nicht vollständig verstanden ist. Es funktioniert in der Praxis unglaublich gut, aber warum es so gut funktioniert und warum es so schnell konvergiert und warum wir nicht mehr Probleme bekommen, die auftreten können, ist noch nicht vollständig verstanden, insbesondere wenn man bedenkt, dass der stochastische Gradientenabstieg in hohen Dimensionen stattfindet. Normalerweise haben Sie buchstäblich zehn oder sogar hunderte von Parametern, die bei jedem Schritt berührt werden. Die Art von Intuition, die Sie in zwei oder drei Dimensionen haben können, ist sehr irreführend; Dinge verhalten sich sehr unterschiedlich, wenn Sie sich höheren Dimensionen zuwenden.

Daher ist das Fazit zu dieser Frage: Es ist sehr relevant. Es gibt einen Teil, in dem die Adam-Magie darin besteht, sehr konservativ mit der Skalierung Ihrer Gradientenschritte umzugehen, und den anderen Teil, der schlecht verstanden wird, aber dennoch in der Praxis sehr gut funktioniert. Übrigens glaube ich, dass die Tatsache, dass der stochastische Gradientenabstieg nicht vollständig intuitiv ist, auch der Grund dafür ist, dass diese Technik fast 70 Jahre lang bekannt war, aber nicht als effektiv anerkannt wurde. Fast 70 Jahre lang wussten die Menschen, dass es existiert, aber sie waren sehr skeptisch. Es brauchte den massiven Erfolg des Deep Learnings, damit die Gemeinschaft erkennt und anerkennt, dass es tatsächlich sehr gut funktioniert, auch wenn wir nicht wirklich verstehen, warum.

Frage: Wie erkennt man, wann ein bestimmtes Muster schwach ist und daher aus dem Modell entfernt werden sollte?

Wieder eine sehr gute Frage. Es gibt keine strengen Kriterien; es ist buchstäblich eine Entscheidung des Supply Chain Scientists. Der Grund dafür ist, dass, wenn das von Ihnen eingeführte Muster Ihnen minimale Vorteile bringt, aber in Bezug auf die Modellierung nur zwei Zeilen Code sind und der Einfluss in Bezug auf die Rechenzeit vernachlässigbar ist, und wenn Sie das Muster später entfernen möchten, ist es halbtrivial, könnten Sie sagen: “Nun, ich kann es einfach behalten. Es scheint nicht zu schaden, es bringt nicht viel Gutes. Ich kann mir Situationen vorstellen, in denen dieses schwache Muster tatsächlich stark werden könnte.” In Bezug auf die Wartbarkeit ist das in Ordnung.

Sie können jedoch auch die andere Seite der Medaille sehen, bei der ein Muster nicht viel erfasst und dem Modell viel Rechenleistung hinzufügt. Es ist also nicht kostenlos; jedes Mal, wenn Sie einen Parameter oder eine Logik hinzufügen, erhöhen Sie den Bedarf an Rechenressourcen für Ihr Modell, was es langsamer und unhandlicher macht. Wenn Sie der Meinung sind, dass dieses schwache Muster tatsächlich stark werden könnte, aber auf eine schlechte Weise, indem es Instabilität erzeugt und Ihre Vorhersagemodellierung durcheinander bringt, ist dies in der Regel die Art von Situation, in der Sie denken würden: “Nein, ich sollte es wahrscheinlich entfernen.”

Sie sehen, es ist wirklich eine Frage des Urteilsvermögens. Differentiable Programming ist eine Kultur; Sie sind nicht allein. Sie haben Kollegen und Gleichgesinnte, die vielleicht verschiedene Dinge bei Lokad ausprobiert haben. Das ist die Art von Kultur, die wir zu pflegen versuchen. Ich weiß, dass es im Vergleich zur allmächtigen KI-Perspektive, der Idee, dass wir eine allmächtige künstliche Intelligenz haben könnten, die all diese Probleme für uns löst, vielleicht etwas enttäuschend sein könnte. Aber die Realität ist, dass Lieferketten so komplex sind und unsere Techniken der künstlichen Intelligenz so grob sind, dass wir keinen realistischen Ersatz für menschliche Intelligenz haben. Wenn ich von Urteilsvermögen spreche, meine ich nur, dass Sie eine gesunde Dosis angewandter, sehr menschlicher Intelligenz für den Fall benötigen, denn alle algorithmischen Tricks sind bei weitem nicht in der Lage, eine zufriedenstellende Antwort zu liefern.

Trotzdem bedeutet das nicht, dass Sie keine Art von Werkzeugen entwerfen können. Das wäre ein anderes Thema; Ich werde sehen, ob ich die Art von Werkzeugen abdecken werde, die wir bei Lokad bereitstellen, um das Design zu erleichtern. Ein tangentialer Aspekt wäre, wenn wir eine Entscheidung treffen müssen, versuchen wir, alle Instrumente bereitzustellen, damit diese Entscheidung sehr schnell getroffen werden kann und die mit dieser Art von Unentschlossenheit verbundenen Schmerzen minimiert werden, bei der der Supply Chain Scientist etwas über das Schicksal des aktuellen Zustands des Modells entscheiden muss.

Frage: Ab welcher Komplexitätsschwelle einer Lieferkette bringen maschinelles Lernen und Differentiable Programming deutlich bessere Ergebnisse?

Bei Lokad schaffen wir in der Regel bedeutende Ergebnisse für Unternehmen mit einem Jahresumsatz von über 10 Millionen US-Dollar. Ich würde sagen, es fängt wirklich an zu glänzen, wenn Sie ein Unternehmen mit einem Jahresumsatz von über 50 Millionen US-Dollar haben.

Der Grund dafür ist, dass Sie grundsätzlich eine sehr zuverlässige Datenpipeline aufbauen müssen. Sie müssen in der Lage sein, alle relevanten Daten aus dem ERP-System täglich zu extrahieren. Ich meine nicht, dass es gute oder schlechte Daten sein werden, nur die Daten, die Sie haben, können viele Mängel aufweisen. Nichtsdestotrotz bedeutet dies, dass es ziemlich viel Aufwand erfordert, um die grundlegenden Transaktionen täglich extrahieren zu können. Wenn das Unternehmen zu klein ist, haben sie in der Regel nicht einmal eine eigene IT-Abteilung, und sie können es nicht schaffen, eine zuverlässige tägliche Extraktion zu haben, was die Ergebnisse wirklich beeinträchtigt.

Nun, was die Branchen oder die Komplexität betrifft, ist die Sache die, dass in den meisten Unternehmen und den meisten Lieferketten meiner Meinung nach noch nicht einmal begonnen wurde, zu optimieren. Wie gesagt, die Mainstream-Lieferketten-Theorie betont, dass man genauere Prognosen verfolgen sollte. Ein reduzierter Prozentsatz an Prognosefehlern ist ein Ziel, und viele Unternehmen würden dies beispielsweise durch ein Planungsteam oder ein Prognoseteam erreichen. Meiner Meinung nach trägt all das nichts zum Geschäftswert bei, weil es im Wesentlichen sehr ausgefeilte Antworten auf die falsche Fragestellung liefert.

Es mag überraschend sein, aber Differentiable Programming glänzt wirklich nicht, weil es grundsätzlich super leistungsstark ist - das ist es -, sondern es glänzt, weil es normalerweise das erste Mal ist, dass etwas wirklich Relevantes für das Geschäft im Unternehmen implementiert wird. Wenn Sie nur ein Beispiel haben möchten, das meiste, was in der Lieferkette implementiert wird, sind typischerweise Modelle wie das Sicherheitsbestand-Modell, die absolut keine Relevanz für irgendeine reale Lieferkette haben. Zum Beispiel nehmen Sie im Sicherheitsbestand-Modell an, dass es möglich ist, eine negative Vorlaufzeit zu haben, was bedeutet, dass Sie jetzt bestellen und gestern geliefert werden. Das ergibt keinen Sinn, und daher sind die operativen Ergebnisse für Sicherheitsbestände in der Regel unbefriedigend.

Differentiable Programming glänzt durch Relevanz, nicht durch eine Art großartige numerische Überlegenheit oder dadurch, besser zu sein als andere alternative Machine-Learning-Techniken. Der Punkt ist wirklich, in einer Welt, die sehr komplex, chaotisch, feindlich und ständig im Wandel ist und in der Sie mit einer halb albtraumhaften Anwendungslandschaft umgehen müssen, die die zu verarbeitenden Daten darstellt, Relevanz zu erreichen.

Es scheint, dass es keine weiteren Fragen gibt. In diesem Fall werde ich Sie nächsten Monat zur Vorlesung über probabilistisches Modellieren für die Lieferkette sehen.