レコメンデーション活用編
--- 開発者より ---
Karubi Namuru
May 16, 2010

自己紹介
● Karubi Namuru
– 詳しくは名刺交換で
● Ph.D. in CS, RD Engineer
●
Twitter ： @karubi
●
facebook ： http://facebook.com/karubi
●
出身：広島，居住：東京 , Seongnam

学生時代の話
●
在学中の研究
●
統計的手法による日常行動分析
– 実世界：ライフログ
– ウェブ：閲覧， clicks
200 200
180 180
160 160
140 140
120 120
100 100
80 80
60 60
40 40
20 20
0 0

現在使っている知識
●
膨大な情報の処理
●
疎な分散処理
●
時系列情報を参照する情報推薦
●
コンテクスト抽出
●
状況変化型の情報推薦
– いつも一緒ではない，時間は刻々と進む

今日の基本スタンス
●
開発者としての LT
●
統計処理など大規模計算をインターネットの
サービスでつかう
– 計算開始から終了まで３日かかるとかだめ！
– インフラコストが馬鹿にならない！
– 運用，とにかく止めちゃだめ！
●
もちろんビジネス
– できれば金儲けしたいよ

お話をする応用について (1)
●
おさらい
●
大きく分類して３つの方法論がある
– コンテンツベースフィルタリング
– ルールベースフィルタリング
– 協調フィルタリング

お話をする応用について (2)
●
画像を利用する推薦サービス
●
画像特徴量を利用する
●
疎結合な分散処理
– 当時流行のクラウドコンピューティング， Amazon EC2
– 分散処理， Apache Hadoop
●
知財化
●
Amazon WebServices エバンジェリストに紹介
– ApacheCon US 2008, Nov.

お話をする応用について (3)
●
広告配信サービス
●
コンテンツ連動広告
– 現在サービス中のため，話せるレベルで ...
●
大規模なログ処理の例，機械学習
– Apache Hadoop
– Apache Mahout （たぶん世界最初の商用で利用
●
閲覧者の需要をどのようにして見つけるのか？

軽めにおさらい
●
レコメンドのアプローチ
●
コンテンツベース
●
ルールベース
●
協調フィルタリング
●
Hamadakoichi さんが詳解している！（はず
– おさらい程度でー

コンテンツベースフィルタリング
●
内容に合わせた見合うアイテムを見つける方法
●
Content-based filtering
●
好きな監督・俳優・ジャンルなどを決める
●
その組み合わせに即して，アイテムを決める
– 映画「プリティ・ウーマン」を選択すると
●
ラブロマンス
●
ジュリア・ロバーツ
→ 「ノッティングヒル」を推薦
●
ラブロマンス
●
ジュリア・ロバーツ

ルールベースフィルタリング
●
エキスパートシステム
●
AI の研究分野
●
専門家の知識をルールのようにプロセスにする
– 映画「プリティ・ウーマン」を選択すると
●
「元となった映画がある場合は併せて推薦する」ルール
→ 「マイ・フェア・レディ」を推薦

協調フィルタリング
●
似た人が与えた評価を利用して，アイテムの評
価を予測する
●
多くの利用者の嗜好情報を蓄積すること
●
ある人と嗜好の類似する他の人の情報
●
クチコミの原理と例えられる
– 趣味の似た人からの意見を参考にする

考え方
●
ユーザ A がアイテム X を好む
●
アイテム X を好む別のユーザ B が好むアイテム
Y が存在する
●
ユーザ A もアイテム Y を好むのではないか
●
実装で利用するのはユーザ同士の類似度
– たとえば，同じアイテムにつけた評価の相関係数

対象する情報
●
明示的な情報源
●
ユーザの評価がついているもの
– レビュー
●
明示的に選択したもの
– 評価ポイント
●
暗示的な情報源
●
システムの操作履歴
– ブラウザの閲覧履歴

明示的な情報の具体例
●
評価の内容
●
例えば映画の場合
– この映画は面白かった，つまらなかった
– ◯◯ 点
– 評価を与えた映画の組み合わせ
●
レビューリスト

画像を利用する推薦サービス
●
概要
●
画像を特徴量にする（色，形など）
●
それぞれの特徴量に対して閲覧者が評価を与えてい
るとする
●
閲覧者の嗜好を協調フィルタリング

画像を利用した動機
●
協調フィルタリングでは対応しづらい世界もあ
る
●
データが集まるまでマトモに機能しない
→ プロダクトライフサイクルの短い商材に向かない
●
コンテンツベースフィルタリング
●
なにの情報を対象にするのか
●
収集もしなければならない
●
できるだけ汎化したい

どのような情報を利用するのか
●
色
●
色空間系
●
質感
●
素材感
●
形
●
境界
●
モデルと背景の問題

どのような開発をするのか
●
計算量が多い
●
画像を特徴化
●
協調フィルタリング
●
更新頻度が早い
– 商品の入れ替えが早い（こまめな商品追加
– 在庫も薄い（洋服の場合
●
止めてはならない

具体的な対策
●
Apache Hadoop
●
分散して計算
●
Map Reduce できるようにデータ構造に注意する
●
Amazon EC2
●
インスタンスを API で増やせる
– 危機の予感がしたときに作ればいい
●
従量課金
– 止めれば料金が掛からないのでベンチャーでも安心

適用結果
現地で
ApacheCon のために Amazon WebServices のエヴァンジェリストに紹介した動画
http://www.youtube.com/watch?v=SkI_2bznyk0

広告配信サービス
●
概要
●
コンテンツ連動広告
– ウェブページの内容に沿った広告

広告に推薦は有効に働くか
●
クリック保証型広告の場合
●
成果が「広告のクリック」
●
閲覧者のニーズ通りの広告が出れば利得が最大
– 最もクリックされるために配信会社は儲かる
– 広告主のサイトに商材に興味のある閲覧者が集まるため
に，広告主のビジネスも成功して儲かる
●
インプレッション保証型広告
●
成果が「広告の閲覧」
●
今回は対象外

どのような情報を利用するのか
●
ウェブページの情報
●
特徴語？
●
閲覧者の情報
●
過去の履歴？
●
などなど色々な情報があります
※ 実サービスでは複数の情報をきちんと調理することが一番良いと思います．

どのような開発をするのか (1)
●
膨大な配信量
●
たとえば一般的な新聞社
– 配信規模：約 2 億 PV / month
– 閲覧者：約 2000 万 UU / month
●
広告配信の場合
– 配信規模も閲覧者も新聞社より多い

どのような開発をするのか (2)
●
配信速度
●
止めてはいけない
●
金が絡みますので
●
計算量を気にしなくてはならない
●
配信ログ

ログの調理の具体例
●
Apache Hadoop
●
前と同様
●
Apache Mahout
●
高度な機械学習

まとめ
●
インターネットでサービスするのは大変
●
技術屋に求められるスキル
●
計算ロジックの説明を求められる
●
配信量が増えるサービスの場合は，突然増えても問
題ないように考えておく
●
運用の手間は少ない方がいい
●
質問あればこちらまで
gogokarubi@gmail.com まで