Elasticsearch と SigLIP-2 による山頂のマルチモーダル探索

ベクトル検索から強力なREST APIまで、Elasticsearchは開発者に最も広範な検索ツールキットを提供します。GitHubのサンプルノートブックにアクセスして新しいことを試してみましょう。また、無料トライアルを始めるか、ローカルでElasticsearchを実行することもできます。

写真アルバムを意味で検索したいと思ったことはありませんか?「青いジャケットを着てベンチに座っている写真を見せてください」「エベレストの写真を見せてください」「日本酒と寿司」などのクエリを試してみてください。コーヒー（またはお好みの飲み物）を飲みながら、読み続けてください。このブログでは、マルチモーダル ハイブリッド検索アプリケーションの構築方法を紹介します。マルチモーダルとは、アプリが単語だけでなく、テキスト、画像、音声などさまざまな種類の入力を理解して検索できることを意味します。ハイブリッドとは、キーワード マッチング、kNN ベクトル検索、ジオフェンシングなどの技術を組み合わせて、より鮮明な結果を提供することを意味します。

これを実現するために、Google の SigLIP-2 を使用して画像とテキストの両方のベクトル埋め込みを生成し、Elasticsearch ベクトル データベースに保存します。クエリ時に、検索入力、テキストまたは画像を埋め込みに変換し、高速 kNN ベクトル検索を実行して結果を取得します。この設定により、効率的なテキストから画像への検索、画像から画像への検索が可能になります。Streamlit UI は、テキストベースの検索を行ってアルバムから一致する写真を検索して表示するだけでなく、アップロードされた画像から山頂を識別し、フォトアルバムでその山の他の写真を表示できるフロントエンドを提供することで、このプロジェクトを実現します。また、検索精度を向上させるために実行した手順や、実用的なヒントやコツについても説明します。さらに詳しく調べるために、 GitHub リポジトリとColab ノートブックを提供しています。

始まり

このブログ投稿は、エベレストベースキャンプトレッキングで撮ったアマダブラム山の写真を全部見せてほしいと私に頼んだ10歳の子供からインスピレーションを受けたものです。写真アルバムを精査しながら、私は他のいくつかの山頂を特定するよう求められましたが、そのうちのいくつかは名前がわかりませんでした。

それで、これは楽しいコンピューター ビジョン プロジェクトになるかもしれないというアイデアが浮かびました。私たちが達成したかったこと:

• 山頂の写真を名前で検索する
• 画像から山頂の名前を推測し、写真アルバムで似たような山頂を見つける
• 概念クエリを機能させる（人、川、祈りの旗など）

ドリームチームを結成: SigLIP-2、Elasticsearch、Streamlit

これを機能させるには、テキスト (「Ama Dablam」) と画像 (私のアルバムの写真) の両方を、意味のある比較が可能なベクトル、つまり同じベクトル空間に変換する必要があることがすぐに明らかになりました。これを実行すると、検索は単に「最も近いものを見つける」だけになります。

最近 Google がリリースしたSigLIP-2はここによく当てはまります。タスク固有のトレーニング (ゼロショット設定) なしで埋め込みを生成でき、ラベルのない写真や異なる名前と言語を持つピークなど、私たちのユースケースに適しています。テキストと画像のマッチングがトレーニングされているため、クエリ言語やスペルが異なっていても、トレッキング中の山の写真と短いテキストプロンプトは埋め込みとして近いものになります。

SigLIP-2 は、品質と速度のバランスが優れており、複数の入力解像度をサポートし、CPU と GPU の両方で実行されます。SigLIP-2 は、オリジナルの CLIP などの以前のモデルと比較して、屋外での写真撮影に対してより堅牢になるように設計されています。私たちのテストでは、SigLIP-2 は一貫して信頼できる結果を生成しました。また、サポートも非常に充実しており、このプロジェクトに最適な選択肢となっています。

次に、埋め込みとパワー検索を保存するためのベクトル データベースが必要です。画像埋め込みに対するコサイン kNN 検索をサポートするだけでなく、単一のクエリでジオフェンスとテキスト フィルターを適用することもサポートする必要があります。Elasticsearch はここで最適です。ベクトル (dense_vector フィールドの HNSW kNN) を非常に適切に処理し、テキスト、ベクトル、地理クエリを組み合わせたハイブリッド検索をサポートし、フィルタリングと並べ替えをすぐに使用できます。また、水平方向にも拡張できるため、数枚の写真から数千枚の写真まで簡単に拡張できます。公式のElasticsearch Python クライアントは、配管をシンプルに保ち、プロジェクトときれいに統合します。最後に、検索クエリを入力して結果を表示できる軽量のフロントエンドが必要です。簡単な Python ベースのデモには、Streamlit が最適です。ファイルのアップロード、レスポンシブな画像グリッド、並べ替えとジオフェンシングのためのドロップダウン メニューなど、必要な基本的な機能を提供します。簡単にクローンを作成してローカルで実行でき、Colab ノートブックでも動作します。

