相互推薦(reciprocal recommendation)
概要
推薦システムにおいて主流なECサイトや動画配信サイトなどではユーザに対して候補となるアイテムが選出され、購入する(目的を果たす)ための決定権はユーザ側にあり、また、ユーザ繰り返し購入を行うことが想定されている
相互推薦(求人サイトやマッチングアプリ)システムでは、
目的を果たす(採用される、会うなど)ためには相手の同意が必要
需要に応じたアイテム(求人、相手)が供給されるわけではない
一回目的を果たしたあとは、基本離脱する
という特徴がある。繰り返し行動することがないため(複数回購入する、など)、ユーザの反応データを集めるのが従来の推薦システムより困難であることを示しており、コールドスタート問題が顕著になる
相互推薦システムはユーザ(求職者)とユーザ(企業)の双方のマッチングを行うことが重要になってくる
互いの優先する観点(給料、スキル、経験)や求めるものは異なるため双方の目的関数を最適化するような問題設定になる
ex.)
1人の求職者にスカウトや求人を大量に送っても全てに目を通すのは不可能
募集人数1人なのに100人も応募してきたら大変
相互推薦システムが解きたい問題は相互にアプローチを行うような状況から、マッチングする相手を予測すること
https://gyazo.com/b26fd317449224b99e11d026bf56e472
RecSys '19で発表されたもの
アルゴリズム
データセットはマッチングアプリ(pairs)のlike、nope(dislike)のaction情報を用いている(フリックでスワイプして行ったときのデータだろうか)
rating matrixについてLatent Factor Model(の一種のMatrix Factorization)を適用して特徴ベクトルを取得する
アルゴリズムの概略図
https://gyazo.com/d0c2925506e032d75fb53f88b4f5d66e
女性→男性(男性→女性)のrating matrixを用いて2つモデルを作成し、スコアを計算する。それらのスコアについて集約関数を適用し、reciprocal scoreとしてある男女の組み合わせのマッチングスコアを算出する
集約関数として、算術平均、幾何平均、調和平均、uninormを用いている
新規性
現在までに協調フィルタリングを用いた手法が考案されているが、データはスパースであり
実用上で困難があったが、Latent Factor Modelを用いることで計算速度の問題を改善している
また、スコアの算出方法について比較し、各種指標について精度の高いものを考察している
評価方法
互いにlikeした=ポジティブサンプル、どちらかがnopeした=ネガティブサンプルとして評価している
精度関連
https://gyazo.com/5530dcfa53e3b32252f3f1ecb8922ee6
Reciprocal Collaborative Filtering (RCF) 、Latent Factor Reciprocal Recommender (LFRR) について比較している
マッチングの信頼に関わるのでなるべく予測を外さない方がいいとのことで、recallが大事らしい
RFCではuninormが、LFRRでは調和平均がよい(F1 scoreを見ているのだろうか)
https://gyazo.com/e4dc09e7a3968cdf23d2e48d6017f76e
https://gyazo.com/9596e2864f3449a02f8a1a3a9741dfcd
実行時間
リアルタイムで学習し、レコメンドするような問題設定をしている。1人のユーザに対してレコメンド結果を生成するのに30分(1800秒)以上かかるのは実用的ではないとしている。
LFRRは現実問題を考えると10,000,000(1,000万回のインタラクション)のデータセットに対しては、2.0秒でありリアルタイムにレコメンド結果を生成することが可能である
RCFは100,000くらいであっても30分以上かかり、リアルタイムにレコメンドする場合、実現は困難である
ただし、今回は並列実行については検討していない
https://gyazo.com/38e40f96e16b7f8e057759369e02dee0
展望(新しい特徴とか)
ユーザの目的(本気か遊びか)を考慮し、同じような目的を持った人同士でマッチングするとか
活発的なユーザと受動的なユーザの違いを区別して、受動的同士はマッチングしないようにするなど
参考
今後読む
相互推薦ratingの重みづけ(高評価する人と低評価する人とか)を考慮しているらしい