BigQueryを使った機械学習プロジェクトの分析とオフライン検証

Copyright © LIMIA, Inc. All Rights Reserved.
BigQueryを使った機械学習
プロジェクトの分析とオフライン
検証
LIMIA推薦システム事例発表

View Slide

● グリーグループのリミア株式会社で、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

View Slide

LIMIAとは?
3
● メディアサービス
● Android, iOS, Web
● 記事一覧を表示し、タップすると
記事詳細を閲覧できる。
● 記事一覧はパーソナライズ。
● 記事詳細読了後に関連記事を出
している。
● PHP→ Go移行中
● 分析基盤はBigQuery

View Slide

LIMIAでは、より良いユーザ体験を提供するため、ユーザ毎に最適な一覧表示
を行なっています。
【発表内容】
それを実現するため、1.分析、2.オフライン検証、3.配信、4.オンライン検証、
5.レポートのシステムを構築しました。
まず、0.推薦システムについて説明し、次に上記5システムについて説明しま
す。最後に6.今後の課題について話します。
【発表のモチベーション】
知識を共有することで、機械学習基盤を効率的に構築したい！
発展途上の分野で定石がないので、お気付きの点があれば教えて欲しい。
概要
4

View Slide

0.推薦システムとは
概要説明

View Slide

推薦システムを作るのは難しい。
理想的には、以下の専門家が必要。
● Analyst: データを分析して課題を発見
● Data Scientist: Model作成
● Algorithm Programer: 本番コード実装
● ML Ops: インフラを作る
● Researcher: 使えそうな論文を見つけて共有
→ この章では、それぞれの専門家がどんな環境で、何を目指して作業している
か説明します。
プロジェクトの構成
6

View Slide

以下の目的のため、データを分析する。
● ユーザ体験向上
● 取引先企業の課題解決
課題を解決するため、施策立案と施策評価を行う。
昭和の言い方だと、上流工程?
機械学習が使えそうな課題があれば、DSに相談する。
→ LIMIAではProductManager(PM)が担当。BigQueryとSpreadSheet
を使って作業している。
Analyst
7

View Slide

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

View Slide

Data Scientistが作ったモデルを使って、本番サービスで動くコードを書く。動
作速度が問題となることが多いので、競技プログラミング
(atcorder/topcorder)組が多い。
実装して本番反映し、オンライン(A/B)検証を行い、結果が良ければ全ユーザ
へ適用する。
→ LIMIAではAPとML Ops(発表者)が担当。golangで実装して本番デプロ
イして、オンライン検証結果を確認する。
Algorithm Programmer
9

View Slide

Algorithm Programmerと相談して、最適なインフラを作る。学習と言われ
るバッチ処理は非常に重い。推論と言われるオンライン処理は、小さい
latencyが求められる。また、自動最適化を行うため、ログの収集が非常に重
要！
→ LIMIAではML Ops(発表者)が担当。各種ログをBigQueryに収集してい
る。vscodeでCloudFormationテンプレートを書いている。
ML Ops
10

View Slide

研究を行いKDD/RecSys/WWWなどでの発表を目指す。DS/AP/MOなどか
ら相談を受け、使えそうな手法を提案する。また、因果推論によるオフライン評
価、マルチタスクなど、最新の論文で使えそうな手法を提案してくれる。
→ LIMIAでは明確な担当者不在。AP, MOとGREEのResearcherで論文輪
読会を開いてカバーしている。
Researcher
11

View Slide

1.分析
Analystが使うシステム

View Slide

分析するためには、ログを収集する必要があります。
LIMIAではBigQueryにログを集約しました。
そこで、BigQueryへのログの収集方法を解説し、それを誰がどのように利用
しているのかを説明します。
分析システムについて
Analystの領域
13

View Slide

Firebase管理画面でボタンを押すだけでBigQueryにデータが連携される。
連携されるデータは、次のもの。
● Analytics: 送信した全てのイベント
● Crashlytics: 発生した例外の情報
● Predictions: 予測結果
● FCM: プッシュ通知送受信ログ
● Performance: 送信したトレース情報
Analytics以外のBigQueryデータは使いこなせていない。良い使い道があれ
ば教えて欲しい。
イベントログ
Firebase
14

View Slide

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

View Slide

● 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

View Slide

原則データの確認はRDS/Dynamo等は使わず、BigQueryにある早朝に
取ったスナップショットに対して行う。BigQuery画面からが多く、DSは
Jupiter+pandasから。
● Analyst: 施策立案のための状況把握。施策の想定効果見積もりと効果
測定。KPI変化の要因分析。
● Data Scientist: パーソナライズを行うため、ユーザやアイテムの特徴を
分析。オフライン検証。
● Algorithm Programmer: オンライン検証結果確認。
● ML Ops: エラーログ、動作速度、機能の利用状況などでシステムの健全
性を分析。
誰が何を分析しているのか
仮説を立てて定量的に検証する
17

View Slide

