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

No content

No content

今日は、音声レコメンドと その実装方法について検証している内容を お話しします！ 

計算手法 言葉で言うと、 長所 短所 コンテンツベース これを聴いているあなたに は●●がオススメ 利用者の情報がなくても、 入力できる。 意外性が無いものが出 る。 協調フィルタリング あなたと似ている人は ●● を聴いています 意外性のあるアイテムが 表示される場合がある (多 様性) 利用者の情報が少ないう ちはワークしない。 少数者のアイテムはオス スメされない。 ハイブリッド型 これを聴いているあなたに は●●がオススメだけど、 似ている人は▲▲だか ら、●▲にしよう。 良いところどり 実装の複雑性が増す レコメンド実装3つの分類 最強! 

バッチ処理型の課題 → 計算量の増加による遅延 モデルA モデルB フィルタ 最終的なリスト 計算に1Hかかる 計算に1Hかかる “今”を捉えていないリストが完成 ステーキが好きだからと言って、四六時中ステーキ食べたいわけ では無いですよねえ (例)協調フィルタリングの場合は、 ユーザー数 x(ユーザー数 -1)の計算量が必要に ...。 

Voicyに当てはめると.... リスナーAさん サウザー完聴済み が、高木えみさんを5つ連続で聴いたケース バッチ処理から生まれるリスト → 一般的な特性から生まれたリスト バッチ + ストリーム処理から生まれるリスト → Nowのムードを反映したリスト ゴッホの放送 加藤ひろゆきの放送 サウザーの過去放送 ゴッホの放送 高木えみの放送 marikoの放送 

そこでグラフデータベース が登場 クエリの実行速度が早い 実装が簡単 リアルタイムレコメンド がメインのユースケース 

Q1: って何やねん? A1: “ノード”と”エッジ”と”プロパティ”で、 現実世界を抽象化したデータベース。RDBと比べて、クエリが圧倒的 に高速 & モデリングが簡単&スキーマレスなどの特徴を持つ。 Pythonから触れるクライアントがあるよ(大事) 

現実: リスナー「Voicy太郎」さんが、「支援家K」さんを「100分」聞きました モデリング: Label: Listener Label:Speaker name: Voicy太郎 gender: 1 name: 支援家K Label: LISTENED total_play_minutes: 100 ノード ノード エッジ 

Neo4jで表現するとこんな感じ.... (現実世界) リスナー”Masaki Sato”さんが、支援家Kさんを累計690分、放送を6個聞きました。 (モデリング結果) ノード - Listenerラベル - genderとnameをプロパティに持つ リレーション - LISTENED リレーション - total_play_minutesとtotal_play_playlistsをプロパティに持つ 

Neo4jで表現するとこんな感じ.... (現実世界) ”支援家K”さんがたくさん放送しているよ！ (モデリング結果) ノード - Speakerラベル - publishedとnameをプロパティに持つ ノード - Playlistラベル - total_play_minutesとnameをプロパティに持つ 

Q2: 実際のサービスではどう使えるの? A2: クエリ実行速度が非常に高速なので、ニアリアルタイムで おすすめリストを生成できる 

- 音喜多俊さんを聴いているリスナーが、最も良く聴いているパーソナリティのリストを作成せよ 実際に協調フィルタリングを試してみた(1) Cypherクエリ 実行結果 

- 音喜多俊さんを聴いているリスナーが、最も長く再生しているパーソナリティのリストを作成せよ 実際に協調フィルタリングを試してみた(2) Cypherクエリ 実行結果 

バッチxリアルタイムで ムードに合わせたレコメンデーションを志向 バッチ集計 (コンテンツベース) リアルタイム (協調フィルタリング) ↑ここのフィルタにどこまで情報を組み込めるかが大事 - 好きでないものは出ないようにする - 好きなPの傾向を反映する..etc フィルタ 最終的なリスト などの即時計算が可能な機構 

No content

“Voicy テックブログ”で検索すると、テックブログが現れます！