Python - Elasticsearch Labs

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

Navneet Kumar — Tue, 04 Nov 2025 00:00:00 GMT

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

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

始まり

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

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

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

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

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

画像の埋め込みを生成するために、多言語ビジョン言語エンコーダーを使用します。これにより、山の写真と「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 テキストプロンプト (+ オプションの参照画像) を組み合わせて構築された単一のプロトタイプベクトルが保存されます。

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

分野

タイプ

例

目的/注意事項

ベクトル/インデックス

キーワード

アマ・ダブラム

安定したスラッグ/ID

—

名前

テキスト + キーワードサブフィールド

["アマ・ダブラム"、"アマダブラム"]

エイリアス/多言語名; 正確なフィルターのためのnames.raw

—

ラトロン

ジオポイント

{"lat":27.8617,"lon":86.8614}

緯度/経度の組み合わせによるピーク GPS 座標 (オプション)

—

高度m

整数

6812

標高（オプション）

—

テキスト埋め込み

dense_vector

768

このピークのブレンドプロトタイプ（プロンプトとオプションで1～3枚の参照画像）

index:true、類似度:"cosine"、index_options: {type:"hnsw", m:16, ef_construction:128}

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

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

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

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

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

def l2norm(v: np.ndarray) -> np.ndarray: return v / (np.linalg.norm(v) + 1e-12) def compute_blended_peak_vec( emb: Siglip2, names: List[str], peak_id: str, peaks_images_root: str, alpha_text: float = 0.5, max_images: int = 3, ) -> Tuple[np.ndarray, int, int, List[str]]: """ Build blended vector for a single peak. Returns: vec : np.ndarray (L2-normalized) found_count : number of reference images discovered used_count : number of references used (<= max_images) used_filenames: list of filenames used (for logging) """ # 1) TEXT vector tv = embed_text_blend(emb, names) # 2) IMAGE refs: prefer folder by id; fallback to slug of the primary name root = Path(peaks_images_root) candidates = [root / peak_id] if names: candidates.append(root / slugify(names[0])) all_refs: List[Path] = [] for c in candidates: if c.exists() and c.is_dir(): all_refs = list_ref_images(c) if all_refs: break found = len(all_refs) used_list = all_refs[:max_images] if (max_images and found > max_images) else all_refs used = len(used_list) img_v = embed_image_mean(emb, used_list) if used_list else None # 3) Blend TEXT and IMAGE vectors, clamp alpha to [0,1] a = max(0.0, min(1.0, float(alpha_text))) vec = l2norm(tv if img_v is None else (a * tv + (1.0 - a) * img_v)).astype("float32") return vec, found, used, [p.name for p in used_list]

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

写真インデックス

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

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

分野

タイプ

例

目的/注意事項

ベクター / インデックス

パス

キーワード

データ/画像/IMG_1234.HEIC

UI でサムネイル/フル画像を開く方法

—

クリップ画像

dense_vector

768

SigLIP-2画像埋め込み

index:true、類似度:"cosine"、index_options: {type:"hnsw", m:16, ef_construction:128}

予測ピーク

キーワード

["ama-dablam","pumori"]

インデックス時の上位Kの推測（安価なUXフィルター/ファセット）

—

GPS

ジオポイント

{"lat":27.96,"lon":86.83}

地理フィルターを有効にする

—

ショット時間

date

2023年10月18日09:41:00Z

撮影時間: 並べ替え/フィルター

—

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

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

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

def bulk_index_photos( es: Elasticsearch, images_root: str, photos_index: str = "photos", peaks_index: str = "peaks_catalog", topk_predicted: int = 5, batch_size: int = 200, refresh: str = "false", ) -> None: """Walk a folder of images, embed + enrich, and bulk index to Elasticsearch.""" root = Path(images_root) if not root.exists(): raise SystemExit(f"Images root not found: {images_root}") emb = Siglip2() batch: List[Dict[str, Any]] = [] n_indexed = 0 for p in iter_images(root): rel = relpath_within(root, p) _id = id_for_path(rel) # 1) Image embedding (and reuse it for predicted_peaks) try: with Image.open(p) as im: ivec = emb.image_vec(im.convert("RGB")).astype("float32") except (UnidentifiedImageError, OSError) as e: print(f"[skip] {rel} — cannot embed: {e}") continue # 2) Predict top-k peak names try: top_names = predict_peaks(es, ivec.tolist(), peaks_index=peaks_index, k=topk_predicted) except Exception as e: print(f"[warn] predict_peaks failed for {rel}: {e}") top_names = [] # 3) EXIF enrichment (safe) gps = get_gps_decimal(str(p)) shot = get_shot_time(str(p)) # 4) Build doc and stage for bulk doc = {"path": rel, "clip_image": ivec.tolist(), "predicted_peaks": top_names} if gps: doc["gps"] = gps if shot: doc["shot_time"] = shot batch.append( {"_op_type": "index", "_index": photos_index, "_id": _id, "_source": doc} ) # 5) Periodic flush if len(batch) >= batch_size: helpers.bulk(es, batch, refresh=refresh) n_indexed += len(batch) print(f"[photos] indexed {n_indexed} (last: {rel})") batch.clear() # Final flush if batch: helpers.bulk(es, batch, refresh=refresh) n_indexed += len(batch) print(f"[photos] indexed {n_indexed} total.") print("[done] photos indexing")

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

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

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

検索ユースケース

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

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

