知識ベース型推薦の解説

・知識ベース型推薦の位置づけ・知識ベース型推薦の種類・制約型推薦・事例型推薦・適用事例

Agenda

このスライドは情報推薦システム入門の第4章、知識ベース型推薦についてまとめたものです。

・知識ベース型推薦の位置づけ・知識ベース型推薦の種類・制約型推薦・事例型推薦・適用事例

Agenda

ユーザーに対する商品のレコメンドでは、主に以下３つの方式がある

知識ベース型推薦の位置づけ(1/2)

協調型推薦 ユーザーの嗜好を元に推薦を行う方式。1.ＡさんとＢさんの嗜好は似ている→AさんがXを好きならＢさんもＸが好き2.商品Xと商品Yに対する評価の傾向は似ている→Xが好きならYも好き1を「協調フィルタリング」、2を「アイテムベース推薦」という。

内容型推薦 商品の特徴（アイテムプロファイル）の類似度で推薦を行う方式。商品Xと商品Yは似ている→商品Xが好きならYも好き。協調型推薦のアイテムベース推薦と異なるのは、ユーザーの評価値でなく内容で類似度を推定する点(小説Xが好きなら同じ時代小説のYも好き、など)。

知識ベース型推薦

ユーザーに好みを示してもらうことで、推薦を行う方式。・制約型：示された好みを最低限満たす中で、効用の大きなものを推薦する・事例型：適当な商品をベースとしそこに嗜好を加味してもらい推薦する(例：ある商品Xを提示し、そこから「もう少し安く」などと嗜好を追加してもらいそれを満たすものを推薦する)

協調型・内容型も結局のところ「今ほしいかどうか」には関係ない。

・時系列が考慮できない車などあまり買わないものは、前回購買時の評価があてにならないONE PEACE最新刊を買ったとき1巻を推薦することに意味はない

etc...

ユーザーの嗜好は絶えず変化する。今まさに買いたいもの、たまに買うものを選ぶ場合協調型・内容型は不適。⇒知識ベース型推薦

知識ベース型推薦の位置づけ(2/2)

・知識ベース型推薦の位置づけ・知識ベース型推薦の種類・制約型推薦・事例型推薦・適用事例

Agenda

知識ベース型推薦には、下記の２種類がある。

・制約型ユーザーに与えられた条件を満たし、最大の効用となるものを提案する。（例：2000円以下で個室があって、一番評価が高いお店、など）

・事例型代表的に選択されたアイテムから、ユーザーの嗜好を加味しながら提案。（例：二郎ラーメンに、野菜増し増し、カタメで、など）

いずれにせよ「ユーザーに嗜好を提示してもらう」シーンが存在する。

知識ベース型推薦の種類(1/3)

それって普通の検索じゃない？

知識ベース型推薦の種類(2/3)

まさに「制約」を設定する欄また、事例(検索結果)をより絞り込む条件

知識ベース型推薦の種類(3/3)

「指定された条件に合うものを提示する」という意味では、まさにただの検索。というか、検索が広い意味での「推薦」。

・知識ベース型は、より「狭く」絞る検索結果が数千件もあっては、提案しているとは言えない。１ページ以内(10件程度)に収まる範囲に絞り提案を行う。

・知識ベース型は、ユーザーに負担をかけないさんざん条件を設定してもらったら、絞り込めて当然。少ない選択で嗜好に合うものを提案する。そのためモデル/ドメイン知識を内包する、状況に応じた条件を提案する応答型I/Fなどの工夫が必要。

制約型の実装

命題：ユーザーから示された嗜好を充足するアイテムを推薦する実装

連言的クエリ：要は単なるAND結合のSQL(価格>100 and 評価>’B’)制約充足方式：制約を充足する中で効用が最大なもの、を選ぶ。

連言的クエリはただのSQLなので、ここでは制約充足方式について解説する。

・知識ベース型推薦の位置づけ・知識ベース型推薦の種類・制約型推薦・事例型推薦・適用事例

Agenda

制約型推薦 モデル化と課題設定(1/4)

モデル化

Cf フィルタ条件

Vc顧客特性 Vprod 製品特性

Cr 互換性制約

Cr(互換性制約)顧客特性間の互換可能なルール

例：大判プリントが可能なら価格が5万円以上なのは許容する

Cf(フィルタ条件)顧客特性を製品特性へ変換するルール

例：大判プリントをするなら画素数は5万画素以上、など

顧客要求REQをフィルタ条件により製品特性の制約へ変換し、これにより製品を抽出する(RES)。REQ:顧客要求

Cprod 製品制約

製品を一意に特定する制約集合

RES:推薦製品

制約型推薦 モデル化と課題設定(2/4)

通常の検索サイトにおける実例としては、以下のようなイメージとなる。

・顧客特性(Vc)：画面上のラジオボタンやチェックボックス・顧客要求(REQ)：上記に対するユーザー入力・製品制約(Cprod)：製品のマスタテーブル・フィルタ条件(Cf)：SQL

