この記事の目的

この記事は、オライリーの「推薦システム実践入門」をまとめたもので、個人の学習目的で書いています。そのため、ややまとまりの無い箇所があるかもしれませんが、ご了承ください。

第1章　推薦システム

推薦システムの定義

今回の書籍において、推薦システムとは、複数の候補から価値のあるものを選び出し、意思決定を支援するシステムと定義されています。

複数の候補から価値のあるものを選び出すとは、推薦のアルゴリズムの事を指します。価値のあるものはそのサービスを利用しているユーザーによりけりであるため、ユーザーが高く評価するアイテムを精度高く予測する事だけが、アルゴリズムの選定基準にはなりません。

意思決定を支援するとは、アルゴリズムで選び出した価値のあるアイテムを実際にユーザーに適切なタイミングで表示することを表します。例えば、amazonにおける商品ページでは、「よく一緒に購入されている商品」や「この商品に関連する商品」などに分けられて、商品が推薦されています。アルゴリズムで選び出されたアイテムがユーザーにとって適切な形で表示されることで、サイト上でのユーザーエクスペリエンスの向上に繋がっています。

推薦の計算の種類

推薦システムの構築に使用されるデータは、アクセスログなどのユーザーとアイテムのインタラクション情報やユーザーやアイテムの属性情報が利用されます。
それらのデータから、計算する推薦の種類は、概要推薦、関連アイテム推薦、パーソナライズ推薦の三つがあります。概要推薦とは、売上順や価格が安い順など全ユーザーに対して同じ内容を表示するものです。amazonであれば、売れ筋ランキングなどが該当します。関連アイテム推薦とは、よくアイテムページの下に出でくるようなそのアイテムに似ている商品を推薦する方法です。そして最後のパーソナライズ推薦は、ユーザーの属性や行動を元にパーソナライズした推薦を行います。アイテムや属性情報のみを使用するもの、インタラクション情報のみを使用するもの、それら二つの情報を使用するものがあります。
これらの推薦の計算から、ユーザーにとって価値のあるものを選び出し、アイテムを適切な形で表示します。

第2章　推薦システムのプロジェクト

推薦システム開発に必要な3つのスキル

本書では、推薦システム開発に必要な三つのスキルを、ビジネス力、データサイエンス力、データエンジニアリング力と定義しています。これらのスキルは、基本的にデータサイエンティストに必要な三つのスキルと言われています。
ビジネス力とは、推薦システムの導入によるユーザーの行動の変化がユーザーエクスペリエンスの向上に繋がるよう課題を設定する力だと考えられます。具体的には、推薦システムを導入する際に、KGIやKPIを設定することが重要になります。明確なKGI、KPIを設定し、それらを達成するための手段として推薦システムが存在するというわけですね。したがって、サービスによっては必ずしも機械学習のような高度なアルゴリズムを利用する必要はありません。
データサイエンス力とは、設定したビジネス目標を達成するために、実際に推薦システムに落とし込む力です。落とし込む過程で、まず王道な方法から試し、理想とする推薦システムと現実のギャップが大きすぎないか確認します。アルゴリズムを試していく中で、データの性質やアルゴリズムの長所・短所を把握しておくことで、理想的なシステムの実現までの時間を短縮する事が出来ます。
データエンジニアリング力とは、ビジネス要件を考慮した上で実装を行い、システムを安定的に稼働させる能力である。推薦の計算が要件よりも時間がかかってしまう場合、そのシステムを実サービスに実装することはできません。したがって、計算を並列化し、早く計算を終われるようにするなど、データエンジニアリングにおけるスキルが求められます。

推薦システムのプロジェクトの進め方

推薦システムのプロジェクトの進め方は以下の通りです。

課題定義
仮説立案
データ設計・収集・加工
アルゴリズム選定
学習・パラメータチューニング
システム実装
評価・改善

