JP2005222297A

JP2005222297A - リコメンダシステムの評価方法

Info

Publication number: JP2005222297A
Application number: JP2004029357A
Authority: JP
Inventors: Keiichiro Hoashi; 啓一郎帆足; Kazunori Matsumoto; 一則松本; Fumiaki Sugaya; 史昭菅谷
Original assignee: KDDI Corp
Current assignee: KDDI Corp
Priority date: 2004-02-05
Filing date: 2004-02-05
Publication date: 2005-08-18
Anticipated expiration: 2024-02-05
Also published as: JP4212043B2

Abstract

【課題】実際にユーザに推薦結果を提示することなく、事前にリコメンダシステムの有効性を評価できるリコメンダシステムの評価方法を提供すること。
【解決手段】推薦対象アイテム情報３１の内から各ユーザが利用したアイテムをアクセス履歴３２として保持する。リコメンダシステムの評価に際し、リコメンダシステム1,2,・・・,nにより推薦されたアイテムを推薦結果一覧３３（１〜ｎ）として保持する。アクセス履歴ベクトル化処理３４、推薦結果ベクトル化処理３６は各アイテムに付随する属性情報に基づいてアクセス履歴３２、推薦結果一覧３３をそれぞれベクトル化する。生成された両ベクトルの類似度がベクトル類似度算出処理３８で算出される。
【選択図】図３

Description

本発明は、リコメンダシステムの評価方法に関し、特に、各アイテムに対するユーザのアクセス履歴などに基づいてユーザの嗜好を推測し、アイテムを推薦して提示するリコメンダシステムの評価方法に関する。

従来、各アイテムに対する全ユーザのアクセス履歴を収集し、アクセス履歴におけるユーザ間の相関値や類似度に基づいて対象ユーザの未評価アイテムに対する予測評価値を算出し、算出された予測評価値に従ってアイテム（商品など）を推薦するリコメンダシステムが知られている。

リコメンダシステム自体に関する特許、論文は多数公開されており、例えば予測評価値の算出に協調フィルタリング手法を採用したリコメンダシステムが下記特許文献１，２に記載されている。

また、協調フィルタリング手法を採用したリコメンダシステムの有効性を測るための評価方式には、下記非特許文献１で提案されたGiven-n方式やAll-but-1方式がある。

Given-n方式は、評価データ内の各ユーザのアクセス履歴からｎ件の履歴を除く全ての履歴を取り除いた上で、取り除かれた履歴に対する評価値と実際に協調フィルタリングにより得られた評価値の差分を算出することにより評価を行う手法であり、All-but-1方式は、評価データ内の各ユーザの履歴から１件だけのアクセス履歴を取り除いた上で、取り除かれた履歴に対する評価値と実際に協調フィルタリングにより得られた評価値の差分を算出することにより評価を行う手法である。

Given-n方式は、All-but-1方式に比較してユーザのアクセス履歴が少ない状況下での協調フィルタリング手法の頑強性を評価できる方式であるとされている。
特開平９−２６５４７８号公報特開平１０−２４０７４９号公報 John S.Breese et al:"Empirical Analysis of Predictive Algorithms for Collaborative Filtering"Proceedings of the 14th Annual Conference of Uncertainty in Artificial Intelligence, pp.43-52,1998

リコメンダシステムの有効性を測るための評価指標は、ユーザに対して推薦されたアイテムがそのユーザに適合し、その結果、該ユーザがそのアイテムを購入・利用するか否か測るべきものである。

しかしながら、上記記非特許文献１で提案されたGiven-n方式やAll-but-1方式では、ユーザが既に評価した結果から構成される評価データ内のアクセス履歴から一部履歴を取り除いた履歴に対する評価値と、実際に協調フィルタリングにより得られた評価値の差分を算出することにより評価を行う手法であるため、ユーザにとって既知のアイテムに対する評価しか行われていない。

つまり、リコメンダシステムは、本来、ユーザにとって未知のアイテムを推薦するシステムであり、未知のアイテムをユーザが購入・利用するか否かを評価すべきであるにもかかわらず、従来手法では既知のアイテムに対する評価しか得られていないため、リコメンダシステムの有効性を厳密に表す評価が行われていないといえる。

リコメンダシステムの有効性を厳密に評価するためには、実験システムなどを構築し、実際にユーザに対してアイテムの推薦を行い、その推薦結果がどの程度ユーザに受け入れられるかを測定する必要がある。しかし、この方法では有効性評価に手間がかかる上、複数の協調フィルタリングアルゴリズムを評価したい場合にはそれぞれに対応した複数の実験システムを構築する必要があり、現実的でない。

