@@+みなさま、おはござです。++最近、クロスドメインレコメンドに取り組む機会がありまして、「よろしく!」みたいな感じになったものの、どうやってやるんだ?????となりその過程でそこそこ調べ物をしました。+この記事はその調べ物の供養です。安らかに眠ってほしいと思います。PopularItemsに負けることすらあり、クロスドメインレコメンドはとても難しい++前半が説明パート、後半が実験してみた結果報告パートです。+前半が結構冗長になってしまったので、後半で使ったコードを置いているリポジトリのURLを予め貼っておきます。そもそもクロスドメインレコメンドとは++クロスドメインレコメンドというのは調べて初めて気付いたのですが、英語でも全然まとまっている文献がないです。転移学習とかそういう文脈と一緒になってるからだと思います。++ちなみにqiitaでも全く記事がないです。出てくるのはクロスドメインリクエスト(AjaxとかCORSとかそういう文脈)でした。++一番まとまっているのは[2014年のRecSysチュートリアル](https://recsys.acm.org/wp-content/uploads/2014/10/recsys2014-tutorial-cross_domain.pdf)です。src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109201/465f0d22-5492-1bd6-7578-1c89b03836f3.png">++この記事も主にこのスライドをなぞりつつ省きつつという形で進めていきます。実際のスライドを引用して貼っていきます。transfer)、レコメンドを行うこと」とされています。++クロスドメインレコメンドの歴史はとても浅く、2002年に初めて文献に登場したようです。2005年からちらほら言及が出始めて2007年にいくつか論文が出てきたって感じですね。レコメンドという文脈におけるクロスドメインの歴史はまだまだ浅いです。ドメインの定義++ドメインがそもそも何を指すのか、ですが大きく「アイテムの種類の違い」・「ユーザの種類の違い」に分けられます。頻度の違うユーザ(超アクティブユーザとほぼ休眠ユーザ)、アクションしているサービスが違うユーザ++わりと解釈次第でドメインの違いは考えられそうですね。僕は大雑把に分布が違いそうだなと思ったら違うドメインになりそうくらいの理解をしています。いう4つに分類されておりまして、一番論文でよく出てくるのはItemレベルのクロスドメインを扱ったものだそうです。src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109201/ba308c2d-0bd8-70a7-db41-a87c32fedcc8.png">++自分のやりたいクロスドメインレコメンドがどれに当たるかを考えた上で「これはあまり論文なさそう」とか「結構見つかりそう」とかの指針立てに使えそうな数字ですね〜。クロスドメインの状況の分類++さて、クロスドメインが定義できたところで、次は「ソースドメインとターゲットドメインがどういう関係性になっているか」も考えないといけません。++![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109201/e1c4ce32-9b0d-b9aa-fd4f-f9e44267bc1f.png)++その「シナリオ」は全部で4つあります。Overlap`)++シナリオごとにどんな手法が使えるか、効果的なのかが変わってくるので注意が必要です。論文を読むときに「こいつはどういうシナリオに対する手法を提案しているのか?」に気をつけながら読むと良さそうです。++ちなみに、当たり前ですが重なりが大きければそれだけ転移がしやすくなり難易度が下がります。どんな手法でクロスドメインレコメンドをするか++さて、そろそろ本題に近づいてきました。「クロスドメインレコメンドってどうやるの?」パートです。transferをどうやるかってことで、大まかに2つに分けられます。src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109201/a77e7034-af79-f937-cfed-9e1c32ea985c.png">++さて、これだけだとスライドにもあるように「曖昧すぎる!!!」ですね。具体的にどうやるかでいうと、それぞれ更に小さい分類になります。src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109201/2f6537bf-7625-8867-5742-f9eae0298c20.png">++それぞれ具体的な例などを混ぜつつ説明していきます。single-domainテクニックを使うなど、のようなまとめあげる手法です。Data`+各ドメインでユーザ・アイテムベクトルを得た後、ターゲットドメインにアクションしていないユーザに対しては、ソースドメインでのk近傍ユーザ(ターゲットドメインでアクションしている人たち)を獲得し、それらk近傍ユーザのターゲットドメインに対するレコメンド結果の平均を、対象ユーザへのレコメンドとします。するかは色々バリエーションがあります。Recommendations`+a.1とa.2はなくてもできますが、この手法はユーザとアイテムの両方がドメインでまたがっている必要があります。両方のドメインそれぞれでレコメンドを出した後、それらの予測値をマージして対象ユーザへのレコメンドを出します。+(movielensを対象にしたcombineアプローチの一例。Domains`+主にターゲットドメインに対するレコメンドのみを行いますが、その計算を行う際にソースドメイン・外部知識を制約条件に入れて、ターゲットドメインのレコメンドのカバレッジ・精度をあげようという感じのものです。factorをシェアすることで行うというものです(これは`adaptive`な手法で、`collective`に行うものとして同時に解くというものもあります)。+ユーザとアイテムが重なっていて、ratingパターンだけが違うシナリオであれば、同時に解く感じの手法が使えます。factorization`などがあります。Patterns`+ユーザもアイテムも重なっているものがないけど、という場合にはこの手法が使えます。matrixを同時にクラスタリングして(`co-clustering`)、同じクラスタに属する、などの情報を使ってターゲットドメインへのレコメンドを行います。実際にクロスドメインレコメンドをやってみよう+さて、ここまで長々説明してまいりましたが、実際にやっていってみましょう。ユーザのみオーバーラップしているデータ(http://jmcauley.ucsd.edu/data/amazon/)++という感じでやっていきます。こちらはCCAの代わりにいい感じのニューラルネットで写像関数を学習します++という感じです。https://github.com/fufufukakaka/cross-domain-recommend-survey++以下、コードを交えつつどんな感じで実際にやったのかを見ていきます。`Aggregate`++ここではMovieLensでやったものをコード例として示します。`Aggregate`以外でも必要になるデータの準備からつらつらと書いています。matrixとして扱います。([RecSys2019BestPaper](https://github.com/MaurizioFD/RecSys2019_DeepLearning_Evaluation)のリポジトリにあった分割関数)を使って、testにいるユーザがtrainにアイテムがない状態がないように分割します。full_train_percentage=0.2)+```+++trainデータが作れたのでこれを使ってALSを実行。model.item_factors.T)+```++testデータから、評価用の辞書を作成します。matrixから、testデータのユーザに対してターゲットドメイン(adventureジャンル)のアイテムを推薦し、その精度をndcgで測ります。{np.mean(ndcgs['ndcg100'])}")+```++![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109201/dcb8f325-eb5a-bb51-4233-98b7179f2e5c.png)++という感じで、一連の流れを見てみました。++ndcg@5で0.11ということで、クロスドメインレコメンドにしては予想よりも高い数値が出ました。MovieLensは一つのアイテムに複数のジャンルがつき、ActionとAdventureはかぶっていることがかなりたくさんあるので、クロスドメインの問題設定としては簡単な部類に入るので、こんなもんかなという感想です。+というか、MovieLensをクロスドメインの問題として解くことがあまりない(`Aggregate`自体は通常のレコメンドとなんら変わらないですが)。++今回はスコアまで示しましたが、スコアは最後に表でドンと示すこととし、以降はあくまで流れを追う形で進めていきます。Mediate`++ここからは前項とはかぶらない部分のみコードを紹介します。それらk近傍ユーザはターゲットドメインにもアクションしているので推薦が出せる。これら推薦結果の平均を、最終的に推薦したいテストユーザへの推薦とする。++文字にするとこんな感じで、絵にすると以下のようになります。NearestNeighbors()+neigh.fit(action_ALS.user_factors)+```++k近傍探索空間ができたら、近いユーザを求めていきます。今回はk=10とします。+(ソースドメインとターゲットドメインで、matrixのshapeが異なり同じindexではないので、ちょいちょいそれに対処するようなコードが入っています。candidates_[:10]+```++上記で求めた近傍ユーザを使って推薦を行います。Factorization`++ソースドメインの情報を補助情報的に扱い、ターゲットドメインへのレコメンドを行います。++詳しいことは割愛しますので、以下の情報をご覧ください。-](https://qiita.com/keitakurita/items/3a12708dc87e76497832)++予め、ソースドメインでALSを行い、ユーザベクトルを得られているものとします。informationとして使います。ような形でできるのでこれを使ってndcgを出す、という感じです。Vector(CCA)`++ソースドメインからターゲットドメインにユーザベクトルを変換することを考えます。matrixを予測することができるようになるためです。++CCAについてはこちらの記事などが詳しいです。overlap_adventure_user_vectors)+```++CCAでX->Yに対する写像を行いたいときは、CCAで取り出した共通成分に変換->そこからYの次元に戻す、といった感じで写像することが出来ます。Net)`++というわけで最後の手法です。上述したCCA部分がニューラルネットになるだけです。ベクトルを受け取ってベクトルを出すイメージとして一番最初に浮かんだAutoEncoderで学習を行います。autoencoder+```++seed固定だけだとどうしても結果が変動してしまうので、今回のみ10-foldそれぞれのモデルを取り出し、各モデルによるndcgの結果を平均して結果とします。結果と考察++長々やってまいりましたが、これでそれぞれの手法に関する説明ができました〜。ここまでお付き合いいただきありがとうございます。+それでは最後に各手法の結果を見ていきましょう。Itemsを置いています。|++はい、ということでMovielensは`ndcg@20`から、Amazonレビューデータセットに至っては`ndcg@5`からPopularItemsに圧倒されてしまいました...++なんでMovielensだと勝ててAmazonだと負けるのかですが、両方のドメインにアクションしているユーザ数の違いが一番大きな差ではないかと思われます。**37388**++前述したように、Amazonのほうはアイテムは一つのジャンルのみを持ちアイテムの重なりがありません。加えて、両ドメインにアクションしているユーザ数が全体の約5%しかなく、Movielensの約50%の重なり具合と比較するとどうしても難しい問題になっていることが推察できます。++これだけしか重なりがないと、両ドメインにアクションしているユーザから得られたデータでどれだけ推薦を行っても推薦する外のユーザの行動の仕方が、両ドメインにアクションしているユーザとかけ離れていることも考えられます。++ユーザの重なり具合が10%以下になってしまっている場合には、クロスドメインらしいアプローチをしなくともPopularItemsやAggregateなどシンプルなアプローチに留めておくのが安全なのかもしれません。ユーザ・アイテムの重なり具合で問題の難易度が変わる(ベースラインにギタギタにされることも十分有り得る)++また別の供養の機会などあれば、そのときまでに別ドメインの組み合わせを試したり、エラー分析をしたり、もうちょっと最新の論文の手法を実装して試してみたりなどに取り組んでみたいなと思う次第です。