検索 on @johtaniの日記 3rd

検索技術勉強会2024 Summerで司会しました

Thu, 31 Oct 2024 13:12:49 +0000

どーも、johtaniです。

Search Engineering Tech Talk 2024 Summerを10/10にビズリーチさんの新オフィスで開催し、また司会をしてきました。今年2度目になります。資料と録画をべ協会のページの資料のところにアップロードしてありますので、当日参加できなかった方、気になっている方は見ていただければと思います。

発表内容については資料などを見ていただくこととし、今回も運営周りでのメモを残しておこうかなと。司会はあいかわらず緩い感じだったので、もう少しちゃんとやらないと。。。

継続したいこと

スピーカーとSlackでやりとり

前回同様に、スピーカーの方たちに初手の連絡は、スピーカー登録フォームに記載していただいた連絡先に連絡を入れましたが、その後は、search-tech-jpのSlackでやり取りをさせていただき、スムーズにやり取りができました。スタッフとも共有しやすいので便利でした。発表当日の連絡や、その後の動画の確認などもこちらが使えるのは楽ですね。

検索技術に関する情報交換を目的とした Slack を立ち上げました！こちらの招待リンクからご参加ください。 https://t.co/Tca70vuMff
— takuya-a (@takuya_b) March 31, 2021

会場へのアクセスのスライドを用意

会場提供をしていただいている方には少し負担になっているかもしれないですが、渋谷の新しいビルということもありスライドを用意してもらいました。オフィス入り口は商用のテナントとは別の入り口だったりするので迷子になることも多いと思います。私自身はスライドのおかげですんなり会場に到着できました。ほかの皆さんはどうだったんだろう？

名札を印刷

今回も次のツールを使って名札を印刷しつつ、ネームホルダーを用意してみました。懇親会で首からぶら下げていただいたのでよかったかな？

MasayaAoyama/connpass-nametag-generator： Connpass のイベント参加者の名札を生成するツール群

飲食提供をやめてみました

会場での飲食自体はOKだったので、おなかがすいた人は食べながら聞いてもらうのもありにしてみました。といっても、食事してる人はいなかったかも？懇親会にも結構な人が残っていただき大変盛り上がりました。今後もこれでいいのかもな。

改善点

録音環境の改善

録音したものを見ていただくとわかりますが、音がこもっています。スピーカーの方にGoogle Meetで入って画面共有してもらいつつ録画し、私のノートPCのマイクだけをONにして録音してみました。録画自体は会場のWi-fiをスピーカー限定で利用したので途切れたりすることもなくきれいに録画できていました。

ただ、音に関してはノートPCのマイクだから＋圧縮されたりノイズキャンセル機能が動いていたりで少しこもった感じがしています。会場のマイク経由での音はそれなりに拾えていますが、マイクなしでの声や拍手は入っていなかったりです。

携帯できるマイクもあったので、次回は持って行って再チャレンジかな？みんなどうしているんだろう？この辺のノウハウが足りないし、3か月に1度の開催なので身についてない気がする。

Summer?Fall？

Summerという名前を付けてしまいましたが、当日は寒かったかもなぁ。。。

そのほか

connpassのQRコード読み取りを活用

参加者の管理と受付 — connpassご利用ガイドドキュメントにあるQRコードを利用した受付をしました。私自身は受付をしてないので、スムーズだったかどうかは定かではないのですが、受付人数の確認がものすごく楽です。名札を印刷しているのもあるので、参加者数は把握できるのですが、実際にどなたが来ていたのか？などがすぐにわかるのは大変便利ですね。 Connpassの開発者の方ありがとうございます！

まとめ

話をしていただいたスピーカーの皆さん、参加していただいた参加者の皆さん、会場を提供していただいたビズリーチさん、準備で奔走してもらったスタッフの皆さん、ありがとうございました。おかげさまで今回も楽しめました（自分が楽しむために開催してます）。そのあと風邪をひいてしまったのでブログや録画の公開が遅くなってしまい申し訳なかったです。

