Estyは手芸や古物，独自の工場生産などの商品を扱うe-commerceを行っている会社で，1億点以上の商品を扱っている．

この記事では，レコメンドアーキテクチャの変遷と，リアルタイムのレコメンデーションを提供するためにどのような設計したかを紹介してくれている．

Batch architecture (aka the simple way)

下図がバッチ推論を行うアーキテクチャになっている．パイプラインは毎晩実行されるようになっていて，過去のデータと学習済みの機械学習モデルからレコメンドリストが生成されて，それをKey-Value Storeに保存される流れ．（ここでは，リスティングIDをキーとして別のリスティングIDのセットを返す）

Batch architecture.

これはバッチ推論の定番の方式で確立されている方法かなと思う．Key-Value Storeの先にML-APIを置いてクライアント側と上手く分離するのが良いと思う．Key-Value Storeはリクエスト時のレイテンシーを一定にかつ低く保てるのが良いよね．

ただ，バッチ推論の場合は，1日に1回しかリストを更新できないのでダイナミックでパーソナライズされたユーザー体験を実現する機会は難しいよねと書かれているのはまさに！これはバッチ推論の性質なので，仕方がないかなと思いつつ更新頻度を上げるぐらいしか方法はなさそうかな．ただ，アイテムの埋め込みとかを使用していると新しいアイテムが来た場合に対応できなくなるので，モデルの再学習が必要になったりとこれも難しいかなと思う．

Online architecture (aka the great but hard way)

パーソナライズされたレコメンドをリアルタイムに提供するために，セッションデータを取り入れたという．これにより例えば，新しいお気に入りのカップを探し始めている人にマグカップを勧めるなどができる（下図はその例）

Recommending mugs to users as they begin the hunt for a new favorite cup.

オンライン推論のためのシステムを考えたと．ユースケースに応じて，これらのサービスはリクエスト時に呼び出されるか，非同期で呼び出されるかハンドリングされている．

Online architecture.

デメリットというかリアルタイム性とのトレードオフとして，コーディングやサービスアーキテクチャの複雑性が挙げられている．ここで2つの重要な課題に直面したとのこと．

• レイテンシーとエラーレートを低く抑えること
• APIをシンプルに保つ
  • サービス数の増加と複雑な入力の組み合わせによって複雑性が増した

Batch vs online architecture, in a nutshell.

A platform approach (aka the scalable way)

ニ段階の推薦システム構成，第一段階で候補生成して第二段階でランキング作成でレコメンドリストの順位を決めるという方法．この方法はYouTubeとかこの前のKaggleのH&Mコンペでも使われた定番の方法の1つかな．

Generating recommendations in two passes.

• リアルタイムのユーザーアクティビティを取得するためのシステム