Back to blog

1年少し前、私たちは予測技術 3.0 として quantile grids を発表しました。Lokad はこれまで以上に、技術が実現し得る最高水準の予測を提供することに注力しています。そして本日、第4世代の予測技術、すなわち 確率的予測エンジン が本番環境で全クライアント向けに利用可能になりました。この新エンジンは予測技術スタックを全面的に書き直したものであり、私たちが長年直面してきた多くの課題に対応しています。

真の確率

いかに優れた予測技術であっても、未来は不確実です。2012年に Lokad が初めて quantile forecasting の領域に挑戦した際、不確実性は従来の予測手法のように無視すべきものではなく、むしろ受け入れるべきだとすぐに気づきました。簡単に言えば、サプライチェーンのコストは統計的な極端値に集中しています。非常に高い需要は欠品を引き起こし、非常に低い需要は死蔵在庫を生み出します。その中間では、サプライチェーンは概ね滑らかに運営される傾向があります。

quantile gridsを用いることで、Lokadは将来の結果の可能性について、より細かい視点を提供していました。しかし、その名が示す通り、私たちの_quantile grids_は実際には複数層のquantileから構築された_quantile forecasts_の上に成り立っていました。これらのquantile gridsは昨年非常に有用であることが証明されましたが、forecasting engineが確率を算出していたにもかかわらず、内部的にはほぼすべてのロジックが確率を直接扱っていなかったのです。計算された確率は、quantile forecastingシステムの副産物に過ぎませんでした。

これらのquantileに由来するため、forecasting engine 3.0には複数の微妙な制限が存在していました。そして、これらの制限のほとんどはクライアントにはあまり気付かれなかったものの、Lokadの研究開発チームには見過ごされることがありませんでした。そこで、私たちは真のネイティブな確率的予測の視点で予測技術全体を再構築することを決定しました。これがforecasting engine 4.0の始まりとなったのです。

リードタイム予測

リードタイムはしばしば既定のものとみなされます。しかし、過去のリードタイムが既知である一方、未来のリードタイムはあくまで推定されるに過ぎません。長年にわたり、Lokadは未来のリードタイムを正確に近似するという課題を過小評価していました。リードタイムは微妙なものであり、需要に影響を与える季節性(特に旧正月など)のような多くの統計的パターンがリードタイムにも影響を及ぼします。

forecasting engine 4.0では、リードタイムが専用のリードタイム予測モードを持つ一級市民となりました。リードタイムは専用の組み込み予測モデルの恩恵を受けるようになりました。当然、エンジンが_確率的_予測エンジンであるため、リードタイム予測は不確実な期間に関連する確率分布となります。

統合需要予測

リードタイムは変動するものですが、forecasting engine 3.0は固定のリードタイムに依存していました。従来の観点では、古典的な安全在庫分析はリードタイムが正規分布に従うと仮定しますが、これまでのほぼすべての測定は、変動するリードタイムが明らかに正規分布していないことを示しています。実験では、固定リードタイムを採用する方が不完全なモデルを採用するよりも優れていることが示されましたが、固定のリードタイムに依存し続けることは、私たちが求めていた完全に満足のいく解決策ではありませんでした。

forecasting engine 4.0は、リードタイム全体にわたって統合されるという意味で_integated_需要予測の概念を導入します。このエンジンはリードタイムの確率分布全体を取り込み、それに対応する確率的需要予測を生成します。実際、リードタイム分布も前述のようにforecasting engineによって計算されます。統合需要予測は、変動するリードタイムに対処するという課題に、遂に満足のいく解答をもたらしました。

新製品予測

新製品の需要予測は非常に困難です。なぜなら、この場合、予測は明らかに販売履歴に依存できないため、予測エンジンは発売前に既知の他のデータに頼らなければならないからです。forecasting engine 3.0はすでにこの特定のユースケース向けの_tags_フレームワークを備えていました。しかし、タグは残念ながら期待していたほどの情報を持っておらず、ある程度の精度が失われてしまいました。

4.0では、カテゴリと階層構造の導入により、この特定の課題が見直されました。カテゴリと階層構造はタグよりも表現力豊かで構造化されているため、はるかに多くの情報を伝達します。forecasting engine 4.0はこのリッチなデータフレームワークを最大限に活用し、より正確な予測を提供します。新製品予測は最も顕著なユースケースとなっています。

在庫切れとプロモーション

forecasting engineの目的は未来の_需要_を予測することです。しかし、過去の需要に関する知識は通常不完全であり、実際に知られているのは過去の_販売_のみです。販売は需要のおおよその見当としては合理的ですが、販売には_在庫切れ_や_プロモーション_など、複数のバイアスが伴います。engine 3.0はすでにこれらのバイアスに対処するためのいくつかのヒューリスティックを備えており、加えてquantile予測は(従来の)平均予測よりも本質的に堅牢です。それでもなお、状況は私たちにとって完全に満足のいくものではありませんでした。

engine 4.0は、_偏った_需要という概念を導入します。これは_検閲された_か_過大評価された_のいずれかである可能性があります。特定の日に特定の製品の需要が_検閲された_とマークされる場合、予測エンジンにはその日の需要が_本来もっと高かったはず_であり、真の需要が不明であることを伝えているのです。エンジンは、この情報を利用して、需要シグナルを歪める多数の履歴が存在する場合でも予測を精緻化します。

超希少需要

quantile予測は希少な事象の確率推定において従来の平均または中央値の予測よりもはるかに優れている一方、極めて希少な事象の推定になるとquantileの限界が現れ始めます。例えば、私たちのquantileモデルは、年に1回または2回しか販売されない商品の取り扱いや、98%を超えるサービスレベルの管理に苦労していました。

engine 4.0で実装されたネイティブな確率モデルは、超希少需要や一般的な“希少”事象への対応において、はるかに適切に機能します。これらのモデルは_quantile forecasting_フレームワーク内で実装することも_可能_でした(確率予測は容易にquantile予測に変換できるため)が、engine 3.0にはそれを支えるインフラがありませんでした。そこで、これらはengine 4.0に実装されることとなりました。

Envisionへの統合

forecasting engineのバージョン2.0と3.0はウェブユーザーインターフェイスを備えていました。一見すると、それは_簡単であるように見えました_。しかし、ユーザーインターフェイスは実際には、(いかなる)予測エンジンを使用する際の真の課題、すなわち予測エンジンに転送されるデータを完全に制御するという要素を無視していました。実際、ゴミが入力されればゴミが出るという問題は非常に頻繁に発生します。

engine 4.0は、商取引の定量的最適化に特化したドメイン固有言語であるEnvision内からインターフェースされています。Envisionスクリプトから提供される一連のデータ引数を用いて予測エンジンを呼び出します。このアプローチは初期の手間がかかるものの、入力データに対して調整が行われると生産性向上の効果がすぐに現れます。

forecasting engine 4.0のリリースは、ここ数週間でLokadにもたらされた一連の重要な改善の第一段階に過ぎません。今後の展開にご期待ください.