はじめに
こんにちは、検索基盤部検索研究ブロックの小倉です。普段はZOZOTOWNの検索精度改善を担当しています。検索研究ブロックでは2020年から検索結果の「あなたにおすすめ順」（以降「おすすめ順」と呼びます）とその改善に取り組んできました。その過程で「これまで積み重ねてきた改善は、トータルでどの程度効果があったのか？」を確かめるために、ネガティブテスト（最新のロジックと古いロジックを比較するA/Bテスト）を導入・運用してきました。しかし実際に運用を重ねる中で、ユーザー体験の悪化やロジック改善の機会損失といった問題も見えてきました。本記事では、ZOZOTOWN検索おすすめ順におけるネガティブテストを「導入して効果を測った段階」から「運用を見直すに至った段階」まで、その経緯と学びをご紹介します。
目次
背景・課題
ZOZOTOWN検索おすすめ順の改善
ZOZOTOWNでは、ユーザーごとにパーソナライズされた「おすすめ順」を検索結果の並び順として提供しています。私たちは、2020年からこの「おすすめ順」の改善プロジェクトを継続的に進めてきました。当初はヒューリスティックな手法が使われていましたが、ランキング学習で構築した機械学習（Machine Learning: ML）モデルを導入し、導入後も反復的にロジックを改善してきました。これらの改善を実施する際は、基本的には常にオンラインA/Bテストを行い、その効果を測った上でリリースの可否を判断しています。
「1年間の積み上げ改善」をどう測るかという課題
短期間で行うA/Bテストでは、売上金額などの指標はKPI（Key Performance Indicator）としては感度が低く、有意な差を検出しづらいという問題があります。そこでおすすめ順改善では、コンバージョン率（Conversion Rate: CVR）やクリック率（Click Through Rate: CTR）などのより感度が高い指標をKPIとしています。売上金額はKGI（Key Goal Indicator）であり、KPIはKGIの代理指標である、という位置付けです。感度の高い指標をKPIとすることで、小さな改善でも積極的にリリースしやすくなります。
プロジェクトを進める上では、ユーザー体験を良くすることだけでなく、中長期的にはKGIの向上に寄与することも求められます。1回1回のA/Bテストで「前より良くなった」ことは確認できる一方で、「この1年間の改善の積み重ねは、KGIの向上に寄与しているのか？」を定量的に把握できないことが課題になってきました。
そこで私たちは、「これまで積み重ねてきた改善の効果を、より直接的に測る方法はないか？」という問いに対して、さまざまなアプローチを検討することになりました。
候補に挙がった評価方法とその検討
1年間の改善を測る方法としては、主に次のような案が検討されました。
- 1.個々のA/Bテスト結果の積み上げ試算
- 1回1回のA/Bテストで得られたupliftを積み上げ、1年間のupliftを推定する方法
- シンプルで説明しやすい一方で、以下の懸念点がある
- 改善施策同士の相互作用（重複効果や打ち消し合い）の扱いが不適切
- 統計的有意差が出ていない結果を積み上げてしまうのは不適切
- 2.長期ホールドアウト
- 一部ユーザーに対して長期間古いロジックの結果を表示し、最新のロジックと比較するA/Bテスト
- 積み上げた効果を直接比較できたり長期的な影響を観察できたりする一方で、以下の問題点がある
- 一部ユーザーに与えるマイナス影響
- 古いロジックを維持し続ける運用保守コスト
- 対象ユーザー数が少ないことによる検出力の低さ
- 3.ネガティブテスト（vs. 古いロジック）
- 通常のA/Bテストと同じ期間で、最新のロジックと古いロジック（1年前のロジック）を比較するA/Bテスト
- 通常のA/Bテストと同じ枠組みで実施できるため、既存のシステム・運用フローを流用しやすく、検出力も同程度を期待できる
- 「古いロジックに戻すことで、ユーザーの体験を意図的に悪化させる」という明確なデメリットがある
- 1年間で有効な改善を積み重ねているほど、悪化も大きくなる
- 4.ネガティブテスト（vs. 簡単なロジック）
- ランダム順など、ごく単純なロジックとの比較をするA/Bテスト
- 比較対象をベースラインとしてupliftを計測できるが、3の手法よりもさらにユーザー体験が悪化する
おすすめ順プロジェクトではまず2の長期ホールドアウトを採用していましたが、KPIの有意な差を検出できませんでした。その後実施した3のネガティブテストではKPIの有意な差を感度高く検出できたため、以降はネガティブテストを採用しました。
なお、これらの評価方法を検討する上で私たちは『A/Bテスト実践ガイド 真のデータドリブンへ至る信用できる実験とは』という書籍を参考にしました。2の手法「長期ホールドアウト」は第15章で触れられています。3と4の手法については、第23章で「リバース実験」として紹介されている手法をベースに考案したもので、社内用語で「ネガティブテスト」と呼んでいます。こちらは一般的な名称ではなく、別の意味を持つ既存の専門用語と被っているため誤解を招く恐れがありますが、本記事では引き続き「ネガティブテスト」と表記します。
また、検索おすすめ順の改善とネガティブテストの思想については、以下のTech Blog記事でも触れています。
ネガティブテストの設計と実施
ネガティブテスト設計時に意識したポイント
ネガティブテストは、意図的に最新のロジックから古いロジックに切り替えるため、treatment群のユーザーにとっては体験が悪化します。十分なデータが取れるように短すぎず、かつユーザー体験への悪影響を抑えられるように長すぎない、適切なタイミングで切り戻しを行いたいと考え、設計段階で特に次の3点を重視しました。
- 指標
- 「この指標が有意差ありで悪化したら即時切り戻す」というガードレール指標を明確化し、ネガティブな影響が広がる前にテストを止められるようにした
- ガードレール指標の設計は、ネガティブテスト導入時の議論を通じて整備され、通常のA/Bテストにおける判断基準にもつながっている
- テスト期間
- 基本的には通常のA/Bテストと同じ期間設定で実施
- 曜日の影響を考慮して1週間分のデータが欲しいものの、ユーザー影響の大きさを鑑みて最低限のテスト期間は2〜3日に設定した
- 切り戻し判断とエスカレーションフロー
- ガードレール指標が一定の閾値を割った場合に「誰が」切り戻しを判断するのかを合意してから実施
- ネガティブテストはその性質上切り戻しになる可能性が十分にあるため、事前にプロダクトオーナーの了承を得た上で実施
実施したネガティブテスト
ZOZOTOWN検索おすすめ順におけるネガティブテストは、過去3回実施しました。
- 第1回
- 「MLモデル vs ヒューリスティックモデル」という構図で、初めての本格的なネガティブテストを実施
- 事前に複数回のMTGを行い、ガードレール指標や切り戻し基準を整備した上でスタートした
- 第2回
- 前年の運用を踏襲しつつ、「最新のMLモデル vs 1年前のMLモデル」という形でネガティブテストを実施
- モデル自体を公平に比較するため、「1年前のMLモデル」も「最新のMLモデル」と同じ期間のログデータから学習した
- 第3回
- 第2回と同じ形式でネガティブテストを実施
- 後述する懸念を受け、「ネガティブテスト自体をどう位置づけるか？」を再定義するための議論・検討を集中的に行った
結果から得られたこと
第1回ネガティブテストでは、ヒューリスティックモデルに対してMLモデルが優位であることを明確に確認できました。プロダクトオーナーには、次のようなメッセージを分かりやすく伝えることができました。
- 「この1年間で、検索おすすめ順は確かに良くなっている」
- 「MLベースのアプローチに継続的に投資する価値がある」
一方で、第2回と第3回ネガティブテストはMLモデル同士の比較となりましたが、それぞれ次のような結果となりました。
- 第2回では、最新のMLモデルが優位ではあるものの、切り戻すほどの大きな差が出ないまま規定のテスト期間が経過
- 第3回では、早い段階で大きな差をつけて最新のMLモデルが圧勝し、切り戻し
これらの結果から、個々のA/Bテストを重ねることでおすすめ順は着実に改善できていると言えます。
運用を重ねて見えてきた課題
ユーザー体験やビジネスへのマイナス影響
あらかじめ想定・許容していたことではありますが、ネガティブテストでは次のような影響があります。
- あえて精度の低いモデルを出すことで、ユーザーが欲しい商品に辿り着きにくくなる
- その結果、短期的にKGIやKPIが低下する
- ユーザーに「ZOZOTOWN検索は使いにくい」という印象を持たれてしまうリスクがある
第2回ネガティブテストでは、「マイナス影響を覚悟してテストを実施したものの、最終的に十分な差が得られなかった」という状況も経験しました。このとき、「ユーザーに負担をかけてまで得られる知見として、割に合っていたのか？」という問いが、プロジェクト内で意識されるようになりました。
古いロジックの再現にかかる工数
ネガティブテストで古いロジックを再現するには、単に古いモデルファイルをデプロイするだけでは済みません。
- 過去1年の間に実施されたシステム変更（特徴量の追加・削除、前処理の仕様変更、インフラ構成の変更など）を洗い出す
- それらを元に戻すか、互換性のある形で再現する
- テスト終了後には再度最新の状態へ戻す
これらには相応の工数がかかりますし、1年前当時の状態を完全には再現できない場合もあります。
加えて、MLモデル同士の比較に特有の問題もあります。学習データとなるログの取得期間を比較対象のモデル同士で揃える場合、そのログは「最新の精度が良いモデルによって並び替えられた検索結果」に依存しています。これにより古いモデルがログを通じて「賢く」なってしまい、モデルの性能差が現れにくくなります。
改善活動が止まることによる機会損失
ネガティブテストの期間中は、他の改善施策のリリースを止めざるを得ません。本来であれば実施できたかもしれない改善施策を、一時的に棚上げすることになります。また、ネガティブテスト自体の準備・分析にも工数がかかるため、他の改善施策が後回しになります。
この「改善活動が止まることによる機会損失」は、テストを重ねるほど無視できないコストとして認識されるようになりました。
早期切り戻しとなった場合の改善幅の計測精度の低さ
ネガティブテストでは、ユーザーへのマイナス影響を抑えるため、途中で切り戻しになる可能性があります。この場合、「1年間の改善幅」をどこまで精度高く推定できるかには、次のような制約が生じます。
- 規定のテスト期間を完走した場合と比べてサンプルサイズが小さくなり、推定値の信頼区間が広がる
- 切り戻しのタイミングや理由によっては、特定の曜日・キャンペーン期間などに偏ったデータしか取得できない
- その結果、「着実に良くなっている」という傾向は確認できても、「年間で◯％改善した」と言い切れるほどの精度では評価しづらい
このように、早期切り戻しは「ユーザー体験やビジネスへのマイナス影響」を抑える一方で、「1年間の改善幅の計測精度」が低くなるというトレードオフの関係があります。
ネガティブテストの再定義と今後の運用方針
毎年の定期イベントから外す判断
当初、ネガティブテストは「1年間の改善を測るための定期イベント」として位置づけていました。しかし、複数回の運用を経て、次のようなデメリットが当初の想定よりも大きいことが分かってきました。
- ユーザー体験やビジネスへのマイナス影響
- 古いロジックの再現にかかる工数
- 改善活動停止による機会損失
- 切り戻しとなった時の改善幅の計測精度の低さ
こうした懸念は、プロダクトオーナーからも明確に共有されるようになりました。「ネガティブテストは、毎年なんとなくやるものではない」「目的に対して割に合わないタイミング・やり方もある」という認識のもと、定期的に実施する運用からは外すという判断に至りました。
KPI妥当性検証のためのスポットテストとしての再定義
ただし、ネガティブテストを完全にやめてしまうわけではなく、その役割と使いどころを絞るという方針に切り替えました。具体的には、ネガティブテストをKGIの代理指標としての、KPIの妥当性を検証するためのスポットテストとして位置づけ直しています。例えば、A/BテストにおけるKPIの定義を変更した後、「そのKPIに沿って改善を積み重ねることで本当にKGIは向上するのか？」を確かめる場合などに実施します。
これにより、ネガティブテストの実施回数を絞りつつ、実施する際には「なぜ今やるのか」「どんな問いに答えるのか」を明確にする、という運用にしました。
プロジェクト成果はA/Bテスト積み上げで見る方針へ
これまでの経緯から、現在のおすすめ順プロジェクトでは成果を以下の方針で測ることとしています。
- 有意に改善したA/Bテスト結果の積み上げ
- 統計的有意差ありで改善したA/Bテストの件数やupliftを一覧化し、「この1年間で、どのような施策でどれだけ改善したか」を整理
- 開発チーム内の目標として、「有意差ありの改善をN件出す」といったA/Bテスト起点の指標を置く
- 前述の懸念に対する対処
- 施策同士の相互作用は正確には分からないものと割り切る
- 有意差なしでもシステム面でのメリットが大きい場合はリリースするが、その結果は改善の積み上げには含めない
ネガティブテスト自体は依然有効な選択肢です。ただしそれは「とりあえず毎年やるもの」ではなく、KPIを再設計したい時や既存の評価軸に大きな不安がある時など、限られた局面で慎重に実施するべきテストです。これが、数年にわたってネガティブテストを導入・運用してきた結果として得られた結論です。
まとめ
本記事ではZOZOTOWN検索おすすめ順改善におけるネガティブテストの運用をご紹介しました。ネガティブテストの導入によって複数回のA/Bテストによる改善の積み上げがトータルでどの程度の効果をもたらしているかを測ることができました。また、ネガティブテストの運用を見直したことでユーザー体験の悪化を最小限に抑え、開発リソースを前向きな改善施策へ回せるようになりました。本記事が、ネガティブテストの導入を検討している方や、既にネガティブテストを実施していて課題を感じている方の参考になれば幸いです。
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。
