Search&Discoveryシステムの評価入門

こんにちはrilmayerです。
この記事はアドベントカレンダー「Search&Discovery 全部俺」8日目の記事となります。

今日はSearch&Discoveryシステムの評価について、その全体像を説明してみようと思います。まずはじめに、ここで言う「評価とは何か」と言う話をした後に、システム全体の評価方法についてその全体像を示します。
そして最後に、実際の評価を進めるに当たって理想的な手順の例を説明しようと思います。

”良い”Search&Discoveryシステムとは？

まず、Search&Discoveryシステムを導入する理由について考えてみましょう。
なぜこうしたシステムを導入するかと言うと、「システム上に大量にアイテムがあるのに、ユーザーがそれらのアイテムと”良い”出会いができていない」などといった課題が存在するからです。

ここで「良い」という状態がきちんと定義できていないと、システムの理想的な挙動を考えることが困難となります。どういうシステムであれば良いかと言うのはビジネス的な観点を多く含む非常に難しい問いであり、システムを提供する立場によって様々な定義が存在します。
（⇔古典的な情報検索ではユーザーに対して適合するアイテムを提供できるシステムがが良いとされてきていたので、この辺りは情報検索とSearch&Discoveryで少し異なるかもしれません。）

例えば良いシステムはその種類によって、「もっと商品が売れる（ECサイト）」や「検索結果に利用者が満足する（図書検索システム）」、「ユーザーが見つけたイラストに”いいね”がなされる（イラスト投稿サイト）」など様々な定義ができます。

重要なのはこうした「良い」と言う状態をきちんと測れるようにしておくと言うことです。
例えば、新たにSearch&Discoveryのシステムを導入したら「売り上げが120%以上改善する」、「システム利用後にアンケートで50%以上のユーザーから☆5をもらえる」、「システム経由で推薦されたイラストのうち10%以上ののイラストに"いいね"がつく」といった具合に良くなったとは具体的にどういうことなのかを事前に考えておくことが必要となります。

これには主に3つの理由があります。
1つは「良い状態に近づけるために開発者が最適な手法を選択できるようにすること」、2つめは「（チームで開発する場合は特に）目指すべき方向性の認識を合わせて力をフォーカスするため」、そして3つめが「システムを導入した後にそのシステムがうまく機能したか（＝当初の課題は解決できたか）を確認するため」です。
そして、今回の記事は3つ目の観点である評価について説明していきたいと思います。

システムの改善で評価は必須

評価をしなければ良いシステムであるかどうかが分からないために、評価を考えることは非常に重要だということを確認してきました。これについて、もう少し詳しく説明します。

Search&Discoveryではそもそもユーザーが良いと思うアイテムを提供するわけですが、この「良い」という状態を達成しなくてはそもそもSearch&Discoveryシステム足り得ないのです。

そのため、システムを開発したり、改善したりする場合は評価についてもセットで考える必要があります。

Search&Discoveryシステムの評価全体像

Search&Discoveryシステムの評価全体像を以下に示します。

ここでは評価の全体工程を「評価設計」→「オフライン評価」→「オンライン評価」→「分析」と分けています。

評価設計ではここまでみてきたようなシステム導入によって何を目指すのかや、どうなると改善されるのかを元に、どのように評価すればそれを検証できるかと行った計画を行います。
通常こうした評価設計は実験計画などとも呼ばれ、実際のサービスでテストを行うオンラインテストについて統計的に必要なユーザーな数などを算出したり、必要な期間などを設定したりします。

オフライン評価では主にシステムとして本番ユーザーの目に触れる前にテストデータ等を用いてシステムがどの程度有効かを検証します。
このフェーズではその評価の性質を定性と定量に分けることができます。
定性については実際にアイテムがどのように提供されるのかを人が目で確認するようなものに加え、UX等を確認するためにユーザーテストと呼ばれるユーザーがシステムを操作する様子を観測することもあります。

オンライン評価については本番ユーザーが実際に使ってどのような効果があったかを確認することができます。こちらも定性のものと定量のものに分けることができます。
通常のオンラインテストではA/Bテストなどと呼ばれる手法を用います。定量観点ではあらかじめ決めておいた重要指標等について、実際のサービス上でうまくそれらに働きかけることができたかを計測します。

分析についてはオンライン評価を行った後に本当に欲しい効果が得られたのかなどについて時には統計手法を用いながら結論を出す過程です。

これらの観点とは別に以下に見るような軸も存在します。