実装

Elasticsearchのインデックス設計とインデックス戦略

このプロジェクトでは、 peaks_catalogとphotosの 2 つのインデックスを使用します。

Peaks_catalogインデックス

この索引は、エベレストベースキャンプトレッキング中に見える主要な山頂のコンパクトなカタログとして機能します。このインデックス内の各ドキュメントは、エベレスト山などの単一の山頂に対応しています。各山頂ドキュメントには、名前/エイリアス、オプションの緯度経度座標、および SigLIP-2 テキストプロンプト (+ オプションの参照画像) を組み合わせて構築された単一のプロトタイプ ベクトルが保存されます。

インデックスマッピング:

このインデックスは主に、画像から山頂を識別するなど、画像間の検索に使用されます。このインデックスは、テキストから画像への検索結果を強化するためにも使用されます。

要約すると、 peaks_catalogは「これは何の山ですか？」という質問を焦点を絞った最近傍問題に変換し、概念的理解を画像データの複雑さから効果的に分離します。

peaks_catalog インデックスのインデックス戦略: EBC トレッキング中に見える最も目立つ山頂のリストを作成することから始めます。各山頂の地理的位置、名前、同義語、標高をyaml ファイルに保存します。次のステップは、各ピークの埋め込みを生成し、それをtext_embedフィールドに保存することです。堅牢な埋め込みを生成するために、次の手法を使用します。

• 以下を使用してテキスト プロトタイプを作成します。
  • 山の名前
  • プロンプト アンサンブル(複数の異なるプロンプトを使用して同じ質問に答える)、例:
    • 「ネパール、ヒマラヤ山脈の山頂{name}の自然写真」
    • 「クンブ地域の{name}マーク的な山頂、高山の風景」
    • 「 {name}山頂、雪、岩だらけの尾根」
  • オプションの反概念（SigLIP-2 に一致しないものを指示する）: 「絵画、イラスト、ポスター、地図、ロゴ」の小さなベクトルを減算して、実際の写真に偏向させます。
• ピークの参照画像が提供されている場合は、オプションで画像プロトタイプを作成します。

次に、テキストと画像のプロトタイプをブレンドして、最終的な埋め込みを生成します。最後に、ドキュメントはすべての必須フィールドでインデックス化されます。

peaks_catalogインデックスからのサンプル ドキュメント:

写真インデックス

このプライマリ インデックスには、アルバム内のすべての写真に関する詳細情報が保存されます。各ドキュメントは 1 枚の写真を表し、次の情報が含まれています。

• フォトアルバム内の写真への相対パス。これを使用して、一致する画像を表示したり、検索 UI に画像を読み込んだりできます。
• 写真のGPSと時間情報。
• SigLIP-2 によって生成された画像エンコーディング用の密なベクトル。
• predicted_peaks ピーク名でフィルタリングできます。インデックスマッピング

写真インデックスのインデックス戦略:アルバム内の写真ごとに、次の操作を実行します。
画像メタデータから画像shot_timeとgps情報を抽出します。

• SigLIP-2 画像埋め込み: 画像をモデルに渡し、ベクトルを L2 正規化します。埋め込みをclip_imageフィールドに保存します。
• ピークを予測し、 predicted_peaksフィールドに保存します。これを行うには、まず前の手順で生成された写真の画像ベクトルを取得し、次にpeaks_catalogインデックスの text_embed フィールドに対して簡単な kNN 検索を実行します。上位 3 ～ 4 つのピークを保持し、残りは無視します。
• 画像名とパスのハッシュを実行して_idフィールドを計算します。これにより、複数回実行した後に重複が発生しなくなります。

写真のすべてのフィールドを決定したら、一括インデックスを使用して写真ドキュメントを一括でインデックスします。

写真インデックスからのサンプルドキュメント:

要約すると、写真のインデックスは、アルバム内のすべての写真を格納する、高速でフィルタリング可能な kNN 対応のストアです。マッピングは意図的に最小限に抑えられており、すばやく取得し、きれいに表示し、結果を空間と時間で分割するのに十分な構造になっています。このインデックスは、両方の検索ユースケースに対応します。両方のインデックスを作成するための Python スクリプトはここにあります。

以下の Kibana マップの視覚化では、写真アルバムのドキュメントが緑のドットで表示され、 peaks_catalogインデックスの山頂が赤い三角形で表示されています。緑のドットはエベレスト ベース キャンプのトレッキング トレイルとぴったり一致しています。