さて、次回も3か月後くらいに開催できるようにスピーカー探し頑張らないとな。スピーカーおまちしております！（スピーカー登録フォーム）

検索技術勉強会2024 Springで司会しました

Sat, 01 Jun 2024 13:31:37 +0000

どーも、johtaniです。

Search Engineering Tech Talk 2024 Springを5/31にLegalOn Technologiesさんの新オフィス（渋谷サクラステージ）で開催し、司会をしてきました。昨年末の12月に4年ぶりの復活開催から2回目（計6回目）となります。フリーランスになってからこういう場で司会をしたのは初めてかも？

前回は諸事情で裏方スタッフとして手伝っていましたが、今回はオープニングと司会をやってきました。ひさびさにオフラインで人前でしゃべったので、ちょっとグダグダ感が出てしまったかもですが、面白い話をいろいろ聞けて楽しかったです。

今回（前回も含め）はいくつか新しい試みも行ったので自分用のメモとして記録しておこうかなと（セッションの感想などは参加者の皆さんにおまかせします！）。

新しい試み

スピーカーとの連絡方法

スピーカー登録については、知り合いに声をかけてみたり、勉強会のページに用意してあるGoogleフォームで登録をしてもらっています。こちらのGoogleフォームに登録されると、メールやTwitterでコンタクトをとり、今回の開催で日程が合うかどうかを調整しています。

実際に登壇していただく形になったあとに、前回からはsearch-tech-jp（以下のツイートから参加可能なはず）のSlackでプライベートチャンネルを作って連絡をするようにしています。個別に連絡するよりもスタッフの誰かが反応できるようになっているので便利になったかなと。

検索技術に関する情報交換を目的とした Slack を立ち上げました！こちらの招待リンクからご参加ください。 https://t.co/Tca70vuMff
— takuya-a (@takuya_b) March 31, 2021

会場へのアクセススライドを用意してもらった

新しいビルでかつ新しいオフィス（すごくかっこいいオフィスエントランスだった！）ということもあり、入り口がわかりにくいかも？という話が事前のスタッフ打ち合わせで出ました。他社のブログに写真付きでオフィス受付ロビーへの案内を作られているものがあったのですが、さすがに流用するのもわるいですよね？ということになり、スタッフでLegalOn Technologiesの方にスライドを作成していただきました（案内スライド）。

そのうち会社としてアクセスのわかりやすいページなどもできると思いますが、わかりにくい入り口などの場合はこういうのを用意すると便利かもなと。

当日は何人かLegalOn Technologiesのかたに誘導役として経路に立っていただいたので、そちらもわかり安かったのではないかなと思っていますがどうでしょう？（感想聴くの忘れてた。。。）

名札を印刷して持って行った

懇親会で交流してもらいやすくするために次のリポジトリで公開されている名札生成ツールを利用させていただきました。

MasayaAoyama/connpass-nametag-generator： Connpass のイベント参加者の名札を生成するツール群

できたものはこんな感じ（名札に入れた写真を撮り忘れた。。。）。

さてと。便利なツールありがとうございます！https://t.co/Q0r84v0ZDp pic.twitter.com/IcSQRZtVf6
— Jun Ohtani (@johtani) May 31, 2024

当日に印刷して裁断して持参しました。アイコンが登録してあると見やすくていいですね。

スタッフ、スピーカーについては参加者一覧には出てこなかったため、別途追加して印刷するところだけは次回以降も忘れないようにしないとかな。（うまくやれば、Connpassの参加者一覧としてダウンロードできるCSVにスタッフやスピーカーも追加できたりするのかな？）

LTもあり

前回まではスピーカーに登録していただくのは25分のセッションのみとしていました。ただ、これだと初めての方やちょっとしたこと（ちょっと困ってること、こんなこと試してみたよ）を話したい方にはハードルが高いかもしれないなと。あと、LTあればスピーカーするのにという声も見かけました。