本発明の目的は、上記課題を解決し、実際にユーザに推薦結果を提示することなく、事前にリコメンダシステムの有効性を評価できるリコメンダシステムの評価方法を提供することにある。

上記課題を解決するために、本発明は、各アイテムに対する全ユーザのアクセス履歴を利用して対象ユーザへの推薦アイテムを抽出して提示するリコメンダシステムの評価方法において、リコメンダシステムで利用される各ユーザのアクセス履歴とリコメンダシステムから出力される推薦アイテム一覧との間の類似度に基づいてリコメンダシステムの有効性評価を行う点に第１の特徴がある。

また、本発明は、前記アクセス履歴と前記推薦アイテム一覧を各アイテムに付与されている属性情報に基づいてそれぞれベクトル化し、これにより生成された両ベクトル間の類似度を算出することにより、前記アクセス履歴と前記推薦アイテム一覧との間の類似度を算出する点に第２の特徴がある。

また、本発明は、アイテムが着信メロディであり、属性情報がアーティストおよびジャンルの少なくとも一方を含む点に第３の特徴がある。

さらに、本発明は、アイテムが携帯サイトあるいは携帯コンテンツである点に第４の特徴がある。

本発明では、リコメンダシステムで利用される各ユーザのアクセス履歴とリコメンダシステムから出力される推薦アイテム一覧との間の類似度に基づいてリコメンダシステムの有効性評価を行うので、実際にユーザに推薦結果を提示することなく、事前にリコメンダシステムの有効性を評価できる。

また、複数の協調フィルタリングアルゴリズムを評価したい場合にも、各協調フィルタリングアルゴリズムによる推薦アイテム一覧を得るだけでよいので、それぞれに対応した複数の実験システムを構築する必要がない。

また、アクセス履歴と推薦アイテム一覧を各アイテムに付与された属性情報に基づいてベクトル化することにより、アクセス履歴と推薦アイテム一覧の類似度を容易に算出できる。

以下、本発明を説明する前に、まず、リコメンダシステム自体について説明する。図１は、本発明が適用されるリコメンダシステムのブロック図である。

ログ収集モジュール１は、ユーザa,b,c,dが各アイテムを利用したときの評価値を収集する。収集された評価値は、アクセス履歴２として蓄積される。スコア算出モジュール３は、ユーザの未評価アイテムに対する予測評価値を算出する。算出された予測評価値はスコア算出結果４として保持される。推薦アイテム抽出モジュール５は、スコア算出結果４に基づいて予測評価値が高いアイテムをユーザに推薦する。

図２は、スコア算出の動作概要の説明図である。ここでは、ユーザa,b,c,d、アイテム(イ),(ロ),(ハ),(ニ),(ホ),・・・,(ヘ)が存在する場合を想定している。図２に示すように、ユーザaのアイテム(イ),(ロ),(ハ),(ニ),(ホ)に対する評価値（「5,1,4,2,3」）が既に収集されており、ユーザb,c,dについてはアイテム(イ),(ロ),(ハ),(ニ),(ホ)に対する評価値に加えてさらにアイテム(ヘ)に対する評価値が収集されていると仮定する。なお、本例では、数値の大きさで評価程度まで表しているが、評価する場合を「1」、評価しない場合を「0」などによって表すようにしてもよい。

ユーザaのアイテム(ヘ)に対する予測評価値を算出する場合、つまり、ユーザaを対象ユーザとする場合、ユーザaと他のユーザb,c,dとの間で既に収集されている評価値の相関あるいは類似度を調べる。

本例の場合、ユーザaとユーザcの相関あるいは類似度が大である。従って、ユーザaのアイテム(ヘ)に対する評価値は、ユーザcのアイテム(ヘ)に対する評価値「5」程度になると予測できる。上記のようにして未評価アイテムに対する予測評価値が算出され、予測評価値の高い上位数件の未評価アイテムが推薦アイテムとして抽出される。これにより抽出された推薦アイテムがユーザaに提示される。

図３は、本発明の実施形態における処理過程の一例を示すフロー図である。リコメンダシステム1,2,・・・,nはそれぞれ図１に示したような構成を有する。アクセス履歴３２は、ログ収集モジュール１により上記のようにして収集されたものであり、予め蓄積されている推薦対象アイテム情報３１の内から各ユーザが利用したアイテムを表している。

