Mathieu Ripert氏，Instacartのマシンラーニング最適化を語る

Instacartは食料品を１時間以内に届けるオンライン・デリバリサービスである。アイテムをWebサイトあるいはモバイルアプリで注文すると，Instacartの購入代行者グループが地元の店舗でそれを購入して，購入者に届ける仕組みだ。

InfoQは同社のデータサイエンティストであるMathieu Ripert氏にインタビューして，よりよいカスタマエクスペリエンスを保証する上で，Instacartがマシンラーニングをどのうように活用しているのか聞いた。

InfoQ: イベントデータ処理に使用しているアーキテクチャと，データ容量／スループットについて教えてください。

Ripert: まず最初に，当社は分散アーキテクチャを使用しています。当社のシステムはビジネスドメイン(カタログ，物流，購入代行者，パートナ，購入者など)毎に分けられています。こうすることで各ドメインの開発とデプロイが独立して可能になると同時に，それぞれのコードやモデルの主要なオーナが明確になるのです。ドメインはそれぞれデータストアを持っていて，ドメイン間の通信にはRabbitMQを使用しています。

運用データベースとしてはPostgreSQLを，オフライン解析にはAamzon Redshiftを採用しています。データは容量に応じて，日あるいは週でパーティショニングされています。例えば，注文処理エンジンで使用するために購入代行者すべてのGPSロケーションをリアルタイムで追跡しているのですが，このデータは1日で1GBに達するため，日毎にパーティショニングしています。

InfoQ: Instacartは1時間以内に食料品を配達しますが，モデルのセンシティビティ変更をどのようにテストして，展開後に確実な予測を立てられるようにしているのでしょう？

Ripert: まず最初に，過去のデータを広範に利用してモデルのバックテストを行ないます。こうすることで，トレーニングで使用したデータに対してだけでなく，データが取得されたのと同じ時間帯について，将来的にも良好に動作するモデルが得られていることを確認できます。新たなトレンドの変化に対応するために，モデルは毎日，再トレーニングされています。

次に，複数の統計情報(例えば，回帰モデルのRMSEとMAE)を使用して，運用環境でのモデルのパフォーマンスを追跡します。当社では，このような統計情報を実運用データから簡単に抽出可能な社内用クエリツールを用意して，基準を大きく逸脱した場合には警告するようにしています。最後に，当社にはマーケットを監視する運用チームがあります。悪天候など特別なイベントに起因するパフォーマンスの唐突な変化が確認された場合には，社内インターフェースを使用して予測をリアルタイムに調整します。このような調整作業についても，将来的には自動化できるように取り組んでいます。

InfoQ: ツリーアンサンブル(tree ensemble)生成のための教師付き学習に，勾配ブースティング(Gradient Boosting)用ライブラリのXGBoostを使用していますが，配達時間を全体的に最適化する上で，このソフトウェアライブラリはどのように利用されているのでしょう？

Ripert: ある市場では，数時間のうちに何千という提供者が集まり，数千人の個人購入代行者が交代で注文を処理しています。当社の注文処理システムは注文に対して，店内の購入代行者が購入し，配送ドライバがピックアップし，顧客の住所に届ける，というバッチを適応させる方法をリアルタイムで決定しなくてはなりません。このシステムにおける当社の目標は，(a)受注した食料品を確実に届けること，(b)チェックアウト時に顧客が選択した１時間の枠内で確実に配達すること，(c)購入代行を可能な限り効率的に行なって，より多くの注文を顧客から受けられること，この３つです。

GBMによる予測は，購入代行者の店舗での注文品購入や，顧客宅への配送に必要とする時間の見積に使用されています。注文を処理する際の私たちの決定によって，結果的に時間内の配達を実現するためには，ある面でこのような予測が極めて重要です。しかしながら，おそらくもっと重要なのは，このような予測をすることによって私たちのアルゴリズムが，システムとして可能な限り速く動作できるような購入代行者と配送者との組み合わせを見つけ出せるようになる – 最終的なスピード向上を実現する，ということです。

InfoQ: XGBoostはApache SparkやApache Flinkなどの分散処理フレームワークで使用できますが，どのようなセットアップをして，モデルが適時計算されることをどのように保証しているのですか？

Ripert: 注文処理システムについては，XGBBoostがネイティブにサポートしているマルチコアプロセッシングを使うことで，モデルを単一インスタンスとして構築することができました。ある意味これは，リージョン毎に独立したモデルを構築できたからでもあります。最も重要な機能はローカル時間と空間効率なのですから，遠く離れたリージョン同士を組み合わせていたのでは汎化性能を大幅に改善することはできません。