当日参加のLTではありませんが、スピーカー登録フォームにLT枠も設けてみました。実際に今回はLTを2本用意していただくことができましたし、いろいろな話題も含められそうだなと。

事前の調整などもあるので今後も当日飛び込みのLTの予定はないですが、LT枠への募集は行っていく予定です。

懇親会が1.5h

今回は開始時間を19時からとしたため、懇親会の時間を長くとることができました（ちょっと懇親会の準備に手間取ってしまいましたが）。そのため、いつもよりもスピーカーや参加者の皆さんの間で話が弾んだんじゃないかな？と思っています。どうだろう？

改善点

いくつか改善できるかも？という点もあるのでこちらもメモを。

名札の配り方

オフィスに入るためにセキュリティゲート前に受付を用意し、記名と引き換えにQRコードを渡して会場まで来ていただき、会場の後ろの机に名札を広げておいて置く形にしました。

印刷したあとで気づいたのですが、受付票にある番号も名札に印刷しておくと名札を受付で渡せたのかもしれないな？と思いました。効率よく名札をつけてもらいつつ入ってもらうのにはどうするのがいいのかなぁ？悩ましいところです。番号あったほうがいいのかな？

スピーカーとのファーストコンタクト

Googleフォームで入力してもらったX（旧Twitter）あてに連絡を入れようとして、フォローされていない方にDMが打てないことがありました。連絡がつかないとしょうがないので、メンションをしたのですがそれでも返信がもらえずに連絡取れないという状況になっていたりします。

メールアドレスのみにするか、search-tech-jpのSlackに登録してもらい、そのアカウントを記入していただくようにしてSlack上でDMをやり取りをしたほうがいいのかもしれないと考えているところです。

事前にSlackに登録していただく必要が出てきてしまうとスピーカー登録のハードルが上がってしまわないかが心配ですが、連絡が取れないよりはいいのかなぁ？どうしたものか。

とりあえず、GoogleフォームにSlackへの導線とSlackアカウントでもOKという記載をして試してみるのがいいのかもな。

開始時間

19時開始となったために、キャンセルしてしまった方とかいるかどうか？というのはちょっと気になる所です。スタッフのみんなにもセッションを聞いてもらいたいので、受付は基本的に勉強会開始のタイミングで閉じるようにしているので。できれば遅いほうがいいなどの意見があるようだったら聞いてみたいけど、そういう人はいたのだろうか？次回開催時にアンケートみたいなのをとるのがいいのかなぁ？

まとめ

話をしていただいたスピーカーの皆さん、参加していただいた参加者の皆さん、会場やフードを提供していただいたLegalOn Technologiesさん、準備で奔走してもらったスタッフの皆さん、ありがとうございました。おかげさまで今回も楽しめました（自分が楽しむために開催してます）。

いくつかチャレンジしてみたこと、チャレンジしてみたいことまだまだありますが、次回の改善につなげられればいいなということでメモを残してみました。

3ヶ月ごとに1度が目標なので、スピーカーや会場探しを次回に向けてがんばらないとなー。

今後も定期的に開催したいので、スピーカー登録、会場やドリンクスポンサー登録をお待ちしております！

検索対象のデータとデータソース(検索システムに関する妄想その3)

Tue, 15 Sep 2020 11:23:34 +0900

先日は「検索システムを構成するパーツ」ということで検索システムを構成しているパーツについて書いてみました。

大体、検索がうまくヒットしないといった場合に、問題になるのがコンテンツ自体のデータもしくは、転置インデックスのキーワードだったりします。そこで今回は、前回のパーツの「データソース・コンテンツ」周りについて少し書いてみようと思います。言葉の定義、それぞれがどんなことをやるのか、とりあえず導入したあとにコンテンツ周りでどんな改善ができるかなどを書いてみます。

言葉の定義

コンテンツ

