分この連載も今回で最終回。最後にまとめとレコメンドシステム作成の周辺の話題を取り上げます。今回紹介したレコメンドのアルゴリズムは,協調フィルタリング,およびコンテンツベースフィルタリングに属するものでした。それぞれに対してユーザベースおよびアイテムベースのアルゴリズムが存在します。それぞれに対し,類似度に既存の関数を利用,あるいは新規に関数を定義したり,重み付けの種類等で数多くの派生形が存在します。数あるレコメンドのアルゴリズムの選択基準は,導入するサービスの目的やビジネスモデル,ユーザのタイプ,及び現時点で利用可能なデータの量および質に依存します。検索サービスやECサイトでは,各ユーザの検索を効率化=サービスの利用時間を短くするレコメンドが,コミュニティサイトやポータルサイトでは,各ユーザの滞留時間=サービスの利用時間を長くするレコメンドが求められます。今回紹介したアルゴリズムの派生形を含め数多くのアルゴリズムが存在するということは,目的に応じて最適なアルゴリズムがあるとも言えます。1つのアルゴリズムだけでなく,複数のアルゴリズムを併用する方法もあります。レコメンドの評価は?評価には大きく分けて,レコメンド結果の評価,およびレコメンドシステムの評価があります。レコメンド結果の評価も,レコメンドを導入するサービスにより異なります。1回きりのものか?レコメンド対象のアイテムは嗜好品か実用品か?アイテムの購入(アクセス)頻度と時間のどちらを優先するか?ユーザのアイテム消費期間の長さアイテムの更新頻度などがあります。具体的な指標には,以下のものがあります。stickiness一方で,レコメンドシステム自身の評価指標には他のシステムと同様に次のようなものがあります。レスポンスタイムスループット初期導入コストまた,定量化しにくいのですが,レコメンドのシステム全体の使い易さ,管理および運用コスト,さらに他のシステム(顧客管理や課金/決済など)との相性や連携のし易さも求められるでしょう。レコメンドの将来像は?レコメンドの対象と実現方式が変わってくるでしょう。レコメンドの進化は,利用可能なデータの種類と適用領域の拡大を契機とし,その結果,新しいアルゴリズムが孵化してきたともいえます。これを段階的に見てみたいと思います。第一段階はこれまで紹介した,履歴やアイテムのメタデータ等を使ったレコメンドでした。これらのデータ量が大きくなるにつれ,データの処理や計算の問題が出てきました。今回はこの問題を解決するためにHadoopを用いました。Hadoopを用いると,低コストで処理可能なデータサイズや速度をスケールアウトできる,また処理ロジックに集中できるというメリットがあります。第二段階は,ユーザ間のネットワークを使ったレコメンドで,すでに実用的なものが登場しつつあります。一度,現実世界でどのようなレコメンドが行われているか思い出してみましょう。第1回で紹介した友人からのレコメンド方式です。映画の趣味が完全一致しない友人でも,映画に詳しい,あるいは日ごろコミュニケーションをとっている人のお薦めであれば,「⁠観てみようかな?」という気になるでしょう。レコメンドの研究及び実用が始まったころは,利用可能なデータと言えば,履歴やアイテムの評価リストでした。最近はソーシャルメディアが浸透し,従来の履歴やアイテムだけでなく友人関係がわかるため,これらのデータを使えばその友人関係を定量化することができます。この定量化した関係の強さを使ってレコメンドを実現する方法が出てきています。この関係の強さを計算するのにもHadoopは有効です。ここからは研究段階にあるものです。第三段階は,テキスト解析と融合したレコメンド方式です。これは第二段階でも利用したソーシャルメディアのデータを使います。アイテムのレビュー等を組み合わせて,各アイテムの特徴やそれに対する評価もレコメンドの入力データとして利用が可能になりました。同一カテゴリでもアイテムの価格が購入判断の基準になる人もいれば,デザイン,機能の豊富さ,あるいはカスタマーサービスの有無が判断の基準になる人もいるでしょう。この判断基準の違いをレコメンドの結果に反映できるだけでなく,レコメンドの理由として提示することが可能になります。ユーザの購入の直前で推薦するのではなく,購入動機が芽生えた段階で推薦することもできるようになります。第四段階は,アイテムのレコメンドから自動生成に移るのではないでしょう。今までのレコメンド方式は,すでにあるアイテムから選択し,ユーザに紹介するものでした。自分の好きな作家に自分向けに小説を書き下ろしてもらいたい,あるいはアーティストに,自分だけのオリジナルソングを創って欲しいと思ったことはないでしょうか?これらのニーズに応えるのが,レコメンドの進化系の一つと考えられます。突飛な話に聞こえるかもしれませんが,現在,メーカはユーザの感想やレビューを参考に商品開発を行っていますので,レコメンドアルゴリズムの進化により,まずはデジタルコンテンツに対して適用される日も近いと思います。若き日の彼と体系がよく似たローランド・キッキンガーに出演してもらい,アーノルド・シュワツェルネッガーの(若い時の)顔を合成処理しています。余談になりますが,彼が若い時に主演したバトルランナー(1987年)の中での話(ベン・リチャーズとキャプテン・フリーダムの対決シーンの合成)が,もう現実の話になっています。今回はレコメンドシステムでも,Hadoopでレコメンドのアイテムリストを作るアルゴリズムが中心で,実際にユーザに提示するまでのシステムの話までできませんでした。期待されていた皆様には,深くお詫びを申し上げます。最後になりましたが,これまでの連載にお付き合いくださった皆様,連載の機会を与えてくれた技術評論社の皆様,そしてこの連載を応援および支援してくださった上司,そして同僚の皆様にこの場を借りて御礼申し上げます。専門は情報検索,統計的機械学習,マーケティングサイエンス。2019」を開催しました。DAY1・DAY2の様子を注目セッションとともにお伝えします。LINEのエンジニア3名がイベントに先駆けて見どころを紹介します。コードの安全性・安定性を高める開発サイクル~テスト管理の効率を上げ,脆弱性診断を自動で行う~本連載では,連載「業務を改善する情報共有の仕掛け」を受けつつ,安全性・安定性を加えた開発サイクルについて考えていきます。若者世代から圧倒的な人気を誇るライブ配信&動画投稿コミュニティアプリ「MixChannel」(ミクチャ)の裏側(レコメンドシステムやサーバサイド開発など)について解説していきます。その他の連載CSS3アニメーションでつくるインターフェイス表現CSS3によるアニメーション表現を紹介していきます。その中でも,幅広い読者に応用してもらえるだろうインターフェイスを主なお題とします。MySQL道普請便り本連載では,MySQLを使ったアプリ開発・運用に関するノウハウをご紹介していきます。RecipeUbuntuの強力なデスクトップ機能を活用するための,いろいろなレシピをお届けします。JavaScriptセキュリティの基礎知識JavaScriptに関するセキュリティ上の問題はどこで発生し,どうすれば防ぐことができるのか?について解説していきます。〜システムをきちんと運用するための基礎知識システムは「作って終わり」ではなく,運用の中でさまざまな問題が発生します。問題の発生に備えて事前にどのような対応をしておくべきなのか,問題発生時に何をしなければならないのか,ポイントを解説していきます。きたみりゅうじの聞かせて珍プレーソフトウェア開発の現場で体験したトホホな失敗,思わずうなる珍プレーをきたみりゅうじ氏が四コママンガで紹介。Linuxのメンテナンスの傍ら,Linuxやオープンソースソフトと日々を過ごす著者が,その魅力とつきあい方を,エッセイ風味でお届けします。PRESS特別編集部員,さわやか笑顔のスーパーハカーはまちちゃんとネット大好き14歳わかばちゃんが,毎号,読者の皆さんから寄せられたおたよりを紹介します。皆さんの日頃の悩みにも答えちゃいますよ。]メールでのお知らせメールで次の案内をお送りしております。メールの配信を希望する方は,利用したい項目をチェックしてメールアドレスを入力し,[登録]ボタンをクリックしてください。UPDATES[ほぼ週間に1回]新刊メールマガジン[ほぼ週間に1回]電脳会議の各号案内[ほぼ1ヵ月半に1回]※変更する場合や停止する場合は,登録情報変更ページをご覧ください。※登録いただいたメールアドレスには,そのお知らせ以外,配信いたしません。Ltd.ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。