こうしてあてはめた場合、通常の検索サイトにどのような問題があり制約型推薦がそれをどのように解決するのかについて示す。

制約型推薦 モデル化と課題設定(3/4)

１．類似した製品を提案できない→類似尺度による推薦多く検索では、「指定したものと全く同じ」値の製品しか推薦できない(3000円コースの居酒屋、という場合2900円が含まれないなど)。

→類似尺度を利用し、指定された値に「近い」ものを提案する

２．選択するため条件がわからない→デフォルトの提案自分の要求に合う製品を選択するための知識が不足している場合がある。(カメラを初めて選ぶとき、画素数はどれを選んだら十分なのか?など)。→デフォルトを提案し、指定がない場合「それらしい」条件を適用し提

案

制約型推薦 モデル化と課題設定(4/4)

３．条件に適合した製品がない→空の結果集合の解決検索して該当する製品がない場合、自分で条件を修正する必要がある。→指定された条件を緩和し制約条件をより近い形で満たす製品を提案する。

４．自分の好みに応じた製品を探せない→効用に応じたソート提案された推薦結果から、自分の好みに合うものを探すのに時間がかか

る。→顧客一人ひとりが感じる効用をベースにしたソートを行い表示する。

制約型推薦 実装(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)と呼ぶ

制約型推薦 実装(2/9)

１．類似尺度による推薦(2/2)ただ、製品特性の中には同じ要求に合うものなら大きい/小さいものの方が良いものが存在する(カメラなら画素数は高い方がいい、株ならリスクが小さい方がいいなど)。これらの特性は、以下のように記述できる。

多いほど良い(more-is-better, MIB)特性製品特性φが大きいほど高い値となる。

少ないほど良い(less-is-better, LIB)特性製品特性φが小さいほど高い値となる。

こうした特性に応じた対応を行うことで、より実態として要求に近い製品の提案が可能になる。

制約型推薦 実装(3/9)

2．デフォルトの提案(1/2)選択条件に確信が持てなかったり、そもそも選ぶ際の前提知識がないときにはデフォルト値の提案が有効になる。デフォルトには、下記の種類が存在する。

・静的デフォルト：特定の特性について固定値を設定する・従属デフォルト：よりメタな特性からデフォルトを提案する・導出デフォルト：これまでの行動ログからデフォルトを提案する

従属デフォルトは、「夜景を撮りたい」「家族で使う」など、ユーザーにより分かりやすい条件から具体的な特性を設定するものである。導出デフォルトについては、これまでのユーザーの検索行動からデフォルトを提案する手法である(後述)。