LTVを上げるには回遊性向上が効果的。
アプリを起動してコンテンツを閲覧せずに離脱しているユーザが多数存在する
ことが分かった。
そこで、起動直後に表示されるピックアップ面の一覧表示をパーソナライズする
ことで回遊性を向上させられないか。
今回のプロジェクトでは
Analyst分析結果
18

View Slide

2.オフライン検証
Data Scientistが使うシステム

View Slide

Data Scientistが過去のデータを
使って、モデルの良し悪しを検証する。
良いモデルができたら、APにJupiter
Notebookを渡す。
→ LIMIAではgistにnotebookを貼
り付けて連携。
左図はGoogle Colaboratoryという
インストールなしで使えるJupiter
Notebookのようなもの。
https://colab.research.google.com/?hl=ja
オフライン検証とは？
Data Scientistの領域
20

View Slide

例えば、
● 14-8日前のデータを使って学習。ユーザ毎に推薦リストを作成。
● 7-1日前に閲覧されたItemが推薦リストの中に含まれている割合で評
価。
最近では因果推論を使った検証が流行中。
→ LIMIAではMAPとnDCGで評価。
検証方法
21

View Slide

オフライン検証のベースラインとして、人気のあるコンテンツを全員に配信した
ときを想定する。
Cell/Itemを表示したらFirebase Analyticsにimpression eventを送信
し、Clickしたらclick eventを送信してBigQueryに格納する。イベント数で割
り算したCTRを人気記事の定義とした。
→ LIMIAではCTRがこれを上回ったら、オンライン検証に移行。
合格ラインは？
Popular Model
22

View Slide

● Item Modeling: 記事を形態素解析して名詞を取り出し、それをword
embeddingしたvectorの平均を取った。
● User Modeling: ユーザが読んだ直近30件のItemのvectorの平均を
取った。
● Scoring: ItemとUserの距離。
● Ranking: Scoreの大きい順に並べた。
全Itemとの距離を計算すると重いので、10個に分類して中心点との距離を距
離を計算することにした。クラスタ内での並び順は、CTR順。
チャレンジし過ぎてRecSys2019のベストペーパーに指摘されるような事態は避けたい。
オフライン検証を通過したモデル
教科書に書いてある事を愚直に
23

View Slide

RecSysは推薦分野の有名な国際学
会。
4つの有名な国際学会に発表された
深層学習を使った推薦のコードを確認
したら、ほとんど動かなかったらしい。
それを発表して最優秀論文に選ばれ
ていた。
自分で出すときは、気を付けたい！
こぼれ話
RecSys2019 Best Paper※2とは?
24

View Slide

3.配信
Algorithm Programmerが使うシステム

View Slide

DSから受け取ったNotebookは、以下のようになっていました。
● 学習: バッチでItemとUserをベクトル化しておきます。
● 推論: ユーザが一覧表示をリクエストすると、それらを使って一覧表示を作
ります。
これを受けて、次のようなシステムを構築しました。
● 学習: Item/Userの更新通知を既にKinesisに流していたため、これを受
け取って処理するLambdaを追加しました。
● 推論: APIをgolangで作っているため、そこに処理を追加しました。
システム概要
ここはAWSです！すいません。m(_ _)m
26

View Slide

記事が更新されると、
SQSに通知されます。そ
れをLambdaで読み込ん
で、単語に分割し、単語を
vectorにします。記事に
含まれる単語の平均を記
事のvectorとします。ただ
し頻出単語の影響緩和の
ため、IDFで補正します。
アイテムベクトル作成
27

View Slide

ユーザが記事を閲覧すると、その情報がKinesisに流れます。
Lambdaで受け取り、直近30件の閲覧履歴をDynamoDBに保存
します。その変更をDynamoDB Streamに流し、Lambdaで受け
取って記事のベクトルの平均をユーザベクトルとしてDynamoDBに
書き込みます。
ユーザベクトル作成
28

View Slide

ItemとUserの距離を計算し、近い物を出す。
ただし、全記事との距離をリアルタイムに計算
すると遅いので、分類して中心点との距離を計
算することにした。クラスタ内での順位はCTR
を使った。
記事の推薦
29

View Slide

4.オンライン検証

View Slide

まず最初にFirebase A/B Testingを使ってオンライン検証を
行った。
この方法は楽だが厳密性に欠けるため、独自システムを開発し
た。
→ ここでは、両方について説明します。
オンライン検証方法
Firebase A/B Testingと独自システム
31

View Slide

● RemoteConfigはKey-Valueスト
ア。
● PCブラウザから設定できるので、企
画側で対応可能。
● Firebase A/B Testingでは、直接
的には指定したRemoteConfig key
の値が変更される。
● そこでデータを取得するAPI毎に
RemoteConfig keyを作成する。
Firebase A/B Testingを使った手法(1)
Firebase RemoteConfig設定
32

View Slide

