7/26 【U-NEXT ☓ Oisix】データ分析と機械学習 事例発表を開催しました
機械学習の勉強会を開催したのでブログを書きます。
なお、以下のお二方がかなり詳細にメモを残してくださっているのでこちらも参考にしていただけると良いかと。
Oisix:顧客属性推定とレコメンド
www.slideshare.net
オイシックスとは
- より多くの人が豊かな食生活を簡単に送れるようなサービスの提供を行う
- 野菜を作った人が自分の子供にも食べさせられるものを提供する
- 毎週定期で買うシステム
顧客属性推定とレコメンド
- パーソナライズプロジェクトの一環
- パーソナライズ = お客様一人一人に寄り添ってサービスや商品を提供すること
- 子どもがいる家庭に卵ボーロを提案する
- パーソナライズ = お客様一人一人に寄り添ってサービスや商品を提供すること
- 使いどころ①:定期ボックスをパーソナライズする
- 顧客属性を推定し、1人1人にあった定期ボックスを提案する
- 使いどころ②:いろんな売り場をパーソナライズする
- 売り場の属性を加味して商品を提案
- クラスタごとの購入商品を元にバスケット分析を行うことで精度を向上させる
- 今回紹介するクラスタ分析はクラス分類の方
- 子どもがいる家庭の商品を学ばせ、任意の家庭に子どもがいるか否かを当てさせる
- バスケット分析はリフト値を計算して高いものから順に出す
- ポテトフライを買った人はクラッカーを買っている傾向がある、など
- オイシックスの分析環境
- 具体事例:商品提案までの流れ
- 1.データの整備
- DBのデータが更新されていないということがあったため、分析作業の出戻りが発生した
- →更新をチェックする仕組みを導入する
- 2.アンケートの収集
- 食の好みについてのアンケートを作成
- 購買が分かれそうな4つのセグメントに分けた
- やってみると料理するに回答したお客様の購買履歴が料理しているように見えない
- →回答と実態に差が出ないような質問項目にする必要がある
- 3.外れ値データの除外
- データを学習させてもなかなか良い分類モデルが作れない
- →購買数量が多い順に商品をソート
- →1人しか買っていない商品、ほぼ買っている商品はクラスタ分類できないので外していく
- 4.分類モデルの作成
- 5.分類モデルの適応
- 標準化作業で出戻りが発生してしまっていた
- →標準化を行う際のパラメータを保管しておく
- 6.バスケット分析
- 購買がない顧客に商品は提案されない
- 似たカテゴリの商品が提案される
- →機械学習は万能ではない。各種手法でできること、できないことを理解する。
- 7.商品の提示
- 同じロジックで商品を提案しても売り場毎にCVR等に差が出た
- →売り場ごとの特性を理解し、工夫することが大事
- 1.データの整備
- ゴール:オイシックスは自分のことを知ってくれていてお買い物が楽
質疑応答
- パーソナライズの分析に関してはYahooビックデータを使ってやっている
- マーケの方と二人三脚でやっている。システム作っていく中でどの売り場をどう見せようとか話している。
- スピード感:今日話したものに関しては4月に入って1,2人でやっていて社内で実験ベースでやるまで2ヶ月程度
- 機械学習で有名な企業との連携は考えた。技術的なところが手探りなので。でも内部のサービスを知っているのは自分たちなので、コンサル的な会社と提携して進めている。
- クラスタの分け方を決定するまでに試行錯誤はした。
- レコメンドの評価は、実際やってみて子供っぽい商品が出てきているかなど都度確認。効果は見られた。
- レコメンドサイクルは週1回。
- 季節性などの細かなチューニングはまだ着手できていない
- 子どもがいると買うものが異なるという仮説を検証する手段が機械学習だった。
U-NEXT:パーソナライズのこれまでとこれから
U-NEXTの紹介
- オンラインでの映像、書籍のレンタルサービス
- 多いのでキュレーションを思いついた
- ただ作品を並べるのではなく、棚組みをする特定のクラスタの人に響くような
- →専門編集者がキュレーション特集(2300特集)を作成
- それでもやっぱり全部は見られない
- →レコメンドしよう
- より好きそうな作品順に左から並べる
- より好きそうな特集順に上から並べる
U-NEXTのレコメンドシステム
- ビジネス的な要求・特徴
- 動画視聴を促進したい
- レコメンド入れることによって動画をより見てもらえることが前提
- 100人いたら100通り、300万人なら300万通りの結果が欲しい
- 同じ人でも1日に1回くらい更新して欲しい
- パフォーマンスは損ないたくない(目標応答時間100msec)
- でも準備期間はさして長くない(○ヶ月で商用リリースしたい)
- 要求・特徴を満たすために考えた事
- とりあえずデータを放り込む場所を確保する
- 小さく初めて試行錯誤する
- レコメンドが動画視聴につながることを評価できるようにしておく
- レコメンドシステム
- とりあえずデータをTresure dataへ突っ込む
- Treasure Dataを計算にも最大活用してレコメンドエンジンは小さく始める
- A/Bテストできるようにしておく
- 完全なランダムには負けないように
- 結果
- 視聴時間の長さが27.5%アップ
- 全視聴の60.8%がレコメンドされた作品に
レコメンド実践ならではの課題と対策
- そもそもレコメンドシステムを作った事がある人がいない
- レコメンドの方法
- 嗜好性の近さ
- 強調フィルタリング(ユーザベース)
- この人とこの人が興味が近いからこれも好きなんじゃないの?
- 協調フィルタリング(アイテムベース)
- Aという作品が好きならBという作品も好きなんじゃないの?
- 強調フィルタリング(ユーザベース)
- 内容の近さ
- 内容ベース
- 嗜好性の近さ
- 評点の予測アルゴリズムをやってみた
- データ量が絶望的に足りない
- アクティブなユーザでも、あまり評点をつけてくれていなかった
- 評点データを持つユーザの割合が圧倒的に足りなかった
- データ量が絶望的に足りない
- 評点データを集めよう
- UIをいじらないといけない
- UXを損なわないように情報設計しないといけない
- 現実的に大量入手可能なデータを使おう
- 明示的データ:評点
- 暗黙的データ:動画再生ログを使う
- 動画再生ログを使おう
- 再生、一時停止、視聴再開など精度の高いデータが集まる
- 長時間見ている、完走率が高い≒評点が高め
- 協調フィルタリング(ユーザベース)してみた
- うまくいかなかった。ヘビーユーザにはいいかんじ
- 協調フィルタリング(アイテムベース)してみた
- いい感じの結果が得られた。視聴時間も延びた。
- 内容ベースしてみた
- まだ改善の余地あり
- コールドスタート問題の解決とセレンディビティの演出には一定の効果あり
- データ加工方法
- 非エンジニアも関わるからGUIでシステムを構築
- 他社との連携
- atilikaという会社と協力中
質疑応答
- 内容ベースで元にする材料として、まずは解説テキストを使っている。その後、スタッフ、キャスト情報、タグとか。
- 内容はキーワード抽出して推定
- ユーザ属性は使っていない。アカウントを家族で使っていたりするのでログだけで。
- 現在曜日に関しては考慮していない
感想とか
今回のイベントにも多くの方が訪れてくださいました。
質疑応答の時間は大変盛り上がり、機械学習、今回の事例への関心の高さが伺えました。
途中専門的な話も出てきており、機械学習が専門外の私にとってはピンと来ない部分もありましたが、基本的には具体事例にそって説明がされていたため非常によくわかる発表となっていました。とても可能性のある分野だと思うのでぜひ頑張っていただきたいです。