00:01 イントロダクション
02:44 予測ニーズの調査
05:57 モデルとモデリング
12:26 これまでのストーリー
15:50 少しの理論と少しの実践
17:41 差分可能プログラミング、SGD 1/6
24:56 差分可能プログラミング、自動微分 2/6
31:07 差分可能プログラミング、関数 3/6
35:35 差分可能プログラミング、メタパラメータ 4/6
37:59 差分可能プログラミング、パラメータ 5/6
40:55 差分可能プログラミング、クセ 6/6
43:41 ウォークスルー、小売需要予測
45:49 ウォークスルー、パラメータのフィッティング 1/6
53:14 ウォークスルー、パラメータの共有 2/6
01:04:16 ウォークスルー、損失マスキング 3/6
01:09:34 ウォークスルー、共変量の統合 4/6
01:14:09 ウォークスルー、疎な分解 5/6
01:21:17 ウォークスルー、フリースケーリング 6/6
01:25:14 ホワイトボックス
01:33:22 実験的最適化に戻る
01:39:53 結論
01:44:40 今後の講義と視聴者の質問
説明
差分可能プログラミング（DP）は、予測的なサプライチェーンの課題に非常に適している広範な統計モデルを設計するために使用される生成的なパラダイムです。DPは、パラメトリックモデルに基づくほとんどの「クラシック」な予測文献を凌駕しています。また、DPは「クラシック」な機械学習アルゴリズムにも優れており、実用的なサプライチェーンの目的においては、採用の容易さを含むほとんどすべての重要な側面で、2010年代後半まで優れています。
フルトランスクリプト
このサプライチェーンの講義シリーズへようこそ。私はジョアネス・ヴェルモレルです。今日は、「サプライチェーンにおける差分可能プログラミングを用いた構造化予測モデリング」を紹介します。正しい行動を選択するには、将来についての詳細な数量的な洞察が必要です。実際、すべての意思決定（もっと買う、もっと生産するなど）は、将来のある程度の予測に基づいています。一般的に、サプライチェーン理論では、この問題に対処するために予測の概念を強調しています。しかし、少なくともそのクラシックな形態では、予測の視点は2つの面で不十分です。
第一に、それは狭い時系列の予測視点を強調しており、現実のサプライチェーンで見つかるさまざまな課題に対応することができません。第二に、それは時系列の予測精度に焦点を絞っており、それも大いに問題です。予測の精度をわずかに向上させることは、サプライチェーンにおける追加の収益を自動的に生み出すわけではありません。
本講義の目的は、予測に対する代替手法を見つけることです。この手法は、一部が技術であり、一部が方法論です。技術としては、微分可能プログラミングを使用し、方法論としては、構造化された予測モデルを使用します。この講義の終わりまでに、この手法をサプライチェーンの状況に適用することができるようになるはずです。この手法は理論的なものではありません。Lokadのデフォルトの手法として数年間使用されてきました。また、前の講義を見ていない場合でも、この講義は完全に理解できないわけではありません。ただし、この講義シリーズでは、講義を順番に見ることが非常に役立つようになっています。この講義では、以前の講義で紹介された要素をいくつか再訪します。
サプライチェーンの予測ニーズの調査において、将来の需要予測が明らかな候補です。実際、需要のより良い予測は、購入や生産などの非常に基本的な意思決定において重要な要素です。しかし、この講義シリーズの第3章で紹介したサプライチェーンの原則を通じて、サプライチェーンを推進するための予測要件にはさまざまな期待があることがわかりました。
特に、例えば、リードタイムは異なり、リードタイムには季節パターンがあります。実際、在庫に関連するほとんどの意思決定には、将来の需要だけでなく、将来のリードタイムの予測も必要です。したがって、リードタイムも予測する必要があります。返品は流れの最大50％を占めることもあります。たとえば、ドイツのファッションEコマースの場合です。このような状況では、返品の予測が重要であり、返品は製品によって大きく異なります。したがって、このような状況では、返品も予測する必要があります。
サプライサイドでは、生産自体が変動することがあり、追加の遅延やリードタイムの変動だけでなく、不確実性も存在する場合があります。これは農業などの低技術産業だけでなく、製薬産業などのハイテク産業でも起こります。したがって、生産収益も予測する必要があります。最後に、顧客の行動も非常に重要です。たとえば、獲得を生み出す製品を通じて需要を喚起することは非常に重要です。逆に、ストックアウトのために製品が欠品していると、その製品がストックアウトのために大きな離脱を引き起こす場合も非常に重要です。したがって、これらの行動は分析や予測、つまり予測が必要です。ここでの重要なポイントは、時系列予測はパズルの一部に過ぎないということです。現実のサプライチェーンに直面するすべての状況に対応するためには、これらの状況を包括的に捉える予測手法が必要です。
予測問題に取り組む際の定番の手法は、モデルを提示することです。この手法は、数十年にわたって時系列予測の文献を牽引してきましたし、現在でも機械学習の分野では主流の手法と言えるでしょう。このモデル中心の手法、それが私がこの手法を指す方法ですが、このモデル中心の視点が実際に何を意味しているのかを評価するためには、一時的に立ち止まることさえ難しいかもしれません。
この講義の提案は、サプライチェーンにはモデリング技術、モデリング中心の視点が必要であり、一連のモデルだけでは、現実のサプライチェーンで見つかるすべての要件に対応するのに十分ではないということです。モデル中心の手法とモデリング中心の手法の違いを明確にしましょう。
モデル中心の手法は、まず何よりもモデルに重点を置いています。モデルはパッケージとして提供され、実際に実行できるソフトウェアの形で提供されることが一般的です。ソフトウェアが利用できない場合でも、モデルは数学的な正確さで説明されることが期待されており、モデルの完全な再実装が可能です。このパッケージ、モデルをソフトウェア化したものが最終目標とされています。
理想的な視点からすると、このモデルは数学関数とまったく同じように振る舞うことが期待されます。入力を受け取り、結果を出力します。モデルに残された設定可能な要素がある場合、それらの設定可能な要素は未解決の問題として扱われます。実際、設定オプションが増えると、モデルの妥当性が弱まります。モデル中心の視点では、設定可能性とオプションの数が多すぎると、モデルはモデルの空間に溶け込んでしまい、一つのモデルというものが存在しなくなります。
モデリング手法は、設定可能性の角度から完全に逆のアプローチを取ります。モデルの表現力を最大化することが最終目標となります。これはバグではなく、むしろ特徴となります。モデリング中心の視点を見ている場合、状況は非常に混乱することがあります。なぜなら、モデリング中心の視点のプレゼンテーションを見ている場合、私たちが見るのはモデルのプレゼンテーションです。しかし、これらのモデルには非常に異なる意図があります。
モデリングの視点を取ると、提示されるモデルは単なるイラストです。それは完全であることや問題の最終的な解決策であることを意図しているわけではありません。それはモデリング技術自体を説明するための一歩に過ぎません。モデリング技術の主な課題は、アプローチを評価することが非常に困難になることです。実際、私たちは素朴なベンチマークオプションを失ってしまいます。なぜなら、このモデリング中心の視点では、モデルの可能性があるからです。私たちは特定のモデルと他のモデルを比較することに特に焦点を当てていません。これは正しい考え方ではありません。私たちには教養ある意見があります。
ただし、ベンチマークとベンチマークに関連付けられた数値があるからといって、それが自動的に科学的なものと見なされるわけではありません。数値は単なる無意味なものかもしれませんし、逆に、教養ある意見だからといって、それが科学的なものよりも劣っているわけではありません。ある意味では、それはただ異なるアプローチであり、現実のところ、さまざまなコミュニティの間で、これらの2つのアプローチは共存しています。
たとえば、2017年にFacebookのチームによって発表された「Forecasting at Scale」という論文を見ると、それはまさにモデル中心のアプローチの典型です。この論文では、Facebook Prophetモデルのプレゼンテーションがあります。また、2018年にFacebookの別のチームによって発表された「Tensor Comprehension」という論文では、本質的にモデリング手法が紹介されています。この論文はモデリングアプローチの典型と見なすことができます。したがって、同じ会社で働く研究チームでも、状況に応じて問題を異なる角度から取り組むことができることがわかります。
この講義は、サプライチェーンの一連の講義の一部です。最初の章では、サプライチェーンを研究の対象として、また実践としての両方の観点から私の見解を述べました。最初の講義から、私は主流のサプライチェーン理論が期待に応えていないと主張してきました。主流のサプライチェーン理論は、モデル中心のアプローチに大いに依存しているため、現実のサプライチェーンのニーズとの間に摩擦が生じる主な原因の1つだと私は考えています。
この講義シリーズの第2章では、一連の手法を紹介しました。実際、単純な手法は通常、サプライチェーンの状況の断続的で頻繁に敵対的な性質によって打ち負かされます。特に、第2章の一部である「経験的実験最適化」という講義は、私が今日の講義で採用している視点の一例です。
第3章では、一連のサプライチェーンのペルソナを紹介しました。これらのペルソナは、候補解決策を完全に無視し、私たちが解決しようとしている問題に焦点を当てたものです。これらのペルソナは、現実のサプライチェーンが直面する予測の多様性を理解する上で重要です。これらのペルソナは、現実のサプライチェーンの細かい詳細に注意を払わずに行われるサプライチェーン理論の狭い時系列の視点にはまり込むことを避けるために不可欠だと私は考えています。
第4章では、一連の補助科学を紹介しました。これらの科学はサプライチェーンとは異なるものですが、現代のサプライチェーンの実践にはこれらの学問の初級レベルの理解が必要です。この第4章では、微分可能プログラミングについて簡単に触れましたが、数分後にこのプログラミングパラダイムをより詳細に紹介します。
最後に、この第5章の最初の講義では、2020年に行われた世界的な予測競争で最先端の予測精度を達成した、単純であると言えるモデルを見ました。今日は、前の講義で紹介したこのモデルのパラメータを学習するために使用できる一連の技術を紹介します。
この講義の残りの部分は、大まかに2つのブロックに分かれ、最後にいくつかの考えを述べます。最初のブロックは、微分可能プログラミングに dedicされています。第4章でこのトピックに触れたことがありますが、今日はより詳しく見ていきます。この講義の終わりまでには、独自の微分可能プログラミングの実装をほぼ作成できるようになるはずです。ただし、使用しているテックスタックによっては、結果は異なる場合があります。また、微分可能プログラミングは独自の技術であり、実践的にスムーズに動作させるには経験が必要です。
この講義の2番目のブロックは、小売需要予測のシチュエーションの解説です。この解説は、前の講義の続きであり、2020年のM5予測競争で1位を獲得したモデルを紹介しました。ただし、前のプレゼンテーションでは、モデルのパラメータが実際にどのように計算されるかは詳細に説明されていませんでした。この解説では、それを具体的に説明し、前の講義で取り上げられなかった在庫切れやプロモーションなどの重要な要素もカバーします。最後に、これらの要素に基づいて、私はサプライチェーンの目的に微分可能プログラミングが適しているかどうかについて議論します。
確率的勾配降下法（SGD）は、微分可能プログラミングの2つの柱の1つです。SGDは見かけによらずシンプルでありながら、なぜうまく機能するのかはまだ完全には理解されていません。なぜうまく機能するのかは完全には明確ではありませんが、なぜうまく機能するのかは完全には明確ではありません。
確率的勾配降下法の歴史は1950年代までさかのぼることができ、長い歴史を持っています。しかし、この技術は、ディープラーニングの登場により、最近の10年間で主流の認識を得ました。確率的勾配降下法は、数学的最適化の観点に深く根ざしています。最小化したい損失関数Qと、すべての可能な解を表す実数のパラメータWがあります。私たちが見つけたいのは、損失関数Qを最小化するパラメータWの組み合わせです。
損失関数Qは、基本的な性質を持つ必要があります。それは、一連の項に加法的に分解できるということです。この加法的分解の存在により、確率的勾配降下法が機能します。もし損失関数がこのように加法的に分解できない場合、確率的勾配降下法は適用できません。この観点では、Xは損失関数に寄与するすべての項の集合を表し、Qxはこの観点での部分損失を表します。
確率的勾配降下法は、学習の状況に特化したものではありませんが、すべての学習ユースケースに非常に適しています。ここで言う学習とは、機械学習のユースケースのことです。実際には、トレーニングデータセットがある場合、このデータセットは、各観測値がモデルの入力を表す特徴量のペアと、出力を表すラベルのペアで構成されるリストの形式を取ります。学習の観点からは、最も良い結果を示すモデルをエンジニアリングすることが目的です。Xは実際には観測値のリストであり、パラメータはこのデータセットに最も適合するように最適化しようとする機械学習モデルのパラメータです。
確率的勾配降下法は、基本的には反復的なプロセスであり、一度に1つの観測値をランダムに反復します。一度に1つの観測値、小さなXを選び、この観測値に対して局所的な勾配、つまりQxのナブラを計算します。これは完全な損失関数の勾配ではなく、損失関数の項にのみ適用される局所的な勾配です。これは部分的な勾配と見なすことができます。
確率的勾配降下法のステップは、この局所的な勾配を取り、この部分的な勾配に基づいてパラメータWを少し変化させることです。これは、WがWマイナスイータタイムズナブラQxWで更新されることを意味しています。これは、非常に簡潔な形で、Xで得られた非常に局所的な勾配の方向にWパラメータを少し変化させることを意味しています。ここで、Xはデータセットの観測値の1つであり、学習の観点から問題に取り組んでいる場合です。その後、ランダムに進み、この局所的な勾配を適用し、反復します。
確率的勾配降下法は、より高速な反復とノイズの多い勾配、そしてより詳細でより速い反復までのトレードオフを示すため、直感的に非常に効果的です。確率的勾配降下法の本質は、勾配の非常に不完全な測定値を持っていても、それらの不完全な測定値を非常に高速に取得できる限り、それに気にしないということです。ノイズの多い勾配の代償として、より高速な反復にトレードオフを移動できるなら、それを行いましょう。そのため、確率的勾配降下法は、パラメータWの特定の品質の解を達成するために必要な計算リソースの量を最小限に抑えるのに非常に効果的です。
最後に、学習率として参照されるeta変数があります。実際には、学習率は一定ではありません。確率的勾配降下法が進行するにつれて、この変数は変化します。Lokadでは、学習率のetaパラメータの進化を制御するためにAdamアルゴリズムを使用しています。Adamは2014年に発表された手法であり、確率的勾配降下法が関与する場合に非常に人気があります。
微分可能プログラミングの第2の要素は、自動微分です。以前の講義でこの概念をすでに見てきました。コードの一部を見ながら、この概念を再訪してみましょう。このコードは、Lokadが供給チェーンの予測最適化の目的で設計した特定のドメイン向けプログラミング言語であるEnvisionで書かれています。私はEnvisionを選んでいますが、例がPython、Java、またはC#を使用する場合に比べてはるかに簡潔で、おそらくはるかに明確です。ただし、Envisionを使用しているとしても、秘密のソースはありません。これらの例を他のプログラミング言語で完全に再実装することもできます。おそらくコードの行数が10倍になるでしょうが、大局を考えれば、これは細部です。ここでは、講義のために、Envisionが非常に明確で簡潔なプレゼンテーションを提供してくれます。
微分可能プログラミングを使用して線形回帰を解決する方法を見てみましょう。これはおもちゃの問題です。線形回帰を行うために微分可能プログラミングを使用する必要はありません。目標は、微分可能プログラミングの構文に慣れることです。1行から6行まで、観測テーブルを表すテーブルTを宣言しています。観測テーブルとは、Xと名付けられた確率的勾配降下法のセットのことです。これはまったく同じものです。このテーブルには、Xという特徴量とYというラベルの2つの列があります。私たちが望むのは、入力としてXを取り、線形モデル、具体的にはアフィンモデルでYを予測することです。明らかに、このテーブルTにはわずか4つのデータポイントしかありません。これは非常に小さなデータセットですが、説明の明瞭さのために行っています。
8行目で、autodiffブロックを導入します。autodiffブロックは、Envisionでのループと見なすことができます。この場合、テーブルTを反復処理するループです。これらの反復は、確率的勾配降下法のステップを反映しています。したがって、Envisionの実行がこのautodiffブロックに入ると、観測テーブルから行を選択し、確率的勾配降下法のステップを適用する繰り返し実行のシリーズがあります。そのためには、勾配が必要です。
勾配はどこから来るのでしょうか？ここでは、モデルのプログラム、Ax + Bを書きました。平均二乗誤差という損失関数を導入します。勾配を持つ必要があります。このような単純な状況では、勾配を手動で書くこともできます。ただし、自動微分は、プログラムを2つの形式でコンパイルすることができる技術です。最初の形式はプログラムの順方向実行であり、2番目の形式はプログラム内のすべてのパラメータに関連する勾配を計算する逆方向実行の形式です。
L9 9行目と10行目では、キーワード「auto」を使用して、2つのパラメータAとBの宣言を行っています。これにより、Envisionによるこれら2つのパラメータの値の自動初期化が行われます。AとBはスカラー値です。自動微分は、このautodiffブロックに含まれるすべてのプログラムに対して行われます。基本的には、このプログラムを順方向パスのために1回、勾配の値を提供するプログラムのために2回コンパイルするためのコンパイラレベルの技術です。自動微分の技術の美しいところは、通常のプログラムを計算するために必要なCPUの量が、逆方向パスを行うために必要なCPUの量と一致することを保証するという点です。これは非常に重要な特性です。最後に、14行目で、autodiffブロックで学習したパラメータを出力します。
微分可能プログラミングは、本当に優れたプログラミングパラダイムです。任意の複雑なプログラムを構成し、このプログラムの自動微分を得ることができます。このプログラムには、例えば分岐や関数呼び出しなどが含まれる場合もあります。このコード例では、前の講義で紹介したピンボール損失関数を再訪します。ピンボール損失関数は、経験的確率分布からの偏差を観測した場合に、分位数の推定値を導出するために使用することができます。推定値の平均二乗誤差を最小化すると、経験的分布の平均値の推定値が得られます。ピンボール損失関数を最小化すると、分位数のターゲットの推定値が得られます。90番目の分位数を目指す場合、それは確率分布の中で、観測される未来の値が推定値よりも90%の確率で下回る値であるか、10%の確率で上回る値であることを意味します。これは、サプライチェーンに存在するサービスレベル分析に似ています。
1行目と2行目では、ポアソン分布からランダムにサンプリングされた偏差で埋められた観測テーブルを導入しています。ポアソン分布の値は平均3でサンプリングされ、10,000の偏差を得ます。4行目と5行目では、ピンボール損失関数の独自の実装を展開しています。この実装は、前の講義で紹介したコードとほぼ同じです。ただし、キーワード「autodiff」が関数の宣言に追加されています。このキーワードは、関数の宣言に付加されると、Envisionコンパイラがこの関数を自動的に微分できるようにします。理論的には、自動微分は任意のプログラムに適用できますが、実際には、微分する意味がないプログラムや、微分することが意味をなさない多くの関数が存在します。たとえば、2つのテキスト値を取り、それらを連結する関数を考えてみてください。自動微分の観点からは、この種の操作に自動微分を適用することは意味がありません。自動微分には、微分しようとしている関数の入力と出力に数値が存在する必要があります。
7行目から9行目では、autodiffブロックがあります。このブロックでは、観測テーブルを介して受け取った経験的分布のターゲット分位数の推定値を計算します。内部では、実際にはポアソン分布です。分位数の推定値は、8行目で「quantile」という名前のパラメータとして宣言され、9行目で独自のピンボール損失関数を呼び出します。分位数のターゲットは0.5と設定されているため、実際には分布の中央値の推定値を求めています。最後に、11行目で、autodiffブロックの実行によって学習した値の結果を出力します。このコードの一部は、自動的に関数呼び出しと分岐を含むプログラムが完全に自動的に実行されることを示しています。
私は、autodiffブロックが観測テーブルから1行ずつ選んで一連の確率的勾配降下（SGD）ステップを実行するループとして解釈できると述べました。ただし、この状況の停止条件についてはかなり曖昧なままです。Envisionでは、確率的勾配降下はデフォルトで10エポック後に停止します。機械学習の用語では、エポックは観測テーブルを完全に通過することを表します。7行目では、autodiffブロックに「epochs」という属性を付けることができます。この属性はオプションです。デフォルトでは値は10ですが、この属性を指定すると別の値を選択できます。ここでは、100エポックを指定しています。計算にかかる合計時間は、エポックの数にほぼ比例することに注意してください。したがって、エポック数が2倍になると、計算時間も2倍になります。
それでも、7行目では「learning_rate」という2番目の属性も導入しています。この属性もオプションで、デフォルトではautodiffブロックに0.01という値が付けられています。この学習率は、学習率の進化を制御するAdamアルゴリズムの初期化に使用される係数です。これは、確率的勾配降下のステップで見たetaパラメータを制御します。基本的に、このパラメータを頻繁に調整する必要はありませんが、このパラメータを微調整することで、確率的勾配降下の合計計算時間の約20%を節約できることが予想されます。
autodiffブロックで学習されるパラメータの初期化も詳しく調べる必要があります。これまでは「auto」というキーワードを使用してきましたが、Envisionでは、これは単にEnvisionがパラメータをランダムに選んで平均1、標準偏差0.1のガウス分布から値を引き出すことを意味します。この初期化は、通常のディープラーニングの慣例とは異なり、パラメータがゼロを中心としたガウス分布でランダムに初期化されるという点で異なります。なぜLokadがこのようなアプローチを取ったのかは、実際の小売需要予測の状況を進めていく中でより明確になります。
Envisionでは、パラメータの初期化をオーバーライドして制御することも可能です。たとえば、「quantile」というパラメータは9行目で宣言されていますが、初期化する必要はありません。実際、autodiffブロックの直前の7行目には、値が4.2に割り当てられた変数「quantile」があり、変数は既に与えられた値で初期化されています。もはや自動的な初期化は必要ありません。また、パラメータの許容範囲を指定することも可能であり、これは9行目の「in」キーワードで行われます。基本的に、「quantile」は1から10の範囲にある必要があると定義しています。この範囲外のパラメータ値をAdamから得た更新が押し出そうとする場合、変更を範囲内に留めるためにAdamからの変更を制限します。さらに、通常はAdamアルゴリズムに付随するモーメンタム値をゼロに設定します。パラメータの範囲を強制することは、クラシックなディープラーニングの慣行とは異なりますが、この機能の利点は、実際の小売需要予測の例を議論し始めると明らかになります。
Differentiable programming relies heavily on stochastic gradient descent. The stochastic angle is literally what makes the descent work very fast. It is a double-edged sword; the noise obtained through the partial losses is not just a bug, but also a feature. By having a little bit of noise, the descent can avoid remaining stuck in zones with very flat gradients. So, having this noisy gradient not only makes the iteration much faster but also helps nudging the iteration to get out of areas where the gradient is very flat and causes the descent to slow down. However, one thing to keep in mind is that when stochastic gradient descent is used, the sum of the gradient is not the gradient of the sum. As a result, stochastic gradient descent comes with minor statistical biases, especially when tail distributions are concerned. However, when these concerns arise, it is relatively straightforward to duct-tape the numerical recipes, even if the theory remains a bit muddy.
Differentiable programming (DP) should not be confused with an arbitrary mathematical optimization solver. The gradient must flow through the program for differentiable programming to work at all. Differentiable programming can work with arbitrarily complex programs, but those programs have to be engineered with differentiable programming in mind. Also, differentiable programming is a culture; it’s a set of tips and tricks that play well with stochastic gradient descent. All things considered, differentiable programming is on the easy side of the machine learning spectrum. It is very approachable as a technique. Nevertheless, it takes a bit of craftsmanship to master this paradigm and operate it smoothly in production.
We are now ready to embark on the second block of this lecture: the walkthrough. We will have a walkthrough for our retail demand forecasting task. This modeling exercise is aligned with the forecasting challenge that we presented in the previous lecture. In brief, we want to forecast the daily demand at the SKU level in a retail network. An SKU, or stock-keeping unit, is technically the Cartesian product between products and stores, filtered along the entries of the assortment. For example, if we have 100 stores and 10,000 products, and if every single product is present in every store, we end up with 1 million SKUs.
There are tools to transform a deterministic estimate into a probabilistic one. We have seen one of those tools in the previous lecture through the ESSM technique. We will revisit this specific concern—turning estimates into probabilistic estimates—in greater detail in the next lecture. However, today, we are only concerned with estimating averages, and all other types of estimates (quantiles, probabilistic) will come later as natural extensions of the core example that I will present today. In this walkthrough, we are going to learn the parameters of a simple demand forecasting model. The simplicity of this model is deceptive because this class of model does achieve state-of-the-art forecasting, as illustrated in the M5 forecasting competition in 2020.
For our parametric demand model, let’s introduce a single parameter for every single SKU. This is an absolutely simplistic form of model; the demand is modeled as a constant for each SKU. However, it is not the same constant for every SKU. Once we have this constant daily average, it’s going to be the same value for all the days of the entire life cycle of the SKU.
異なる可能性のある推定値を確率的なものに変換するためのツールがあります。前の講義でESSM技術を通じてそのようなツールの1つを見てきました。次の講義では、この特定の問題、つまり推定値を確率的な推定値に変換することについて、さらに詳しく取り上げます。しかし、今日は平均値の推定にのみ関心があり、他のすべての推定値（分位数、確率的なもの）は、私が今日紹介するコアの例の自然な拡張として後で登場します。この解説では、単純な需要予測モデルのパラメータを学びます。このモデルの単純さは欺瞞的ですが、このモデルのクラスは、2020年のM5予測コンテストで示されているように、最先端の予測を実現しています。
私たちのパラメトリックな需要モデルでは、各SKUごとに単一のパラメータを導入しましょう。これはまったく単純化されたモデルの形式です。需要は各SKUごとに定数としてモデル化されます。ただし、すべてのSKUに対して同じ定数ではありません。この定数の日次平均を持っていると、SKUの全寿命のすべての日に同じ値になります。
異なる可能性のある推定値を確率的なものに変換するためのツールがあります。前の講義でESSM技術を通じてそのようなツールの1つを見てきました。次の講義では、この特定の問題、つまり推定値を確率的な推定値に変換することについて、さらに詳しく取り上げます。しかし、今日は平均値の推定にのみ関心があり、他のすべての推定値（分位数、確率的なもの）は、私が今日紹介するコアの例の自然な拡張として後で登場します。この解説では、単純な需要予測モデルのパラメータを学びます。このモデルの単純さは欺瞞的ですが、このモデルのクラスは、2020年のM5予測コンテストで示されているように、最先端の予測を実現しています。
ここで何が起こっているかを理解するために、いくつかのブロードキャストの振る舞いが発生しています。テーブル「T」はSKUと日付のクロステーブルです。autodiffブロックは、観測テーブルの行を反復する反復です。9行目では、autodiffブロック内にいるため、SKUテーブルの行を選択しました。値「SKUs.level」はここではベクトルではなく、スカラーです。観測テーブルの行を1つだけ選択したため、値は1つだけです。その後、「T.sold」はもはや行列ではありません。すでに1つのSKUを選択しているため、残っているのは「T.sold」が実際にはベクトルであり、日付と同じ次元を持つベクトルであるということです。この引き算「SKUs.level - T.sold」を行うと、日付テーブルに整列されたベクトルが得られ、それを「D.delta」というベクトルに割り当てます。このベクトルは1日ごとに1行、2年と1ヶ月分の行があります。最後に、9行目では損失関数を計算しています。このモデルは非常に単純です。カレンダーパターンについては、何ができるか見てみましょう。
パラメータ共有は、おそらく最もシンプルで有用な微分可能プログラミングのテクニックの1つです。パラメータが複数の観測行に寄与する場合、そのパラメータは共有されていると言われます。観測ごとにパラメータを共有することで、勾配降下法を安定化させ、過学習の問題を緩和することができます。曜日パターンを考えてみましょう。各個別のSKUに対してさまざまな重みを表す7つのパラメータを導入することができます。これまでのところ、1つのSKUには需要の定数のみがあります。需要の認識を豊かにするために、各曜日には独自の重みがあると言えます。週には7日あるため、7つの重みがあり、それらの重みを乗算して適用することができます。
ただし、すべてのSKUに独自の曜日パターンがある可能性は低いです。現実的には、カテゴリや製品ファミリー、製品カテゴリ、製品サブカテゴリ、または店舗の部門など、カテゴリやグループ化レベルが存在すると仮定する方がはるかに妥当です。私たちはSKUごとに7つのパラメータを導入したいのではなく、曜日パターンに関して均質な振る舞いがあると仮定するグループ化レベルであるカテゴリごとに7つのパラメータを導入したいのです。
もしも私たちがレベルに対してこの7つのパラメータを乗算効果として導入することを決めた場合、これは前の講義でこのモデルに取られたアプローチとまったく同じです。このモデルはM5コンペティションのSKUレベルで1位になりました。レベルと曜日パターンの乗算効果があります。
コードでは、1行から5行目には以前と同じくモックデータのブロックがあり、“category"という名前の追加のテーブルを導入しています。このテーブルはSKUのグループ化テーブルであり、概念的にはSKUテーブルの各行には、カテゴリテーブルで一致する行が1つだけあります。Envision言語では、カテゴリはSKUテーブルの上流にあると言います。7行目では、曜日テーブルを導入しています。このテーブルは重要であり、キャプチャしたい周期的なパターンを反映した特定の形状で導入しています。7行目では、日付を7で割った値に基づいて日付を集計して曜日テーブルを作成しています。作成するテーブルはちょうど7行あり、それぞれの行が週の7日の1つを表します。日付テーブルの各行について、データベースの各行には日付テーブルの1つの対応があります。したがって、Envision言語に従えば、曜日テーブルはテーブル「date」の上流にあります。
これで、カテゴリと曜日のテーブルであるテーブル「CD」があります。行数に関しては、このテーブルはカテゴリの数×7行と同じ数の行を持ちます。曜日は7行あります。12行目では、「CD.DOW」（DOWは曜日を表す）という新しいパラメータを導入しています。自由度の観点からは、カテゴリごとに正確に7つのパラメータ値があります。私たちは、1つのカテゴリごとに1つのパターンだけを持つモデルを求めています。SKUごとに1つのパターンではなく、カテゴリごとに1つのパターンをキャプチャするモデルが欲しいのです。
このパラメータを宣言し、キーワード「in」を使用して「CD.DOW」の値が0.1から100の間であることを指定します。13行目では、モデルによって表される需要を書きます。需要は「SKUs.level * CD.DOW」となります。需要から観測された「T.sold」を引いたものがデルタとなります。そして、平均二乗誤差を計算します。
13行目では、かなりのブロードキャストの魔法が行われています。「CD.DOW」はカテゴリと曜日のクロステーブルです。autodiffブロック内にいるため、テーブルCDはカテゴリと曜日のクロステーブルです。autodiffブロック内にいるため、ブロックはSKUsテーブルを反復処理しています。基本的には、1つのSKUを選択すると、カテゴリも選択されたことになります。カテゴリテーブルは上流にあるため、CD.DOWはもはや行列ではなく、次元が7のベクトルです。ただし、それは「date」テーブルの上流にあるため、これらの7つの行は「date」テーブルにブロードキャストされます。このブロードキャストを行う唯一の方法は、曜日テーブルの各行が日付テーブルの特定の行と関連付けられているためです。二重ブロードキャストが行われ、最終的にはSKUの曜日レベルで周期的な値の需要が得られます。これが現時点での私たちのモデルであり、損失関数の残りの部分は変わりません。
Envisionの関係性の性質とその微分可能なプログラミング能力から得られるブロードキャストの振る舞いを組み合わせることで、周期性に対処する非常に優れた方法が見つかりました。カレンダーの周期性をたった3行のコードで表現することができます。このアプローチは、非常に疎なデータを扱っている場合でもうまく機能します。平均して1ヶ月に1つの単位しか売れない商品を見ている場合でも、問題ありません。そのような場合、賢明なアプローチは、数十、もしくは数百の商品を含むカテゴリを持つことです。このテクニックは、年の月や月の日など、他の周期的なパターンを反映するためにも使用することができます。
M5コンペティションで最先端の結果を達成した前の講義で紹介したモデルは、週の曜日、年の月、月の日の3つの周期性の乗算の組み合わせでした。これらのパターンはすべて乗算として連鎖されました。他の2つのバリエーションの実装は、注意深い聴衆に委ねられていますが、周期的なパターンごとにわずか数行のコードで実現できるため、非常に簡潔です。
前の講義では、販売予測モデルを紹介しました。ただし、私たちが興味を持つのは販売ではなく需要です。ゼロの販売とゼロの需要を混同してはいけません。ある日、店舗で顧客が買うための在庫がなかった場合、Lokadでは在庫切れに対処するために損失マスキング技術が使用されます。これは在庫切れに対処するための最も単純な技術ですが、唯一の技術ではありません。私の知る限りでは、製品には少なくとも2つの他の技術が使用されており、それぞれに長所と短所があります。これらの他の技術は今日は取り上げませんが、後の講義で取り上げます。
コードの例に戻り、1行から3行まではそのままです。次に続く部分を見てみましょう。6行目では、モックデータに在庫の有無を示すブールフラグを追加しています。各SKUと各日について、その日の終わりに在庫切れがあったかどうかを示すブール値があります。15行目では、在庫切れが観測された日を除外するために、損失関数を変更してそれらをゼロにします。これにより、在庫切れの発生によるバイアスが存在する状況では、勾配がバックプロパゲーションされないことを保証しています。
損失マスキングテクニックの最も困惑する側面は、それがモデル自体を変更しないことです。実際には、14行目で表現されたモデルを見ると、まったく同じです。触れられていません。変更されるのは損失関数自体だけです。このテクニックはシンプルかもしれませんが、モデル中心の視点から大きく逸脱しています。それは、その本質的にはモデリング中心のテクニックです。在庫切れによるバイアスを認識し、モデリングの努力に反映させることで、状況を改善しています。ただし、これは精度指標を変更することであり、モデル自体を変更しているわけではありません。言い換えれば、最適化する損失を変更しており、純粋な数値エラーの観点で他のモデルと比較できないモデルになっています。
Walmartのような状況では、前の講義で議論されたように、損失マスキングテクニックはほとんどの製品に適しています。一般的な指針として、このテクニックは、需要がほとんどの時間在庫が1つしかないほどまばらでない場合にうまく機能します。また、在庫切れが非常に頻繁に発生する製品は避けるべきです。なぜなら、小売業者の明示的な戦略が、その日の終わりに在庫切れになることを目指しているからです。これは通常、小売業者がその日の終わりまでに在庫切れの状況を目指している一部の超新鮮な製品に起こります。これらの制限を補う代替技術もありますが、今日はそれについて説明する時間がありません。
プロモーションは小売業における重要な要素です。一般的に、価格設定や商品をゴンドラに移動するなど、小売業者が需要を影響し形成するためのさまざまな方法があります。予測目的のための追加情報を提供する変数は、サプライチェーンの分野では通常、共変量と呼ばれます。天候データやソーシャルメディアデータなどの複雑な共変量については、多くの願望的な考えがあります。ただし、高度なトピックに入る前に、明らかに需要に大きな影響を与える価格情報など、部屋の中の象としての問題に取り組む必要があります。したがって、このコードの例の7行目で、14行目の各日に対して「category.ed」という共有ベクトルパラメータを導入します。ここで、「ed」は需要の弾力性を表すものです。16行目では、価格弾力性の指数形式を導入します。指数形式は(-category.ed * t.price)の指数関数です。直感的には、価格が上昇すると、指数関数の存在により需要が急速にゼロに収束します。逆に、価格がゼロに収束すると、需要は急激に増加します。
この指数形式の価格反応は単純化されていますが、パラメータを共有することで、この指数関数をモデルで使用しても高い数値的安定性が確保されます。実際の世界の設定では、特にWalmartのような状況では、割引、通常価格との差、サプライヤーによって実行されるマーケティングプッシュを表す共変量、ゴンドラなどを導入するカテゴリ変数など、さまざまな価格情報があります。微分可能なプログラミングを使用すると、ほとんどどのような種類の共変量でも非常に簡単に統合できます。
スロームーバーは小売業や他の多くの業界で生じる現象です。これまでに紹介したモデルは、SKUごとに1つのパラメータ、共有パラメータを含めるとさらに多くのパラメータを持っています。しかし、これはすでに多すぎるかもしれません、特に1年に1回しか回転しないSKUや年に数回しか回転しないSKUの場合は。そのような状況では、SKUレベルで自由度を持つすべてのパラメータを削除し、共有パラメータのみに頼る必要があります。
L6 2行目と4行目で、「products」と「stores」という2つのテーブルを導入し、「SKUs」というテーブルは、productsとstoresの直積のフィルタリングされたサブテーブルとして構築されます。これがアソートメントの定義そのものです。15行目と16行目では、2つの共有ベクトルパラメータを導入しました。1つはproductsテーブルと関連性を持つレベルで、もう1つはstoreテーブルと関連性を持つレベルです。これらのパラメータは、0.01から100までの特定の範囲で定義されています。
今、18行目で、SKUごとのレベルは、製品レベルと店舗レベルの乗算として構成されます。スクリプトの残りの部分は変更されていません。では、どのように機能するのでしょうか？19行目で、SKU.levelはスカラーです。SKUsテーブルを反復処理するautodeskブロックがあります。これは観測テーブルです。したがって、18行目のSKUs.levelは単なるスカラー値です。次に、products.levelがあります。productsテーブルはSKUsテーブルの上流にあるため、単一のSKUに対して1つの製品テーブルがあります。したがって、products.levelは単なるスカラー値です。同様に、SKUsテーブルの上流にある店舗テーブルも同様です。18行目では、この特定のSKUには1つの店舗のみが関連付けられています。したがって、私たちが持っているのは2つのスカラー値の乗算であり、それがSKU.levelを与えます。モデルの残りの部分は変更されていません。
これらの技術は、時にはデータが十分でないとか、データが疎すぎるという主張に完全に新しい光を当てます。実際には、微分可能な観点からは、それらの主張は実際にはあまり意味をなしません。データが少なすぎるとか、データが疎すぎるというものは、絶対的な意味では存在しません。スパース性に向けて修正可能なモデルだけが存在します。このような強制された構造は、学習プロセスを可能にし、数値的に安定させるためのガイドレールのようなものです。
機械学習モデルがゼロからすべてのパターンを発見しようとする他の機械学習技術と比較して、この構造化アプローチは学習しなければならない構造そのものを確立します。したがって、ここで働く統計的なメカニズムは、学習する内容に制約があります。その結果、データ効率に関しては非常に効率的です。もちろん、これは適切な構造を選択していることに依存しています。
実験を行うことは非常に簡単です。すでに非常に複雑なことをしており、50行未満でかなり複雑なウォルマートのような状況に対処することができました。これは非常に大きな成果です。少し経験的なプロセスがありますが、実際にはそれほどでもありません。数十行のことを話しています。会社や大規模な小売ネットワークを運営しているERPの場合、通常、1000のテーブルとテーブルごとに100のフィールドがあります。したがって、ビジネスシステムの複雑さは、この構造化予測モデルの複雑さと比較しても圧倒的に巨大です。少しの時間を反復する必要があるとしても、ほとんど何もありません。
さらに、M5予測コンテストで示されたように、サプライチェーンの実践者は既にパターンを知っています。M5チームが使用した3つのカレンダーパターン、つまり曜日、月、日のパターンは、経験豊富なサプライチェーンの実践者にとって自明のものでした。サプライチェーンにおいては、隠れたパターンを発見しようとしているわけではありません。たとえば、価格を大幅に下げると需要が大幅に増加するという事実は、誰にとっても驚くことではありません。残された唯一の問題は、その効果の大きさと応答の正確な形状です。これらは比較的技術的な詳細であり、少しの実験の機会を許すことで、これらの問題に比較的簡単に対処できます。
このウォークスルーの最後のステップとして、微分可能なプログラミングのわずかな特異性について指摘しておきたいと思います。微分可能なプログラミングは、一般的な数理最適化ソルバーとは混同されるべきではありません。私たちは、勾配降下法が行われていることを念頭に置かなければなりません。具体的には、パラメータの最適化と更新に使用されるアルゴリズムは、ADAMアルゴリズムに付属する学習率と等しい最大降下速度を持っています。Envisionでは、デフォルトの学習率は0.01です。
コードを見ると、4行目で、販売される数量が平均50のポアソン分布からサンプリングされる初期化が導入されています。レベルを学習する場合、技術的には、50程度のレベルが必要です。しかし、パラメータの自動初期化では、値が約1から始まり、0.01の増分でしか進むことができません。この値50に到達するには、約5,000エポックが必要です。非共有パラメータであるSKU.levelは、このパラメータはエポックごとに1回しか変更されません。したがって、計算を不必要に遅くするためには、5,000エポックが必要です。
下降を加速するために学習率を増やすことができますが、これは問題に取り組むための正しい方法ではありません。実際の状況では、この非共有パラメータに加えて共有パラメータも持っています。これらの共有パラメータは、各エポックごとに確率的勾配降下法によって何度も変更されます。学習率を大幅に増やすと、共有パラメータの数値的な不安定性が生じる可能性があります。SKUレベルの移動速度を高めることができますが、他のパラメータの数値的な安定性の問題を引き起こす可能性があります。
より良いテクニックは、パラメータを指数関数にリスケーリングすることで、これが8行目で行われていることです。このラッパーを使用すると、エポック数がはるかに少ない場合でも、レベルのパラメータ値が非常に低いか非常に高い場合に到達できます。この特異性は、小売需要予測のウォークスルーのために導入する必要がある唯一の特異性です。全体を考慮すると、それはわずかな特異性です。それにもかかわらず、異なるプログラミングでは勾配のフローに注意を払う必要があることを思い出させてくれます。異なるプログラミングは、全体的には流動的なデザイン体験を提供しますが、それは魔法ではありません。
いくつかの別れの言葉：構造化モデルは最先端の予測精度を達成します。このポイントは前の講義で詳しく説明されました。しかし、今日紹介された要素に基づいて言えば、精度は構造化パラメトリックモデルを採用する決定的な要素ではありません。私たちが得るものは理解です。予測を行うことができるソフトウェアだけでなく、捉えようとしているパターンについての直接的な洞察も得ることができます。例えば、今日紹介したモデルは、明示的な曜日の重みと需要の明示的な弾力性を伴う需要予測を直接提供します。たとえば、ブラックフライデーに関連付けられたアップリフトを導入するために、毎年同じ時期に発生しない準季節的なイベントを拡張する場合、単に要素を追加するだけで、曜日パターンなどの他のすべてのパターンから切り離されたブラックフライデーアップリフトの推定値を得ることができます。これは非常に興味深いです。
構造化アプローチを通じて得られるものは、生のモデル以上のものです。たとえば、価格を上げると需要が増えるという状況で弾力性がマイナスになる場合、ウォルマートのような状況では、これは非常に疑わしい結果です。おそらく、モデルの実装に問題があるか、深刻な問題が発生していることを反映しています。精度指標が何を言おうとも、製品を高くすることで人々がより多く買うという結果が得られるウォルマートの状況に陥った場合、データパイプライン全体に疑問を抱くべきです。それが理解の本質です。
また、モデルは変更可能です。微分可能プログラミングは非常に表現力があります。私たちが持っているモデルは旅の一つのイテレーションに過ぎません。市場が変化したり、会社自体が変化した場合、私たちが持っているモデルは自然にこの進化を捉えることができるでしょう。自動的な進化というものは存在しません。この進化を捉えるためには、サプライチェーンサイエンティストの努力が必要です。ただし、この努力は比較的最小限であると期待されます。それは、非常に小さく整理されたモデルを持っている場合、後でこのモデルの構造を調整する必要がある場合、比較的小さなタスクになるからです。一方、モデルが巨大なエンジニアリングの怪物である場合と比較すると、その差は大きくなります。
慎重に設計された場合、微分可能プログラミングで生成されるモデルは非常に安定しています。安定性は構造の選択に帰結します。微分可能プログラミングを通じて最適化するプログラムには必ずしも安定性があるわけではありません。パラメータに特定の意味がある非常に明確な構造がある場合にのみ得られるものです。たとえば、モデルを再学習するたびに曜日ごとに完全に異なる重みが得られるモデルがある場合、ビジネスの現実はそれほど速く変化していないということです。モデルを2回実行すると、比較的安定した曜日の値が得られるはずです。そうでない場合、需要のモデリング方法に何か非常に問題があるということです。したがって、モデルの構造を賢く選択することで、非常に安定した数値結果を得ることができます。これにより、サプライチェーンのコンテキストで複雑な機械学習モデルを使用しようとする際によくある問題を回避することができます。実際、サプライチェーンの観点からすると、数値の不安定性は致命的です。なぜなら、あらゆる場所にラチェット効果があるからです。需要の推定値が変動すると、無駄に発注や生産発注をトリガーすることになります。生産発注をトリガーした後で、次の週にそれが間違いだったと判断して取り消すことはできません。したがって、将来の需要の推定値が変動し続けると、過剰な補充と過剰な生産発注になります。この問題は、安定性を確保することで解決することができます。それは設計の問題です。
機械学習を本番環境に導入する際の最大の障壁の一つは信頼性です。数百万ユーロまたはドル単位で操作する場合、数値レシピの内部で何が起こっているかを理解することは重要です。サプライチェーンのミスは非常に高価になる可能性があり、理解されていないアルゴリズムの誤った適用によるサプライチェーンの災害の例はたくさんあります。微分可能プログラミングは非常に強力ですが、エンジニアリングのモデルとして実装されたモデルは非常にシンプルです。これらのモデルは実際にはExcel スプレッドシートで実行できるものであり、通常は直感的な乗算モデルであり、分岐と関数があります。Excelスプレッドシートでは自動微分は実行できませんが、数百万のSKUがある場合はスプレッドシートでそれを試みないでください。ただし、シンプルさの観点では、スプレッドシートに入れることができるものと非常に互換性があります。このシンプルさは、機械学習をファンシーなプロトタイプとして保持するのではなく、本番環境に持ち込むための信頼を確立するのに非常に役立ちます。
最後に、これらの特性をすべて組み合わせると、非常に正確な技術が得られます。この視点は、このシリーズの最初の章で議論されました。私たちは、サプライチェーンへの投資を資本投資に変え、サプライチェーンの専門家や実践者を何度も同じことをする必要がある消耗品として扱うのではなく、投資としての価値を生み出し続けることを目指しています。微分可能プログラミングは、この資本主義的なサプライチェンの視点と非常に相性が良いです。
第2章では、「実験的最適化」という重要な講義を紹介しました。これは、サプライチェーンにおいて実際に改善するとはどういう意味なのかという根本的な問いに対する1つの可能な答えを提供しています。微分可能プログラミングの視点は、サプライチェーンの実践者が直面する多くの困難について非常に具体的な洞察を提供します。企業のソフトウェアベンダーは、サプライチェーンの失敗の原因をしばしばデータの悪さに責任転嫁します。しかし、私はこれが問題を見る間違った方法であると考えています。データはただのデータです。あなたのERPはデータサイエンスのために設計されたものではありませんが、何十年もの間スムーズに運用されており、会社の人々はそれにもかかわらずサプライチェーンを運営しています。あなたのサプライチェーンに関するデータをキャプチャするERPが完璧でなくても大丈夫です。完璧なデータが利用可能になることを期待するのは甘い考えです。私たちはサプライチェーンについて話しているので、世界は非常に複雑ですから、システムは完璧ではありません。現実的には、1つのビジネスシステムではなく、半ダースのシステムがあり、それらは完全に一貫していません。これは生活の一部です。しかし、企業のベンダーがデータの悪さを非難するとき、現実は、ベンダーが特定の予測モデルを使用しているということです。このモデルは、会社についての特定の一連の仮定で設計されています。問題は、あなたの会社がそれらの仮定のいずれかを破る場合、技術が完全に崩壊するということです。この状況では、合理的でない仮定を持つ予測モデルがあり、データを供給し、それが完璧ではないため、技術が崩壊します。会社が非難されるのは完全に理不尽です。問題は、データがサプライチェーンの文脈でどのようなものであるかについて、完全に現実的でない仮定をするベンダーによって押し付けられる技術です。
今日は正確性の指標についてのベンチマークを示していません。しかし、私の提案は、それらの正確性の指標はほとんど重要ではないということです。予測モデルは意思決定を促進するためのツールです。重要なのは、何を買うか、何を生産するか、価格を上げるか下げるかといった意思決定が良いか悪いかです。悪い意思決定は予測モデルに遡ることができますが、それは正確性の問題ではありません。例えば、私たちは販売予測モデルを持っていて、適切に管理されていなかった在庫切れの角度を修正しました。しかし、在庫切れの角度を修正したことで、私たちは正確性の指標そのものを修正したのです。つまり、予測モデルを修正することは正確性を向上させることを意味するのではなく、非常に頻繁には、自分がどのような問題と視点で作業しているかを再考し、それに基づいて正確性の指標またはそれ以上のものを変更することを意味します。クラシックな視点の問題は、正確性の指標が価値のある目標であると仮定していることです。これは完全には当てはまりません。
サプライチェーンは現実世界で運営されており、予期せぬ出来事や奇妙な出来事がたくさんあります。例えば、船舶によるスエズ運河の閉塞が発生することがありますが、これは完全に奇妙な出来事です。このような状況では、この地域を見ていたすべてのリードタイム予測モデルが即座に無効になります。明らかに、これは以前に実際に起こったことではないので、このような状況で何かをバックテストすることはできません。しかし、スエズ運河を遮断する船舶のような完全に例外的な状況があっても、私たちは今日提案しているこのようなホワイトボックスアプローチがあれば、モデルを修正することができます。この修正には推測が必要ですが、それは問題ありません。正確に間違っているよりもおおよその正しさの方が良いです。例えば、スエズ運河が閉塞されている場合、この経路を通るすべての供給品のリードタイムに1ヶ月を追加すると言うことができます。これは非常におおよその値ですが、既に情報を持っているにもかかわらず、遅延が全くないと仮定するよりも良いです。さらに、変化はしばしば内部から起こります。例えば、小売ネットワークを考えてみましょう。古い流通センターと新しい流通センターが数十の店舗に供給しているとします。古い流通センターから新しい流通センターに供給品を移行するという状況が発生しています。このような状況は、この特定の小売業者の歴史の中でほとんど一度しか起こりませんし、バックテストすることはできません。しかし、微分可能プログラミングのようなアプローチを使用すれば、この段階的な移行に適合するモデルを簡単に実装することができます。
結論として、微分可能プログラミングは、将来についての洞察を構造化するアプローチを提供する技術です。微分可能プログラミングは、文字通り私たちが将来を見る方法を形作ることができます。微分可能プログラミングは、この図の知覚側に位置しています。この知覚に基づいて、サプライチェーンのためにより良い意思決定をすることができ、それらの意思決定が図の反対側にある行動を促します。主流のサプライチェーン理論の最大の誤解の1つは、知覚と行動を厳密に分離されたコンポーネントとして扱えるということです。これは、計画を担当するチーム（知覚）と補充を担当する独立したチーム（行動）を持つ形で現れます。
しかし、知覚と行動のフィードバックループは非常に重要です。これは、正しい形の知覚に向かうための非常に重要なメカニズムです。このフィードバックループがないと、自分が正しいものを見ているのか、見ているものが本当に思っているものなのかさえわかりません。このフィードバックメカニズムが必要であり、このフィードバックループを通じて、サプライチェーンの行動に関連する将来の正確な定量評価に向けてモデルを実際に誘導することができます。主流のサプライチェーンアプローチは、非常に堅牢な予測形式に固執しているため、このケースをほとんど無視しています。このモデル中心の予測形式は、Holt-Winters予測モデルのような古いモデルやFacebook Prophetのような最近のモデルである場合でも同じです。状況は同じです。予測モデルに固執している場合、図の行動側から得られるすべてのフィードバックは無意味です。なぜなら、それを完全に無視する以外に何もできないからです。
与えられた予測モデルに固執している場合、行動側からの情報を受けてモデルを再フォーマットまたは再構築することはできません。一方、構造化モデリングアプローチを持つ微分可能プログラミングは、まったく異なるパラダイムを提供します。予測モデルは完全に使い捨てです。もし行動からのフィードバックが予測の視点で根本的な変化を要求する場合、単純にそれらの根本的な変化を実装するだけです。特定のイテレーションに特定のアタッチメントはありません。モデルを非常にシンプルに保つことは、モデルを変更し続けるオプションを保持するために非常に重要です。なぜなら、もしエンジニアリングモンスターのようなものを作り上げた場合、一度本番に入ると、それを変更することは非常に困難になるからです。重要な点の1つは、変更し続けるためには、コードの行数と内部の複雑さが非常に簡素であるモデルを持っている必要があるということです。これが微分可能プログラミングの優れた点です。高い精度を達成することではなく、高い関連性を達成することです。関連性がなければ、すべての精度指標は完全に無意味です。微分可能プログラミングと構造化モデリングは、関連性を達成し、それを維持するための旅を提供します。
今日の講義はこれで終わります。次回は3月2日、同じ時間、パリ時間の午後3時に、サプライチェーンの確率モデリングを紹介します。単に1つの未来を選び、それを正しいものと宣言するのではなく、すべての可能な未来を考慮することの技術的な影響について詳しく見ていきます。実際には、すべての可能な未来を考慮することは、サプライチェーンがリスクに対して効果的に強靭であるために非常に重要です。1つの未来を選ぶだけでは、予測が完全に正確でない場合、非常に脆弱な状態になる可能性があります。そして、予測は決して完全に正確ではないため、すべての可能な未来を考慮する必要があるという考えを受け入れることは非常に重要です。そして、現代の数値レシピを使ってそれをどのように行うかを見ていきます。
質問: 確率的ノイズは局所的な最小値を回避するために追加されますが、どのように活用され、大きな偏差を回避して勾配降下法が目標から遠く離れないようにスケーリングされますか？
それは非常に興味深い質問であり、この回答には2つの要素があります。
まず、これがAdamアルゴリズムが移動の大きさに関して非常に保守的である理由です。勾配は基本的には制約されていません。勾配は数千または数百万の価値を持つことがあります。しかし、Adamでは、最大ステップは実際には学習率によって上限が設定されています。したがって、実際には、Adamは文字通り最大ステップを強制する数値レシピを持っており、これによって大規模な数値的な不安定性を回避できることを期待しています。
さて、ランダムに、学習率があるにもかかわらず、単に純粋な変動のために、間違った方向に反復的に移動する可能性があります。これは可能性があります。そのため、確率的勾配降下法はまだ完全に理解されていません。実際には、実践では非常にうまく機能していますが、なぜそれがうまく機能し、なぜそれが非常に速く収束し、なぜ起こりうる問題がそれほど多くないのかは、特に確率的勾配降下法が高次元で行われる場合には完全に理解されていません。通常、1つのステップごとに触れられるパラメータは文字通り数十、もしくは数百あります。2つまたは3つの次元で持つことができるような直感は非常に誤解を招くものです。高次元を考慮すると、物事は非常に異なる振る舞いをします。
したがって、この質問の結論は非常に関連しています。それは、Adamが勾配ステップのスケールに非常に保守的であるという魔法の一部であり、もう一つは実践では非常にうまく機能しているが、まだ理解されていない部分です。ちなみに、確率的勾配降下法が完全に直感的でないという事実も、この技術が存在していたが効果的とは認識されていなかった理由です。約70年間、人々はそれが存在することを知っていましたが、非常に懐疑的でした。深層学習の大成功によって、コミュニティは実際にはうまく機能していることを認識し、認めるようになりましたが、なぜうまく機能しているのか、なぜそれほど速く収束するのか、なぜ起こりうる問題がそれほど多くないのかは、本当に理解されていません。
質問: ある特定のパターンが弱いと判断し、モデルから削除するべきかをどのように理解するのですか？
これも非常に良い質問です。厳格な基準はありません。それは、サプライチェーンの科学者の判断によるものです。その理由は、導入するパターンが最小の利益しかもたらさないが、モデリングの観点ではコードのわずか2行であり、計算時間への影響が無視できるほどであり、後でそのパターンを削除することが比較的簡単である場合、「まあ、そのままにしておけばいいかもしれません。それほど害はないようですし、あまり良いことはありません。この弱いパターンが実際に強くなる可能性がある状況も見えます。保守性の観点からは問題ありません。
ただし、パターンがあまり捉えられておらず、モデルに多くの計算を追加している場合、別の側面も見ることができます。したがって、無料ではありません。パラメータやロジックを追加するたびに、モデルに必要な計算リソースの量が増え、遅くなり、扱いにくくなります。この弱いパターンが実際に強くなる可能性があるが、悪い方法で強くなる場合、不安定性を生成し、予測モデリングに混乱を引き起こす可能性があるのは、通常、このような状況です。その場合、「いや、おそらく削除すべきだろう」と考えるでしょう。
見ての通り、これは判断の問題です。微分可能なプログラミングは文化です。一人ではありません。Lokadでさまざまなことを試した同僚や仲間がいます。これは私たちが育成しようとしている文化です。オールパワフルなAIの視点と比較すると、少しがっかりするかもしれませんが、供給チェーンは非常に複雑であり、人工知能の技術は粗末なものですので、人間の知性には現実的な代替手段がありません。判断の問題と言っているのは、アルゴリズムのトリックだけでは満足のいく答えを提供することはできないため、応用された人間の知性が必要だということです。
それにもかかわらず、ツールの設計は可能です。これは別のトピックですが、Lokadで提供しているツールの設計を実際にカバーするかどうかを見てみます。もし判断を下さなければならない場合、現在のモデルの状態に関する判断を行うためのすべての計測を提供し、このような迷いに伴う苦痛の量を最小限に抑えることができるようにします。
質問: サプライチェーンの複雑さのしきい値は、機械学習と微分可能なプログラミングがはるかに優れた結果をもたらすようになるのはいつですか？
Lokadでは、通常、年間売上高が1000万ドル以上の企業に対して大きな成果をもたらすことができます。年間売上高が5000万ドル以上の企業であれば、本当に輝き始めると言えるでしょう。
その理由は、基本的には非常に信頼性の高いデータパイプラインを確立する必要があるからです。ERPから関連するデータを毎日抽出できる必要があります。それが良いデータであるか悪いデータであるかは問題ではありませんが、持っているデータには多くの欠陥があるかもしれません。それにもかかわらず、基本的なトランザクションを毎日抽出するためにはかなりの配管が必要です。企業が小さすぎる場合、通常、専任のIT部門さえ持っていないため、信頼性のある毎日の抽出ができず、結果が本当に損なわれます。
さて、垂直方向や複雑さに関しては、ほとんどの企業やサプライチェーンでは、私の意見ではまだ最適化を開始していないと思います。私が言ったように、主流のサプライチェーン理論では、より正確な予測を追い求めるべきだと強調されています。予測誤差の割合を減らすことが目標であり、多くの企業は計画チームや予測チームを持つことでそれに取り組むでしょう。私の意見では、それらはすべてビジネスに価値を追加しているわけではなく、基本的には間違った質問に対して非常に洗練された答えを提供しているだけです。
驚かれるかもしれませんが、微分可能なプログラミングが本当に輝くのは、それが基本的には非常に強力であるからではなく、それが通常、会社にとって本当に関連性のあるものであるからです。例を挙げると、サプライチェーンで実装されているもののほとんどは、安全在庫モデルのようなモデルですが、これは実際のサプライチェーンにはまったく関連性がありません。たとえば、安全在庫モデルでは、負のリードタイムが可能であると仮定しています。つまり、今注文しても昨日には納品されているということです。これは全く意味をなさず、その結果、安全在庫の運用結果は通常、満足のいくものではありません。
微分可能なプログラミングは、他の代替機械学習技術よりも優れているわけではなく、数値的な優位性を追求するわけでもありません。そのポイントは、非常に複雑で混沌とした世界で関連性を実現することです。常に変化し、凶悪なアプリケーションの風景と取り組まなければならないデータを表す世界で、関連性を実現することが本当の目的です。
この場合、もう質問はないようですね。それでは、次回はサプライチェーンの確率モデリングの講義でお会いしましょう。
