「明日から検索機能の担当やってね」と言われたときに知っておくと良さそうなことをいくつか。
※この記事はCrowdWorks Advent Calendar 2018の９日目の記事です
まえおき
検索っていう機能はみんな気軽に＆無意識に使っているけど、いざ検索機能を提供する側になってみると「え、何から始めたらいいの…？」ってなりがちです。
会社で何度か”検索勉強会”ってのを開催して、そういう疑問の解消に努めているのですが、よくある期待（誤解）として「検索エンジンは、ユーザの探してる情報をいい感じに出してくれるもの」のようなふわっとした理解があるのではないかと思っています。
検索エンジンの役割を正確に理解することで、検索の施策は一気にやりやすくなります。
ということで、この記事では、社内向けにやっていた”検索勉強会”の内容をなんとなく放出してみようかなと思います。
検索とは何か？
まず、検索とは何かをさらっと説明します。
ざっくりまとめたのが上の図です。端的にいうと、検索とは、ユーザの検索意図に合う情報をひっぱりだしてあげることです。
ユーザは
- 検索意図をクエリとして表現し
- 検索エンジンにクエリを入力して
- 検索結果を取得する
というプロセスを経るものが検索です。
よく混同される、検索ではないもの
- 検索履歴や閲覧履歴などの表示
- レコメンデーション
など。これらは明確な検索意図をもたない情報表示なので、厳密には検索ではありません。
負の検索結果にも着目しよう
検索エンジンの出力は、
正の検索結果・・・クエリに合致するものを返す
負の検索結果・・・クエリに合致しないと判断したものを返さない
の２つがあります。
「合致するものを返す」と「合致しないものを返さない」って同じ意味じゃないの？？と思うかもしれませんが、とりあえずは別物ととらえておいてください。検索エンジンを評価をする際に用いる”再現率”という指標で、この「合致しないものを返さない」という観点が重要になってきます。
検索エンジンに過度な期待をすることなかれ
「検索機能」と「検索エンジン」の役割をしっかり区別しておきましょう。
検索機能・・・検索意図のクエリ化 ＋ 検索エンジンによる情報抽出・スコアリング。システム全体を指す。
検索エンジン・・・与えられたクエリに対して合致する情報をスコアリングして返すだけ。
最近よく使われている ElasticSearch などは検索エンジンであって、（かなり高機能ではありますが）万能な検索機能を提供するものではありません。後の方でも説明しますが、検索エンジンはユーザの検索意図を正確なクエリに反映できて初めて真価を発揮するものなのです。
「いい検索機能」とはなにか
検索機能をつくったときには、必ずその評価をしなければなりません。
ここでは「いい検索機能」を定義しておきたいと思います。
これをちゃんと定義しておかないと
「イイ感じに空気を読んで（閲覧履歴とかを考慮して）動いてくれる」のがいい検索？確かにそうです。
「ユーザ評価をしてA/Bテストで良かったほう」が良い検索？本当にそうでしょうか？
うーーん、、みたいなことになって、ちゃんとした評価ができません。
検索機能の評価は「適合率」と「再現率」でおこなう
一般的に、検索機能の良さは
適合率: 正の検索結果のうち、検索意図に合致するものの割合
再現率 検索意図に合致するものが、負の検索結果に含まれていない割合
の２軸で評価されます。そして、この両方の数値が高いものが「いい検索機能」です。
さて、ところでなぜ２軸必要なのでしょうか？
100件の検索結果のうち1件だけ正解の検索機能 v.s. 100件の検索結果のうち98件が正解の検索機能
→当然、後者がよい。これは後者が適合率が高いから。というのは直感的にすぐ理解できると思います。
しかし、適合率が高くても必ずしもいい検索とは言えないケースがあります。
本来1000件の検索にヒットするべきデータがあって、正解の5件だけを出してくれる(995件はとりこぼす)検索機能
→適合率は100%だが再現率が5%しかないようするに取りこぼしの少なさ（先に書いた、負の検索結果の妥当性）も指標として必要だよね、という発想で、2軸での評価をするのが一般的になっているのです。
適合率や再現率の具体的な定義や数式などは「検索 適合率 再現率」とかでググったらいろいろ出てくると思うので、詳しく知りたい方はそちらを見てください。（適当でごめんなさいｗ）
検索機能の評価は「検索クエリへの合致」ではなく「検索意図との合致」で判断する
適合率・再現率の評価で重要なポイントとして、検索クエリに合致するかどうかではなく、検索意図に合致するかどうかを判断軸とするということがあります。
これは裏を返すと、そもそも検索意図を正しくクエリに反映できていないと、いくら検索エンジンを改良してもいい検索機能にはならないということです。
たとえば、アプリの仕事を探したい人が Android ってクエリを入力したとします。
おそらくそのユーザは「Androidアプリ開発の仕事が出てくる、スマートフォン向けのWebページ開発の仕事などは出てこないのが理想的♪」というような期待をもっていることでしょう。
ただ、それをそのまま評価をしても、おそらくいい適合率・再現率にはなりません。
これはなぜかというと、「アプリの仕事を探したい」という検索意図があるのならば、Android ではなく Android kotlin -html5 のような検索意図を反映したクエリが入力されることが検索エンジンとして期待する入力だからです。Android kotlin -html5 というクエリを与えてもなお適合率・再現率が思わしくないのであれば検索エンジン側をチューニングする必要が出てきますし、逆に Android kotlin -html5 というクエリを入力すれば適合率・再現率が良い場合には、検索エンジンではなく検索クエリを組み立てる側に注力する必要が出てきます。
ということで、検索クエリには合致しているのに検索意図には合っていない結果が多く得られる場合には「本当にこの検索クエリで評価するのは妥当なのか？検索意図をちゃんとクエリに反映できていないのではないか？」と疑う姿勢を持ちつつ評価をするとよいでしょう。
実際に検索機能を提供するときに考えておくとよさそうなこと
ここからは、実践的な話です。
検索とはなにかを理解し、その評価方法までわかったところで、どうやって検索機能を作っていくとよいか？というところを説明します。
① 検索の「正解」「ゴール」をしっかりチームで議論しよう
たとえば「初めて使う人が自分にあった仕事を探せるのがいい」のようなゴールイメージでは、検索機能を作っていくことはできません。
- どういう検索意図を持った人が
- どういう入力を検索フォームでおこなって
- どういう検索結果が得られること
という正解ユースケースをあらかじめ議論しておくと、検索エンジンの設計もしやすいし評価もしやすく、スピード感をもって施策を進めていくことができるでしょう。
もちろん正解ユースケースは１つではなくて、複数用意しておくことが望ましいです。
- Androidのアプリ開発をしたい人が「Android」と入力したときに、アプリ開発の仕事を得ることができる
- 会社のロゴデザインを発注したい人が、「会社 ロゴ」と入力したときに、過去の仕事でどのような発注文面で発注されているのか、代表的な仕事を見ることができる
みたいなイメージのものをたくさん用意しておきましょう。
たとえ全部叶えることは難しくても、無いよりは有ったほうが良いです。
② 検索対象のデータセットの特性を知ろう
すなわち、
「エンジンに対してどういうクエリを投げたらいい感じの情報が返ってくるか」
「どういうクエリを投げてしまうと精度がガタ落ちしてしまうのか」
を把握しておこう、ということです。
例えば仕事検索機能を提供するとして、
- 仕事カテゴリによる絞り込みを行うと再現率が著しく下がる
（仕事カテゴリが適切に設定されていないケースがとても多い） - 求めるスキルの項目をキーワード検索対象にすると適合率を上げやすい
などの”癖”をあらかじめ調査しておきましょう。
精度が低い検索機能をつかって満足するユーザは絶対にいません。なので、精度が出ないと事前にわかっているクエリは作れないようにしておくこと（例: カテゴリ検索機能は提供しない、など）で、相対的にユーザの満足度を上げることができます。
③クエリログを残すようにしよう
実際に検索機能をリリースした後では、「ユーザの検索意図」が机上の空論で終わっていないかを確認する必要があります。
たとえば
小遣い稼ぎというキーワード入力が意外とされているAndroidで検索している人は、アプリではなくWebの仕事を請け負っている人が多い
など、想定していなかった検索意図があるかもしれません。
- 誰が
- いつ
- どういうクエリを入力
というフォーム入力値を愚直に保持するという方法もありますし、ElasticSearchなどの検索エンジンではElasticsearchでコンテンツ検索のログを活用する で紹介されているように、メタデータをいろいろ取得できるので、その辺も合わせて保持するとよいでしょう。
まとめ
検索は理論も実装もそれなりに難しい分野ですが、この記事では「どういう姿勢で検索機能を作っていくとよいか？」というところにフォーカスしていろいろ説明してみました。
これから検索機能を作っていくチームで、アイディアを出していくための手助けになればと思います…。
