rtrec@dbem6

Database Engineering Meetup #6: Data + AI
https://scalar.connpass.com/event/345819/

で @myui が発表した
「おすすめが止まらない：秒単位で即応するリアルタイム推薦技術」のスライドです。

リアルタイムの推薦ライブラリ
https://github.com/myui/rtrec
を紹介しました。

Transcript

1. おすすめが止まらない: 秒単位で即応するリアルタイム推薦技術 Real-Time Recommendation Technology evolving at the Speed of Seconds Senior Principal Engineer Makoto Yui @myui
2. 自己紹介 @myui 2 2009年 NAIST博士後期課程修了。博士（工学） ロックフリーDB、並列分散DB、XMLネイティブデータベースを研究 学振PD、CWI客員研究員、産総研主任研究員を経て、2015年トレ ジャーデータ入社。 Research Engineer→ワークフローteam→ML team tech lead→CTO室所属 Apache Hivemallの開発やTreasure AutoMLのサービス化をリード XMLデータベースの開発で第1期IPA未踏ユーススーパクリエイタ
3. https://github.com/myui/rtrec 3 rtrec: リアルタイムユースのオンラインのモデル更新を サポートする唯一(?)のOSSレコメンデーションライブラリ 本日紹介する内容
4. Why Realtime Recommendation? 4 ある日のブレインストーミング パーソナライゼーションは重要だけど、なんでリアルタイム？
5. Why Realtime Recommendation? 5
6. 6 従来の推薦システム • オフラインで生成されたバッチ推薦 ◦ モデルの更新は頻繁に出来ない（毎日または毎週） • オンラインのモデル更新に対応したOSSの推薦ライブラリが存在しない ◦ Implicit、LightFMとそのwrapperのRectoolsは割とよくできているが、逐次更新には 対応できない ◦ 最初はContextual Banditsを検討したが、線形モデル(arm)をアイテムごとに作るので予測がスケールし ない（オンライン更新に対応したapprox NN検索ライブラリがない） Argmax dot productを近似NNで高速化 https://www.benfrederickson.com/approximate-nearest-neighbours-for-recommender-systems/ Why Realtime Recommendation?
7. 従来の推薦システムの制限事項 7 • ユーザーの行動にリアルタイムで対応できない ◦ 既に購入済みのアイテムに関連したアイテムが表示される ▪ ヒューリスティックなロジックで後処理する必要がある ◦ レコメンドしたアイテムに反応がなくてもレコメンド内容に反映されない • コンテキストに応じた推薦ができない ◦ 子供と一緒の時と一人では観る番組が異なる ◦ 時間帯によって興味が異なる（通勤中、リラックスした時間） • 推薦された商品に興味がないのにクリックしていないのに 推薦リストが更新されない ◦ 否定的または肯定的なリアルタイムのフィードバックが 即時反映されない
8. Why Realtime Recommendation? 8 リアルタイム推薦システム • ユーザーのインタラクションに動的に適応し、コンテキストに応じた 推薦を行う • 技術課題 ◦ モデルを動的に更新するにはオンライン学習が必要だが、巷にある推薦 ライブラリはオンライン学習に非対応 ◦ 蓄積済みバッチ的な学習と差分学習の両立 ▪ オンライン学習(1 epoch)だけだと精度面やスループットの問題が ある • ある程度データ量がないと良いモデルが作れない • 新規のデータに対して追加学習できることが重要
9. 典型的な推薦システムのアーキテクチャ 9 分断された壁
10. 既存のOSS推薦ライブラリ 10
11. 12 リアルタイム処理のコストに見合わない状況 • コンテンツやユーザー嗜好の変化が緩やか → オフラインやバッチ処理で十分な精度が得られる場合 • システムコストと複雑性の増大 → リアルタイム処理のインフラ投資や運用コストが過剰な場合 • コールドスタート問題 → 初期データが不足しているユーザーには適用が難しい When not to use real-time recommendations? Disclaimer: リアルタイムが常に必要とは限りません バッチレコメンデーションで十分なケースも多く存在します
12. When to use real-time recommendations? 13 リアルタイムレコメンデーションが効果的な状況 • ユーザー行動の急速な変化 例: 閲覧、クリック、購入などの直近のアクションに基づく推薦 • 動的なコンテキスト 例: 季節性、トレンド、イベント等、時間依存の要素が強い場合 • 即時性が求められるアプリケーション 例: ニュース、ソーシャルメディア、フラッシュセールなど
13. リアルタイム推薦の主要課題 14 1. スケーラビリティ: 大量のデータとトラフィックの処理 2. レイテンシ: ミリ秒単位での推薦生成 3. 精度: スピード要件にもかかわらず推薦の質を維持 4. 新鮮さ: 推薦が最新のユーザー行動を反映していることを 保証 5. エンジニアリングの複雑さ: モデルをストリーミングシス テムと統合 これらの課題は互いに密接に関連しており、一つの課題を最適化すると他の課題に影響を与える トレードオフの関係 → リアルタイム推薦システムはこれらのバランスを考慮する必要がある
14. 精度と新鮮さのトレードオフ 15 トレードオフと解決策: トレードオフ: 複雑なモデル(DNNなど)は精度が高いが計算に時間がかかり頻繁な更新が難し い •解決策1: バッチで事前計算した基本モデルをオンライン学習でリアルタイムに増分更新 •解決策2: 静的特徴に加え、動的特徴や最新のユーザ評価を利用できる学習モデルを採用する
15. レイテンシと精度のトレードオフ 16 トレードオフと解決策: トレードオフ: 高精度なモデルほど計算コストが高く、レイテンシが増加する •解決策1: モデルの軽量化と最適化（量子化、枝刈り、モデルの蒸留） •解決策2: 2ステージの段階的計算（最初に簡易の候補生成+高精度モデルでフィルタリング） •解決策3: 結果のプリコンピューティングと戦略的なキャッシング 使い回しやすい 2-stage recommender systemの デザインパターンを考えて実装した話 最初の候補にそもそも入らないと厳しい（購入済みの関連アイテムが表示されるなど） キャッシュからの削除も考えないといけない
16. 新鮮さとエンジニアリングの複雑さ 17 トレードオフと解決策: トレードオフ: リアルタイム処理の実現は、システム設計と運用の複雑さを大幅に増加させる •解決策1: ストリーミングプラットフォーム（Kafka、Kinesis）を活用した標準化された処理パイプラ イン •解決策2: マイクロバッチ処理の採用（完全なリアルタイムと定期バッチの中間）
17. リアルタイム推薦の主要課題 18 •スケーラビリティ、レイテンシ、精度、新鮮さ、エンジニアリングの複雑さ の間には本質的なトレードオフが存在 •アプリケーションの具体的なニーズと優先事項に基づいてバランスポイント を決定することが重要 バッチでのモデル構築も高速で、オンライン学習を利 用した低いレイテンシの増分更新をどちらにも対応で きれば良くね？ できればライブラリ側で課題を吸収して欲しい
18. 推薦アルゴリズムの基本 （recap; Matrix Completion) 19 提案手法の説明に不可欠なので推薦アルゴリズムの基本から説明します 推薦アルゴリズムの雰囲気だけでも感じていただけたらと思います
19. 明示的（Explicit）Feedback 20 行列補完 アルゴリズム
20. Matrix Factorization (FunkSVD) 21 R ≈ P × Q^T R: 評価行列（欠損値を含む） P: ユーザー潜在特徴行列 Q^T: アイテム潜在特徴行列の転置 Netflix Prizeで Simon Funk によって提案された推薦システム向けの 行列分解手法（低ランク行列で近似）
21. 22 実用例 ✅ Netflix: Netflix Prizeで広く使われ、推薦システムの基盤技術となった ✅ Amazon: 商品推薦エンジンに類似手法を採用 ✅ Spotify: 音楽推薦に行列分解ベースの手法を利用 ✅ YouTube: 動画推薦に広く活用 Matrix Factorization (FunkSVD) Netflix Prizeで Simon Funk によって提案された推薦システム向けの 行列分解手法（低ランク行列で近似）
22. 暗黙的(Implicit) Feedback 24
23. 暗黙的(Implicit) Feedback 25 +1 インタラクションあり（購入した/クリックした）
24. Why Implicit Feedback is (generally) preferred over Explicit Feedback? 26 https://github.com/maciejkula/explicit-vs-implicit LightFMの作者やImplcitの作者によるImplicit beats Explicit Feedbackが良いという主張 ・学習させる事例数/Information Entropyが多くなる
25. Bayesian Personalized Ranking (BPR) 27 暗黙的Feedbackのためのペアワイズ比較に基づく確率的ランキング手法 基本概念 • ユーザは観測されたインタラクションしたアイテムi(+1)は未観測のものよりアイテムj(-1)より好む と仮定 • ユーザーの選好関係の順序（i > j）を直接モデル化 i(+1) j(-1) • 𝑃 𝑖 <𝑢 𝑗 : ユーザ𝑢がアイテム𝑖よりアイテム𝑗を好む確率 • ෠ 𝑋𝑢𝑖 , ෠ 𝑋𝑢𝑗 : ユーザ𝑢に対するアイテム𝑖, 𝑗の予測スコア 定式化 𝑃 𝑖 <𝑢 𝑗 = 𝜎 ෠ 𝑋𝑢𝑖𝑗 = 𝜎 ෠ 𝑋𝑢𝑖 − ෠ 𝑋𝑢𝑗 > 0.5 目的関数
26. 28 Bayesian Personalized Ranking (BPR) i(+1) j(-1) 3 4 5
27. WARP (Weighted Approximate-Rank Pairwise) 29 3 4 5
28. Negative samplingに対する疑問 30 新規アイテムが時間経過と 共に増えていく 新規ユーザも時間経過と 共に増えていく 新規追加されるアイテムよりも 既存アイテムの方が、高い確率 で選ばれ、偏ったサンプリング がされてしまう リアルタイムフィードバックを考慮すると…
29. iALS (Implicit Alternating Least Squares) 31 • 交互最小二乗法（Alternating Least Squares)を暗黙的Feedbackに適用する手法 ◦ 共役勾配法（Conjugate Gradient）を利用した効率的な計算が可能（OSSのimplicitが代表 的な実装） • 近年Stefan Rendel（BPR/FM論文の著者）らのGoogle研究チームによって、重要な指摘がなされ、 Deep系のモデルに匹敵する結果であると報告されている[1] S. Rendel et.al., Revisiting the Performance of iALS on item Recommendation Benchmarks, Proc. RecSys’22 S. Rendel et.al., Revisiting the Performance of iALS on item Recommendation Benchmarks, Proc. RecSys’22 ✅ ML20Mでは、iALSはMult-VAEと同等のパ フォーマンス ✅ EASE/SLIMも健闘 ✅ MSDでは、iALSはEASEに次ぐ2番目に優 れた手法 • Visinalエンジニアの記事 • GMOエンジニアの記事 • CyberAgentエンジニアの記事
30. 32 iALSの着眼点: • 接触が実際にあるユーザー・アイテムの組み合わせについては、確かにそのユーザーはアイテムに何かしら の興味があったと言える • しかし、接触がなかった組み合わせについては、必ずしも興味がなかったのではなく、ユーザーがアイテム のことを知り得なかった場合など、さまざまな事情がありえる → よって、この場合はそれほど自信を持って 𝑈𝑖 ・𝑉 𝑗 が 0 に近いとは言えない iALS (Implicit Alternating Least Squares) Revisiting iALS論文の損失関数 S. Rendel et.al., Revisiting the Performance of iALS on item Recommendation Benchmarks, Proc. RecSys’22 S. Rendel et.al., Revisiting the Performance of iALS on item Recommendation Benchmarks, Proc. RecSys’22 オリジナルとは若干異なるがこっちの方が真にimplicit
31. 確信度を利用しImplicitフィードバックをExplicit化 33 明示的な評価がない状況でも、行動の頻度から選好に対する確信度を導出し、重みとして利用 benfred/implicitはこのアプローチ iALSのオリジナル論文 Collaborative Filtering for Implicit Feedback Datasets. Proc. ICDM 2008. 「暗黙的フィードバックはbinary値、明示的フィードバックはそれ以外」といった理解は正しくないとのこと
32. 深層学習推薦システムの再現性問題 34 RecSys’19のBest Paper 「Are We Really Making Much Progress? A Worrying Analysis of Recent Neural Recommendation Approaches」の主張 • トップ会議（KDD, SIGIR, WWW, RecSys）で発表されたDNN関連の推薦シ ステム研究18本を追試 • 実装の再現に現実的な努力を行った上で再現できたのはわずか7本（39%） • 再現できた7本のうち6本が単純なkNNベースの手法+ハイパーパラメータ最適 化に性能で劣る • 残り1本も単純な線形手法（調整済み）に負ける場合 があることが判明 • 評価できるのは、Mult-VAEぐらい RecSys 2019 ベストペーパーを読んだメモ@Qiita
33. SLIM (Sparse LInear Method) 35 Ning & Karypis, SLIM: Sparse Linear Methods for Top-N Recommender Systems, Proc. ICDM 2011
34. SLIM (Sparse LInear Method) 36 アイテム間のSimilarityを重みとして学習し、評価行列を再構成 ෝ 𝑟𝑢 = 𝑟𝑢 𝑊で予測し、ユーザーがまだ評価していないアイテムを高スコア順に推薦 アイテムベースの協調フィルタリングの安定性 𝑊はスパースであることに注意 ユーザの過去のアイテムRatingが 𝑅𝑢𝑖 の予測に利用される ユーザの評価行列もスパース
35. SLIMの目的関数 37 自分自身との類似度をゼロにして自己推薦を避ける アイテム間の類似度を常に正とし解釈性を高める 最適化しやすくする 過学習を抑える スパース性を促進し、 効率的なモデルを作成 評価行列𝐴とその再構築𝐴𝑊間 の差を最小化
36. SLIMとMFの比較 39 MF SLIM URM(User Rating Matrix）を予測に用いる（ ෝ 𝑟𝑢 = 𝑟𝑢 𝑊 ）のが特徴 → 最新のフィードバックを利用できる 学習済みの潜在ベクトルの内積で予測 学習 New interaction New interaction 𝑚𝑜𝑑𝑒𝑙. 𝑓𝑖𝑡(𝑅′, 𝑟 𝑗 ) 𝑊 𝑗 = 𝑚𝑜𝑑𝑒𝑙. 𝑐𝑜𝑒𝑓_
37. SLIMの簡易疑似コード（勾配法ver） 40 userがitemにfeedbackした際に、 予測誤差をユーザが過去に接触した 他のアイテムに伝播するイメージ 全接触アイテムに誤差を伝播し てSimilarity matrixを更新する必要 は必ずしもない
38. From SLIM to Regression 41 Cordinate Descent（座標降下法）を 用いたElasticNetで高速かつ精度良く解ける from sklearn.linear_model import ElasticNet
39. fsSLIM: SLIM with Feature Selection 42 元のSLIM のobjective fsSLIM のobjective 1st NN 2nd NN 更新対象のカラム𝑎𝑗 の近傍のアイテムだけを更新
40. fsSLIM: SLIM with Feature Selection 43 更新対象のカラム𝑎𝑗 の近傍のアイテムだけを更新
41. Item-basedの協調フィルタリング(CF)との関係 44 SLIMはMatrix Completionであるが同時にItem-based CFの発展系という のがユニーク Similarity Matrix Item-based kNN CF ユーザが接触したアイテム𝑖に強く関連するtop-kアイテムを推薦
42. SLIM with Feature Selectionによって得られる性能向上 45 Ning & Karypis, SLIM: Sparse Linear Methods for Top-N Recommender Systems, Proc. ICDM 2011
43. Rtrecにおける実装上の工夫 46 https://github.com/myui/rtrec
44. SLIMの更新性能の高速化の試行錯誤 47 1. 既存のSLIM実装を調査したが密ベクトル前提であったり非効率で良いSLIM実装が ない (Recbole/DaisyRecなど) 2. 最初に実装したSGD/FTRLのPure Python版 → M2 MBPで約10,000 samples/sec以下の更新性能で 3. Rust(Py3o/maturin)で書き直し → 約30,000 samples/secまで3倍程度の高速化 → Rayonを利用したデータ並列処理で頑張るもそこから上がらず → 確率的勾配法由来の精度/収束面の課題が残った (nDCG 0.13程度) 4. 座標降下法（Coordinate Descent）とscipy/numpyで書き直し → nDCG評価での精度が向上 (nDCG 0.15以上) → 約190,000 samples/secの更新性能を達成 1. Feature Selectionを導入 → 50個の近傍に絞ることで、nDCG精度の許容範囲の低下するが、6倍程度高速化 2. Multiprocessingと共有メモリで並列処理 → 6*0.7=4.2 CPUs割り当てたcontainer上の処理で3倍程度高速化 5. Sparseデータを効率的に扱うように改変 出典論文で言及されている重要なアイデアだが研究ライブラリ(Recbole/DaisyRec等）では実装されていない
45. メモリ消費量の見積り 48 Data Scale Users Items Interactio ns Small 10K 1K 100K Medium 100K 10K 1M Large 1M 100K 10M Extra-Large 10M 1M 100M
46. ユーザ評価行列(URM)へのTime Decay(半減期)の導入 49 ユーザーの興味や好みは、時間の経過とともに変動する 「 Time weight collaborative filtering 」論文の時間の経過とともにユーザーのインタラ クションの重要度を変化させる手法を導入 → 遅延実行でユーザ評価行列の参照時にTime decayを適用 Time weight collaborative filtering (CIKM’05) Time Decay導入効果 ユーザーの最新のfeedbackをよ り強調することで、推薦内容が最新の 嗜好変化に即応 古いインタラクションが推薦に与 える影響を低減することで、興味が薄 れたアイテムが推薦されるリスクを軽 減
47. Incremental Feedbackのユーザ評価行列（URM）への反映 50 暗黙的Feedbackの入力となるURMは0/1のみで以下のようなリアルタイムのFeedbackに適さない また、Explicit FeedbackもURMが集計されていることを基本的に前提としている → URMを予測に使うSLIMの特徴を利用 → リアルタイムのフィードバックを受け付けるオンライン学習用に指定のレンジ内でURMを delta更新するような入力設計 new_value = clip_range( apply_decay(current) + delta) )
48. Rtrecにおける学習データの入力形式 51 訓練事例としてuser, item, tstamp, ratingからなるタプルを入力にとる ✅ URMの動的更新に対応 ✅ 学習時に存在しないItem, User でも問題なく動作(cold userに はhotItemを返す） ✅ Ratingには+1だけ(implicit feedback)でも可 ✅ Delta updateにしない上書きモ ードもあり ✅ DataFrameのHigh Level API や効率的なBulk fit APIも提供
49. Cold Start問題とコンテキストへの対応 52 コンテキスト特徴とは、ユーザーやアイテムに 関する追加情報や状況データ コールドスタート問題を解決するための重要な 手がかり コンテキスト特徴
50. Cold Start問題とコンテキストへの対応 53 LightFM(MF+WARP)をベースに差分更新をサポート+コンテキスト対応 Source) 図はRectoolsのLightFMの説明より抜粋 LightFMはFMとついているが、MFに細工してFM化している 1. User Identity Matrixとユーザ特徴列と連結 2. MFで学習されたUser embeddingと内積をとる → 各列がユーザの潜在特徴ベクトルとなる 3. 同様にアイテムの潜在特徴ベクトルを得る 4. MF同様にユーザとアイテムの潜在ベクトルで内積で予測
51. 本日のまとめ 54 https://github.com/myui/rtrec Feedback歓迎です。興味ある方 は使ってみて下さい SLIMとContext特徴をサポートしたFMをサポートするOSSのリアルタ イム推薦ライブラリを紹介 iALS (Implcit)、FM (LightFM）に加わる選択肢を提供 評価データと訓練データを時間で分割するとSLIMはiALSを凌いだ りするのでSLIMもいい選択肢 オンラインのモデル更新をサポート 興味の減衰を考慮 コンテキスト特徴もFMでは使える