あなたのお気に入りのBen and Jerryアイスクリームフレーバーが今すぐあなたの近くのスーパーで入手可能かどうかを知る方法があったことを望みましたか？ Instacartの機械学習チームは、それを見つけ出すためのツールを構築しました。

当社の市場規模により、洗練された予測モデルを構築することができます。当社は7万人以上のショッパーがいて、彼らは1日に1万5千店の店舗で何百もの商品をスキャンし、それらを顧客に届けています。 これらの店舗は、Aldi、Costco、Krogers、Safeway、Wegmansなどの当社の食料品小売パートナーに属しています。

Instacartのショッパーが商品をカートに入れたり、商品が「見つかりません」とマークされるたびに、商品の在庫の有無を細かく予測するのに役立つ情報が得られます。 これにより、在庫切れの商品を正確に予測し、在庫切れの可能性が高い商品を適切に交換することをお勧めします。

Instacartがどのようにビジネスをするかを簡単に説明します。顧客はオンラインで注文を出して、当社の個人ショッパーが商品を選び、1時間以内で配達します。 私たちのウェブサイトには何百万もの食料品が載っています。 特定の店舗の各商品は「商品」として定義されており、各商品の在庫状況を知りたいと考えています。

問題：「見つからない」ことを理解する

もしショッパーがその店で品物を見つけることができない場合、その品物に「見つかりません」というラベルを付けます。 顧客が欲しいものを手に入れることができず、小売パートナーが収益を見逃し、ショッパーがそれらを探すのにより多くの時間を費やし、そしてInstacartが最高のユーザー体験を提供することもできなくなる。

見付からない理由は、主に2つの理由で発生します:

1.入手可能性：Instacartは、サイトにリストされている商品のロジスティクスサプライチェーン（物流チェーン）を所有していないため（当社の小売パートナーは所有している）、第三者としての私たちにとって店舗がある時点で商品を持っているかどうかを知ることは難しいです。 すべての商品が入手可能かどうかについては、小売パートナーから定期的に（通常は1日に1回）更新されます。 しかし、商品は1日以内にすぐに売り切れることがあります。 私たちは一日を通してもっと細かいデータが必要であることに気づきました – 各商品の在庫をリアルタイムで知る必要がありました。

2.検索能力：私達の網羅的なカタログのために、ショッパーは店で実はある商品が見つからない場合もあります。 季節プロモーションのためにアイテムが移動されたか、アイテムがペアになって売り上げが増加するための可能性もあります。 たとえば、チップは通常の棚ではなくSalsa（サルサ）の隣に配置されます。 見つけやすい商品をオススメすることでショッパーの時間を節約し、顧客のキャンセルも削減する。

したがって、リアルタイムの在庫状況を推測し、見つけやすさを獲得するために、30分ごとに2億の食料品の在庫状況を常に更新するモデルを構築しました。

モデルを構築する

このモデルの構築に着手したとき、すべての注文されたアイテム（トレーニングサンプル）は判別問題としてそれを定式化しました。 商品の入手可能性と検索能力を把握するために、モデルは商品がショッパーによって見つけられたかどうかを予測するように訓練されています。 このモデルを機能させることは、優れたパフォーマンスでモデルをトレーニングするという観点からも、実行する必要がある規模からも、難しい問題です。 まずモデリングについて見てみましょう。

機能

見つけられた/見つけられなかった（各トレーニングサンプル）のために、我々は機能を作成するためのオーダーは数ヶ月前からのデータを使います。 このモデルはXGBoostを使用しているため、すべての機能エンジニアリングはツリーベースのモデルでうまく機能することを目指しています。 モデルをトレーニングするために、3つの大きカテゴリーの機能を使用します。アイテムレベルの機能、時間ベースの機能、およびカテゴリー機能です。

アイテムレベルの機能

アイテムの過去の注文データとそれに関連する見つかった/見つからなかったデータを使って、アイテムレベルの機能を構築します。 アイテムが見つかるかどうかを予測しようとしているので、これらが最も重要な機能のセットになるはずです。 過去60分以内に見つからなかったアイテムは、店頭で入手できなくなる可能性が非常に高いです。 あるいは、非常に低い発見率の記録を有するアイテムは、見つけるのが困難であり、したがって、発見されない可能性が非常に高いです。

見つからなかった時点から最大60分後に、アイテムの発見率は非常に低くなります。

このセットの最も重要な機能は、アイテムの過去の発見率、最後に発見されてからの経過時間、次に発見されないまでの予想時間（そのアイテムの2つの未発見の間の過去の時間に基づく）です。 また、小売業者から毎日提供される商品の在庫状況データを使用して、より多くの機能を作成しています。

時間ベースの機能

注文が店舗で選択された時刻や曜日など、時間ベースの機能を基づいています。 そして普通は朝の時、商品の入手可能性が高いその事実をよく見ます。 （プロのアドバイス：朝は買い物をするのが一番いいタイミングです！　そのとき棚に再入荷され置かれています）

発見されたものはすべて在庫があり、スコアが高くなりますが、それに対して見つからなかった場合は低くなります。 モデルがどのようにして見つからなかった行為を忘れようとし、時間とともに徐々にスコアを増加させるかに注目してください。 また、モデルはデリが閉じている早朝と晩の夜に低いスコアを割り当てます。これらはすべて、これらの時間の間に過去の注文からより高い値が見つかりませんでした。

高カーディナリティのカテゴリ別機能問題

