1

DoBoken データ分析チーム

特許出願中

Jubatus の EC サイトへの適応

チーム紹介

Hajime

1 日目、明け方までがんばって今日はダウン

Tokoroten

ふるすたっくぐろーすはっくでーたさいえんてぃすと

あまの　だいすけDaisuke Amano

データ分析右翼

Yuji IsobeDB まわり

エンジニア 3 人で月間 10 億 PV をさばく

ZenClerk とは？

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

つまり ZenClerk とは？

「お客様、何かお探しですか？なるほど、こちらの商品を検討中ですか。

では、その商品、今なら特別に 1 割引にしますが、

ご検討いただけませんでしょうか？」

という機能を EC サイトで実現したサービス

サーバ環境

https://speakerdeck.com/yujiosaka/enzinia3ren-dezhi-eruyue-jian-10yi-pv

プロダクションにおける機械学習の課題

1. 特徴量がサイトのデザインに依存しているサイトリニューアルに弱い

2.TVCM などによる新規流入学習時と別セグメントのユーザの流入に弱い

3. 分類器の確認が人手精度確認、分類器の確認が必要

データ蓄積に数日、確認に 1 営業日

それユバ（それ Jubatus でできるよ！）

V.S

バッチ学習からオンライン学習へ

EC サイトの変化にリアルタイムに追従するオペレーションコストを削減する

実験環境

• クラス分類器を利用

• ユーザのページビュー時の行動ログから、そのユーザにクーポンを送るべきか否かを判定

• 本番の DB から、リアルタイムのアクセスログ、特徴量を取得

• リアルタイムで Jubatus に学習させながら、本番環境の分類器の予測結果と、 Jubatus の予測結果を比較

精度比較（大手 EC サイト１）

0

10

20

30

40

50

60

70

80

90

100

production_recallproduction_precisionjubatus_recalljubatus_precision

オンライン学習が、バッチ学習精度に追いつく

精度比較（新規クライアント、学習器反映待ち）

0

10

20

30

40

50

60

70

80

90

100

production_recallproduction_precisionjubatus_recalljubatus_precision

↓ 本番で動いている学習器は仮対応なので、著しく精度が悪い

精度比較（大手 ECサイト２、 Jubatusの過学習）

0

10

20

30

40

50

60

70

80

90

100

production_recallproduction_precisionjubatus_recalljubatus_precision

↓ 結果を蓄積するリングバッファが一周した

精度比較（中規模 EC 、データ不足で収束せず）

0

10

20

30

40

50

60

70

80

90

100

production_recallproduction_precisionjubatus_recalljubatus_precision

Demo

考察

• データ量が多い EC サイトでは、リアルタイム機械学習でもバッチ学習と同程度の精度が出る

• EC サイトのデータの偏りによっては、教師データの偏りから、過学習が発生しうる

• たとえば、購買予測の問題だと、アクセスの 9 割は買わない人なので、アクセスログを全て学習させると、買わない側に過学習する

• Precision が悪い、バッチ学習に追いつかない

• Recall と Precision のバランス調整が難しい

• バッチ学習だと、学習させるデータのバランス調整が容易

• 教師データと特徴量の関係が凸関数や非線形になっているものが多いので、線形分類器で扱いづらい（かも？）

• 非線形の分類器はまだですか・・・

ハッカソンの結果

ソニーの GoPro モドキでハッカソンの撮影してた

ら、 GoPro 貰った

ちゃんと消耗しました