defaultはリソースファイルに保持しておき、RemoteConfigから非同期に値を取得しま
す。
Firebase RemoteConfigからのデータ取得
33

View Slide

QueryStringにRemoteconfigから取得したパラメータを追加します。
サーバ側では、そのパラメータを使って処理を分けます。
HTTPリクエストのQueryStringに追加
34

View Slide

● ユーザグループA
とBに送られる
RemoteConfig
の値を設定しま
す。
● PCブラウザから設
定できるので、企
画側で対応可能。
Firebase A/B Testing設定
35

View Slide

PCブラウザから結果を確認
できる。
設定から結果確認までPCブ
ラウザで出来るので、エンジ
ニアが開発に集中できる！
テスト結果
36

View Slide

RemoteConfigは非同期で情報を取得する。そのため、初回アクセス時に
は、A/B振り分けられた値が取得されていないケースが多い。
ここが厳密性に欠けるとの指摘を受けたため、独自実装のシステムを作った。
独自実装の方は、userIdの下二桁で分岐するやり方。
独自システムについて
37

View Slide

5.レポート

View Slide

【Firebase A/B Testing手法】
A/Bテストでどちらのセグメントに振り分
けられたか、UserPropertyに設定されま
す。keyは次のようになります。
ﬁrebase_exp_
【独自実装】
FAにsetUserId()という足が生えているの
で、それで設定するとUserPropertyの
user_idに設定されている。
パターン毎の集計方法
Firebase A/B Testingと独自実装
39

View Slide

6.今後の課題

View Slide

● LTVと相関が強い指標を探す。特にRetentionを上げる方法。
● ピックアップ以外でパーソナライズしたい場所があれば。他タブ、回遊導
線、プッシュ通知、検索結果など。
● BigQueryのqueryを実装するより早く分析する方法。GAのWeb+App
の分析機能???
今後の課題
Analyst領域
41

View Slide

● ItemModel: word embedding(学習データにLIMIAの記事を加える。
最新のWE手法を使う。
● ItemModel: 形態素解析の辞書をチューニング。user辞書にLIMIA記
事。neologd利用。
● UserModel: 平均 vs RNN(読んだ順序を考慮するか)
● Scoring: 協調フィルタリングのScoreを作って既存に加える
● Ranking: アドテクを参考にFrequency Capをかけて、興味のない記事
を掲載されずらくする
● Kaggleを頑張る
今後の課題
Data Scientist領域
42

View Slide

● UnitTestがほとんど無いので書く
● Data ScientistからPythonのコードが来るのに書き換えるべき?
● atcorder頑張る
今後の課題
Algorithm Programmer領域
43

View Slide

● エラーログ周りをなんとかする
● micro serviceとして切り出して他prjへ提供
● k8s(GKE)対応
今後の課題
ML Ops領域
44

View Slide

● 論文輪読を繰り返して、最新に追いつく。
● 論文を書いて発表する。
今後の課題
Researcher領域
45

View Slide

まとめ

View Slide

● ユーザ体験向上のため、一覧表示のパーソナライズを行った。
● この構成が良いと思っていないので、お気付きの点があれば指摘して欲し
い。歴史が浅い分野なので、情報を共有して僕らで定石を作っていきた
い。
● 機械学習prjは、様々な専門性を持つ人達を結集する必要がある。しかし
仲間が少なく、一人で複数の専門性を見ているので成長が遅い。
まとめ
47

View Slide

一緒に推薦システムを作ってくれる仲間を募集中です。
● Analyst
● Data Scientist
● Algorithm Programmer
● ML Ops
● Researcher
興味がある方は声をかけてください！
We are hiring!
48

View Slide

Appendix

View Slide

● 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

View Slide

類似ユーザに人気の記事を配信することで、CTRが上がるという仮説を検証し
た。
ユーザをいくつかのクラスタに分類する。
分類結果をBigQueryに送信し、クラスタ毎のCTRを集計する。
定期的に集計してストレージに格納しておき、ユーザは所属するクラスタ内で
CTRが高い記事を一覧表示する。
これをPopular Modelとオフラインで比較して、既存手法とオンラインで比較し
た。
失敗した手法
Segmentation Popular Model　
51

View Slide

LIMIAにはtwitterのようにユーザをフォローする機能がある。フォロー数が多
いほど来訪頻度が高いことが分かっている。興味のあるユーザを推薦すること
でフォロー数が増えるという仮説を検証した。
BigQueryにあるフォロー情報を使ってUser x Userの行列を作る。
コサイン距離を計算するUDFを作り、類似ユーザを抽出した。自分がフォロー
している人の類似ユーザや類似ユーザがフォローしていて自分がしていない人
を推薦した。
その他の推薦
UDFを使った協調フィルタリング
52

View Slide

BigQueryを使った機械学習プロジェクトの分析とオフライン検証

BigQueryを使った機械学習プロジェクトの分析とオフライン検証

mahiguch

More Decks by mahiguch

Other Decks in Programming

Featured

Transcript