エスキュービズム ラボ Blog

ここ数年。
amazonの「この商品を買った人はこんな商品も買っています」で、
すっかり御馴染みになったレコメンド技術。

その中でも比較的有名なのが「協調フィルタリング」ってヤツなんですが。
最近はお客様からのご要望として、その辺りを挙げられる方もいらっしゃるので、
ここは一度軽くかじっておこうかと思いまして。

まぁ、流石に有名なのか「基本的な仕組み」については、
探せば幾らでも出てくる御時世なので、そちらを見ていただくとして。

ぶっちゃけ簡単にたとえますと―――
　　
　
【アイテムベース協調フィルタリング】
　◆入力
　　ECサイト内における全ての注文情報
　　　　↓
　◆出力
　　商品Ａを買った人に聞きました。
　　「アナタが他に買った商品」は？
　
【ユーザーベース協調フィルタリング】
　◆入力
　　ECサイト内における全ての注文情報
　　　　↓
　◆出力
　　ユーザーＡと比べて、比較的似た購入パターンの人に聞きました。
　　「アナタが買った『ユーザーＡがまだ買っていない商品』」は？
　
　
というカンジですかねぇ。
ゆえにレコメンド技術として広く使われているようで。

とは言え、入力データ（収集項目，収集場所）を変えれば、
出力データの傾向，意味合いも大きく変わってきます。
ましてや、それをどう使いどう表現するかは各々の自由なんですけども。

まぁ、作ったことも無いのにとやかく言うのも無粋なので、
とりあえず「シンプルなアイテムベース協調フィルタリング」を、
「その辺で見つけた仕組み」を、そのままに形にして、
ec-cubeの商品詳細表示（detail.php）に入れてみました。

ただ、この手のシロモノは「膨大なサンプルデータ」あって初めて、
その効果を実感できると言うもの…というワケで。
　
　
　ec-cubeの受注データ：14,000件
　ec-cubeの受注詳細データ：46,000件
　
　
を、食わせてみました。
流石に全データ（※１）を使うと膨大すぎるので…
どこから調達したかは、そのうち弊社「EC-Orangeブログ」にて。

なおDBサーバのスペックは「memory:1G」「cpu:2.66GHz(1core)」と結構普通。
以下、お手軽レシピ。
　
　
【手順１】
「どの顧客が、どの商品を買ったか（数不問）」なテーブルを作る。
→まぁ、７秒程度。レコード件数は32,000件。
　
【手順２】
手順１で作ったテーブルを元に、
「商品Ｘを買った人で、商品Ｙを買った人がＺ人」なテーブルを作る。
→１分かかった…レコード件数は1,270,000件。
　
【手順３】
商品詳細表示画面でにて。
例えば商品Ａの場合、手順２で作ったテーブルより「商品Ａを買った人で～」のレコード群を取得。
あとは「中学，高校の確率／統計」な話なので以下略。
　
　　
あくまで「その辺で見つけた仕組み」を、そのままコードに起こしただけのシロモノですが、
それっぽく（笑）動いてます。

集計，解析（手順１，２）も日次バッチに含めてやれば、
特に負担になるワケでもないので、それなりに使えそうです。
（とはいえ性質上、サンプルデータの量あってのシロモノですが）
　
ちなみに精度については…どーなんでしょ？
本格的に調べていくと、おそらくツッコミどころや改善点に満ち溢れてるハズ。
まぁ、本当「そのまま」形にしただけですし、それほど的外れではないとは思うんですが―――
　
　
　
　　『賢者（クラウドマップ作者）に聞いてみるか…』
　
　
　
おあとがよろしいようで。

※１．order:90k,order_detail:240k,customer:120k,products:140k