はじめに

こんにちは。Pococha 事業部エンジニアの杉原です。社内の AI 専門チームと連携して、タイムライン推薦の改善や配信審査の効率化に取り組んでいます。

本記事では、 Pococha のエンジニアが取り組んでいる課題の中で、Pococha におけるライバーの推薦システムについてご紹介したいと思います。

Pococha におけるライバーとリスナーのマッチング

Pococha のプロダクト設計で最も大切にしていることは、ロングテールなサービスを作ることです。アイドルやインフルエンサーのような有名人でなくても、老若男女誰でも配信を始められて報酬を受け取ることができる、そんなサービスを目指しています。Pocochaの目指すロングテールプラットフォームの詳しい説明はプロデューサの水田が公開している Note の記事をご覧ください。

プラットフォームビジネスにおいて、ユーザー同士のマッチングは重要な要素です。更にロングテールプラットフォームを目指しているPocochaにおいては、多様な価値観、多様なコミュニケーションを認め、どんな人でもPocochaには居場所がある！と思ってもらえる体験を作る必要があります。新しく配信を始めたライバーは事前準備をしなくても自然とリスナーが集まって交流が生まれ、新しく視聴を始めたリスナーはタイムラインを巡回しなくても応援したいライバーを見つけることができるようにするために、個別最適された精度が高いマッチングロジックが非常に重要となります。

推薦システムの構成

Pococha ではタイムラインの一部に機械学習による推薦システムを導入することで、ライバーとリスナーのより良いマッチングを実現しています。

推薦システムは以下のような構成で実現しています。推薦システムの API は Amazon ECS で運用していて、タイムラインの表示の際に Server-to-Server で通信が行われます。推薦モデルの学習に利用するユーザの行動ログやデータベースなどの情報は BigQuery に転送され、それをもとに内製の機械学習基盤である Hekatoncheir(※1) で学習を行ってます。学習は日次で行われ、最新のモデルは AWS CodeDeploy 経由で自動デプロイされます。

※1 Hekatoncheir: Google Cloud Platform の AI Platform など既存のツールを組合せて作成した内製の機械学習基盤。詳細については こちら のURLを参考

推薦システムの課題と現状の効果

ライバーとリスナーのマッチングアルゴリズムの改善

Pococha では精度の高いマッチングを実現するために、継続して推薦システムのアルゴリズムの改善に取り組んでいます。

推薦システムを実現するための主なアプローチとして、コンテンツ情報をもとに類似のコンテンツを推薦する「内容ベースフィルタリング」と、ユーザの視聴履歴などから嗜好の近いユーザの好むコンテンツを推薦する「協調フィルタリング」があります。

Pococha で推薦対象となる配信は、ライバーとリスナーによる雑談が中心的なコンテンツです。例えばここで単純に内容ベースフィルタリングを適用しようとしてもうまくいきません。タイトルなどではコンテンツの類推を行うのが難しいことに加え、リスナーがコンテンツの情報自体を重要と思っておらず、交流やそれによる関係性の構築に価値を置いてることもあります。協調フィルタリングによる推薦を行うには、定着を促したいサービスを始めたてのユーザーに関する十分な情報が取れないことが課題になります。

最初期のモデルでは、リスナーが配信を繰り返し継続視聴した先にファンになっていくと仮定して、初視聴から継続して視聴したライバーとリスナーの組み合わせをもとに学習したモデルを利用しました。A/Bテストを行い推薦を受けたリスナーとそうでないリスナーを比較したところ、継続視聴は必ずしもコアファン(※2）には繋がらないことが分かりました。

視聴時間、日数、消費コイン、コメントなどの単一項目ではコアファンになる指標がなかったため、これらの項目の組み合わせをラベルとして用いることにしました。また、コアファン周りの特徴を取り入れるため、「被推薦対象のリスナーが過去にコアファンを取ったライバー」と「推薦対象のライバー」の類似度を学習に取り入れました。これらの更新により、初視聴後の再訪率に向上が見られました。

直近のモデルでは、新たに「被推薦対象のリスナー」と「推薦対象のライバーの配信でコアファンを取っているリスナー」の類似度も考慮するように変更することで大きく性能が向上し、初視聴後コアファンとなるリスナー数が3割ほど増加しました。

※2 コアファン： 1ヶ月の間でライバーに一定数以上のエール（視聴時間、消費コイン数、コメント数等で加算）を贈ったリスナーが得られる称号のこと

システム負荷の軽減

マッチングロジックの精度を上げるだけでなく、サーバやインフラの設計・開発の能力も求められます。タイムラインは配信を視聴する上で最も目立つ導線なので、安定かつ高速な API を提供することの意義は大きく、効率的なテーブルの設計、適切なオートスケールの設定、サービス監視、CI/CD の実現など様々な観点を考慮する必要があります。

当初の実装はモデルの更新に手動でのデプロイが必要だったため、直近のユーザの行動などを反映したくても更新頻度を高くすることが困難でした。そこでまず AWS CodePipeline を利用して ECR へのイメージプッシュをトリガーとしてデプロイが行われるようにしました。

またモデルのデプロイが行われると ECS にリクエストが集中する実装になっていたため、オートスケールが間に合わずアラートが飛んでしまうことがありました。これを防ぐため ECS のリクエストがデプロイのタイミングに依存しないように修正しました。このスパイクの解消で過剰に用意されていた ECS のタスク数を減らすことができ、最終的に推薦システムのインフラ費用を7割程度削減することができました。

今後の展望

今取り組みたい課題として、推薦システムの開発イテレーションを上げることと新規リスナーの推薦モデルの適用を早めることがあります。推薦システムはモデルの開発と定量的な検証の繰り返しで進めていきます。現状のシステムは複数のモデルを並列稼働させる前提で作られていないため、予算や運用方針も考慮して最適な設計・開発を行う必要があります。

また、モデル更新のタイミングとデータベースの転送がボトルネックになっていて、新規リスナーが推薦システムの恩恵を受けるためにラグが生じます。今は他の施策も併用することで新規リスナーの導線を作っていますが、将来的には視聴に応じて都度適切なライバーが推薦される状態を目指しています。

さいごに

本記事では、Pococha のエンジニアが取り組んでいる課題の中で、Pococha におけるライバーの推薦システムについてご紹介させていただきました。 ロングテールなサービスだからこそ、よりスムーズに自分の居場所を見つける手助けとなる推薦システムは非常に重要となります。

効果的な推薦システムを実現するには、機械学習とサービスの両方の深い理解が求められます。どのように機械学習を進めていくかは基本的に AI 専門チームが主導で決定していき、学習に使うデータの提案や A/B テスト後の結果の議論はエンジニアやビジネスも一緒に行っています。

特定の技術領域のエンジニアだけではなく、AIのスペシャリスト、深いユーザー理解のあるビジネスメンバーなどと一緒に肩を組んで、今後もPocochaが多くのユーザーにとっての心地よい居場所を提供するために探求をしていきます。