はじめまして、Marketing Solution Division所属の岩永と申します。Marketing Solution Divisionでは、主にKDDIグループ会社に対し、データ分析観点でのコンサルティング、ソリューションの提供などを行っています。
ARISEでは現在、新規ソリューションとしてレコメンドエンジンの開発を進めています。レコメンドエンジンと聞くとあまり馴染みのない方もいらっしゃるのではないかと思い、今回を含め全3回で、レコメンド自体の概要から、どのような仕組みを用いているのか、具体的にどのように大規模データを扱っているのかなどを紹介する予定です。
初回はレコメンドとは何なのか、一般的にどのような仕組みで動いているのか、などを紹介していきます。
レコメンドとは
レコメンドエンジンは、推薦システムと呼ばれることもありますが、その名の通りユーザに何かをおすすめするしくみです。レコメンドエンジンやレコメンドという言葉に馴染みがなくても、普段ネットに触れていると、自然と触れている事が多いと思います。
身近なものだとネット通販や動画配信サービスの「この商品(動画)を見た人はこちらも見ています」「あなたへのおすすめです」や、ユーザの属性や興味関心を元に表示されるターゲティング広告などが、まさにレコメンドです。
例えば、マウスを探しているときに「こういうマウスもありますよ」「ご一緒にマウスパッドもいかがですか？」と教えてもらったり、ドラマや映画、アニメなどを1シリーズ見終わった後に「続編やスピンオフもありますよ」と提案してもらったり、ヒントとなるようなものを自動でおすすめしてくれるため、重宝している方も多いかもれません。
どうやっておすすめしているの？代表的なアルゴリズムは？
ユーザが「マウスを探していたので、次はマウスパッドを探します」「1シリーズ見終わったので、関連作品を見ます」などと、明示しているわけではないのに、どうして行動を先読みできるのでしょうか。それは、以前に同じことをしている人が多いからです。
通販や動画配信サイトでは、毎日大量のユーザから様々なアクセスが行われます。この人はこれを見た、その後にこれを見た、これは候補として表示されたけど、選ばれなかったなど、大量のログが蓄積されていきます。このログを用いることで、「今マウスを見た人がいるが、今までこのマウスを見た人はこのマウスパッドに興味を持つことが多かったので、きっとこの人もマウスパッドに興味を持つだろう」と、先読みして推薦できるのです。
このような仕組みは協調フィルタリングと呼ばれ、レコメンドエンジンでは頻繁に用いられています。長くなるのと、わかりやすい説明がすでに多数なされているため、協調フィルタリングの説明はここでは割愛させていただきます。
協調フィルタリング以外のアルゴリズムとしては、この商品を買った人には必ずこれを出すといったルールベースや、商品自体の情報を使うコンテンツベースがあります。コンテンツベースについては後ほど説明します。
協調フィルタリングの弱点は？
協調フィルタリングを行う際のデータの大きさは、商品数*ユーザ数となります。商品数・ユーザ数が増えていくと、データの大きさが数億数兆のオーダーになることもあり、そのまま処理するには、相応のスペックのマシンと、時間が必要になります。現在我々が開発しているレコメンドエンジンの導入先では、商品数が数千万、ユーザ数が数百万であり、素直に協調フィルタリングを行うことができませんでした。
そこで、word2vecを導入し、各ユーザのログをベクトル化することで、巨大なデータに対しても擬似的に協調フィルタリングを行うことができました。word2vecは、一般的には文書中の単語の出現傾向から単語にベクトルを付与する手法として、機械翻訳や文書要約など、自然言語処理の分野で用いられることが多い手法ですが、レコメンドで用いることもできます。word2vec自体の詳しい説明も、長くなるため割愛させていただきます。
ユーザごとに閲覧した商品IDを時系列で並べword2vecを用いると、各商品にベクトルを付与できます。近くで出現することが多いID、すなわち近いタイミングで閲覧された商品は、ベクトルの値が近くなるように紐付けがされます。このベクトルが近い商品同士をレコメンドすることで、「擬似的に」協調フィルタリングを実現できました。「擬似的に」と書いたのは、厳密には処理の結果レコメンドされるものが協調フィルタリングとは異なるからです。word2vecでは単語1個ずつに注目し、その単語から一定範囲の前後にどういった単語が出現しているのか、出現頻度で紐付けを行います。
上の例では、文中のeatという単語に注目しています。
eatの1単語前にはto、1単語後にはmanyがあり、紐付けする範囲Wを1単語とした場合、この文ではeatにtoとmanyが紐付けされます。Wを2にした場合、wantとsushiも紐付けされるようになります。
この紐付けする範囲Wをウィンドウサイズと呼びます。ウィンドウサイズを調整することで、一定範囲内の単語のみを紐付けします。用いるモデルによって異なりますが、ウィンドウサイズには5や10が推奨されています。注目する単語をずらしながら、大量の文章で学習を行います。学習が完了すると、ある単語が別のどんな単語と類似しているか(どんな単語と近くで使われやすいか)、数値で出力できるようになります。
例えばeatとは、上の例のsushiや、ramenといった食べ物を表す単語や、restaurantやdishといった、食事を表す単語と類似度が高い、と出力されるでしょう。一方、computerなど、並べて使われることの少ない単語は類似度が低い、と出力されることが予想できます。
レコメンドでは、商品IDを単語とみなし各ユーザが閲覧した商品のIDを時系列に並べることで、ある商品が別のどんな商品と近くで閲覧されているのかをもとに、商品間の類似度を出力できます。
商品AからGまで順番に閲覧したユーザがいたとすると、商品Dの後に見た商品Eや、Dの直前に見た商品CはDと類似度が高そうだ、と考えることができます。一方で、商品Aと商品Gは閲覧したタイミングが遠く、あまり類似度が高くなさそうだと予想できます。この類似度を用いることで、閲覧ログからレコメンドを出力しています。
ウィンドウサイズを無制限にすると、1ユーザの行動内すべてで紐付けが行われますが、一定数に設定することで、直近で閲覧された商品のほうがより類似度が高くなるようになります。
1日のうち朝と夜に見たペアよりも、直前直後に見たペアのほうが類似度が高いと考え、直近に閲覧した商品に絞って紐付けされるようにしています。
ログがないときはどうするの？
協調フィルタリングでは、「この人はAを見て、Bも見て、Cは見なくて、Dも見なかった」「別の人はAとBは見なかったけど、CとDは見た」といったログを用いて、「Aを見たならBも見るだろう」とレコメンドしています。
一方、サイトを開設したばかりでユーザがほとんどおらず商品間の関連性がわからない、ということや、新商品を追加したためまだ誰も見ておらず、どういった商品と紐付ければよいのかがわからない、ということもあります。この問題はコールドスタート問題と呼ばれ、協調フィルタリングだけでレコメンドを行うのであれば、協調フィルタリングが使える程度のログが貯まるまで待つしかありません。これも協調フィルタリングの弱点です。
しかしそれでは、他のレコメンドがしっかり表示されているサイトにユーザが流れてしまったり、いつまで経っても商品が見られず、ログが十分に蓄積されなかったりする可能性があり、別の対応をする必要がありそうです。そういったときに使えるのが、コンテンツベースによるレコメンドです。コンテンツベースではユーザの行動履歴を参照するのではなく、コンテンツ(商品や動画)自体の情報を用いてレコメンドを行います。まだ誰も見ていない商品でも、その商品と似ているものがあれば出してしまおう、という発想です。
例えば新しいマウスが登録されたとします。マウスはカテゴリとしては「PC周辺機器」に分類できますし、値段やメーカも、マウスという商品に付随した情報となります。説明文からは、無線なのか有線なのか、充電式なのか乾電池式なのか、なども読み取ることができます。こうした情報を使い、すでに登録されている商品から似たようなマウスを探し出して、レコメンドを出力できます。
我々のレコメンドエンジンでは、word2vecを使って商品の説明文をベクトル化することで、コンテンツベースによるレコメンドを実現しています。先程説明した商品IDを並べる手法ではなく、説明文をベクトル化し近い商品をレコメンドする、という一般的なやり方です。(余談ですが、2種類の使い方があるため、文脈なしに「w2vのモデルが～」という話をすると、「どっちの？」となります。笑)
しかし、コンテンツベースにも弱点があります。それは、似た商品しかレコメンドできないという点です。マウスを選んでいるときであればまだしも、すでにマウスを買った人に「今買ったマウスとこのマウス似てますよ！どうですか！」とおすすめしても、誰も買いません。また、「見た後」と「買った後」では出すべき商品が違ってくるので、どの画面に表示するかにより手法を使い分ける必要がありますし、ここまで紹介した2つの手法もバランス良く使っていく必要があります。
まとめ
今回は、レコメンドの一般的な手法についてお話しました。レコメンドは通販や動画配信サイトを始め様々なところで用いられており、よりユーザの興味関心に合致したものがおすすめされるよう、様々な手法が取り入れられています。過去には、単独企業による賞金付きのアルゴリズムコンテストもありました。
次回は、大量のデータを並列処理するためにSpark上に機械学習モデルを載せ、分散推論させる話について掲載する予定です。お楽しみに！
