正解の無い検索品質評価にオフラインA/Bテストで立ち向かう
この記事は、NAVITIME JAPAN Advent Calendar 2021の 7日目の記事です。
こんにちは、見習いスパルタ人2号です。ナビタイムジャパンで地点検索の品質改善および保守運用を担当しています。
今回は弊社地点検索の品質改善においてリリース前検証として実施しているオフラインA/Bテストについて紹介します。
地点検索ログと検索の改善
弊社の各アプリでは、地点検索後のユーザー行動によって
入力文字列
検索結果
何番目の検索結果を選択したか（あるいは何も選ばれなかったか）
チーム内では選択rankと呼んでいます
を地点検索ログとして収集しています。
例えば検索結果の上から3番目に出てきた地点を選択した場合はrank3、検索したが何も選ばずにアプリを離脱した場合はrank0が記録されます。
選択rankが0
-> ユーザーが期待する地点を返却できず、思ったようにサービスを利用できなかった選択rankが大きな数字
-> 目当ての地点を探すためにユーザーにスクロール等の手間をかけさせてしまった
と判断できるため、この検索ログが改善と評価の起点になります。
我々のチームでは定期的にこの検索ログから上記のようにユーザーに不利益がある事象の原因を調査分類し、改善可能かつ内訳が大きなものから順に対応していくという形の改善を行ってきました。
最近の課題
システム成熟に伴う検証難易度の上昇
改善を積み重ねていく中で全体的に利くような汎用的だけでなく、特定ジャンルを狙った改善も増えてきました。
それに合わせて検索システムとしては結果のランク付けに用いる要素が増え、ジェンガ終盤のごとくバランスを取るのが難しくなるなど複雑化が進んでいきました。
ある修正が狙ったケース以外に対してどの程度影響があるか、変更内容から察するにどのようなデグレの懸念があるのか、といった類推はしばしば困難でした。
有識者の退職
検索エンジン・データ両面に対する幅広い知識で検索品質を守ってきたベテランエンジニアの退職がそこに重なり、課題はさらに顕在化しました。
知識がなければ検証ケースの数で補うほかありませんが、先述のように地点検索は多くの要素で成り立っているため、変更内容によっては広範囲に挙動差分が発生してしまいます。変更内容によっては1万件のテストパターンのうち数千件以上で差分が発生するようなケースもあり、それらを端から端まで毎回全て見ることは現実的ではありません。
有識者でないと変更に対して適切なリリース前品質検証を行うことが困難である、という課題を直視せざるを得ない状況が訪れたのです。
オフラインA/Bテスト
前置きが長くなりましたが、前述のような課題を抱えていた時期に導入されたのがオフラインA/Bテストです。
これは何らかの地点が選択された検索ログを収拾して変更前後のシステムで検索を行い、検索rankの変動をもって品質を評価するというものです。
本番環境に影響を及ぼさずに変更前後の優劣を判定することからオフラインA/Bテストと呼んでいます。
以下に具体イメージを示します。
この例では「ナビタイム」「国会」でユーザーが選択した地点がいずれもより上位で返却されるようになりました。
「渋谷のんだくれ道場」の順位は下がりましたが、入力ワードの性質的に多少の順位変動がやむなしと思われるケースのため、総合的には改善していると判断できます。
実際のケースはより規模が大きく数百～数千件程度差分が出てくるのですが、定量指標があることで以下のようなアプローチが可能になりました。
検索rank変動値でヒストグラムを描き、全体的な差分の傾向を把握する
変動値の値でグループ分けをし、各グループから一定数の差分を確認する
このようなプロセスを踏襲することで、いたずらに端から端まで全ての差分を確認せずとも
「トータルでは検索rankは改善傾向にあり、明確に良くなるケースはXXやYYなどで、最も悪化するケースもZZZというような場合であるためこれは許容範囲です」
といった明確な根拠に基づいた説明が比較的経験が浅いメンバーでも可能になりました。
以下に今年行った住所検索改善対応の具体例を紹介します。
なお対応内容は「（少なくとも弊社の住所DB上に）存在しない住所が入力された場合、なるべく近い住所を返却するようにする」というものでした。
全体的な差分の傾向を把握する
まずは検索rank変動値でヒストグラムを描くことで、差分発生の頻度や全体的な差分の傾向を簡易的に把握することができます。上図の例では差異0付近に山ができているものの改善と悪化の件数は同程度で、この情報だけから全体的な良し悪しは判断できませんでした。
グループごとの差異を確認する
全体を把握した後は差分を
改善幅が大きかったグループ
悪化幅が大きかったグループ
小幅な差分があったグループ
などいくつかのグループに分け、それぞれ具体的なケースを確認します。
「古国府1-2-5」のもともとのトップヒットは「大分県大分市古国府2丁目5-1」だったので、意図通りに改善したと言える内容になっています。他のケースも同様の傾向にあるものが多かったです。
一方、悪化ケースでは「ユーザーが本当に求めていたのはその地点なのか？」という例が散見されました。「妥当な候補が上位に無かったため、多少ずれている候補をやむなく選んだ」という可能性があるためです。
「東淀川区豊新2-12-1」の変更後のトップヒットは「大阪府大阪市東淀川区豊新2丁目12」だったので、入力ワードとの類似度を見ると一概に悪化したとは言えないケースと言えます。
以上のような検証を経て、この例ではリリースする価値のある対応だと判断しました。
まとめ
少しの変更でも多くのリクエストパターンで差分が発生する
絶対的な正解が存在しない
という検索システムに対して「検索rankの変動」という定量指標を軸にした検証プロセスを導入したことで、有識者でなくとも最低限の根拠を持った品質検証が現実的な労力で行えるようになりました。
地点検索以外でも、上記2点のような特徴を持つプロダクトであればなにがしかの定量指標を持ち出すことで同様の品質評価が行える可能性があると考えられます。
正解のない世界であるべき姿に少しでも近づかんと日々奮闘されている読者の方にとって少しでも参考になりましたら幸いです。