第2回の検索技術勉強会 Search Engineering Tech Talk 2019 Spring に参加してきました。
個人的に、最近少し離れているのですが、Elasticsearch で検索関連の仕事をしていて、興味があったので参加しました。
第1回には参加できなかったのですが、第2回も濃い内容でした。
今回はブログ枠で参加したので、内容と感想を少し書きたいと思います。
安心な移動のためのPOI検索
1つ目は、今回の会場だった NAVITIME の地点検索 PM の方のお話。
NAVITIME って有名で個人的にも使っていますが、技術的な話を効いたことがなかったので新鮮でした。
スライド:
https://twitter.com/navitime_tech/status/1120874426340233216
POIとは
Point of interest: 移動の目的地 という言葉は初めて聞いたのですが、今回は NAVITIME らしいこの POI の検索に関する話です。
POI の必須要素は
- key, 名前、緯度、経度
- その他にも、よみ、住所、郵便番号、カテゴリ、など
上記のようなもので、NAVITIME では 1000万 POI を提供していて、その提供者は 700 もいるようです。
POI の特徴
- 要素が沢山
- 要素は単語か短文
- 文章は少ないかまったくない
また、目的地にたどり着けないのは、検索結果が何もないのは大きな問題のようです。
どんな検索でも問題になる点ですね。
この後、Google 等の情報検索と似てる点などの比較のお話をされていましたが
- 検索結果の上位選択率
- ほとんどの人が、検索結果の上位5件以内を選択 3つの NAVITIME アプリで > 90%
これらの点は、ふつうの情報検索とにていて、キーワードとの一致度が重要そうな感じ。
しかし、普通の情報検索のように、キーワードのみを重視すると発生する問題もあるようで、
具体的な例として "椿山荘" を取り上げられていました。
椿山荘といえば、ほとんどの人がきれいが庭園があって有名な "ホテル椿山荘東京" を思い浮かべそう。
しかし、キーワードマッチを重視すると、各地にある椿山荘という名前のアパート、他県のものがでてくるようになってしまうそう。
その他にも、キーワードだけを重視すると失敗する例として、椿山荘、スカイツリー、ディズニー（ディズニーストア？もあるけど、ランドやシー）を挙げられてました。
上記のように、有名な POI は上位に返却されることを期待されているため、これを考慮しなければいけないようです。
POI は 有名度という独自のスコアを利用していて、PV, いいねのかず、に相当するものを使っているようです。
一方で、有名度を考慮した結果（NG例）として、"セブンイレブン" というワードがあって、有名度をもとにすると一番上が、丸の内二重橋ビル店、テレビ東京本社店など、有名そうなところになる問題が。
コンビニは近いほうがいい、距離の考慮も必要で、チェーン店の場合は近くを優先する必要があるみたいです。
結果的に、検索結果へ考慮する要素としては
有名なPOI向けの要素と優先順位の場合
- *有名度、適合率、再現率
チェーン店
- 適合率、*距離、再現率
4つの要素、重み付けは日々研究中という話でした。
さらなる工夫
変な名前、食楽知庵（くらちゃん）など、IMEで変換できないものはオートコンプリートが必要。
また、路線名の検索など、POI以外のキーワードとの組み合わせも多い。(例: 銀座線 => 銀座線の駅)
まとめ
- POI検索における検索要素を紹介
- POI ならではの工夫を一部紹介
- 安心な移動を実現するために日々改善中
質疑応答
有名の判断
- 人力も自動も両方ある
地名 + チェーン店
- 例えば、あるカフェの近辺に何駅があるかのデータを作っている
- 駅ワードがあるので、チェーン店の中からこれにマッチさせる
個人的な感想
検索対象として、1000万と聞くなかなか現実的な数字なんだなと言う感じがしますね。
生々しい話が出てきてすごい楽しかったです。とても NAVITIME らしい話でした。
社内ドキュメント検索システム構築
検索エンジンの中身ではなく、企業内検索の中身。
Fess というオープンソース検索システムの運用のお話でした。
スライド:
https://twitter.com/shinsuke_sugaya/status/1120701240059367424
企業内検索とは
エンタープライズサーチとも言う、企業内の様々な情報を検索するシステム
- 社内サイト
- ファイルサーバー
- 業務システム（クラウドサービス
Fess
- オープンソースの全文検索システム
- 5分で構築できるぐらい簡単に利用可能
- Javaベース、Elasticsearchを検索エンジンとして利用
検索分野での立ち位置としては、検索システム、Lucene や Elasticsearch、クローラーより、もっと知識がなくても利用可能ですぐ使えるもの。
Google も同様のものを提供していたが、最近やめた？らしい。
よく出る課題
クロール対象の大規模化
- 数千万ファイル
- 分散検索、Elasticsearch で実現可能
- クロールする方法も工夫が必要
- 更新されたファイルリストを生成
セキュア検索
認証状態により検索結果を出し分ける
AD連携、Sambaの場合にはファイルの権限を利用
シングルサインオン
ファイルの種類
Office や PDF だけでなく、一太郎や AutoCAD なども対応しているらしい
file:// が動かない
- Fess ではプロキシとしてファイルを返却
爆弾ファイル問題
- zipファイル爆弾
- 展開後に数Gのファイル、tikaでは対策がある
- excelファイル爆弾
- 大量のコピペ
- Fessでは単語の切り捨てや、重複除去対応
PDFの文字化け
古いバージョン出刃文字化けするが、PDFBox なら問題ない
OCR は、無駄なスペースが入るので、また別な処理が必要
集計や反映
クリック数Likeで判断する
関連クエリー（同義語）
- Google Search Appliance にあるので要件になりやすい
- 同義語辞書で対応可能な場合もある
個人的な感想
個人的には、この手の話は知識がなくて初めて聞いたので、本当に勉強という感じでした。
エンタープライズサーチは、お金になりそうで、どんな会社でも必要そうなシステムだが、それぞれの会社の環境にあわせて作るのは本当に大変そう。
とはいえ、自社でもこういうの実装したら便利そうとは思った。特に社内検索には日々不満があるので。
料理動画アプリ「クラシル」の検索について
検索仕事歴2年目のエンジニアの方のお話。
クラシルという、レシピ動画サイトの事例でした。
スライド:
https://twitter.com/818uuu/status/1121014158172938240
つかみの、検索専任の人はいなかったが、検索担当で入社する際に、入社する前にここ直したいぞノートを作ってた話が面白かったです。
クラシルの検索の不具合データを作成して、提出したらしい。
個人的に前から知っていた人だったが、その時にもすごい検索好きな人だったので検索への熱意が感じられました。
検索を良くするために、ひたすら熱意と運用でカバーするお話でした。
クラシルとは
レシピ動画数は、25000本以上
レシピ動画数世界No1料理動画サービス
辞書シノニムの問題
手動で設定できるツールが社内にあったそうで、毎日コツコツログを見て登録することで、検索離脱率が減少。
検索が目に見えて改善され、どこも苦労してる問題だが、いいことで、うれしい。
終りが見えない、運用運用運用。
とり胸肉だけでたくさん種類があり、レシピサイトだととにかくお肉に苦しめられるらしい。(鶏胸肉、鶏むね肉、鳥胸肉)
豆にも苦しめられるらしい。（えんどう豆、スナップエンドウ、さやいんげん）
どれがどう一緒なのかわからない
検索結果がない
2018年は、0件キーワードを100個以上削減対応したという。
チーズドッグなど、新生レシピもチェックしている。
検索体験向上し、チーズドッグ自体のたべれぽも伸びて、自分もユーザーもうれしい体験となったということです。
派生で、普段から食に関するリサーチをしていて、SNSで話題なものとかを調査している。
検索結果はあるけど、おかしいもの
0件に比べて難しい。
ここでは、"一人鍋" のキーワード例を取り上げて、改善前の検索結果として "スキレット鍋でビッグたこ焼き" など鍋じゃない結果が多かったそう。
改善後、"一人前のキムチ鍋" なども出るようにしたそう。
対応としては、オートコンプリート、検索人気キーワードの設置、検索から見えるユーザー行動の分析などがありそう。
クラシルならではの知見
食材クエリ、メニュークエリで離脱率は大きく異なる場合がある
- 肉じゃがは、必ず肉じゃが
- きゅうりは、その人によって浮かべているイメージが異なる
表示順序は、Google ほど強く相関せず、平日と土日で検索クエリの種類は変わるそう。
iOS/Androidでも検索クエリの種類は違うという話が面白かったです。
例えば、Android は節約系のレシピが人気らしい
テレビの影響が大きい
きくらげダイエット、テレビで紹介されてきくらげがすごい上がった
その他失敗例
検索ガイドラインをつくった
- Google の検索品質ガイドラインを真似たが、普及がうまくいかない、一人では評価の運用がそもそも困難
ロングテールの対応がむずい
- アクセス１のものに対してレシピを作るべきか
こういう検索の機能を作りたい
- 技術力がなくて失敗
- 風邪の時に食べたい
- のどが痛い時に食べたい
- 機械学習とかが必要？
社内に他の県作エンジニアがいない、立ち位置
- 検索エンジニアのキャリアパス
- すべての検索を一人でやることは不可能
いろいろな人が関わってる、地道にコツコツでも着実に良くなる、銀の弾丸はまだ手に入らない
質疑応答
検索離脱率 KPI => いまはちょっとちがう
作ったあとのフィードバックが大事、食べレポとか
検索、見つける => 食材を買う => 作る、なので一度セッションが切れる
全体的な感想
検索の汎用的な技術的な部分だけでなくて、実際の事例をもとにしたリアルな課題や工夫が聞けてとても良かった。
なかなか、検索の事例や工夫は、かなりそのサービスの根幹になっているものも多いので、対抗企業も多い中で公開するのは難しい部分もありそうだけど、もっとたくさんこういう事例が共有できる場があったらとても盛り上がると思う。
検索と一言でいっても、様々な例があって、全てに対応するようなものはやっぱり難しいよなぁとおもった。特に最後の例は、自分でも実際の検索の運用で体験したような話ばかりで、すごい共感を得られた。
話を聞いているだけで、自分のサービスにも適用できそうな工夫やアイデアが出てきたりするきっかけになるので、とても有益でした。