1, 2, 7は主にビジネス力が必要になり、3, 4, 5, 6, 7はデータサイエンス力・データエンジニアリング力が必要になります。
課題定義では、事業上のKPIを定め、KPIの目標と現状の差を分析し、その差を課題として定義し、KPIを達成するためには、どこに伸びしろがあるのかを分析します。仮説立案では、定義した課題に対する打ち手を検討します。打ち手を実行することで発生するROIを基準に取り組む優先順位を決定します。この打ち手として推薦システムが活用されます。したがって、推薦システムの導入よりも高いKPIを達成する打ち手が他にあれば、そちらを優先すべきです。
データ設計・収集・加工では、推薦システムに必要なデータが自社内に蓄積されているのかを整理していきます。使用するデータに不適切なデータ（ボットやクローラーなどによるログ）が含まれている場合、それらを適切に取り除くなどの加工が必要になります。
アルゴリズム選定では、アルゴリズムの計算時間、必要なデータ、求められる予測精度などの様々な観点から、推薦の計算に使用するアルゴリズムを選定します。モデルの予測精度を1%上げるためには、多大なコストがかかる場合があるため、サービスの初期では簡単なアルゴリズムを実装していくことが大切です。
学習・パラメータチューニングでは、推薦システムをオフラインでの効果検証を行います。モデルの精度だけではなく、実際のサービスに組み込まれた場合、納得感のある推薦が出来ているかを確かめることが重要です。予測精度が上がったけれでも、KPIはめちゃくちゃ落ちたみたいなことがあるとシステムそのものの意味が無くなってしまうからです。
システム実装では、オフラインで効果検証を終えた推薦アルゴリズムを実サービスに実装します。学習・予測の更新頻度や新規のアイテムやユーザーに対してどう推薦するのか、データのパイプラインをどうするかなどシステム周りの設計を行います。
評価・改善では、実際にサービスに実装した後、効果があったのかを検証し、その検証結果から推薦システムを改善していきます。

第3章　推薦システムのUI/UX

ユーザーの目的に応じたUI/UX

本章では、推薦システムの定義である「複数の候補から価値のあるものを選び出し、意思決定を支援する」の後半部分にあたる「意思決定を支援する」ことに焦点を当てています。具体的には、アルゴリズムでユーザーにとって価値のあるものを選び出し、その価値あるものを適切な形でユーザーに届ける方法について記述がされています。ユーザーに価値あるものを届ける方法について、本書ではまず、サービスのユーザーの目的別に事例が紹介されています。ユーザー目的は、主に以下の４つに分類されます。

適合アイテム発見
適合アイテム列挙
アイテム系列消費
サービス内回遊

適合アイテム発見とは、ユーザーが目的を達成するのに適したアイテムを一つでもいいのでサービス上で発見しようとしている場合を指します。例えば、「金曜日の夜に、映画のサブスクリプションサービス上で、今から見たい映画を探している」状態が考えられる。この目的におけるアイテムの効果的な表示方法は、ユーザーの好みに合う可能性の高いアイテムから順に整列したリストをユーザーに提示する方法です。
適合アイテム列挙とは、ユーザーが目的を達成するのに適したアイテムをできるだけ全てサービス上で発見しようとしている場合を指します。例えば、「年末休みの旅行プランをじっくりと検討して決めたい」という状態が考えられます。つまり適合アイテム発見との違いは、適合アイテムを選択することで、後悔をしたくないという気持ちが強く、条件に合うアイテムを網羅的に比較し検討したいという思いが強くなります。したがって、アイテムの提示方法もユーザーの検索条件に合うアイテムを網羅的に表示することが効果的な方法と言えます。
アイテム系列消費とは、アイテムを閲覧・消費していく中で、推薦されたアイテムの系列全体から価値を得ることを目的とする状態です。例えば、音楽のストリーミングサービスにおいて、ある楽曲単体を聴く事に意味があるだけでなく、次々と再生される楽曲をその順番で聴くことに意味があります。ユーザーが明るい曲を聴いた場合、次に再生される曲も明るくあってほしいなどを考えるかもしれません。他にも、amazonで充電ケーブルを購入する時、充電アダプターも一緒に購入することを検討したいかもしれません。
サービス内回遊とは、ユーザーが利用しているサービス本来の目的を達成するためでなく、ただアイテムを閲覧する事自体を目的としてサービス内を回遊する状態を指します。例えば、今すぐに旅行をする計画は無いが、どんな観光地があるのか、どんなホテルがあるのかを眺めることを目的としてサービスを利用しているというような状態です。ユーザーがこの目的でサービスを利用している場合、購入を過度に促すような推薦を行ってしまうとユーザーの満足度が下がってしまい、サービスを利用しなくなってしまいます。したがって、概要推薦のようなサービス内の人気アイテムや特定のカテゴリの新着アイテムなどを推薦することで、なんとなく面白い・興味を持てそうなアイテムがサービス内にあることを感じてもらうことがユーザーの満足度を上げるのに効果的です。

