前回の Private Walk の続編.
伝統的には推薦システムとは開発側が開発側の為に開発するものだったが, 近年では User-side Recommender System という概念が提唱され始めた(!). 提供されてるレコメンドがフェアでないと思ったユーザーに開かれたシステム. ユーザーはシステムのデータを使えないからログデータ等なしで推薦システムを構築することになる.
この論文ではシステムの推薦から隠されたアイテムの特徴ベクトルが復元できること, これを使って推薦システムが構築できることを見ていく. 理論上可能だがその通りに実装することを効率的ではない. 実用的に 健全な (sound) 推薦システムの実装も見てく. ここで満たすべき3つの性質を提唱する.
\(\def\A{\mathcal{A}} \def\I{\mathcal{I}} \def\H{\mathcal{H}}\) \(\def\Prov{\mathcal{P}_{\mathit{prov}}}\)
システムの推薦システムとして item-to-item があるとする. これを \(\Prov\) と書く. アイテム \(i\) があったとき, 推薦システムは \(K\) 個のアイテム列を返す.
\[\Prov(i) \in \I^K\]この \(k\) 番目を \(\Prov(i)_k \in \I\) と書こう ( \(k=1,2,\ldots,K)\) .
ユーザーから見て \(\Prov\) の中身は完全にブラックボックスであるのが普通だ. これを fair かつ white-box にするのが目的.
\(\Prov\) の中身が次のようだと仮定する.
\(x\) 自体はユーザーからは絶対に見えない. で, やりたいことは \(\Prov\) の入出力のサンプルから \(x\) を復元すること.
アイテム \(i\) には何か具体的なセンシティブな属性 \(a_i \in \A\) があるとする. 例えば性別や人種が考えられる. ここではユーザーから観測可能なものだけを取り扱う.
ユーザーは既に何らのアイテム \(\H \subset \I\) についてはインタラクションをしてきていて, それらについては知っていることとする. 例えば購入履歴である. テクニカルな仮定として, \(\Prov\) は \(H\) のアイテムをレコメンドすることはないこととする.
提案される方法では \(\H\) は空集合であっても機能する.
次のような推薦グラフ \(G = (V,E)\) を考える
実際に \(\Prov\) を用いることは出来るから, ユーザーから見て \(G\) は観測可能な対象である. ひたすらページをクローリングしてく.
ランクまで考慮することでアイテムの類似度やスコアまで推定することは理論上可能だろうが, 話が難しくなりすぎるのでここでは考慮しない.
特徴ベクトルの復元を考える. ここで距離を保存する変換（平行移動, 回転, 拡大縮小）は無視して考える. それらは kNN の結果を変えないので.
Hashimoto らではこのグラフの上を Random Walk してくことで, 任意の誤差未満で復元できることを示している. （なんか色々条件付きで.）
Alamgir & von Luxburg は, グラフに適切に重みを割り当ててくことで, グラフ上の最短距離が特徴ベクトル間の距離と一致するように出来ることを示した. これを使うことで, グラフ \(G\) を与えてアイテム同士（その特徴ベクトル）の距離行列
\[D \in \mathbb R^{n \times n}\]得られる.
Terada & von Luxburg は, 重みなし k-NN グラフに彼らの提案する Local Oridinal Embeddings (LOE) を割り当てることで復元できたことを示した. ことを示した. これも実際にはなんやかんや条件があるらしいが, ともかく本論文の実験では LOE を使ったそう.
色々言ったがともかく, 推薦グラフ \(G\) が手に入ったらアイテムの特徴ベクトルは復元できる. そしてらこれを元にまた推薦システムを構築できるし, fair な推薦をするために後処理を施すこともできる (ETP; Estimate-then-postprocessing).
Figure 1. 二次元のでトイデータから kNN グラフを作って復元する実験. 完璧じゃないけどほぼほぼ復元できてる.
これから User-side Recommendation, \(Q\) を設計する. パラメータとして, 非負整数 \(\tau\) を持たせる. これは fairness と preformance をトレードオフに調整する.
\(\Prov\) と比較したときに性能がほとんど劣化してないその度合いを指す. 特に \(\tau=0\) のときに, \(\Prov\) と nDCG が下がってないときに consistent であるという. (全く同じ結果が出せるようになっていれば consistent だ.)
どのレコメンド結果 \(Q(i) \in I^K\) についても, 各属性 \(a \in \A\) に属するアイテムが \(\tau\) 個以上あること.
\[\forall i \in \I ,~ |\{ k \in [K] \mid Q(i)_k = j, a_j = a \}| \geq \tau\]グラフ \(G\) の部分だけからでも復元できること. 全てのアイテムについて集めてきてフルな \(G\) を作れば復元できるのは良いけど, それだと実用上は大変なので, 一部のアイテムについてだけでもグラフを作って, そのアイテムの分だけでも特徴量ベクトルが復元できると便利.
Consul は consistent で sound で local であることが示されている.
Table 3. Oracle ( \(\Prov\) ) をそのまま使うのに比べて Consul を使うと Accuracy/nDCG がどのくらい変わるか. もちろん下がるがその下がり幅が小さいことが大事. また Access では Oracle を何回使うかだが, たいてい 10 回未満で済んでいる.
Consul 自体は, まあそう, といった感じ. 提供されてる item-to-item レコメンダがあって, これを多段で叩くことでバリエーションが増やせるようになる（だからこそ fair なものが作れる）というのはノウハウとしてはなるほど. 特徴量ベクトルが復元できる話は結局, フェアなレコメンドを作りたい話とは関係なかった. それ自体は知識として有用だけど, LOE 単体のレポートな気がする, それは.