Jubatus Hackathonで、ECサイトのリアルタイムのアクセスログを用いて、オンライン学習を行いバッチ学習の結果との比較を行った。

1. JubatusのECサイトへの適応
DoBoken データ分析チーム
1
特許出願中

2. チーム紹介
Hajime
1日目、明け方までがんばって
今日はダウン
Tokoroten
ふるすたっくぐろーすはっく
でーたさいえんてぃすと
あまのだいすけ
Daisuke Amano
データ分析右翼
Yuji Isobe
DBまわり
エンジニア3人で月間10億PVをさばく

3. ZenClerkとは？
ユーザーの「迷っている」を機械学習
クーポンを提示し、購買を後押し

4. つまりZenClerkとは？
「お客様、何かお探しですか？
なるほど、こちらの商品を検討中ですか。
では、その商品、今なら特別に1割引にしますが、
ご検討いただけませんでしょうか？」
という機能をECサイトで実現したサービス

5. サーバ環境
https://speakerdeck.com/yujiosaka/enzinia3ren-dezhi-eruyue-jian-10yi-pv

6. プロダクションにおける機械学習の課題
1.特徴量がサイトのデザインに依存している
サイトリニューアルに弱い
2.TVCMなどによる新規流入
学習時と別セグメントのユーザの流入に弱い
3. 分類器の確認が人手
精度確認、分類器の確認が必要
データ蓄積に数日、確認に1営業日

7. それユバ（それJubatusでできるよ！）
バッチ学習からオンライン学習へ
ECサイトの変化にリアルタイムに追従する
オペレーションコストを削減する

8. 実験環境
• クラス分類器を利用
• ユーザのページビュー時の行動ログから、そのユーザに
クーポンを送るべきか否かを判定
• 本番のDBから、リアルタイムのアクセスログ、特徴量を取得
• リアルタイムでJubatusに学習させながら、
本番環境の分類器の予測結果と、Jubatusの予測結果を比較

9. 精度比較（大手ECサイト１）
100
90
80
70
60
50
40
30
20
10
0
オンライン学習が、バッチ学習精度に追いつく
production_recall
production_precision
jubatus_recall
jubatus_precision

10. 精度比較（新規クライアント、学習器反映待ち）
100
90
80
70
60
50
40
30
20
10
0
production_recall
production_precision
jubatus_recall
jubatus_precision
↓本番で動いている学習器は仮対応なので、著しく精度が悪い

11. 精度比較（大手ECサイト２、Jubatusの過学習）
100
90
80
70
60
50
40
30
20
10
0
↓結果を蓄積するリングバッファが一周した
production_recall
production_precision
jubatus_recall
jubatus_precision

12. 精度比較（中規模EC、データ不足で収束せず）
100
90
80
70
60
50
40
30
20
10
0
production_recall
production_precision
jubatus_recall
jubatus_precision

13. Demo

14. 考察
• データ量が多いECサイトでは、リアルタイム機械学習でもバッチ学習と同程度の
精度が出る
• ECサイトのデータの偏りによっては、教師データの偏りから、過学習が発生しう
る
• たとえば、購買予測の問題だと、アクセスの9割は買わない人なので、アクセ
スログを全て学習させると、買わない側に過学習する
• Precisionが悪い、バッチ学習に追いつかない
• RecallとPrecisionのバランス調整が難しい
• バッチ学習だと、学習させるデータのバランス調整が容易
• 教師データと特徴量の関係が凸関数や非線形になっているものが多いので、
線形分類器で扱いづらい（かも？）
• 非線形の分類器はまだですか・・・

15. ハッカソンの結果
ソニーのGoProモドキで
ハッカソンの撮影してたら、
GoPro貰った
ちゃんと消耗しました