実際に検索させたいデータになります。コンテンツにはWebページ、データベースのレコード(CMSで登録されたデータなど)、ファイルサーバーにある文書(PDF、Word、Excelなど)などになります。

データソース

コンテンツのマスタデータが保存されている先です。よくあるデータソースとしては以下のものが考えられます。

Webサイト - 自社もしくはインターネットに存在しているWebサイトです。
ファイルサーバー - ローカルネットワーク上のファイルサーバーもありますが、最近ではGoogle DriveやDropboxといった外部のWebサービスもあります。
RDB - CMSや自社システムでのデータの保存先です。

クローラー

コンテンツをデータソースから収集してくるプログラムのことです。 Webサイトやファイルサーバーからコンテンツを収集して検索エンジンに登録するところまでを担当します。 RDBにあるデータを検索エンジンに登録する場合はクローラーがデータを登録するというよりは、RDBにデータを登録するシステムが検索エンジンに登録する機能を持っていることが多いです。

データの収集と登録

収集

クローラーを使用した収集の場合は、サービスの特性とデータソースによって、どの程度の頻度でクロールするのか、クロール対象はどこまでか?といったものを決める必要が出てきます。これらが決まれば収集ができるかと(他に権限とかもありますが。)。収集コンテンツは、そのままでは利用しにくかったり、利用できないことがあるので、次はデータの変換を行います。

データ変換

コンテンツはそのままの形では検索エンジンには扱いにくいデータ形式である場合があります。

Webページの場合

Webページの場合、コンテンツにはHTMLタグが入っていたり、JavaScriptなど検索対象にはしたくないデータなどが入っています。これらを除去して、検索させたいものを取り出す必要があります。また、Titleタグなど、いくつかメタデータとして扱えるものがHTMLで規定されているので、これらを別の項目として取り出して個別に検索できるようにすると便利です。 HTMLをパースしてデータを抜き出す処理ができるライブラリなどがあるので活用します。

ファイル

PDFファイルなど、ファイルの場合もメタデータと呼ばれるファイル自体が持っている情報が存在します。作成者、更新日時、ファイル名、パスなどです。これらも検索時に有効な情報になります。また、ファイルから文字列を抜き出す処理も必要になります。それぞれデータフォーマットが異なりますので、そのフォーマットに合わせて文章データを抜き出す処理が必要です。OSSや製品がありますので、それらを利用して、ファイルから文章を抜き出します。

RDB

RDBのデータの場合、データが正規化されています。検索エンジンでは、非正規化のデータを登録して検索することが基本となるため、まずは非正規化して取り出す必要が出てきます。

例えば、ジャンルやカテゴリ、各種IDなどが実際のコンテンツのレコードに入っていると思いますが、これらをユーザーが入力したキーワードで検索したい場合などは、IDではなく表示名を取り出して、検索エンジンに登録する必要が出てきます。

その他

データごとの変換処理について説明しました。その他に、データのクリーニング処理などと言ったことも必要になってきます。例えば、HTMLのタイトルに必ずサイト名が入っているが、除去したいといった場合や、検索エンジン固有のデータの前処理などもあります。

登録

最後は検索エンジンへの登録です。最近の検索エンジンはJSON形式でデータを受け取る場合が多いので、JSONに変換することが多いです。基本的には各種プログラミング言語のライブラリが用意されているのでこれらを利用するのが基本となります。

検索したい項目、検索させたい方法などを洗い出し、必要なデータを作成して検索エンジンに登録します。登録と書いていますが、更新、削除などもここでの対象となります。

ここまでの流れで、データソースからコンテンツを取得し、変換して、検索エンジンへの登録が終わりました。

検索の改善

検索のログから分析して改善していくのが良いですが、ユーザーからの質問や意見などからも改善すべき点が見えてくると思います。検索ログでは、次のようなものを元に、検索がうまく行かないものを見つけ出します。

0件ヒット
0件クリック