POST photos/_search { "knn": { "field": "clip_image", "query_vector": [ ... ], "k": 60, "num_candidates": 2000 }, "query": { "bool": { "filter": [ { "geo_bounding_box": { "gps": { "top_left": "...", "bottom_right": "..." } } } ] } }, "_source": ["path","predicted_peaks","gps","shot_time"] } Response (first two documents): { "hits": { "total": { "value": 56, "relation": "eq" }, "max_score": 0.5779596, "hits": [ { "_index": "photos", "_id": "d01da3a1141981486c3493f6053c79e92a788463", "_score": 0.5779596, "_source": { "path": "IMG_2738.HEIC", "predicted_peaks": [ "Pumori", "Kyajo Ri", "Khumbila", "Nangkartshang", "Kongde Ri" ], "gps": { "lat": 27.97116388888889, "lon": 86.82331111111111 }, "shot_time": "2023-11-03T08:07:13" } }, { "_index": "photos", "_id": "c79d251f07adc5efaedc53561110a7fd78e23914", "_score": 0.5766071, "_source": { "path": "IMG_2761.HEIC", "predicted_peaks": [ "Kyajo Ri", "Makalu", "Baruntse", "Cho Oyu", "Khumbila" ], "gps": { "lat": 27.975558333333332, "lon": 86.82515 }, "shot_time": "2023-11-03T08:51:08" } } }

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

Elasticsearchクエリ:

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

GET peaks_catalog/_search { "knn": { "field": "text_embed", "query_vector": [...image-vector... ], "k": 3, "num_candidates": 500 }, "_source": [ "id", "names", "latlon", "text_embed" ] } Response (first two documents): { "took": 2, "timed_out": false, "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 3, "relation": "eq" }, "max_score": 0.58039916, "hits": [ { "_index": "peaks_catalog", "_id": "pumori", "_score": 0.58039916, "_source": { "id": "pumori", "names": [ "Pumori", "Pumo Ri" ], "latlon": { "lat": 28.01472, "lon": 86.82806 }, "text_embed": [ ... embeddings... ] } }, { "_index": "peaks_catalog", "_id": "kyajo-ri", "_score": 0.57942784, "_source": { "id": "kyajo-ri", "names": [ "Kyajo Ri", "Kyazo Ri" ], "latlon": { "lat": 27.909167, "lon": 86.673611 }, "text_embed": [ ... embeddings... ] } } ] } }

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

POST photos/_search { "knn": { "field": "clip_image", "query_vector": [ ...image-vector... ], "k": 30, "num_candidates": 2000 }, "_source": [ "path", "gps", "shot_time", "predicted_peaks", "clip_image" ], "query": { "bool": { "filter": [ { "term": { "predicted_peaks": "Pumori" } } ] } } } Response (first two documents): { "hits": { "total": { "value": 56, "relation": "eq" }, "max_score": 0.5779596, "hits": [ { "_index": "photos", "_id": "d01da3a1141981486c3493f6053c79e92a788463", "_score": 0.5779596, "_source": { "path": "IMG_2738.HEIC", "predicted_peaks": [ "Pumori", "Kyajo Ri", "Khumbila", "Nangkartshang", "Kongde Ri" ], "gps": { "lat": 27.97116388888889, "lon": 86.82331111111111 }, "shot_time": "2023-11-03T08:07:13" } }, { "_index": "photos", "_id": "c79d251f07adc5efaedc53561110a7fd78e23914", "_score": 0.5766071, "_source": { "path": "IMG_2761.HEIC", "predicted_peaks": [ "Kyajo Ri", "Makalu", "Baruntse", "Cho Oyu", "Khumbila" ], "gps": { "lat": 27.975558333333332, "lon": 86.82515 }, "shot_time": "2023-11-03T08:51:08" } } }

流線型の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

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

ユーザー行動データに基づく判断リストを使用して Elasticsearch で LTR モデルをトレーニングする

Alexander Dávila — Wed, 15 Oct 2025 00:00:00 GMT

ランク付け学習モデルを使用する際の大きな課題は、モデルをトレーニングするための高品質の判断リストを作成することです。従来、このプロセスでは、クエリとドキュメントの関連性を手動で評価し、それぞれにグレードを割り当てていました。これは、拡張性が低く、維持が困難な、時間のかかるプロセスです (数百のエントリを含むリストを手動で更新する必要があることを想像してください)。

さて、検索アプリケーションでの実際のユーザーインタラクションを使用してこのトレーニングデータを作成できたらどうなるでしょうか?UBIデータを使用すると、まさにそれが実現できます。検索、クリック、その他のインタラクションをキャプチャして使用し、判断リストを生成できる自動システムを作成します。このプロセスは、手動による操作よりもはるかに簡単に拡張および繰り返すことができ、より良い結果が得られる傾向があります。このブログでは、Elasticsearch に保存されている UBI データをクエリして意味のある信号を計算し、 LTRモデルのトレーニングデータセットを生成する方法について説明します。

完全な実験は ここで ご覧いただけます。

UBIデータがLTRモデルのトレーニングに役立つ理由

UBI データには、手動による注釈に比べていくつかの利点があります。

量: UBI データは実際のやり取りから得られるため、手動で生成できるよりもはるかに多くのデータを収集できます。もちろん、このデータを生成するのに十分なトラフィックがあることを前提としています。
実際のユーザーの意図:従来、手動の判断リストは、利用可能なデータの専門家による評価から作成されます。一方、UBI データは実際のユーザー行動を反映しています。これは、何が関連しているべきかという理論的な仮定ではなく、ユーザーが実際にコンテンツとやりとりして価値を見出す方法に基づいているため、検索システムの精度を向上させる、より優れたトレーニングデータを生成できることを意味します。
継続的な更新:判断リストは時間の経過とともに更新する必要があります。UBI データから作成すれば、最新のデータが得られ、判断リストが更新されます。
コスト効率:判断リストを手動で作成するオーバーヘッドがないため、プロセスを何度でも効率的に繰り返すことができます。
自然なクエリ分布: UBI データは実際のユーザークエリを表し、より深い変化を促すことができます。たとえば、ユーザーはシステム内で検索する際に自然言語を使用しているでしょうか?もしそうなら、セマンティック検索またはハイブリッド検索アプローチを実装する必要があるかもしれません。

ただし、いくつかの警告も伴います。

バイアスの増幅:人気のあるコンテンツは、露出が増えるため、クリックされる可能性が高くなります。そのため、人気のあるアイテムが強調され、より良い選択肢が埋もれてしまう可能性があります。
カバレッジが不完全:新しいコンテンツにはインタラクションがないため、結果の上位に表示されることは難しい可能性があります。まれなクエリでは、意味のあるトレーニングデータを作成するのに十分なデータポイントが不足している場合もあります。
季節的な変動:ユーザーの行動が時間の経過とともに劇的に変化することが予想される場合、履歴データからは、どのような結果が適切であるかについてあまり情報が得られない可能性があります。
タスクの曖昧さ:クリックしても、ユーザーが探していたものが見つかるとは限らない。

成績計算

LTRトレーニングのグレード

LTR モデルをトレーニングするには、ドキュメントがクエリにどの程度関連しているかを数値で表現する必要があります。私たちの実装では、この数値は 0.0 から 5.0+ までの連続したスコアであり、スコアが高いほど関連性が高くなります。

この評価システムがどのように機能するかを示すために、手動で作成された次の例を考えてみましょう。

クエリ

文書の内容

学年

説明

「最高のピザレシピ」

「本格的なイタリアンピザ生地のレシピ（写真付きステップバイステップ）」

4.0

関連性が高く、まさにユーザーが探しているもの

「最高のピザレシピ」

「イタリアのピザの歴史」

1.0

ピザに関する内容ですが、レシピではありません

「最高のピザレシピ」

「初心者向け15分でできる簡単ピザレシピ」

3.0

関連性があり、良い結果ですが、「最高」のレシピとは言えないかもしれません。

「最高のピザレシピ」

「車のメンテナンスガイド」

0.0

全く関係ありません。クエリとは全く関係ありません。

ここからわかるように、グレードは、ドキュメントが「最高のピザのレシピ」というサンプルクエリにどれだけ関連しているかを数値で表したものです。これらのスコアを使用して、LTR モデルはどのドキュメントを結果の上位に表示する必要があるかを学習できます。

成績の計算方法は、トレーニングデータセットの中核です。これを行うには複数のアプローチがあり、それぞれに長所と短所があります。たとえば、関連性がある場合は 1、関連性がない場合は 0 というバイナリスコアを割り当てたり、クエリごとに結果のドキュメントのクリック数をカウントしたりすることもできます。

このブログ投稿では、ユーザーの行動を入力として考慮し、グレード番号を出力として計算する、異なるアプローチを使用します。また、ドキュメントの関連性に関係なく、検索結果の上位の方がクリックされる傾向があるという事実から生じる可能性のあるバイアスも修正します。

成績の計算 - COECアルゴリズム

COEC ( Clicks over Expected Clicks ) アルゴリズムは、ユーザーのクリックから判断グレードを計算する手法です。前述したように、ユーザーは、ドキュメントがクエリに最も関連していない場合でも、上位に表示された結果をクリックする傾向があります。これは、ポジションバイアスと呼ばれます。COEC アルゴリズムを使用する際の基本的な考え方は、すべてのクリックが同等に重要であるわけではないということです。つまり、位置 10 のドキュメントをクリックすると、位置 1 のドキュメントをクリックするよりも、そのドキュメントがクエリとの関連性がはるかに高いことを示します。COEC アルゴリズムに関する研究論文 (上記リンク) を引用します。

「検索結果や広告のクリック率（CTR）は、検索結果の順位によって大幅に低下することがよく知られています。」

ポジションバイアスの詳細については、こちらをご覧ください。

COEC アルゴリズムを使用してこれに対処するには、次の手順に従います。

1. 位置のベースラインを確立する:検索位置ごとに 1 から 10 までのクリック率 (CTR) を計算します。つまり、通常、ユーザーの何パーセントが位置 1、位置 2 などをクリックするかを決定します。このステップでは、ユーザーの自然な位置の偏りを捉えます。CTR は次のように計算します。

どこ：

p = 位置。1から10まで Cp = すべてのクエリにおける位置pでの合計クリック数（任意のドキュメント） Ip = 総表示回数: すべてのクエリで、任意のドキュメントが位置 p に表示された回数

ここでは、上位の順位の方がクリック数が多くなると予想されます。

2.予想クリック数（EC）を計算する:

この指標は、ドキュメントが表示された位置とその位置のCTRに基づいて、ドキュメントが「受け取るべき」クリック数を決定します。ECは次の方法で計算します。

どこ：

Qd = 文書dが出現したすべてのクエリ pos(d,q) = クエリqの結果における文書dの位置

3.実際のクリック数をカウントする:ドキュメントが表示されたすべてのクエリでドキュメントが受け取った実際の合計クリック数をカウントします。以降、 A(d) と呼びます。

4. COECスコアを計算します。これは、実際のクリック数（A(d)）と予想クリック数（EC(d)）の比率です。

このメトリックは、次のように位置バイアスを正規化します。

スコア 1.0 は、ドキュメントが表示された位置に応じて、期待どおりに実行されたことを意味します。
スコアが 1.0 を超える場合、ドキュメントの位置を見ると予想よりもパフォーマンスが優れていることを意味します。したがって、このドキュメントはクエリに対してより関連性があります。
スコアが 1.0 未満の場合、ドキュメントの位置から判断すると、予想よりもパフォーマンスが悪かったことを意味します。したがって、このドキュメントはクエリとの関連性が低くなります。

最終結果は、検索システムとの実際のやりとりから抽出された位置ベースの期待を考慮して、ユーザーが探しているものを捉えたグレード番号になります。

技術的な実装

LTR モデルをトレーニングするための判断リストを作成するスクリプトを作成します。

このスクリプトの入力は、Elastic でインデックス化された UBI データ (クエリとイベント) です。

出力は、COEC アルゴリズムを使用してこれらの UBI ドキュメントから生成された CSV ファイル内の判断リストです。この判断リストをElandで使用すると、関連する特徴を抽出し、LTR モデルをトレーニングできます。

クイックスタート

このブログのサンプルデータから判断リストを生成するには、次の手順に従います。

1. リポジトリをクローンします。

git clone https://github.com/Alex1795/elastic-ltr-judgement_list-blog.git cd elastic-ltr-judgement_list-blog

2. 必要なライブラリをインストールする

このスクリプトには、次のライブラリが必要です。

pandas : 判定リストを保存する
elasticsearch : ElasticデプロイメントからUBIデータを取得する

Python 3.11も必要です

pip install -r requirements.txt

3. .envファイルでElasticデプロイメントの環境変数を更新します。

ES_ホスト
API_キー

環境変数を追加するには、次を使用します。

source .env

4. ubi_queries、ubi_events インデックスを作成し、サンプルデータをアップロードします。setup.py ファイルを実行します。

python setup.py

5. Python スクリプトを実行します。

python judgement_list-generator.py

これらの手順に従うと、次のような judgement_list.csv という新しいファイルが表示されます。

このスクリプトは、以下に示すcalculate_relevance_grade()関数を使用して、前に説明した COEC アルゴリズムを適用して成績を計算します。

データアーキテクチャ

Ubiクエリ

UBI クエリインデックスには、検索システムで実行されたクエリに関する情報が含まれています。これはサンプルドキュメントです:

{ "client_id": "client_002", "query": "italian pasta recipes", "query_attributes": { "search_type": "recipe", "category": "food", "cuisine": "italian" }, "query_id": "q002", "query_response_id": "qr002", "query_response_object_ids": [ "doc_011", "doc_012", "doc_013", "doc_014", "doc_015", "doc_016", "doc_017", "doc_018", "doc_019", "doc_020" ], "timestamp": "2024-08-14T11:15:00Z", "user_query": "italian pasta recipes" }

ここでは、ユーザー（client_id）、クエリの結果（query_response_object_ids）、クエリ自体（timestamp、user_query）のデータを見ることができます。

Ubiクリックイベント

ubi_events インデックスには、ユーザーが結果内のドキュメントをクリックするたびに収集されたデータが含まれています。これはサンプルドキュメントです:

{ "action_name": "click", "application": "recipe_search", "client_id": "client_001", "event_attributes": { "object": { "description": "Authentic Italian Pizza Dough Recipe with Step-by-Step Photos", "device": "desktop", "object_id": "doc_001", "position": { "ordinal": 1, "page_depth": 1 }, "user": { "city": "New York", "country": "USA", "ip": "192.168.1.100", "location": { "lat": 40.7128, "lon": -74.006 }, "region": "NY" } } }, "message": "User clicked on document doc_001", "message_type": "click", "query_id": "q001", "timestamp": "2024-08-14T10:31:00Z", "user_query": "best pizza recipe" }

判定リスト生成スクリプト

スクリプトの一般的な概要

このスクリプトは、Elasticsearch に保存されているクエリとクリックイベントからの UBI データを使用して、判断リストの生成を自動化します。次のタスクを実行します:

Elasticsearch で UBI データを取得して処理します。
UBI イベントをそのクエリと関連付けます。
各位置の CTR を計算します。
各ドキュメントの予想クリック数 (EC) を計算します。
各ドキュメントの実際のクリック数をカウントします。
各クエリとドキュメントのペアの COEC スコアを計算します。
判定リストを生成し、CSVファイルに書き込みます。

それぞれの機能を見ていきましょう。

connect_to_elasticsearch()

def connect_to_elasticsearch(host, api_key): """Create and return Elasticsearch client""" try: es = Elasticsearch( hosts=[host], api_key=api_key, request_timeout=60 ) # Test the connection if es.ping(): print(f"✓ Successfully connected to Elasticsearch at {host}") return es else: print("✗ Failed to connect to Elasticsearch") return None except Exception as e: print(f"✗ Error connecting to Elasticsearch: {e}") return None

この関数は、ホストと API キーを使用して Elasticsearch クライアントオブジェクトを返します。

fetch_ubi_data()

def fetch_ubi_data(es_client: Elasticsearch, queries_index: str, events_index: str, size: int = 10000) -> Tuple[List[Dict], List[Dict]]: """ Fetch UBI queries and events data from Elasticsearch indices. Args: es_client: Elasticsearch client queries_index: Name of the UBI queries index events_index: Name of the UBI events index size: Maximum number of documents to fetch Returns: Tuple of (queries_data, events_data) """ logger.info(f"Fetching data from {queries_index} and {events_index}") # Fetch queries with error handling try: queries_response = es_client.search( index=queries_index, body={ "query": {"match_all": {}}, "size": size } ) queries_data = [hit['_source'] for hit in queries_response['hits']['hits']] logger.info(f"Fetched {len(queries_data)} queries") except Exception as e: logger.error(f"Error fetching queries from {queries_index}: {e}") raise # Fetch events (only click events for now) with error handling try: events_response = es_client.search( index=events_index, body={ "query": { "term": {"message_type.keyword": "CLICK_THROUGH"} }, "size": size } ) events_data = [hit['_source'] for hit in events_response['hits']['hits']] logger.info(f"Fetched {len(events_data)} click events") except Exception as e: logger.error(f"Error fetching events from {events_index}: {e}") raise logger.info(f"Data fetch completed successfully - Queries: {len(queries_data)}, Events: {len(events_data)}") return queries_data, events_data

この関数はデータ抽出レイヤーであり、Elasticsearch に接続して match_all クエリを使用して UBI クエリを取得し、UBI イベントをフィルタリングして 'CLICK_THROUGH' イベントのみを取得します。

プロセスubi_data()

def process_ubi_data(queries_data: List[Dict], events_data: List[Dict]) -> pd.DataFrame: """ Process UBI data and generate judgment list. Args: queries_data: List of query documents from UBI queries index events_data: List of event documents from UBI events index Returns: DataFrame with judgment list (qid, docid, grade, keywords) """ logger.info("Processing UBI data to generate judgment list") # Group events by query_id clicks_by_query = {} for event in events_data: query_id = event['query_id'] if query_id not in clicks_by_query: clicks_by_query[query_id] = {} # Extract clicked document info object_id = event['event_attributes']['object']['object_id'] position = event['event_attributes']['object']['position']['ordinal'] clicks_by_query[query_id][object_id] = { 'position': position, 'timestamp': event['timestamp'] } judgment_list = [] # Process each query for query in queries_data: query_id = query['query_id'] user_query = query['user_query'] document_ids = query['query_response_object_ids'] # Get clicks for this query query_clicks = clicks_by_query.get(query_id, {}) # Generate judgment for each document shown for doc_id in document_ids: grade = calculate_relevance_grade(doc_id, query_clicks, document_ids, queries_data, events_data) judgment_list.append({ 'qid': query_id, 'docid': doc_id, 'grade': grade, 'query': user_query }) df = pd.DataFrame(judgment_list) logger.info(f"Generated {len(df)} judgment entries for {df['qid'].nunique()} unique queries") return df

この関数は判定リストの生成を処理します。UBI イベントとクエリを関連付けることで、UBI データの処理を開始します。次に、ドキュメントとクエリのペアごとに calculate_relevance_grade() 関数を呼び出して、判断リストのエントリを取得します。最後に、結果のリストを pandas データフレームとして返します。

判断統計を生成する()

def generate_judgment_statistics(df: pd.DataFrame) -> Dict: """Generate statistics about the judgment list.""" stats = { 'total_judgments': len(df), 'unique_queries': df['qid'].nunique(), 'unique_documents': df['docid'].nunique(), 'grade_distribution': df['grade'].value_counts().to_dict(), 'avg_judgments_per_query': len(df) / df['qid'].nunique() if df['qid'].nunique() > 0 else 0, 'queries_with_clicks': len(df[df['grade'] > 1]['qid'].unique()), 'click_through_rate': len(df[df['grade'] > 1]) / len(df) if len(df) > 0 else 0 } return stats

判定リストから、合計クエリ数、合計ユニークドキュメント数、グレード分布などの有用な統計情報を生成します。これは純粋に情報提供であり、結果の判断リストは変更されません。

結果と影響

クイックスタートセクションの指示に従うと、320 エントリの判定リストを含む CSV ファイルが生成されます (リポジトリでサンプル出力を確認できます)。これらのフィールド:

qid: クエリの一意のID
docid: 結果のドキュメントの一意の識別子
グレード: クエリとドキュメントのペアの計算されたグレード
クエリ: ユーザークエリ

「イタリア料理のレシピ」というクエリの結果を見てみましょう。

クイド

ドシド

学年

クエリ

q1-イタリア料理レシピ

パスタの基本レシピ

0.0

イタリアのレシピ

q1-イタリア料理レシピ

レシピ_ピザ_マルゲリータ

3.333333

イタリアのレシピ

q1-イタリア料理レシピ

レシピ_リゾット_ガイド

10.0

イタリアのレシピ

q1-イタリア料理レシピ

レシピ_フレンチ_クロワッサン

0.0

イタリアのレシピ

q1-イタリア料理レシピ

レシピ_スペイン_パエリア

0.0

イタリアのレシピ

q1-イタリア料理レシピ

ギリシャ風ムサカのレシピ

1.875

イタリアのレシピ

結果から、「イタリアのレシピ」というクエリに対して次のことがわかります。

リゾットのレシピは間違いなくクエリに対する最高の結果であり、予想よりも10倍多くのクリックを獲得しています。
ピザマルゲリータも素晴らしい出来栄えです。
ギリシャのムサカも（意外にも）良い結果であり、結果上の順位が示唆するよりも良い成績を残しています。これは、イタリア料理のレシピを探していた数人のユーザーが、代わりにこのレシピに興味を持ったことを意味します。おそらくこれらのユーザーは地中海料理全般に興味があるのでしょう。結局のところ、このことからわかるのは、これは上で説明した他の 2 つの「より良い」一致の下に表示される良い結果になる可能性があるということです。

まとめ

UBI データを使用すると、LTR モデルのトレーニングを自動化し、独自のユーザーから高品質の判断リストを作成できます。UBI データは、検索システムがどのように使用されているかを反映する大きなデータセットを提供します。COEC アルゴリズムを使用して成績を生成することで、固有の偏りを考慮しながら、同時にユーザーがより良い結果と考えるものを反映します。ここで概説した方法は、実際のユースケースに適用でき、実際の使用傾向に合わせて進化する、より優れた検索エクスペリエンスを提供できます。

ES|QL を使用した Elasticsearch 地理空間検索

Craig Taverner — Mon, 12 Aug 2024 00:00:00 GMT

Elasticsearch は長年にわたって強力な地理空間検索および分析機能を提供してきましたが、その API は一般的な GIS ユーザーが使い慣れたものとはまったく異なっていました。過去 1 年間で、SQL と同じくらい、あるいは SQL よりも簡単なパイプクエリ言語である ES|QL クエリ言語を追加しました。これは、Elastic が得意とする検索、セキュリティ、可観測性のユースケースに特に適しています。また、ES|QL 内での地理空間検索と分析のサポートも追加されており、特に SQL またはGISコミュニティ出身のユーザーにとって、はるかに使いやすくなります。

Elasticsearch 8.12 および 8.13 では、ES|QL に地理空間タイプの基本サポートが導入されました。これは、8.14 で地理空間検索機能が追加されたことにより大幅に強化されました。さらに重要なことは、このサポートは、PostGIS などの他の空間データベースで使用されている Open Geospatial Consortium (OGC) の Simple Feature Access 標準に厳密に準拠するように設計されているため、これらの標準に精通している GIS 専門家にとって非常に使いやすくなっていることです。

このブログでは、ES|QL を使用して地理空間検索を実行する方法と、それを SQL およびクエリ DSL と同等の機能と比較する方法を紹介します。また、ES|QL を使用して空間結合を実行する方法と、結果を Kibana Maps で視覚化する方法も紹介します。ここで説明する機能はすべて「テクニカルプレビュー」段階であるため、改善方法について皆様からのフィードバックをお待ちしています。

地理空間データの検索

クエリの例から始めましょう:

FROM airport_city_boundaries | WHERE ST_INTERSECTS( city_boundary, "POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))"::geo_shape ) | KEEP abbrev, airport, region, city, city_location

これは、三亜鳳凰国際空港 (SYX) の周囲の長方形の検索ポリゴンと交差する都市境界ポリゴンの検索を実行します。

空港、都市、都市境界のサンプルデータセットでは、この検索により交差するポリゴンが検索され、一致するドキュメントから必要なフィールドが返されます。

略語

空港

地域

市

都市の場所

シックス

三亜フェニックス国際空港

天外区

三亜

点(109.5036 18.2533)

簡単でした！次に、同じクエリの従来の Elasticsearch クエリ DSL と比較してみましょう。

GET /airport_city_boundaries/_search { "_source": ["abbrev", "airport", "region", "city", "city_location"], "query": { "geo_shape": { "city_boundary": { "shape": { "type": "polygon", "coordinates" : [[ [109.4, 18.1], [109.6, 18.1], [109.6, 18.3], [109.4, 18.3], [109.4, 18.1] ]] } } } } }

どちらのクエリも意図はかなり明確ですが、ES|QL クエリは SQL によく似ています。PostGIS での同じクエリは次のようになります。

SELECT abbrev, airport, region, city, city_location FROM airport_city_boundaries WHERE ST_INTERSECTS( city_boundary, 'SRID=4326;POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))'::geometry );

ES|QL の例を振り返ってみましょう。とても似ていますよね？

Elasticsearch API の既存のユーザーにとって、ES|QL の方がはるかに使いやすいことがわかりました。既存の SQL ユーザー、特に Spatial SQL ユーザーにとって、ES|QL は使い慣れたものと非常によく似ていると感じられるものと期待しています。

なぜSQLではないのですか?

Elasticsearch SQL についてはどうですか?しばらく前から存在しており、いくつかの地理空間機能を備えています。ただし、Elasticsearch SQL は元のクエリ API の上にラッパーとして記述されたため、元の API にトランスパイルできるクエリのみがサポートされていました。ES|QL にはこの制限はありません。完全に新しいスタックであるため、SQL では不可能だった多くの最適化が可能になります。私たちのベンチマークでは、ES|QL は、特に集計において、クエリ API よりも非常に高速であることが示されています。

SQLとの違い

前の例から、ES|QL は SQL と多少似ていることは明らかですが、いくつか重要な違いもあります。たとえば、ES|QL はパイプクエリ言語であり、FROM などのソースコマンドで開始し、後続のすべてのコマンドをパイプ | 文字で連結します。これにより、各コマンドがデータテーブルを受け取って、そのテーブルに対して何らかのアクション ( WHEREによるフィルタリング、 EVALによる列の追加、 STATSによる集計の実行など) を実行する方法が非常に簡単に理解できるようになります。最終的な出力列を定義するためにSELECTから始めるのではなく、1 つ以上のKEEPコマンドがあり、最後のコマンドで最終的な出力結果を指定できます。この構造により、クエリに関する推論が簡素化されます。

上記の例のWHEREコマンドに注目すると、PostGIS の例と非常によく似ていることがわかります。

ES|QL

WHERE ST_INTERSECTS( city_boundary, "POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))"::geo_shape )

ポストGIS

WHERE ST_INTERSECTS( city_boundary, 'SRID=4326;POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))'::geometry )

文字列引用文字の違いは別として、最も大きな違いは、文字列を空間型に型キャストする方法にあります。PostGIS では::geometryサフィックスを使用し、ES|QL では::geo_shapeサフィックスを使用します。これは、ES|QL が Elasticsearch 内で実行され、型キャスト演算子::を使用して文字列をサポートされているいずれかの ES|QL 型(この場合はgeo_shape ) に変換できるためです。さらに、Elasticsearch のgeo_shapeおよびgeo_pointタイプは、WGS84 と呼ばれる空間座標系を意味し、通常は SRID 番号 4326 を使用して参照されます。PostGIS ではこれを明示的にする必要があるため、WKT 文字列にSRID=4326;プレフィックスを使用します。そのプレフィックスが削除されると、SRID は 0 に設定され、特定の座標系に関連付けられていない Elasticsearch タイプcartesian_pointおよびcartesian_shapeに似たものになります。

ES|QL と PostGIS はどちらも型変換関数の構文も提供しています。

ES|QL

WHERE ST_INTERSECTS( city_boundary, TO_GEOSHAPE("POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))") )

ポストGIS

WHERE ST_INTERSECTS( city_boundary, ST_SetSRID( ST_GeomFromText('POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))'), 4326 ) )

OGC関数

Elasticsearch 8.14 では、次の 4 つの OGC 空間検索関数が導入されています。

ES|QL

ポストGIS

説明

ST_INTERSECTS

ST_交差

2 つのジオメトリが交差する場合は true を返し、そうでない場合は false を返します。

ST_DISJOINT

ST_分離

2 つのジオメトリが交差しない場合は true を返し、そうでない場合は false を返します。ST_INTERSECTS の逆。

ST_CONTAINS

ST_Contains

1 つのジオメトリに別のジオメトリが含まれている場合は true を返し、含まれていない場合は false を返します。

ST_WITHIN

ST_以内

1 つのジオメトリが別のジオメトリ内にある場合は true を返し、そうでない場合は false を返します。ST_CONTAINS の逆。

これらの関数は PostGIS の対応する関数と同様に動作し、同じように使用されます。たとえば、 ST_INTERSECTS 2 つのジオメトリが交差する場合は true を返し、そうでない場合は false を返します。上記の表のドキュメントリンクに従うと、すべての ES|QL の例がFROM句の後のWHERE句内にあるのに対し、すべての PostGIS の例はリテラルジオメトリを使用していることに気付くでしょう。実際、どちらのプラットフォームでも、意味のあるクエリのどの部分でも関数の使用がサポートされています。

ST_INTERSECTSの PostGIS ドキュメントの最初の例は次のとおりです。

SELECT ST_Intersects( 'POINT(0 0)'::geometry, 'LINESTRING ( 2 0, 0 2 )'::geometry );

ES|QL でこれに相当するものは次のとおりです。

ROW ST_INTERSECTS( "POINT(0 0)"::geo_point, "LINESTRING ( 2 0, 0 2 )"::geo_shape )

PostGIS の例では SRID を指定していないことに注意してください。これは、PostGIS でgeometryタイプを使用する場合、すべての計算が平面座標系で実行されるため、両方のジオメトリが同じ SRID を持つ場合、SRID が何であるかは問題にならないためです。Elasticsearch でも、これはほとんどの関数に当てはまりますが、 geo_shapeとgeo_point球面計算が使用されるという例外があります。これについては、空間距離検索に関する次のブログで説明します。

ES|QLの汎用性

上記では、 WHERE句とROWコマンドで空間関数を使用する例を見てきました。他にどこで意味を成すのでしょうか?非常に便利な場所の 1 つは、 EVALコマンドです。このコマンドを使用すると、式を評価して結果を返すことができます。たとえば、国名ごとにグループ化されたすべての空港の重心が、国の境界内にあるかどうかを判断します。

FROM airports | EVAL in_uk = ST_INTERSECTS(location, TO_GEOSHAPE("POLYGON((1.2305 60.8449, -1.582 61.6899, -10.7227 58.4017, -7.1191 55.3291, -7.9102 54.2139, -5.4492 54.0078, -5.2734 52.3756, -7.8223 49.6676, -5.0977 49.2678, 0.9668 50.5134, 2.5488 52.1065, 2.6367 54.0078, -0.9668 56.4625, 1.2305 60.8449))")) | EVAL in_iceland = ST_INTERSECTS(location, TO_GEOSHAPE("POLYGON ((-25.4883 65.5312, -23.4668 66.7746, -18.4131 67.4749, -13.0957 66.2669, -12.3926 64.4159, -20.1270 62.7346, -24.7852 63.3718, -25.4883 65.5312))")) | EVAL within_uk = ST_WITHIN(location, TO_GEOSHAPE("POLYGON((1.2305 60.8449, -1.582 61.6899, -10.7227 58.4017, -7.1191 55.3291, -7.9102 54.2139, -5.4492 54.0078, -5.2734 52.3756, -7.8223 49.6676, -5.0977 49.2678, 0.9668 50.5134, 2.5488 52.1065, 2.6367 54.0078, -0.9668 56.4625, 1.2305 60.8449))")) | EVAL within_iceland = ST_WITHIN(location, TO_GEOSHAPE("POLYGON ((-25.4883 65.5312, -23.4668 66.7746, -18.4131 67.4749, -13.0957 66.2669, -12.3926 64.4159, -20.1270 62.7346, -24.7852 63.3718, -25.4883 65.5312))")) | STATS centroid = ST_CENTROID_AGG(location), count=COUNT() BY in_uk, in_iceland, within_uk, within_iceland | SORT count ASC

結果は予想通りで、英国の空港の重心は英国の境界内にあり、アイスランドの境界内にはなく、その逆も同様です。

重心

カウント

英国

アイスランド

英国内

アイスランド内

ポイント (-21.94663446396589364.13187285885215)

間違い

true

間違い

true

ポイント (-2.597342072712148 54.33551226578214)

true

間違い

true

間違い

ポイント (0.04453958108176276 23.74658354606057)

873

間違い

実際、これらの関数は、そのシグネチャが意味を成すクエリのどの部分でも使用できます。これらはすべて、リテラル空間オブジェクトまたは空間型のフィールドのいずれかである 2 つの引数を取り、ブール値を返します。重要な考慮事項の 1 つは、ジオメトリの座標参照システム (CRS) が一致している必要があることです。一致していない場合はエラーが返されます。つまり、同じ関数呼び出しでgeo_shape型とcartesian_shape型を混在させることはできません。ただし、 geo_pointタイプはgeo_shapeタイプの特殊なケースであり、両方とも同じ座標参照系を共有しているため、 geo_pointタイプとgeo_shapeタイプを混在させることができます。上記で定義された各関数のドキュメントには、サポートされている型の組み合わせがリストされています。

さらに、どちらの引数も、空間リテラルまたはフィールドを任意の順序で指定できます。2 つのフィールド、2 つのリテラル、フィールドとリテラル、またはリテラルとフィールドを指定することもできます。唯一の要件は、タイプに互換性があることです。たとえば、次のクエリは同じインデックス内の 2 つのフィールドを比較します。

このクエリは基本的に、都市の場所が都市の境界内にあるかどうかを尋ねます。これは通常当てはまるはずですが、常に例外があります。

基数

カウント

市内

少し

間違い

多くの

740

true

さらに興味深い質問は、空港の場所が、その空港がサービスを提供する都市の境界内にあるかどうかです。ただし、空港の位置は、都市の境界を含むインデックスとは異なるインデックスに存在します。これには、これら 2 つの個別のインデックスからデータを効果的にクエリして相関させる方法が必要です。

空間結合

ES|QL はJOINコマンドをサポートしていませんが、SQL の「左結合」と同様に動作するENRICHコマンドを使用して、特殊な結合を実現できます。このコマンドは SQL の「左結合」に似た動作をし、2 つのデータセット間の空間関係に基づいて、1 つのインデックスの結果を別のインデックスのデータで強化することができます。

たとえば、空港の場所を含む都市の境界を見つけることで、空港のテーブルからの結果に、空港がサービスを提供する都市に関する追加情報を付加し、結果に対していくつかの統計を実行してみましょう。

FROM airports | ENRICH city_boundaries ON city_location WITH airport, region, city_boundary | MV_EXPAND city_boundary | EVAL boundary_wkt_length = LENGTH(TO_STRING(city_boundary)) | STATS centroid = ST_CENTROID_AGG(location), count = COUNT(city_location), min_wkt = MIN(boundary_wkt_length), max_wkt = MAX(boundary_wkt_length) BY region | SORT count DESC | LIMIT 5

これは、空港が最も多い上位 5 つの地域と、一致する地域を持つすべての空港の重心、およびそれらの地域内の都市境界の WKT 表現の長さの範囲を返します。

重心

カウント

最小wkt

最大wkt

地域

ポイント (-32.5609347096071932.598117914802714)

207

ヌル

ポイント (-73.9451533276587740.70366442203522）

438

ニューヨーク市

ポイント (-83.1039831787347842.300230911932886)

473

デトロイト

ポイント (-156.302024586126220.176383580081165)

307

803

ハワイ

ポイント (-73.8890273217111845.57078813901171)

837

モントリオール

それで、ここで実際に何が起こったのでしょうか?JOINはどこで発生したのでしょうか?クエリの核心はENRICHコマンドにあります。

FROM airports | ENRICH city_boundaries ON city_location WITH airport, region, city_boundary

このコマンドは、Elasticsearch に、 airportsインデックスから取得された結果を強化し、元のインデックスのcity_locationフィールドと、前のいくつかの例で使用したairport_city_boundariesインデックスのcity_boundaryフィールドの間でintersects結合を実行するように指示します。しかし、この情報の一部はこのクエリでは明確に表示されません。表示されるのはエンリッチポリシーの名前city_boundariesであり、不足している情報はそのポリシー定義内にカプセル化されています。

{ "geo_match": { "indices": "airport_city_boundaries", "match_field": "city_boundary", "enrich_fields": ["city", "airport", "region", "city_boundary"] } }

ここでは、 geo_matchクエリ ( intersectsがデフォルト) が実行され、照合するフィールドがcity_boundaryであり、 enrich_fieldsが元のドキュメントに追加するフィールドであることがわかります。これらのフィールドの 1 つであるregionは、実際にはSTATSコマンドのグループ化キーとして使用されていましたが、これはこの「左結合」機能がなければ実行できませんでした。エンリッチポリシーの詳細については、エンリッチのドキュメントを参照してください。これらのドキュメントを読んでいくと、取り込みパイプラインを構成することによって、インデックス作成時にデータを拡充するための拡充インデックスの使用について説明されていることに気付くでしょう。ES|QL では、 ENRICHコマンドがクエリ時に機能するため、これは必要ありません。必要なデータとエンリッチポリシーを使用してエンリッチインデックスを準備し、ES|QL クエリでENRICHコマンドを使用するだけで十分です。

また、最も頻繁に見つかった地域はnullであったことにも気付くでしょう。これは何を意味するのでしょうか?このコマンドを SQL の「左結合」に例えたことを思い出してください。つまり、空港に一致する都市境界が見つからない場合でも、その空港は返されますが、 airport_city_boundariesインデックスのフィールドにはnull値が含まれます。一致するcity_boundaryが見つからなかった空港が 89 か所あり、 regionフィールドがnullである一致する空港が 1 か所あることがわかりました。これにより、結果にregionが含まれない空港が 90 件見つかりました。もう 1 つの興味深い点は、 MV_EXPANDコマンドの必要性です。これが必要なのは、 ENRICHコマンドが入力行ごとに複数の結果を返す場合があり、 MV_EXPANDこれらの結果を結果ごとに 1 つずつ複数の行に分割するのに役立つためです。これにより、「ハワイ」が異なるmin_wktとmax_wkt結果を表示する理由も明らかになります。同じ名前でありながら境界が異なる複数の地域が存在したためです。

Kibanaマップ

Kibana は、マップアプリケーションに Spatial ES|QL のサポートを追加しました。つまり、ES|QL を使用して Elasticsearch で地理空間データを検索し、その結果をマップ上に視覚化できるようになりました。

レイヤー追加メニューに、「ES|QL」という新しいレイヤーオプションがあります。これまで説明したすべての地理空間機能と同様に、これは「技術プレビュー」段階です。このオプションを選択すると、ES|QL クエリの結果に基づいてマップにレイヤーを追加できます。たとえば、世界中のすべての空港を表示するレイヤーをマップに追加できます。

または、 airport_city_boundariesインデックスからポリゴンを表示するレイヤーを追加することもできます。さらに良い方法として、各地域に空港がいくつあるかという統計を生成する、上記の複雑なENRICHクエリはどうでしょうか。

新しいエクスペリエンス

上記の 2 つの例では、さらに別の空間関数ST_CENTROID_AGGが組み込まれていることに気付いたかもしれません。これは、 STATSコマンドで使用される集計関数であり、ES|QL に追加する予定の多くの空間分析機能の最初のものです。もっと詳しく紹介できるようになったら、ブログで紹介します!

その前に、私たちが取り組んできた特に興味深い機能、つまり Elasticsearch で最もよく使用される空間検索機能の 1 つである空間距離検索を実行する機能について詳しく説明したいと思います。距離検索の構文がどのようになるか想像できますか?おそらく OGC 関数に似ていますか?詳細については、このシリーズの次のブログをお読みください。

ネタバレ注意: Elasticsearch 8.15 がリリースされました。ES|QL による空間距離検索が含まれています。

検索関連性の評価パート1－BEIRベンチマーク

Thanos Papaoikonomou,Thomas Veasey — Tue, 16 Jul 2024 00:00:00 GMT

これは、BEIRベンチマークをより深く理解するという観点から、独自の検索システムを評価する方法について検討するブログ記事シリーズの最初の投稿です。BEIRをよりよく理解するために、検索評価プロセスを改善するための具体的なヒントやテクニックを紹介します。また、評価の信頼性を下げる一般的な落とし穴も紹介します。最後に、LLMは検索エンジニアに強力な新しいツールを提供することを指摘し、検索の評価にLLMをどのように使用できるかを例を挙げて示します。

検索関連性評価におけるBEIRベンチマークの理解

あらゆるシステムを改善するには、それがどの程度うまく機能しているかを測定できる必要があります。検索の観点では、BEIR（またはMTEBリーダーボードの検索セクションに相当するもの）が情報検索コミュニティの「聖杯」と考えられており、それ自体は驚くことではありません。これは、さまざまなタスクにわたる多様なデータセットを備えた、非常によく構造化されたベンチマークです。具体的には、以下の領域が対象となります。

引数取得（ArguAna、Touche2020）
オープンドメインQA（HotpotQA、Natural Questions、FiQA）
パッセージ検索（MSMARCO）
重複質問取得（Quora、CQADupstack）
ファクトチェック（FEVER、Climate-FEVER、Scifact）
バイオメディカル情報検索（TREC-COVID、NFCorpus、BioASQ）
エンティティ検索（DBPedia）
引用予測（SCIDOCS）

これは、システムが返す上位結果の中で、各タスク例で最も関連性の高いドキュメントをシステムがどの程度一致させたかに関する単一の統計であるnDCG@10を提供します。人間が操作する検索システムでは、上位結果の関連性が非常に重要です。しかし、検索の評価には多くのニュアンスがあり、単一の要約統計では見逃してしまうものがあります。

BEIRデータセットの構造

各ベンチマークには3つのアーティファクトがあります。

取得すべきコーパスや文書
クエリ
クエリの関連性判断（別名 qrels）

関連性判定は、ゼロ以上のスコアとして提供されます。0以外のスコアは、ドキュメントがクエリに多少関連していることを示します。

データセット

コーパスのサイズ

テストセット内のクエリ数

肯定的にラベル付けされた#qrels

ゼロに等しい#qrels

コーパス内の#duplicates

Arguana

8,674

1,406

Climate-FEVER

5,416,593

1,535

4,681

DBPedia

4,635,922

400

15,286

28,229

FEVER

5,416,568

6,666

7,937

FiQA-2018

57,638

648

1,706

HotpotQA

5,233,329

7,405

14,810

Natural Questions

2,681,468

3,452

4,021

16,781

NFCorpus

3,633

323

12,334

Quora

522,931

10,000

15,675

1,092

SCIDOCS

25,657

1,000

4,928

25,000

Scifact

5,183

300

339

Touche2020

382,545

932

1,982

5,357

TREC-COVID

171,332

24,763

41,663

MSMARCO

8,841,823

6,980

7,437

324

CQADupstack (sum)

457,199

13,145

23,703

表1：データセットの統計。数値はデータセットのテスト部分（ MSMARCOの場合はdev ）で計算されました。

表1は、BEIRベンチマークを構成するデータセットの統計を示しています。これには、コーパス内のドキュメント数、テストデータセット内のクエリ数、qrelsファイル内の正/負（クエリ、ドキュメント）ペアの数などが含まれます。データをざっと見てみると、すぐに次のことが推測できます。

ほとんどのデータセットには、qrelsファイル内に負の関係、つまりゼロスコアが含まれていません。これは、ドキュメントが与えられたクエリに対して明確に無関係であることを示します。
クエリごとの平均ドキュメント関係数（#qrels/#queries）は、ArguAnaの場合1.0からTREC-COVIDの493.5まで変化しますが、大部分のケースでは値が<5です。
一部のデータセットでは、コーパス内に重複したドキュメントが存在するため、ドキュメントがクエリに関連していると見なされても、その重複は関連していないなど、誤った評価につながる場合があります。例えば、ArguAnaでは、クエリに関連するとマークされたドキュメントが1つしかない、重複したドキュメントペアを96件確認しました。重複も含め初期qrelsリストを「拡張」することで、 nDCG@10スコアが平均で約1%相対的に増加することが観測されました。

{ "_id": "test-economy-epiasghbf-pro02b", "title": "economic policy international africa society gender house believes feminisation", "text": "Again employment needs to be contextualised with …", "metadata": {} } { "_id": "test-society-epiasghbf-pro02b", "title": "economic policy international africa society gender house believes feminisation", "text": "Again employment needs to be contextualised with …", "metadata": {} }

ArguAnaの重複ペアの例。qrelsファイルでは、（反論として）最初のものだけがクエリ「test-economy-epiasghbf-pro02a」に関連しているようです。

MTEBリーダーボード上のモデルを比較する場合、平均的な検索品質に焦点を当てたくなることがあります。これはモデル全体の品質を示す良い指標ですが、必ずしもモデルのパフォーマンスを正確に示すわけではありません。結果はデータセットごとに報告されるため、異なるデータセットが検索タスクとどれほど密接に関連しているかを理解し、最も関連性の高いものだけを使用してモデルを再スコアリングする価値があります。さらに深く掘り下げたい場合は、さまざまなデータセットコーパスとのトピックの重複を追加で確認することもできます。品質基準をトピック別に階層化することで、トピックごとの長所と短所をより細かく評価できます。

ここで重要な注意点は、ドキュメントがqrelsファイル内でマークされていない場合、デフォルトではクエリとは無関係であると見なされることです。この領域をさらに掘り下げ、「評価者が（クエリ、ドキュメント）ペアに対して、グラウンドトゥルース情報がない場合、どれくらいの頻度で提示されるか？」という問いに光を当てるための証拠を収集します。これが重要な理由は、浅いマークアップしか利用できない（したがって、すべての関連文書がそのようなラベル付けされているわけではない）場合、1つの情報検索システムが、異なる関連（しかしマークされていない）ドキュメントを単に「選択」して表面化させるため、別のシステムよりも劣っていると判断される可能性があるためです。これは高品質の評価セットを作成する際によくある時限爆弾で、特に大規模なデータセットの場合に顕著です。手動でのラベル付けは、通常、現在のシステムによって返される上位の結果に重点を置くため、盲点にある関連ドキュメントを見逃す可能性があります。したがって、通常は、より広範囲な浅いマークアップよりも、より少ないクエリのより完全なマークアップにより多くのリソースを集中させることが好ましいです。

検索関連性評価におけるBEIRベンチマークの活用

分析を開始するために、次のシナリオを実装します（ノートブックを参照）。

まず、各データセットのコーパスをElasticsearchインデックスにロードします。
テストセットの各クエリについて、BM25の上位100件の文書を取得します。
取得したドキュメントを、さまざまなSOTA再ランク付けモデルを使用して再ランク付けします。
最後に、ステップ2（取得後）とステップ3（リランキング後）の上位10件のドキュメントの「判定率」をレポートします。つまり、qrelsファイルにスコアがある上位ドキュメント10件の平均割合を算出します。

使用したモデルのリランキングのリストは次のとおりです。

Cohereのrerank-english-v2.0と rerank-english-v3.0
BGEベース
mxbai-rerank-xsmall-v1
MiniLM-L-6-v2

検索

リランキング

データセット

BM25 (%)

Cohere Rerank v2 (%)

Cohereリランク v3(%)

BGEベース (%)

mxbai-rerank-xsmall-v1 (%)

MiniLM-L-6-v2 (%)

Arguana

7.54

4.87

7.87

4.52

4.53

6.84

Climate-FEVER

5.75

6.24

8.15

9.36

7.79

7.58

DBPedia

61.18

60.78

64.15

63.9

63.5

67.62

FEVER

8.89

9.97

10.08

10.19

9.88

FiQa-2018

7.02

11.02

10.77

8.43

9.1

9.44

HotpotQA

12.59

14.5

14.76

15.1

14.02

14.42

Natural Questions

5.94

8.84

8.71

8.37

8.14

8.34

NFCorpus

31.67

32.9

33.91

30.63

32.77

32.45

Quora

12.2

10.46

13.04

11.26

12.58

12.78

SCIDOCS

8.62

9.41

9.71

8.04

8.79

8.52

Scifact

9.07

9.57

9.77

9.3

9.1

9.17

Touche2020

38.78

30.41

32.24

33.06

37.96

33.67

TREC-COVID

92.4

98.4

98.2

93.8

99.6

97.4

MSMARCO

3.97

6.00

6.03

6.07

5.47

6.11

CQADupstack (avg.)

5.47

6.32

6.87

5.89

6.22

6.16

表 2：上位10件の取得/リランキングされたドキュメントに基づいて計算された（データセット、リランカー）ペアごとの判定率

表2から、TREC-COVID （カバレッジ90%超）、DBPedia （～65% ）、Touche2020 、nfcorpus （～35% ）を除き、大半のデータセットの検索後またはリランキング付け後のラベリング率は5%から10%を少し超える程度であることがわかります。これは、マークされていないドキュメントがすべて関連性があるという意味ではありませんが、それらのサブセット（特に上位に配置されたもの）が正である可能性があります。

汎用命令調整言語モデルの登場により、関連性の判断を自動化できる可能性のある強力な新しいツールが生まれました。これらの方法は通常、検索のためにオンラインで使用するには計算コストがかかりすぎますが、ここではオフライン評価に焦点を当てます。以下では、これらを使用して、BEIRデータセットの一部が浅いマークアップに悩まされているという証拠を調査します。

この仮説をさらに調査するために、MSMARCOに焦点を当て、100件のクエリのサブセットと、（Cohere v2で）リランキングされた上位5つのドキュメントのうち、現在関連性があるとマークされていないものを選択することにしました。私たちは 2 つの異なる評価方法を採用しました。まず、慎重に調整されたプロンプト（これについては後の投稿で詳説します）を使用して、最近リリースされたPhi-3-mini-4kモデルを準備し、クエリに対するドキュメントの関連性（または関連性の欠如）を予測しました。並行して、これらのケースは手動でラベル付けされ、LLMの出力と人間の判断との一致率も評価されました。全体として、以下の2つの結論が導き出されます。

LLMの応答と人間の判断の間の一致率は約80％で、その方向性において十分な出発点であるように思われます。
57.6％のケース（人間の判断に基づく）で、返されたドキュメントが実際にクエリに関連していることが判明しました。言い換えれば、100件のクエリに対して107件のドキュメントに関連性があると判断されましたが、少なくとも0.576 x 5 x 100 = 288の追加のドキュメントが実際には関連しています！

以下は、MSMARCO/dev データセットから抽出された、クエリ、注釈付きの正のドキュメント（qrelsから）、不完全なマークアップによる偽陰性のドキュメントを含む例です。

例1：

{ "query": { "_id": 155234, "text": "do bigger tires affect gas mileage" }, "positive_doc": { "_id": 502713, "text": "Tire Width versus Gas Mileage. Tire width is one of the only tire size factors that can influence gas mileage in a positive way. For example, a narrow tire will have less wind resistance, rolling resistance, and weight; thus increasing gas mileage.", }, "negative_doc": { "_id": 7073658, "text": "Tire Size and Width Influences Gas Mileage. There are two things to consider when thinking about tires and their effect on gas mileage; one is wind resistance, and the other is rolling resistance. When a car is driving at higher speeds, it experiences higher wind resistance; this means lower fuel economy." } }

例2：

{ "query": { "_id": 300674, "text": "how many years did william bradford serve as governor of plymouth colony?" }, "positive_doc": { "_id": 7067032, "text": "http://en.wikipedia.org/wiki/William_Bradford_(Plymouth_Colony_governor) William Bradford (c.1590 \u00e2\u0080\u0093 1657) was an English Separatist leader in Leiden, Holland and in Plymouth Colony was a signatory to the Mayflower Compact. He served as Plymouth Colony Governor five times covering about thirty years between 1621 and 1657." }, "negative_doc": { "_id": 2495763, "text": "William Bradford was the governor of Plymouth Colony for 30 years. The colony was founded by people called Puritans. They were some of the first people from England to settle in what is now the United States. Bradford helped make Plymouth the first lasting colony in New England." } }

このような特定のクエリを手動で評価することは、nDCG@10のような定量的尺度を補完する検索品質を理解する上で一般的に役立つ手法です。検索に変更を加えるときに常に実行する代表的なクエリのセットがあれば、統計には表示されない、パフォーマンスの変化に関する重要な定性情報が得られます。例えば、検索で返される誤った結果についてより深い洞察を得ることができます。取得した結果の中で明らかな誤りを特定したり、ドメイン固有の用語の誤解釈などの関連する誤りのクラスを特定したりすることができます。

私たちの結果は、 MSMARCO評価に関する関連研究と一致しています。例えば、Arabzadehらは同様の手順を踏んでおり、クラウドソーシングされたワーカーに選好判定を行わせています。特に、彼らは、多くの場合、リランキングモジュールによって返されたドキュメントがMSMARCO qrelsファイル内のドキュメントよりも選好されるということを示しています。もう一つの証拠は、RocketQAリランカーの著者らによるもので、リランキングされたドキュメントの70％以上が手動検査後に関連性があると判断されたと報告しています。

更新 - 9月9日：データセットの慎重な再評価の結果、関連ドキュメントの事例が15件追加で特定され、合計数は273件から288件に増加しました。

主なポイントと次のステップ

ベンチマークやモデルの比較にとって、より優れたグラウンドトゥルースの追求は極めて重要であるため、終わりがありません。LLMは、慎重に使用し、適切な指示に従って調整すれば、いくつかの評価領域で役立つ可能性があります。
より一般的には、ベンチマークが完璧になることは決してないことを考えると、純粋なスコアの比較から、統計的に有意な差異を捕捉するより堅牢な手法に切り替えることが望ましいかもしれません。Arabzadehらの研究はこのことを示す良い例であり、彼らは調査結果に基づいて、さまざまな実行間での有意な差（または有意でない差）を示す95%信頼区間を構築しています。付属のノートブックでは、ブートストラッピングを使用した信頼区間の実装を提供しています。
エンドユーザーの視点からは、ベンチマークの結果を読む際にタスクの整合性を考えることが有用です。例えば、RAGパイプラインを構築し、最も一般的なユースケースがさまざまなソースから複数の情報を集めることであると知っているAIエンジニアにとっては、BEIRベンチマーク全体のグローバル平均ではなく、HotpotQAのようなマルチホップQAデータセットで検索モデルのパフォーマンスを評価する方が有意義です。

次のブログ記事では、LLMとしてのPhi-3の使用と、関連性を予測するようにチューニングする過程をさらに詳しく説明します。

AI盗作：Elasticsearchによる盗作検出

Priscilla Parodi — Tue, 19 Dec 2023 00:00:00 GMT

盗作には、直接的な盗用（コンテンツの一部または全体をコピーする）と言い換えれば言い換え（著者の作品のいくつかの単語やフレーズを変更して言い換える）があります。

インスピレーションと言い換えには違いがあります。コンテンツを読んでインスピレーションを得て、たとえ同じような結論に達したとしても、自分の言葉でそのアイデアを探求することは可能です。

盗作は長い間議論されてきたテーマですが、コンテンツの制作と公開が加速するにつれて、盗作は関連性を保ち、継続的な課題となっています。

この課題は、盗作チェックが頻繁に行われる書籍、学術研究、司法文書に限定されません。それは新聞やソーシャルメディアにも及ぶ可能性があります。

情報が豊富で出版物に簡単にアクセスできるようになった今、スケーラブルなレベルで盗作を効果的にチェックするにはどうすればよいでしょうか?

大学、政府機関、企業はさまざまなツールを使用していますが、単純な語彙検索で直接的な盗用を効果的に検出できる一方で、言い換えられたコンテンツを特定することが主な課題です。

生成AIによる盗作検出

生成 AI によって新たな課題が生まれます。AI によって生成されたコンテンツは、コピーされた場合に盗作とみなされますか?

たとえば、 OpenAI の利用規約では、OpenAI はユーザー向けに API によって生成されたコンテンツに対する著作権を主張しないことが規定されています。この場合、生成 AI を使用する個人は、生成されたコンテンツを引用なしで自由に使用できます。

しかし、効率性を向上させるために生成 AI を使用することが受け入れられるかどうかは、依然として議論の余地があります。

OpenAIは盗作検出に貢献しようと検出モデルを開発したが、後にその精度が十分に高くないことを認めた。

「これは単独の検出では精度が十分ではなく、より効果を上げるにはメタデータベースのアプローチ、人間の判断、一般の教育と組み合わせる必要があると考えています。」

課題は依然として残っていますが、利用できるツールが増えたことにより、言い換えられたコンテンツや AI コンテンツの場合でも盗作を検出するための選択肢が増えています。

Elasticsearchで盗作を検出する

これを認識して、このブログでは、メタデータ検索を超えて、自然言語処理 (NLP) モデルとベクトル検索、盗作検出を使用したもう 1 つのユースケースを検討します。

これは Python の例で実証されており、NLP 関連の記事を含む SentenceTransformers のデータセットを活用しています。以前に Elasticsearch にインポートされたテキスト埋め込みモデルで生成された「要約」埋め込みを考慮して「意味的テキスト類似性」を実行することにより、要約の盗用をチェックします。さらに、AI によって生成されたコンテンツ (AI 盗作) を識別するために、OpenAI によって開発されたNLP モデルも Elasticsearch にインポートされました。

次の図はデータフローを示しています。

推論プロセッサを使用した取り込みパイプラインの実行中に、「abstract」段落は 768 次元のベクトル「abstract_vector.predicted_value」にマッピングされます。

マッピング：

"abstract_vector.predicted_value": { # Inference results field "type": "dense_vector", "dims": 768, # model embedding_size "index": "true", "similarity": "dot_product" # When indexing vectors for approximate kNN search, you need to specify the similarity function for comparing the vectors.

ベクトル表現間の類似性は、「類似性」パラメータを使用して定義されるベクトル類似性メトリックを使用して測定されます。

コサインはデフォルトの類似度メトリックであり、「(1 + cosine(クエリ、ベクトル)) / 2」として計算されます。元のベクトルを保持する必要があり、事前に正規化できない場合を除き、コサイン類似度を実行する最も効率的な方法は、すべてのベクトルを単位長さに正規化することです。これにより、検索中に余分なベクトルの長さの計算を実行することを回避でき、代わりに 'dot_product' を使用できます。

この同じパイプラインでは、テキスト分類モデルを含む別の推論プロセッサが、コンテンツがおそらく人間によって書かれた「本物」か、おそらく AI によって書かれた「偽物」かを検出し、各ドキュメントに「openai-detector.predicted_value」を追加します。

取り込みパイプライン:

client.ingest.put_pipeline( id="plagiarism-checker-pipeline", processors = [ { "inference": { #for ml models - to infer against the data that is being ingested in the pipeline "model_id": "roberta-base-openai-detector", #text classification model id "target_field": "openai-detector", # Target field for the inference results "field_map": { #Maps the document field names to the known field names of the model. "abstract": "text_field" # Field matching our configured trained model input. } } }, { "inference": { "model_id": "sentence-transformers__all-mpnet-base-v2", #text embedding model id "target_field": "abstract_vector", # Target field for the inference results "field_map": { "abstract": "text_field" # Field matching our configured trained model input. Typically for NLP models, the field name is text_field. } } } ] )

クエリ時に、同じテキスト埋め込みモデルを使用して、「query_vector_builder」オブジェクト内のクエリ「model_text」のベクトル表現も生成されます。

k 最近傍 (kNN) 検索は、類似度メトリックによって測定されたクエリベクトルに最も近い k ベクトルを見つけます。

各ドキュメントの _score は類似性から導き出され、スコアが大きいほどランキングが高くなります。これは、ドキュメントが意味的に類似していることを意味します。結果として、3 つの可能性を出力します。スコアが 0.9 を超える場合は「高い類似性」を考慮し、スコアが 0.7 未満の場合は「低い類似性」、それ以外の場合は「中程度の類似性」を考慮します。ユースケースに応じて、_score のどのレベルが盗作とみなされるかを決定するために、さまざまなしきい値を柔軟に設定できます。

さらに、テキスト分類が実行され、テキストクエリ内の AI によって生成された要素もチェックされます。

クエリ:

from elasticsearch import Elasticsearch from elasticsearch.client import MlClient #duplicated text - direct plagiarism test model_text = 'Understanding and reasoning about cooking recipes is a fruitful research direction towards enabling machines to interpret procedural text. In this work, we introduce RecipeQA, a dataset for multimodal comprehension of cooking recipes. It comprises of approximately 20K instructional recipes with multiple modalities such as titles, descriptions and aligned set of images. With over 36K automatically generated question-answer pairs, we design a set of comprehension and reasoning tasks that require joint understanding of images and text, capturing the temporal flow of events and making sense of procedural knowledge. Our preliminary results indicate that RecipeQA will serve as a challenging test bed and an ideal benchmark for evaluating machine comprehension systems. The data and leaderboard are available at http://hucvl.github.io/recipeqa.' response = client.search(index='plagiarism-checker', size=1, knn={ "field": "abstract_vector.predicted_value", "k": 9, "num_candidates": 974, "query_vector_builder": { #The 'all-mpnet-base-v2' model is also employed to generate the vector representation of the query in a 'query_vector_builder' object. "text_embedding": { "model_id": "sentence-transformers__all-mpnet-base-v2", "model_text": model_text } } } ) for hit in response['hits']['hits']: score = hit['_score'] title = hit['_source']['title'] abstract = hit['_source']['abstract'] openai = hit['_source']['openai-detector']['predicted_value'] url = hit['_source']['url'] if score > 0.9: print(f"\nHigh similarity detected! This might be plagiarism.") print(f"\nMost similar document: '{title}'\n\nAbstract: {abstract}\n\nurl: {url}\n\nScore:{score}\n\n") if openai == 'Fake': print("This document may have been created by AI.\n") elif score < 0.7: print(f"\nLow similarity detected. This might not be plagiarism.") if openai == 'Fake': print("This document may have been created by AI.\n") else: print(f"\nModerate similarity detected.") print(f"\nMost similar document: '{title}'\n\nAbstract: {abstract}\n\nurl: {url}\n\nScore:{score}\n\n") if openai == 'Fake': print("This document may have been created by AI.\n") ml_client = MlClient(client) model_id = 'roberta-base-openai-detector' #open ai text classification model document = [ { "text_field": model_text } ] ml_response = ml_client.infer_trained_model(model_id=model_id, docs=document) predicted_value = ml_response['inference_results'][0]['predicted_value'] if predicted_value == 'Fake': print("\nNote: The text query you entered may have been generated by AI.\n")

アウトプット：

High similarity detected! This might be plagiarism. Most similar document: 'RecipeQA: A Challenge Dataset for Multimodal Comprehension of Cooking Recipes' Abstract: Understanding and reasoning about cooking recipes is a fruitful research direction towards enabling machines to interpret procedural text. In this work, we introduce RecipeQA, a dataset for multimodal comprehension of cooking recipes. It comprises of approximately 20K instructional recipes with multiple modalities such as titles, descriptions and aligned set of images. With over 36K automatically generated question-answer pairs, we design a set of comprehension and reasoning tasks that require joint understanding of images and text, capturing the temporal flow of events and making sense of procedural knowledge. Our preliminary results indicate that RecipeQA will serve as a challenging test bed and an ideal benchmark for evaluating machine comprehension systems. The data and leaderboard are available at[ http://hucvl.github.io/recipeqa](http://hucvl.github.io/recipeqa). url:[http://aclweb.org/anthology/D18-1166](http://aclweb.org/anthology/D18-1166) Score:1.0

この例では、データセットの「抽象」値の 1 つをテキストクエリ「model_text」として使用した後、盗用が特定されました。類似度スコアは 1.0 であり、類似度が高いこと、つまり直接的な盗用であることを示しています。ベクトル化されたクエリとドキュメントは、予想どおり AI 生成コンテンツとして認識されませんでした。

クエリ:

#similar text - paraphrase plagiarism test model_text = 'Comprehending and deducing information from culinary instructions represents a promising avenue for research aimed at empowering artificial intelligence to decipher step-by-step text. In this study, we present CuisineInquiry, a database for the multifaceted understanding of cooking guidelines. It encompasses a substantial number of informative recipes featuring various elements such as headings, explanations, and a matched assortment of visuals. Utilizing an extensive set of automatically crafted question-answer pairings, we formulate a series of tasks focusing on understanding and logic that necessitate a combined interpretation of visuals and written content. This involves capturing the sequential progression of events and extracting meaning from procedural expertise. Our initial findings suggest that CuisineInquiry is poised to function as a demanding experimental platform.'

アウトプット：

テキストクエリ「model_text」を、類似した単語の繰り返しを最小限に抑えながら同じメッセージを伝える AI 生成テキストで更新すると、検出された類似度は依然として高かったものの、スコアは 1.0 ではなく 0.9302529 になりました(言い換え盗用) 。AIによって生成されたこのクエリが検出されることも予想されました。

最後に、テキストクエリ「model_text」を、これらのドキュメントの要約ではない Elasticsearch に関するテキストと見なすと、検出された類似度は 0.68991005 となり、考慮されたしきい値によると類似度が低いことが示されました。

クエリ:

#different text - not a plagiarism model_text = 'Elasticsearch provides near real-time search and analytics for all types of data.'

アウトプット：

Low similarity detected. This might not be plagiarism.

AI によって生成されたテキストクエリでは、言い換えや直接コピーされたコンテンツの場合と同様に、盗用が正確に識別されましたが、盗用検出の状況を把握するには、さまざまな側面を認識する必要があります。

AI 生成コンテンツの検出という観点から、私たちは価値ある貢献を果たすモデルを検討しました。ただし、単独の検出には固有の限界があり、精度を高めるには他の方法を組み込む必要があることを認識することが重要です。

テキスト埋め込みモデルの選択によってもたらされる変動性も、もうひとつの考慮事項です。異なるデータセットでトレーニングされたさまざまなモデルでは、さまざまなレベルの類似性が得られ、生成されたテキスト埋め込みの重要性が強調されます。

最後に、これらの例では、ドキュメントの要約を使用しました。ただし、盗作検出には大きな文書が関係することが多く、テキストの長さの問題に対処することが不可欠です。テキストがモデルのトークン制限を超えることはよくあり、埋め込みを構築する前にチャンクに分割する必要があります。これを処理する実用的なアプローチとしては、dense_vector を使用したネストされた構造を利用することが挙げられます。

まとめ

このブログでは、特に言い換えられたコンテンツや AI によって生成されたコンテンツにおける盗作の検出の課題と、この目的のために意味的なテキストの類似性とテキスト分類をどのように使用できるかについて説明しました。

これらの方法を組み合わせることで、AI によって生成されたコンテンツ、直接的な盗用と言い換えられた盗用を正常に識別した盗用検出の例を示しました。

主な目的は検出を簡素化するフィルタリングシステムを確立することですが、検証には人間による評価が依然として不可欠です。

意味的テキスト類似性と NLP についてさらに詳しく知りたい場合は、次のリンクもご覧ください。

Elasticsearch による語彙検索と意味検索

Priscilla Parodi — Tue, 03 Oct 2023 00:00:00 GMT

検索は、検索クエリまたは複合クエリに基づいて最も関連性の高い情報を検索するプロセスであり、関連する検索結果はこれらのクエリに最も一致するドキュメントです。検索にはさまざまな課題と方法がありますが、最終的な目標は、質問に対する最適な回答を見つけることです。

この目標を考慮して、このブログ投稿では、Elasticsearch を使用して情報を取得するためのさまざまなアプローチを検討し、特にテキスト検索（語彙検索とセマンティック検索）に焦点を当てます。

要件

これを実現するために、eコマース製品情報をシミュレートするために生成されたデータセットでのさまざまな検索シナリオを示す Python の例を提供します。

このデータセットには 2,500 を超える製品が含まれており、それぞれに説明が付いています。これらの製品は 76 の異なる製品カテゴリに分類されており、各カテゴリには以下に示すようにさまざまな数の製品が含まれています。

ツリーマップの視覚化 - カテゴリ.キーワードの上位 22 個の値 (製品カテゴリ)

セットアップには次のものが必要です:

Python 3.6以降
Elastic Pythonクライアント
Elastic 8.8 以降のデプロイメント、8GB メモリの機械学習ノード
Elastic Learned Sparse EncodeRモデルは、Elastic にプリロードされており、デプロイメントにインストールされて起動します。

Elastic Cloud を使用します。無料トライアルをご利用いただけます。

このブログ記事で提供されている検索クエリに加えて、 Python ノートブックでは次のプロセスをガイドします。

Pythonクライアントを使用してElasticデプロイメントへの接続を確立する
Elasticsearchクラスターにテキスト埋め込みモデルをロードする
特徴ベクトルと密ベクトルのインデックスを作成するためのマッピングを使用してインデックスを作成します。
テキスト埋め込みとテキスト拡張のための推論プロセッサを備えた取り込みパイプラインを作成する

語彙検索 - スパース検索

テキストクエリに基づいて Elasticsearch がドキュメントの関連性をランク付けする従来の方法では、 語彙検索用のスパース モデルである BM25 モデルの Lucene 実装が使用されます。この方法は、正確な用語の一致を探すという、テキスト検索の従来のアプローチに従います。

この検索を可能にするために、Elasticsearch はテキスト分析を実行してテキストフィールドデータを検索可能な形式に変換します。

テキスト分析は、検索に関連するトークンを抽出するプロセスを管理する一連のルールであるアナライザーによって実行されます。アナライザーには、トークナイザーが 1 つだけ必要です。トークナイザーは文字のストリームを受け取り、それを個々のトークン (通常は個々の単語) に分割します。以下に例を示します。

語彙検索のための文字列トークン化

#Performs text analysis on a string and returns the resulting tokens. # Define the text to be analyzed text = "Comfortable furniture for a large balcony" # Define the analyze request request_body = { "analyzer": "standard", "text": text } # Perform the analyze request response = client.indices.analyze(analyzer=request_body["analyzer"], text=request_body["text"]) # Extract and display the analyzed tokens tokens = [token["token"] for token in response["tokens"]] print("Analyzed Tokens:", tokens)

出力

Analyzed Tokens: ['comfortable', 'furniture', 'for', 'a', 'large', 'balcony']

この例では、デフォルトのアナライザーである標準アナライザーを使用しています。これは、英語の文法に基づいたトークン化を提供するため、ほとんどのユースケースに適しています。トークン化により、個々の用語での一致が可能になりますが、各トークンは文字どおりに一致します。

検索エクスペリエンスをカスタマイズしたい場合は、別の組み込みアナライザーを選択できます。たとえば、ストップアナライザーを使用するようにコードを更新すると、ストップワードの削除がサポートされ、文字以外の文字でテキストがトークンに分割されます。

... # Define the analyze request request_body = { "analyzer": "stop", "text": text } ...

出力

Analyzed Tokens: ['comfortable', 'furniture', 'large', 'balcony']

組み込みアナライザーがニーズを満たさない場合は、ゼロ個以上の文字フィルター、トークナイザー、およびゼロ個以上のトークンフィルターの適切な組み合わせを使用するカスタムアナライザーを作成できます。

"analyzer": { "my_analyzer": { "type": "custom", #For custom analyzers, use a type of custom or omit the type parameter. "tokenizer": "standard", #Built-in or customized tokenizer "filter": ["lowercase", "synonym"] #Built-in or customized token filters } }

トークナイザーとトークンフィルターを組み合わせた上記の例では、テキストは、同義語トークンフィルターによって処理される前に、小文字フィルターによって小文字化されます。

語彙マッチング

BM25 は、用語の頻度と重要度に基づいて、特定の検索クエリに対するドキュメントの関連性を測定します。

以下のコードは、一致クエリを実行し、 「ecommerce-search」 インデックスの 「description」 フィールド値と検索クエリ 「 Comfortable furniture for a large balcony 」 を考慮して最大 2 つのドキュメントを検索します。

このクエリに一致すると見なされるドキュメントの基準を絞り込むと、精度が向上します。ただし、より具体的な結果を得るには、変動に対する許容度が低くなるというデメリットがあります。

# BM25 response = client.search(size=2, index="ecommerce-search", query= { "match": { "description" : { "query": "Comfortable furniture for a large balcony", "analyzer": "stop" } } } ) hits = response['hits']['hits'] if not hits: print("No matches found") else: for hit in hits: score = hit['_score'] product = hit['_source']['product'] category = hit['_source']['category'] description = hit['_source']['description'] print(f"\nScore: {score}\nProduct: {product}\nCategory: {category}\nDescription: {description}\n")

出力

Score: 15.607948 Product: Barbie Dreamhouse Category: Toys Description: is a classic Barbie playset with multiple rooms, furniture, a large balcony, a pool, and accessories. It allows kids to create their dream Barbie world. Score: 9.137739 Product: Comfortable Rocking Chair Category: Indoor Furniture Description: enjoy relaxing moments with this comfortable rocking chair. Its smooth motion and cushioned seat make it an ideal piece of furniture for unwinding.

出力を分析すると、最も関連性の高い結果は「 おもちゃ 」カテゴリの「バービードリームハウス」製品であり、その説明には「家具」、「 大型」 、「バルコニー」という用語が含まれているため関連性が高く、説明に検索クエリに一致する用語が 3 つ含まれている唯一の製品であり、説明に「バルコニー」という用語が含まれているのもこの製品のみです。

2 番目に関連性の高い製品は、「屋内用家具」に分類される「快適なロッキングチェア」で、その説明には「 快適な 」および「家具」という用語が含まれています。データセット内のこの検索クエリの少なくとも 2 つの用語に一致する製品は 3 つだけであり、この製品はそのうちの 1 つです。

「快適」という言葉は 105 製品の説明に登場し、 「家具」という言葉は、おもちゃ、屋内用家具、屋外用家具、および「犬と猫の用品とおもちゃ」という 4 つのカテゴリーの 4 製品の説明に登場しています。

ご覧のとおり、クエリを考慮すると最も関連性の高い製品はおもちゃであり、2 番目に関連性の高い製品は屋内用家具です。これらのドキュメントが一致する理由を知るためにスコア計算に関する詳細な情報が必要な場合は、 explain __query パラメータを true に設定できます。

両方の結果が最も関連性の高いものであるにもかかわらず、このデータセット内のドキュメントの数と用語の出現の両方を考慮すると、クエリ「大きなバルコニー用の快適な家具」の背後にある意図は、おもちゃや室内用家具などを除いた、実際の大きなバルコニー用の家具を検索することです。

語彙検索は比較的単純かつ高速ですが、ユーザーの意図やクエリを必ずしも知らずにすべての用語と同義語を知ることが常に可能であるとは限らないため、限界があります。自然言語の使用においてよく見られる現象は語彙の不一致です。調査によると、平均して80% の確率で、異なる人々 (同じ分野の専門家) が同じものを異なる名前で呼ぶことがわかっています。

これらの制限により、意味的知識を組み込んだ他のスコアリングモデルを探すことになります。自然言語のような連続的な入力トークンの処理に優れたトランスフォーマーベースのモデルは、ドキュメントとクエリの両方の数学的表現を考慮して、検索の根本的な意味を捉えます。これにより、テキストの高密度でコンテキストを認識したベクトル表現が可能になり、関連するコンテンツを見つけるための洗練された方法であるセマンティック検索が強化されます。

セマンティック検索 - 高密度検索

このコンテキストでは、データを意味のあるベクトル値に変換した後、 k 最近傍 (kNN)検索アルゴリズムを使用して、データセット内でクエリベクトルに最も類似したベクトル表現を検索します。Elasticsearch は、kNN 検索に、正確なブルートフォース kNNと近似 kNN (ANN とも呼ばれる) の 2 つの方法をサポートしています。

ブルートフォース kNN は正確な結果を保証しますが、大規模なデータセットでは適切に拡張できません。近似 kNN は、パフォーマンスを向上させるために精度をある程度犠牲にして、近似最近傍を効率的に見つけます。

Lucene の kNN 検索と高密度ベクトルインデックスのサポートにより、Elasticsearch は階層的ナビゲート可能スモールワールド (HNSW) アルゴリズムを活用し、さまざまなann ベンチマークデータセットにわたって強力な検索パフォーマンスを発揮します。以下のサンプルコードを使用して、Python で近似 kNN 検索を実行できます。

近似kNNによるセマンティック検索

# KNN - approximate kNN response = client.search(index='ecommerce-search', size=2, knn={ "field": "description_vector.predicted_value", "k": 50, # Number of nearest neighbors to return as top hits. #The optimal value of k is dependent on the data. It can vary in different scenarios. "num_candidates": 500, # Number of nearest neighbor candidates to consider per shard. #Increasing num_candidates tends to improve the accuracy of the final k results. "query_vector_builder": { # Object indicating how to build a query_vector. kNN search enables you to perform semantic search by using a previously deployed text embedding model, the steps for this process are demonstrated in the Python notebook. "text_embedding": { "model_id": "sentence-transformers__all-mpnet-base-v2", # Text embedding model id "model_text": "Comfortable furniture for a large balcony" # Query } } } ) for hit in response['hits']['hits']: score = hit['_score'] product = hit['_source']['product'] category = hit['_source']['category'] description = hit['_source']['description'] print(f"\nScore: {score}\nProduct: {product}\nCategory: {category}\nDescription: {description}\n")

このコードブロックは、Elasticsearch の kNN を使用して、製品データセットの「 description 」フィールドの埋め込みを考慮した「大きなバルコニー用の快適な家具 」のベクトル化されたクエリ (query_vector_build) に類似した説明を持つ最大 2 つの製品を返します。

製品の埋め込みは、以前はパイプラインに取り込まれたデータに対して推論するための「 all-mpnet-base-v2 」テキスト埋め込みモデルを含む推論プロセッサを使用して、取り込みパイプラインで生成されていました。

このモデルは、「 sentence_transformers.evaluation 」を使用した事前学習済みモデルの評価に基づいて選択されました。トレーニング中にさまざまなクラスを使用してモデルを評価します。「all-mpnet-base-v2」モデルは、Sentence-Transformers ランキングで最高の平均パフォーマンスを示し、 Massive Text Embedding Benchmark (MTEB)リーダーボードでも好位置を獲得しました。このモデルは、Microsoft/mpnet ベースのモデルを事前トレーニングし、10 億の文のペアのデータセットで微調整されており、文を 768 次元の密なベクトル空間にマッピングします。

あるいは、特にドメイン固有のデータに合わせて微調整されたモデルなど、使用できる他のモデルも多数あります。

出力

Score: 0.79207325 Product: Patio Sofa Set with Ottoman Category: Outdoor Furniture Description: is a versatile and comfortable patio sofa set, including a sofa, ottoman, and coffee table, great for outdoor lounging. Score: 0.7836937 Product: Patio Sofa Set with Canopy Category: Outdoor Furniture Description: is a luxurious and comfortable patio sofa set with a canopy, providing shade and style for outdoor lounging.

出力は、選択したモデル、 フィルター 、および おおよその kNN チューニング によって異なる場合があります。

kNN 検索結果は両方とも「 Outdoor Furniture 」カテゴリにありますが、クエリの一部として「 outdoor 」という単語が明示的に言及されておらず、コンテキストにおけるセマンティクスの理解の重要性が強調されています。

高密度ベクトル検索にはいくつかの利点があります。

セマンティック検索の有効化
非常に大規模なデータセットを処理できるスケーラビリティ
幅広いデータタイプを処理できる柔軟性

しかし、高密度ベクトル探索には独自の課題もあります。

ユースケースに適した埋め込みモデルの選択
モデルが選択されると、ドメイン固有のデータセットでのパフォーマンスを最適化するためにモデルを微調整する必要がある場合があり、このプロセスにはドメイン専門家の関与が求められる。
さらに、高次元ベクトルのインデックス作成は計算コストが高くなる可能性がある。

セマンティック検索 - 学習されたスパース検索

別のアプローチとして、セマンティック検索を実行する別の方法である学習済みスパース検索を検討してみましょう。

スパースモデルとして、数十年にわたる最適化の恩恵を受けている Elasticsearch の Lucene ベースの転置インデックスを活用します。ただし、このアプローチは、BM25 などの語彙スコアリング関数を使用して同義語を単純に追加するだけにとどまりません。代わりに、より深い言語スケールの知識を使用して学習した関連性を組み込み、関連性を最適化します。

Elastic Learned Sparse Encoder は、検索クエリを拡張して元のクエリには存在しない関連用語を含めることにより、以下の例に示すように、スパースベクトル埋め込みを改善します。

Elastic Learned Sparse Encoder によるスパースベクトル検索

# Elastic Learned Sparse Encoder response = client.search(index='ecommerce-search', size=2, query={ "text_expansion": { "ml.tokens": { "model_id":"elser_model", "model_text":"Comfortable furniture for a large balcony" } } } ) for hit in response['hits']['hits']: score = hit['_score'] product = hit['_source']['product'] category = hit['_source']['category'] description = hit['_source']['description'] print(f"\nScore: {score}\nProduct: {product}\nCategory: {category}\nDescription: {description}\n")

出力

Score: 14.405318 Product: Garden Lounge Set with Side Table Category: Garden Furniture Description: is a comfortable and stylish garden lounge set, including a sofa, chairs, and a side table for outdoor relaxation. Score: 14.281318 Product: Rattan Patio Conversation Set Category: Outdoor Furniture Description: is a stylish and comfortable outdoor furniture set, including a sofa, two chairs, and a coffee table, all made of durable rattan material.

この場合の結果には、「 屋外用家具 」に非常に類似した製品を提供する「 ガーデン家具 」カテゴリが含まれます。

「ml.tokens」を分析すると、学習済みスパース検索によって生成されたトークンを含む「rank_features」フィールドを見ると、生成されたさまざまなトークンの中に、「リラックス」（快適）、「ソファ」（家具）、「屋外」（バルコニー）など、検索クエリの一部ではないものの、意味的には関連している用語があることがわかります。

以下の画像は、用語拡張ありとなしの両方で、クエリとともにこれらの用語の一部を強調表示しています。

ご覧のとおり、このモデルはコンテキスト認識型の検索を提供し、より解釈しやすい結果を提供しながら語彙の不一致の問題を軽減するのに役立ちます。ドメイン固有の再トレーニングが適用されない場合でも、高密度ベクトルモデルよりも優れたパフォーマンスを発揮します。

ハイブリッド検索: 語彙検索と意味検索を組み合わせた関連性の高い結果

検索に関しては、普遍的な解決策はありません。これらの検索方法にはそれぞれ長所がありますが、課題もあります。ユースケースに応じて、最適なオプションは変わる場合があります。多くの場合、複数の検索方法間で最良の結果が補完的になります。したがって、関連性を高めるために、それぞれの方法の長所を組み合わせることを検討します。

ハイブリッド検索を実装する方法は複数あります。線形結合、各スコアへの重み付け、重みの指定が不要な逆ランク融合 (RRF) などです。

Elasticsearch: 語彙検索と意味検索の両方の長所を活用

# BM25 + Elastic Learned Sparse Encoder (Linear Combination) response = client.search(index='ecommerce-search', size=2, query= { "bool": { "should": [ { "match": { "description" : { "query": "A dining table and comfortable chairs for a large balcony", "boost": 1 } } }, { "text_expansion": { "ml.tokens": { "model_id": "elser_model", "model_text": "A dining table and comfortable chairs for a large balcony", "boost": 1 } } } ] } } ) # The boost value is 1 for the text expansion and match query. This means that the relevance score of the results of these queries are not boosted. You can specify a boost value to give a weight to each score in the sum. The scores will be calculated as: score = boost value * match_score + boost value * text_expansion_score for hit in response['hits']['hits']: score = hit['_score'] product = hit['_source']['product'] category = hit['_source']['category'] description = hit['_source']['description'] print(f"\nScore: {score}\nProduct: {product}\nCategory: {category}\nDescription: {description}\n")

このコードでは、「大きなバルコニー用のダイニングテーブルと快適な椅子」という値を持つ 2 つのクエリを使用してハイブリッド検索を実行しました。検索語として「家具」を使用する代わりに、探しているものを指定しており、両方の検索で同じフィールド値「説明」を考慮しています。ランキングは、BM25 スコアと ELSER スコアに等しい重み付けをした線形結合によって決定されます。

出力

Score: 31.628141 Product: Garden Dining Set with Swivel Rockers Category: Garden Furniture Description: is a functional and comfortable garden dining set, including a table and chairs with swivel rockers for easy movement. Score: 31.334227 Product: Garden Dining Set with Swivel Chairs Category: Garden Furniture Description: is a functional and comfortable garden dining set, including a table and chairs with swivel seats for convenience.

以下のコードでは、クエリに同じ値を使用しますが、逆ランク融合法を使用して BM25 (クエリパラメータ) と kNN (knn パラメータ) のスコアを結合し、ドキュメントを結合してランク付けします。

# BM25 + KNN (RRF) response = client.search(index='ecommerce-search', size=2, query={ "bool": { "should": [ { "match": { "description": { "query": "A dining table and comfortable chairs for a large balcony" } } } ] } }, knn={ "field": "description_vector.predicted_value", "k": 50, "num_candidates": 500, "query_vector_builder": { "text_embedding": { "model_id": "sentence-transformers__all-mpnet-base-v2", "model_text": "A dining table and comfortable chairs for a large balcony" } } }, rank={ "rrf": { # Reciprocal rank fusion "window_size": 50, # This value determines the size of the individual result sets per query. "rank_constant": 20 # This value determines how much influence documents in individual result sets per query have over the final ranked result set. } } ) for hit in response['hits']['hits']: rank = hit['_rank'] category = hit['_source']['category'] product = hit['_source']['product'] description = hit['_source']['description'] print(f"\nRank: {rank}\nProduct: {product}\nCategory: {category}\nDescription: {description}\n")

RRF 機能はテクニカルプレビュー段階です。GA の前に構文が変更される可能性があります。

出力

Rank: 1 Product: Patio Dining Set with Bench Category: Outdoor Furniture Description: is a spacious and functional patio dining set, including a dining table, chairs, and a bench for additional seating. Rank: 2 Product: Garden Dining Set with Swivel Chairs Category: Garden Furniture Description: is a functional and comfortable garden dining set, including a table and chairs with swivel seats for convenience.

ここでは、異なるフィールドと値を使用することもできます。これらの例のいくつかは、 Python ノートブックで利用できます。

ご覧のとおり、Elasticsearch を使用すると、従来の語彙検索とベクトル検索（疎かでも密かでも）の両方の利点を活用でき、目標を達成して質問に対する最適な回答を見つけることができます。

ここで説明したアプローチについてさらに学習したい場合は、次のブログが役立ちます。

Elasticsearch は、ベクター検索を構築するために必要なすべてのツールとともに、ベクターデータベースを提供します。

Elasticsearchベクターデータベース
Elasticによるベクトル検索のユースケース

まとめ

このブログ記事では、Elasticsearch を使用して情報を取得するためのさまざまなアプローチについて検討し、特にテキスト、語彙、意味の検索に焦点を当てました。これを実証するために、eコマース製品情報を含むデータセットを使用してさまざまな検索シナリオを紹介する Python の例を示しました。

BM25 を使用した従来の語彙検索をレビューし、語彙の不一致などの利点と課題について議論しました。この問題を克服するために、意味的知識を取り入れることの重要性を強調しました。さらに、セマンティック検索を可能にする高密度ベクトル検索について説明し、高次元ベクトルのインデックス作成時の計算コストなど、この検索方法に関連する課題についても説明しました。

一方、スパースベクトルは圧縮率が非常に高いことを説明しました。そこで、元のクエリには存在しない関連用語を含めるように検索クエリを拡張する Elastic の Learned Sparse Encoder について説明しました。

検索に関しては、万能の解決策は存在しません。それぞれの検索方法には長所と課題があります。そこで、ハイブリッド検索の概念についても議論しました。

ご覧のとおり、Elasticsearch を使用すると、従来の語彙検索とベクトル検索の両方の長所を活用できます。

始める準備はできましたか?利用可能なPython ノートブックを確認し、 Elastic Cloud の無料トライアルを開始してください。

Python - Elasticsearch Labs

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

始まり

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

実装

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

Peaks_catalogインデックス

写真インデックス

検索ユースケース

流線型のUI

まとめ

ユーザー行動データに基づく判断リストを使用して Elasticsearch で LTR モデルをトレーニングする

UBIデータがLTRモデルのトレーニングに役立つ理由

成績計算

LTRトレーニングのグレード

成績の計算 - COECアルゴリズム

技術的な実装

クイックスタート

データアーキテクチャ

Ubiクエリ

Ubiクリックイベント

判定リスト生成スクリプト

スクリプトの一般的な概要

connect_to_elasticsearch()

fetch_ubi_data()

プロセスubi_data()

関連性グレードを計算する()

判断統計を生成する()

結果と影響

まとめ

ES|QL を使用した Elasticsearch 地理空間検索

地理空間データの検索

なぜSQLではないのですか?

SQLとの違い

OGC関数

ES|QLの汎用性

空間結合

Kibanaマップ

新しいエクスペリエンス

検索関連性の評価パート1－BEIRベンチマーク

検索関連性評価におけるBEIRベンチマークの理解

BEIRデータセットの構造

検索関連性評価におけるBEIRベンチマークの活用

主なポイントと次のステップ

AI盗作：Elasticsearchによる盗作検出

生成AIによる盗作検出

Elasticsearchで盗作を検出する

まとめ

Elasticsearch による語彙検索と意味検索

要件

語彙検索 - スパース検索

語彙検索のための文字列トークン化

語彙マッチング

セマンティック検索 - 高密度検索

近似kNNによるセマンティック検索

セマンティック検索 - 学習されたスパース検索

Elastic Learned Sparse Encoder によるスパースベクトル検索

ハイブリッド検索: 語彙検索と意味検索を組み合わせた関連性の高い結果

Elasticsearch: 語彙検索と意味検索の両方の長所を活用

まとめ