レコメンドで商品 相関 がうまく働かない時のアプローチ


レコメンド機能において最も代表的な手法である商品 相関

前回書いたように、レコメンド機能において現在でももっとも代表的な手法は商品 相関 です。

Aを買っている人はBも買っています、というやつです。

Amazonレコメンドと呼んだりもします。

商品 相関 で使われるデータは購買履歴です。

買ったというより買われた情報を元に、 相関 を計算しているということです。

購買履歴は相当強力な行動履歴ですから、ある意味当然ではあります。

では商品 相関 がうまく働かないケースではどうしたらよいかについて考えてみます。

商品 相関 がうまく働かないケースとは

まず「商品 相関 がうまく働かないケース」というのはどういったものでしょうか。

いろいろなパターンがありますが、例えば「商品自体に 相関 があまり関係ない」というものがあります。

たとえば食材などは「にんじんを買ったからじゃがいもを買う」ということはあまりないでしょう。 相関 があるケースもありますが。

商品相関

他にも「行動履歴がスパースすぎて 相関 にならない」というケースもあります。

スパースというのは疎という意味です。疎密の疎です。もっと簡単にいえば「まばら」ということです。

商品点数に対して購買履歴がまばらすぎると、信憑性のある 相関 を導き出すのは難しいといえます。

例えばAという商品とBという商品が、共に数回買われたくらいでは 相関 があるとは言えないでしょう。

基本商品 相関 を出すには、ユーザーがおおむねリピーターで、商品点数がそこまで多くなく、商品寿命が長い必要があります。

そもそも別のケースとして、「商品寿命が短い」とそもそも 相関 が出せたとしてもレコメンドとして使えない、というパターンもあります。

たとえばニュース記事などは、 相関 がたまる頃には記事としての賞味期限が切れてしまっている可能性が高いでしょう。

他にもいろいろなケースがありますが、こういったパターンを一気に解決する魔法のような手法というのはありません。

個々のパターンごとに対応していく必要があります。

それをかたっぱしから列挙していくのでもいいですが、代表的な手法というか考え方について解説してみます。

メタデータを使ったレコメンドとは

まず最初が「行動履歴ではなくメタデータを使う」というものです。

メタデータという言葉自体若干曖昧ですが、ここでは商品というかアイテムに付属するデータだと思ってください。

行動履歴による 相関 の場合、アイテム自体をノードというか単なる記号として扱います。

ぶっちゃけ商品ID的なものさえあれば 相関 は出せるということです。

その商品の商品名や説明文章、色や形などは使ってもいいですが 相関 そのものの根拠としては使いません。

商品のメタデータが不要である代わりに、スパースではない行動履歴の蓄積を待つ必要がある、ともいえます。

例えば先程のニュース記事ですが、これは記事なのでそのテキストというものが商品というかアイテムに付随するメタデータとして存在します。

メタデータ

一行で終わる速報ニュースとかでなければ、この記事のテキスト自体を活用して記事 相関 を出すことが可能になります。

また記事同士の 相関 ではなく、ユーザーごとに好む傾向のある単語群との 相関 を出すことも可能です。

この場合はユーザーの好む単語群を出すために、そのユーザーの過去の記事の閲覧履歴自体は必要ですが、新しく配信された記事は配信された時点で 相関 について評価することができるようになります。

これは先程の行動履歴(購買履歴)と、ちょうど対照的であるともいえます。

商品自体のメタデータは不要だが 相関 を出すまでに行動履歴を溜める時間がかかる、というものと、行動履歴を溜める時間は不要だが商品自体のメタデータは必要、というものです。

もちろん実際にはこの2つの手法は相反するものではなく、併用することも可能です。

行動履歴の次元を削除するアプローチ

また他の手法として「行動履歴の次元を削減する」というものがあります。

これだけだと何を言っているのかわかりずらいですが、スパース(疎)な履歴を密にする、ということです。

削減の代わりに圧縮という表現を使うこともあります。

この「次元の削減」にはさまざまなアプローチがあります。

いま話題沸騰のディープラーニングも次元の削減という考え方を活用しています。

たとえばスーパーやドラッグストアで買われるような商品は行動履歴がスパースになりがちです。

これを、ユーザーや商品をそれ単独として扱うのではなく、グルーピングしてしまうと 相関 が有意になる可能性があります。

ある商品群に対してあるユーザー群がつける行動履歴は、ある商品に対してあるユーザーがつける行動履歴より圧縮されています。

このとき計算根拠とする商品点数、ユーザー数は減っている(群になっている)わけですが、それがつまり「次元の削減」です。

商品点数が1万点の場合、それは1万次元のデータとして扱いますが、これを仮に100個づつ100の商品群とした場合は100次元のデータになるということです。

他にも例えば、先程の記事と同様、テキストについて考えてみるとき、単純な単語数だと1万語あるとしてそこから重要な単語を100抜き出したとしたら、これも1万次元を100次元に次元を削減(圧縮)しているといえます。

重要な単語はどう判断するかというと、一番単純なのは「登場するテキスト数が少ないほど重要」という考え方です。

たとえば「今日」「日本」などはかなりの割合のテキストに登場しそうなので、あまり重要ではありません。

商品 相関 が使えない場合のアプローチとしては他にもいろいろありますが、まずはこの「メタデータを活用する」「次元を削減する」という手法を取り入れるだけで、かなり取り扱えるデータの種類というか幅は広がります。

■ZERO ZONE製品シリーズ■
サイト内検索エンジン・EC商品検索 「ZERO ZONE SEARCH」
レコメンドエンジン「ZERO ZONE RECOMMEND」

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【著者情報】
株式会社ゼロスタート
代表取締役社長 山崎 徳之

【連載紹介】
[gihyo.jp]人工知能で明日のビジネスは変わるのか?
[Biz/Zine]テクノロジービジネスの幻想とリアル
[ECZine]人工知能×ECことはじめ
[ECのミカタ]ECの役割
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

vector graphics and icons designed by Freepik (http://jp.freepik.com)

 

他のコラムを読む

– 前の記事 –
レコメンド とは?

– 次の記事 –
サイト内検索マーケティング の実現に必要な要素は「合算できない技術」