検索システムを構成するパーツ(検索システムに関する妄想その2)

先日は「システムの特徴と検索機能について」という感じでふんわり書きました。まぁ、頭の中でぼんやり考えてることを文章にしてみた感じです。他にもぼんやりしてるものはいくつかあるので今日も書いてみることに。検索システム?みたいなツイートも見かけたので、検索システムってこんなイメージですというブログを書いてみました。

検索システム(機能)を構成するパーツ

今回はシステムに組み込まれる検索機能を構成するパーツについて書き出してみようかなと思います。パーツといってもユーザー、UI、コンテンツなども入れています。

ユーザー
検索UI
- 検索窓
  - オートコンプリート
- 検索結果画面
  - ファセット
  - ソート
  - ハイライト
- 詳細画面
  - レコメンド
検索エンジン
コンテンツ
検索ログ
- クリックログとかも
サービス提供者

ざっくり書くとこんな感じです。システム構成だったり、機能だったり、アクターだったりといろいろなものが混ざってしまっていますが、登場するものはこんなものです。

ざっくりした繋がりの図はこんな感じです。

それぞれの役割について見ていきましょう。

ユーザー

サイト、システムのユーザーです。検索UIを経由して望んだコンテンツを探します。探す目的は、サイトによって異なります。「何かを購入(ECサイトやオークション)する」だったり、「情報(レシピや社内文書)を見つける」だったりします。図では「キーワード」と記載しましたが、最近では自然文(文章)を受け付ける検索もあります。

検索UI

サイト、システムが提供するUIです。ユーザーはこのUIにキーワード(質問)を入力し、検索結果を取得します。 UIにはいくつものパーツがさらに存在します。簡単に例を上げると以下のようなものです。

検索窓 - キーワードを入れるための入力ボックスです。
- オートコンプリート(自動補完) - サイトによっては、検索窓に何かを入力すると、キーワードを保管したりサジェストしたりしてくれます。
検索結果画面 - 質問にマッチしたコンテンツの一覧を表示する画面です。一覧以外にもいくつか情報が表示されます。
- 検索結果一覧 - コンテンツの一覧です。何かしらの基準(日付順や人気順など)によってソートされたものが表示されます。
- ファセット - 検索結果が持っている属性(価格帯、カテゴリ、メーカー名など)の一覧で、絞り込み検索のヒントです。
- ハイライト - 入力したキーワードがどこにマッチしたかがわかるように、強調表示されたスニペット(情報の一部)が出ます。

検索APIとUIに分かれている場合が多いでしょうか? 処理の流れとしては、検索窓に入力されたキーワードを検索エンジンに問い合わせができるクエリに書き換えてからリクエストを投げます。あとは、検索エンジンからのレスポンスにある検索結果を表示できる形に変換して表示するのが役割です。また、検索ログの出力もこの部分で担当することが多いです(もしくは、検索エンジン自体がログ出力の機能を持っている場合もあります)。

検索エンジン

検索に特化したデータ構造を内部に持っているサーバーもしくはサービスです。 ElasticsearchやApache Solr、Azure Cognitive Searchなどは転置インデックスと呼ばれるデータ構造になっています。検索エンジンの検索処理に対しての主な役割は次の2つです。

クエリにマッチするコンテンツの集合を決定する
マッチしたコンテンツを特定の条件で並び替える(ランキング)

クエリを受け取り、検索結果のリストを返すのが処理の大きな流れです。その他に、ファセット、ハイライトといった付加的な処理を実行することがあります。

また、データ登録(インデキシング/インデクシング)の処理もあります。

登録するコンテンツを検索に特化したデータ構造にして格納する

転置インデックスの場合は、入力されたデータ(文章)から単語列を作り出して、単語からコンテンツのIDが判別できる形にする処理になります。

AlgoliaやElastic App SearchのようなSaaSであったり、RDBの機能を利用するといった選択肢もあります。

データソース・コンテンツ

実際に提供したいコンテンツになります。コンテンツが保存されている場所は、サイトによって異なります。

Webの検索サイト - インターネット上のホームページ
ECサイト - データベースに格納されているアイテムのデータ
社内文書検索 - ファイルサーバーやWikiなどのファイル、文書

といった感じです。実際には、データソースからコンテンツを検索エンジンに登録する場合は、いくつかの処理(いわゆる前処理)が必要になります。社内文書検索やWebの検索サイトの場合は、データを収集するためのクローラーが必要ですし、収集したデータから、検索エンジンに登録するデータを加工したり(HTMLタグを除去したり、メタデータ(URL、収集日、タイトル)を付与したり)もします(ETL処理とか言われる)。

検索ログ

検索を提供するだけであれば、必要ありません。が、実際に検索がどのような使われ方をしているか?を知るために必要な機能になります。この検索ログがユーザーのニーズを読み解くための情報になります。検索ログには次のような情報が入ります。

検索窓に入力された文字列
入力された文字列でヒットした件数

検索結果を出したタイミングでのログです。他にも実際にヒットしたコンテンツのIDなどをログに残したり、他のユーザーと区別をつけるために、ユーザーのセッションごとにIDを発行してログに残したりもします。

また、検索に満足してもらえているかを見るために、実際に検索結果のどのコンテンツに興味をもったのか?という情報も検索ログとして残すことがあります。クリックログなどとも呼ばれます。検索結果のどのドキュメントが実際にクリックされたか(詳細画面に遷移したか)という情報です。1回の検索結果に対してクリックされるごとにログが残ります。もちろん、結果に満足しない場合は、クリックされずに、キーワードを変えたり、絞り込み条件がクリックされたりします。

ECサイトなどの場合は更に、実際に購入されたかどうかといった情報もユーザーのニーズを読み解くための情報となります。詳細画面へのクリックログや購入ログについては、検索以外からの流れ(広告やDMだったり、レコメンドだったり)なども考えられます。これらのログを元に、検索を改善していくことになります。

サービス提供者

サイト・システムの提供者です。コンテンツの準備、検索UIにはどんな物が必要なのか、サイト・システムにとって良い検索とはなにか?、検索ログからユーザーのニーズを分析して何を改善していくのか?といったことを考えます。例としては次のようなことです。

検索結果に表示するコンテンツとはなにか?
コンテンツの持っている項目・属性の何を検索対象とするか?
検索結果の並び順(ランキング)がどんなものがよいのか?
検索UIにはどんなものを表示するのか?

検索機能を作るときの流れ

検索機能を構成するパーツにどんなものがあるかを紹介しました。実際にシステムに検索機能を追加する場合は、最低限、次のものが必要になります。

検索UI
検索エンジン(RDB?SaaS?ミドルウェア?)
データソース・コンテンツ

とりあえずこれらがあれば、検索機能を作ることはできるかと。ただ、作っただけでは、いいか悪いかの判断がつかないので、どういった使われ方をしているかを知るために検索ログをとったりして、改善をしていく必要が出てきます。

まとめ

わかってるよそんなことはと言われそうな感じになったかもしれないですが、検索の機能を構成するパーツについて紹介してみました。細かなはなしは色々とありますが、大まかにはこのような役割のパーツがあります。

実際にはこれらのパーツを用意すればよいわけではなく、それぞれで検索を良くしていくためにどんなことを考えていくのか?などが出てきます。そのあたりの話はまた、別のブログで書いていく感じでしょうか。こんな感じで書いてくと、終わらない気がしてきたけど。。。次はどんなはなしを書くかなぁ。