【イベントレポート】タイミーのレコメンドにおける ABテストの運用

イベント概要

2024年9月18日に「GENBA #4 〜データサイエンティストの現場〜」と題してタイミー、ビットキー、AbemaTVの3社でデータサイエンスに関する合同勉強会を開催しました。今回はそちらの勉強会からタイミーのデータサイエンティストである小関さん（@ozeshun_）の発表をイベントレポート形式でお伝えします。

自己紹介

まず、自己紹介をさせていただきます。私は2022年にタイミーにデータサイエンティストとして入社し、現在は機械学習モデルの改善、機械学習パイプラインの構築、そして推薦API基盤の運用を担当しています。最近では、検索機能にも携わっており、Elasticsearchのキャッチアップしながら頑張っています。趣味は野球で、ロッテやレンジャースの試合を観るのが好きです。

本日は、以下のような内容でお話ししようと思います。まず最初に、タイミーのサービス紹介を簡単に行います。その後、私が担当しているレコメンド機能について、A/Bテストをどのように運用しているのか、具体的なアーキテクチャやプロセスを説明します。また、A/Bテストを実施する際の指標のモニタリング方法についても触れ、その結果をどのように管理しているのかを順を追ってご紹介していきます。

サービス紹介

前提となる部分なんですが、タイミーはなんぞやというと働きたい時間と働いてほしい時間をマッチングする「スキマバイト」サービスです。アプリを開くと仕事のリストが表示され、ワーカーは気軽に仕事を申し込むことができます。一方、クライアント側も求人情報を簡単に掲載でき、効率的に働き手を見つけることが可能です。

レコメンド機能におけるABテスト

レコメンド機能におけるA/Bテストについて説明しますが、まずはタイミーのアプリ上でこのレコメンド機能がどのように実装されているのか、そしてどこを注視すべきかをお話しします。

タイミーのレコメンド機能は、アプリを開いた際に、トップ画面の「探す」タブや「お気に入り」タブに表示される「あなたのおすすめの仕事」バナーをタップすると、パーソナライズされた仕事のリストが表示される仕組みです。たとえば、探すタブの真ん中あたりにあるバナーや、お気に入りタブの上部に表示されるバナーをタップすると、あなたにおすすめの仕事が一覧として表示されます。このように、ユーザーごとにパーソナライズされた結果として仕事が表示される形で実装されています。

ユーザーが「あなたのおすすめのお仕事」画面でお気に入り登録を行うと、推薦がうまく機能していると判断でき、その後の申し込みに繋がれば、さらに効果的だったと見なせます。このように、推薦機能がどの程度成功しているかを確認するために、まずはお気に入り登録、その次に申し込みの動向を追っています。

レコメンド機能におけるA/Bテストについては、非常にシンプルな方法を取っています。基本的に、既存のアルゴリズムと新しいアルゴリズムを対決させる形でテストを行っています。導入初期では、レコメンド機能を表示するグループと非表示のグループで比較した結果、表示グループのKPIが圧倒的に良かったため、レコメンド機能の導入を決定しました。

現在では、既存アルゴリズムと新規アルゴリズムを日々比較し、どちらがより効果的かを評価しながら運用しています。

タイミーのレコメンド機能では、オフラインでの検証からオンラインにデプロイするまでのプロセスが非常に迅速である点が特徴です。このスピード感のある運用についても、具体的にどのように実施しているのか、説明していきたいと思います。

最後に、A/Bテストで計測している指標についてお話しします。先ほども少し触れましたが、まず重要なのは「お気に入り数」です。レコメンド機能を通じてお気に入りに登録される数が増えると、アルゴリズムが正しく機能していると判断できます。これが先行指標として、アルゴリズムの改善を測る基準になります。

次に遅行指標として、申し込み数も重要です。レコメンド画面から直接申し込む場合もありますし、レコメンド経由でお気に入りに追加した後に通知を受け取って申し込むパターンもあります。このように、申し込み数が遅れて増えることを確認できると、さらに効果的な結果となります。

また、全体の指標も見ていく必要があります。お気に入り数については、レコメンド経由のお気に入り数とそれ以外のお気に入り数の合計で構成されています。ただし、レコメンド経由のお気に入り数が増えたとしても、それ以外の部分が変わらないというわけではなく、時には減少することもあります。特に申し込みに関しては、ワーカーの時間が限られており、タイミーのアプリでは1日に1回しか働けないため、レコメンド経由での申し込みが増えると、それ以外の申し込みが減少するというトレードオフが発生することがあります。こうした点を注意深くモニタリングしています。

なお、他にもマッチングスピードなども指標として確認していたりなど、さまざまな指標を計測しながら運用を続けています。

ABテストの設定方法

A/Bテストの設定方法についてですが、タイミーでは非常に高速にデプロイできる仕組みが整っていますので、そのアーキテクチャについて説明します。

レコメンドシステムのアーキテクチャを簡単にご紹介します。左側がアプリ本体の基盤がある場所で、これはAWS上に構築されています。一方で、私が所属しているデータエンジニアリング部が主に操作するデータ基盤は、Google Cloud側にあります。