ヒットしていない検索ワードがある場合、コンテンツに問題がある場合があります。まずはこのあたりをとってみるのが良いかと。そもそも、入力されたキーワードにマッチするコンテンツを扱っていないこともわかりますし、入力されたキーワードに似た単語を持ったコンテンツなども存在するはずです。類義語の辞書を用意して、検索にヒットできるようにするといった分析と改善にも利用できます。

あとは、検索エンジン側の話ですが、形態素解析器などを利用している場合に、意図した区切りになっていないために、うまくキーワードがヒットしないと言ったこともあります。

コンテンツの理解

実はこれが一番だったりします。どんなコンテンツを自分たちが扱っているのか?どんなデータがどういった項目でコンテンツに入っているのか?といったところから、コンテンツのデータを元に検索にヒットさせる方法が改善できます。

CMSなど人が入力したデータをコンテンツとして扱う場合、入力画面を改良することで、望んでいるデータを入れてもらえたり、不要なデータが入らなくなる可能性があります。例えば、ECサイトなどで商品の説明文やタイトルにいろいろなキーワードが入っている場合などがあります。むりやりどんなキーワードでもヒットさせたいという入力者の意図もあるのですが、検索しているユーザーにはノイズになることも多いです。適切にカテゴリやジャンル、属性といった項目に分けることでおかしな入力データを減らすことも可能です。

Webサイトなどをクローリングしたものの場合は、サイトごとに文章の特徴があったり、重複している部分などが合ったりする場合があります。これらもコンテンツをよく調べることで、不要な情報を除去したりといったことが可能になります。

まとめ

簡単ですが、検索のデータソースやコンテンツにまつわる話を紹介しました。もちろんここでは紹介しきれていない項目がいっぱいあります。また、具体例ではなく概略をざっくりと書いているのでわかりにくい場合もあるかもしれません。すこしユースケースを絞り込んで書いたほうがわかりやすくなるのかも?

次はUIとか書くかも?

不明点とか疑問点、指摘事項などあればコメントしていただければと。要望などもお待ちしております。

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

Tue, 28 Jul 2020 12:34:42 +0900

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

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

今回はシステムに組み込まれる検索機能を構成するパーツについて書き出してみようかなと思います。パーツといってもユーザー、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?ミドルウェア?)
データソース・コンテンツ

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

まとめ

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

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

システムの特徴と検索機能について(検索システムに関する妄想その1)

Mon, 27 Jul 2020 18:28:54 +0900

今年の頭からシステムの検索周りを手伝う仕事をフリーランスとしてやっています。検索の仕組みを知れば知るほど面白くなってきたからという理由になるのかな? LuceneやSolr、Elasticsearchなどを長く触っているというのもあるかと思います。

ということで、検索についていつも考えています。頭の中でまとまっていない状況ですが、システムにおける検索機能についていくつか頭の中にあることを書き出して、いろんな方にダメ出しやコメントをもらいたいなと思ったので、色々と書いてみようかと。思いつきのままに書いているので、はなしがあちこち飛ぶ可能性もありますが、あしからず。

検索って難しい

「「検索」とは、データの集合から目的のデータを探し出すこと」By Wikipedia

一言で「検索」といっても、使う人、ユースケースによっていろいろな「検索」があります。例えば、新しいスマホを買ったときに、スクリーンロックの時間を設定する機能を「検索」したりします。また、PCで仕事をしているときに、ファイルの中身をある文字列で「検索」したりもします。 TSUTAYAに行って、欲しかった本がおいてあるかどうか店内の端末で「検索」もします。 Rustを書いていて、こんなことをやるライブラリありそうだよな?と思ってGoogleでウェブの検索をしたりもします。

私が特にそうだと思いますが、なにかあったらまず検索をするという生活をしています。ただ、このとき、「検索」といっても望んでいる挙動が違ったりするものです。以下は自分が「検索」しているときに想定していることになります。

