新しい推薦方式 知識ベース型推薦についての解説
?Download as PPTX, PDF?
5 likes?2,263 views
協調フィルタリング、コンテンツベース以外の、第3の推薦方式である知識ベース型推薦についてのまとめと解説。 参照：情報推薦システム入門の第4章 知識ベース型推薦
新しい推薦方式 知識ベース型推薦についての解説
- 1. 知识ベース型推荐の解説
- 2. Agenda ?知識ベース型推薦の位置づけ ?知識ベース型推薦の種類 ?制約型推薦 ?事例型推薦 ?適用事例 このスライドは 情報推薦システム入門の第4章、知識ベー ス型推薦についてまとめたものです。
- 3. Agenda ?知識ベース型推薦の位置づけ ?知識ベース型推薦の種類 ?制約型推薦 ?事例型推薦 ?適用事例
- 4. 知識ベース型推薦の位置づけ(1/2) ユーザーに対する商品のレコメンドでは、主に以下３つの方式がある 協調型推薦ユーザーの嗜好を元に推薦を行う方式。 1.ＡさんとＢさんの嗜好は似ている→AさんがXを好きならＢさんもＸが好き 2.商品Xと商品Yに対する評価の傾向は似ている→Xが好きならYも好き 1を「協調フィルタリング」、2を「アイテムベース推薦」という。 内容型推薦商品の特徴（アイテムプロファイル）の類似度で推薦を行う方式。 商品Xと商品Yは似ている→商品Xが好きならYも好き。 協調型推薦のアイテムベース推薦と異なるのは、ユーザーの評価値でなく内容で類 似度を推定する点(小説Xが好きなら同じ時代小説のYも好き、など)。 知識ベース型 推薦 ユーザーに好みを示してもらうことで、推薦を行う方式。 ?制約型：示された好みを最低限満たす中で、効用の大きなものを推薦する ?事例型：適当な商品をベースとしそこに嗜好を加味してもらい推薦する (例：ある商品Xを提示し、そこから「もう少し安く」などと嗜好を追加してもらい それを満たすものを推薦する)
- 5. 知識ベース型推薦の位置づけ(2/2) 協調型?内容型も結局のところ「今ほしいかどうか」には関係ない。 ?時系列が考慮できない 車などあまり買わないものは、前回購買時の評価があてにならない ONE PEACE最新刊を買ったとき1巻を推薦することに意味はない etc... ユーザーの嗜好は絶えず変化する。 今まさに買いたいもの、たまに買うものを選ぶ場合協調型?内容型は不適。 ?知識ベース型推薦
- 6. Agenda ?知識ベース型推薦の位置づけ ?知識ベース型推薦の種類 ?制約型推薦 ?事例型推薦 ?適用事例
- 7. 知識ベース型推薦の種類(1/3) 知識ベース型推薦には、下記の２種類がある。 ?制約型 ユーザーに与えられた条件を満たし、最大の効用となるものを提案する。 （例：2000円以下で個室があって、一番評価が高いお店、など） ?事例型 代表的に選択されたアイテムから、ユーザーの嗜好を加味しながら提案。 （例：二郎ラーメンに、野菜増し増し、カタメで、など） いずれにせよ「ユーザーに嗜好を提示してもらう」シーンが存在する。
- 8. 知識ベース型推薦の種類(2/3) それって普通の検索じゃない？ まさに「制約」を設定する欄 また、事例(検索结果)をより绞り込む条件
- 9. 知識ベース型推薦の種類(3/3) 「指定された条件に合うものを提示する」という意味では、まさにただの検索。 というか、検索が広い意味での「推薦」。 ?知識ベース型は、より「狭く」絞る 検索結果が数千件もあっては、提案しているとは言えない。 １ページ以内(10件程度)に収まる範囲に絞り提案を行う。 ?知識ベース型は、ユーザーに負担をかけない さんざん条件を設定してもらったら、絞り込めて当然。 少ない選択で嗜好に合うものを提案する。そのためモデル/ドメイン知識を 内包する、状況に応じた条件を提案する応答型I/Fなどの工夫が必要。
- 10. 制約型の実装 命題：ユーザーから示された嗜好を充足するアイテムを推薦する 実装 連言的クエリ：要は単なるAND結合のSQL(価格>100 and 評価>’B’) 制約充足方式：制約を充足する中で効用が最大なもの、を選ぶ。 連言的クエリはただのSQLなので、ここでは制約充足方式について解説する。
- 11. Agenda ?知識ベース型推薦の位置づけ ?知識ベース型推薦の種類 ?制約型推薦 ?事例型推薦 ?適用事例
- 12. 制約型推薦モデル化と課題設定(1/4) モデル化 Vc 顧客特性Vprod 製品特性 Cf フィルタ条件 Cr 互換性制約 Cr(互換性制約) 顧客特性間の互換可能なルール 例：大判プリントが可能なら価格が5万 円以上なのは許容する Cf(フィルタ条件) 顧客特性を製品特性へ変換するルール 例：大判プリントをするなら画素数は5 万画素以上、など 顧客要求REQをフィルタ条件により製 品特性の制約へ変換し、これにより製 Cprod 製品制約 製品を一意に特 定する制約集合 REQ:顧客要求RES:推薦製品 品を抽出する(RES)。
- 13. 制約型推薦モデル化と課題設定(2/4) 通常の検索サイトにおける実例としては、以下のようなイメージとなる。 ?顧客特性(Vc)：画面上のラジオボタンやチェックボックス ?顧客要求(REQ)：上記に対するユーザー入力 ?製品制約(Cprod)：製品のマスタテーブル ?フィルタ条件(Cf)：SQL こうしてあてはめた場合、通常の検索サイトにどのような問題があり制約型推薦 がそれをどのように解決するのかについて示す。
- 14. 制約型推薦モデル化と課題設定(3/4) １．類似した製品を提案できない→類似尺度による推薦 多く検索では、「指定したものと全く同じ」値の製品しか推薦できない (3000円コースの居酒屋、という場合2900円が含まれないなど)。 →類似尺度を利用し、指定された値に「近い」ものを提案する ２．選択するため条件がわからない→デフォルトの提案 自分の要求に合う製品を選択するための知識が不足している場合がある。 (カメラを初めて選ぶとき、画素数はどれを選んだら十分なのか?など)。 →デフォルトを提案し、指定がない場合「それらしい」条件を適用し提 案
- 15. 制約型推薦モデル化と課題設定(4/4) ３．条件に適合した製品がない→空の結果集合の解決 検索して該当する製品がない場合、自分で条件を修正する必要がある。 →指定された条件を緩和し制約条件をより近い形で満たす製品を提案する。 ４．自分の好みに応じた製品を探せない→効用に応じたソート 提案された推薦結果から、自分の好みに合うものを探すのに時間がかか る。 →顧客一人ひとりが感じる効用をベースにしたソートを行い表示する。
- 16. 制約型推薦実装(1/9) １．類似尺度による推薦(1/2) 「類似」とは顧客の要求に対する製品の類似度となる。 REQ中の要求rに対するアイテムpの類似度をsim(p,r)とすると、類似度はその合 計で表すことができる。 sim(p,r)は、アイテムpが要求rに近いほど良いため以下のように書ける。 製品特性φがrに近いほど値は0に近くなる ため、これは近いほど大きい値となる。 (max-min)で割っているのは正規化のため (値を大体0～1の範囲に収める)。 MIB/LIBのように名前がついてないが、便 宜的にNear Is Better(NIB)と呼ぶ
- 17. 制約型推薦実装(2/9) １．類似尺度による推薦(2/2) ただ、製品特性の中には同じ要求に合うものなら大きい/小さいものの方が良い ものが存在する(カメラなら画素数は高い方がいい、株ならリスクが小さい方が いいなど)。 これらの特性は、以下のように記述できる。 多いほど良い(more-is-better, MIB)特性 製品特性φが大きいほど高い値となる。 少ないほど良い(less-is-better, LIB)特性 製品特性φが小さいほど高い値となる。 こうした特性に応じた対応を行うことで、より実態として要求に近い製品の提案 が可能になる。
- 18. 制約型推薦実装(3/9) 2．デフォルトの提案(1/2) 選択条件に確信が持てなかったり、そもそも選ぶ際の前提知識がないときにはデ フォルト値の提案が有効になる。 デフォルトには、下記の種類が存在する。 ?静的デフォルト：特定の特性について固定値を設定する ?従属デフォルト：よりメタな特性からデフォルトを提案する ?導出デフォルト：これまでの行動ログからデフォルトを提案する 従属デフォルトは、「夜景を撮りたい」「家族で使う」など、ユーザーにより分 かりやすい条件から具体的な特性を設定するものである。 導出デフォルトについては、これまでのユーザーの検索行動からデフォルトを提 案する手法である(後述)。
- 19. 制約型推薦実装(4/9) 2．デフォルトの提案(2/2) 顧客価格ズーム液晶サイズ c1 400 10倍3.0 c2 300 10倍3.0 c3 150 4倍2.5 c4 200 5倍2.7 c5 200 5倍2.7 ?提案方法1：1-最近傍 入力された要求に最も近い顧客データから提案を行う。 例：価格400/ズーム10倍が指定されたら、顧客c1のログよ り駅用サイズ3.0をデフォルトとして提案する。 ?提案方法2：重み付き多数決投票 入力された要求に近い幾つかのログを取得し、その中で最 も選択されているものを提案する。 例：ズーム3倍の場合、最も近いのはc3～c5。その中で最 も選択されているものは価格：200/液晶サイズ:2.7である ためこれを提案する。 デフォルトの提案は、条件そのものの提案にも利用できる。例えば、価格とズームが指定されることが 多く、ユーザーがまだそれらを指定していないならその設定を促すなどである。
- 20. 制約型推薦実装(5/9) 3．空の結果集合の解決 与えられた条件をすべて満たす製品が存在しないということはままある。 この場合、条件を自動的に緩和し提案することが可能である。 例：条件A?B?Cすべてを満たすものはないがA?Bならあるなど。 制約のはずし方は様々な手法があるが(QuickXPlain/MinRelaxなど)あまり役に は立たない。 基本的に制約の解除はユーザーにとって優先度の低い制約から行っていくべきで あり、上記の手法はそれを考慮しないためである。
- 21. 制約型推薦実装(6/9) 4．効用に応じたソート(1/4) ユーザーは推薦された製品のリストを基本的には上から順にみていくため、ソー ト順は非常に重要な要素となる。 ソート値は、各製品の効用とユーザーの嗜好の組み合わせで計算する。 まず、製品の効用は以下のようにあらわせる。 製品の効用uは、各製品特性pv(1~n)に対し効用を計算した結果の合計値となる。 例：品質という効用があり、各製品特性に対し値が設定されている場合(価格が 150以上なら品質5、画素数が8M以下なら品質3など???)、その製品の品質の値 はその合計値となる。
- 22. 制約型推薦実装(7/9) 4．効用に応じたソート(2/4) 効用が同じでも、それをどう評価するかは顧客に依存する(ある顧客は品質を重 視するかもしれないし、ある顧客は経済性を重視するかもしれない)。 効用uに対する顧客の嗜好をcuとすると、最終的な効用は下記で表現できる。 例：顧客cの製品pに対する効用を計算する。効用はu1=品質,u2=経済性の2種類であり、その値は以下のように計算する。 品質(u1) =(価格(pv1) > 200 then 10, else 5) + (画素数(pv2) > 100 then 5 else 1) 経済性(u2) =(価格(pv1) > 200 then 1, else 10) + (画素数(pv2) > 100 then 3 else 1) 顧客cの嗜好がu1:0.8,u2:0.2である場合、製品p(価格200,画素数100)の効用は、 u = (10 + 5) * 0.8 + (1 + 3) * 0.2 = 12.8 となる。
- 23. 制約型推薦実装(8/9) 4．効用に応じたソート(3/4) ユーザーの嗜好を取得するには、以下の方法がある。 ?ユーザー定義の嗜好：直接ユーザーに聞いてしまう ?効用ベースの嗜好：ユーザーが設定した条件から推定 ?コンジョイント分析：ユーザーの行動ログから推定 効用ベースの嗜好は、ユーザーが設定した条件から前述の効用を計算し重みを判 定する手法である。 前述の製品p(価格200,画素数100)の製品特性をそのまま顧客が指定した条件と考えれば、品質(u1)?経済性(u2)に対する 効用はそれぞれ15?4となる。ここから、品質の嗜好=15/(15+4)=78%、といった感じで嗜好を定義する。 顧客が他製品に対して何らかの評価を行っていれば、その行動ログを利用した紺 ジョイント分析が可能となる。
- 24. 制約型推薦実装(9/9) 4．効用に応じたソート(4/4) 各製品の価格/画素数を以下のようにマッピングした際、顧客が下記のように評 価(ランキング付)しているとする。 括弧内は、平均からの差異となっている。この値が大きいほど、顧客はその指標 に対して敏感、つまり重要視しているといえる。 価格1 価格2 価格3 平均(画素数) 画素数1 4 5 6 5(-1.5) 画素数2 2 1 3 2(1.5) 平均(価格) 3(0.5) 3(0.5) 4.5(-1.0) 3.5
- 25. Agenda ?知識ベース型推薦の位置づけ ?知識ベース型推薦の種類 ?制約型推薦 ?事例型推薦 ?適用事例
- 26. 事例型推薦モデル化と課題設定(1/2) 既存の検索では、ユーザーはまず検索条件を入力する必要がある。 しかし、専門分野などではそもそもどんな検索条件を入力すればよいのかあたり がつかないことも多い。 そこで生まれたのが、事例型の推薦である。 具体的には、代表的な製品をいきなり提案してしまい、それに対して「もっと価 格は安く」などというように条件(批評:critiquing)を加えていくという手法であ る。 通常の条件に基づくクエリベース(query-based)のアプローチに対し、このよう な手法を閲覧ベース(browsing-based)のアプローチと呼んでいる。 （当然、クエリ/閲覧ベースを併用することも可能である）。
- 27. 事例型推薦モデル化と課題設定(2/2) 事例型の処理ステップは、以下のようになる。 開始アイテムの提案 批評の実施 推薦アイテムの提案 初期ユーザークエリ(通常の検索、もしくは制約型による提案等)によ り起点となるアイテムを提示する。 アイテムに対する批評を行う(より安い、など)。 批評を加味し、推薦するアイテムを選択する。 以後、それに対する批評???とループする。 批評とそれによる推薦アイテムの提案、これが処理の肝となる。
- 28. 事例型推薦実装(1/7) 批評の種別 ?単位批評 「より安い」、など単一の特性に対する批評 ?複合批評 「より安いかつ画素数が高い」というような複合的な批評。 静的：あらかじめ組み合わせのルールを用意しておく。 動的：現在の開始/推薦アイテムから適切な複合批評を動的に決定する。 動的な複合批評の生成は、以下のような手法で行う。
- 29. 事例型推薦実装(2/7) １．現在の開始/推薦アイテムに対する批評パターンを導出する 批評パターンとは、特定のアイテムに対し各特性を評価したもの (価格は<、画素数は>、など不等号の連なりで表現される) ２．批評パターンから、複合的批評を見つけ出す 価格<なら画素数も<(価格が高い=画素数も高い)の確率が高い、など ３．導出した複合的指標の支持度と確信度を計算する 支持度：発見したパターンは、全体の何パーセントに見られるか。 確信度：発見したパターンが発現する確率 (上記のパターンなら、価格>となるもののうちパターン通り画素 数>となるパターンの割合）
- 30. 事例型推薦実装(3/7) 価格画素数液晶サイズ動画撮影 開始アイテム200 9.1 3.0 yes 比較 価格画素数液晶サイズ動画撮影 候補アイテム150 7.1 2.5 no 180 8.0 2.5 yes 190 8.0 3.1 yes 260 10.0 3.0 yes
- 31. 事例型推薦実装(4/7) 開始アイテムに対する候補アイテムの比較結果は、以下のようになる。 価格画素数液晶サイズ動画撮影 批評パターン< < < != < < < = < < > = > > = = ここから、例えば価格<なら画素数<、画素数<なら液晶サイズ<という傾向が 見えたとする(相関関係を判定することで、複合的批評を導出する)
- 32. 事例型推薦実装(5/7) 導出された複合的批評について、その支持度と確信度を計算する。 複合的批評支持度(SUPP) 確信度(CONF) 価格< & 画素数< 4件中3件に確認、価格<のとき画素数<となるのは100% 75% 100% 画素数< & 液晶< 4件中2件に確認、画素数<のとき液晶<となるのは50% 50% 50% 支持度が低いほどレアなパターンとなり絞り込むには有効だが、その分目的のア イテムから外れる可能性がある(高支持の場合この逆)。 導出された複合的批評を選択するには昇順/降順/ランダムがあるが、昇順が効率 的ということが知られている。
- 33. 事例型推薦実装(6/7) ユーザーによって繰り返された批評のデータを使用することで、より適した推薦 を行うことができる。 具体的には、推薦対象アイテムのうち、批評を充足する度合い(批評を満たす数/ 全批評数)を互換性スコアとし、これと類似度の積をランク付けに利用する。 なお、批評は互いに矛盾するものを含む可能性があるため(前価格<100を指定し たがその後価格>150になったなど)、矛盾したものは評価対象から外す必要があ る。
- 34. 事例型推薦実装(7/7) ?事例型が有効なシーン 批評を利用した推薦は、類似したアイテムが集中するホットスポットがない場合 に有効となる。 ※ホットスポットがあると、批評を行っても同定ができなくなる。 ただ、この解決策として現在すでに選択されている批評に対しより重なりが小さ い批評を次に選ぶという手法がある(重なりが小さいほど、より絞り込むことが できる)。 支持度とこの重なり双方を加味することで、より効率的な探索が可能になる。 支持度と重なりの積を「質」とし、この質がより低いものを選択することでより アイテムを限定することが可能になる。
- 35. Agenda ?知識ベース型推薦の位置づけ ?知識ベース型推薦の種類 ?制約型推薦 ?事例型推薦 ?適用事例
- 36. 適用事例 ?制約型 保険会社で、営業員が顧客に推薦すべき保険商品を検索するのに利用。 顧客の年齢等の特性と要求から推薦すべき保険商品とその理由を提案する。 知識はルールベースで獲得しており、専門家がルールを登録するためのシステム も併せて使用している。 ?事例型 レストランの検索で、通常のテキスト検索を補完する形で利用されている (これでよいけどちょっと安いのも見たい、など)。 知識はルールベース。ユーザーが期待している類似性を判断する必要がある (上記の例では、価格は安くしたいがレストランの種別(イタリアンなど)は変え たくないという暗黙の制約を読む必要がある)。