Slide 1
Slide 1 text
Copyright © LIMIA, Inc. All Rights Reserved.
BigQueryを使った機械学習
プロジェクトの分析とオフライン
検証
LIMIA推薦システム事例発表
Slide 2
Slide 2 text
Copyright © LIMIA, Inc. All Rights Reserved.
● グリーグループのリミア株式会社で、LIMIA という住まい領域のメディア
を作っています。ゲーム会社ですが、最近はメディアに力を入れていま
す。
● 機械学習(RecSys)のエンジニアですが、iOS, Android,JSなどもやってい
る何でも屋です。5歳の娘のパパ。twitter: @mahiguch1
● 部活動でグリー技術書典部を作り技術書典7参加、8に参加予定。
● https://limia.jp/
● https://arine.jp/
● https://aumo.jp/
● https://www.mine-3m.com/mine/
Masahiro Higuchi/樋口雅拓
2
Slide 3
Slide 3 text
Copyright © LIMIA, Inc. All Rights Reserved.
LIMIAとは?
3
● メディアサービス
● Android, iOS, Web
● 記事一覧を表示し、タップすると
記事詳細を閲覧できる。
● 記事一覧はパーソナライズ。
● 記事詳細読了後に関連記事を出
している。
● PHP→ Go移行中
● 分析基盤はBigQuery
Slide 4
Slide 4 text
Copyright © LIMIA, Inc. All Rights Reserved.
LIMIAでは、より良いユーザ体験を提供するため、ユーザ毎に最適な一覧表示
を行なっています。
【発表内容】
それを実現するため、1.分析、2.オフライン検証、3.配信、4.オンライン検証、
5.レポートのシステムを構築しました。
まず、0.推薦システムについて説明し、次に上記5システムについて説明しま
す。最後に6.今後の課題について話します。
【発表のモチベーション】
知識を共有することで、機械学習基盤を効率的に構築したい！
発展途上の分野で定石がないので、お気付きの点があれば教えて欲しい。
概要
4
Slide 5
Slide 5 text
Copyright © LIMIA, Inc. All Rights Reserved.
0.推薦システムとは
概要説明
Slide 6
Slide 6 text
Copyright © LIMIA, Inc. All Rights Reserved.
推薦システムを作るのは難しい。
理想的には、以下の専門家が必要。
● Analyst: データを分析して課題を発見
● Data Scientist: Model作成
● Algorithm Programer: 本番コード実装
● ML Ops: インフラを作る
● Researcher: 使えそうな論文を見つけて共有
→ この章では、それぞれの専門家がどんな環境で、何を目指して作業している
か説明します。
プロジェクトの構成
6
Slide 7
Slide 7 text
Copyright © LIMIA, Inc. All Rights Reserved.
以下の目的のため、データを分析する。
● ユーザ体験向上
● 取引先企業の課題解決
課題を解決するため、施策立案と施策評価を行う。
昭和の言い方だと、上流工程?
機械学習が使えそうな課題があれば、DSに相談する。
→ LIMIAではProductManager(PM)が担当。BigQueryとSpreadSheet
を使って作業している。
Analyst
7
Slide 8
Slide 8 text
Copyright © LIMIA, Inc. All Rights Reserved.
Analystから提案された課題の解決方法を提案する。
Researcherと相談して、使えそうな理論を選び、手元の開発環境でモデルを作
る。作ったモデルをAlgorithm Programmerに渡してサービスに組み込んでも
らう。Kagglerが多い。
推薦システムは、次の4つの要素から構成される。※1
● Item Modeling(Itemをvector化)
● User Modeling(Userをvector化)
● Scoring(それらを使ってscoreを作り)
● Ranking(1つ以上のscoreを使って並べ替え)
それぞれで使える手法を選んで実装し、オフライン検証を行う。良い結果が出た
ら、Algorithm Programmerに渡す。
→ LIMIAではAPが担当。Jupiter/Python/BigQueryを使う。
Data Scientist
8
Slide 9
Slide 9 text
Copyright © LIMIA, Inc. All Rights Reserved.
Data Scientistが作ったモデルを使って、本番サービスで動くコードを書く。動
作速度が問題となることが多いので、競技プログラミング
(atcorder/topcorder)組が多い。
実装して本番反映し、オンライン(A/B)検証を行い、結果が良ければ全ユーザ
へ適用する。
→ LIMIAではAPとML Ops(発表者)が担当。golangで実装して本番デプロ
イして、オンライン検証結果を確認する。
Algorithm Programmer
9
Slide 10
Slide 10 text
Copyright © LIMIA, Inc. All Rights Reserved.
Algorithm Programmerと相談して、最適なインフラを作る。学習と言われ
るバッチ処理は非常に重い。推論と言われるオンライン処理は、小さい
latencyが求められる。また、自動最適化を行うため、ログの収集が非常に重
要！
→ LIMIAではML Ops(発表者)が担当。各種ログをBigQueryに収集してい
る。vscodeでCloudFormationテンプレートを書いている。
ML Ops
10
Slide 11
Slide 11 text
Copyright © LIMIA, Inc. All Rights Reserved.
研究を行いKDD/RecSys/WWWなどでの発表を目指す。DS/AP/MOなどか
ら相談を受け、使えそうな手法を提案する。また、因果推論によるオフライン評
価、マルチタスクなど、最新の論文で使えそうな手法を提案してくれる。
→ LIMIAでは明確な担当者不在。AP, MOとGREEのResearcherで論文輪
読会を開いてカバーしている。
Researcher
11
Slide 12
Slide 12 text
Copyright © LIMIA, Inc. All Rights Reserved.
1.分析
Analystが使うシステム
Slide 13
Slide 13 text
Copyright © LIMIA, Inc. All Rights Reserved.
分析するためには、ログを収集する必要があります。
LIMIAではBigQueryにログを集約しました。
そこで、BigQueryへのログの収集方法を解説し、それを誰がどのように利用
しているのかを説明します。
分析システムについて
Analystの領域
13
Slide 14
Slide 14 text
Copyright © LIMIA, Inc. All Rights Reserved.
Firebase管理画面でボタンを押すだけでBigQueryにデータが連携される。
連携されるデータは、次のもの。
● Analytics: 送信した全てのイベント
● Crashlytics: 発生した例外の情報
● Predictions: 予測結果
● FCM: プッシュ通知送受信ログ
● Performance: 送信したトレース情報
Analytics以外のBigQueryデータは使いこなせていない。良い使い道があれ
ば教えて欲しい。
イベントログ
Firebase
14
Slide 15
Slide 15 text
Copyright © LIMIA, Inc. All Rights Reserved.
Embulkを使ってBigQueryへ転送している。Embulkコンテナを作り、ECS
Fargateで回している。以下に要点だけ示す。
● ALB: daily table(xxlog_20190828)に前日分を転送
● CloudFront: ファイル名で前日分を特定できないので、手元に最終更新
日時指定でs3 syncしてから転送。
● RDS: 負荷を考慮して1テーブルずつ転送。daily tableを切らずに上書
きしていく。履歴は残らないが、MySQLと同じqueryが使える。
● Dynamo: 構造化データはjson文字列として格納。
GCP service accountは、EKSで暗号化したファイルをcontainerに含めて
いる。embulkはfargateのExecRoleを見てくれないので、AWS IAM user
を環境変数で渡している。
AWSのデータ
ALBとCloudFrontのアクセスログ/RDSとDynamoのデータ
15
Slide 16
Slide 16 text
Copyright © LIMIA, Inc. All Rights Reserved.
● Search Console: golangバッチでAPIから取得し、BigQueryへ転送。
ECS fargate taskで毎晩実行。
● Google Analytics: 集計パターンをいくつか作り、それぞれをBigQuery
の対象テーブルへ転送。実行環境はSCと同じ。
● Adjust: Cloud FunctionsにEndpointを作り、来たデータを全て
BigQueryに格納。AdjustのGlobal Callbackに設定。
● Kintone: 一部業務の管理ツールとしてKintoneが使われていたため、
Kintone APIをGASで叩いてBigQueryへ。
その他のログ
SearchConsole/GoogleAnalytics/Adjust
16
Slide 17
Slide 17 text
Copyright © LIMIA, Inc. All Rights Reserved.
原則データの確認はRDS/Dynamo等は使わず、BigQueryにある早朝に
取ったスナップショットに対して行う。BigQuery画面からが多く、DSは
Jupiter+pandasから。
● Analyst: 施策立案のための状況把握。施策の想定効果見積もりと効果
測定。KPI変化の要因分析。
● Data Scientist: パーソナライズを行うため、ユーザやアイテムの特徴を
分析。オフライン検証。
● Algorithm Programmer: オンライン検証結果確認。
● ML Ops: エラーログ、動作速度、機能の利用状況などでシステムの健全
性を分析。
誰が何を分析しているのか
仮説を立てて定量的に検証する
17
Slide 18
Slide 18 text
Copyright © LIMIA, Inc. All Rights Reserved.
LTVを上げるには回遊性向上が効果的。
アプリを起動してコンテンツを閲覧せずに離脱しているユーザが多数存在する
ことが分かった。
そこで、起動直後に表示されるピックアップ面の一覧表示をパーソナライズする
ことで回遊性を向上させられないか。
今回のプロジェクトでは
Analyst分析結果
18
Slide 19
Slide 19 text
Copyright © LIMIA, Inc. All Rights Reserved.
2.オフライン検証
Data Scientistが使うシステム
Slide 20
Slide 20 text
Copyright © LIMIA, Inc. All Rights Reserved.
Data Scientistが過去のデータを
使って、モデルの良し悪しを検証する。
良いモデルができたら、APにJupiter
Notebookを渡す。
→ LIMIAではgistにnotebookを貼
り付けて連携。
左図はGoogle Colaboratoryという
インストールなしで使えるJupiter
Notebookのようなもの。
https://colab.research.google.com/?hl=ja
オフライン検証とは？
Data Scientistの領域
20
Slide 21
Slide 21 text
Copyright © LIMIA, Inc. All Rights Reserved.
例えば、
● 14-8日前のデータを使って学習。ユーザ毎に推薦リストを作成。
● 7-1日前に閲覧されたItemが推薦リストの中に含まれている割合で評
価。
最近では因果推論を使った検証が流行中。
→ LIMIAではMAPとnDCGで評価。
検証方法
21
Slide 22
Slide 22 text
Copyright © LIMIA, Inc. All Rights Reserved.
オフライン検証のベースラインとして、人気のあるコンテンツを全員に配信した
ときを想定する。
Cell/Itemを表示したらFirebase Analyticsにimpression eventを送信
し、Clickしたらclick eventを送信してBigQueryに格納する。イベント数で割
り算したCTRを人気記事の定義とした。
→ LIMIAではCTRがこれを上回ったら、オンライン検証に移行。
合格ラインは？
Popular Model
22
Slide 23
Slide 23 text
Copyright © LIMIA, Inc. All Rights Reserved.
● Item Modeling: 記事を形態素解析して名詞を取り出し、それをword
embeddingしたvectorの平均を取った。
● User Modeling: ユーザが読んだ直近30件のItemのvectorの平均を
取った。
● Scoring: ItemとUserの距離。
● Ranking: Scoreの大きい順に並べた。
全Itemとの距離を計算すると重いので、10個に分類して中心点との距離を距
離を計算することにした。クラスタ内での並び順は、CTR順。
チャレンジし過ぎてRecSys2019のベストペーパーに指摘されるような事態は避けたい。
オフライン検証を通過したモデル
教科書に書いてある事を愚直に
23
Slide 24
Slide 24 text
Copyright © LIMIA, Inc. All Rights Reserved.
RecSysは推薦分野の有名な国際学
会。
4つの有名な国際学会に発表された
深層学習を使った推薦のコードを確認
したら、ほとんど動かなかったらしい。
それを発表して最優秀論文に選ばれ
ていた。
自分で出すときは、気を付けたい！
こぼれ話
RecSys2019 Best Paper※2とは?
24
Slide 25
Slide 25 text
Copyright © LIMIA, Inc. All Rights Reserved.
3.配信
Algorithm Programmerが使うシステム
Slide 26
Slide 26 text
Copyright © LIMIA, Inc. All Rights Reserved.
DSから受け取ったNotebookは、以下のようになっていました。
● 学習: バッチでItemとUserをベクトル化しておきます。
● 推論: ユーザが一覧表示をリクエストすると、それらを使って一覧表示を作
ります。
これを受けて、次のようなシステムを構築しました。
● 学習: Item/Userの更新通知を既にKinesisに流していたため、これを受
け取って処理するLambdaを追加しました。
● 推論: APIをgolangで作っているため、そこに処理を追加しました。
システム概要
ここはAWSです！ すいません。m(_ _)m
26
Slide 27
Slide 27 text
Copyright © LIMIA, Inc. All Rights Reserved.
記事が更新されると、
SQSに通知されます。そ
れをLambdaで読み込ん
で、単語に分割し、単語を
vectorにします。記事に
含まれる単語の平均を記
事のvectorとします。ただ
し頻出単語の影響緩和の
ため、IDFで補正します。
アイテムベクトル作成
27
Slide 28
Slide 28 text
Copyright © LIMIA, Inc. All Rights Reserved.
ユーザが記事を閲覧すると、その情報がKinesisに流れます。
Lambdaで受け取り、直近30件の閲覧履歴をDynamoDBに保存
します。その変更をDynamoDB Streamに流し、Lambdaで受け
取って記事のベクトルの平均をユーザベクトルとしてDynamoDBに
書き込みます。
ユーザベクトル作成
28
Slide 29
Slide 29 text
Copyright © LIMIA, Inc. All Rights Reserved.
ItemとUserの距離を計算し、近い物を出す。
ただし、全記事との距離をリアルタイムに計算
すると遅いので、分類して中心点との距離を計
算することにした。クラスタ内での順位はCTR
を使った。
記事の推薦
29
Slide 30
Slide 30 text
Copyright © LIMIA, Inc. All Rights Reserved.
4.オンライン検証
Slide 31
Slide 31 text
Copyright © LIMIA, Inc. All Rights Reserved.
まず最初にFirebase A/B Testingを使ってオンライン検証を
行った。
この方法は楽だが厳密性に欠けるため、独自システムを開発し
た。
→ ここでは、両方について説明します。
オンライン検証方法
Firebase A/B Testingと独自システム
31
Slide 32
Slide 32 text
Copyright © LIMIA, Inc. All Rights Reserved.
● RemoteConfigはKey-Valueスト
ア。
● PCブラウザから設定できるので、企
画側で対応可能。
● Firebase A/B Testingでは、直接
的には指定したRemoteConfig key
の値が変更される。
● そこでデータを取得するAPI毎に
RemoteConfig keyを作成する。
Firebase A/B Testingを使った手法(1)
Firebase RemoteConfig設定
32
Slide 33
Slide 33 text
Copyright © LIMIA, Inc. All Rights Reserved.
defaultはリソースファイルに保持しておき、RemoteConfigから非同期に値を取得しま
す。
Firebase A/B Testingを使った手法(2)
Firebase RemoteConfigからのデータ取得
33
Slide 34
Slide 34 text
Copyright © LIMIA, Inc. All Rights Reserved.
QueryStringにRemoteconfigから取得したパラメータを追加します。
サーバ側では、そのパラメータを使って処理を分けます。
Firebase A/B Testingを使った手法(3)
HTTPリクエストのQueryStringに追加
34
Slide 35
Slide 35 text
Copyright © LIMIA, Inc. All Rights Reserved.
● ユーザグループA
とBに送られる
RemoteConfig
の値を設定しま
す。
● PCブラウザから設
定できるので、企
画側で対応可能。
Firebase A/B Testingを使った手法(4)
Firebase A/B Testing設定
35
Slide 36
Slide 36 text
Copyright © LIMIA, Inc. All Rights Reserved.
PCブラウザから結果を確認
できる。
設定から結果確認までPCブ
ラウザで出来るので、エンジ
ニアが開発に集中できる！
Firebase A/B Testingを使った手法(5)
テスト結果
36
Slide 37
Slide 37 text
Copyright © LIMIA, Inc. All Rights Reserved.
RemoteConfigは非同期で情報を取得する。そのため、初回アクセス時に
は、A/B振り分けられた値が取得されていないケースが多い。
ここが厳密性に欠けるとの指摘を受けたため、独自実装のシステムを作った。
独自実装の方は、userIdの下二桁で分岐するやり方。
独自システムについて
37
Slide 38
Slide 38 text
Copyright © LIMIA, Inc. All Rights Reserved.
5.レポート
Slide 39
Slide 39 text
Copyright © LIMIA, Inc. All Rights Reserved.
【Firebase A/B Testing手法】
A/Bテストでどちらのセグメントに振り分
けられたか、UserPropertyに設定されま
す。keyは次のようになります。
firebase_exp_
【独自実装】
FAにsetUserId()という足が生えているの
で、それで設定するとUserPropertyの
user_idに設定されている。
パターン毎の集計方法
Firebase A/B Testingと独自実装
39
Slide 40
Slide 40 text
Copyright © LIMIA, Inc. All Rights Reserved.
6.今後の課題
Slide 41
Slide 41 text
Copyright © LIMIA, Inc. All Rights Reserved.
● LTVと相関が強い指標を探す。特にRetentionを上げる方法。
● ピックアップ以外でパーソナライズしたい場所があれば。他タブ、回遊導
線、プッシュ通知、検索結果など。
● BigQueryのqueryを実装するより早く分析する方法。GAのWeb+App
の分析機能???
今後の課題
Analyst領域
41
Slide 42
Slide 42 text
Copyright © LIMIA, Inc. All Rights Reserved.
● ItemModel: word embedding(学習データにLIMIAの記事を加える。
最新のWE手法を使う。
● ItemModel: 形態素解析の辞書をチューニング。user辞書にLIMIA記
事。neologd利用。
● UserModel: 平均 vs RNN(読んだ順序を考慮するか)
● Scoring: 協調フィルタリングのScoreを作って既存に加える
● Ranking: アドテクを参考にFrequency Capをかけて、興味のない記事
を掲載されずらくする
● Kaggleを頑張る
今後の課題
Data Scientist領域
42
Slide 43
Slide 43 text
Copyright © LIMIA, Inc. All Rights Reserved.
● UnitTestがほとんど無いので書く
● Data ScientistからPythonのコードが来るのに書き換えるべき?
● atcorder頑張る
今後の課題
Algorithm Programmer領域
43
Slide 44
Slide 44 text
Copyright © LIMIA, Inc. All Rights Reserved.
● エラーログ周りをなんとかする
● micro serviceとして切り出して他prjへ提供
● k8s(GKE)対応
今後の課題
ML Ops領域
44
Slide 45
Slide 45 text
Copyright © LIMIA, Inc. All Rights Reserved.
● 論文輪読を繰り返して、最新に追いつく。
● 論文を書いて発表する。
今後の課題
Researcher領域
45
Slide 46
Slide 46 text
Copyright © LIMIA, Inc. All Rights Reserved.
まとめ
Slide 47
Slide 47 text
Copyright © LIMIA, Inc. All Rights Reserved.
● ユーザ体験向上のため、一覧表示のパーソナライズを行った。
● この構成が良いと思っていないので、お気付きの点があれば指摘して欲し
い。歴史が浅い分野なので、情報を共有して僕らで定石を作っていきた
い。
● 機械学習prjは、様々な専門性を持つ人達を結集する必要がある。しかし
仲間が少なく、一人で複数の専門性を見ているので成長が遅い。
まとめ
47
Slide 48
Slide 48 text
Copyright © LIMIA, Inc. All Rights Reserved.
一緒に推薦システムを作ってくれる仲間を募集中です。
● Analyst
● Data Scientist
● Algorithm Programmer
● ML Ops
● Researcher
興味がある方は声をかけてください！
We are hiring!
48
Slide 49
Slide 49 text
Copyright © LIMIA, Inc. All Rights Reserved.
Appendix
Slide 50
Slide 50 text
Copyright © LIMIA, Inc. All Rights Reserved.
● 1: 書籍:推薦システム https://www.kyoritsu-pub.co.jp/bookdetail/9784320124301
● 2: Are We Really Making Much Progress? A Worrying
Analysis of Recent Neural Recommendation Approaches
https://arxiv.org/pdf/1907.06902.pdf
●
参考資料
資料中の※は、以下の資料を表す。
50
Slide 51
Slide 51 text
Copyright © LIMIA, Inc. All Rights Reserved.
類似ユーザに人気の記事を配信することで、CTRが上がるという仮説を検証し
た。
ユーザをいくつかのクラスタに分類する。
分類結果をBigQueryに送信し、クラスタ毎のCTRを集計する。
定期的に集計してストレージに格納しておき、ユーザは所属するクラスタ内で
CTRが高い記事を一覧表示する。
これをPopular Modelとオフラインで比較して、既存手法とオンラインで比較し
た。
失敗した手法
Segmentation Popular Model
51
Slide 52
Slide 52 text
Copyright © LIMIA, Inc. All Rights Reserved.
LIMIAにはtwitterのようにユーザをフォローする機能がある。フォロー数が多
いほど来訪頻度が高いことが分かっている。興味のあるユーザを推薦すること
でフォロー数が増えるという仮説を検証した。
BigQueryにあるフォロー情報を使ってUser x Userの行列を作る。
コサイン距離を計算するUDFを作り、類似ユーザを抽出した。自分がフォロー
している人の類似ユーザや類似ユーザがフォローしていて自分がしていない人
を推薦した。
その他の推薦
UDFを使った協調フィルタリング
52