はじめに
今回から9回に渡り、Hadoopを使ったレコメンドシステムの実装について紹介させていただくことになりました。
レコメンドシステムを構築した方は少ないと思いますが、レコメンドのサービスに触れている方は多いと思います。今回の連載で、読者の皆様にレコメンドシステムの可能性とその実装の面白さをお伝えできればと思います。よろしくお願い申し上げます。
連載の予定は次の通りです。
- レコメンドシステムと集合知（今回）
- レコメンドシステムの実装と課題
- 協調フィルタリング（前・後編）
- コンテンツベースレコメンド（前・後編）
今回の記事のポイントは以下の通りです。
- レコメンドシステムの目的は気付きと驚きを与えること
- 理想のレコメンドはソムリエのお薦め
- レコメンドシステムに必要なのは嗜好と専門性
では、早速はじめましょう。
レコメンドシステムとは？
レコメンドシステムは情報フィルタリングの一種で、大量の情報の中から個人の嗜好に合ったものを推薦します。たとえば、アイテム（商品）を扱うECサイトであれば、大量のアイテムの中から、ユーザの嗜好に合致し、そのユーザがまだ知らない、あるいは気が付き難いアイテムを推薦します。
レコメンドシステムが効果を発揮するのは、アイテムの数が、ユーザが自力で把握できる数よりも多く、ユーザにより評価が分かれるアイテムを扱う場合です。たとえばパソコンやデジカメといった機能で条件検索できるアイテムよりも、本、音楽や映画といった人の嗜好や価値観が反映される嗜好的なアイテムの検索に向いています。
ただし、ユーザにとって既知のアイテムを推薦してもあまり意味がありません。たとえば、レディー・ガガのファンに彼女の新曲を薦めるような場合がこれに相当します。できるだけ「ユーザはまだ知らなが、知ったら気に入るはず」というアイテムを紹介し、ユーザに気づきと驚きを与えるのがレコメンドの目的です。レディー・ガガが尊敬し、彼女に影響を与えたデボラ・ハリーの曲であれば、レディー・ガガのファンにとっては彼女の新曲より推薦する価値が高いと考えられます。
レコメンドを提供している有名なWebサービスのひとつに、オンラインのブックストアがあります。これらのサイトでは、本をチェックする度に「この商品をチェックした人はこんな商品もチェックしています」や「この商品を見た後に買っているのはこんな商品です」という基準で本を推薦します。
推薦できるのは本に限らず、DVD、ゲーム、映画、お店なども可能です。このブックストアの強みの一つは各アイテムについて豊富なレビューを持っていることです。単に商品を推薦するだけでなく、その商品のレビューも同時に見せることで、利用者の商品購入を後押ししています。
ブックサイトが明示的なアイテムを推薦するのに対し、これらレビューを使ったレビューサイトは暗示的なアイテム推薦をしているとも言えるでしょう。
有名なところでは、ホテル、レストラン、映画、DVDや音楽のレビューサイトがあります。先ほどのブックストアではレコメンドシステムが推薦するアイテムを決定するのに対し、レビューサイトはレビューを投稿したレビュワがアイテムを推薦している違いがあります。どちらのサイトでも多くの人の知識を利用している点で共通しています。
他のサービスでもレコメンドは使われています。たとえばSNSでは「友達かも？」というサービスで、友人リストに登録していない友人あるいは共通の知り合いを紹介しています。
また、サーチエンジンでも検索結果のランキングあるいは入力クエリの補完や共起するクエリの予測などもあります。これもまた人が作ったページ、テキストやリンク構造などを利用しています。検索結果に出現する広告もレコメンドの一種といえるでしょう。
このようにレコメンドを提供するサービスの形態はバラエティーに富んでいます。今回の連載では、この中で最初に紹介したブックストアに使われるレコメンドシステムの実装を中心に話を進めていきます。
集合知とは？
レコメンドシステムは自分を含め、多くの人の知識と経験を利用して役立つ情報を提供します。ご存知のように、レコメンドはWeb上に限った話でなく、実生活でも普通に行われています。
お薦めの映画を友人に聞いた例を見てみましょう。
A君は「『ムカデ人間！』『人蛇大戦』もいいよ！」とあまり知られていない映画を薦めてくれますが、この映画はA君の好みには合っても、自分の好みに合っていない可能性があります。
B君の薦めてくれた映画は「『スパイキッズ4D』か『猿の惑星：創世記』じゃない？」と自分の好みに合っていますが、有名なのですでに知っています。
C君は映画に詳しく、自分の好みも知っていたので、「『スーパー!』、ちょっと前の『キック・アス』もいいよ！」と自分が知らなかっただけで、好みに合う映画をお薦めしてくれました。
つまり、多くの人に聞くことで、自分の好みに合う映画を見つけることができるようになります。聞くことができる友人の数が多ければ、その可能性はさらに高くなります。これが集合知のメリットで、先ほど紹介したように多くのサービスで利用されています。
世の中には映画以外のアイテムのカテゴリが数多く存在し、それぞれのカテゴリで自分の好みを知り、詳しい人が居れば大変助かることでしょう。その数も多ければ多いほど、自分の好みに合ったアイテムに巡り会う事が出来ます。理想を言えば、ワインであればソムリエでしょう。数百、場合によっては数千種類のワインから、料理に合ったワインを選んでくれます。
「本日の鴨肉には、ピノで出来たワインが合います。●●さんの今までの好きなワインからすると、ブルゴーニュのものは香りが合わないと思うのでカルフォルニア、▲▲で作っているこのワインでしょう」と、ワインとそれを推薦する理由を教えてくれます。これが集合知を使うことで目指す推薦、ソムリエの推薦です。
ですが、意思決定の際に、常にそういったことを聞ける人がいるとは限りません。また、彼らの意見を集約する時間がない場合もあります。ネット上で彼らの集合知を使ったのがレコメンドシステムです。
集合知の利用
レコメンドシステムを実現するためには何が必要でしょうか？ 先ほど述べたように情報フィルタリングの一種ですから、どのようなフィルタを設計するかがポイントです。もっと詳しく言うと、役立つ情報が含まれているデータを準備して、そこから役立つ情報を取り出す処理、アルゴリズムが必要になります。
ここで各サービスのレコメンドにおいて、使われるデータとアルゴリズムを見てみましょう。
表1 各レコメンドにおけるデータとアルゴリズムの例
| サービス | データ | アルゴリズム |
|---|
| ECサイト | 購入履歴、アイテムのメタデータ | ユーザ間およびアイテム間の類似性に基づくレコメンド |
| SNS | お友達リスト、訪問履歴 | リンク構造解析に基づくレコメンド |
サーチ
エンジン | ページのコンテンツ、リンク情報、クリック履歴 | コンテキスト＋リンク構造解析に基づくレコメンド |
アルゴリズムの肝は、どのようにユーザあるいはアイテム間の類似性を定義するかにあります。レコメンドでよく使われるアルゴリズムがどのように類似性を定義するかを見てみましょう。
表2 レコメンドにおける類似性の定義例
| | ユーザベース | アイテムベース |
|---|
協調
フィルタ
リング | ユーザ間の類似性を、該当ユーザ間の行動の類似性（同じアイテムをアクセスしたなど）で定義 | アイテム間の類似性を、両アイテムにアクセスした同一ユーザの数を基に定義 |
|---|
コンテンツ
ベース | ユーザ間の類似性を、該当ユーザ間のプロファイルの類似性で定義 | アイテム間の類似性を、アイテム間のメタデータ（アイテムが本であれば、本に含まれる単語）の類似性で定義 |
|---|
図1の協調フィルタリングのユーザベースでは本の趣味の類似性により、趣味が合うユーザを発見し、それらユーザのお気に入りの本をターゲットユーザにレコメンドすることになります。
ユーザベースレコメンドシステムは「過去に同じような行動（たとえば、同じアイテムを購入）をした人たちは好みが似ている。したがって、この中で人気のあるアイテムは、このグループの他の人にも気に入られるだろう」という仮説に基づいてアイテム推薦を行っています。
そこで、レコメンドシステムはデータから類似した人を探し出し、興味や嗜好が類似する他人の目を通し、それに適ったアイテムを推薦しています。もし、履歴が100万人分あれば、瞬時に100万人に聞いた上で最適な答えをレコメンドシステムが教えてくれることでしょう。
先ほどの映画の例では、C君とB君はA君より自分の趣味に近いので、そのように類似度を計算できるアルゴリズムが必要です。レコメンドでは類似性の定義が大事で、この定義の違いがアルゴリズムの種類の豊富さにつながっています。
図1 協調フィルタリングのユーザベースのレコメンド：人を通したフィルタリング
実際には類似性は計算できても、各ユーザの専門性まではなかなか把握できないので、ソムリエを特定するのは難しいです。つまりC君とB君がA君より自分に近いことはわかっても、C君とB君の区別が難しいということです。したがって、推薦されるアイテムには意外性がない、既知のアイテムがあり、現状のレコメンドシステムはまだまだ発展の余地があるといえるでしょう。
次回は、これらのデータやアルゴリズムを実装する課題と解決方法について見ていきます。
