1時間でなんとなくわかる推薦システム読書会

推薦システムのアルゴリズム(http://www.kamishima.net/archive/recsysdoc.pdf)
の社内向け読書会資料

Transcript

1. 株式会社クラウドワークス マッチングUXグループ 1時間でなんとなくわかる 推薦システム読書会
2. 題材 • 推薦システムのアルゴリズムの第 I 部まで ◦ http://www.kamishima.net/archive/recsysdoc.pdf
3. 目次 • 第 I 部 推薦システムの概要 p.1 • 第 1 章 推薦システム p.2 • 第 2 章 推薦システムの分類と目的 p.5 • 2.1 推薦の個人化の度合い p.6 • 2.2 推薦システムの運用目的の分類 p.8 • 2.3 推薦システムの予測タスクの分類 p.10 • 2.4 推薦システムの利用動機の分類 p.11 • 第 3 章 推薦システム設計の要素 p.13 • 3.1 推薦の性質 p.13 • 3.2 推薦候補の予測に関する制約 p.19
4. 推薦システムとは どれに価値があるかを特定するのを助ける道具 背景 • 大量の情報が発信されるようになった • 情報の流通が容易になった 要するに、情報過多
5. 歴史 • 初期はフィルタリングの手法 ◦ 協調フィルタリング ▪ 手動で作った推薦を検索できる ▪ 現在の「協調フィルタリング」とは違うもの ◦ 内容ベースフィルタリング • 徐々に推薦システムという呼び方が定着
6. 構成要素 • ヒューマン・コンピュータ・インターフェイス • 機械学習・統計的予測 • データベース、並列計算、ネットワーク
7. 第2章: 推薦システムの分類と目的 関連する (似た) 技術と、推薦システムとの違い • 情報フィルタリング ◦ 不要なものを除外するという点で異なる • マーケティングの技術 ◦ 供給側の視点に立つという点で異なる
8. 2.1 推薦の個人化の度合い 推薦は消費者個々人に向けて • 非個人化 (no personalization) • 一時的個人化 (ephemeral personalization) • 永続的個人化 (persistent personalization)
9. 2.1 推薦の個人化の度合い 非個人化 (no personalization) • すべての利用者に全く同じ推薦をする ◦ 売上順位 ◦ 単純にオススメ ◦ 個人化されておりかつ自動化されたものも含められる • 推薦データの選定方法 ◦ 温かみあふれる人の手作業で選ぶ • クラウドワークスでいうところの ◦ オススメのお仕事の「 イチオシ特集」（少々の疑問は残るが・・・） ◦ オススメ案件メルマガ
10. 2.1 推薦の個人化の度合い 一時的個人化 (ephemeral personalization) • 同じ振る舞いをしたユーザーには、同じものを推薦する ◦ 関連商品 (RedBull ⇒ Monster) ◦ 付属商品 • 推薦データの選定方法 ◦ 単純に関連する商品など (関連する栄養ドリンク ) ◦ 個人のバックグラウンドは関係なく、表面的な行動が同一であれば同じものを推薦する • クラウドワークスでいうところの ◦ 仕事詳細画面の「この仕事の依頼内容に似ている仕事 」 ◦ 仕事詳細画面の「この仕事を見た他のユーザーが見ている仕事 」 ◦ マイページ画面の「オススメ」タブ ◦ オススメのお仕事の「 あなたにオススメの仕事 」?
11. 2.1 推薦の個人化の度合い 永続的個人化 (persistent personalization) • 同じ行動をしていても、ユーザーのバックグラウンドに応じて推薦する ◦ 年齢 ◦ 過去の利用履歴 ◦ 過去の商品への評価 • 推薦データの選定方法 ◦ 関心があるであろうアイテムを「順位付け」して推薦 ◦ 過去評価をつけたアイテムの類似商品など • クラウドワークスでいうところの ◦ 「まだない」 ◦ 新しく作って行きたい
12. 2.2 推薦システムの運用目的の分類 推薦するにもいろんな見せ方がある • 概要推薦 (broad recommendation) • 利用者評価 (user comments and rating) • 通知サービス (notification service) • 関連アイテム推薦 (item-associated recommendation) • 緊密な個人化 (deep personalization)
13. 2.2 推薦システムの運用目的の分類 概要推薦 (broad recommendation) • 適正な対象者 ◦ 初心者 ◦ 利用頻度が低いユーザー • 推薦の効果 ◦ 自身の要求とサービスが提供する情報との間に「価値」を見出してもらう • 推薦データの見せ方 ◦ アクセスしたときのファーストビューに大まかな情報を見せる ◦ 「非個人化」または「一時的個人化」したアイテムを見せる
14. 2.2 推薦システムの運用目的の分類 利用者評価 (user comments and rating) • 適正な対象者 ◦ 自ら参照したユーザー • 推薦の効果 ◦ アイテムに対する信用向上、サービス利用の頻度向上が期待できる • 推薦データの見せ方 ◦ 運営者は関与せず、ユーザーが自ら閲覧したアイテムについて評価を見せる ◦ ユーザー視点での公平公正な第三者評価（ユーザー間の評価）として見せる ◦ 「非個人化」または「一時的個人化」したアイテムを見せる
15. 2.2 推薦システムの運用目的の分類 通知サービス (notification service) • 適正な対象者 ◦ システム利用していないユーザー • 推薦の効果 ◦ システムの再利用を促す効果 • 推薦データの見せ方 ◦ 過去履歴から似たアイテムを推薦 ◦ 好きなアーティストなどの新着を見せる（明確な表明から推薦） ◦ 「永続的個人化」または「一時的個人化」したアイテムを見せる
16. 2.2 推薦システムの運用目的の分類 関連アイテム推薦 (item-associated recommendation) • 適正な対象者 ◦ アイテムを閲覧、購入検討しているユーザー • 推薦の効果 ◦ 購入の決断を促す（後押し） ◦ 追加購入を促す（後押し） • 推薦データの見せ方 ◦ アイテムの比較候補（例：他メーカーの同等品）や補助的な商品（ OP付属品）を見せる ◦ 「一時的個人化」または「永続的個人化」したアイテムを見せる
17. 2.2 推薦システムの運用目的の分類 緊密な個人化 (deep personalization) • 適正な対象者 ◦ システムを利用し続けているユーザー • 推薦の効果 ◦ 競合システムとの差別化 ◦ 長期間にわたるロイヤリティの向上効果 • 推薦データの見せ方 ◦ ユーザーの過去の行動情報を蓄積して推薦を行う（利用が長いと精度が高くなる） ◦ 「永続的個人化」または「一時的個人化」したアイテムを見せる • 補足 ◦ 実装コストが高い（最もパーソナリティが高い推薦であるため）
18. 2.3 推薦システムの予測タスクの分類 (1/4) 適合アイテム発見 (finding some good items) • ユーザーが自分の嗜好に適合するものを見つけ出すこと • ユーザーが積極的な動機を持っている • 例 ◦ 食事するためにレストラン推薦を利用 ◦ 評価の高いレストランに絞り込んで提示
19. 2.3 推薦システムの予測タスクの分類 (2/4) 評価値予測 (predicting ratings) • ユーザーがアイテムに付けるであろう評価値を予測すること • 例 ◦ レストラン紹介のWebサイトで料理の種別、★の数、店の写真などを同時に表示することで、ユー ザー自身が何に関心があって探しているのかを助ける
20. 2.3 推薦システムの予測タスクの分類 (3/4) 適合アイテム列挙 (finding all good items) • ユーザーが自分の嗜好に適合するものを網羅的に見つけ出すこと • 適合しないものを排除する目的であるともいえる • 例 ◦ 会社の法務部門が関連する特許や判例を検索 ◦ スパムメールの可能性がないメールだけを閲覧
21. 2.3 推薦システムの予測タスクの分類 (4/4) 効用最適化 (optimizing utility) • 何らかの効用関数(物，エネルギー，情報，サービスなどの効用を数値におきかえ る関数)を設定し，それを最適化するようなアイテムを見つけること • 例 ◦ 電子商取引サイトで推薦システムによって利益を増やす場合に，元から購入を意図していたアイテ ムに追加のアイテムを購入させるという組み合わせ販売 (cross-selling) を促進するような効用関 数を設定
22. 2.4 推薦システムの利用動機の分類 (1/2) • 備忘録 (reminder) ◦ 既知のアイテムを思い出させる . ▪ 過去に見た仕事 気になる！リストに入れた仕事 • 類似品 (more like this) ◦ 比較などのため既知のアイテムに類似したものを探す . ▪ この仕事に似た仕事 ▪ この仕事を見ている他の人が見た仕事
23. 2.4 推薦システムの利用動機の分類 (2/2) • 新規アイテム (new items) ◦ 自分が確実に好むであろう，未知の新製品を探す . ▪ ？？？ • 視野を広げる (broden my horizon) ◦ 他のジャンルにも自分の関心を広げる . ▪ タスク⇒ライティングタスク ▪ ライティングタスク⇒固定報酬ライティング
24. 第 3 章 推薦システム設計の要素 • 機械学習の基本的な定理であるノーフリーランチ定理によれば万能アルゴリズム は存在しない https://ja.wikipedia.org/wiki/ノーフリーランチ定理
25. • アルゴリズムは利用目的や推薦を実行する環境の制約に応じて選択する ◦ 推薦の性質 ◦ 推薦を計算するためのデータや計算機資源の制約 第 3 章 推薦システム設計の要素
26. 3.1 推薦の性質 • 推薦のターゲットとなるユーザーが何を好むかは、目的、状況、推薦候補によって 変わる • 推薦の性質を決める基準があれば、どういう時にどういう推薦を行えばいいか考え ることができる • 基準となるものは以下のようなもの ◦ 予測精度 ◦ 多様性・セレンディピティ ◦ 被覆率 ◦ 学習率
27. 3.1.1 予測精度 • 予測して推薦したアイテムを実際にユーザーがどれくらい関心を持つかという基準 • もっとも重視すべき基準 • 評価方法 ◦ オンライン ▪ 実際にユーザーにフィードバックしてもらう • ユーザーごとにABテストしたり、ABまぜてどちらがより選ばれるかなど ◦ オフライン ▪ 事前にユーザーから集めた嗜好データと予測結果が一致するかを調べる ▪ 交差確認: データを訓練用とテスト用で分けて精度を評価する ▪ 超パラメータがある場合は訓練用、確認用、テスト用に分ける
28. 3.1.1 予測精度 • 予測精度の尺度 ◦ 正解率(accuracy) ▪ 予測結果とテスト用データの一致率 ◦ 精度(precision)と再現率(recall) ▪ 精度: 判定結果が実際にあっている率 • 例) 違反案件判定されたものが実際に違反案件である率 ▪ 再現率: 判定がもれなくされているかの率 • 例) 実際に違反案件であるもののうち違反案件と判定される率 ▪ rf. F尺度, ROC曲線 ◦ 平均絶対誤差 ▪ 予測値が正解から平均的にどの程度の乖離があるか ◦ half-life utility metricと順位相関(rank correlation) ▪ 推薦するアイテムの並び方の良さ
29. 3.1.1 予測精度 • 予測精度の問題 ◦ 交差確認による評価はテストに用いるサンプルと今後予測するサンプルは同じ分布の前提 ◦ 評価されない推薦アイテムはユーザーが関心を示さなかったものであることが多い ◦ 評価されないアイテムは評価が低いアイテムに偏る ◦ 予測対象となるアイテムの分布とテストに用いるアイテムの分布が異なってしまうので厳密な評価 が難しい ▪ テスト時は適度にばらけたサンプルでテストしていたけど、実運用にはいると評価の低いアイ テムはフィードバックを得られない可能性が高い ▪ なので無反応のものは評価されなかったとしてフィードバックデータとして蓄積する必要があ る
30. 3.1.2 多様性・セレンディピティ(diversity・serendipity) • そのユーザーが好むものを推薦してもわかりきったものではその推薦は有用とは 言えない場合がある • 仕事の推薦としてはこの要素はそこまで求めなくてもいい気がする
31. 3.1.3 被覆率(coverage) • 全アイテムのうち予測可能なアイテムの割合 ◦ 例) 公開直後の仕事は誰にも見られていないのでオススメに出てこない • 仕事はおすすめできるものをもれなくおすすめできたほうがいいので被覆率は 100%が望ましい
32. 3.1.4 学習率(learning rate) • 予測精度の向上具合 • 学習率を高くしすぎると過学習となり、予測精度がかえって悪くなる場合がある ◦ 例) ニッチな違反案件を判定できるようにすると、よくある違反案件が判定できなくなる的な？
33. 3.1.5 推薦の性質に関するトレードオフ • 評価基準はトレードオフである • 推薦対象や利用者の目的など様々な要因を考慮して決める必要がある
34. • 推薦候補を予測するために必要な，データや計算機資源は無限にはなく，何らか のトレードオフを考慮しつつ推薦アルゴリズムを選択する必要がある 3.2 推薦候補の予測に関する制約
35. • 嗜好データの制約 ◦ （一般的に）「疎」である ▪ 評価値があるのは全体の 1%〜0.001%（CWはこれに比べると多分だいぶマシ） ▪ しかも評価数は一部のアイテムに偏る（評価数は指数関数的に減少する） ◦ 揺らぎが大きく，評価のたびに変化して不整合を生じる ◦ 利用者数とアイテム数の比率は予測精度に影響する（利用者数に対してアイテム数が多すぎると 精度が出ない？） ◦ 運用中に，随時データが追加される ◦ 平滑化（is 何？）などを用いた予測技術を使うと，疎なデータでも比較的安定的な予測ができる（一 方、計算量が増えて予測モデルの更新を頻繁に実行しにくくなるという問題もある） 3.2 推薦候補の予測に関する制約
36. • その他の制約 ◦ データ数が多数であるにもかかわらず，高速な予測が要求される（スケーラビリティの問題） ◦ 推薦をする状況や利用者の暗黙的な要求 ▪ 利用者がどれくらい詳細な推薦を求めているか（適合・不適合のみ、適合の度合いも必要、など） 3.2 推薦候補の予測に関する制約