推薦システムのA／Bテストにおけるポイント
並川淳氏：ここまでMLアーキテクチャの話をずっとしてきたんですけど、ここからは少し趣向を変えて、分析やA／Bテストの話をしていきたいと思います。
というのも、MLアーキテクチャが仮にあったとしても、その上で動くモデルをチューニングして良くしていくためには、分析やテストが欠かせないからです。なので、我々はアーキテクチャだけではなくて、データ解析を非常に重視しています。
分析について最初にお話ししたいことは、推薦システムの評価指標についてです。というのも、モデルをチューニングして良くするといったときに、何をもって良いのかが決まらないと当然チューニングもできないわけなので、その「良い状態」を数理的に定義しておく必要があります。
イントロダクションで紹介したように、我々は現在「Score」と呼ぶクリックとバツボタンの押された回数の比をメインの指標にしているんですけど、このScoreという値をメインの指標として選んだ理由は大きく分けて3つあります。
1つ目は、ユーザーに「どのコンテンツが好きですか？」というアンケートを取ったんですね。そのアンケート結果といろいろな統計的な指標を比べた結果、このScoreとそのアンケートの満足度の相関が非常に高かった。少なくともCTRよりもすごく高くて、アンケートとの親和性が高かったことが、選んだ理由の1つです。
2つ目は、計算がすごく楽ということです。これは意外とバカにできない理由です。
3つ目は、時間的な安定性が高くて扱いやすかったという点です。この時間的な安定性とはどういうことなのか説明がいると思うので、グラフを用いて説明したいと思います。
これはSmart Channelのリリース初期の頃のグラフで、青色がScoreと呼んでいる値で、赤色がCTRで、緑色がバツボタンのCTRになっています。
所々で、赤色の線と緑色の線がパッと立ち上がってしばらくすると減衰するようなカーブを描いていると思うんですけど、この値が跳ねているときに何があったかというと、スタンプやニュースや漫画といった新しい種類のコンテンツをリリースしたり、表示する対象ユーザーを拡大したりした、そういうリリースのタイミングなんですね。
これはどういうことかというと、最初はユーザーは見慣れないのでクリックもするしバツボタンも押すんですけど、だんだん見慣れてくるとポジティブな反応もネガティブな反応も減ってくる。つまり目新しさによる一過性のものだと僕らは考えています。
これはユーザーの満足度とは関係なくて、ただ単に物珍しいものに対する反応に過ぎないので、そのような数値に一喜一憂するべきじゃないわけです。例えばCTRを僕らのメインのKPIにして数値を追い求めると、物珍しいものをユーザーに表示すれば一時的に上がるので、ユーザーが好むか好まないかにかかわらず、どんどん変なコンテンツを見せるほうに走ってしまう可能性もあります。
一方、見ていただいたらわかるように、Scoreはそういう減衰するような振る舞いはなくて安定している。リリースしたら数値自体は変わることはあるんですけど、時間的に減衰したりはしないので、そういう意味で非常に扱いやすい指標です。
この3つの理由によってScoreをKPIに選びました。
ダッシュボードでステータスを確認
インプレッションやScoreやCTRのような統計量は、ダッシュボードに表示されていて、プロジェクト関係者は日々この数値を見ています。このダッシュボードでは、どういうタイプのコンテンツがどれくらい表示されてるのか、それぞれのScoreやCTRはどうなのか、前の週より良くなってるのか悪くなってるのか、などが一覧で表示されます。
さらに、いろいろなサービスのコンテンツの情報を表示するので、あるコンテンツで異常が起こったみたいなことはダッシュボードを見ているだけではなかなか気がつきにくいんですね。なので、異常検知をするシステムも作って、異変を見落としてしまう可能性に対処しています。
スライドの例ですが、Slackに実際に通知して、異常があれば我々は分析をして対応しています。
新しいモデルを実装したり、新しい特徴量を作った場合に、A／Bテストでユーザーに表示して評価する前に、事前にテストするためのオフラインテストの環境があります。A／Bテストをやるためには実際にシステムを開発しなければならないので、そのコストを払わずにできるオフラインテストは、非常に低コストでたくさんの実験ができるメリットがあります。
我々はログをDataLakeと呼ばれるHadoopクラスタにためて、オフラインテストのコードはJupyterなどで簡単に書けるようにしておいて、簡単に新しい特徴量や新しいモデルを評価できるようにしています。評価用のシステム自体は本番と同じシステムのクローンを使うことができます。
最後にA／Bテストなんですけど、弊社では「Libra」というA／Bテスト用のシステムが存在します。画面の左側がLibraを利用しているサービスのリストなんですけど、いろいろなサービスがこのLibraを使ってA／Bテストをやっています。Smart ChannelでもこのA／Bテストのシステムを使って最適化のアルゴリズムやUIを改善しています。
画像の追加でCTRが劇的に変わる
ここまでアーキテクチャとデータ分析とA／Bテストの環境について話をしたので、最後にA／Bテストを実際にやってみた事例をいくつか紹介していきたいと思います。
Smart Channelについては、レコメンデーションの改善に関わる部分だけでも多くのA／Bテストをやってきました。ここではその中で改善の幅が大きかったものについて3つほどご紹介したいと思います。
1つ目はモデルを切り替えた件ですね。MLアーキテクチャのところでモデルの説明をしたと思うんですけど、そのときはBayesian Factorization Machineを使っていると言いました。ただ、実は初期は別のモデルを使っていました。それはLinUCBというモデルで、これもContextual Banditの一種なんですけど、線型のモデルという特徴を持っています。
線型性についてここですごく重要だったのは、並列計算がめちゃくちゃ楽ということでした。線型なので差分を全部足し合わせれば完全に同じものになるので、途中で紹介したような並列計算アルゴリズムなどは一切抜きで実装できます。なので、すごく実装が楽だったので、最初はこれを使ってました。
ですが、Factorization Machineのようなものを使ったほうが精度がいいだろうと思ったのでA／Bテストをしてみたところ、CTRは上がって、バツボタンのCTRは下がりました。つまりポジティブな反応が増えてネガティブな反応が減り、結果Scoreが上がりました。
これは並列計算のモデルとかアルゴリズムの研究が必要だったりでコストはかかったのですが、やった価値はあったという事例の1つです。
2つ目なんですけど、今回ご紹介するのは推薦の数値が良くなった順に紹介していて、実は2番目に良かったのは、機械学習はぜんぜん関係なく、ただUIを変えたという話になっています。
これは何かというと、Smart Channelで昔ニュースは画像が表示されてなかったんですね。ただ文字だけでニュースの説明をしてた。それを画像を表示するようにしたときにどうなるかというA／Bテストをやりました。
これはそもそも画像が小さいので「効果あるのか？」みたいな話は事前に議論にもなりましたし、あとは、あそこの枠にたまたまきれいに表示させる画像もなくて、うまくクロッピングするようなシステムの追加開発が必要だったので、コストはかかったんですけど。
実際にこんな小さい画像でも効果あるのか、A／Bテストで試してみたところ、これがすごかったんですね。CTRが一気に56パーセントも上がっちゃって、モデルを変えるよりもぜんぜんいいという感じ……。
（会場笑）
本当に「モデルとかどうでもよいんじゃね？」という感じなんですけど、一方でこのバツボタンのCTRもすごく上がっちゃったんですね。だから、画像を表示したことによって、ポジティブにもネガティブにもすごく反応を得ることができるようになりました。
ただ、結果的にそのポジティブ度とネガティブ度の比率でどうだったのかというと、Score自体もすごく上がったので、画像を見ることによってユーザーは好みのものを選べるようになったという意味で、全体的にもポジティブな事例でした。
3つ目は、モデルのところで説明があった、Embeddingを追加した件です。実はこのEmbedding部分についても最初は実装がありませんでした。 ただし、これがないとパーソナライズしたレコメンデーションはできないので本当はあったほうがいいんです。
ただ、最初に説明したように、各サービスのレコメンデーションシステムがすでに個人化されているので、ここがなくても一応個人化されたものが推薦されるので、必須かと言われるとそうでもない。こういう状態において、こういう特徴量を追加したときにどうなるのかをA／Bテストしました。
結果はこのようになっていて、数値の動き自体は先ほどの画像の例よりも小さめなんですけど、CTRは上がって、バツボタンのCTRがすごく下がって、結果的にScore自体は画像を追加するよりもかなり大きい改善結果が得られました。なので、一応UI改善よりもいい結果も時々はあるみたいなかたちで、機械学習やっててよかったねというかたちです。これはネガティブな数字の変動がなくて、すごくうまくいった結果になっています。
将来的には各サービスの推薦システム自体を統一させる
このように僕らは日々A／Bテストを繰り返してモデルやUIを改善しているんですけど、最後に、今後僕らがどういうふうな世界を目指していて、どういうふうに改善していこうと思っているかを紹介したいと思います。
これも最初のほうに出た絵なんですけど、現状は、実は各サービスからレコメンドの結果を受け取って、それをさらに選んでユーザーに届けるみたいな、一方通行のシステムになっています。
ですが、本当に最適化を極限まで突き詰めていこうと思うと、この中央のシステムと各サービスの推薦システムがカップリングしてうまく最適化したほうが当然精度は上がるので、一方通行になっているのを双方向に変えて精度を上げていきたいと我々は考えています。
ただ、そのためには各サービスの推薦システムやデータ基盤が違っていると当然コストがかかりすぎるので、我々は、各サービスの推薦システム自体も統一させる方向で今動いています。
データ基盤のクラスタを1つに統一したり、マシンラーニングを計算するGPUクラスタをKubernetes上に構築して、みんなが同じような環境でマシンラーニングを実行できるようにしたり、そういうシステムを作ることで各サービスの推薦システムをうまく統一して、全体のサービス横断のシステムと連携できるようにすることを我々は考えています。
以上で発表を終わります。ご清聴ありがとうございました。
（会場拍手）