また、リコメンダシステム1,2,・・・,nは、リコメンダシステムの評価に際し、予め蓄積されている推薦対象アイテム情報３１の内からユーザに推薦するアイテムを抽出する。各々のリコメンダシステム1,2,・・・,nにより推薦されたアイテムは推薦結果一覧３３（１〜ｎ）として保持される。

推薦対象アイテム情報３１には各アイテムに対する属性情報が含まれている。アクセス履歴ベクトル化処理３４はこの属性情報に基づいてアクセス履歴３２をベクトル化し、アクセス履歴ベクトル３５を生成する。また、推薦結果ベクトル化処理３６は属性情報に基づいて推薦結果一覧３３をベクトル化し、推薦結果ベクトル３７を生成する。

ベクトル類似度算出処理３８は、アクセス履歴ベクトル３５と推薦結果ベクトル３７の類似度を算出し、類似度算出結果３９を出力する。各リコメンダシステム1,2,・・・,nで推薦された推薦結果一覧３３（１〜ｎ）について類似度算出結果３９を算出することによりリコメンダシステム1,2,・・・,nの有効性を評価することができる。

以下、アイテムが着信メロディである場合を例とした図４を参照して具体的に説明する。図４（ａ）は、各着信メロディに対して付与される属性情報の例を示す。各着信メロディには、ＩＤ番号の他に、タイトル、アーティスト、ジャンルなどの属性情報が付与される。このような情報は推薦対象アイテム情報３１として予め蓄積される。

図４（ｂ）は、協調フィルタリングにより抽出されてユーザに提示され、実際に該ユーザがダウンロードしたダウンロード履歴の例であり、ダウンロードされた着信メロディのＩＤ番号、日付、時刻を含む。これらの情報はアクセス履歴３２として蓄積される。

アクセス履歴ベクトル化処理３４は、ダウンロード履歴をアーティストおよびジャンルの属性情報に基づいてベクトル化し、アーティストの属性を表すベクトル（アーティストベクトル）とジャンルの属性を表すベクトル（ジャンルベクトル）を生成する。

ベクトルを〈〉付き文字で表し、アクセス履歴ベクトル化処理３４で生成されるアーティストベクトルを〈Ａ_ｄ〉、ジャンルベクトルを〈Ｇ_ｄ〉とすると、アーティストベクトル〈Ａ_ｄ〉、ジャンルベクトル〈Ｇ_ｄ〉の次元数はそれぞれ、下記(1)式で示すように、ジャンル、アーティストの総数によって決定される。ベクトル〈Ａ_ｄ〉、〈Ｇ_ｄ〉の各要素には該当するダウンロード件数が格納される。

〈Ａ_ｄ〉＝（宇多田ヒカル, SMAP, 氷川きよし, 渡る世間は鬼ばかり, Aerosmith, サザンオールスターズ,・・・）
〈Ｇ_ｄ〉＝（J-POP, 演歌, TVドラマ,洋楽、クラシック, アニメ,・・・） (1)

図４（ｂ）のダウンロード履歴の例ではアーティストの属性がそれぞれ、「氷川きよし」,「ベートーベン」,「SMAP」,「Aerosmith」である着信メロディがそれぞれ１件ずつダウンロードされているため、下記(2)式のアーティストベクトル〈Ａ_ｄ〉が生成される。また、それぞれのジャンルの属性は「演歌」,「クラシック」,「J-POP」,「洋楽」であるため、下記(3)式のジャンルベクトル〈Ｇ_ｄ〉が生成される。

〈Ａ_ｄ〉＝（０，１，１，０，１，０，・・・） (2)
〈Ｇ_ｄ〉＝（１，１，０，１，１，０，・・・） (3)

一方、上記ダウンロード履歴を持つユーザに対し、例えばリコメンダシステム1から図４（ｃ）に示すような推薦アイテム一覧1が提示されたとする。なお、推薦アイテム一覧にはユーザが既にダウンロードした既知のアイテムは含まれない。

推薦結果ベクトル化処理３６は、アクセス履歴と同様に、推薦アイテム一覧1からアーティストベクトル〈Ａ_ｒ〉とジャンルベクトル〈Ｇ_ｒ〉を生成する。図４（ｃ）の推薦アイテム一覧の例では下記(4),(5)式のアーティストベクトル〈Ａ_ｒ〉とジャンルベクトル〈Ｇ_ｒ〉が生成される。

〈Ａ_ｒ〉＝（１，０，０，１，０，・・・） (4)
〈Ｇ_ｒ〉＝（２，０，１，０，０，・・・） (5)

