Wantedly Visitの機械学習を使ったレコメンデーション

Wantedly Visitで開発チームのリーダーをしている久保長です。ここ最近は、Wantedly Visitのレコメンデーションを強化するために、推薦チームの立ち上げも行ってきていました。

推薦チームを発足して二年間で、大きな成果を生み出すことができました。具体的には、例えば「募集の推薦画面に表示されてから話を聞きに行く確率」といういうような主要指標が２倍になり、ユーザ体験にも大きな影響を与えることができました。

もともとレコメンデーションの経験がなかったこともあり、当初、全体的に取り組まないといけないことはなにか、どのように最適化を進めていくのかが分かっていませんでした。今回、一つ一つのトピックについて簡単にはなりますが、できるだけ関係しているプロジェクトの全体が分かるようにまとめています。機械学習を使った様々なアルゴリズムを取り入れたことに加えて、UIや基盤の改善についてもそれぞれお話します。

UI・基盤・推薦それぞれについて取り組んだことと成果

以下の図は2017年から2018年の間に、UI・基盤・推薦それぞれについて取り組んできたことのサマリと主要指標の推移です。

2017年前半は基盤構築を取り組み、2017年からUI・基盤・推薦それぞれ進めています。主要指標は、2017年後半は2017年前半と比べて130%、2018年前半は160%、2018年後半は200%と大きく、改善してきました。

2017年前半

BigQueryへのデータ集約

BigQueryへのデータの集約とは、ログデータやDBのデータを全てBigQueryに集約することです。Wantedlyでは、10GBほどのログを毎日Treasure Dataというログ収集サービスに保存していました。Treasure DataにもQueryを実行する機能はありましたが、大きなデータをJOINするような複雑なクエリは１時間以上かかり実行できないものもありました。BigQueryに移行することで、従来の100倍近いパフォーマンスで実行できるクエリもあり、生産性が大きく向上しました。また、コストも安いため、全てのデータを集約することができました。

フィルターとパーソナライズを両立させる仕組み

Visitでは、何も絞り込みを行わずに推薦することに加えて、職種や地域やタグなど様々な絞り込みの項目があります。また、自由入力のワードで絞り込みを行うこともできます。もともと検索はelasticsearchを利用していましたが、スコアが複雑になるに連れて仕組みを変える必要がありました。

redisのsorted setを利用することで利用頻度の高いデータをキャッシュしながら素早くフィルタリングする仕組みを実装しました。

再現性のあるデータの保存

アルゴリズムを評価しようと思った際に、過去のアルゴリズムを簡単に再現できませんでした。推薦で利用するスコア、利用する際にどのアルゴリズムをどの順番で表示したか、スコアを計算する上での元データそれぞれを残しておく必要があります。

推薦で利用するデータは毎日更新しますが、更新するタイミングでBigQueryにも保存しています。また、推薦のリクエストがあった時はどのアルゴリズムをどの順番で表示したかログに残しています。スコアを再現するために、RDBのデータのスナップショットもBigQuery上にコピーをしています。

オフラインの評価基盤

推薦の評価は以前のブログでも説明しましたが、いろいろな方法があります。

もっともシンプルなものは、推薦したデータに対して、クリックやユーザーアクション（ブックマーク、応援、応募、送信）がどのくらいの割合で行われたか、precisionを計算する方法です。再現性のあるデータを保存することができていれば、実際に表示したアルゴリズムと比較して新しいアルゴリズムのパフォーマンスを比較することができます。

評価の時、ユーザに表示したことがないものを評価することはできないと考えてしまうと思いますが、ユーザも目的のものを探すためにたくさんのアイテムを見ていることもあるため、過去のデータを利用することで評価は可能なことが多いです。少し新しいアルゴリズムの方が不利な状態で、既存のアルゴリズムに勝つことができると安心してリリースができます。Visitでリリースした全ての新しいアルゴリズムは過去のアルゴリズムに勝つ評価結果を見て、リリースしています。

オンラインの評価基盤

A/Bテストという手法を使いました。推薦アルゴリズムを複数のユーザー群に分けて実験することです。

運用していると、ウェブサービスのA/Bテストは、終わりを自分で決められるため、たまたま良くなったタイミングでテストが終わることが発生していました。評価する際にどのくらいデータがばらついているかはある時点の数字を見るだけだと判断できなく、結果だけ見ると正しいように見えて困りました。

対策として、1時間ごとに指標の変化率とp値の変化をグラフにし、判断の精度を上げました。最初に基盤を整えることで、徐々に推薦アルゴリズムの開発が行いやすくなりました。(airbnbのブログを参考に実施しました)

2017年後半

検索条件の利用の促進

ユーザーの体験を促進する上で、そのまま推薦したものを見せるのか、フィルタリングを行なって見せるのか、自由入力でキーワードを入力してから見せるのか、パフォーマンスを評価しました。結果的に検索条件や自由入力を即すようにUIを最適化しました。

基本的には、ユーザーの負荷は、自由入力->フィルタリング->そのまま推薦で、ユーザーの求めるものを見つける確率は、その反対になります。そのため、利用するためのハードルを上げるか、推薦した後の精度を上げるかのトレードオフになります。

目的があって（検索キーワードが思いついて）サービスにアクセスするサービスか、サービスを使い続ける人が増えて自由入力キーワードを考えてくれるようになっているか、推薦できるコンテンツの数など、サービスの特徴や成熟度によっても解は異なるかもしれません。

検索の高速化

ユーザー体験を上げる上で高速化は非常に重要です。推薦アルゴリズムの実行時間は200ms、すべてのデータを返すまでの速度は500msなど目標を決めています。

