(多分)あなたの知らないグラフデータベースの世界

Transcript

1. あなたの知らない グラフデータベースの世界
4. 今日は、音声レコメンドと その実装方法について検証している内容を お話しします！
5. 計算手法 言葉で言うと、 長所 短所 コンテンツベース これを聴いているあなたに は••がオススメ 利用者の情報がなくても、 入力できる。 意外性が無いものが出 る。 協調フィルタリング あなたと似ている人は •• を聴いています 意外性のあるアイテムが 表示される場合がある (多 様性) 利用者の情報が少ないう ちはワークしない。 少数者のアイテムはオス スメされない。 ハイブリッド型 これを聴いているあなたに は••がオススメだけど、 似ている人は▲▲だか ら、•▲にしよう。 良いところどり 実装の複雑性が増す レコメンド実装3つの分類 最強!
6. バッチ処理型の課題 → 計算量の増加による遅延 モデルA モデルB フィルタ 最終的なリスト 計算に1Hかかる 計算に1Hかかる “今”を捉えていないリストが完成 ステーキが好きだからと言って、四六時中ステーキ食べたいわけ では無いですよねえ (例)協調フィルタリングの場合は、 ユーザー数 x(ユーザー数 -1)の計算量が必要に ...。
7. Voicyに当てはめると.... リスナーAさん サウザー完聴済み が、高木えみさんを5つ連続で聴いたケース バッチ処理から生まれるリスト → 一般的な特性から生まれたリスト バッチ + ストリーム処理から生まれるリスト → Nowのムードを反映したリスト ゴッホの放送 加藤ひろゆきの放送 サウザーの過去放送 ゴッホの放送 高木えみの放送 marikoの放送
8. そこでグラフデータベース が登場 クエリの実行速度が早い 実装が簡単 リアルタイムレコメンド がメインのユースケース
9. Q1: って何やねん? A1: “ノード”と”エッジ”と”プロパティ”で、 現実世界を抽象化したデータベース。RDBと比べて、クエリが圧倒的 に高速 & モデリングが簡単&スキーマレスなどの特徴を持つ。 Pythonから触れるクライアントがあるよ(大事)
10. 現実: リスナー「Voicy太郎」さんが、「支援家K」さんを「100分」聞きました モデリング: Label: Listener Label:Speaker name: Voicy太郎 gender: 1 name: 支援家K Label: LISTENED total_play_minutes: 100 ノード ノード エッジ
11. Neo4jで表現するとこんな感じ.... (現実世界) リスナー”Masaki Sato”さんが、支援家Kさんを累計690分、放送を6個聞きました。 (モデリング結果) ノード - Listenerラベル - genderとnameをプロパティに持つ リレーション - LISTENED リレーション - total_play_minutesとtotal_play_playlistsをプロパティに持つ
12. Neo4jで表現するとこんな感じ.... (現実世界) ”支援家K”さんがたくさん放送しているよ！ (モデリング結果) ノード - Speakerラベル - publishedとnameをプロパティに持つ ノード - Playlistラベル - total_play_minutesとnameをプロパティに持つ
13. Q2: 実際のサービスではどう使えるの? A2: クエリ実行速度が非常に高速なので、ニアリアルタイムで おすすめリストを生成できる
14. - 音喜多俊さんを聴いているリスナーが、最も良く聴いているパーソナリティのリストを作成せよ 実際に協調フィルタリングを試してみた(1) Cypherクエリ 実行結果
15. - 音喜多俊さんを聴いているリスナーが、最も長く再生しているパーソナリティのリストを作成せよ 実際に協調フィルタリングを試してみた(2) Cypherクエリ 実行結果
16. バッチxリアルタイムで ムードに合わせたレコメンデーションを志向 バッチ集計 (コンテンツベース) リアルタイム (協調フィルタリング) ↑ここのフィルタにどこまで情報を組み込めるかが大事 - 好きでないものは出ないようにする - 好きなPの傾向を反映する..etc フィルタ 最終的なリスト などの即時計算が可能な機構
18. “Voicy テックブログ”で検索すると、テックブログが現れます！