アルゴリズムとシステム（リサーチとエンジニアリング）

きちんとアルゴリズムとシステムの両観点から評価を行うことが重要です。
例えば以下のような事例を考えてみましょう。

実験でユーザーに対して非常に良いアイテムを返すことができるが、実際のシステムでは（今までは0.2秒以内でアイテムを返せていたのに）平均で1秒以上アイテムの返却に時間を要する

非常にシンプルでエラーが起こりにくいシステムではあるが、ユーザーにとって全く良くない（むしろ悪い）アイテムが提供されている

両者の例もアルゴリズムとシステムのバランスがよくない場合です。
どんなに素晴らしいアイディアであってもシステムでうまく動かなければ意味がなく、どんなに優れたシステム構成であっても実際に良いユーザー体験を作れなければ意味がありません。
ちなみに、システム観点では「どのくらい安定して作動するか」や「どのくらいの遅延が生じるか」や「どのくらい運用しやすいか」などを見ていきます。

実際にユーザーに対し価値を提供するために、アルゴリズムとシステム両者の観点から適切に評価がなされて運用されることが重要であると私は考えます。

オフラインとオンライン（オフラインテストはそこそこに）

オンラインテストでは通常事前に決めた重要指標（例えばCTRなどの指標）が新たな機能によって改善されているかを確認します。

オフラインテストは実際のサービスに影響が出ることがないのに対して、オンラインテストでは実際のサービスに影響が出ます。
そのため、オフラインテストで入念に実験をして結果が十分に良くなることを確認してからオンラインテストに以降するといったケースがあります。

ところが。オンラインテストの結果については、オフラインテストの結果がよければ必ず良くなるとは限りません。むしろ全く逆の結果になってしまう場合も往往にしてあります。
そのため、ある程度オフラインテストで結果が良いことを確認した後は、できるだけ早急にオンラインテストで試すことも重要です。

実際のサービスの評価の進め方

ここまで見てきた評価方法について実際のサービスで評価を行う場合にどのような進め方になるのかを、動画投稿サービスを例に検索結果を改善するというケースで見てみましょう。以下のケースは丁寧にやる場合となります。

1. 評価設計
1-1. 仮説
現状「キーワード検索で関連した動画が検索結果一覧に表示されていないため、検索結果一覧画面でのユーザーの動画クリック率(CTR)が悪い（という仮説）」を持っているため、とある機能を追加すると「検索結果が改善されてCTRがN%向上するだろう」という想定を立てる

1-2. 実験計画
上記の機能改善の評価を行うために、現状機能と新機能で比較するA/Bテストどの程度の差が出たら、統計的に有効と言えるのかユーザー数や実験期間を算出し、その間に他の影響が出ないように調整する

2. オフライン評価
2-1. 定性評価
新機能のシステムがだいたい完成したのでその機能によって検索結果がどのように変わるかを確認し、現状の機能よりも改善していることを確認する

2-2. 定量評価
事前に作成しておいたテストデータを元に、今回の新機能について各種評価指標を用いて実際に改善しているかを確認する
クラウドソーシングや社内メンバーによる検索結果の評価を行っても良い

2-3. システム評価
システムに対して負荷をかけたり複雑なキーワード等を投げたりして、問題なく作動するかを確認する
現状の機能と比べ各種システム性能評価指標に差分がないことを確認する

3. オンライン評価
3-1. リリース直後チェック
実際に表示されるアイテムが想定通りか、システムの挙動がおかしくなっていないか等、問題ないことを確認

3-2. A/Bテスト
実験計画にて設定したユーザー群を用意して指定期間の実験を行う

4. 分析
4-1. 仮説の検証
実験計画で事前に設定した重要指標についてそこに統計的に意味のある差があるか（良くなったか悪くなったか）を確認することによって、実験の成否を結論付ける

4-2. 詳細分析
その他の指標の変化を元に新機能によって現状機能からどのような変化がユーザーに起きたかを分析してまとめる
今後の施策をより良くするためにそれらをまとめて共有

少し長くなってしまいましたが、以上が一般的な評価の流れです。
とはいえ、やや冗長な部分や少し足りない部分等はあるので、もし上記を参考にしていただける場合は、自身の関わるSearch&Discoveryシステムに応じて削ったり追加したりしていただけると良いのかもしれません。

おわりに

今日はSearch&Discoveryシステムをどのように評価するか、そもそもなぜ評価が大事なのかというお話をしました。
次回はより詳細な評価方法について解説できればと思います。