ファイル内の検索をしているときはgrep的な検索を想定していることが多い。
書籍の検索をしているときは、特定の項目(著者など)に対してgrep的な検索を想定しているが、名前の読みなどでも検索されることを想定している(漢字覚えてなかったりする。。。)。
Rustを書いているときに機能をGoogleで検索するときは、いい感じに検索してくれることを望んでいる(入力するキーワードが曖昧なことが多々ある。例えば、そのものズバリの名前をしらないときとか)

あくまでも私が想像している挙動です。他の人とは違う可能性もあります。なので、「検索」といってもさまざまな要素があるし、想定しているシーンも異なるので「難しい」なと思っています。また、そんな「検索」ですが、世の中的にはあって当たり前だと思われていたり、お金や時間がかかるものと思われてなかったりもします。ま、けどそういったことも含めてやればやるほど面白いなと感じている今日このごろです。

前置きはこのくらいにして、今回はシステムの特徴と検索機能について感じていることを書いてみようと思います。

システムの特徴と検索機能

先ほども書きましたが、検索は今やシステムに欠かせない機能となっています。が、あればいいというものでもないのではないかなと。とりあえず検索できるべきだということで検索機能を追加しても使いにくいものや、想定している動きをしない場合は使われないものになってしまいます。

システムでの検索機能は特に、「情報検索」(Wikipediaはこちら)と呼ばれたりもします。Wikipediaによるとこんな説明です。

情報検索（じょうほうけんさく）とは、コンピュータを用いて大量のデータ群から目的に合致したものを取り出すこと。検索の対象となるデータには文書や画像、音声、映像、その他さまざまなメディアやその組み合わせとして記録されたデータなどが含まれる。

「目的」と呼ばれるものは「ユーザーのニーズ」と呼ばれたりもします。「合致したもの」というのがシステムが返す「検索結果」になります。検索結果は大体の場合、何かしらの順序でソートされていることが多いです。ざっくり話をすると、「ユーザーのニーズ」を元に「(何かしらの順序でソートされている)検索結果」を返すという処理です。

ただ、この「ユーザーのニーズ」や「何かしらの順序でソートされている検索結果」はシステムの特性、特徴によってぜんぜん違うものになります。検索エンジンを入れただけで解決するものではありません。

また、システムは提供する側のニーズもあります。 ECサイトであればより多くのユーザーに購買してもらったり、コミュニティサイトの場合は利用ユーザーを増やしてコンテンツや広告の収入を増やしたりといったニーズがあります。

これらの両方のニーズが検索機能に影響を与えたりもします。

いくつか例を上げてみましょう。

書籍の検索の場合

ユーザーのニーズは、「ある本を探す」ことです。そのためにユーザーがクエリを入力します。クエリは、例にも出しましたがタイトルや著者名の読みだったりします。検索窓が1つしかないというよりは、著者やタイトル、出版社などそれぞれの項目ごとに検索できるほうが便利だったりしますよね。検索結果については、完全一致したものが一番最初に出てきてほしいこともあれば、出版年月日の降順で並べたいことなど、その時々でやりたいことが変わったりもします。

場合によっては、説明文などでも検索できると嬉しいこともあります。また、システムからは離れますが、図書館や書店で時々、「〇〇について書かれている本ありますか?」といった聞き方をしたりもします。

また、書店としては、探している本を見つけてもらうために検索端末などを用意しますが、それ以外の本も買ってもらえるといいですよね。オンラインの書店などでは、検索結果や書籍詳細の画面に関連書籍が出ていることもあります。

検索とは少し異なり、探索(なにか面白い本とかないかな?というようなニーズ)をしに、書店に行くこともあります。書店で平積みされた本やポップなどを見て新しい本に興味を持つこともあります。

オークションサイトやECサイトでの検索の場合

ユーザーのニーズは、「欲しい物を探す」ことです。ユーザーが入力するクエリは、幅広いものになると思います。製品の型番を入力する人もいれば、メーカー名や製品名だったり、ジャンルで絞り込んで検索することもあります。

