レコメンドを勉強していく
winnie279レコメンドに入門する
レコメンドとは？
以下のように定義する。
複数の候補から価値のあるものを選び出し、意思決定を支援する[1]
AmazonなどのECサイトで見る、「あなたへのおすすめ商品」などが一例。
レコメンドは「ビジネス × データサイエンス × エンジニアリング」の3軸と、レコメンドシステムの発展を顧みる時間軸の、合わせて4軸で見ると理解しやすい。
ビジネスから見るレコメンド
なぜレコメンドが必要なのか？
1990年代後半のインターネットの普及により[^2]、ECサイトで膨大な商品を扱うようになった[^3]。マーケットにはロングテールが生まれ[^4]、それをどのようにマーケティングするかが課題となった[^5]。
レコメンドが何を解決するのか？
何を求めてるのか？そこまで性能を求めるのか？リアルタイム性を求めるのか？アイテムに流動性があるのか？ファッションとか。コストに見合うか？アイテム数は多いのか？検索機能が充実していないのか？KPI
レコメンドとデザイン
UIUX
レコメンド理解の必要性 CSは、汎用的な複数のレコメンドからドメインとの兼ね合いを考えて最適なレコメンドを提案する必要がある
レコメンドと思惑
補正項（売りたいアイテム）の表現
データサイエンスから見るレコメンド
レコメンドシステムは、「Aさんが商品Bにつける評価は★4だ」のように、数学的にはあるユーザーがある商品につける評価値を予測する問題と言える。ただし、あるユーザーが購入するのはごく一部の商品であり（疎, スパース）、そのデータから残りの膨大な商品の評価値を予測するのは難しい。そこで、統計や機械学習など様々な方法を用いて高い精度で評価値を予測することになる。
レコメンドが抱える数学的な問題点
アイテム-ユーザー行列のスパース性 → 行列分解
コールドスタート問題
検索上位のバイアス
複数の分野の数学でみる
ベクトル空間：ユーザーを高次元のアイテム空間で表す
統計：P（ y|x）
類似度計算 cos類似度とか ジャッカード係数とか
近似最近傍探索 正確性を犠牲に近傍ベクトルを計算
エンジニアリングからみるレコメンド
レコメンドシステムではあるユーザーがある商品につける評価値を予測するため、基本的な計算量はユーザー数 × アイテム数（＝ O(MN)）となる。ユーザーが1人増える度に計算量がM増えてしまうため、処理が重くなりやすい。エンジニアリングでは、計算量を少なくすることが課題となる。また、データを把握するために可視化することも重要である（ユーザーはM次元のベクトルになっていたりするので、可視化も意外と大変である）。
計算量 ← 協調フィルタリング
バッチレコメンド（オフライン？） or オンラインレコメンド
評価値行列
-
推薦システム実践入門 ↩︎
winnie279バスケット分析 Non-personalized
- 支持度
- 信頼度
- lift
winnie279協調フィルタリング
予測値の計算
winnie279類似度
ピアソン相関係数
コサイン類似度
winnie279Large Language Model（LLM）
winnie279Neural Collaborative Filtering（NFC）
ユーザーのone-hotベクトルとアイテムのone-hotベクトルを結合したベクトルから評価値を予測している。
winnie279Neural Graph Collaborative Filtering
-
Graph Convolutional Matrix Completio（GCMC）
https://arxiv.org/abs/1706.02263 -
Graph Neural Network for Session-based Recommendation（GCSRec）
https://arxiv.org/abs/1811.00855
winnie279時系列
- Sequential graph collaborative filtering
- Sequential Variational Autoencoders for Collaborative Filtering
Recurrent Recommender Networks
Self-Attentive Sequential Recommendation
winnie279Dataset
Instacart Market Basket Analysis
winnie279User-Based Collaborative Filtering
Item-Based Collaborative Filtering
Matrix Factorization
SGD-based Matrix Factorization
Non-negative Matrix Factorization（NMF）
AutoRec
Deep Learning Collaborative Filtering
winnie279ざっくり説明
前提
- あるユーザーがあるアイテムに付ける評価を予測する。
→ ユーザーi j r_{i, j} i ∈ N, j ∈ M - 予測する評価は、似たユーザーの評価と近くなると考える
→ 類似したユーザーは類似した評価を行うと仮定する。 - 今ある評価を元に、評価されていない値を予測する。
→ ユーザー間の類似度で重み付けした、評価値の加重平均を予測値とする。
古典的な手法
- ユーザー同士がどのくらい似ているか計算する。
→u_i u_i' s_{i, i'} - 似ているユーザーの評価ほど重要視されるように、評価の平均値を出す。
→ 類似度を重みとして（s_{i, i'} ･ r_{i', j} - 平均値をユーザーの評価の予測にする。
- すべてのユーザーの組み合わせ × アイテム数の分を計算する。
→ 計算量はO (N^2M)
winnie279LLM
winnie279P5（Pretrain, Personalized Prompt, and Predict Paradigm）
（おそらく）LLMをレコメンド用のデータセットでファインチューニングする。様々なタスクを、プロンプトを使い分けることで1つのモデルで対応できるようになっている。
以下のようなプロンプトでファインチューニングする。
"input": "What is the top recommendation for ML100K user_4 ?"
"output": "ML100K item_1081"
winnie279上記のIDをプロンプトに含める際に、IDを意味のあるテキストにする技術
winnie279A Survey on Large Language Models for Recommendation
winnie279Two-Tower Model
GoogleやYouTubeなどで用いられる推薦モデル。クエリをベクトルに埋め込む構造（タワー）と、アイテムをベクトルに埋め込むタワーの、2つのタワーから構成される。ベクトル同士の乗算は、それぞれの特徴量が圧縮された後に行われるため高速である。また、アイテムベクトルは、アイテムに変更がない限り計算結果をキャッシュできる。
例えばアイテムベクトルをテキストの埋め込みとして獲得すれば、テキスト同士の類似度を比較することでコールドスタートの問題を回避できる。
winnie279Deep Learning Recommendation Model for Personalization and Recommendation Systems（DLRM）
winnie279なんか忘れたけど2016の有名なGoogleの論文
winnie279検索
マッチング
- 単語によるインデクシング
- 単語とその位置情報による（フレーズに対応した）インデクシング
- メタワード（HTMLなど）を利用したインデクシング
"Constrained Searching of an Index" (AltaVista, 1999)
ランキング
"The anatomy of a large-scale hypertextual web search engine." (Brin, Sergey, and Page, 1998)
winnie279Matrix Factorizationの実装