関連トピック

アイテムの「類似度」

ユーザーが購入したアイテムと類似度の高いアイテムを推薦することで、クロスセルなどが達成できる場合がありますが、アイテムによっては類似度の高いアイテムを推薦することが、UXの低下に繋がる可能性があります。例えば、プリンターを購入したユーザーが新たに別のプリンターを推薦されたとしても、購入する確率は低いです。プリンターを購入した場合、プリンターを補完するようなアイテム（インクカートリッジ、コピー用紙など）を推薦するべきです。類似度の高い「代替する」ような商品を推薦するのか、それともアイテムを「補完する」ような商品を推薦するのかは、ユーザーのニーズに応じて設計するべきです。

ノベルティ・セレンディピティ・ダイバーシティー

サービスによっては、ユーザーの関心のあるアイテムのみを推薦することに加えて、推薦に別の要素を求められる場合があります。一つ目のノベルティ（目新しさ）は、ユーザーにとってのアイテムに対する「関心」と「新規性」を満たす状態です。例えば、ユーザーがある作家のファンで、このユーザーにその作家の最新作を発売日に推薦した場合、ユーザーにとってその最新作は「関心」と「新規性」を満たしている事になります。二つ目のセレンディピティは、これは「関心」「新規性」に加えて、思いがけなさや予見のできなさといった「意外性」の要素が推薦されるアイテムに加わることです。例えば、ユーザーが好きな作家と作風がよく似た新人作家の作品を推薦することは、「関心」「新規性」に加えて、この作家が好きな作家と作風が似ていることを予見できないので「意外性」があると言えます。しかし、このセレンディピティに必要な「意外性」というユーザーの定性的な指標を定量的に計測することは困難であるため、「ダイバーシティー（多様性）」という観点で定量的に計測されます。「ダイバーシティー（多様性）」とは、推薦される複数のアイテムが互いに似ていないことです。

第4章　推薦アルゴリズムの概要

本章では、推薦システムの定義である「複数の候補から価値のあるものを選び出し、意思決定を支援するシステム」の前半部分である「複数の候補から価値のあるものを選び出す」ことを実現する推薦システムのアルゴリズムについて説明します。以下の表に概要をまとめました。

	内容ベースフィルタリング	協調フィルタリング
アルゴリズムの概要	ユーザーの好みを表すユーザープロファイルとアイテムの属性を表すアイテム特徴の類似度を元に推薦するアイテムを決定する。	ユーザーと好みの似ているサービス内の他のユーザーの過去の行動などから得られる好みの傾向を利用し、推薦するアイテムを決定する。推薦を行うタイミングで推薦アイテムを予測するメモリベース法と事前にモデルを作成し推薦するタイミングで予測するモデルベース法がある。
多様性の向上	×	○
ドメイン知識を扱うコスト	×	○
コールドスタート問題への対応	△	×
ユーザー数が少ないサービスにおける推薦	○	×
被覆率の向上	○	×
アイテム特徴の活用	○	×
予測精度	△	○

続いて、内容ベースフィルタリングと協調フィルタリングの比較を行います。比較項目に関して、それぞれのアルゴリズムが苦手とされていた項目を改善するアプローチが研究されています。ここでは、それぞれの標準的なアルゴリズムの性質について比較を行います。

多様性の向上

協調フィルタリングでは、推薦を受けるユーザー自身が知らないアイテムでも、ユーザーと好みの似ている他のユーザーが知っており、評価をしていれば、その情報を元に推薦できるため、多様性を向上させることができます。一方、内容ベースフィルタリングでは、推薦を受けるユーザーのユーザープロファイルには、未知のアイテム情報は反映されません。従って、推薦を受け取るユーザーが知らない情報をアイテム特徴として持つアイテムとユーザープロファイルの類似度が高くなりにくく、多様性のある推薦をすることが難しくなります。