探されるもの(コンテンツ、アイテム)も多数に渡ります。検索窓は1つかもしれませんが、検索結果には、絞り込み条件(ファセット)がいくつか並んで、絞り込んでいける仕組みが用意されていることが多いです。

検索結果のソートは、価格順だったり人気順だったりします。ただ、オークションサイトの場合は新しいもの順や、終了日時の早い物順だったりします。

サイト提供者のニーズとしては、より多くのアイテムを購入してもらうこと(売上)です。また、オークションサイトの場合は、アイテムを提供している人のニーズも影響してくるでしょう。売りたい人はより多くの人の目に留まってほしいと思うはずなので、様々な情報を付与していかに目にとまるか?といったことを考えてくると思います。

また、様々な商品を扱うECサイトの場合は、さらに色々と大変になってきます。たとえば、「iPhone」で検索されたときに、 iPhoneそのものが上位に来るべきなのか、ケースなどの周辺商品なのかだったりといった問題が出てきます。商品の提供者が多数に渡る場合は、同一商品でもさまざまなお店から提供されてしまうために、検索結果一覧に多数同じ商品が並んだりもしますよね。

レシピサイトでの検索の場合

ユーザーのニーズは「レシピを探す」です。が、探し方はユーザーによって様々です。冷蔵庫にある材料を入力して検索することもあれば、食べたいものが決まっていてそのレシピを検索することもあります。このとき、重要なのは類義語だったりするでしょう。食材やレシピは同じものでも様々な名前(例:パクチー、コリアンダー、シャンツァイ(香菜)など)を持っていたりします。また、部位や形によっても名前が変わったりもします。

検索結果は人気順で並ぶことが多いでしょうか? ただ、レシピの提供がユーザーによるものなのか、サイト運営者が提供しているものかによっても変わってくるでしょう。

サイト提供者のニーズとしては、レシピコミュニティサイトの場合は、ユーザー数の増加や広告の売上などがあるでしょう。調味料などのメーカーがレシピサイトをやっている場合は、調味料の売上だったりします。この場合は、検索がどの程度売上に寄与しているのか?などを測ることが難しかったりしそうです。

社内文書検索の場合

ユーザーのニーズは「文書を探す」です。探し方はファイル名であったり、ファイルのなかに出てくる単語だったりします。社内用語・略語のような特殊な単語で検索されることもあるでしょう。ユーザーによっては、ぼんやりとした「こんな資料を探している」といったふんわりとした検索をしたくなることもあります。

検索結果の表示順は「それっぽいもの」が上位に出てくることが望まれそうです。ただ、古い文書が出てきても役に立たないこともあります。新しい文書のほうが役に立つことが多いので、最近作られたものというのも重要な情報になります。ただし、権限によっては見ることができなかったり、そもそも探すこともNGだったりもします。

社内文書検索の提供者は、素早く検索できるものを提供することで仕事の効率を上げてもらったり、無駄を省くことができることを期待しているでしょう。

昔からですが、社内の文書は様々な場所に散らばっていることが多いです。顧客管理システム、ファイルサーバー、Wiki、ウェブサイトなどこれらをまとめて検索できるシステムなどが望まれていることも多いです(使われるかはまた別ですが。。。)。

スマートスピーカーの場合

ちょっと特殊な面白い例かなと思ってます。音声で検索(というかお願い?)します。システムとしては、ユーザーのニーズを理解するのに2段階あるのかなと。

音声認識
認識した文章・キーワードで検索(場合によってはコマンド発行)

これだけでも難易度が増します。

さらに、画面のないスピーカーの場合は、結果は1件だけになります。これって結構難しいことだと思うんです。画面があれば、検索結果を上位10件などのリストで表示して、あとはユーザーに選んでもらうことができますが、音声の場合は1件だけしか返せません。また、レスポンスタイムもシビアなものだと想定されます。ずっとスピーカーに黙っていられると困りますよね? きっと大変なんだろうなぁ(妄想)。

