バックテストの限定的な適用性
バックテストは、過去のデータを遡って過去の条件下でアルゴリズムのパフォーマンスを評価するために、学習アルゴリズムまたは最適化アルゴリズムをこの過去のデータセットに適用する実験の設計です。この手法はシンプルでエレガントであり、供給チェーンの実践者に非常に魅力的です。しかし、バックテストは銀の弾丸とは程遠く、その制約が誤解されると、バックテストに焦点を当てることはむしろ害をもたらします。
私たちが「量的サプライチェーン」イニシアチブを実施している経験から、イニシアチブの成功に対する主な脅威は次のとおりです：
- 関連するトランザクションデータへのアクセスがない
- ゴミのような過去のトランザクションデータ
- トランザクションデータの誤った前処理
- データの健康状態のモニタリングの欠如
- 断続的な障害が発生する脆弱なデータパイプライン
- 経済ドライバーの理解の欠如
- 経済ドライバーの誤った戦略モデリング
- 現実の制約とそのモデリングの不一致
- 最適化された意思決定を消費するための適切なプロセスやツールの不足
伝統的な予測手法では、_不正確な予測_はこのリストの一部でしたが、確率的予測を使用すると、それはずっと心配する必要がありません。確率的予測がより正確であるわけではありませんが、予測の精度自体が低下しても、意思決定の品質はより優れた状態を保ちます。
実際には、「不正確な」確率的予測は、確率の分布が非常に広範囲に広がることを主な特徴としています。このような振る舞いは望ましくありませんが、一方で、不正確な伝統的な（確率的でない）予測の結果と比べると、会社が正しい予測を行わない単一の将来に全てを賭けることの方がはるかに悪い結果となります。不正確な確率的予測は非常に保守的で慎重な意思決定に変わります。お金はまだ無駄になりますが、多くのサプライチェンシチュエーションでは非常に非対称なコストが発生するため、慎重さは最悪の戦略ではありません。
正しいバックテストを実施することは現実の状況では容易ではありません。単純なバックテストの実装は過学習によって簡単に誤解されます。いくつかの隠れた共変数がビジネスの成長の大部分を説明できるため、バックテストプロセスの試行錯誤を続けると、市場の過去の変動を「記憶」したモデルが生成されますが、市場を予測することはできません。
Lokadでは、特定の統計モデルをバックテストするための唯一の信頼性のある方法は、非常に多様な状況に直面している数十の企業のデータセットを活用することです。このアプローチは過学習を完全に排除するわけではありませんが、それを大幅に緩和します。
量的サプライチェンイニシアチブでは、予測ツールが適切であり、サプライチェンの実践者がモデルを手動でパラメータ化する必要がない場合、バックテストに早期に焦点を当てることは、イニシアチブの実装を担当するチームをリスク要因から逸らし、期待されるバックテストプロセスの利益を支配するものです。
一部の予測ツールは不適切に設計されており、エンドユーザーに統計パラメータを考え出すよう要求します。例えば、単純な予測モデルである指数平滑法では、「平滑化係数」が必要です。エンドユーザーはこれらのパラメータを空想することはできないため、最初にモデルを動作させるためにバックテストプロセスに頼る必要があります。ただし、バックテストの望ましさは、一部の予測ツールの偶発的な設計ミスによって課せられる要件とは混同してはなりません。
一般的な指針として、バックテストを考慮するのは以下の場合です：
- データパイプラインの実行が退屈で予測できない状態になった場合。
- 経済ドライバーが理解され、文書化されている場合。
- 制約条件（例：MOQs）が徹底的に見直され、検証された場合。
- サプライチェーンプロセスが自動化された意思決定を最大限に活用するように整理された場合。
これらの条件が満たされている場合、バックテストは量的サプライチェーンイニシアチブのパフォーマンスをさらに向上させるための追加の視点として展開できます。
