レコメンドシステム—— 流れとアーキテクチャの紹介
シーリズの目次
レコメンドシステムのシーリズをここにまとめています。
無料相談コース(未経験OK)
- 機械学習やレコメンド分野に悩んでいる人
- 機械学習やレコメンド分野に携わりたい人
ぜひ下記の無料コースへお申し込みください！
機械学習エンジニア、レコメンドエンジニアになるためのサポート
はじめに
レコメンドシステムは私たちの生活のあらゆる面に影響を与えます：
- ネットショッピング、プラットフォームは私たちに商品を推薦します
- ニュースを見ているとメディアがニュースを勧めてきます
- リラックスするとき,Youtubeからおすすめの動画が並んでいます
ではレコメンデーションの仕組みとは何でしょう?何千万という候補コンテンツの中から、ユーザーの行動履歴データをもとに、どのようにして興味のあるものを見つけ出すのでしょうか。
レコメンドシステムの主な流れを紹介します。
機能のアーキテクチャ
レコメンドシステムには、一般的に3つの主要なステージがあります：
最初は「リコール」ステージで、ユーザーの一部の特徴に基づいて、大量のアイテムからユーザーが潜在的に興味を持つ可能性のある一部のアイテムを迅速に取得します。
次に「ランキング」ステージでは、多くの特徴を組み込んで、複雑なモデルを使用して個別の推薦を精緻に行います。
最後に「再ランキング」ステージでは、読んだアイテムの除外、重複の削除、ランダム化、多様性の確保、特定の種類のアイテムの挿入など、さまざまな技術とビジネス戦略が使用されることがあり、主に技術や製品戦略に基づくか、ユーザーエクスペリエンスの向上を目指します。
これらのステージの中で、「リコール」ステージは速さを重視し、「ランキング」ステージは精度を重視します。
レコール
リコール（Recall）は推薦の最初のステップであり、対象となる候補アイテムは通常数百万に達することがあります。したがって、召回モジュールの主要な目標は「速さ」であり、一部の精度を犠牲にしても、ユーザーの関心に合致するアイテムを見つけることができれば十分です。最も適したアイテムを見つける必要はありません、なぜならそれは後続のソートモジュールの役割だからです。
召回モジュールは、通常、「オフライン計算+オンラインキャッシュ」モデルを使用して、数百万の候補アイテムを迅速に選別するために依存します。数百万の候補アイテムはオフラインで事前に処理され、処理結果はデータベースに保存され、インデックスが作成されます。
精度の不足を補うために、レコールモジュールは通常、マルチ路リコールの方法を採用し、量で精度を補います。各路レコールは、ユーザー情報またはアイテム情報の一側面に焦点を当てます。例えば、一部のレコールは現在の最も人気のあるコンテンツをレコールするのに特化し、他のレコールはユーザーの好みの「タグ」に基づいてレコールを行い、また他のレコールはユーザーがクリックしたコンテンツと類似した他のコンテンツをレコールするのに特化します。単独のレコールは一つの側面に焦点を当てていますが、複数のレコール結果を統合することで、長所を活かし短所を補い、ユーザーの興味の幅広い側面をカバーすることができます。
レコールでモデルを使用してリコールする方法はどのようになっていますか？下の図は、モデルを使用した抽象的なリコールの一般的なアーキテクチャを示しています。
主な考え方は、ユーザー特徴とアイテム特徴を分離し、それぞれの特定のモデルを使用してユーザー埋め込み（Embedding）とアイテム埋め込みを生成することです。オンラインでは、ユーザーの興味に基づいて埋め込みを使用し、Faissなどの効率的な埋め込み検索ツールを活用して、ユーザーの興味に合致するアイテムを迅速に見つけ出すことができます。
理論的には、任意の監督学習モデルがこのレコールモデルに使用できます。たとえば、FM（Factorization Machines）やDNN（Deep Neural Networks）などが挙げられます。一般的に言われる「Dual Tower」モデルは、ユーザー側とアイテム側の特徴を分離し、それぞれの埋め込み構造を生成するモデルを指します。
FMモデルを使用してレコールを行う具体的な操作については、下記の記事で詳しく説明されています。
ランキング
ランキングのタスクは、上流から数千のアイテムがユーザーの興味に比較的合致するものを厳選し、その中からユーザーの好みに最も合った100以上のアイテムを選択するものです。排序段階は、レコメンドシステムの3つのステージの中で最も注目される部分と言えるでしょう。
理由は：
- 候选集が絞られて、速度が制約要因ではなくなると、精密なランキングのためにより複雑なモデル構造を採用する条件が整いました。これにより、予測の精度をさらに向上させることができます。
- ランキングは推薦プロセスの後半に位置し、ビジネス目標への影響が直接的かつ強力です。
ランキングの設計の主要な焦点は、予測精度の向上です。したがって、リコールとは異なり、ランキングモデルの主要な焦点はアイテム情報とユーザー情報をより十分に交差させることです。そのため、ランキングではより多くのクロスフィーチャーを導入し、より複雑なモデル構造を使用しています。
現在、最も人気のあるソートモデルにはDeepFMモデルとWide＆Deepモデルが含まれます。これについては他の記事で詳しく説明します。
再ランキング
ランキング時、類似したコンテンツ（例えば、同じトピックや同じタグを持つもの）は、ランキングモデルによって似たようなスコアが与えられ、結果セット内で近い位置に配置されます。このようなソート結果をユーザーに直接表示すると、ユーザーは似たようなコンテンツを何件も見ることになり、視覚的疲労を感じやすく、それがユーザーエクスペリエンスに悪影響を与える可能性があります。そのため、ランキング結果はリランク（再ランキング）が必要です。
前述のプロセスとは異なり、再ランキングの主な目的はフィルタリングではなく、ランキング結果の順序を調整し、類似したコンテンツをばらばらにし、ユーザーが1画面内で見ることができる推薦結果を多様かつ豊かにすることです。
再ランキングは「脇役」の一部ですが、どのレコメンドシステムでも欠かせない要素です。小規模なシステムでは、再ランキングは比較的簡単で、いくつかのルールで実現できます。
データのアーキテクチャ
上記で紹介した機能アーキテクチャに加えて、レコメンドンシステムのモジュールはデータ処理の方法に基づいても分割でき、それがレコメンドンシステムのデータアーキテクチャです。
例えば、各ビデオの人気度をモデルに理解させるために、各ビデオのCTR（クリックスルーレート）を計算する必要があるとします。見かけには簡単なタスクのように見えますが、実際には以下の2つの難点があります。
- 最初に、統計結果の有効性を確保するために、統計ウィンドウを長く設定する必要があります。たとえば、過去1週間の各ビデオの露出回数やクリック数を統計します。ただし、過去を遡る期間が長くなるほど、関連する計算量も増えます。
- 次に、時間が非常に制約されています。オンライン予測時に、ユーザーのリクエストを受け取ってから推薦結果を返すまでの総時間は厳密に100ミリ秒以下に制限され、すべての特徴の準備に使える時間も100ミリ秒を超えません。
問題解決のアプローチは以下の通りです。
- データリクエストを、コールドデータとホットデータに分けて2つのサブリクエストに分割する。
- コールドデータのリクエストに関しては、「オフラインレイヤー」が一括で計算を行い、その結果をキャッシュに保存して高速なクエリを提供します。
- ホットデータのリクエストに関しては、「オンラインレイヤー」がストリームアルゴリズムを使用して処理します。
- コールドデータとホットデータから取得したサブ結果を集約し、最終的な計算結果を得ます。
おわりに
この文章は、レコメンドシステムのアーキテクチャとプロセスについて概要を提供しており、読者に一般的な理解を持ってもらうことを目的としています。もちろん、各段階は詳細に説明できます。
他にも知りたいことがあれば、コメント欄に質問を残していただければ幸いです。
Discussion