Search Engineering Newsletter vol.11
Search Engineering Newsletter vol.11
イチオシは、Elasticsearch 8.4から利用可能な近似近傍探索と従来の検索機能を組み合わせたハイブリッド検索 です。
Search
qdrant/quaterion: Blazing fast framework for fine-tuning similarity learning models
類似学習のための転移学習を高速に実現できるバッケージ。 PyTorch Lightning をベースに作られている。Qdrantという Rust製のニューラル検索エンジンを開発する企業が開発している。 Rustによる検索エンジンの再開発、盛り上がっていますね。 Qdrant - Benchmarks
Elasticsearch8系から近似近傍探索機能が利用可能になりましたが、従来の検索機能(term, fillterなど)と組み合わせることはできませんでしたが、Elasticsearch 8.4から待望の knnによる近似近傍探索と従来の検索を組み合わせたハイブリッド検索が可能になったので、その機能をドラえもんのひみつ道具をデータセットとして収集して検索エンジンアプリを公開してみました。 実際に近似近傍探索の現実的な適用例が爆発的に普及しそうです。 近似近傍探索の結果を特定のカテゴリで枝刈りするなどすればクオリティコントロール自体もブレークスルーが起きそうですね。
実は、GCP Matching Engine では近似近傍探索でフィルタリングなども可能なのだが、これはElasticsearch のような仕組みとは違いそうな気がする ベクトル一致をフィルタする | Vertex AI | Google Cloud また、ちょっと色が違いますが、近似近傍探索自体を部分集合に対して行いたいなどのモチベーションの研究はあり、東大の松井先生などが論文も出されています。 Reconfigurable Inverted Index
スタンバイにおける検索への取り組み - Stanby Tech Blog
求人検索を提供するスタンバイさんの検索エンジンがどのように構築されているかの記事。Yahoo Japan!さんと連携して検索エンジンを実装している模様。
Algolia vs Elasticsearch vs Meilisearch vs Typesense Comparison
Typesense というOSSの検索エンジンが紹介する検索エンジンの比較記事。 言わずもがなTypesense 推しではあるが、比較記事としては面白い。
【10X/M3/CADDi】検索エンジン運用勉強会 - connpass
10X, M3, CADDiさんらが共同で開催した検索エンジンの運用面に注目した勉強会。資料公開非常にありがたいです。
医者向けと患者向けで検索傾向や仕様が全く異なる中でElascitsearchを統合したお話。Sudachi の魅力的な機能が紹介されており使ってみたくなった。特に移行時のQAはこれはかなり茨の道なのでお疲れさまでしたとし言いようがない。また、@po3rin さんが自分でぶち当たった課題に対してツールを自分で作成して技術で殴るという姿勢が非常にかっこいいですね。
OpenSearchで実現する画像検索とテスト追加で目指す安定運用 - Speaker Deck
OpenSearch(AWSが主導で開発するElasticsearchをベースにした検索エンジン)の活用事例は国内で初めてみた気がします。選定理由としては、まずkNN(近似近傍探索ではなく、全探索)とフィルタリングの組み合わせが必須条件で、OpenSearch では2021年7月の時点で導入されていたからとのことです。Elasticsearch は2022年5月に8.2でサポート。
また、実際にぶち当たった問題など検索システム運用の奥深さが公開されていて読んでいて面白かったです。PM「ちょっと精度悪いんだけど?」の22pは、検索システムを運用していく上で、あるある過ぎて笑ってしまった。定量的指標で語り合うこと大事ですよね。
10Xの検索を10xしたい at 【10X/M3/CADDi】検索エンジン運用勉強会 - Speaker Deck
本番環境で自動mapping 使われている場合ってあるんだな?と自分は思ったが、実際みんな使うのだろうか? 怖くないかなと思ったり。ここは読者の方の反応が知りたい。ネットスーパーの検索システムは肝となる体験だと思うのでやりがいがありそう。
オンラインドキュメントと日本語全文検索 Rust製の検索エンジン Meilisearch を使って、Sphinx のドキュメントを日本語で全文検索可能にしたお話。こういう需要って多そうだけどサクッと実現できるようになったのは素晴らしいですね。例えば、前回紹介したお手軽な検索 API 構築 | メルカリエンジニアリングでも同じようなことは実現できそうです。
Amazon Search Query Understanding Page
Amazon 検索のQuery Understanding チームの成果と構成メンバーの公式サイト。 EC検索でQuery Understanding に興味がある場合は、Amazon の論文を参考にして間違いは無いので、気になったときに参照してみて下さい。
The Information Retrieval Anthology
情報検索関係の論文が集約されたサイト、情報検索の論文を探す場合まずはここから探してみるのが良さそうです。
放送レコメンド機能をTensorFlow Recommendersで作り、ABテストしてみた
GCPの機能をモリモリに使って、放送コンテンツの推薦をやってみたよという話。推薦システムをTensorFlow Recommenders で行っており、色々と現状の制約などを知れます。推薦システムを出すのがはじめての状況らしいですが、そこでちゃんとABテストで評価するという姿勢が良いですね(なぜならプロダクト開発の速度感の兼ね合いもあるので、いつABをやるべきなのかという意思決定は難しいので) 有意差は出なかったようですが、一度この仕組みを作ってしまえばABテストを実施する仕組みはできているので、得るものは大きそうです。
AI Platform Predictionでサービングしているモデル部分だけで、50パーセンタイルで600~700ms,95パーセンタイルで1000ms程度のレイテンシが発生しています。実際にクライアントアプリにおすすめセクションが表示されるまでにはバックエンド側で行っているフィルタリング処理にかかる時間も乗ってくるので、更に+αで時間がかかります。
とAI Platform Predictionのサービングの時間がなかなかにかかるので、もはやオンライン処理は諦めてバッチ処理にしたほうが良いのかなと思える速度ですね。 個人的にはもっと軽い仕組み(過去に視聴したカテゴリ、タグなどを推薦とか？)でパーソナライゼーションした場合のABテストを最初にやってみたほうが迅速に学びを得れるのではと感じました。
感想など
Twitter で #searchengineeringnewsletter のハッシュタグでつぶやいていただくか、Google フォーム での感想投稿をお待ちしております。 また、substack上でのコメントも歓迎しております。
それらのご感想は執筆の励みにさせていただきます。
もしよろしければ、Buy Me a Coffeeからサポート(投げ銭)していただけると、ニュースレター配信のモチベーションに繋がります✨