Hadoopでレコメンドシステムを作ろう

第9回 進化するレコメンドシステム

この記事を読むのに必要な時間:およそ 2 分

この連載も今回で最終回。最後にまとめとレコメンドシステム作成の周辺の話題を取り上げます。

レコメンドのアルゴリズムとその目的

今回紹介したレコメンドのアルゴリズムは,協調フィルタリング,およびコンテンツベースフィルタリングに属するものでした。それぞれに対してユーザベースおよびアイテムベースのアルゴリズムが存在します。

さらにそれぞれに対し,類似度に既存の関数を利用,あるいは新規に関数を定義したり,重み付けの種類等で数多くの派生形が存在します。

数あるレコメンドのアルゴリズムの選択基準は,導入するサービスの目的やビジネスモデル,ユーザのタイプ,及び現時点で利用可能なデータの量および質に依存します。たとえば,検索サービスやECサイトでは,各ユーザの検索を効率化=サービスの利用時間を短くするレコメンドが,コミュニティサイトやポータルサイトでは,各ユーザの滞留時間=サービスの利用時間を長くするレコメンドが求められます。

つまり,今回紹介したアルゴリズムの派生形を含め数多くのアルゴリズムが存在するということは,目的に応じて最適なアルゴリズムがあるとも言えます。

また,1つのアルゴリズムだけでなく,複数のアルゴリズムを併用する方法もあります。

レコメンドの評価は?

評価には大きく分けて,レコメンド結果の評価,およびレコメンドシステムの評価があります。

レコメンド結果の評価も,レコメンドを導入するサービスにより異なります。サービスの判断ポイントとしては,

  • レコメンド対象のアイテムは何度も購入(アクセス)するものか? 1回きりのものか?
  • レコメンド対象のアイテムは嗜好品か実用品か?
  • アイテムの購入(アクセス)頻度と時間のどちらを優先するか?
  • ユーザのアイテム消費期間の長さ
  • アイテムの更新頻度

などがあります。

具体的な指標には,以下のものがあります。

  • 適合率,再現率,被覆率
  • 推薦アイテムの新鮮度,人気度
  • Gini係数
  • クリック率
  • リピート率
  • user stickiness

一方で,レコメンドシステム自身の評価指標には他のシステムと同様に次のようなものがあります。

  • レスポンスタイム
  • スループット
  • 初期導入コスト

また,定量化しにくいのですが,レコメンドのシステム全体の使い易さ,管理および運用コスト,さらに他のシステム(顧客管理や課金/決済など)との相性や連携のし易さも求められるでしょう。

レコメンドの将来像は?

レコメンドの対象と実現方式が変わってくるでしょう。レコメンドの進化は,利用可能なデータの種類と適用領域の拡大を契機とし,その結果,新しいアルゴリズムが孵化してきたともいえます。これを段階的に見てみたいと思います。

第一段階はこれまで紹介した,履歴やアイテムのメタデータ等を使ったレコメンドでした。これらのデータ量が大きくなるにつれ,データの処理や計算の問題が出てきました。

今回はこの問題を解決するためにHadoopを用いました。Hadoopを用いると,低コストで処理可能なデータサイズや速度をスケールアウトできる,また処理ロジックに集中できるというメリットがあります。

第二段階は,ユーザ間のネットワークを使ったレコメンドで,すでに実用的なものが登場しつつあります。もう一度,現実世界でどのようなレコメンドが行われているか思い出してみましょう。

たとえば,第1回で紹介した友人からのレコメンド方式です。映画の趣味が完全一致しない友人でも,映画に詳しい,あるいは日ごろコミュニケーションをとっている人のお薦めであれば,⁠観てみようかな?」という気になるでしょう。

レコメンドの研究及び実用が始まったころは,利用可能なデータと言えば,履歴やアイテムの評価リストでした。最近はソーシャルメディアが浸透し,従来の履歴やアイテムだけでなく友人関係がわかるため,これらのデータを使えばその友人関係を定量化することができます。この定量化した関係の強さを使ってレコメンドを実現する方法が出てきています。もちろん,この関係の強さを計算するのにもHadoopは有効です。

ここからは研究段階にあるものです。

第三段階は,テキスト解析と融合したレコメンド方式です。これは第二段階でも利用したソーシャルメディアのデータを使います。たとえば,アイテムのレビュー等を組み合わせて,各アイテムの特徴やそれに対する評価もレコメンドの入力データとして利用が可能になりました。

同一カテゴリでもアイテムの価格が購入判断の基準になる人もいれば,デザイン,機能の豊富さ,あるいはカスタマーサービスの有無が判断の基準になる人もいるでしょう。この判断基準の違いをレコメンドの結果に反映できるだけでなく,レコメンドの理由として提示することが可能になります。また,ユーザの購入の直前で推薦するのではなく,購入動機が芽生えた段階で推薦することもできるようになります。

第四段階は,アイテムのレコメンドから自動生成に移るのではないでしょう。

今までのレコメンド方式は,すでにあるアイテムから選択し,ユーザに紹介するものでした。たとえば,自分の好きな作家に自分向けに小説を書き下ろしてもらいたい,あるいはアーティストに,自分だけのオリジナルソングを創って欲しいと思ったことはないでしょうか?これらのニーズに応えるのが,レコメンドの進化系の一つと考えられます。

かなり突飛な話に聞こえるかもしれませんが,現在,メーカはユーザの感想やレビューを参考に商品開発を行っていますので,レコメンドアルゴリズムの進化により,まずはデジタルコンテンツに対して適用される日も近いと思います。

映画であれば,ターミネータ4(2009年)「シュワちゃんを見たい!」という声に応えて? 若き日の彼と体系がよく似たローランド・キッキンガーに出演してもらい,アーノルド・シュワツェルネッガーの(若い時の)顔を合成処理しています。

余談になりますが,彼が若い時に主演したバトルランナー(1987年)の中での話(ベン・リチャーズとキャプテン・フリーダムの対決シーンの合成)が,もう現実の話になっています。

今回はレコメンドシステムでも,Hadoopでレコメンドのアイテムリストを作るアルゴリズムが中心で,実際にユーザに提示するまでのシステムの話までできませんでした。期待されていた皆様には,深くお詫びを申し上げます。


最後になりましたが,これまでの連載にお付き合いくださった皆様,連載の機会を与えてくれた技術評論社の皆様,そしてこの連載を応援および支援してくださった上司,そして同僚の皆様にこの場を借りて御礼申し上げます。

著者プロフィール

川前徳章(かわまえのりあき)

工学博士,NTTコムウェア 研究開発部 勤務。専門は情報検索,統計的機械学習,マーケティングサイエンス。現在はレコメンドシステムと感性検索の研究と開発に従事。

東京電機大学安田研究室 研究員

コメント

コメントの記入