つまり、アプリの基盤はAWS、データの基盤はGoogle Cloudといった形で役割分担がされています。私たちが管理する部分は基本的にGoogle Cloud側が多いため、特に高速なデプロイが必要なときには、Google Cloud上にサービスがあると非常に効率的です。この点を念頭に置いた設計を採用しています。

次に、AWS上にあるRails APIがタイミー本体のAPIとなります。これに対して、右側のCloud Run上に構築したアイテム推薦APIがリクエストを受け取り、「推薦アイテムを返して」とリクエストが来ると、ロードバランサーを経由してその結果を返すといった構成になっています。

A/Bテストの振り分けについては、先ほども述べた通り、Google Cloud側で管理しています。Google Cloud上のアイテム推薦API内でA/Bテストの振り分けがすぐに設定できるような設計になっており、柔軟で迅速に対応可能なシステムとなっています。

実際にどのようにA/Bテストを設定しているかというと、とてもシンプルで、すべてYAMLファイルで管理しています。

具体的には、YAMLファイルの中にA/Bテストの設定を書き込んでいます。たとえば、アルゴリズムAとBを5対5で割り振るようなA/Bテストを設定する場合、durationをstart_atとend_atで指定し、A/Bテストに使用するキー名も設定します。その下には、variantsとしてアルゴリズム名を指定し、アルゴリズムAに対してウェイトを0.5、アルゴリズムBにも同様に0.5を割り振ります。また、表示するグループ（display）と非表示グループ（hidden）に対する割り振りもここで指定します。たとえば、表示群と非表示群に5対5で割り振るように設定することができます。

このYAMLファイルを記述するだけで、あとは推薦結果を正しく出力できるMLパイプラインが整備されていれば、すぐにA/Bテストが開始できる状態になります。

ABテストで計測する指標のモニタリング

A/Bテストで計測する指標のモニタリングについてですが、弊社ではGoogle Cloud上のデータ基盤を活用し、Looker Studioを使ってさまざまな指標を可視化しています。具体的には、毎日モニタリングが必要な指標をグラフとして可視化し、日々確認しています。たとえば、テスト群とコントロール群で「お気に入りクリック数」を比較する場合、グラフ上で緑の線（テスト群）が上にくると良い結果と判断できます。

こういった重要なグラフは、Slackで毎日通知されるように設定しており、A/Bテストの結果をリアルタイムで確認できる体制を整えています。また、週に2回ほど、可視化された指標をもとに同期的にレビューを行い、モデルが意図通りに機能しているか、次にどのようなアクションを取るべきかなどを議論しています。

DWH（データウェアハウス）やデータマートのモニタリングについても、かなりしっかりと構築しています。まず、データレイク層にはアプリの生ログやレコメンドAPI側のログが保存されています。これらのログを直接スキャンすると、スキャン量が非常に大きくなってしまいます。皆さんもご存じの通り、これを毎回BIツールで呼び出すのは非常にコストがかかるため、データマートとデータウェアハウスを効率的に設計しています。

私が所属するデータサイエンスグループでは、これらのシステムのバッチ実行部分もしっかりと構築しています。毎日、ビジネスKPIやランキングメトリクスといった指標を集計し、それをデータマートに格納することで、BIツールで簡単に参照できるような仕組みを作っています。

現在、バッチツールとしてはCloud Composerを使用していますが、今後はdbtへの移行も検討しています。このように、効率的なデータ処理とモニタリング環境を日々改善しています。

ABテストの仮説と分析結果の管理方法

A/Bテストの仮説と分析結果の管理について説明します。私たちのチームでは、A/Bテストの仮説と結果をすべてNotionのデータベースで一元管理しています。アナリストチームがプロダクト全体で利用できるデータベースを構築しており、それを活用しています。

ドキュメントにはまず簡単にテスト内容をまとめ、その後「確かめたいこと」を記載します。これにより、テスト後に検証すべき内容が明確になり、スムーズに分析を進められます。次に「仕様」も詳細に記載し、他のメンバーが振り返りやすいようにしています。

A/Bテストの設計では、比較手法としてA/Bテストを行うか、因果推論的手法を使うかを事前に決めます。サンプルサイズも事前にシミュレーションし、実験期間を見積もりますが、期間が長すぎる場合はA/Bテストをやめて全ユーザーに公開し、因果推論的手法を使うこともあります。

メトリクスでは「お気に入り数」など重要な指標を設定し、ガードレールメトリクスも活用します。また、テストの条件とアクションを事前に設定することで、実験の目的を明確にしています。

テスト終了時にはドキュメントに結果と考察を書き込み、次の疑問や検証すべき内容を整理して次のステップに繋げるようにしています。

最後に、仮説の立て方についての具体例をお伝えしておきます。私たちは、確認したいポイントに対して「こう考えているので、この特徴量を加える」といった形で仮説を立てています。そして、その仮説に基づいて、意図通りに動いているかを分析します。また、仕様の部分には、これまでのアルゴリズムが抱えていた課題や、新しいアルゴリズムで行った変更を記載しておき、仮説に対応させることで、後からの検証がスムーズに進むようにしています。これらは、仮説検証を効率よく行うための例として紹介させていただきました。