推薦入門を読んだ

『推薦システム実践入門』を読んだ

動機

検索と推薦はかなり近い領域の話だと思ったので、この機会にまとめて概要をおさえておきたかった。
協調フィルタリング、コンテンツベースフィルタリングなどの概念自体は知っていて、とても素朴なアルゴリズム(K近傍)を使った機能などは実装していたが、
より精度を高めるためには何をすればよいのかを知りたかった
PythonでMovieLensのデータを実際に試す、みたいなのはそもそも行列とかが分かってないので一旦飛ばした。
肌感みたいなのは全然得られてないので、機械学習に必要な数学を勉強してから再チャレンジしたい

メモ

p.9 閲覧履歴をベースにした推薦

閲覧履歴にはユーザーの嗜好がリアルタイムに反映されるので、関連アイテムを取得するアルゴリズムを実装しておくとパーソナライズも簡単でコスパがよい

p.20 ROIを考える

推薦機能の実装はコストが高いので検索を含む各施策を出して、ROIの高いものから取り組んだほうがいい

課題	対応策	重要度	コスト	優先度

p.21 概要推薦

人気ランキング、とか編集部おすすめ、みたいなものを概要推薦と呼ぶ。
特に人気ランキングのRecall、Precisionを指標として見るのが良さそう

p.40 パーソナライズされた推薦

〇〇さんへのおすすめ、などパーソナライズされていることを強調する
情報が集まりきっていないうちに推薦すると、ユーザーががっかりして信頼感を損ねることにつながるので十分にデータが集まってからにする
気に入らないアイテムを出現させないようにするなどのネガティブなフィードバックを返す手段を用意する

p.55 推薦理由を提示する

〇〇を見てるあなたへのおすすめ、などの推薦理由を提示することによって、運営側の利益誘導と疑われることを回避できる

p.60 メモリベース法とモデルベース法

予測のタイミングで全データを使って計算するものをメモリベース法、事前に作成されたモデルとユーザーのデータのみを使うのをモデルベース法という

p.70 明示的獲得と暗黙的獲得

レーティングなどが明示的獲得、クリックや滞在時間が暗黙的獲得にあたる

p.82 未評価と不支持

暗黙的獲得では未評価と不支持を判別しにくい
3回推薦したのにクリックがなかった、など条件を設定することで区別していく

p.83 データのスパース性

ほとんどのユーザーとアイテム間の評価値は埋まっていないことが多い。
これをデータがスパースであるという
購入データのみを評価対象にするのではなく、暗黙的に獲得された情報(クリックなど)を使って補完することが必要

p.88 各アルゴリズムの一覧

アソシエーションルールとFactorizationMachines, item2vecが良さそうかなと思った

p.97 アルゴリズムの評価方法

元になるデータを学習用とテスト用に分けておく。確かにと思った…
予測値と実際の評価誤差(RMSE), 何個当てられたか(Recall@K), どれぐらいの割合で当てはまっていたか(Precision@K)を使う

p.110 アソシエーションルール

あるアイテムAとアイテムBが一緒に購入されることが多い、といった法則を見つける。
あとで実際に動かしてみたい

p.118 ピアソンの相関係数

ユーザーやコンテンツの類似度を計算するときに使う。
これも後で動かす

p.130 特異値分解

評価値行列を分解するときに欠損値をどうするかが大事らしい
これも後で

p.136 Matrix Factorization

欠損値を埋めず、観測された評価値のみを使って行列分解する

p.145 Factorization Machines

評価値だけでなく、特徴量も使える

p.161 word2vec

ユーザーの行動履歴を単語の集合と見なしてword2vecを適用する
アイテムのベクトルさえ保持していればユーザーのベクトルを瞬時に計算できるのでオンライン推薦に使いやすい

p.165 深層学習

コンテンツベース推薦の性能を高めることができる

p.180 多段階推薦

候補選択 -> スコアリング -> リランキングの3段階に分けることでシステムの負荷を下げることができる

p.182 近似最近傍探索

各ベクトルを領域ごとに分割し、インデックスしておくことで類似するアイテムを絞込める

p.186 近似最近傍アルゴリズムの選択フローチャート

アイテム数、GPU、メモリの速度によって選択すべきアルゴリズムの図が載ってた
N < 10^6 CPUなしなのでfaiss-cpu 線形探索(IndexFlatL2)が良さそう

p.190 ECサービスでの行動ログ例

user_id item_id position location logic action date
推薦ランキングの位置(position),アルゴリズムの名前(logic)などが特徴的

p216 評価指標の実装にはバグが入りやすい

OSSなどの検証済みの実装を使ったほうがよいとのこと

p.218 A/Bテスト実施時の仮説テンプレート

コンテキスト、変更点、対象、指標目標、ビジネス目標を明文化する

p.221 指標の設計方針

A/Bテストのベストプラクティスと落とし穴 ~KDD2019 レポート~ - Gunosyデータ分析ブログ

p.233 バイアス

ユーザーは自分の好みの作品にしか評価をつけない、他のユーザの評価に影響される、人気の作品がより推薦されやすくなる
などのバイアスを前提にした実装が必要