次に、ダウンロード履歴から生成されたアーティストベクトル〈Ａ_ｄ〉と推薦アイテム一覧から生成されたアーティストベクトル〈Ａ_ｒ〉のベクトル類似度を算出することにより、ダウンロード履歴と推薦アイテム一覧間のアーティストでの類似度を測る。また、ダウンロード履歴から生成されたジャンルベクトル〈Ｇ_ｄ〉と推薦アイテム一覧から生成されたジャンルベクトル〈Ｇ_ｒ〉のベクトル類似度を算出することによりダウンロード履歴と推薦アイテム一覧間のジャンルでの類似度を測る。

なお、ベクトル類似度は、例えばベクトル〈Ａ_ｄ〉と〈Ａ_ｒ〉、または〈Ｇ_ｄ〉と〈Ｇ_ａ〉がなす角のコサイン値、ベクトル〈Ａ_ｄ〉と〈Ａ_ｒ〉、または〈Ｇ_ｄ〉と〈Ｇ_ｒ〉間の距離などで算出できる。

これにより得られたアーティストおよびジャンルでの類似度により、ユーザに実際に推薦アイテムを提示することなくリコメンダシステムの有効性を評価することができ、その評価結果を考慮したシステム設計ができる。

例えば、アーティストでの類似度およびジャンルでの類似度がともに高い場合、ユーザの嗜好に適合しているが、発見性が低いシステムであるなどと評価でき、アーティストでの類似度が低く、ジャンルでの類似度が高い場合には、ジャンルでの類似度が高いのでユーザの嗜好に適合しており、アクセス履歴と異なるアーティストが推薦されるので発見性が高いシステムであるなどと評価できる。

以上、実施形態を説明したが、本発明は上記実施形態に限定されない。例えば、アクセス履歴と推薦アイテム一覧との間の類似度は、それらに付随する種々の情報に基づいて算出でき、アーティストやジャンルなどの属性情報に限られず、また、ベクトル化しての算出にも限られない。

さらに、アイテムは着信メロディに限らず、携帯サイトあるいは携帯コンテンツ（待ち受け画像など）などであってもよい。携帯サイトには種々のサービスを提供するものがあり、それらの携帯サイトをサービス分野、天気予報や交通案内やエンタテイメント（ゲームやカラオケなど）や株価情報などといったサービス内容により、あるいはさらに細かく分類して属性情報とすることができる。また、待ち受け画像の場合には画像の種類や内容を属性情報とすることができる。

本発明が適用されるリコメンダシステムのブロック図である。リコメンダシステムにおけるスコア算出の動作概要の説明図である。本発明の実施形態における処理過程の一例を示すフロー図である。本発明の具体例を説明するための図である。

符号の説明

１・・・ログ収集モジュール、２，３２・・・アクセス履歴、３・・・スコア算出モジュール、４・・・スコア算出結果、５・・・推薦アイテム抽出モジュール、３１・・・推薦対象アイテム情報、３３・・・推薦結果一覧、３４・・・アクセス履歴ベクトルか処理、３５・・・アクセス履歴ベクトル、３６・・・推薦結果ベクトル化処理、３７・・・推薦結果ベクトル、３８・・・ベクトル類似度算出処理、３９・・・類似度算出結果、ａ〜ｄ・・・ユーザ、（イ）〜（ヘ）・・・アイテム

Claims

各アイテムに対する全ユーザのアクセス履歴を利用して対象ユーザへの推薦アイテムを抽出して提示するリコメンダシステムの評価方法において、
リコメンダシステムで利用される各ユーザのアクセス履歴とリコメンダシステムから出力される推薦アイテム一覧との間の類似度に基づいてリコメンダシステムの有効性評価を行うことを特徴とするリコメンダシステムの評価方法。
前記アクセス履歴と前記推薦アイテム一覧を各アイテムに付与されている属性情報に基づいてそれぞれベクトル化し、これにより生成された両ベクトル間の類似度を算出することにより、前記アクセス履歴と前記推薦アイテム一覧との間の類似度を算出することを特徴とする請求項１に記載のリコメンダシステムの評価方法。
アイテムが着信メロディであり、属性情報がアーティストおよびジャンルの少なくとも一方を含むことを特徴とする請求項２に記載のリコメンダシステムの評価方法。
アイテムが携帯サイトあるいは携帯コンテンツであることを特徴とする請求項１または２に記載のリコメンダシステムの評価方法。