AWSがプッシュするインスタンスメモリとCPU能力(最大2TBおよび128CPUまで)を考えれば，ほとんどの問題に対して分散処理フレームワークの利用を避けることができます。メモリに収められなくなるデータ量については，推奨事項として記載してあります。また推奨事項では，協調的フィルタリングモデルとしてApache SparkとMLLibを使うように推奨しています。

InfoQ: 配達時間の最適化ではどのようなデータソースを考慮していますか，また，過去データはどの程度まで遡って分析しているのでしょうか？

Ripert: 配達時間に関しては，出発地と目的地の緯度と経度，配達開始を計画した時刻，顧客の住所に関する情報(自宅か勤務先か)，配達手段(自動車，バイク，徒歩)を使用しています。

最適化エンジンについては，配送担当と購入代理人のさまざまな組み合わせを考えるために，広い地域では1分間に100,000の予測を行なう必要があります。そのことが，これらの予測に含まれる情報の量に対する制約になります – 多くの情報がまだ分かっていませんし，特徴生成(feature generation)と予測はスケーラブルである必要があるからです。

配達の割り当てが完了すれば，担当した購入代理人や場所，最近の移動状況，天候などの付加的情報を使って，移行の予測を更新することが可能になります。このような拡張のアイデアの探求とテストを続けているのです。

InfoQ: エクスペリエンス全般を改善する上で，NLP(自然言語処理)技術はどのように利用されているのでしょうか？

Ripert: NLPはInstacartにとって，ビジネスの発見という側から最も重要です。過去の購買行動を分析することで，ユーザに対して，一般的に購入されたアイテムを強く推奨することが可能になります。一方で当社のカタログには，数百の小売パートナの扱う数百万の製品が掲載されていて，注文頻度によっては長期的な提供を行なうようになっています。当社はNLPを，購入頻度の低い商品に関するレコメンデーションを生成するために使用しています。例えば，あるユーザがグルテンフリーの製品とイタリア食材に興味を持っていることが分かれば，それらに近い条件を持った製品にまでレコメンデーションの範囲を拡張することができます。

InfoQ:現在の問題を解決する手段として，ディープラーニングを導入する考えはありますか？

Ripert: もちろんです。Search and Discovertyチームがすでに，自然言語処理上の問題の解決に埋め込みモデル(embedding model)を使用しています。私たちカタログチームでも，イメージ処理に畳み込みニューラルネットワークを使用する試みを積極的に行なっています。そして最後に，購入代行者がその地域内の最もよい店舗でアイテムを購入するシーケンスの予測するための，ディープラーニングモデルのプロトタイプを現在作成中です。新年の始めには，そのモデルを使った購入リストの再オーダをテストする計画もあります。

基本的にディープラーニングは，それまでの標準的なマシンラーニングツールでは扱うことの難しかった新たな問題を提起するものであり，膨大な量の機能エンジニアリング作業を必要とします。当社が収集しているデータの量を考えれば，ユーザと購入代行者の両方のエクスペリエンスを改善するという目的で，ディープラーニングを使用する機会はたくさんあると思います。

InfoQ: ビッグデータとマシンラーニングを実際のサービスとして運用した過程で直面した課題や，そこから学んだ教訓には何がありましたか？

Ripert: さまざまな課題に直面しました。

• データの整合性 – マシンラーニングで最も重要なのはデータです。ですから収集するデータは，ノイズのないクリーンなものでなければなりません。例えば，購入代行者は買物の終了時に，作業が終了したことを示す購入アプリのボタンを押す必要があります。私たちはそのタイムスタンプを使用して，配達時間予測モデルをトレーニングするのです。しかしながら，いろいろな理由から，代行者が終了時に“配達”を正しくクリックしない場合があります。そのような情報をフィルタするため，正しい時刻をGPSデータから推測するシステムを構築しました。

• 異常検出 – 大きな嵐が発生した場合には，将来時間を含む機能について，直近の予測をバイアスできるようになっています。

• 分散モデリング – 当社の注文処理エンジンでは，注文を時間通り確実に配送しつつ，全体の移動時間を最小化可能にするために，複数の注文の組み合わせを決定する必要があります。予想が正しくない場合について確実に考慮しておくために，分位解析を使用して配達時間を上限値を予測しておいた上で，この上限値に基づいて計画するようにしています。

• レイテンシ – 1分当たり数十万という予測を呼び出しているので，“スピードと精度”のトレードオフが現実的な問題になります。

• 性能評価 – 別の課題として，当社のビジネス目標に対して最も望ましいモデル評価指標をいかにして選択するか，という問題があります。例えばMEAは，当社の予測モデルに対する最善策ではないかも知れません。事実として，注文が遅れている場合とそうでない場合とでは，1分の誤差の意味は同じではないのです。