検索ユースケース

名前による検索（テキストから画像へ）：この機能により、ユーザーはテキスト クエリを使用して山頂の写真（さらには「祈りの旗」のような抽象的な概念）を見つけることができます。これを実現するために、テキスト入力は SigLIP-2 を使用してテキスト ベクトルに変換されます。堅牢なテキストベクトル生成のために、 インデックスでテキスト埋め込みを作成するために使用したのと同じ戦略を採用しています。つまり、テキスト入力を小さなpeaks_catalog プロンプトアンサンブル と 組み合わせ 、小さな 反概念ベクトル を減算し、 L2正規化 を適用して最終的なクエリベクトルを生成します。次に、 photos.clip_imageフィールドで kNNクエリを実行し、コサイン類似度に基づいて一致する上位のピークを取得して、最も近い画像を見つけます。オプションとして、クエリの一部として地理および日付フィルター、および/またはphotos.predicted_peaks用語フィルターを適用することで、検索結果の関連性を高めることができます (以下のクエリ例を参照)。これにより、トレッキング中に実際には見えていない、似たような山頂を除外することができます。

ジオフィルターを使用した Elasticsearch クエリ:

画像による検索 (画像間):この機能を使用すると、写真内の山を識別し、写真アルバム内で同じ山の他の画像を見つけることができます。画像がアップロードされると、SigLIP-2 画像エンコーダーによって処理され、画像ベクトルが生成されます。次に、 peaks_catalog.text_embedフィールドでkNN 検索を実行し、最も一致するピーク名を特定します。次に、これらの一致するピーク名からテキスト ベクトルが生成され、写真インデックスに対して別のkNN 検索が実行され、対応する写真が検索されます。

Elasticsearchクエリ:

ステップ1: 一致するピーク名を見つける

ステップ 2: photosインデックスで検索を実行し、一致する画像を見つけます (テキストから画像への検索ユース ケースに示されているのと同じクエリ)。

流線型のUI

すべてをまとめるために、両方の検索ユースケースを実行できるシンプルな Streamlit UI を作成しました。左側のレールには、チェックボックスとミニマップ/ジオフィルターが付いた、スクロール可能なピークのリスト（ photos.predicted_peaksから集約）が表示されます。上部には、名前による検索ボックスと写真アップロードからの識別ボタンがあります。中央のペインには、kNN スコア、予測ピーク バッジ、キャプチャ時間を表示するレスポンシブなサムネイル グリッドがあります。各画像には、フル解像度のプレビューを表示するための画像表示ボタンが含まれています。

画像をアップロードして検索:ピークを予測し、写真アルバムから一致するピークを見つけます。

テキスト検索: アルバム内の一致するピークをテキストから検索します

まとめ

アマ・ダブラムの 写真 だけ見せてもらえませんか ？ というところから始まりました。小規模で実用的なマルチモーダル検索システムになりました。私たちは生のトレッキング写真を撮影し、それをSigLIP-2 埋め込みに変換し、 Elasticsearchを使用してベクトルに対して高速kNN を実行し、さらに単純な地理/時間フィルターを使用して意味によって適切な画像を浮かび上がらせました。途中で、私たちは 2 つのインデックス、つまり混合プロトタイプの小さなpeaks_catalog (識別用) と、画像ベクトルと EXIF のスケーラブルなphotosインデックス (検索用) で関心を分離しました。実用的かつ再現性があり、拡張も簡単です。

調整したい場合は、いくつかの設定を試すことができます。

• クエリ時間の設定: k (返す近隣の数) とnum_candidates (最終スコアリングの前に検索する範囲)。これらの設定については、こちらのブログで説明されています。
• インデックス時間の設定: m (グラフの接続性) およびef_construction (ビルド時間の精度とメモリ)。クエリの場合は、 ef_searchも試してください。値が大きいほど、通常は、レイテンシを多少トレードオフして、リコール率が向上します。これらの設定の詳細については、このブログを参照してください。

今後、マルチモーダルおよび多言語検索用のネイティブモデル/リランカーがElasticエコシステムにまもなく導入される予定です。これにより、画像/テキスト検索とハイブリッドランキングがさらに強化されるはずです。ir.elastic.co+1

これを自分で試してみたい場合は:

• GitHub リポジトリ: https://github.com/navneet83/multimodal-mountain-peak-search
• Colab クイックスタート: https://github.com/navneet83/multimodal-mountain-peak-search/blob/main/notebooks/multimodal_mountain_peak_search.ipynb

これで私たちの旅は終わり、帰る時間になりました。これが役に立つことを願っています。これを壊した場合（または改善した場合）、何を変更したかをお聞かせください。