NewsPicksにおけるレコメンドエンジニアのお仕事について

NewsPicksでCTOをしている高山です。最近の仕事のうちの大きな部分は、レコメンドエンジンを開発するチームのプロダクトマネージャー的な役割です。

今回はレコメンドエンジニアに興味のあるエンジニア向けにNewsPicksにおけるレコメンドエンジニアのお仕事を紹介してみます。

NewsPicksにおけるレコメンドのこれまで

2019年以前

Google Chrome拡張機能でNewsPicksの最初のレコメンドエンジンが数年前に作られました。それを元にして「マイニュース」機能に朝刊・夕刊機能が作られました。

その機能を作った北内はユーザベースの機械学習システムを数多く構築してきたメンバーで、NewsPicksのレコメンドエンジンにおいてもブレーンといえる存在です。

北内によるスライドが公開されています。レコメンドエンジンでは一般的な手法である「協調フィルタリング」と「コンテンツベース」のアルゴリズムを組み合わせるものです。

https://www.slideshare.net/tau3000/newspicks-82760305

2020年以降

スマホアプリ版NewsPicksが大幅リニューアルして、トップ画面がレコメンド主体のUIになりました。リニューアルのレコメンドエンジンは従来の朝刊・夕刊をベースに、無限スクロールというUIに合わせて再設計したものです。

NewsPicksのアルゴリズムチームのミッションの大部分が、このレコメンドエンジンを改善していくことです。

NewsPicksのレコメンドエンジニアのお仕事

レコメンドを開発するチームのお仕事を列挙してみます。

  • アルゴリズムを考える
    • 論文やブログなどから新しい手法を見つけてくる
  • アルゴリズムに渡すデータやパラメータを探索する
    • データの量や閾値や特徴量を変えて実験する
  • 手元で実験したモデルをリアルタイムなシステムとして実装する
    • クラウドを駆使して設計する
    • 処理時間やメモリ使用量などを最適化する
  • パフォーマンスを計測する
    • リリースは必ずABテストで比較して判断
    • 既にリリースされているモデルについても、SQLを書いたりBIツールなどで可視化して仮説を検証する

などなど。

分析などのデータサイエンスっぽい場面もあれば、ガリガリDevOpsする場面もあり、それでいてユーザーの利用スタイルなどがイメージできていないと仮説を立てられないUX的な側面もあり、チームの総合力が試されます。

最近の改善例

より具体的に、最近やった改善施策から「協調フィルタリングのライブラリをLIBMFからimplicitに切り替え」を紹介します。

オフライン評価

まず、NewsPicksのサービスの性質としてimplicitのほうが合っているのではないかと仮説を立て、手元でコードを書いて実験をしました。

過去数ヶ月分のリアクション(閲覧、Pickなど)のログを使ってモデルを作り、その後数日の間にユーザーがリアクションしそうなアイテムのランキングをユーザーごとに作成します。そのランキングの中で実際にユーザーがリアクションしたアイテムが上位に現れたかどうかを数値化します。nDCGという指標を用いました。

リアクションログの量や、各リアクションの重みや、ライブラリに与えるパラメータなどを変化させながら、何十パターンかの実験を繰り返します。その中でほどよくスコアが高く、必要以上にデータ量を使わなくても良いモデルを選択しました。

モデルが決まると、本番のコードに移植していきます。本番のコードは1日1回のバッチ処理と、その後逐次入ってくるログを処理するストリーム処理の組み合わせになっています。1日1回のバッチ処理では過去数ヶ月分のリアクションログを読み込んでモデルを再構築するようになっているため、疎行列のライブラリを使うなどメモリの節約をしました。

オンライン評価

この時点では我々はA/Bテストができる仕組みが充実していなかったため、A/Bテストを行えるようにシステムを作っていきました。

ようやくA/Bテスト開始です。実際のログをダッシュボード化して、様々な指標を並べて見られるようにしました。

ここで問題が発覚しました。手元の実験では大幅に改善していたのですが、A/Bテストでは逆の数値になっていました。こうなるとひたすら調査です。レコメンド以外の要因を疑ってログを見たり、一度巻き戻して問題切り分けのためのABテストをしたり、途中のデータを見たりして、かなり苦労した結果ようやくコードのバグにたどり着けました。

普通のプログラムのように、コードのバグがエラーとして現れるわけではなく、不可解なログとして現れるところは辛いところでした。

その後またA/Bテストを仕込んで、何日もグラフを見て有意差を確認した後にようやく全面適用することができました。

レコメンドエンジニアリングの楽しさ

前述しましたが、レコメンドの楽しさはこのような総合力が求められることだと思います。上記の例も一人ではなくチームの総合力で成し遂げられました。

仮説を出すためにはUXのことを考えなければいけませんし、仮説から先行事例にたどり着ける学術的な知識も必要になります。システムに落とし込む設計力やチューニングするときにはコンピュータサイエンスの力が求められます。A/Bテストをするときには統計の知識ももちろん使うことになります。

自分自身、データサイエンスのお仕事といえば回帰や分類モデルを作ることを想像していましたが、もっともっと幅広い領域にまたがることが意外でやり甲斐を感じていることです。

これからの展望

NewsPicksにおけるレコメンドはまだまだ始まったばかりで、ユーザーさんによってはまだまだ改善の余地があると言われるかもしれません。

しかし、着実に一歩一歩改善のサイクルが積み上がっていますので、自信も付いてきています。今後はさらに大胆な改善を予定しています。

© Uzabase, Inc. All rights reserved.