制約型推薦 実装(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であるためこれを提案する。

デフォルトの提案は、条件そのものの提案にも利用できる。例えば、価格とズームが指定されることが多く、ユーザーがまだそれらを指定していないならその設定を促すなどである。

制約型推薦 実装(5/9)

3．空の結果集合の解決与えられた条件をすべて満たす製品が存在しないということはままある。この場合、条件を自動的に緩和し提案することが可能である。

例：条件A・B・Cすべてを満たすものはないがA・Bならあるなど。

制約のはずし方は様々な手法があるが(QuickXPlain/MinRelaxなど)あまり役には立たない。基本的に制約の解除はユーザーにとって優先度の低い制約から行っていくべきであり、上記の手法はそれを考慮しないためである。

制約型推薦 実装(6/9)

4．効用に応じたソート(1/4)ユーザーは推薦された製品のリストを基本的には上から順にみていくため、ソート順は非常に重要な要素となる。ソート値は、各製品の効用とユーザーの嗜好の組み合わせで計算する。まず、製品の効用は以下のようにあらわせる。

製品の効用uは、各製品特性pv(1~n)に対し効用を計算した結果の合計値となる。例：品質という効用があり、各製品特性に対し値が設定されている場合(価格が150以上なら品質5、画素数が8M以下なら品質3など・・・)、その製品の品質の値はその合計値となる。

制約型推薦 実装(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 となる。

制約型推薦 実装(8/9)

4．効用に応じたソート(3/4)ユーザーの嗜好を取得するには、以下の方法がある。

・ユーザー定義の嗜好 ：直接ユーザーに聞いてしまう・効用ベースの嗜好 ：ユーザーが設定した条件から推定・コンジョイント分析 ：ユーザーの行動ログから推定

効用ベースの嗜好は、ユーザーが設定した条件から前述の効用を計算し重みを判定する手法である。

前述の製品p(価格200,画素数100)の製品特性をそのまま顧客が指定した条件と考えれば、品質(u1)・経済性(u2)に対する効用はそれぞれ15・4となる。ここから、品質の嗜好=15/(15+4)=78%、といった感じで嗜好を定義する。

顧客が他製品に対して何らかの評価を行っていれば、その行動ログを利用した紺ジョイント分析が可能となる。

制約型推薦 実装(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

・知識ベース型推薦の位置づけ・知識ベース型推薦の種類・制約型推薦・事例型推薦・適用事例

Agenda

事例型推薦 モデル化と課題設定(1/2)

既存の検索では、ユーザーはまず検索条件を入力する必要がある。しかし、専門分野などではそもそもどんな検索条件を入力すればよいのかあたりがつかないことも多い。そこで生まれたのが、事例型の推薦である。

具体的には、代表的な製品をいきなり提案してしまい、それに対して「もっと価格は安く」などというように条件(批評:critiquing)を加えていくという手法である。

通常の条件に基づくクエリベース(query-based)のアプローチに対し、このような手法を閲覧ベース(browsing-based)のアプローチと呼んでいる。（当然、クエリ/閲覧ベースを併用することも可能である）。

事例型推薦 モデル化と課題設定(2/2)

事例型の処理ステップは、以下のようになる。

開始アイテムの提案

批評の実施

推薦アイテムの提案

初期ユーザークエリ(通常の検索、もしくは制約型による提案等)により起点となるアイテムを提示する。

アイテムに対する批評を行う(より安い、など)。

批評を加味し、推薦するアイテムを選択する。以後、それに対する批評・・・とループする。

批評とそれによる推薦アイテムの提案、これが処理の肝となる。

事例型推薦 実装(1/7)

批評の種別・単位批評

「より安い」、など単一の特性に対する批評・複合批評

「より安い かつ 画素数が高い」というような複合的な批評。静的：あらかじめ組み合わせのルールを用意しておく。

動的：現在の開始/推薦アイテムから適切な複合批評を動的に決定する。

動的な複合批評の生成は、以下のような手法で行う。

事例型推薦 実装(2/7)

１．現在の開始/推薦アイテムに対する批評パターンを導出する

批評パターンとは、特定のアイテムに対し各特性を評価したもの

(価格は<、画素数は>、など不等号の連なりで表現される)

２．批評パターンから、複合的批評を見つけ出す

価格<なら画素数も<(価格が高い=画素数も高い)の確率が高い、など

３．導出した複合的指標の支持度と確信度を計算する

支持度：発見したパターンは、全体の何パーセントに見られるか。

確信度：発見したパターンが発現する確率

(上記のパターンなら、価格>となるもののうちパターン通り画素

数>となるパターンの割合）

事例型推薦 実装(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

比較

事例型推薦 実装(4/7)

価格 画素数 液晶サイズ 動画撮影

批評パターン < < < !=

< < < =

< < > =

> > = =

開始アイテムに対する候補アイテムの比較結果は、以下のようになる。

ここから、例えば価格<なら画素数<、画素数<なら液晶サイズ<という傾向が見えたとする(相関関係を判定することで、複合的批評を導出する)

事例型推薦 実装(5/7)

導出された複合的批評について、その支持度と確信度を計算する。

複合的批評 支持度(SUPP) 確信度(CONF)

価格< & 画素数<4件中3件に確認、価格<のとき画素数<となるのは100%

75% 100%

画素数< & 液晶<4件中2件に確認、画素数<のとき液晶<となるのは50%

50% 50%

支持度が低いほどレアなパターンとなり絞り込むには有効だが、その分目的のア

イテムから外れる可能性がある(高支持の場合この逆)。

導出された複合的批評を選択するには昇順/降順/ランダムがあるが、昇順が効率

的ということが知られている。

事例型推薦 実装(6/7)

ユーザーによって繰り返された批評のデータを使用することで、より適した推薦を行うことができる。

具体的には、推薦対象アイテムのうち、批評を充足する度合い(批評を満たす数/

全批評数)を互換性スコアとし、これと類似度の積をランク付けに利用する。

なお、批評は互いに矛盾するものを含む可能性があるため(前価格<100を指定し

たがその後価格>150になったなど)、矛盾したものは評価対象から外す必要があ

る。

事例型推薦 実装(7/7)

・事例型が有効なシーン

批評を利用した推薦は、類似したアイテムが集中するホットスポットがない場合

に有効となる。

※ホットスポットがあると、批評を行っても同定ができなくなる。

ただ、この解決策として現在すでに選択されている批評に対しより重なりが小さ

い批評を次に選ぶという手法がある(重なりが小さいほど、より絞り込むことが

できる)。

支持度とこの重なり双方を加味することで、より効率的な探索が可能になる。

支持度と重なりの積を「質」とし、この質がより低いものを選択することでより

アイテムを限定することが可能になる。

・知識ベース型推薦の位置づけ・知識ベース型推薦の種類・制約型推薦・事例型推薦・適用事例

Agenda

適用事例

・制約型保険会社で、営業員が顧客に推薦すべき保険商品を検索するのに利用。顧客の年齢等の特性と要求から推薦すべき保険商品とその理由を提案する。知識はルールベースで獲得しており、専門家がルールを登録するためのシステムも併せて使用している。

・事例型レストランの検索で、通常のテキスト検索を補完する形で利用されている(これでよいけどちょっと安いのも見たい、など)。知識はルールベース。ユーザーが期待している類似性を判断する必要がある(上記の例では、価格は安くしたいがレストランの種別(イタリアンなど)は変えたくないという暗黙の制約を読む必要がある)。