前編では、レコメンドシステムmarbleの概要について説明を行いました。後編では協調フィルタリングの下処理やMixChannelの使用例を解説します。
モデルベース協調フィルタリングにおける下処理の方法
行列分解
事前計算の手法の1つに、行列分解を用いる方法があります。前編の図2に示したようなユーザー／アイテム間行列について低次元の近似を求めることにより、ユーザーやアイテムをクラスタリングして扱い、レコメンド時の計算量を低減できます。
レコメンドでよく使われる行列分解の手法として、非負値行列因子分解（NMF）があります。NMFの特徴は、分解後の行列のすべての要素が非負になるようにうまく分解を行うところです。NMFでは、元の行列の値をある要素の足し合わせで表現することが求められ、各ユーザー／アイテムがそれぞれの要素をどの程度の強さで持っているかという表現が得られます。
たとえば、元の行列として、前編の図2の
を使うことにします。これを、NMFを用いて2次元に圧縮すると、
のようになります（有効数字2桁になるように四捨五入。以降同様）。この行列の積を計算すると、
となり、もともとの行列で値が1だった箇所は大きな値になっています。0だった箇所は、そのユーザーと共通のアイテムを評価したユーザーがそのアイテムを評価したかどうかで値が変化します。ユーザーBから見たアイテムCが0のままなのは、ユーザーBの評価したアイテムAとBを評価したユーザーの中に、アイテムCを評価したユーザーがいないためです。
このように、NMFを用いて行列を分解してから行列積を求めて元に戻すことで、協調フィルタリングによる評価値を求めることができます。実際の運用では定期的に行列分解を行い、その際に行列積の計算まで済ませておくか、行列積の計算処理が重い場合には分解後の2つの行列を保持しておき、アクセスに合わせてそのユーザーのベクトルとアイテム行列の積を求めることになります。
また、NMFで得られた次元の小さい行列の要素は、人間が解釈できる特徴を示している場合があります。たとえば、アイテムA～Dが映画を表しており、アイテムAとBは邦画、CとDは洋画だとします。すると、前者2つは要素0が大きく、後者2つは要素1が大きいため、要素0は邦画、要素1は洋画に対応すると推測されるといった事例です。この場合、ユーザーAは洋画と邦画の両方を見るユーザー、ユーザーBは邦画専門のユーザー、ユーザーCは洋画専門のユーザーということが分解した行列から読み取れます。
Word2Vec
Word2Vecは、自然言語処理の分野では有名な、単語のベクトル表現を求める手法です。「似た周辺語を持つ単語は似た意味である」という思想で、ある単語を入力するとその周辺語を出力するニューラルネットを作成し、その隠れ層への重み行列を用いるSkip-Gramが一般的な方法です。おもしろいことに、「東京－日本＋フランス」が「パリ」に近づくなど、得られた単語のベクトルで加算や減算がある程度成り立つと言われています。
Word2Vecにおける単語をitemID、文章をあるユーザーの評価したitemID列と読み替えることによって、Word2Vecをアイテムベース協調フィルタリングアルゴリズムとして用いることができます（もちろん、単語をuserID、文章をあるアイテムを評価したuserID列としてとらえるとユーザーベースになります）。「前後に似たアイテムが評価されているアイテムどうしは似ている」と考えると、自然に理解できるかもしれません。図1は、自然言語によるWord2Vecと、協調フィルタリングのためのWord2Vecを比較したものです。
図1 自然言語によるWord2Vecと、協調フィルタリングのためのWord2Vecの比較
Word2VecではNMFと異なり、ユーザー側のベクトルは得られません。そのため、ユーザーの行動とアイテムのベクトルを使って求める必要があります。たとえば、最近評価したアイテム5つのベクトルの相加平均を用いる方法などが考えられます。
また、求めたベクトルの要素がある特徴を表すといった直接的な解釈はできません。解釈を行いたい場合は、適当なアルゴリズムでクラスタリングを行うなどの処理が必要です。
レコメンドシステムの導入・運用
レコメンドシステムを導入、運用するには、多くの機械学習システムと同様に気をつける点があります。まず、目標を明確にすることが大切です。レコメンドシステムを運用していくには、何を学習データにするかも含めて広く調整を行う必要がありますが、明確なKPIが決定されていない状態でそれをするのは困難です。レコメンドシステムを含む機械学習システムでは、あとから目標を変えることが難しく、属人化やコード／ドキュメントの難読化の原因になります。
効果測定でも注意が必要です。レコメンドでは、単純なクロスバリデーションを用いると、テストデータにしか存在しないitemIDが生まれてしまう場合があります。また、レコメンドのあるなしでそもそもユーザー行動が変化するため、レコメンドがない状態の正解データをどの程度信用するかなどの問題が発生する場合もあります。したがって、それぞれの場合に対して工夫を行うべきです。
クロスバリデーションでは、順位相関や平均二乗誤差などさまざまな指標が考えられる中でどれを採用するかを考えておきましょう。実装が完了して現実的なKPIを追求する段階になったらA/Bテストを行います。このとき、セレクションバイアスの有無を確認するために、A/Aテストを行っておく必要があります。A群／B群のKPIは、統計上適切な方法で比較できるようにしておくべきでしょう。
ほかに、技術的負債を生まないための細やかな努力が必要です。前述のようなレコメンドアルゴリズムをライブラリによってシンプルに実装する程度であれば、アルゴリズムを解説したドキュメントを用意しておくくらいで大丈夫でしょう。しかし、ライブラリの入力／出力に対して細かな処理を大量に追加するコードを書く場合や、ニューラルネットワークなどを使用した複雑なレコメンドアルゴリズムを用いる場合には、コード面、インフラ面、ドキュメント面などを含めて細心の注意を払ってください。
MixChannelにおける使用例
MixChannelの協調フィルタリングアルゴリズムでは、おもにWord2Vecを用いています。これは、計算時間などを考慮すると都合が良いからです。しかし、今後さらなるKPI向上を目指す際には、ユーザー情報を協調的な部分と混ぜやすいほかのアルゴリズム（たとえば、行列分解を元にしたFactorization Machines）に変更することがありえます。
marbleでは、定期的に学習を行う学習用サーバ（Python）と、実際にレコメンド結果を返す計算用サーバ（Python）を分けて用意しています。学習用サーバでは、定期的に本番用DBから学習元となるデータを取得し、学習を行ったのちに学習結果を計算用サーバに送信しています。計算用サーバでは、学習用サーバから送られてきたデータを用い、APIサーバ（Go言語）から送られてきたuserIDに対する推薦結果を計算して返しています。これらのサーバ間通信では、速度や保守性、型付けの安全性を鑑みて、gRPCを利用しています。
協調フィルタリングではアイテムの絶対的な「良さ」が評価されないので、推薦を行う際にはデータに基づき、フィルタリングや補正をかけています。「良さ」を評価するための指標としては、「同時視聴者数」「最大同時視聴者数」「累計視聴者数」「獲得投げ銭」「最近の配信時間合計」などが考えられます。
さまざまな調整の結果、レコメンドシステム導入前に比べ、ホーム画面からライブ配信画面への遷移回数をA/Bテストベースで50％ほど向上させることができました。
おわりに
今回は、MixChannelに関する連載の第1回としてレコメンドシステムについて述べました。この記事が読者のみなさんのシステムを改善するきっかけになればさいわいです。
次回は、MixChannelにおけるサーバサイド開発についての記事を予定しています。
- 特集1
イミュータブルデータモデルで始める
実践データモデリング
業務の複雑さをシンプルに表現！
- 特集2
いまはじめるFlutter
iOS/Android両対応アプリを開発してみよう
- 特集3
作って学ぶWeb3
ブロックチェーン、スマートコントラクト、NFT
