リクルートテクノロジーズの大杉です。

私はAPソリューショングループ（ASG）という組織で、検索基盤QASS¹アルゴリズムの最適化に取り組んでいます。もっと具体的には、検索キーワードや条件が指定された時の、検索結果のソート順を決定するアルゴリズムを開発しています。

この検索順アルゴリズムの良し悪しは、ABテストでKPIが有意に向上するか否かによって決まります。現実のデータに勝る根拠は存在しないです（断言）。

検索アルゴリズムの改善のためには、パラメータ値を更新した場合の性能評価（最終的にはABテスト）が必要です。

一方で、検索順アルゴリズムに関わるパラメータ数は、１つや２つではとても済まず、かなり大量にあります。

そのため、ABテストを短期間にどれだけ大量にできるかが、改善のスピードに直結します。

しかし、ABテストは、検索アルゴリズム改善だけでなく、例えばUIデザイン改善にも必要です。

そこで、どのサイト訪問者にどのABテストを行うのかを両者が衝突しないように、仲良くわけたイメージ図がこちらです。

この方法では大きく２つの問題があります。

1. 検索とUIの施策に交互作用があった場合、それが測定できない（お互いの施策が効果を打ち消しあっていたらどうするのか？）
2. ABテスト枠の量をめぐって、検索チームとUIチームが対立するおそれがある（ABテスト枠を細分化していくと１枠内の訪問者数が減り、結果が不安定になります²。）

この"衝突しないように仲良くわけたはずなのに・・・"問題は、図２のような形で、ABテストの住み分けすることで解決できます。

Googleもこのような方法でABテストをしているようです³。

この方法では、検索が利用するABテスト枠とUIが利用するABテスト枠の間でAとB (あるいはC, D, E, ・・・)のわかれ方を統計的に独立にしています。要は別の乱数値を使って分け方を決定しています。

独立にしていることで、検索のA条件とB条件の中で、UIのA条件とB条件がほぼ同数混ざることになり、検索の立場から見た場合にUIのABテストを完全に無視しても、だいたいうまくいきます。交互作用が無視できないほど大きい場合も、この方法なら交互作用の影響を直接測定可能なので、その影響を定量化すれば良いだけです。

この方法のメリット・デメリットを列挙すると以下のようになります⁴。

• メリット
  1. 短い時間でABテストを大量にできる
  2. 交互作用の影響を測定できる
• デメリット
  1. 交互作用が大きくマイナスに働き、施策の良さを打ち消すことがある
  2. 分析が比較的難しくなる
  3. 複数のテストを一斉に始める場合、準備が大変

デメリットの内、1は計画段階で、交互作用が大きくマイナスに働きそうなものを排除する、2と3は交互作用の影響をあまり考えなくても良さそうな、検索とUIの間のような関係だったら交互作用の影響を無視する、といった方法で軽減できます。

そもそもの話、交互作用の影響を気にするのだったら、交互作用の影響を測定できる、こちらの方法の方が都合良いです。

この考え方をおしすすめていくと、ひとつの画面の中でもABテストを複数同時に行うことを認めるmulti-variable testing⁵といった、さらに一般的な方法に到達します。

すでにリーン開発のような高速開発体制が整っているところなら、じゃんじゃんABテストをしていき、改善をどんどんしていくメリットの方が大きいかと思います⁶。

こうして発想を変えることでABテストをたくさんでき、検索アルゴリズムの精度改善ができるようになりました。

やったね！

ということで、検索アルゴリズムの改善にはABテストのやり方を変えていくことも大切だ、という話でした。

当たり前のようにmulti-variable testingを運用している方にとっては自明の話だったかもしれませんが、ここまでおつきあいいただきありがとうございました。

検索アルゴリズム改善そのものについては、またの機会に書きます。

では、また。