このように、検索と言っても、システムごとに要求・想定されるものは変わってきます。

まとめ

例をいくつか上げましたが、ざっくりしすぎて発散してますかね。。。想像している部分もあるので、この通りではないと思います。ただ、システムによって、「検索」といってもシステムの特性上、さまざまな物事、思惑が絡んでくるというのは想像してもらえたと思います?(思いたい)。

システムに検索機能を追加すると言っても、探したいものが何なのか?、探してもらうものはどういったものなのか?、検索機能を追加することで何を達成したいのか?など考えることは色々あります。どうやって、検索機能を実装するのか、その検索機能を実装するためにはどんな情報が必要なのか?などの検索機能のコアな部分を考えるだけでなく、提供しているシステム、コンテンツがどんなものかなど、システム全体を考えながら検索機能を考えていく事が検索をより良いものとして行くことだと思います。

また、検索されるものも検索する人もシステムが成長するのに合わせて変化していきいます。システム同様、一度作ればおしまいというものではないので、やることはいっぱいあるのかなと。

次は、検索のパーツについてなにか書こうかなぁ。

ボヤキ

もう少しまとめてから書いたほうがいいのかもなぁ。もしくは、出てくる要素を整理するとか。ユーザー、コンテンツ、コンテンツ提供者とかで。ふんわりとしたブログになってしまった。個別のシステムごとにもっと書けることもありそう。

Search Engineering Tech Talk(検索技術勉強会)の運営として参加して始めてみました。

Tue, 26 Feb 2019 23:38:00 +0900

どーも、johtaniです。

Search Engineering Tech Talkという勉強会に運営として参加して、第1回の勉強会を開始しました。本日（2/26）は第1回目だったので、ブログを残しておこうかと。

勉強会自体の資料については第1回の勉強会のページにあるし、勉強会の感想とかブログはツイートやみんながブログを書いてくれると思うので、勉強会開催の経緯などについてブログを残しておこうかと。

なんで始めたの？

私自身が古くはFAST Searchに始まり、何か縁があって、検索のシステムに長く携わってきたこと（Apache Solrの本書いたり、Elasticsearch勉強会始めたり）もあり、検索が面白いなと日々思ってます（思ってるだけかもしれないが）。

で、これまでElasticsearch勉強会をやっているのですが、検索エンジン固有の話ではない、いわゆる検索の共通の課題というのがあるなぁと。そういう課題やノウハウって、製品に限らず共有できれば面白いことがもっとできるんじゃないだろうか？と感じることが多々ありまして。オープンソースのコミュニティをソースコードをベースではなく、共通の課題・話題を中心としたコミュニティがあってもいいんじゃないかなぁと。

まぁ、要は、私がみんなの検索で困ってることとか、どうやって検索システム考えてるのかが聞きたかったわけですよ。

ということで、一人でやっても面白くないので、興味ありそうな人を募ってやってみようということを始めたのが2018年12月くらいです。

運営とかどうしてるの？

まずは、共同主催者（コアメンバー）を募集してみようということで、Googleフォーム作って、興味ありそうな人がいる場所に投稿してみました。（TwitterとかFBとか）で集まったのが今回紹介したメンバー（スライド参照）です。ユーザー企業の人もいれば、私みたいな検索エンジンの人もいるので面白い感じにできたかなぁと。で、スピーカーを運営や知り合いに声をかけて第1回をやってみたという感じです。

今後どうするの？

残念ながら次回はまだ未定です。 2ヶ月に1回くらいのペースで開催できればなーと思ってますが、スピーカーが集まるかなどによるかなぁと。ということで、勉強会のグループのページにスピーカー応募フォームのリンクがありますので、スピーカーに興味がある方は入力していただければと。

もちろん第2回はやりたいので、勉強会のページからの連絡をお待ちください！！