また、モデルでそのまま使えるいくつかの分類別機能（店舗、製品、小売業者、部門、棚、ブランド、地域などの識別子）もあります。 しかし、これらのいくつかは非常に高いカーディナリティ（ユニークなカテゴリーの数）を持っています。 カーディナリティは、商品IDでは数百万、ストアIDでは数万になります。 これらをワンホットエンコード（one-hot-encoded）機能として使用すると学習効率が悪くなり、スケーリングの観点からも非効率的になります（OHE機能はデータサイズとモデルのトレーニング/スコアリング時間を増大させる可能性があります ！

また、数百万のカーディナリティを考えると、埋め込んだトレーニングはおそらく良い考えではありません。 モデルが適切な埋め込みを学習するためには、各カテゴリがトレーニングデータに十分なサンプルを持つ必要があります。これは、トレーニングデータのサイズを再び膨らませることになります。 私たちはこの問題を簡単なことで解決しまて、その同時に別の重要な問題も解決しました。それについて、以下に説明します。

ロングテールの商品

多くの商品は何度も購入されていますが、ロングテールの中には過去6か月に1回販売されているものが常にあります。 まばらな注文履歴は脆弱さ（機能レベル）を導き、商品が存在しない商品まで導いてしまいます。 また、トレーニングデータにそのような項目が含まれていることは、最も重要な機能セットが機能しないため、間違いなく問題になります。

高い基数とロングテールアイテムの問題に加えて、上記の機能はまだサプライチェーンの効率、店舗固有の補充パターン、商品の季節性、製造中止の商品などの多くの要因を捉えていません。 これらの要因を正確に捉えるのは不可能ですが、これらの要因やおそらく他の要因の直接の結果である、商品の発見率に関する明示的なデータはあります。 したがって、この目的のために、商品メタデータ（商品、ブランド、地域、およびそれらの組み合わせなど）の粒度（granularity）で発見率を使用します。

すべてのカテゴリー機能やそれに付随する組み合わせに対してエンコードを意味する似たような動きをします。 平均エンコーディングでは、カテゴリー値はそのカテゴリーの従属変数の平均値で代入されます。 我々の場合の従属変数の平均は発見率であり、トレーニングデータ内からの発見率を使用する代わりに、過去の発見率を使用します。 たとえば、店舗ID機能では、IDがその店舗の過去の発見率に置き換えられ、連続的な機能に変換されます。

3つのグループの機能の重要性

これらの機能はアイテムの注文履歴ではなくメタデータの注文履歴に依存しないため、これらの機能はテールアイテムに適しています。 これらの機能は、テールアイテムのモデルを大幅に改善し、最も重要な機能の1つであることが証明されました。

具体的には、モデルの最も重要な機能は、商品が販売されている地域全体で集計された商品の親商品の発見率です。 この機能は主に、商品の見つけやすさとその地域におけるサプライチェーンの良さを表しています。 非効率なサプライチェーンを持つ商品は、地域全体で低い発見率を持つことになります。 この機能は、生産が中止されているかシーズン外になっている商品も表しています。 たとえ個々の商品が以前に購入されたことがなくても、それは異なる店にまたがって商品の低い発見率を収集し、この情報をその商品の全てに登録し、それらに低いスコアを与えるでしょう！

アイテムレベルの機能ではうまく機能しないため、エンコードされたカテゴリカル機能によるAUCの向上はテールアイテムには劇的になります。

スコアの規模

商品の在庫状況は、販売され在庫が補充されるとほぼリアルタイムで変化します。そのため、可能な限り在庫状況を予測したいと考えています。 大規模でのトレーニングがボトルネックになることがありますが、この問題では大規模でのスコアリングが大きなボトルネックになります。

そのため、30分ごとに2億アイテムを超えるスコアを得られるように、スコアリングパイプラインを最適化するための努力を重ねました。 このパイプラインでは、アイテムごとに約130のフィーチャーが作成され、30分ごとに10 TBのデータが処理されます。 ゼロから構築した新しいスコアアーキテクチャでは、1/4の時間で1/5のリソースを使用して、15倍の項目数が増加します。 以下は、この大規模なスケーリングを達成するのに役立ったいくつかのことです。

1.pythonの代わりに私たちのスノーフレークデータウェアハウスで複雑な機能エンジニアリングを実行する。

2.頻繁には変更されない機能を特定してキャッシュする – これにより、機能のエンジニアリング時間を短縮できます。

3.データウェアハウスからAWSインスタンスへのデータ転送を最適化しました。

4.python採点コードのより良い並列化（parallelization）。

5.Postgresへのより早く効率的なスコアをアップロード。

モデルを進化させる

現在、商品の在庫見積りをさまざまなところで使用しています。 そのようなユースケースの1つは、顧客が注文できる商品を決定することです。 利用可能性スコアが非常に低く、関連性が低いアイテムを非表示にします。 また、これらの予測を基づいて、ショッパーを注文された商品の在庫状況が余裕ありの店舗にルーティングします。

私たちはまた商品の在庫状況に影響を与える要因を理解し始めたところです。 将来を見据えて、私たちは常にモデルを劇的に改善するかもしれないより良いデータソースを識別（見分け）しています。 現在、私たちは改善された顧客とショッパーの経験のために各アイテムのための見つけやすさと利用可能性スコアを割り当てるという考えで力を入れる。 そしてやるべきことはまだたくさんあります。

原文タイトル：Predicting the real-time availability of 200 million grocery items

作者：Abhay Pawar

リンク先：https://tech.instacart.com/predicting-real-time-availability-of-200-million-grocery-items-in-us-canada-stores-61f43a16eafe

Interested in working on such large-scale and high impact projects at Instacart? Check out our careers page at careers.instacart.com.