ML@Loft #3の資料。 ニュースサービスのパーソナライズを支える仕組みと課題について紹介

1. 2019/06/21 ML@Loft
株式会社 Gunosy
Gunosyにおけるパーソナライズシステム

2. （C） Gunosy Inc. All Rights Reserved. PAGE |2
自己紹介
● 小澤俊介（こざわしゅんすけ）
○ skozawa (twitter: @5kozawa)
○ 博士（情報科学）
● Gunosy データ分析部
○ データ分析、ロジック開発全般
● 大学時代は自然言語処理の研究に従事

3. （C） Gunosy Inc. All Rights Reserved. PAGE |3
株式会社Gunosy
「情報を世界中の人に最適に届ける」
● 情報キュレーションサービスの開発
○ グノシー
○ ニュースパス
○ LUCRA（ルクラ）
○ オトクル
● データ分析部
○ 記事配信アルゴリズムの改善
○ ユーザ行動分析

4. （C） Gunosy Inc. All Rights Reserved. PAGE |4
ニュース推薦の特徴
● 更新性の高さ
○ 数千記事 / 日
○ ユーザの興味サイクルが早い
● 価値が時間減衰
○ 時間が経つにつれて価値は低下
● 既存アルゴリズムを単純適用できない

5. （C） Gunosy Inc. All Rights Reserved. PAGE |5
ニュース推薦の要求仕様
● 興味を捉えられる
○ 話題は変化する
● リアルタイム性
○ 数時間に1度のバッチ計算では間に合わない
● 時間を考慮できる
分散表現を利用し、ベクトル空間上で興味を表現
できる限りリアルタイムにスコアリング
ニュースの価値、ユーザとの接触を考慮

6. （C） Gunosy Inc. All Rights Reserved. PAGE |6
システムアーキテクチャ

7. （C） Gunosy Inc. All Rights Reserved. PAGE |7
システムアーキテクチャ
スコアリングデータ生成
推薦API
記事、ユーザベクトルの更新

8. （C） Gunosy Inc. All Rights Reserved. PAGE |8
システムアーキテクチャ
記事、ユーザベクトルの更新

9. （C） Gunosy Inc. All Rights Reserved. PAGE |9
アイテムベクトルとユーザベクトルの更新
記事ベクトルとユーザベクトルをリアルタイムに更新

10. （C） Gunosy Inc. All Rights Reserved. PAGE |10
アイテムベクトルとユーザベクトルの更新
記事ベクトルとユーザベクトルをリアルタイムに更新
記事ベクトルの更新
ユーザベクトルの更新

11. （C） Gunosy Inc. All Rights Reserved. PAGE |11
アイテムベクトルとユーザベクトルの更新
記事ベクトルとユーザベクトルをリアルタイムに更新
記事ベクトルの更新
Crawlerが新着記事を取得
ArticleVectorizerがベクトル生成し、dynamoに書き込む

12. （C） Gunosy Inc. All Rights Reserved. PAGE |12
アイテムベクトルとユーザベクトルの更新
記事ベクトルとユーザベクトルをリアルタイムに更新
ユーザベクトルの更新
ユーザのクリックをトリガーに、クリックした記事IDをDynamoDBに保存
DynamoDBへの書き込みをトリガーにラムダを発火
ラムダで記事ベクトルを取得、ユーザベクトル生成して保存

13. （C） Gunosy Inc. All Rights Reserved. PAGE |13
システムアーキテクチャ
スコアリングデータ生成

14. （C） Gunosy Inc. All Rights Reserved. PAGE |14
スコアリング
ユーザの興味関心に応じたスコアリング
時間減衰
ユーザの興味に応じたスコア
興味ベクトルとユーザベクトルの距
離に応じて重み付け
パーソナライズスコア

15. （C） Gunosy Inc. All Rights Reserved. PAGE |15
時間減衰
● ニュースの価値
○ 時間が経つにつれて減衰する
○ 1度見たニュースはもう見られない
■ リスト面にだすのはできれば1度だけにしたい
■ ユーザごとの全インプレッションを保存し、リアルタイムに処理するのは難し
い
● 時間減衰関数を用意
○ 記事配信日から時間が経つにつれスコア減衰
○ ユーザの前回リクエスト時間によってスコア減衰
イメージ

16. （C） Gunosy Inc. All Rights Reserved. PAGE |16
システムアーキテクチャ
推薦API

17. （C） Gunosy Inc. All Rights Reserved. PAGE |17
推薦API（リスト表示）
● ユーザのリクエストごとにスコアリング
○ 50msec or die
○ 行列演算のみ
■ データのI/Oは極力なくす
■ プロセスキャッシュ
リクエスト
ユーザベクトル取
得
スコアリング 記事リスト生成
興味ベクトル
記事スコア
backgroundで定期的に

18. （C） Gunosy Inc. All Rights Reserved. PAGE |18
推薦システム運用の課題
● 動作検証
○ 開発環境だとデータ数が少ない
○ パーソナライズされているのでリスト面の検証が困難
● 分散表現のモデル更新
○ 分散表現を更新したい場合、システム全体の更新が必要
● Spark / EMR / presto 運用
○ たまに終わらない
○ prestoは立て直しが必要

19. （C） Gunosy Inc. All Rights Reserved. PAGE |19
推薦アルゴリズムの課題
● コールドスタート問題
○ 0 クリック時の推薦
○ インプレッションの評価
● オフライン実験
○ パラメータ調整などをA/Bテストでするのは難しい
○ オンライン実験と必ずしも一致しない
■ Offline Evaluation to Make Decisions About Playlist Recommendation
Algorithms, WSDM2019
● 遷移 / 時系列の扱い
○ 点（クリック）での推薦になりがち、線での推薦もしたい
○ データの持ち方など実運用には工夫が必要

20. （C） Gunosy Inc. All Rights Reserved. PAGE |20
まとめ
● ニュース推薦の特徴
● リアルタイム性の高いシステム構成
● ユーザの興味とニュース価値の時間減衰を考慮したスコ
アリング
● 推薦システムの課題

21. 情報を世界中の人に最適に届ける