リクエストのログにもレスポンス速度を含めることで、特定のユーザや特定のクエリのパフォーマンスが落ちてないかチェックできるようにしています。

順番を返す、アイテムの詳細情報を取得する、ユーザー特有の情報（ブックマークしたか）など、処理を分けて適切にキャッシュを行うと速度を改善しやすくなります。

BigQueryを使ったコラボレーションフィルタリング

コラボレーションフィルタリングとは、ユーザーのアクションの関係性から近いものを推薦するというものです。

シンプルなのですが、実装する上でボトルネックはありました。アクションログの収集とジョブの実行基盤とスケーラビリティを考えた実装です。というのも、例えばあるアイテムを閲覧したというデータは非常に大きくなりやすく、シンプルなアルゴリズムでは実行ができなくなります。大きなグラフを扱うテクニックはありますが、実装のハードルは上がります。また、実行速度が遅くなることで、データクレンジングの試行錯誤が進めにくくなります。（データクレンジングは推薦において非常に重要で、様々なことを行っています。例えば、ボットやスパムのような動きをするユーザー、ランダム性の高いアクションなどです。）

BigQueryを利用することで、ジョブの実行ごとBigQueryで管理し、シンプルなアルゴリズムで非常に高速に処理を行うことができます。シンプルなアルゴリズムの具体例としては、ユーザーのアイテムごとの積集合と和集合の比やコサインを使った類似度の計算です。ざっくりいうと、BigQueryを使うことで、力業で目的を達成できます。

interleavingによるオンライン評価

もともとA/Btestingを行なっていましたが、評価を行う上での精度や速度に問題がありました。評価する精度や速度は、サンプル数と指標の変化量に依存します。想定よりも良い改善なら良いと判断できますが、悪い場合は判断できなくなります。

つまり、少し良い施策や少し悪い施策は判断できません。また、実務上常に判断できないものは取り込まないともできない中、施策を行なっているチームは良くなって欲しいというバイアスがあるので、結果的に悪いものを取り込みやすくなります。

interleavingはAとBにユーザーを分けるわけでなく、AとBというアルゴリズムを交互に同時に出すことで評価を行う手法です。interleavingを利用すると、指標は10倍以上の違いが生まれ、言い換えると、10倍以上速く判断できるようになり、実務的には逆効果な施策を取り込むことが減ります。(netflixのブログを参考に実装しました。techbookにも詳しく書いています。)

2018年前半

コンテンツリッチなUIに

ここでコンテンツリッチとは、画像サイズを大きくし、推薦する際の一つ一つのアイテムの大きさを大きくすることです。推薦の精度が上がってくると、コンテンツリッチなUIにしやすくなります。少ない推薦でもユーザーは目的としているアイテムを見つけることができるからです。推薦精度に合わせてユーザの行動は変わるので、それに合わせてUIを変更していくことで、よりよいUXが実現できます。

キーワード検索に計算したスコアを反映する仕組み

キーワード検索のスコア計算が複雑になることによるパフォーマンスの悪化の解決と、よりフレキシブルにキーワード検索にスコアを適用していくことを取り組もうとしていました。

elasticsearchは、シャードを増やすことでパフォーマンスを改善できますが、200ms以内にレスポンスを返す目標に対して、クエリ実行時にたくさんの計算を行うことは両立できませんでした。また、新しい推薦案ではアイテムごとのアクションではなく、検索キーワードごとのアクションを元に検索キーワードごとにスコアを計算することを考えていました。

調査すると、上位1000件のキーワードで、クエリ全体の90%をカバーし、ページネーションはあまり深くは行われておらず、上位200件で90%以上をカバー出来ることが分かりました。精度と速度のトレードオフを考慮して、適用範囲を制限して実装することにしました。具体的には、推薦を用意したキーワードは推薦を利用し、ない場合はelasticsearchにfallbackさせる。推薦の用意してないページまでスクロールした場合も、elasticsearchにfallbackさせました。

キーワード検索の最適化

もともとelasticsearchを利用しており、tf-idfを利用した文章中に含まれる単語の重要度の計算と、アイテムごとの特徴やパフォーマンスをスコアを計算する上で利用していました。具体的には、rubyというキーワードが含まれ、重要度の高いかというスコアに加えて、画像があるなどよいコンテンツであること・ソーシャルに拡散されやすい・ブックマークされやすいなどを考慮して、クエリ実行時にスコアを計算していました。

上記に加えて、検索キーワードごとのアクションのスコアへの反映を行いました。例えば「ruby」と検索した時に応募されやすい企業は、「ruby」と検索した時により上位に表示させるようにするということを行いました。シンプルですが、非常に強力で大きくキーワード検索のパフォーマンスは改善されました。

ランダムウォークによるコラボレーションフィルタリング

ランダムウォークとは、文字通りランダムにグラフ上を移動することです。例えば、ある地点から100回移動した時、よく通過した地点は類似度が高いという計算をします。

類似度の計算をする際にランダムウォークを用いるメリットとしては、より深いグラフの特徴を反映できる、カスタマイズしやすい、スケールさせて計算しやすいということがあります。

より深いグラフ構造を反映させられることで、精度を上げることができ、推薦できるアイテムの数を増やすことができます。カスタマイズは、例えば、プロフィールに共通な点が多いユーザーのアクションを優先させたい時、ランダムウォークの際の移動する確率を変更することで対応できます。また、Visitの場合季節性が強い（年ごとにイケてる企業は変わる）ので、時間が経つと移動する確率を下げる処理も行なっています。