ドメイン知識を扱うコスト

協調フィルタリングでは、推薦を受け取るユーザーと好みの似ているユーザーがどのようなアイテムを好むのかの情報を元に推薦を行うため、ドメイン知識に基づくアイテムの属性情報やユーザーの属性情報は基本的には不要です。従って、ドメイン知識を扱うコストは低いと言えます。一方で、内容ベースフィルタリングは、ユーザーが好むアイテムと似ているアイテムを決める際に、アイテムの属性を表すアイテム特徴を使用します。この際に、適切にドメイン知識を活用し、アイテム同士の類似度を決めるアイテム特徴を定義しなければなりません。従って、内容ベースフィルタリングでは、ドメイン知識を扱うコストは高いと言えます。

コールドスタート問題への対応

コールドスタート問題とは、サービス内でのユーザーやアイテムに関する情報が少ない場合、特に新規ユーザーや新規アイテムについて推薦を行うことが困難になる問題です。
協調フィルタリングでは、ユーザーの過去の行動履歴などが無い場合、ユーザーの好みを把握することが困難になるため、コールドスタート問題への対応は難しいと言えます。一方で、内容ベースフィルタリングでは、ユーザーがサービスに登録する際、明示的に好みを入力してもらうことが出来れば、ユーザーの好みを把握することができ、その好みに似たアイテムを推薦することが出来ます。新規アイテムであっても、アイテム特徴が与えられていれば、ユーザープロファイルに基づいて推薦を行うことが出来ます。しかし、ユーザーに好みを入力してもらった場合でも、ユーザープロファイルを完全に獲得することは困難であるため、コールドスタート問題に完全に対応できる訳ではありません。

ユーザー数が少ないサービスにおける推薦

ユーザー数が少ないサービスにおいて、推薦対象のユーザーと十分似ているユーザーの行動履歴を獲得することが困難になります。従って、サービス内の他のユーザーの行動履歴を元に推薦を行う協調フィルタリングを用いて、良い推薦を行うことは難しい傾向にあります。一方、内容ベースフィルタリングでは、アイテム特徴や推薦対象のユーザープロファイルさえ獲得することが出来れば、推薦を行うことが出来るので、システム内のユーザ数はあまり推薦に関係はありません。

被覆率の向上

被覆率とは、サービス内にあるすべてのアイテムのうち、推薦システムでユーザーに推薦することが出来るアイテムの割合のことです。協調フィルタリングでは、推薦対象のユーザーに似ているユーザーがまだ試していないアイテムを推薦することが困難であるため、被覆率を向上させることは困難な傾向にあります。一方で、内容ベースフィルタリングでは、推薦対象のユーザーのプロファイルと関連するアイテム特徴を有するアイテムであれば、サービスに存在するどのアイテムでも推薦可能であるため、被覆率の向上という観点では優れています。

アイテム特徴の活用

アイテム特徴をうまく活用した推薦が行えるかという観点では、内容ベースフィルタリングの方が優れた性質を持っています。ドメイン知識を利用せずにユーザーの過去の嗜好データのみに基づいて推薦を行う協調フィルタリングにおいては、服の色が何色であるかなどのアイテム属性情報を基本的には考慮することが出来ません。一方、内容ベースフィルタリンでは、アイテムの様々な特徴を明示的に考慮した上で推薦を行うため、アイテム特徴をうまく活用した推薦をすることが出来ます。

予測精度

予測精度の観点において、常にどんな状況においてもどちらかのアルゴリズムが優れているという訳ではありません。ここでは、ある程度の規模のサービスにおいて、多数派である一定以上のアクティブにサービスを利用している一般的な嗜好傾向を持つユーザーに対する推薦を考えます。この場合、内容ベースフィルタリングよりも協調フィルタリングの方が、高い精度で予測を行うことが出来ると一般的に言われています。様々なユーザーの行動履歴を推薦結果に反映できる協調フィルタリングの方が複雑なユーザーの嗜好を考慮できるからと考えられています。

最後に

今回の記事では、第1章から第4章まで取り上げました。次回は、より具体的な推薦アルゴリズムの実装を行い、実験したいと思います。ここまで読んでくださり、ありがとうございました。