新規ユーザーにとって、これは高品質なベクトル検索を最も迅速に開始する方法です。すでにElasticsearchをご利用の場合は、新しいシステムを導入する必要はなく、データが既に存在するプラットフォーム上でベクトル検索を利用できるようになります。Elasticsearch Vector Databaseは、大規模言語モデル（LLM）のグラウンディングから、AIエージェントへの検索機能とメモリの提供、数千億ものベクトルの提供まで、幅広いシナリオをサポートします。わずか数分で新しいプロジェクトを立ち上げ、開始できます。

1つのエンジン、あらゆるベクトルユースケース

Elasticsearch Vector Databaseは、ベクトルを使用してアプリケーションを構築するすべての人向けに設計されています。

• RAG：高密度ベクトル検索と低密度ベクトル検索でLLMに最適なコンテキストを取得するか、ベクトル検索と語彙検索の両方を組み合わせたハイブリッド検索を利用できます。生成結果の質は、検索結果の質に比例して向上します。

• AIエージェント：マルチステップのエージェントループで求められる低レイテンシで、ドキュメントや会話記憶に対する高速でフィルタリングされた検索をエージェントに提供します。

• セマンティック検索：1つのフィールドタイプとパイプラインコード不要で、キーワードではなく意味に基づいて一致させます。

• レコメンデーションと類似性：製品、画像、その他あらゆるコンテンツにわたり、大規模なスケールで最近傍を検索できます。

ベクトルワークロードに必要なすべてを、すぐに使えるよう最適化

ベクトルベースのアプリケーションを構築するには、いくつかの個別の要素を連携させる必要があります。具体的には、埋め込みモデルの設定とホスティング、それらを用いたドキュメントのインデックス作成、ベクトルの効率的な保存、各クエリへの埋め込みモデルの適用、ベクトルストアとの照合、そして最後に、一致したドキュメントの取得です。Elasticsearch Vector Databaseは、追加の設定やセットアップなしで、これらすべてを自動的に処理します。

vectordb_documentインデックスモードを使用したベクトルのインデキシング

ベクトル優先ワークロード専用に設計された新しいインデックス構成であるvectordb_documentインデックスモードはデフォルトで有効になっており、エキスパートが選択するような設定が適用されます。以下が有効化されます。

• デフォルトでbfloat16：ベクトルはfloat32の半分のサイズで格納され、再現率への影響はごくわずかで、量子化を適用する前の段階でもディスク使用量をほぼ半分に削減します。

• ソースベクトルの除外：Elasticsearchでは、埋め込みはすでに検索に使用されるインデックス構造内に存在します。_sourceに未加工のコピーを重複して保持すると、ストレージを消費し、結果の取得が遅くなるだけです。重複を除外することで、レスポンスが高速化され、格納するデータ量を削減できます。

• 適切なファイルをキャッシュに事前読み込み：ベクトルクエリが最初にアクセスするデータ構造があらかじめメモリに読み込まれるされるため、1番目の（そして1,000番目の）クエリも超高速で実行されます。

• 並列マージ：マージによってセグメントがより整理されたベクトル構造に統合され、再現率とレイテンシーの両方が向上します。さらに、これらのマージをマルチスレッドで実行することで、より高速に完了できます。

ベクトルストレージ、圧縮、自動チューニング

• ベクトルは自動的に圧縮されます。Better Binary Quantization（BBQ）により、再現率を維持しながらベクトルのメモリ・フットプリントを最大32倍削減できます。さらに、DiskBBQは大規模なワークロードのメモリ要件をさらに削減します。 

• 自動キャリブレーションを有効にすると、各セグメントの量子化がデータに合わせて調整され、データのずれに応じてマージのたびに再調整されます。18種類のデータセットでテストを行った結果、1秒あたりのクエリ数（QPS）は平均16.7%向上し、そのほとんどで再現率も向上しました。

マネージドGPU推論での埋め込み

• ネイティブのJina AIの埋め込みモデルとリランカーモデルで埋め込みを生成することも、サードパーティ製モデルを導入することもできます。いずれもElastic Inference Service（EIS）を介したマネージドGPUで実行でき、モデルサーバーを運用する必要はありません。または、ご自身でホストすることも可能です。

• semantic_textフィールドタイプは、チャンキングと埋め込み、そしてクエリを自動的に処理し、市場で最もシンプルなセマンティック検索への道を提供します。

ハイブリッド検索とフィルタリングされたベクトル検索

• ハイブリッド検索が組み込まれており、単一のクエリで全文検索とベクトル検索を組み合わせることができます。逆順位融合（RRF）やその他の任意のブレンドメカニズムを使用して結果を統合できます。通常、ベクトル検索はハイブリッド検索の中で適切に設定するのが最も難しい部分です。Elasticsearch Vector Databaseを使用すれば、その問題は解決し、ハイブリッドスタック全体の性能が向上します。

• フィルタリングされたベクトル検索では、再現率を損なう後処理としてではなく、ベクトル検索自体の一部としてメタデータフィルタを適用できます。

初日からエンタープライズ対応

また、純粋なベクトルデータベースには一般的に備わっていない、ロールベースのアクセス制御（RBAC）、監査ログ、コンプライアンス認定も利用できます。

スケールしても手頃で予測可能

Elasticsearch Vector Databaseは、成長に合わせてコスト効率を維持できるように設計されています。ストレージを線形に保ち、メモリ使用量を低く抑えるBBQおよびDiskBBQ圧縮により、数千億のベクトルに拡張してもコストが急増することはありません。支払う料金は、格納するデータ量、作成するインデックス量、必要な検索容量など、すでに把握している数値に基づいて算出されます。ドキュメント数、ベクトルの次元数、クエリ負荷を見積もれば、プロジェクトを作成する前に料金を算出できます。月末には、請求内容を項目ごとに確認することもできます。不透明な計算ユニットはなく、バックグラウンド処理に対する予期せぬ料金も発生しません。

Elasticsearch Vector Databaseの利用開始方法

サーバーレスベクトルデータベースプロジェクトを作成する

Elastic Cloudで新しいサーバーレスVector Databaseプロジェクトを作成します。データをエンドポイントに向ければ、インデックスの準備は完了です。

semantic_textを使用したインデックスの作成

ベクトルインデックスモードは、ベクトルの構成を処理します。semantic_textを使用すると、マネージドGPU推論上でインデックス設定と同様に埋め込みやチャンキングの設定も自動的に管理されるため、埋め込みパイプラインを構築する必要はありません。

ドキュメントを投入する

テキストをインデックスすると、埋め込みが自動的に生成されます。

セマンティック検索クエリを実行する

先ほど作成したセマンティックフィールドをクエリします。

そして、結果が返されます。

セマンティック検索は始まりにすぎません。完全なテキストクエリを実行することも、両方を組み合わせてハイブリッドクエリにすることもできます。独自のベクトルクエリを作成して、完全に制御することもできます。詳しい手順については、ドキュメントのセマンティック検索クイックスタートをご覧ください。

Elasticsearchにおけるベクトル検索の今後

私たちは既に次の改善に取り組んでいます。

• より優れたマルチテナント処理：テナントごとにデータを分離する必要がある場合、より少ないコードでより迅速に実現する方法を提供します。

• インデックスの自動最適化：できるだけ手をかけずに、「新規作成直後のインデックス」から「完全に最適化済み」へ。

• 継続的なインフラストラクチャーの改善：Vector Databaseの設定とインフラストラクチャーを継続的に調整することで、常に最高のスループットと最速の対応を得られるようにします。

Elastic Cloud ServerlessでElasticsearchベクトルデータベースをお試しください

本番環境レベルのデフォルト設定がチューニングを行うため、空のプロジェクトから数分でフィルター適用済みのハイブリッドベクトルクエリを作成できます。インフラの構築ではなく、高速でスケーラブルなAIアプリの構築に専念しましょう。

Elastic Cloud Serverlessを開始するか、詳細ドキュメントとAPIリファレンスをご覧ください。

リコールとは何ですか？

再現率は、0から1のスケールで、ユーザーが実際に欲しいドキュメントが検索結果にどれだけ含まれているかを測定します。クエリで3点の製品が表示されるはずなのに、検索結果の上位10位に2つしか表示されない場合は、そのクエリの再現率はrecall@10 = 0.67となります。これは集合ベースの指標であり、そのk件の結果内の関連ドキュメントの位置は考慮されません。10番目の位置にある関連ドキュメントは、1番目の位置にある関連ドキュメントと同じものとして扱われます。再現率が高いということは、関連性の高い検索結果を見逃さないということです。

この図は2つの集合を示しています。1つは関連するすべてのドキュメント（左側）、もう1つはBM25が実際に取得したドキュメント（上位10件、右側）です。再現率に影響する交差部分、prod_1とprod_2が見つかり、prod_3、prod_4、prod_6は完全に見落とされました。結果：Recall@10 = 2/5 = 0.40。

要件

再現率がどのように機能するのかをよりよく理解するために、本題に入りましょう。このデモンストレーションではPythonを使用します。付属のノートブック（notebook.ipynb）で一緒に進めることができます。すべてのコードブロックは、実行準備が整ったセルです。

提供されたコードでは、以下を使用しています。

• Elasticsearch 9.3以降

• Python 3.10+

• Elasticsearchの認証情報が含まれる.envファイル

データセット

靴、電子機器、工具など、さまざまなカテゴリーにわたる1,000点の製品を掲載した製品カタログを使用します。

各ドキュメントには4つのフィールドがあります。

フィールド

タイプ

`タイトル`

テキスト

`description`

テキスト

`ブランド`

キーワード

`category`

キーワード

データセットは dataset.csvから読み込まれます。

語彙検索の力と限界

BM25は、Elasticsearchおよびほとんどの検索エンジンのデフォルトのランキングアルゴリズムです。ドキュメントは、クエリ用語がどれだけ頻繁に出現するかによってスコアリングされます。これは、ドキュメントの長さと、インデックス全体でのそれらの用語の頻度に合わせて調整されます。さらに、小文字への正規化、語幹抽出、ストップワード除去といったアナライザーも搭載されています。「running shoes」というクエリは、「Running Shoes」と一致し、おそらく「run」とも一致します。

これは、多くの種類のクエリに対して有効です。

• 「running shoes」はタイトルにこれらのトークンを含む商品を即座にマッチングします。

• 「Bluetoothスピーカー」は、トークンが逐語的に表示されるため、携帯オーディオ製品として表示されます。

結果は決定論的で説明可能です。つまり、検索クエリに含まれる用語がドキュメント中に含まれているからこそ、そのドキュメントは上位にランク付けされるのです。関連性のデバッグは単純明快です。

問題が発生する箇所

では、同じカタログに対してこれらのクエリを試してみましょう。

• 「スキンケアルーティン」：どの製品名にも「ルーティン」という単語は含まれません。BM25は、「スキンケア」で部分一致することができますが、フェイス美容液、ボディオイル、モイスチャライザーは、「ビタミンC」、「レチノール」、または「ブライトニング」のような用語を使用して説明されており、いずれもクエリと重複しません。完全なスキンケアルーティンを形成する製品は、共通のトークンを持たずにインデックス全体に散らばっています。

• 「ペット用旅行用品」：これはユースケースのグループ分けであり、製品カテゴリではありません。犬用スリングキャリア、ペット用カーシート、旅行用クレートはどれも関連性のあるアイテムですが、それらの説明文は「旅行用品」というよりは、携帯性、安全性、快適性について述べています。BM25は「ペット」と大まかに一致しますが、旅行固有の商品を他のペットカタログと区別するシグナルはありません。

これは 再現率の問題です。関連するドキュメントはインデックスに存在しますが、ユーザーの言葉と文書の単語が十分に一致しないため、BM25はそれらを見つけることができません。

同義語を追加することは、既知の事例に役立ちますが、ユーザーが意図を表現するすべての方法を列挙することはできません。そこでベクトルが役立ちます。

リコールを測定すべき理由

問題を解決する前に、まずそれを定量化する必要があります。

Recall@kは、ユーザーが実際に求めているドキュメントのうち、検索結果に表示されるドキュメントの数を測定します。正式には：

Precision@kは、上位k件の結果のうち、実際にどれだけ関連性があるかを測定します。

高精度とは、得られる結果が良好であることを意味します。電子商取引においては、関連商品を見落とすこと（再現率の低さ）は、多少不完全な結果を表示すること（精度の低さ）よりも深刻です。なぜなら、商品が表示されないということは、販売機会の損失を意味するからです。

Elasticsearchのrank_eval APIは、両方を体系的に測定できます。それぞれに評価されたドキュメントを含むクエリのリストを提供すると、Elasticsearchがすべてのクエリのメトリックを計算します。

評価の設定

rank_eval APIには評価データセットが必要です。これは、クエリとそれに関連するドキュメントのマッピング、および関連性グレード（0 = 関連性なし、1 = 関連性あり、2 = 非常に関連性あり）で構成されます。

ノートブックでは、これは判断リストです。

この組み合わせは意図的なものです。 q1はBM25が適切に処理するクエリ（製品タイトル内の正確なトークン）であり、 q2 、 q3 、 q4はユーザーの意図が特定の製品キーワードではなく概念として表現されるインテントベースのクエリです。

BM25ベースライン再現率の測定

まず、Elasticsearchクライアントを設定し、生のテキストデータをインデックス化します。

次にBM25のrank_evalリクエストを作成しましょう。リスト内の各リクエストは、クエリとその評価を組み合わせたものです。

次の結果が得られます。

0.43 は、4つのクエリすべてで、BM25が見つけるべきドキュメントの43%しか見つけられないということです。不足している点は、意図に基づくクエリに集中している。「スキンケアルーティン」という検索では、「ルーティン」が製品タイトルに含まれていないため、フェイス美容液やボディオイルが見つかりません。また、「ペット用旅行用品」という検索では、旅行用品ではなく携帯性や安全性の観点から説明されているキャリーケースやクレートが見つからない一方で、関連性のないペット用品が検索結果に表示されます。

これがベースラインです。これで、破るべき数値ができました。

Jina埋め込みを用いたベクトル検索機能の追加

Vector search はドキュメントとクエリを高次元ベクトルとしてエンコードします。高次元ベクトルとは、数百または数千の数値から構成されるベクトルの一種で、各数値はそれが表すデータの特定の特徴をエンコードします。意味が似ているドキュメントは、たとえ共通の単語が一つもなくても、ベクトル空間上では互いに近い位置に配置されます。「ジム器具」と「ダンベルセット」は、概念が関連しているため、近くに配置されるでしょう。私がベクトルデータベースとしてElasticsearchを選んだ理由は、ハイブリッド検索をサポートしており、セマンティックな理解とキーワードの精度をすぐに実現できるからです。

EISには、推論APIを通じてモデル埋め込みを標準でサポートする機能が含まれています。

ステップ1：Jina埋め込みv5を推論エンドポイントとして使用する

クラスターにGPUリソースがある場合（Elastic CloudおよびElasticsearch 9.3以降で利用可能）、埋め込みはGPU上で生成されます。これはCPU推論よりも大幅に高速であり、従来、大規模な環境でベクトル処理を高価にしていたパフォーマンスのトレードオフを解消します。

なぜJina埋め込みが特に重要なのでしょうか。JINA-embeddings-v5-textは、32,000トークンのコンテキストウィンドウを持ち、タスク固有の Low-Rank Adaptation (LoRA) アダプターをサポートする多言語モデル（119言語以上に対応）です。短い商品説明であれば、そのままでも十分に機能します。jina-embeddings-v5-textモデルの詳細についてはこちらをご覧ください。

ステップ2：セマンティックフィールドを持つインデックスを作成

ここで重要なのは semantic_text フィールドタイプです。これはdense_vectorよりも高レベルの抽象化です。推論エンドポイントを指定すると、Elasticsearchが埋め込みの生成を自動的に行います。

copy_toプロパティがtitleとdescriptionにある場合、両方のフィールドのコンテンツがsemantic_fieldに流れ込んで埋め込まれるため、単一のベクトルで製品の完全な表現を捉えることができます。

ステップ3：製品をインデックス化する

インデックス時には、Elasticsearchは各文書の推論エンドポイントを呼び出し、その結果得られた埋め込みをsemantic_fieldに保存します。余計なコードは必要ありません。

ハイブリッド検索：BM25とベクトルおよびRRFの組み合わせ

ベクトルを追加すると再現率は向上しますが、ベクトルのみを使用すると、完全一致クエリの精度が低下するリスクがあります。「ランニングシューズ」は、依然として逐語的に一致するものを最優先にランク付けするべきです。ハイブリッド検索は、その精度を維持するために、語彙要素を意図的に保持します。

ハイブリッド逆順位融合（RRF）検索は、両方の長所を保持します。

• BM25は正確およびほぼ正確なクエリを高精度で処理します。

• セマンティック検索は、意図に基づく多言語クエリを高い再現率で処理します。

• RRFは2つのランキングリストを1つのランキングに統合します。

RRF式は、各結果リストのランクに基づいて各文書にスコアを割り当てます。

両方のリストで上位に表示されるドキュメントほど、統合スコアは高くなります。rank_constantは、より低いランクの文書に与えられる重みを制御します。

次の結果が得られます。

ハイブリッドはBM25（0.43）よりも大幅に改善されており、「ランニングシューズ」のような完全一致クエリに対しても精度を維持します。

結果：ビフォーアフター

3つのアプローチの完全な比較は次のとおりです。

次の結果が得られます。

メソッド

Recall@10

BM25（語彙）

0.43

ハイブリッド（BM25 + ベクター）

0.75

クエリごとに分解すると次のようになります。

まとめ

この記事を通して、BM25の語彙検索は、ユーザーが正確なクエリを入力する場合には信頼性が高いものの、キーワードではなく意図に基づいて検索する場合は再現率が低下することがわかりました。rank_evalを用いて、そのギャップを実数で測定するための再現可能な基準を確立しました。そこから、Jina埋め込みを利用したsemantic_textフィールドを追加し、評価を再度実行しました。結果：ハイブリッド検索により、0.43から0.75への再現率が向上し、正確な一致クエリでの精度を維持しました。ただし、実際の差はクエリの組み合わせによって異なります。

このパターンは、この例を超えてスケールします。ユーザーの実際のクエリから判断を収集し、rank_evalをベースラインとして実行し、semantic_textを追加して再度測定します。何がどれだけ改善したかが正確にわかるでしょう。

今後の見通し

• 再現率とベクトル検索についてさらに詳しく：再現率とベクトル検索の量子化（Jeff Vestal著）

• 上位結果の精度をさらに向上させるために再ランキング機能を追加

• Elasticsearchハイブリッド検索のドキュメントをご覧ください。

• rank_eval APIについて詳しくはこちら

Elasticsearch simdvecの構築方法

Elasticsearchにおけるすべてのベクトル検索クエリは、Hierarchical Navigable Small World（HNSW）トラバーサル、転置ファイル（IVF）スキャン、再ランキングパスのいずれであっても、結局は同じ問題に帰着します。すなわち、クエリごとにベクトル間の距離を何百万回も計算しなければならないということです。Elasticsearchは、float32からint8、bfloat16、バイナリ、Better Binary Quantization（BBQ）まで、幅広いデータ型と量子化戦略をサポートしています。それぞれにメモリ、スループット、リコールのトレードオフが異なります。そのすべての背後にあるのは、simdvecという単一のエンジンです。

私たちは、ハードウェアが許す限りすべての距離計算を高速に行うためにsimdvecを構築しました。この記事では、simdvecを構築した理由、その内部構造、そしてどのような場面で最も効果を発揮するのかを説明します。

レースカーのような構造

F1愛好家として（当社チームには以前フェラーリのF1チームで勤務経験があるメンバーもいます）明確な類似点を見いだせます。F1カーは、最高のラップタイムを達成するという唯一の目的のために設計されています。エンジンのパワー、空力性能、シャーシ設計は、その結果に貢献する限りにおいてのみ重要です。ベクトルデータベースについても同様で、インデキシングのスループット、クエリのレイテンシ、リコールが成功を定義します。

最終結果は重要ですが、最高レベルのパフォーマンスを達成するには、各コンポーネントが最高の状態である必要があります。必要十分ではなく、そのカテゴリーで最高でなければなりません。simdvecはその考え方で構築されており、システムの重要な部分であるエンジンに焦点を当てています。これは、専用に構築された、単一命令多重データ（SIMD）最適化カーネルライブラリで、JavaからPanama外部関数インターフェース（FFI）を介して呼び出される、手動で調整されたネイティブC++距離関数を提供します。一括スコアリング、キャッシュラインのプリフェッチ、Elasticsearchで使用されるすべてのベクトルの種類とレイアウトをサポートしています。

それがすべてのクエリの背後にあるエンジンです。

自社開発した理由

当社は2023年にApache LuceneのPanama Vector APIを使用してスタートしました。float32の内積計算にはうまく機能しましたが、すぐにその機能ではElasticsearchのニーズには対応できなくなりました。Elasticsearchは、int8、int4、bfloat16、シングルビット、非対称BBQなど、幅広い量子化されたベクトルタイプをサポートしています。それぞれにSIMD戦略、パッキングレイアウト、アキュムレータの要件が異なります。型カバレッジに加えて、Elasticsearchのスコアリングパスは単一ペアのスループット以上のものを要求します。HNSWは1回のパスで複数のグラフ隣接ノードをスコアリングする必要があり、IVFはプリフェッチを使用して数千の候補を一括スコアリングする必要があり、ディスクベースのスコアリングはコピーせずにmmapされたメモリ上で直接動作する必要があります。入手可能なものを調べてみましたが、すべての条件を満たすものは見つかりませんでした。

そこで、simdvecを構築しました。これは、JavaからFFI経由で呼び出される手作業で調整されたネイティブC++カーネルで、一括スコアリング、プリフェッチ、Elasticsearchが使用するすべてのベクトルタイプをサポートしています。ライブラリを所有することで、私たちはフルスタックを制御できます。BBQのような新しい量子化タイプを追加すると、システム全体にわたって調整されたSIMDカーネルが組み込まれます。上流のライブラリがそれをサポートするのを待つ必要はなく、いかなる型においてもパフォーマンスに妥協することはありません。Elasticsearchにおけるすべてのベクトルクエリ（HNSW、IVF、リランキング、ハイブリッドなど）は、実際に使用する操作とタイプに基づいて構築されたこのエンジン上で実行されます。

simdvecには、x86とARMそれぞれに対応したネイティブライブラリが用意されており、起動時に複数の命令セットアーキテクチャ（ISA）階層を選択できます。FFIを介したJavaからの呼び出しオーバーヘッドは非常に低く、1桁ナノ秒です。

ランドスケープ

SIMD最適化されたベクトル距離カーネルを構築しているのは私たちだけではありません。このエコシステムは豊かで、私たちはsimdvecがどのように動作するのかを理解したいと考えました。プロジェクトの優劣を決めるのではなく、背景情報を提供し、Elasticsearchエンジンの位置づけを説明することが目的です。私たちは異なるアプローチを表す3つのプロジェクトを基準点として選びました。

• jvector：ベクトル化された距離計算にPanama Vector APIを使用するJava近似最近傍探索（ANN）ライブラリ。x86上ではオプションでネイティブCアクセラレーションが可能。

• FAISS：手作業で調整されたAVX2/AVX-512カーネルを備えた、広く展開されているオープンソースのベクトル検索フレームワーク。

• NumKong （旧称 SimSIMD）：距離関数、行列演算、地理空間計算など、2,000種類以上の手作業で調整されたSIMDカーネルを網羅した包括的なスイート。

各プロジェクトは異なる目的を持ち、異なるトレードオフをもたらします。Elasticsearchが必要とする特定の操作におけるsimdvecのパフォーマンスのコンテキストを提供するために、それらからの参照番号を含めています。

測定方法

simdvecとjvectorのベンチマークは、FFIオーバーヘッドを含めた標準JVMマイクロベンチマークハーネスであるJMHを使用してJavaで記述されています。NumKongベンチマークとFAISSベンチマークについては、標準的なC++マイクロベンチマークフレームワークであるGoogle Benchmarkを使って小さなC/C++ハーネスを作成しました。どちらのフレームワークも、ウォームアップと反復キャリブレーションを含めた1操作あたりのナノ秒数の精度を報告しています。ハードウェアパフォーマンスカウンターを介して、すべてのライブラリが両方のプラットフォームでSIMDを使用していることを確認しました。ベンチマークコードはすべて、リンク先のGitHubリポジトリ（およびsimdvecの場合はelasticsearchリポジトリ）で公開されています。

ソフトウェア： JDK 25.0.2、JMH 1.37、GCC 14、Google Benchmark（最新版）。

一度に1つのベクトル

ベクトル検索における最も基本的な操作は、2つのベクトル間の距離を計算することです。すべてのHNSW近隣評価、すべてのIVF候補スコア、すべての再ランク比較は、この内側のループに還元されます。

両プラットフォームで1024次元における単一ペアのスループットを測定しました。まず、ベースラインとなる型であり、エコシステムの競争が最も激しいfloat32から評価を開始しました。simdvecをFAISSおよびjvectorと比較しました。NumKongはfloat32にfloat64アキュムレータを使用するため、スループットよりも数値精度を優先し、処理速度が3.2倍から5.3倍遅くなる（プラットフォームによって異なる）ため、比較対象から除外しました。比較を同じように保つために、代わりにint8でNumKongのベンチマークを行います。ここでは、simdvecと同じアキュムレータ戦略を使用しています。

x86アーキテクチャーでは、FAISS AVX-512が23ナノ秒と最速のシングルペアカーネルです。simdvec AVX-512は28ナノ秒で続きますが、この差はFFI呼び出しのオーバーヘッドを反映したものです。どちらもマルチアキュムレータアンローリングを備えた512ビットFMAを使用しています。AVX2レベルでは、両者の性能差ははるかに小さく、それぞれ36ナノ秒と39ナノ秒で、どちらも256ビットのレジスタとメモリのロード幅によって制約されています。jvectorはJava Panama Vector APIを使用して44ナノ秒で到達します。Panamaは優れたSIMDコードを生成しますが、手作業で調整されたC++ intrinsicsが優位を保っています。

ARMでは、simdvecは70ナノ秒でリードしており、110ナノ秒のjvectorと156ナノ秒のFAISSをはるかに上回っています。simdvecはaarch64向けにNEONカーネルを独自にチューニングしました。JvectorにはネイティブのARMコードがなく、Panamaに依存しています。FAISSは明示的なNEON組み込み関数ではなく、コンパイラの自動ベクトル化に依存しているため、差が大きくなっています。これは、カーネルライブラリを所有することによる実用的な利点を反映しています。ElasticsearchがGravitonに拡張された際、専用に構築されたNEONカーネルを追加しました。jvectorもFAISSも、ARMネイティブコードを同程度に優先しているわけではありません。

しかし、Elasticsearchはfloat32だけを評価するわけではありません。Int8の量子化はメモリ使用量を4分の1に削減し、bfloat16は2分の1に、BBQは32分の1に削減します。それぞれのタイプには独自のSIMD戦略が必要であり、simdvecはすべてのタイプ向けに手動チューニングされたネイティブカーネルを提供しています。

比較したライブラリの中で、int8用の同等のカーネルを備えているものはNumKongのみでした。int8ドット積、二乗ユークリッド、余弦を1024次元で測定しました。

Int8シングルペアスコアリング（1024次元、ns/vec 演算 - 数値が小さいほど良い）

どちらのアーキテクチャでも、NumKongは小～中次元では同等かより高速です。その差は主に呼び出しのオーバーヘッドが少ないことに起因します（Cの直接呼び出しとJavaのFFI）。より大きな次元では、simdvecが追いつき、より効率的なカーネル実装（カスケードアンローリングを使用する）が呼び出しコストを償却します。次元が増えるにつれて、このギャップは閉じ、最終的には逆転します。クロスオーバーのサイズは、機能や構造によって768から1536の間となります。

Java FFIのオーバーヘッドが若干高いにもかかわらず、simdvecは高度に最適化されたC/C++ライブラリと同等の性能を発揮します。float32とint8の両方に対応した最適化されたカーネルを備えた唯一のライブラリであるだけでなく、ARMアーキテクチャではトップクラスの性能を誇り、x86アーキテクチャではFAISSにわずかに劣る程度（float32の場合）、そして両アーキテクチャにおいてNumKongに非常に近い性能（int8の場合）を実現しています。また、bfloat16、int4、binary、BBQについては、代替手段は存在するものの、simdvecは各型のデータレイアウトに合わせて手作業で調整されたSIMDによって差別化を図っています。

しかし、実際の検索エンジンは一度に1つのベクトルを評価するのではなく、クエリごとに数千のベクトルを評価します。次の質問は、そのスケールで何が起こるかということです。

一度に数千件

シングルペアのパフォーマンスは全体の一部に過ぎません。実際には、システムが負荷時にどのように動作するかが重要です。単一のHNSWクエリは数百のグラフ近傍をスコアリングすることがあります。IVFスキャンは、数千件の投稿リストエントリーをスコアリングすることがあります。リランクパスは数万の候補をスコアリングすることがあります。シングルペアのスループットは重要ですが、より重要なのは、多くのベクトルをどれだけ速くスコアリングできるか、そして作業セットがCPUキャッシュから溢れ出すにつれてパフォーマンスがどれだけスムーズに低下するかです。

simdvecは、あらゆるデータタイプに対して一括スコアリング機能を提供します。これらは単なる単一ペアカーネル上のループではなく、クエリベクトルを1次元ストライドごとに1回ロードし、複数のドキュメントベクトル間で共有するマルチアキュムレータ内部ループを使用します。次のバッチに対しては、明示的なキャッシュラインプリフェッチが行われます。jvectorもFAISSも同等の機能を提供していません（執筆時点では）。Jvectorには一括処理APIがないため、呼び出し元はループ内で一度に1組ずつスコアを計算します。FAISSはfvec_inner_products_nyを公開していますが、執筆時点では、クエリ償却やプリフェッチを行わずに、シングルペア距離関数のループとして実装されています。

Float32。カーネルレベルでのインパクトを測定するために、HNSWのような散在グラフの近傍検索をシミュレートするランダムアクセスパターンを用いて、1024次元float32ドキュメントベクトルの数を増やしながら単一のクエリのスコアを計算しました。3つのデータセットサイズ（32、625、32,500ベクトル）は、それぞれL1、L2、L3キャッシュを超えるように選択されています。

データがキャッシュに収まる場合、simdvecはどちらのプラットフォームでも最速ですが、カーネル演算が支配的であるため、マージンは控えめです。実際の分離は、ワーキングセットがL3を超えるにつれて現れます。x86では、simdvecのスコアは1ベクトルあたり95ナノ秒ですが、FAISSは165ナノ秒、jvectorは412ナノ秒です。ARM上でも同様の傾向が見られ、simdvecは162ナノ秒で安定しているのに対し、FAISSは347ナノ秒、jvectorは476ナノ秒に上昇します。simdvecのプリフェッチとクエリの償却により、シングルペアカーネル上の単純なループでは対応できない方法でメモリの待ち時間が隠され、メインメモリの奥深くで実際の検索ワークロードが動作する場所でその利点が広がります。

Int8。同じパターンは量子化された型にも当てはまります。int8ドット積の一括スコアリングを1024次元で測定し、データセットのサイズが同じL1、L2、L3キャッシュ境界を超えるように選択して、simdvecのバルクスコアリングをループ内のNumKongシングルペアスコアリングと比較しました。

x86では、simdvecは1.2倍～1.9倍高速で、これは明示的なプリフェッチとバッチ処理の組み合わせによってもたらされます。ARM環境では、すべてのデータセットサイズにおいて、simdvecが再び優位に立ちました（1.7倍から1.9倍高速）。その利点は、4つのベクトルを一度にバッチ処理することで、インターリーブアクセスパターンを介してメモリレベルの並列処理を実現することにあります。いずれの場合も、最も顕著な結果は最大のデータセットサイズで何が起こるかであり、それが最も重要な場所です。

結果は、二乗距離とコサインで同様のパターンを示し、ARMでは1.4倍から1.8倍、x86では1.3倍から3.0倍の速度向上が見られました（詳細はこちら）。

メモリが重要となる場合

本番環境のベクトルインデックスは通常、CPUキャッシュに収まりません。1024次元の10Mベクトルint8インデックスは10GBです。候補のスコアリングとは、DRAMからデータをストリーミングすることを意味し、そこでバルクスコアリングアーキテクチャが大きな違いを生むのです。

バルクスコアリング中のCPU内部で何が起こるかを測定するためにハードウェアパフォーマンスカウンターを使用し、メモリーレイテンシを隠すためには、アーキテクチャごとに根本的に異なる2つの戦略が必要であることを発見しました。

x86アーキテクチャでは、明示的なプリフェッチによってキャッシュミスが解消されます。バルクカーネルはベクトルを逐次的に処理し、次のベクトルを処理する前に1つのベクトルを完全に計算しながら、次のバッチのためのプリフェッチ命令を発行します。将来のデータはCPUが必要とする前にL1に取り込まれます。

ARMアーキテクチャでは、プリフェッチを使用しても、同じ逐次的なアプローチではパフォーマンスが低下しました。代わりに、バルクカーネルが4つのベクターからすべてのストライド位置でロードをインターリーブし、アウトオブオーダーエンジンに4つの独立したメモリストリームを提供します。CPUのデータの取得速度が速くなったわけではなく、メモリ要求の処理中に常に別の計算処理を行うことで、待ち時間を短縮しているのです。詳細な分析についてはこちらのGitHubイシューをご覧ください。

数字は2つの異なる物語を語っています。

1. x86アーキテクチャでは、プリフェッチによって139,000回のキャッシュミスが19,000回に減り、1サイクルあたりの命令実行数（IPC）が2倍以上になります。データセットのサイズが大きくなるにつれてプリフェッチによってコストのかかるDRAM往復処理が徐々に隠蔽されるため、データ量の増加によるメリットは大きくなり、L2レベルでは1.2倍、L3レベルを超えると2.8倍になります。

2. ARMではキャッシュミスはほとんど変わりません。変化するのは利用率です。インターリーブアクセスパターンによってパイプラインへの供給が維持されるため、バックエンドの停止時間が40%減少します。この利点は、データセットのサイズに関係なく一貫して1.8倍です。これは、データがキャッシュまたはDRAMから来ているかに関係なく、メモリレベルの並列処理が適用されるためです。

2つのアーキテクチャ、2つの戦略、結果は1つ：本番環境規模では、simdvecはベクトルがメインメモリ全体に分散している場合でも、CPUパイプラインを常にフル稼働させます。

Elasticsearchユーザーへの影響

これらのカーネルレベルの能力は相乗効果を発揮します。単一のベクトル検索クエリでは、HNSWグラフの走査、候補のスコアリング、再ランキングなど、数百万もの距離演算が計算される場合があります。数千回の同時クエリにおいて、1回の操作でナノ秒単位がクエリ遅延やクラスタスループットに直接変換されます。float32、int8、bfloat16、BBQのいずれを使用する場合でも、インデックスがメモリ上にあるかディスク上にあるかに関わらず、simdvecが基盤となるエンジンであり、これらのすべての操作は同じエンジンを通して実行され、ナノ秒単位まで最適化されています。

重要なポイントは、本番規模では、ベクトル検索のパフォーマンスは主に生のSIMDスループットによって決まるわけではないということです。システムのパフォーマンスは、数百万もの小さな演算処理において計算能力を維持しながら、メモリの遅延をいかに効率的に隠蔽できるかに大きく左右されます。

simdvecカーネルは、ほぼすべてのElasticsearchリリースで改善されています。新しい量子化タイプやハードウェアプラットフォームが登場すると、初日からチューニング済みのカーネルが提供されます。また、既に出荷されている実装を改良していくにつれて、既存の型もますます高速化していきます。

組織は大量のドキュメントコレクション（サポートチケット、法的書類、ニュースフィード、研究論文など）を蓄積しており、適切な質問をする前にその内容を理解する必要があります。ラベルやトレーニングデータがなければ、何千もの文書を手動で確認するのは非現実的です。何を検索すればいいかわからない場合、従来の検索は役に立ちません。

この投稿では、この検索の問題に対処するElasticsearchネイティブのアプローチによる教師なし文書クラスタリングと時間軸に沿ったストーリー追跡について説明します。最終的には、次のようにストーリーの文脈を日々にわたってたどることができるようになります。

読み取れる内容：

• なぜクラスタリング埋め込み（検索埋め込みではない）が、クエリーなしでトピック発見を行いたい場合に重要なのか。

• Elasticsearchのk-nearest-neighbor（kNN）とバッチ処理msearch を使用したトピックにより、密度探査型重心分類で文書をグループ化する方法。

• significant_text がクラスターに自動ラベルを付けることで、モデルをトレーニングしなくてもテーマを読めるようにする方法。

• テーマが日々どのように変化するかを示す上で、時間軸に沿ったストーリーチェーンが日々のクラスターをどのように結び付けるのか。

このパイプラインでは、2025年2月のBBCニュースとガーディアンの記事を約8,500件、テストコーパスとして使用しています。ニュースは明確な時間的推移を示すため便利ですが、このパターンは文書の発見が重要なあらゆる場面に適用されます：法的レビュー、コンプライアンスの監視、研究の統合、カスタマーサポートのトリアージ。

スタック：

• Jina v5のクラスタリング埋め込み：トピックグループ化のためのタスク固有の低ランク適応（LoRA）アダプター。JinaはElasticに統合され、そのモデルはElastic Inference Service（EIS）を通じてネイティブで利用可能です。

• Elasticsearch：拡張性のあるkNN、significant_textラベリング、ベクトルストレージ。

• DiskBBQ：ディスクベースのベクトルインデックス形式で、 Better Binary Quantization（BBQ）と階層的なk-平均法による分割を組み合わせ、近似最近近接傍（ANN）加速を実現します。このインデックス分割はベクトル探索の内部で行われ、本投稿で用いる密度探査型クラスタリング・アルゴリズムとは別です。bbq_diskはディスクに量子化されたベクトルを格納し、ヒープにはパーティションメタデータのみを保持することで、bbq_hnswと比較してリソース要件を大幅に削減しながら、高い再現率を維持します。

• グローバルクラスタリング + 日々の時間軸に沿ったリンク付け：発見とストーリーの進化。

以下が必要です：

• Elasticsearchの導入（Elastic Cloud、Elasticsearchサーバーレス、またはElastic Self-Managed 8.18+/9.0+）：bbq_disk 8.18以降が必要です。オプションのdiversify retrieverセクションは9.3+またはサーバーレスが必要です。

• Jina APIキー：無料プランには1000万トークンが含まれており、これはコアクラスタリング・パイプライン（約425万トークン）をカバーします。オプションの検索対クラスタリング比較は、2番目の埋め込みパスを使用します。

• Guardian APIキー（無料）。

セットアップ

必要なパッケージをインストールしてください：

オプション（このリポジトリからスクレイピングヘルパーを実行する場合のみ）：

次に、プロジェクトのルートにある.envファイルでAPIキーを設定します。

このノートブックは load_dotenv(override=True)を呼び出し、局所的な .env 値が優先されます。

パート1：ディスカバリークラスタリング - なぜ埋め込みをクラスタリングするのか？

ほとんどのベクター検索は、クエリを関連文書に一致させるようにトレーニングされた検索埋め込みを使用します 。これは検索には最適ですが、発見には適していません。まったくクエリーせずにコーパスに存在するトピックを見つけたい場合は、類似した文書をグループ化する埋め込みが必要です。

Jina v5では、タスク固有の低ランク適応（LoRA）アダプタを使用してこの問題を解決します。LoRAは、ほとんどのベースモデルの重みを凍結したまま、ターゲットとなる内部層に小さな低ランクの更新を加えるため、完全な再トレーニングを行うことなく、モデルの挙動が特定のタスクにシフトします。同じベースモデルでも、taskパラメータによって異なる埋め込みが生成されます。

タスク

訓練の目的

ユースケース

retrieval.passage

クエリーと文書のマッチング

Search、Retrieval-Augmented Generation（RAG）

クラスタリング

トピックのグループ化（密度が高いクラスタリングの最適化）

発見、分類

クラスタリング・アダプターは、同じトピックに関する文書を埋め込み空間で近づけ、異なるトピックに関する文書を離すように訓練されています。下のビジュアル比較で、その違いが具体的にわかります。

検索とクラスタリング：視覚的な比較

違いを確認するために、両方のタスクタイプを含むサンプル文書を埋め込んでいます。クラスタリングは元の1024次元の埋め込み空間で実行されます。均一多様体近似と射影（UMAP）は、可視化のためそれらの埋め込みを2Dに投影する目的でのみ使用されます。東映UMAPは局所的な近傍構造を保持するため、クラスターの分離を比較する上で有用です。

以下では、同じ480件の文書のサンプルが両方のタスクタイプに埋め込まれ、UMAPで2Dに投影されています。クラスタリングパネルで、より密集していて、分離された色群を探します。

検索埋め込み（左）はトピックを広く分散させます。クラスタリング埋め込み（右）は、同じドキュメントからより緊密で分離されたグループを生成します。

クラスタリング埋め込みは、より緊密で視覚的に際立ったグループを生み出します。検索用の埋め込みはトピックをより均等に分散させ、（きめの細かい類似性で）検索する上で理想的です。しかし、発見のためには、緊密なトピッククラスターが重要です。

このため、このチュートリアルの残りの部分では task="clustering" が使用されています。

データセットの読み込み

次のコーパスは、2025年2月の2つのニュースソースを組み合わせています。

• RealTimeData/bbc_news_alltime HuggingFaceデータセット経由のBBCニュース。

• Guardian Open Platform API経由のThe Guardian。

複数のソースがあると、クラスタリングがトピックではなくソース固有のスタイルを見つけることを検証するのに役立ちます。

クラスタリングタスクによる埋め込み

Jina v5 APIはすべての文書に対してtask="clustering"で呼び出されます。埋め込みはディスクにキャッシュされるため、その後の実行ではAPIを完全にスキップします。

API呼び出しはシンプルです。taskパラメータが、典型的な埋め込み使用との主な違いです。

以下のタイミングはキャッシュヒットを反映しています。APIに対する最初の実行は、コーパスサイズによって時間がかかります。

単一のElasticsearchインデックスへのインデキシング

発見クラスタリングでは、1か月間を1つのインデックス（docs-clustering-all）にまとめます。日々の分割は、時間軸に沿ったストーリーリンクのために後から行われます。

インデックスマッピングでは、ベクトルフィールドにbbq_diskを使用します。

1024次元のfloat32ベクトルは4KBです。bbq_disk は階層的k-means法を使用してベクトルを小さなクラスターに分割し、それらをバイナリ量子化し、再スコアリングのためにフルプレシジョンのベクトルをディスクに格納します。パーティションのメタデータのみがヒープに存在し、そのため大規模なコーパスでもメモリ要件は低く抑えられます。より多くのヒープを許容できるワークロードの場合、bbq_hnsw は、より高いリソースコストでより高速な検索を行うための階層的ナビゲーシブル・スモールワールド（HNSW）グラフを構築します。

dense_vectorフィールドタイプは複数の量子化戦略をサポートしています：bbq_diskとbbq_hnswは、ここで使用されている1024次元ベクトルのような高次元埋め込みに最適です。

クラスタリング：密度探査型重心分類

HDBSCANのような従来型のクラスタリングアルゴリズムでは、完全なn×dベクトル行列をメモリに保持し、フルパス更新を繰り返し実行できることを前提としています。8,495件のドキュメントを1024次元で扱う場合、処理可能（最大35MB）ではあるものの、このアプローチは追加のインフラストラクチャーなしでは数百万の文書にスケールすることはできません。

このアルゴリズムは、ボロノイ領域への割り当て割り当てとノイズフロアによるKMeans++法の初期化と概念的には似ていますが、ElasticsearchのkNN検索を計算プリミティブとして使用し、ほぼ全ての作業をサーバー側で行います。

1. 文書の5%を密度プローブとしてサンプリングします（ランダムサンプル、最低50件）。

2. バッチ処理された　msearch　kNNによるプローブ密度。各プローブはkNNクエリを実行し、隣接プローブの平均類似度を記録します。平均類似度が高い＝埋め込み空間の密な領域。msearch は単一のHTTPコールで複数の検索リクエストを送信し、これは重要です。密度プローブは数百のkNNクエリを生成し、それらをバッチ処理することでリクエストごとのオーバーヘッドを回避します。

3. 多様性を考慮した高密度シードの選択：中央値以上の密度を持つ候補は、密度の降順でソートされ、既存のすべてのシードとのコサイン類似度が分離閾値を下回る場合にのみ貪欲に受け入れられます。これがクライアント側での唯一の計算です（8,000件の文書で最大0.01秒）。

4. msearch kNNで全ての書類を重心に照らして分類します。各シードが重心として機能し、kNN検索は類似度しきい値を超える近接文書を取得します。各文書は、最も高いスコアを返した重心に割り当てられます。小さなクラスターはノイズとして処理されます。

Elasticsearchが面倒な処理を担当します：msearchは密度プローブ、msearchは分類、significant_textはラベル付けを担います。このコーパス（8,495件の文書）では、5％の密度プローブサンプルが425件のkNNプローブクエリを開始し、msearchが9つのHTTPコール（バッチサイズ50）にバッチ処理され、プローブごとに1つのリクエストを処理することによるオーバーヘッドを回避します。bbq_diskANNルックアップと組み合わせることで、クラスタリング段階を高速かつスケーラブルに保つことができます。kNNクエリは、クラスタリングパス中の速度のために最小のnum_candidates値を使用します。本番環境の検索クエリでは、レイテンシを犠牲にしてリコールを向上させるために、より高いnum_candidates値を使用する必要があります。

クラスターは各重心の周りの埋め込み空間の密度によって決定される実際的なサイズを持ち、厳格なkの上限によって決定されるものではありません。密なトピック領域はより大きなクラスターを生み出し、ニッチなトピックは小さなクラスターを生み出します。

KMeansやHDBSCANが実用的ではない理由

KMeans法は球状クラスターを想定しており、メモリに完全なn×d行列が必要です。メモリに収まるコーパスの場合、HDBSCANは強力な代替手段です。任意のクラスタ形状に対応でき、密度に関するセマンティクスも十分に理解されています。

密度探査型重心アプローチは、異なるニッチをターゲットとしています。ストレージ、検索、およびクラスタリングを1つのシステムで行いたい場合や、スケールがクライアント側の行列操作を実用的でなくするようなコーパスです。これは、Elasticsearch kNNを計算プリミティブとして使用し、任意のクラスターサイズを処理し、ほぼすべての計算をサーバー側で行います。

ノイズレートについて理解する

最大28%のノイズ率は設計によるもので、故障モードではありません。設定されたsimilarity_thresholdでどの高密度クラスターにも適合しない文書は、一致率が低いと強制的に判断されるのではなく、割り当てられずに残されます。これは品質ゲートの役割を果たします：意見を記したコラム、短い記事、そして一回限りのストーリーは、一貫したグループを定義する主題の密度が不足しているため、クラスタリングに抵抗する性質があります。

しきい値は調整可能です。similarity_thresholdを下げると、より積極的なクラスタリングが生成されます（より多くの文書が割り当てられますが、クラスターは緩くなります）。一方、これを上げると、クラスターが引き締まり、ノイズの割合が増加します。こうした様々なニュースコンテンツを含むコーパスにおいては、約30％のノイズは妥当な動作基点と言えます。本番環境での導入は、分野固有の品質基準に合わせてしきい値を調整することが推奨されます。

significant_textを使用した自動ラベル付け

各クラスターには人間が読みやすいラベルが必要です。Elasticsearchのsignificant_textアグリゲーションは、フォアグラウンドセット（クラスター）とバックグラウンドセット（完全なコーパス）を比較して、異常に頻繁に現れる用語を見つけます。

内部的には、絶対頻度の変動と相対頻度の変動のバランスを取る統計的ヒューリスティック（デフォルトではJLHスコア）を使用しており、機械学習や大規模言語モデル（LLM）の呼び出しは行っていません。英国の政治に関するクラスターでは、starmer、labour、downingのような用語が浮かび上がる可能性があります。これらの用語は、全体的なニュースコーパスと比較して、そのクラスターで不釣り合いに頻出しているためです。

このグローバルパスでは、ラベルはdocs-clustering-allに対して直接計算されるため、前景と背景の両方が月全体のデータから描画されます。パート2では、ラベル付けに日次インデックスパターン（docs-clustering-*）を使用します。これは、クエリで一致するすべてのインデックスを同時に対象にできるワイルドカードで、significant_textにより広い背景を与えてコントラストを高めます。

最小クエリー形状は次のようになります。

significant_text また、品質ゲートの役割も果たします。有意な用語を生成しないクラスターには、特徴的な語彙がありません。これらはまとまりのないグループであり、誤解を招くようなラベルを付けるのではなく、ノイズとして分解する必要があります。

軽量で決定論的なクリーンアップステップで、ノイズの多いラベルの用語（数値トークン、一般的な単語）を削除し、必要に応じて代表的な見出しに切り替えます。これにより、ラベルをElasticsearchネイティブのまま維持しつつ、可読性を向上させます。

クラスターの可視化

以下の可視化は、グローバルクラスタリングパスが発見した内容を示しています：クラスター化された文書とノイズ文書の日付ごとの内訳、全月のUMAP投影、およびクラスターがソースではなくトピックを反映していることを確認するソースミックスチャート。

2025年2月におけるクラスター化された文書とノイズ文書の日次分布。

UMAPの色のついた島はそれぞれがクラスターを表しています。クラスターは、純粋に類似性を埋め込むことで発見された、同じトピックに関する記事の集合です。灰色のノイズポイントは、いずれのクラスターにもきれいに収まらなかった記事（多くの場合、短い記事、意見記事、または一回限りのストーリー）です。

情報源の内訳図を見ると、各クラスターにはBBCニュースとガーディアンの両方からの記事が含まれていることが確認できます。クラスタリングは、ソースではなくトピックを見つけ出すものであり、まさに教師なし学習から期待される結果です。

Diversify Retrieverによるクラスター幅の調査

通常のkNNは、クラスターの重心（密なコア）に最も類似した文書を返します。しかし、実際のクラスターはサブトピックも対象にします。The Diversify Retrieverは、Maximal Marginal Relevance（MMR） を使用して、重心に関連するだけでなく、互いに異なる文書を抽出します。

鍵となるパラメータは λ（ラムダ）です。

• λ = 1.0 → 純粋な関連性（通常のkNNと同じ）。

• λ = 0.0 → 純粋多様性（最大限に分散された結果）。

• λ = 0.5 → バランスが取れている：トピックに関連しているが、異なる角度をカバーしている。

最小Retrieverリクエストの形状は次のようになります。

type、field、および query_vector パラメーターは、diversifyレベルで必要です。field はMMRに結果間の類似性に使用する dense_vector フィールドを指示し、query_vector は関連性スコアリングの参照点を提供します。

これにより、単に「その中心は何か？」という問いではなく、「このクラスターは実際に何を対象としているのか？」という問いに答えることができます。

プレーンなkNNは、トピックの1つの角度、つまり中心点および互いに最も類似したドキュメントの周りにクラスターを形成します。Diversify Retrieverは、同じクラスターの異なるファセット、つまりサブトピック、異なるソース、多様な視点を提示します。

多様性指標はこれを定量的に裏付けます。Diversify Retrieverの結果では、平均ペアワイズ類似度が低く、これは返された文書がより広範囲をカバーしていることを意味します。

これは以下の用途に役立ちます。

• クラスターが実際に対象としている内容を理解。その中心だけでなく端も含め理解します。

• 要約の生成。多様で代表的な文書は、LLMにより良い材料を提供します。

• 人によるレビューや下流工程でのラベリングのために、代表的な例を発見。

• 品質チェック。多様な結果が一貫性に欠けている場合、クラスターの分割が必要かもしれません。

パート2：時間軸に沿ったストーリーチェーン

日をまたいだデータストーリーの追跡

パート1では、トピック発見のために1か月全体をグローバルにクラスタリングしました。時間軸に沿ったフローでは、同じ密度プローブの重心分類が日次インデックスごとに1日単位で独立して実行され、その後、クラスターが隣接する日々にわたってリンクされます。注意：日々のクラスターはパート1のグローバルクラスターとは独立しており、それぞれの1日はその日のコンテンツに合わせて独自のクラスター割り当てとラベルを生成します。

関連付けの手法：サンプルとクエリ

A日目の各クラスターについて：

1. いくつかの代表的な文書をサンプルとして選択します。

2. kNNをB日目のインデックスに対して実行します。

3. B日目のクラスターごとにヒット数を数えます。

4. ヒット率がしきい値（kNNの割合≥ 0.4）を超える場合は、リンクを記録します。

この処理は高速で（クラスターごとにわずかなドキュメントのみがクエリされ、すべてではありません）、ElasticsearchのネイティブkNNを使用し、外部ツールは必要ありません。

kNN分数が100％ということは、ソースクラスターからサンプリングされたすべてのドキュメントが同じターゲットクラスターに到達していることを意味し、これは異なる日付間のリンクが理論上最も強くなります。ほとんどの上のリンクはフットボール関連で、これは理にかなっています。プレミアリーグは毎日報道され、高いトピックの一貫性があります。

The score | operator | gedling → league | striker | season リンクは、ニッチなローカルフットボールクラスター（Gedling はノンリーグクラブです）が翌日に広範なプレミアリーグクラスターに吸収される例であり、これは異なる粒度での日々の再クラスタリングの自然な効果です。

ストーリーチェーンの構築

ストーリーチェーンとは、連日にわたって連続した一連のクラスターです。

個々のペアワイズリンクは、月曜日の「UK politics」クラスターが火曜日のクラスターにリンクしていることを示しています。チェーンはストーリー全体を明らかにします。月曜日に始まり、週を通して展開し、金曜日までに消えていくストーリーです。

チェーンは、kNN分数が0.4以上のリンクから貪欲に構築されます。これは、ソースクラスターからサンプリングされたドキュメントの少なくとも40％が単一のターゲットクラスターに到達したことを意味します。最も古いクラスターから開始し、アルゴリズムは常に最も強い発信リンクを追跡します。

最も長いチェーンは、ウクライナとロシアに関する報道を19日間連続で追跡していますが、2025年2月の地政学的な緊張が持続していることを考えると、これは驚くべきことではありません。2番目に長いチェーンは、19日間にわたるプレミアリーグのサッカーを追跡するものです。より短いチェーンは、映画賞シーズン（6日間）、シックス・ネーションズラグビー（10日間）、英国の政治指導者に関する報道（7日間）を追跡しています。それぞれのチェーンは、アルゴリズムが日々のインデックス全体にわたる埋め込み類似性のみから発見したストーリー展開を表しています。

サンキー：ストーリーの流れを可視化する

サンキーダイアグラムは、リンクの幅がつながりの強さを表す流れの可視化です。ここでは、各垂直バンドが1日を表し、各ノードは日々のクラスター（ドキュメント数によってサイズが決まる）であり、各色のパスは時間の経過に沿って1つのストーリーチェーンを追跡します。リンク幅はkNNのオーバーラップ強度をエンコードします。リンクが太いほど、サンプリングされたドキュメントの数がより多くターゲットクラスターに到達したことになります。色はチェーンごとに分かれているので、左から右へ流れる1つのカラーパスで1つのストーリーの進行がわかります。

たとえば、ウクライナとロシアのチェーン（比較的長い経路の一つとして示されている）は、2月初旬から第3週まで途切れることなく続いており、一貫して太い線で結ばれていることから、日々の話題の連続性が強いことがわかります。

2025年2月に流れる時間軸に沿ったストーリーチェーン各色のパスは、複数日にわたって続くストーリーを表し、リンクの幅はkNNの重なりの強さを示します。

このアプローチがもたらすメリット

このウォークスルーでは、Elasticsearch上に構築された完全な教師なしドキュメントクラスタリング・パイプラインについて説明しました。

1. クラスタリング埋め込み：Jina v5のタスク固有のアダプターは、トピックのグループ化に最適化された埋め込みを生成し、単なるクエリと文書のマッチングだけではありません。

2. グローバルな発見クラスタリング：1つのインデックスで1か月間をクラスタリングすることで、日をまたいだトピックの発見を最大化します。

3. 密度プローブによる重心分類：5％をサンプリングし、msearch kNNを介して密度をプローブし、多様な高密度シードを選択し、すべての文書を重心に対して分類します。Elasticsearchは負荷の高い計算を処理します。シード選択のみがクライアント側で実行されます（最大0.01秒）。

4. significant_textラベリング：有意性テストは、MLモデルや手動アノテーションなしで意味のあるクラスタラベルを生成します。有意な項を生み出さないクラスタは非整合となり、ノイズに格下げされます。これは内蔵された品質ゲートです。

5. 時間軸に沿ったストーリーのリンク付け：日次インデックスとサンプルおよびクエリのクロスインデックスkNNは、ストーリーが時間とともにどのように進化するかを追跡します。

重要なポイント

• 埋め込みタスクの種類が重要です。クラスタリング埋め込みは、測定可能かつより緊密な話題のグループを生成します。

• Elasticsearchはストレージ層およびクラスタリングエンジンの両方としてkNN検索を通じて機能します。

• 密度探査型重心分類は、ほぼすべての計算をサーバー側で行い、埋め込み空間の密度によって決定される合理的なサイズのクラスターを生成します。

• significant_text 高速で解釈可能で、自動ラベリングと品質管理の両方に効果的です。

このアプローチは、以下の場合に有用です。

• タイムスタンプ付きのテキストがあり、ラベル付きトレーニングデータを使用せずにトピックを発見したい場合があります。

• ストレージ、ベクトル検索、ラベル付け、および時間軸に沿ったリンク付けのために、1つのスタックが必要な場合があります。

検討すべき拡張機能：

• 複数期間クラスタリング（週間、月間集計）。

• リアルタイムのインジェストと段階的なクラスター割り当て。

• LLM生成のクラスタサマリーは、significant_text項をシードとして用います。

• より大規模なスケールでは、サンプリングされたKMeansの重心が密度ベースのクラスタリングのウォームスタートシードとして機能し、探査フェーズのコストを削減できます。

はじめましょう

タイムスタンプ付きの文書コーパスを差し替えます。日付のあるテキストのコレクションであれば、このパイプラインで利用可能です。完全なノートブックとサポートコードは、付属レポジトリで入手できます。

• Elastic Cloudの無料トライアルを開始：bbq_diskサポート付きのマネージドクラスターを数分でご利用いただけます。

• Elasticsearch Serverlessをお試しください：クラスターの管理は不要で、自動的にスケールし、このウォークスルーのすべてをサポートします。

Elasticsearchは、遅れて到着するメトリクスを拒否していました。これらの拒否により、パイプラインが遅延し、結果としてより多くの遅延データが発生し、さらに多くの拒否を引き起こしました。最終的にパイプラインは完全に停止しました。

復旧のためには、スナップショットからの復元、データの再インデックス作成、データ取り込みパイプラインの再設計が必要でした。

根本的な原因はインデックスライフサイクル管理（ILM）自体ではなく、時系列データストリーム（TSDS）と、それらが時間的制約のあるバッキングインデックスを強制する方法にありました。

TSDSは指標のストレージ要件を40〜70％削減できますが、TSDSを効率的にするアーキテクチャの変更により、時間の経過とともにインデックスの動作も変わります。これらの変更は、ILMポリシーを設計する時、またはインジェストパイプラインで遅れて到着するデータが生成される可能性がある場合に重要です。

TL;DR

TSDSを使用する場合：

• バックアップインデックスは、特定の時間枠内でのみ文書を受け付けます。

• 遅延データがインデックスがColdまたはFrozen状態に移行した後に取り込まれた場合、Elasticsearchはそれらのドキュメントを拒否するか、設定されている場合は障害ストアにルーティングします。

デザインルール：

時系列データストリームとは何ですか？

時系列データストリーム（TSDS）は、メトリクスデータに最適化された特殊なデータストリームです。データは関連するドキュメントが同じシャード内に配置されるようにルーティングされ、クエリと検索のための最適化が行われます。Elasticsearchは以下の方法で行います：

各文書には以下が含まれます。

• 1つのタイムスタンプ。

• 時系列を識別するディメンションフィールド。

• 測定値を表すメトリックフィールド。

例：

• ホストあたりのCPU使用率。

• サービスごとのリクエスト遅延。

• センサーごとの温度測定値。

ディメンションは測定したい対象を特定し、メトリクスは時間とともに変化する値を表します。

ディメンション

ディメンションは測定対象を表します。

例：

それらをマッピングで次のように定義します：

メトリクス

メトリクスは数値を表し、以下によって定義されます。

一般的なメトリクスの種類：

• ゲージ：増減する値。

• カウンター：リセットされるまで増加する値。

Elastic Agentは主にメトリクスおよびログデータを収集するため、TSDSのインデックスを手動で有効にしていなくても、クラスター内に存在している場合があります。

_tsidフィールド

Elasticsearchは内部的にディメンションフィールドから _tsid 値を生成します。これにより、同一のディメンションを持つドキュメントを同じシャードにルーティングすることができ、以下が改善されます：

• 圧縮。

• クエリのローカル環境。

• アグリゲーションのパフォーマンス。

主な違い：時間制限付きバッキングインデックス

従来のデータストリームは常に最新のバッキングインデックス（書き込みインデックスと呼ばれる）に書き込みますが、TSDSは異なる動作をします。

各TSDSバッキングインデックスには定義された時間ウィンドウがあり、そのウィンドウ内に収まる@timestamp値を持つドキュメントのみを受け入れます：

ドキュメントがインデックス化されると、Elasticsearchはそれをタイムスタンプに関わるバッキングインデックスにルーティングします。これは、従来のインデックスとは異なり、TSDSが複数のバッキングインデックスに同時に書き込む可能性があることを意味します。

例：

• リアルタイムデータ → 最新のインデックス。

• 遅延データ → その期間をカバーする以前のインデックス。

遅延データに対応する設計方法

実際のインジェストパイプラインは、ほとんどの場合、完全に期限内に指標を届けるわけではありません。メトリクスは、ネットワークの停止、途中のバックログ、バッチのインジェスト、およびエッジデバイスの損失（これらのデバイスは再接続し、キャッチアップを始めます）によって遅延する可能性があります。

従来のインデックスは、静かにその遅延を吸収しますが、TSDSはしません。

ドキュメントのタイムスタンプが書き込み可能なバッキングインデックスの範囲外にある場合、Elasticsearchはそれを拒否します。これは、ILMポリシーが遅延データを考慮する必要があることを意味します。

重要な制約

バッキングインデックスは遅延データを受け入れられるだけの期間、書き込み可能な状態を維持する必要があります。

実際には、これは次のことを意味します。

ILMはロールオーバーからの時間経過を測定するため、運用ルールは次のようになります。

たとえば、メトリクスが最大6時間遅延する可能性がある場合、インデックスはロールオーバー後少なくとも6時間は書き込み可能な状態を維持する必要があります。

この制約を考慮しなかったことが、前述のインジェスト障害の正確な原因でした。遅れて到着したデータは、既にColdティアにあり、そのため書き込みがブロックされていた以前のインデックスに向けられていました。

拒否されたドキュメントの処理

TSDS がドキュメントを拒否すると、Elasticsearch は、タイムスタンプが書き込み可能なインデックスの範囲内にないことを示すエラーを返します。インジェストパイプラインがそのエラーをどのように処理するかによって、データを失うか、インジェストが停止するかが決まります。

拒否されたドキュメントを処理する主要なメカニズムは、障害ストアです。

障害ストア（Elasticsearch 9.1以降で推奨）

Elasticsearch 9.1では、拒否されたドキュメントを自動的に格納するfailure storeが導入されました。Elasticsearchは、クライアントにエラーを返す代わりに、失敗したドキュメントをデータストリーム内の専用の障害インデックスに書き込みます。

障害の調査には以下の方法があります。

障害ストアを使用することで、拒否エラーによるインジェストパイプラインの停止を防ぎつつ、障害データを分析または再インデックスのために保存します。

拒否される問題の監視

遅れて到着する問題は通常、最初にインジェスト異常として現れます。最初は、以下によって気付く場合があります：

• インデキシングレートの突然の低下。

• 拒否されたドキュメントの急増。

• 障害ストアエントリ数の増加。

• パイプラインの入力数と出力数の不一致。

これらの兆候に基づいて警告を発することで、オペレーターはパイプラインが停止する前に問題を検知することができます。ワークフロー、機械学習ジョブ、およびその他のメカニズムを使用して、検出と通知を自動化できます。

TSDS + ILMの移行チェックリスト

メトリクスクラスターをTSDSに移行する場合、ILM階層化を導入する場合、またはメトリクスがデフォルトでTSDSであるElasticsearchバージョンにアップグレードする場合は、まずこれらの項目を確認してください。

1. インジェストレイテンシの測定

ILMの方針を変更する前に、以下を決定してください。

• 通常のインジェスト遅延。

• 最悪の場合、インシデント時の遅延。

• バッチパイプラインによる遅延。

ILM設計は、現実的な最大限の遅延に対応する必要があります。

2. インデックス付けの時間ウィンドウを検証する

TSDSのバッキングインデックスを調べます。

以下について探します：

• time_series.start_time

• time_series.end_time

これらの制限が、どのインデックスがドキュメントを受け入れられるかを決定します。これらのウィンドウを理解することで、データがどのくらい遅れていても拒否されないのかを判断できます。

3. 遅延データを考慮してHotティアのサイズを調整する

遅延データに対しても、バッキングインデックスが書き込める状態を保ちます。

運用ルール：

• warm_min_age > rollover_max_age + maximum_expected_lateness

メトリクスが6時間遅れて届く場合、インデックスは少なくとも6時間は書き込める状態を維持する必要があることに留意してください。

4. 拒否されたドキュメントの処理方法を決定する

TSDSを有効にする前に以下のストラテジーを選択します：

• 障害ストア（Elasticsearch 9.1以降で推奨）。

• Logstashのデッドレターキュー。

• 到着が遅れた場合のフォールバックインデックス。

• 限定的なデータ損失を受け入れる。

5. インジェストの正常性を監視する

以下のアラートを追加します：

• インデキシングの速度低下。

• 却下された書類。

• ストアの拡大失敗。

• パイプラインの入力と出力の不一致。

遅延データの問題は、多くの場合、インジェスト時の異常として最初に現れます。

まとめ

時系列データストリームは、メトリックワークロードに対して主要なストレージとパフォーマンスの改善を提供しますが、重要なアーキテクチャ上の変更も導入します。バッキングインデックスには時間的な制約があり、これがILMの動作に影響します。

TSDSを使用する場合：

• インデックスは、遅延データを受け入れられるだけの期間、書き込み可能な状態を維持する必要があります。

• インジェストパイプラインは、拒否されたドキュメントを安全に処理する必要があります。

留意する重要なルールは次の通りです：

その制約に基づいてILMポリシーを設計すると、TSDSはメトリクスのワークロードに非常に適しています。

無視した場合、インジェストパイプラインがその時間的制約によって機能不全に陥る可能性があります。

最初のクエリ

まず、Elasticsearchインデックスにマップする普通のCLRオブジェクト（POCO）を定義します。プロパティ名は、標準的なSystem.Text.Json属性（[JsonPropertyName]など）または設定されたJsonNamingPolicyを通じてES|QL列名に解決されます。クライアントの他の部分に適用されるソースシリアル化ルールは、ここでも同様に適用されます。

型を指定すると、クエリは次のようになります。

プロバイダーはこれを次のES|QLに変換します。

いくつか注意すべき点があります。

• プロパティ名の解決： p.Priceは[JsonPropertyName] 属性のためprice_usdになり、p.BrandはデフォルトのcamelCase命名規則に従って brandになります。

• パラメーターのキャプチャ：C#変数 minPriceとbrandは、名前付きパラメーター（?minPrice、?brand）としてキャプチャされます。これらはJSONペイロード内のクエリ文字列とは別に送信されるため、インジェクション攻撃を防ぎ、サーバー側のクエリプランのキャッシュを可能にします。

• ストリーミング：QueryAsync<T>はIAsyncEnumerable<T>を返します。Elasticsearchからデータが到着すると、行は1つずつマテリアライズされます。

また、実行せずに生成されたクエリとそのパラメーターを検査することもできます。

これはどのように機能するのでしょうか？LINQ の簡単なおさらい

LINQプロバイダーを可能にするメカニズムは、IEnumerable<T>とIQueryable<T>の区別にあります。

.Where(p => p.Price > 100) を IEnumerable<T> 上で呼び出すと、ラムダは Func<Product, bool> にコンパイルされます。これは、ランタイムがインプロセスで実行する通常のデリゲートです。これはLINQ-to-Objectsです。

同じメソッドを IQueryable<T> で呼び出すと、C#コンパイラはラムダを Expression<Func<Product, bool>> でラップします。これは実行可能な形式ではなく、コードの構造を表すデータ構造です。式ツリーは実行時に検査、分析、および別の言語への変換を行うことができます。

IQueryProviderインターフェースは拡張ポイントです。どのプロバイダーでも、これらの式ツリーをターゲット言語に変換するために CreateQuery<T> と Execute<T> を実装できます。Entity FrameworkはSQLを発行するためにこれを使用します。LINQからES|QLへのプロバイダーはこれをES|QLの生成に使用します。

上記のクエリの式ツリーは次のようになります。

例のクエリに対する式ツリー。

ツリーは内側から外側にネストされています。Takeが OrderByDescendingをラップし、これがWhereをラップし、これがFrom, をルート定数EsqlQueryable<Product> をラップします。Where述語自体がBinaryExpressionノードのサブツリーであり、&&、>=、および==演算子に対してMemberExpressionリーフがプロパティアクセス用、minPriceおよびbrand変数用のクロージャキャプチャ用に存在します。これは、プロバイダーが最終的なES|QLを生成するために使用するデータ構造です。

内部構造：変換パイプライン

LINQ式からクエリ結果までの経路は、6段階のパイプラインをたどります。

データ変換パイプラインの概要。

1. 式ツリーのキャプチャ

.Where()、.OrderBy()、.Take()などの演算子をIQueryable<T> に連鎖させると、標準のLINQインフラストラクチャーが式ツリーを構築します。EsqlQueryable<T> はIQueryable<T> を実装し、EsqlQueryProvider に委譲します。

2. 変換

クエリが実行されると（列挙、 ToList()の呼び出し、またはawait foreach)使用によって）、 EsqlExpressionVisitorは式ツリーを内側から外側へと走査します。各LINQメソッド呼び出しを専門のビジターに送信します。

ビジター

翻訳します

対象

WhereClauseVisitor

.Where(predicate)

WHERE 条件

SelectProjectionVisitor

.Select(selector)

EVAL + KEEP + RENAME

訪問者別にグループ化

.GroupBy().Select()

STATS ... BY

OrderByVisitor

.OrderBy() / .ThenBy()

SORTフィールド [ASC\|DESC]

EsqlFunctionTranslator

EsqlFunctions.*、Math.*、文字列メソッド

80+ ES|QL関数

翻訳中、式で参照されるC#変数は名前付きパラメーターとしてキャプチャされます。

3. クエリモデル

ビジターは直接文字列を生成しません。代わりに、QueryCommandオブジェクト、すなわち不変の中間表現を生成します。FromCommand、WhereCommand、SortCommand、およびLimitCommandの各々が、1つのES|QL処理コマンドを表しています。これらはEsqlQueryモデルに集められます。

クエリモデルとコマンドパターン。

この中間モデルは、式ツリーと出力形式の両方から切り離されています。フォーマット前に検査、傍受（IEsqlQueryInterceptor経由）、または修正が可能です。

4. フォーマット

EsqlFormatter 各QueryCommandを順番に訪問し、最終的なES|QL文字列を生成します。各コマンドは1行になり、ES|QLが処理コマンドを連鎖させるために使用するパイプ (|) 演算子で区切られます。特殊文字を含む識別子は自動的にバッククォートでエスケープされます。

5. 実行

フォーマットされたES|QL文字列とキャプチャされたパラメーターは、JSONペイロードとしてElasticsearchの/_queryエンドポイントに送信されます。IEsqlQueryExecutorインターフェースはトランスポートレイヤーを抽象化し、ここで階層型パッケージアーキテクチャが登場します。

6. マテリアライズ

EsqlResponseReader JSON応答をストリーム化し、結果セット全体をバッファリングせずに処理します。ColumnLayoutツリーは、1クエリにつき1回事前に計算され、フラットなES|QL列名（address.street、address.cityなど）をネストされたPOCOプロパティにマップします。各行はTインスタンスに組み立てられ、 IEnumerable<T> または IAsyncEnumerable<T>によって1行ずつ生成されます。

レイヤーアーキテクチャ

LINQ to ES|QL機能は、以下の3つのパッケージに分かれています。

パッケージアーキテクチャー。Elastic.Esql は純粋な変換エンジンです。HTTPへの依存関係は一切なく、式ビジター、クエリモデル、フォーマッター、レスポンスリーダーが含まれています。スタンドアロンで使用すると、Elasticsearch接続がなくてもES|QLクエリを構築および検査できます。これは、テスト、クエリロギング、または独自の実行レイヤーの構築に役立ちます。

Elastic.Clients.Esql は軽量なスタンドアロンのES|QLクライアントです。Elastic.Transportを経由してElastic.Esql上にHTTP実行を追加します。もしアプリケーションが他のElasticsearch APIではなく、ES|QLのみを必要とする場合、これが最小限の依存関係オプションです。

Elastic.Clients.Elasticsearch は完全なElasticsearch .NETクライアントです。また、Elastic.Esql を基盤とし、client.Esql名前空間を通じてLINQプロバイダーを公開します。これはほとんどのアプリケーションで推奨されるエントリーポイントです。

どちらの実行層パッケージも、変換と転送をつなぐ戦略インターフェースであるIEsqlQueryExecutorの独自の実装を提供します。

これら3つのパッケージはすべて、ソース生成のJsonSerializerContextと併用する場合、ネイティブAOTと互換性があります。完全なクライアントについては、Native AOTのドキュメントをご覧ください。

基本を超えて

上記の例では、フィルタリング、ソート、ページネーションについて説明しています。このプロバイダーはより幅広い操作をサポートしています。

アグリゲーション

GroupBySelectの集約関数と組み合わせるとES|QL STATS ... BYに変換されます。

予測

Select匿名型を持つと、 EVAL、 KEEP、 RENAME コマンドが生成されます。

豊富な関数ライブラリ

80以上のES|QL関数が EsqlFunctionsクラスを通じて利用可能で、日付/時間、文字列、数学、IP、パターンマッチング、スコアリングをカバーしています。標準的なMath.*およびstring.*メソッドも変換されています。

ルックアップ結合

クロスインデックス検索はES|QL LOOKUP JOINに変換されます。

未加工のES|QLエスケープハッチ

LINQプロバイダーでまだサポートされていないES|QL機能については、生のフラグメントを追加できます。

サーバー側の非同期クエリ

実行時間の長いクエリについては、サーバー上でバックグラウンド処理を行うように設定します。

サーバー側の非同期クエリは、通常のタイムアウトしきい値を超える可能性のある長時間実行される分析クエリや大規模データセットの処理、あるいはロードバランサー、APIゲートウェイ、プロキシなど、厳格なHTTPタイムアウトを強制するタイムアウトに敏感な環境で特に役立ちます。非同期クエリは、結果の取得から提出を切り離すことで接続切断を回避します。

はじめに

LINQ to ES|QLは次のバージョンから利用可能です。

• Elastic.Clients.Elasticsearch v9.3.4 (9.x ブランチ)

• Elastic.Clients.Elasticsearch v8.19.18（8.xブランチ）

NuGetからのインストール：

dotnet add package Elastic.Clients.Elasticsearch

エントリーポイントはclient.Esqlにあります。

メソッド

戻り値

ユースケース

Query<T>(...)

IEnumerable<T>

同期実行

QueryAsync<T>(...)

IAsyncEnumerable<T>

非同期ストリーミング

CreateQuery<T>()

IEsqlQueryable<T>

高度な構成と検査

SubmitAsyncQueryAsync<T>(...)

EsqlAsyncQuery<T>

長時間実行されるサーバー側クエリ

クエリオプション、複数フィールドへのアクセス、ネストされたオブジェクト、複数値フィールドの処理など、機能の詳細についてはLINQ to ES|QLのドキュメントを参照してください。

まとめ

LINQ to ES|QLは、C# LINQの完全な表現力をElasticsearchのES|QLクエリ言語にもたらし、クエリ文字列を手作業で作成することなく、厳密に型付けされた構成可能なクエリを書くことができます。自動パラメーターキャプチャ、ストリーミングマテリアライゼーション、スタンドアロン変換から完全なElasticsearchクライアントまで拡張できる階層型パッケージアーキテクチャーにより、あらゆる規模の.NETアプリケーションに自然に適合します。最新のクライアントをインストールし、LINQ式をインデックスに向け、残りはプロバイダーに任せましょう。

これを解決するために、Elasticsearchのような検索エンジンは主に2つの最適化戦略を使用します。

1. 近似検索（Hierarchical Navigable Small World [HNSW]）：すべての文書をスキャンする代わりに、ナビゲーショングラフを構築して、回答の可能性が高い近傍に素早くジャンプします。

2. 量子化：メモリ使用量を削減し、計算速度を向上させるために、ベクトルを圧縮します（例えば、32ビット浮動小数点数から8ビット整数、あるいは1ビットのバイナリ値へ）。

しかし、最適化にはしばしば精度という代償が伴います。

「データを圧縮し、検索中にショートカットを取ると、最高の結果を見逃すのではないか？」「この最適化は検索エンジンの関連性を低下させるのではないか？」といった恐れは正当です。

Elasticの量子化が結果を低下させないことを証明するために、DBpedia-14 データセットを使用して再現可能なテストハーネスを構築し、Elasticsearchのデフォルトの最適化を使用する際に、速度と引き換えにどれだけの精度（具体的には再現率）を犠牲にしているかを正確に計算しました。

要約すると、それはおそらく想定よりもずっと少ないでしょう。こちらのノートブックをチェックして、ぜひご自身でお試しください。

定義（非専門家向け）

コードを見る前に、いくつかの用語について確認しておきましょう。

• 関連性対再現率：関連性 は主観的で（良いものが見つかったか？）、再現率は数学的なものです。データベース内にクエリと完全に一致する文書が10件あり、検索エンジンがそのうち9件を見つけた場合、再現率は90%（または0.9）です。

• 完全一致検索（フラット）：総当たり法とも呼ばれ、検索エンジンはインデックス内のすべての文書をスキャンし、距離を計算します。

  • 長所：100%完璧な再現率。

  • 短所：計算コストが高く、スケール時の処理速度が遅くなる。

• 近似探索（HNSW）：いわゆる「ショートカット」の方法。検索エンジンは HNSW グラフを作成し、グラフを巡回して最も近い隣接点を探します。

  • 長所：非常に高速で拡張性が高い。

  • 短所：グラフの探索が早すぎて停止すると、近傍を見逃す可能性がある。

実験：完全一致と近似探索の比較

再現率をテストするために、テキスト分類モデルのトレーニングと評価によく使用される、14のオントロジークラスにわたるタイトルと要約の大規模なデータセットDBPedia-14データセットを使用しました。具体的には、「Film」カテゴリに焦点を当てます。最適化された生産設定を、数学的に完璧な真値と比較したいと考えました。

この実験では、テキスト表現の業界ベンチマークをリードする最先端の多言語モデルjina-embeddings-v5-text-smallモデルを使用しています。このモデルを選んだ理由は、高性能埋め込みの現在の標準となっているためです。Jina v5の優れた精度とElasticsearchのネイティブ量子化を組み合わせることで、計算効率が高く、検索品質にも妥協のない検索アーキテクチャを実証できます。

二重マッピングを使用したインデックスを設定し、同じテキストを同時に2つの異なるフィールドに取り込みました。

1. content.raw（タイプ: flat）。これにより、ElasticsearchはFloat32ベクトル全体の総当たりスキャンを実行することになります。これにより完全一致の結果が返され、ベースラインとして使用されます。

2. content（タイプ： semantic_text）。デフォルトではHNSW + Better Binary Quantization（BBQ）を使用しています。これは、近似一致のための標準的かつ最適化された生産設定です。

Recall@10 テスト

指標としては、Recall@10を使用しました。

50本のランダムな映画を選び、両方のフィールドに同じクエリを実行しました。

• 完全一致（フラット）検索で上位10個の近傍が ID [1, 2, 3... 10] であると示されている場合。

• また、近似（HNSW）検索では、ID [1, 2, 3... 9, 99] が返されます。

• 上位10位のうち、9位を正しく特定できました。スコアは0.9です。

こちらが使用したマッピングです。

結果：成功の「横ばい線」

スケールテストを実行し、完全なデータセットを再読み込みし、1,000～40,000件の文書のインデックスサイズに対してテストしました。

再現率スコアに何が起こったかは以下のとおりです。

ドキュメント

Recall@10スコア

1,000

1.000 (100%)

5,000

0.998 (100%)

10,000

0.992 (99.4%)

20,000

0.999 (99.0％)

40,000

0.992 (98.8%)

結果は驚くほど安定していました。スケールアップしても、近似検索は総当たりの完全一致検索と99％超の確率で一致しました。

なぜこれほど上手くいったでしょう？

ベクトルをバイナリ値に圧縮すると、これよりも精度が低下すると考えられるかもしれません。その理由は、Elasticsearchが検索を処理する方法にあります。

今日のほとんどの埋め込みモデルは、大きなFloat32ベクトルを出力します。探索を効率的にするために、Elasticsearchは高次元ベクトルに対して量子化を使用します。具体的には、バージョン9.2以降、デフォルトでBBQを使用するようになりました。

BBQは再スコアリングメカニズムを採用しています。

1. トラバーサル：検索エンジンは圧縮された（量子化された）ベクトルを使ってHNSWグラフを高速に走査します。ベクトルが小さいため、効率的にオーバーサンプリングを行い、パフォーマンスを損なうことなく、より多くの候補リスト（例えば、類似性の高い上位100件の文書）を収集できます。

2. 再スコアリング：候補が見つかったら、その数件の文書について完全精度の値を取得して、最終的な正確なランキングを計算します。

これにより、量子化による高速な処理と、最終的なソートにおける浮動小数点数の精度という、両方の利点を享受できます。

もっと良くできるでしょうか？

注目すべき点は、ここで確認している結果がデフォルト設定とデータのランダムサンプリングを使用していることです。これは高性能の出発点とお考えください。Jina v5は非常に優れていますが、これらの再現率スコアはすべてのデータセットに対して「万能な」保証ではありません。すべてのデータ収集には独自の特性があり、さらにパフォーマンスを向上させるために調整することは可能ですが、常に自分の特定のデータに対してベンチマーク設定を行い、どこまで性能を引き出せるかを確認する必要があります。

まとめ

これは非常に小規模なテストです。ただし、この演習の目的は埋め込みモデルやBBQを個別に測定することではありません。最小限のセットアップで、データセットの再現率を簡単に測定する方法を示すことです。

このテストを独自のデータで実行したい場合は、こちらのノートブックをチェックして試してみてください。

HNSWでは、グラフ内の候補ノードを反復的に拡張し、これまでに発見された最も近い近傍の制限されたセットを維持することで検索が進行します。各拡張にはコスト（ベクトル演算、ディスクへのランダムシークなど）がかかり、そのコストに対する限界効用は検索が進むにつれて減少する傾向があります。

HNSWグラフのトラバーサルを最適化する1つの方法は、新しい真の近傍を見つける周辺尤度が増加しない場合に検索を停止することです。このため、Elasticsearch 9.2では、新しい早期終了メカニズムを導入しました。これは、グラフノードを訪問しても一定回数連続して十分な数の新しい最近傍が提供されない場合に、検索プロセスを停止するものです。

この記事では、HNSWの前述の早期終了メカニズムを改良して、さまざまなデータセットやデータ分布に適したものにする方法について説明します。

HNSWでの早期終了

HNSW では、近接グラフ内の候補ノードを反復的に拡張し、これまでに発見された最も近い近傍の制限されたセットを維持して、グラフ全体を訪問するか、早期終了基準を満たすまで、検索が続行されます。

したがって、早期終了は必ずしも最適化ではなく、検索アルゴリズム自体の一部です。停止を決定する瞬間が、効率性と再現率のバランスを決定します。Elasticsearchでは、HNSWのクエリを早期終了させる方法がすでにいくつか存在します。

• 固定された最大数のノードが訪問されます。

• 一定のタイムアウトに達した場合。

これらのルールは単純かつ予測可能ですが、検索が実際に何をしているかにはほとんど関係がありません。また、これらは主に、クエリがエンドユーザーにとって妥当な時間内に完了することを確認するために使用されます。

前回のブログ投稿ではHNSWにおける冗長性の概念を紹介しました。つまり、HNSWが新しい候補ノードを評価し続けても、さらに最も近い近傍が見つからない場合、冗長な計算が発生します。

忍耐度：努力ではなく進歩を測る

忍耐度という概念は、努力ではなく進歩を中心に早期終了を再構築します。

次のように尋ねる代わりに

「何ステップ進んだ？」

新たに次のように問いかけます。

「希望を失うまでに受け入れられる無駄な計算はどれだけかな？」

HNSW検索では、通常、初期の探索によっ上位k候補セットの最高の改善がもたらされます。HNSWグラフ探索の最初のステップでは、アルゴリズムがクエリベクトルにますます近い近傍を検出し続けるため、近傍のセットは継続的に更新されます。時間が経ち、検索が収束するにつれて、これらの改善はまれになります。忍耐度ベースの終了はこのパターンを監視し、改善が一定期間停止した時点で検索を終了します。

実際には、HNSWグラフを訪問する際、候補ノードをホップしながらキューの飽和比も計算します。これは、最新のグラフノードを訪問中に変更されなかった最も近い近傍の割合（または最後の反復中に導入された新しい近傍の数の逆数）を測定します。このような比率が連続した反復処理で大きくなりすぎると、グラフの訪問を停止します。

概念的には、忍耐度はHNSWの検索を収穫逓減プロセスとして扱います。リターンが平坦になると、グラフの調査を継続してもほとんど利益は得られません。

この枠組みは、終了を恣意的な固定された制限ではなく、観察可能な結果に直接結び付けるため、強力です。

このスマートな早期終了手法を使用する利点は、HNSWグラフ探索では、ほぼ完璧な相対再現率を維持しながら、より少数のグラフノードを訪問する傾向があることです。

これを視覚化するために、FinancialQAとQuoraという2つのデータセットと、JinaV3とE5-smallというモデルで、忍耐度に基づく早期終了（ et=staticとラベル付け）で取得した訪問ノードあたりの再現量を、デフォルトのHNSW動作（ et=noとラベル付け）と比較してプロットすることができます。

静的しきい値とHNSWのダイナミクス

実際には、Elasticsearchでは静的しきい値を使用してこれが実装されます。1つのしきい値は、飽和しきい値、つまり、最適ではないと判断される飽和度の比率を指します。もう1つのしきい値は、最適ではないキュー飽和を維持しながら連続して訪問できるグラフノードの数、つまり忍耐しきい値を指します。

Elasticsearch 9.2でこの早期終了戦略を導入したとき、レイテンシーとメモリ消費の面でメリットを得ながら再現率を可能な限り高められるように、保守的なデフォルトを選択することにしました。このため、KNNクエリでは飽和しきい値を100%に、忍耐しきい値を num_candidates の（有界の）30%に設定しています。

多くのシナリオでは、これらの設定はうまく機能しますが、同じ数の近傍を要求する2つのクエリでは、収束動作が根本的に異なる可能性があります。あるクエリは密集した局所的な近傍に遭遇し、すぐに飽和します。他のクエリは競争力のある候補を見つけるまでに、長くまばらな経路を通過しなければなりません。後者は、効果的に処理するのが最も困難であることが判明しました。

その結果、次のようなことに気付くことがありました。

• 簡単なクエリに対する過度の探索。

• 難しいクエリに対する時期尚早の終了。

したがって、固定されたしきい値は収束に関する全体的な仮定をエンコードしますが、HNSWをさまざまなダイナミクスに適応させることができると考えました。

HNSWの早期終了を適応的に

適応的早期終了は、この問題に異なる角度からアプローチします。事前に定義された停止しきい値を強制する代わりに、アルゴリズムが検索のダイナミクス自体からいつ停止するかを推測します。

したがって、2つの連続した候補間のキュー飽和比を比較する代わりに、即時平滑化発見率 （クエリqの最後の訪問iで導入された新しい隣接ノードの数）と、グラフ訪問中のそのような発見率の移動平均と標準偏差を導入することにしました（ウェルフォードのアルゴリズムを使用）。これらの発見率に関する統計はクエリごとに計算されるため、この情報をもとに各クエリの忍耐度を判断できます。

以前は静的であったしきい値は、発見率の統計に対して適応的になります。飽和しきい値はローリング平均と標準偏差の合計になり、一方で忍耐力は標準偏差に反比例して適応およびスケーリングされます。

早期終了ルールは変わらず、飽和は即時発見率が適応飽和しきい値より低い場合に発生します。適応的忍耐度よりも大きい連続候補訪問回数にわたって飽和が継続する場合、グラフ訪問は停止します。

こうすることで、KNNクエリの num_candidates パラメーターに依存しない動作（早期終了に関係なく、常に設定されるか、デフォルトのままになる場合がある）が得られ、各クエリとベクトル分布に動的に適応しやすくなります。

適応型戦略（ et=adaptiveとラベル付け）を使用したFinancialQAおよびQuoraでの訪問ノードあたりの再現率は、静的戦略（ et=static ）およびデフォルトのHNSW動作（ et=no ）と比較した場合、高くなっています。

適応的早期終了はElasticsearch 9.3ではHNSWの高密度ベクトルフィールドに対してデフォルトでオンになっています（最終的には同じインデックスレベルの設定でオフにすることができます）。

2,000万件の文書コーパスを用いたベンチマークテストの結果、Elasticsearchはフィルタリングされたベクトル検索においてOpenSearchよりも最大8倍高いスループットを実現し、テストしたすべての構成においてより高いRecall@100を達成しました。コンテキストエンジニアリングに必要な要素は高速ベクトル取得だけではありません。ワークフローの反復につれて、チームはハイブリッド検索やフィルタリングなどの強力な関連性制御、操作の簡便性、予測可能なパフォーマンスも必要とするようになります。しかし、エージェントはリクエストごとに取得、推論、取得のループを何度も実行することが多いため、取得の遅延が乗数効果となり、ここでの改善はエンドツーエンドの応答性の向上とコスト削減に直接つながります。

コンテキストエンジニアリングにおいて、取得は一度きりのステップではありません。エージェントとアプリケーションは、クエリを洗練させ、事実を検証し、根拠に基づいたコンテキストを構築し、タスクを完了するために、取得 → 推論 → 取得といったループを繰り返し実行します。このパターンは、エージェント型ワークフローや反復型検索拡張生成（RAG）においてよく見られます。検索はユーザーリクエストごとに何度も呼び出される可能性があるため、応答に遅延が生じ、インフラコストが増加します。

ベクトル検索のパフォーマンスが重要な理由

「15インチのノートパソコンが入る、防水性があり、金曜日までに届く60ドル以下の機内持ち込み用バックパックが必要です」という質問に、店員が答える場面を想像してみてください。

実際の運用環境では、アシスタントがベクトルクエリを1回発行して停止することはほとんどありません。適切なコンテキストを構築するために検索ループを実行し、各ステップは通常、在庫状況、地域、出荷約束、ブランドルール、ポリシー適格性などのフィルターによって制約されます。

ステップ1：意図を解釈し、制約に変換する。

エージェントはリクエストを構造化されたフィルタとセマンティッククエリに変換します。例えば、次のようなものです。

• フィルター：在庫あり、ユーザーの郵便番号に配達可能、金曜日までに配達、価格60ドル未満、有効な出品

• ベクトルクエリ：「機内持ち込み用バックパック 15インチノートパソコン対応 防水」

ステップ2：候補を取得し、絞り込む。

適切な一致を見逃さないように、しばしばバリエーションを加えて検索を繰り返します。

• 「旅行用バックパック 機内持ち込み可能 ノートパソコン用スリーブ」

• 「防水通勤用バックパック 15インチ」

• 「軽量 機内リュック」

各クエリは同じ適格性フィルターを使用します。なぜなら、無関係な項目や利用できない項目を取得することは、コンテキストの無駄になるからです。

ステップ3：詳細を確認し、リスクを軽減するために展開する。

エージェントは、最終的な回答に影響を与える主要な属性を再度確認するために取得を行います。

• 素材と耐水性に関する記述

• 寸法とノートパソコン収納部の適合性

• 返品ポリシーや保証の制約

• 在庫が少ない場合の代替オプション

これは、取得、推論、取得、組み立てという複数段階のコンテキストエンジニアリングです。

コンテキストエンジニアリングにおいてレイテンシと再現率が重要な理由

これらのやり取りには、ユーザーセッションごとに数十回のフィルタリングされたデータ取得呼び出しが含まれる場合があります。それにより、呼び出しごとのレイテンシがエンドツーエンドの応答時間に直接的な乗数となり、低い再現率は追加の再試行を強制したり、エージェントが対象アイテムを見逃す原因となり、回答の質を低下させます。

要点：コンテキストエンジニアリングされたシステムでは、フィルタリングされた近似最近傍法（ANN）は単一のルックアップではありません。これは制約下での反復処理であるため、大規模言語モデル（LLM）が最も目立つ要素である場合でも、ベクトル検索のパフォーマンスはレイテンシ、スループット、コストにすぐに現れます。

ベンチマーク

成果

グラフ2では、各点が1つのテスト構成を表しています。最も良い結果は左上に表示され、これは低いレイテンシで高い再現率が得られることを意味します。Elasticsearchの結果はOpenSearchよりも常に左上に近く、同じワークロード設定下でより優れた速度と精度を示しています。

いくつかの重要な洞察

• s_n_r_value: size_numCandidates_rescoreOversampleの省略形（これらのテストではkとnumCandidatesはnumCandidatesと等しく設定されます）。例えば、 100_500_1 size=100、numCandidates=500、k=500、再スコアオーバーサンプル=1 を意味します。

• 再現率：その構成における測定Recall@100

• 平均レイテンシ（ミリ秒）：クエリごとの平均エンドツーエンドレイテンシ

• スループット：1秒あたりのクエリ数

• 再現率（％）：ElasticsearchとOpenSearchの相対的な再現率向上率（Elasticsearch - OpenSearch）/OpenSearch

• レイテンシXs：OpenSearchの平均レイテンシをElasticsearchの平均レイテンシで割った値

• スループットX：Elasticsearchのスループットをオープンサーチのスループットで割った値

エンジン

`s_n_r_value`

リコール

平均レイテンシ（ミリ秒）

スループット

再現率（％）

レイテンシ Xs

スループット Xs

Elasticsearch

100_250_1

0.7704

25

534.75

9.70％

2.28

1.91

OpenSearch

100_250_1

0.7023

57.08

279.58

Elasticsearch

100_500_1

0.8577

25.42

524.14

7.20%

2.4

2

OpenSearch

100_500_1

0.8001

60.9

262.12

Elasticsearch

100_750_1

0.8947

29.67

528.09

5.72％

2.25

2.21

OpenSearch

100_750_1

0.8463

66.76

239.11

Elasticsearch

100_1000_1

0.9156

29.65

534.5

4.66％

2.46

2.44

OpenSearch

100_1000_1

0.8748

72.88

219.01

Elasticsearch

100_1500_1

0.9386

31.84

497.3

3.38％

2.71

2.68

OpenSearch

100_1500_1

0.9079

86.16

185.4

Elasticsearch

100_2000_1

0.9507

34.69

457.2

2.57%

2.98

2.96

OpenSearch

100_2000_1

0.9269

103.36

154.55

Elasticsearch

100_2500_1

0.9582

37.9

418.43

1.99％

3.28

3.26

OpenSearch

100_2500_1

0.9395

124.29

128.53

Elasticsearch

100_3000_1

0.9636

41.86

379.4

1.62％

3.46

3.44

OpenSearch

100_3000_1

0.9482

144.67

110.34

Elasticsearch

100_4000_1

0.9705

50.28

316.21

1.06%

3.87

3.85

OpenSearch

100_4000_1

0.9603

194.36

82.22

Elasticsearch

100_5000_1

0.9749

58.77

270.91

0.73%

4.43

4.41

OpenSearch

100_5000_1

0.9678

260.33

61.38

Elasticsearch

100_6000_1

0.9781

66.75

238.59

0.52%

4.91

4.89

OpenSearch

100_6000_1

0.973

327.44

48.81

Elasticsearch

100_7000_1

0.9804

74.64

213.49

0.38％

5.28

5.27

OpenSearch

100_7000_1

0.9767

394.24

40.53

Elasticsearch

100_8000_1

0.9823

82.28

193.59

0.27％

6.86

6.83

OpenSearch

100_8000_1

0.9797

564.14

28.33

Elasticsearch

100_9000_1

0.9837

90.08

176.96

0.16%

7.63

7.61

OpenSearch

100_9000_1

0.9821

687.25

23.25

Elasticsearch

100_10000_1

0.9848

97.64

163.31

0.08%

8.38

8.36

OpenSearch

100_10000_1

0.984

818.64

19.53

例えば、100_9000_1では、OpenSearchの平均取得時間687ミリ秒に対してElasticsearchは90ミリ秒であり、10ステップの取得ループでは約10×(687-90)=6秒の追加待機時間となります。

全ての結果をご覧ください。

調査手法

Pythonを使ってクエリを送信し、対応タイミングやその他の統計を追跡し、以下のクエリをエンジンに送信しました。ベクター検索エンジンのパフォーマンスは、そのコアパラメータ（考慮する候補の数、再スコアリングの積極性、返されるコンテキストの量など）をどのように調整するかによって決まることを覚えておいてください。これらの設定は、再現率（正解を見つける可能性）とレイテンシ（結果を得るまでの速さ）の両方に直接影響します。

ベンチマークでは、エージェント検索ループで通常調整するのと同じ候補、再スコア、結果サイズの設定を使用し、そのワークロード下でElasticsearchがどのように機能するかを測定しました。その後、同じ設定でOpenSearchをリファレンスとして実行しました。

OpenSearch

• "size": <RESULT_SIZE>: クライアントに返されたヒット数。このベンチマークでは、Recall@100を計算するために、結果のサイズは100です。

• "k": <NUMBER_OF_CANDIDATES>: 最近傍候補の数。

• "ef_search": <NUMBER_OF_CANDIDATES>: 検査するベクトルの数。

• "oversample_factor": <OVERSAMPLE>: 再スコアリングを行う前に取得される候補ベクトルの数。

Elasticsearch

• "size": <RESULT_SIZE>: クライアントに返されたヒット数。このベンチマークでは、Recall@100を計算するために、結果のサイズは100です。

• "k": <NUMBER_OF_CANDIDATES>: 各シャードから返す最近傍の数。

• "num_candidates": <NUMBER_OF_CANDIDATES>: knn検索を実行する際にシャードごとに考慮する最近傍候補の数。

• "oversample": <OVERSAMPLE>: 再スコアリングを行う前に取得される候補ベクトルの数。

例

Knn クエリ（ 100_500_1 ）は次のようになります。

OpenSearch

Elasticsearch

Terraformスクリプト、Kubernetesマニフェスト、ベンチマークコードとともに、完全な構成はこのリポジトリのes-9.3-vs-os-3.5-vector-searchフォルダで入手可能です。

クラスターの設定

私たちは、16 vCPUと64 GB RAMを備えた6台のe2-standard-16クラウドサーバーでテストを実行しました。各サーバーにおいて、検索エンジンノードを実行する各Kubernetesポッドに15個のvCPUと56GBのRAMを割り当て、そのうち28GBをJVMヒープ用に確保しました。

クラスターはElasticsearch 9.3.0とOpenSearch 3.5.0（Lucene 10.3.2）で実行しました。このベンチマークでは両方のシステムが同じLuceneバージョンを使用しているため、観測されたスループットとレイテンシの違いはLucene単独に起因するものではなく、各エンジンがフィルタリングされたk近傍法（kNN）による検索と再スコアリングをどのように統合し実行するかの違いを反映します。私たちは、3つのプライマリシャードと1つのレプリカ（合計6つのシャード、ノードごとに1つ）を持つ単一のインデックスを使用しました。

我々はまた、同じリージョン内の別のサーバーを使用してベンチマーククライアントを実行し、タイミング統計を収集しました。

データセット

このベンチマークでは、2,000万件のドキュメントを含む大規模なeコマーススタイルのカタログ埋め込みデータセットを使用しました。これは、実世界のフィルタリングされたベクトル検索を大規模なスケールで反映するように設計されています。

各ドキュメントはカタログ項目を表し、以下を含みます。

• 近似kNN検索に使用される128次元の密なベクトル埋め込み。

• 構造化されたメタデータフィールドを使用してフィルタリング（例：アイテムの有効性と可用性、およびその他のカタログ制約）を行うことで、適格なサブセット内でのみ最近傍を取得するという一般的な本番パターンを可能にします。

このデータセットを選んだ理由は、本番環境におけるエージェント型システムやRAG型システムで見られる主要なパフォーマンス上の課題を捉えているからです。つまり、ベクトル類似性だけでは不十分であり、検索はフィルタによって制約されることが多く、システムはこれらの制約の下で高い再現率を維持しながらレイテンシを低く抑える必要があるということです。より小規模なQAスタイルのデータセットと比較すると、2000万件の文書コーパスは、フィルタリングされたANNシステムが実際に直面する規模と候補数によるプレッシャーをより適切に反映しています。

まとめ

現代のAIアーキテクチャー、特にコンテキストエンジニアリングを中心としたアーキテクチャーにおいては、ベクトル探索の速度は些細な実装上の問題ではなく、乗数です。エージェントとワークフローが取得 → 推論 → 取得を繰り返す際、検索パフォーマンスはエンドツーエンドのレイテンシ、スループット、モデルに供給されるコンテキストの品質を直接形作ります。

当社のベンチマークでは、Elasticsearchは、OpenSearchと比べて、より低いレイテンシで一貫して高い再現率を達成しました。これは、類似ベクトルの取得だけでなく、正確性が「適切なドキュメントを取得できること」に左右されるシナリオで顕著でした。制御されたデータセットではその差は明確であり、本番環境では、大量の検索呼び出しを通じてそれらの利点が蓄積され、応答性が向上し、容量余裕が増加し、インフラストラクチャーコストが削減されます。

参考資料

1. コンテキストエンジニアリングとは何ですか？

2. ハイブリッド検索とコンテキストエンジニアリングの進化

3. AIエージェント向けコンテキストエンジニアリングにおける関連性の影響

要約

まず、現状をお伝えしましょう。Elasticsearchは、強力なベクトルデータベースとして確立され、大規模な類似性検索に対して豊富な特徴と強力なパフォーマンスを提供しています。スカラー量子化、Better Binary Quantization（BBQ）、SIMDベクトル演算、DiskBBQのようなよりディスク効率の高いアルゴリズムなどの機能により、すでにベクトルワークロードの管理に効率的かつ柔軟な選択肢を提供しています。

NVIDIA cuVSをベクトル検索タスク用の呼び出し可能なモジュールとして統合することで、ベクトルインデキシングのパフォーマンスと効率を大幅に向上させ、大規模なベクトルワークロードをより良くサポートすることを目指しています。

課題

高性能ベクトルデータベースを構築する上で最も困難な課題の一つは、ベクトルインデックス（HNSWグラフ）を構築することです。インデックス構築は、すべてのベクトルが他の多数のベクトルと比較されるため、すぐに数百万、あるいは数十億の算術演算によって支配されるようになります。さらに、インデックスのライフサイクル操作、例えば圧縮やマージなどは、インデキシングの全体的な計算オーバーヘッドをさらに増加させる可能性があります。データ量と関連するベクトル埋め込みが指数関数的に増加するにつれ、大規模な並列処理と高スループットの数学演算用に構築された高速コンピューティングGPUは、これらのワークロードを処理するのに理想的な位置にあります。

Elasticsearch-GPUプラグインの登場

NVIDIA cuVSは、GPUによるベクトル検索とデータクラスタリングのためのオープンソースCUDA-Xライブラリであり、AIおよび推奨ワークロード向けの高速インデックス構築と埋め込み検索を可能にします。

ElasticsearchはcuVSをcuvs-javaを通じて使用しています。cuvs-javaはコミュニティが開発し、NVIDIAが保守するオープンソースライブラリです。cuvs-javaライブラリは軽量で、cuVS C APIをベースにPanama Foreign Functionを使用して、cuVSの特徴をJavaらしい方法で公開しつつ、モダンな高性能を維持しています。

cuvs-javaライブラリは新しいElasticsearchプラグインに統合されています。そのため、GPU上でのインデキシングを同じElasticsearchノードとプロセスで実行でき、外部のコードやハードウェアを提供する必要はありません。CUVsライブラリがインストールされていて、GPUが存在して構成されている場合、インデキシング中にElasticsearchはGPUを使用してベクターインデキシング処理を高速化します。ベクトルはGPUに提供され、GPUはCAGRAグラフを構築します。その後、このグラフはHNSW形式に変換され、CPU上でのベクトル検索にすぐに利用可能になります。構築されたグラフの最終的な形式は、CPU上に構築されるものと同じです。これによりElasticsearchは、基盤となるハードウェアがサポートしている場合、GPUを活用して高スループットのベクトルインデックスを作成し、CPUのパワーを他のタスク（同時検索やデータ処理など）に解放することができます。

インデックス構築の加速

ElasticsearchにGPUアクセラレーションを統合する一環として、cuvs-javaにいくつかの機能強化が行われ、効率的なデータのインプット/出力と関数呼び出しに焦点が当てられました。主要な機能強化は、cuVSMatrixを使用して、Javaヒープ、オフヒープ、またはGPUメモリに存在するベクトルを透過的にモデル化することです。これにより、データをメモリとGPU間で効率的に移動でき、潜在的に数十億のベクトルの不要なコピーを回避できます。

この基礎となるゼロコピー抽象化のおかげで、GPUメモリへの転送とグラフの取得の両方が直接実行できます。インデキシング中、ベクトルは最初にJavaヒープ上のメモリにバッファリングされ、その後GPUに送られてCagraグラフを構築します。その後、グラフはGPUから取得され、HNSW形式に変換され、ディスクに保存されます。

マージ時には、ベクトルはすでにディスクに格納されており、Javaヒープを完全にバイパスします。インデックスファイルはメモリマップされ、データは直接GPUメモリに転送されます。この設計は、float32やint8などのさまざまなビット幅にも簡単に対応し、他の量子化スキームにも自然に拡張できます。

実際のパフォーマンス

数字を見てみる前に、少し背景を説明しておきましょう。Elasticsearchのセグメントマージは通常、インデキシング中にバックグラウンドで自動的に実行されるため、分離してベンチマークをとることが難しくなります。再現可能な結果を得るために、制御された実験でforce-mergeを使用してセグメントのマージを明示的にトリガーしました。force-mergeはバックグラウンドマージと同じ基礎となるマージ操作を実行するので、実際のインデキシングワークロードでは正確な効果が異なる場合でも、そのパフォーマンスは期待される改善を示す有用な指標となります。

さて、数字を見てみましょう。

最初のベンチマーク結果は非常に有望です。ベンチマークは、ローカルに接続されたNVMeストレージを持つAWS g6.4xlargeインスタンスで実行しました。Elasticsearchのシングルノードは、デフォルトの最適なインデキシングスレッド数（各物理コアに1つずつの計8つ）を使用し、マージスロットリング（高速NVMeディスクではあまり適用されません）を無効にするように設定しました。

データセットにはOpenAI Rallyベクトルトラックから取得した1,536次元のベクトル260万個をbase64文字列としてエンコードし、float32 hnswとしてインデックスして使用しました。すべてのシナリオにおいて、構築されたグラフは最大95%のリコールレベルを達成します。結果は以下となりました。

• インデキシングのスループット：メモリ内バッファのフラッシュ中にグラフ構築を GPU に移動することで、スループットが約 12 倍向上します。

• 強制マージ：インデキシングが完了した後、GPUはセグメントのマージを加速し続け、強制マージフェーズを約7倍高速化します。

• CPU使用率：グラフ構築をGPUにオフロードすると、平均およびピーク時のCPU使用率が大幅に削減されます。以下のグラフは、インデキシングとマージ中のCPU使用率を示しており、これらの操作をGPUで実行すると使用率がどれだけ低くなるかを強調しています。GPUインデキシング中のCPU使用率が低下すると、CPUサイクルが解放され、検索パフォーマンスの向上に向けることができます。

• リコール：CPU実行とGPU実行の精度は実質的に同じですが、GPUで構築されたグラフのリコールはわずかに高くなります。

別の次元での比較：価格

先ほどの比較では、意図的に同一のハードウェアが使用されており、唯一の違いはインデキシング中にGPUが使用されたかどうかでした。この設定は、生のコンピューティング効果を分離するのに役立ちますが、コストの観点から比較することもできます。

GPUアクセラレーション構成とほぼ同じ時間単価で、同等のCPUおよびメモリリソースの約2倍（32個のvCPU（AMD EPYC）と64GBのRAM）を備えたCPUのみのセットアップをプロビジョニングでき、インデキシングスレッドの数を2倍の16に増やすことができます。

比較を公平かつ一貫性のあるものにするために、このCPUのみの実験をAWS g6.8xlargeインスタンスで実行しました。GPUは明示的に無効になっています。これにより、GPUアクセラレーションとCPUのみのインデキシングのコストパフォーマンスのトレードオフを評価する際、他のすべてのハードウェア特性を一定に保つことができました。

予想どおり、より強力なCPUインスタンスでは、上記のセクションのベンチマークと比較してパフォーマンスが向上しています。しかし、このより強力なCPUインスタンスを元のGPUアクセラレーション結果と比較すると、GPUは、リコールレベル最大95%に達するグラフを構築しながら最大5倍のインデキシングスループット向上、最大6倍のフォースマージと、依然として大幅なパフォーマンス向上を提供します。

結論

エンドツーエンドのシナリオでは、NVIDIA cuVSによるGPUアクセラレーションにより、インデキシングのスループットが約12倍向上し、force-mergeのレイテンシが7倍減少し、CPU使用率が大幅に低下します。これは、ベクトルインデキシングとマージワークロードがGPUアクセラレーションから大きな恩恵を受けることを示しています。コスト調整後の比較では、GPUアクセラレーションは引き続き大幅なパフォーマンス向上をもたらし、インデキシングのスループットは約5倍、force-merge操作は6倍高速化されます。

GPUアクセラレーションによるベクトルインデキシングは、現在Elasticsearch 9.3の技術プレビューで計画されており、2026年初頭にリリース予定です。

続報をお楽しみに。

これを実現するために、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

キーワード

アマ・ダブラム

安定したスラッグ/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 に一致しないものを指示する）: 「絵画、イラスト、ポスター、地図、ロゴ」の小さなベクトルを減算して、実際の写真に偏向させます。

• ピークの参照画像が提供されている場合は、オプションで画像プロトタイプを作成します。

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

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フィールドを計算します。これにより、複数回実行した後に重複が発生しなくなります。

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

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

要約すると、写真のインデックスは、アルバム内のすべての写真を格納する、高速でフィルタリング可能な 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

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

このシリーズの最後の部分では、Elastic の事前トレーニング済み E5 モデル (および Hugging Face の他の多言語テキスト埋め込みモデル) のデプロイについて説明し、Elasticsearch と Kibana を使用してテキスト データから高密度のベクトル埋め込みを生成する方法について詳しく説明しました。このブログでは、これらの埋め込みの結果を調べ、多言語モデルを活用することの大きな利点を強調します。

インデックスcoco_multilingualが作成されたので、検索を実行すると、参照用の「en」フィールドを含む複数の言語のドキュメントが表示されます。

英語で検索する

英語で検索を実行して、どれくらいうまくいくか確認してみましょう。

ここでは、クエリは一見単純に見えますが、内部的にはすべての言語のすべてのドキュメントにわたって「kitty」という単語の数値埋め込みを検索しています。また、ベクトル検索を実行しているため、「kitty」に関連する可能性のあるすべての単語を意味的に検索できます。「cat」、「kitten」、「feline」、「gatto」（イタリア語）、「mèo」（ベトナム語）、고양이（韓国語）、猫（中国語）などです。その結果、クエリが英語であっても、他のすべての言語でコンテンツを検索できるようになります。たとえば、「a kitty l ying on somethingを検索すると、イタリア語、オランダ語、ベトナム語のドキュメントも返されます。効率について話しましょう!

他の言語でコンテンツを検索する

同様に、韓国語で「cat」（「고양이」）のキーワード検索を実行しても、意味のある結果が返されます。驚くべきことに、このインデックスには韓国語の文書がまったくありません。

これが機能するのは、埋め込みモデルが意味を共有セマンティック空間で表現し、インデックス付けされたキャプションとは異なる言語でのクエリでも関連する画像を取得できるためです。

ハイブリッド検索と再ランキングによる関連性の高い検索結果の向上

関連する結果が期待どおりに表示されたことを嬉しく思います。しかし、現実の世界では、たとえば、最も関連性の高い上位 5 ～ 10 件の結果に絞り込む必要がある e コマースや RAG アプリケーションでは、再ランク付けモデルを使用して最も関連性の高い結果を優先することができます。

ここで、ベトナム語で「猫の色は何色ですか？」と尋ねるクエリを実行すると、多くの結果が表示されますが、上位 1 つまたは 2 つが最も関連性が高いとは限りません。

結果にはすべて「猫」または何らかの形の色が言及されています。

では、それを改善しましょう!Cohereの多言語再ランク付けモデルを統合して、質問に対応する推論を改善しましょう。

これで、上位の結果により、アプリケーションは子猫の色が黒か茶色で縞模様であると自信を持って答えることができます。ここでさらに興味深いのは、ベクトル検索によって、元のデータセットの英語のキャプションの欠落が実際に検出されたことです。参照の英語翻訳ではその詳細が抜けていたにもかかわらず、茶色の縞模様の猫を見つけることができます。これがベクトル検索の威力です。

まとめ

このブログでは、多言語埋め込みモデルの有用性と、Elasticsearch を活用してモデルを統合し埋め込みを生成する方法、ハイブリッド検索と再ランク付けによって関連性と精度を効果的に向上させる方法について説明しました。独自のクラウド クラスターを作成し、選択した言語とデータセットですぐに使用できる E5 モデルを使用して、多言語セマンティック検索を試すことができます。

世界中のユーザーがいる世界では、言語間情報検索 (CLIR) が非常に重要です。CLIR を使用すると、検索を 1 つの言語に限定するのではなく、あらゆる言語で情報を検索できるため、ユーザー エクスペリエンスが向上し、操作が効率化されます。電子商取引の顧客が自分の言語で商品を検索でき、事前にデータをローカライズする必要なく、適切な結果が表示されるグローバル市場を想像してみてください。あるいは、情報源が別の言語であっても、学術研究者がニュアンスや複雑さを含めて母国語で論文を検索できる場所です。

多言語テキスト埋め込みモデルを使用すると、まさにそれが実現できます。埋め込みは、テキストの意味を数値ベクトルとして表現する方法です。これらのベクトルは、同様の意味を持つテキストが高次元空間内で互いに近く配置されるように設計されています。多言語テキスト埋め込みモデルは、特に、異なる言語間で同じ意味を持つ単語やフレーズを同様のベクトル空間にマッピングするように設計されています。

オープンソースの Multilingual E5 のようなモデルは、多くの場合、対照学習などの手法を使用して、大量のテキスト データでトレーニングされます。このアプローチでは、モデルは類似した意味を持つテキストのペア (肯定的なペア) と類似しない意味を持つテキストのペア (否定的なペア) を区別することを学習します。モデルは、正のペア間の類似性が最大化され、負のペア間の類似性が最小化されるように、生成するベクトルを調整するようにトレーニングされます。多言語モデルの場合、このトレーニング データには、相互に翻訳された異なる言語のテキスト ペアが含まれており、モデルが複数の言語の共有表現空間を学習できるようになります。結果として得られる埋め込みは、クエリの言語に関係なく、テキスト埋め込み間の類似性を使用して関連するドキュメントを検索するクロスリンガル検索を含むさまざまな NLP タスクに使用できます。

多言語ベクター検索のメリット

• ニュアンス: ベクター検索は、キーワードのマッチングを超えて、意味を捉えることに優れています。これは、文脈や言語の微妙なニュアンスを理解する必要があるタスクにとって非常に重要です。

• クロスリンガル理解: クエリとドキュメントが異なる語彙を使用している場合でも、言語間で効果的な情報検索を可能にします。

• 関連性: クエリとドキュメント間の概念的な類似性に焦点を当てることで、より関連性の高い結果を提供します。

たとえば、さまざまな国における「ソーシャル メディアが政治的議論に与える影響」を研究している学術研究者を考えてみましょう。ベクトル検索を使用すると、「l'impatto dei social media sul discorso politico」（イタリア語）または「ảnh hưởng của mạng xã hội đối với diễn ngôn chính trị」（ベトナム語）などのクエリを入力し、英語、スペイン語などで関連する論文を見つけることができます。他のインデックス付き言語。これは、ベクトル検索では、正確なキーワードを含む論文だけでなく、ソーシャル メディアの政治への影響の概念について議論している論文も特定されるためです。これにより、研究の幅と深さが大幅に向上します。

使い始める

Elasticsearch を使用して CLIR を設定する方法 (すぐに使用できる E5 モデルを使用) を次に示します。複数の言語の画像キャプションを含むオープンソースの多言語 COCO データセットを使用して、2 種類の検索を視覚化します。

1. 1つの英語データセット上の他の言語のクエリと検索用語、および

2. 複数の言語のドキュメントを含むデータセットに対する複数の言語でのクエリ。

次に、ハイブリッド検索と再ランキングの力を活用して、検索結果をさらに改善します。

要件

• Python 3.6以上

• Elasticsearch 8以上

• Elasticsearch Pythonクライアント: pip install elasticsearch

データセット

COCO データセットは、大規模なキャプション データセットです。データセット内の各画像には複数の異なる言語でキャプションが付けられており、言語ごとに複数の翻訳が利用可能です。デモンストレーションの目的で、各翻訳を個別のドキュメントとしてインデックス化し、参照用に最初の利用可能な英語の翻訳もインデックス化します。

ステップ1: 多言語COCOデータセットをダウンロードする

ブログを簡素化し、理解しやすくするために、ここでは、単純な API 呼び出しを使用して、restval の最初の 100 行をローカル JSON ファイルに読み込みます。あるいは、HuggingFace のライブラリ データセットを使用して、完全なデータセットまたはデータセットのサブセットを読み込むこともできます。

データが JSON ファイルに正常に読み込まれると、次のようなものが表示されます。

Data successfully downloaded and saved to multilingual_coco_sample.json

ステップ2: (Elasticsearchを起動) Elasticsearchでデータをインデックスする

a) ローカル Elasticsearch サーバーを起動します。

b) Elasticsearch クライアントを起動します。

c) インデックスデータ

データがインデックスされると、次のようなものが表示されます。

Successfully bulk indexed 4840 documents

Indexing complete!

ステップ3: E5トレーニング済みモデルをデプロイする

Kibanaで、スタック管理 >トレーニング済みモデルページに移動し、.multilingual-e5-small_linux-x86_64のデプロイをクリックします。オプション。この E5 モデルは、linux-x86_64 向けに最適化された小型の多言語モデルで、そのまま使用できます。「デプロイ」をクリックすると、デプロイ設定または vCPU 構成を調整できる画面が表示されます。簡単にするために、デフォルト オプションを使用し、適応型リソースを選択します。これにより、使用状況に応じてデプロイメントが自動的にスケーリングされます。

オプションとして、他のテキスト埋め込みモデルを使用することもできます。たとえば、BGE-M3 を使用するには、 Elastic の Eland Python クライアントを使用して HuggingFace からモデルをインポートできます。

次に、「トレーニング済みモデル」ページに移動し、インポートしたモデルを必要な構成でデプロイします。

ステップ4: デプロイされたモデルを使用して元のデータをベクトル化または埋め込みを作成する

埋め込みを作成するには、まずテキストを取得して推論テキスト埋め込みモデルに通すことができる取り込みパイプラインを作成する必要があります。これは、Kibana のユーザー インターフェースまたは Elasticsearch の API を通じて実行できます。

Kibana インターフェース経由でこれを行うには、トレーニング済みモデルをデプロイした後、 [テスト]ボタンをクリックします。これにより、生成された埋め込みをテストおよびプレビューできるようになります。cocoの新しいデータビューを作成しますインデックスを作成し、データ ビューを新しく作成した coco データ ビューに設定し、フィールドをdescriptionに設定します。これは、埋め込みを生成するフィールドだからです。

それは素晴らしいですね！これで、取り込みパイプラインの作成に進み、元のドキュメントのインデックスを再作成し、パイプラインに渡して、埋め込みを含む新しいインデックスを作成できます。これを実現するには、 「パイプラインの作成」をクリックします。これにより、埋め込みの作成に必要なプロセッサが自動的に入力され、パイプラインの作成プロセスがガイドされます。

ウィザードでは、データの取り込みと処理中に障害を処理するために必要なプロセッサを自動的に入力することもできます。

それでは、取り込みパイプラインを作成しましょう。パイプラインにcoco_e5という名前を付けます。パイプラインが正常に作成されたら、ウィザードで元のインデックス付きデータを新しいインデックスに再インデックスすることで、パイプラインをすぐに使用して埋め込みを生成できます。プロセスを開始するには、 「再インデックス」をクリックします。

より複雑な構成の場合は、Elasticsearch API を使用できます。

一部のモデルでは、モデルのトレーニング方法により、埋め込みを生成する前に実際の入力の先頭または末尾に特定のテキストを追加する必要がある場合があります。そうしないと、パフォーマンスが低下します。

たとえば、e5 の場合、モデルは入力テキストが「passage: {content of passage} 」に続くことを想定します。これを実現するために、取り込みパイプラインを活用しましょう。新しい取り込みパイプラインvectorize_descriptions を作成します。このパイプラインでは、新しい一時的なtemp_descフィールドを作成し、 descriptionテキストの先頭に「passage:」を追加し、モデルでtemp_descを実行してテキスト埋め込みを生成し、 temp_descを削除します。

さらに、生成されたベクトルに使用する量子化の種類を指定することもできます。デフォルトでは、Elasticsearch はint8_hnswを使用しますが、ここでは各次元を 1 ビットの精度に削減するBetter Binary Quantization (またはbqq_hnsw ) を使用します。これにより、精度は犠牲になりますが、メモリ フットプリントが 96% (または 32 倍) 削減されます。後で再ランク付けを使用して精度の低下を改善することが分かっているため、この量子化タイプを選択しています。

そのためには、 coco_multiという名前の新しいインデックスを作成し、マッピングを指定します。ここでの魔法は vector_description フィールドにあり、そこでindex_optionsのタイプをbbq_hnswに指定します。

これで、説明フィールドを「ベクトル化」または埋め込みを作成する取り込みパイプラインを使用して、元のドキュメントを新しいインデックスに再インデックスできます。

以上です！Elasticsearch と Kibana を使用して多言語モデルを正常にデプロイし、Kibana ユーザー インターフェースまたは Elasticsearch API を使用して Elastic でデータにベクトル埋め込みを作成する方法を段階的に学習しました。このシリーズの第 2 部では、多言語モデルを使用した場合の結果とニュアンスについて説明します。その間、独自のクラウド クラスターを作成し、選択した言語とデータセットですぐに使用できる E5 モデルを使用して多言語セマンティック検索を試すことができます。

ベクトル検索でのフィルタリングの仕組みを理解すると、パフォーマンスとリコールのトレードオフのバランスをとるのに役立ちます。また、フィルタリングの使用時にベクトル検索のパフォーマンスを高めるために使用される最適化のいくつかを知ることもできます。

なぜフィルタリングするのですか?

ベクトル検索は、大規模なデータセット内で関連情報を検索する方法に革命をもたらし、クエリと意味的に類似する項目を発見できるようになりました。

ただし、類似アイテムを見つけるだけでは十分ではありません。多くの場合、特定の基準や属性に基づいて検索結果を絞り込む必要があります。

電子商取引ストアで商品を検索していると想像してください。純粋なベクター検索では視覚的に類似したアイテムが表示される場合がありますが、価格帯、ブランド、在庫状況、または顧客評価でフィルタリングすることもできます。フィルタリングがなければ、類似した製品が大量に表示され、探しているものを正確に見つけることが難しくなります。

フィルタリングにより、検索結果を正確に制御できるようになり、取得された項目が意味的に一致するだけでなく、必要な要件をすべて満たすことが保証されます。これにより、より正確で効率的、そしてユーザーフレンドリーな検索エクスペリエンスが実現します。

Elasticsearch と Apache Lucene が優れているのはこの点です。さまざまなデータ タイプにわたって効果的なフィルタリングを使用することが、他のベクター データベースとの主な違いの 1 つです。

正確なベクトル検索のためのフィルタリング

正確なベクトル検索を実行するには、主に 2 つの方法があります。

• dense_vector フィールドにflatインデックス タイプを使用します。これにより、 knn検索では近似検索ではなく正確な検索が使用されるようになります。

• ベクトル関数を使用してスコアを計算するscript_score クエリを使用します。これはどのインデックス タイプでも使用できます。

正確なベクトル検索を実行すると、すべてのベクトルがクエリと比較されます。このシナリオでは、フィルターを通過するベクトルのみを比較する必要があるため、フィルタリングによってパフォーマンスが向上します。

いずれにしてもすべてのベクトルが考慮されるため、結果の品質には影響しません。興味のない結果を事前にフィルタリングするだけで、操作の数を減らすことができます。

これは非常に重要です。適用したフィルターによって少数のドキュメントが生成される場合、近似検索ではなく正確な検索を実行するとパフォーマンスが向上する可能性があるためです。

経験則としては、フィルターを通過するドキュメントが 10,000 個未満の場合は完全一致検索を使用します。BBQインデックスは比較が非常に高速なので、ベース インデックスが 10 万未満の場合は、完全一致検索を使用するのが合理的です。詳細については、このブログ投稿をご覧ください。

フィルターが常に非常に制限的である場合は、HNSW ベースのインデックス タイプではなくflatインデックス タイプを使用して、近似検索ではなく完全検索に重点を置いたインデックス作成を検討してください。詳細については、 index_options のプロパティを参照してください。

近似ベクトル検索のためのフィルタリング

近似ベクトル検索を実行する場合、結果の精度とパフォーマンスをトレードオフします。HNSW のようなベクトル検索データ構造は、数百万のベクトルのおおよその最近傍を効率的に検索します。計算コストのかかるベクトル比較を最小限に抑えて、最も類似したベクトルを取得することに重点を置いています。

つまり、他のフィルタリング属性はベクター データの一部ではないということです。さまざまなデータ タイプには、用語辞書、投稿リスト、ドキュメント値など、検索やフィルタリングに効率的な独自のインデックス構造があります。

これらのデータ構造はベクトル検索メカニズムとは別であるため、ベクトル検索にフィルタリングをどのように適用すればよいでしょうか?フィルターには、ベクター検索の後にフィルターを適用する (ポストフィルタリング) か、ベクター検索の前にフィルターを適用する (プレフィルタリング) という 2 つのオプションがあります。

それぞれの選択肢には長所と短所があります。詳しく見ていきましょう！

ポストフィルタリング

ポストフィルタリングは、ベクトル検索が完了した後にフィルターを適用します。これは、最も類似した上位 k 個のベクトル結果が見つかった後にフィルターが適用されることを意味します。

明らかに、結果にフィルターを適用した後、 k 件未満の結果が返される可能性があります。もちろん、ベクトル検索 (より高い k 値) からより多くの結果を取得できますが、フィルターを適用した後に k 以上の結果が得られるかどうかはわかりません。

ポストフィルタリングの利点は、ベクトル検索の実行時の動作を変更しないことです。つまり、ベクトル検索はフィルタリングを認識しません。ただし、取得される結果の最終的な数は変わります。

以下は、 knn クエリを使用したポストフィルタリングの例です。フィルタリング句が knn クエリとは別であることを確認します。

post-filterを使用した knn 検索では、ポストフィルタリングも利用できます。

knn 検索では明示的なポストフィルター セクションを使用する必要があることに注意してください。ポストフィルターを使用しない場合、knn 検索はポストフィルターを実行する代わりに、最近傍の結果を他のクエリまたはフィルターと組み合わせます。

プレフィルタリング

ベクトル検索の前にフィルターを適用すると、まずフィルターを満たすドキュメントが取得され、次にその情報がベクトル検索に渡されます。

Lucene はBitSetsを使用して、フィルター条件を満たすドキュメントを効率的に保存します。次に、ベクトル検索は条件を満たすドキュメントを考慮して、HNSW グラフを走査します。候補を結果に追加する前に、それが有効なドキュメントの BitSet に含まれているかどうかを確認します。

ただし、有効なドキュメントでない場合でも、候補を調査してクエリと比較する必要があります。HNSW の有効性は、グラフ内のベクトル間の接続に依存します。つまり、候補の探索を停止すると、その近傍もスキップされる可能性があることを意味します。

ガソリンスタンドに行くために車を運転するのを想像してください。ガソリンスタンドのない道路を無視すると、目的地にたどり着く可能性は低くなります。他の道はあなたにとって必要なものではないかもしれませんが、目的地まであなたを繋いでくれます。HNSW グラフ上のベクトルも同様です。

したがって、プレフィルタリングを適用すると、フィルタを適用しない場合よりもパフォーマンスが低下します。検索で訪れるすべてのベクトルに対して作業を実行し、フィルターに一致しないベクトルを破棄する必要があります。私たちは、トップ k の結果を得るために、より多くの作業とより多くの時間をかけています。

以下は、Elasticsearch クエリ DSL での事前フィルタリングの例です。フィルタリング句が knn セクションの一部になっていることを確認します。

事前フィルタリングは、 knn 検索とknn クエリの両方で利用できます。

プレフィルタリングの最適化

プレフィルタリングのパフォーマンスを確保するために適用できる最適化がいくつかあります。

フィルターの制限が厳しい場合は、完全一致検索に切り替えることができます。比較するベクトルが少ない場合は、フィルターを満たす少数のドキュメントに対して正確な検索を実行する方が高速です。

これは、 Luceneおよび Elasticsearch で自動的に適用される最適化です。

別の最適化方法では、フィルターの条件を満たさないベクトルを無視します。代わりに、このメソッドは、フィルターを通過するフィルター処理されたベクトルの近傍をチェックします。このアプローチでは、フィルタリングされたベクトルは考慮されず、現在のパスに接続されたベクトルの探索が継続されるため、比較の回数が効果的に削減されます。

このアルゴリズムは ACORN-1 であり、そのプロセスについてはこちらのブログ記事で詳しく説明されています。

ドキュメントレベルのセキュリティを使用したフィルタリング

ドキュメント レベル セキュリティ (DLS)は、ユーザー ロールが取得できるドキュメントを指定する Elasticsearch 機能です。

DLS はクエリを使用して実行されます。ロールにはインデックスに関連付けられたクエリを持たせることができ、これにより、そのロールに属するユーザーがインデックスから取得できるドキュメントを効果的に制限できます。

ロール クエリは、それに一致するドキュメントを取得するためのフィルターとして使用され、BitSet としてキャッシュされます。この BitSet は、基盤となる Lucene リーダーをラップするために使用されるため、クエリから返されたドキュメントのみがライブであると見なされます。つまり、それらのドキュメントはインデックス上に存在し、削除されていません。

knn クエリを実行するためにリーダーからライブ ドキュメントが取得されるため、ユーザーが利用できるドキュメントのみが考慮されます。プレフィルターがある場合は、DLS ドキュメントがそれに追加されます。

つまり、DLS フィルタリングは、近似ベクトル検索のプレフィルタとして機能し、同じパフォーマンスへの影響と最適化を実現します。

完全一致検索を使用した DLS には、任意のフィルターを適用する場合と同じ利点があります。つまり、DLS から取得されるドキュメントが少ないほど、完全一致検索のパフォーマンスが向上します。DLS によって返されるドキュメントの数も考慮してください。DLS ロールの制限が非常に厳しい場合は、近似検索ではなく完全検索の使用を検討してください。

ベンチマーク

Elasticsearch では、ベクトル検索フィルタリングが効率的であることを確認したいと考えています。当社には、さまざまなフィルタリングを使用して近似ベクトル検索を実行するベクトル フィルタリング用の特定のベンチマークがあり、ベクトル検索で関連する結果を可能な限り高速に取得し続けることができるようにします。

ACORN-1 が導入されたときの改善点を確認します。ベクトルの 2% のみがフィルターを通過するテストでは、クエリの待機時間は元の期間の 55% に短縮されます。

まとめ

フィルタリングは検索の不可欠な部分です。ベクトル検索でフィルタリングのパフォーマンスを確保し、トレードオフと最適化を理解することが、効率的で正確な検索の成否を左右します。

フィルタリングはベクトル検索のパフォーマンスに影響します。

• フィルタリングを使用すると、正確な検索が高速になります。フィルタリングが十分に制限されている場合は、近似検索ではなく完全検索の使用を検討する必要があります。これは Elasticsearch での自動最適化です。

• 事前フィルタリングを使用すると近似検索が遅くなります。事前フィルタリングを使用すると、検索速度は遅くなりますが、フィルターに一致する上位 k 件の結果を取得できます。

• ポストフィルタリングでは、フィルターの適用時にフィルターによってフィルタリングされる可能性があるため、必ずしも上位 k 件の結果が取得されるわけではありません。

フィルタリングをお楽しみください！

この記事では、これらのフィールド タイプ、それぞれのフィールド タイプをいつ使用するか、インデックス作成時とクエリ時の両方で埋め込み生成と使用戦略にどのように関連するかについて説明します。

密ベクトル型

Elasticsearch のdense_vectorフィールド タイプは、ほぼすべての次元が関連する、テキスト、画像、音声などのデータの数値表現である密なベクトルを格納するために使用されます。これらのベクトルは、OpenAI、Cohere、Hugging Face などのプラットフォームによって提供される埋め込みモデルを使用して生成され、他のドキュメントと正確な用語を共有していない場合でも、データの全体的な意味をキャプチャするように設計されています。

Elasticsearch では、使用されるモデルに応じて、密なベクトルは最大 4096 次元を持つことができます。たとえば、all-MiniLM-L6-v2 モデルは 384 次元のベクトルを生成しますが、OpenAI の text-embedding-ada-002 は 1536 次元のベクトルを生成します。

dense_vectorフィールドは、事前に生成されたベクトルの使用、カスタム類似度関数の適用、外部モデルとの統合など、より高度な制御が必要な場合に、この種の埋め込みを格納するためのデフォルトのタイプとして一般的に採用されています。

dense_vector 型をいつ、なぜ使用するのでしょうか?

高密度ベクトルは、文、段落、またはドキュメント全体の間の意味的な類似性を捉えるのに最適です。同じ用語を共有していなくても、テキストの全体的な意味を比較することが目的の場合、非常に効果的です。

密ベクトル フィールドは、OpenAI、Cohere、Hugging Face などのプラットフォームによって提供されるモデルを使用した外部埋め込み生成パイプラインが既にあり、これらのベクトルを手動で保存およびクエリするだけの場合に最適です。このタイプのフィールドは、埋め込みモデルとの高い互換性と、生成およびクエリの完全な柔軟性を提供し、検索中にベクトルがどのように生成、インデックス付け、使用されるかを制御できます。

さらに、ランキングロジックを調整する必要がある場合には、k-NN や script_score などのクエリを使用して、さまざまな形式のセマンティック検索をサポートします。これらの可能性により、高密度ベクトルは、RAG (検索拡張生成)、推奨システム、類似性に基づくパーソナライズされた検索などのアプリケーションに最適です。

最後に、このフィールドでは、 cosineSimilarity 、 dotProduct 、 l2normなどの関数を使用して関連性ロジックをカスタマイズし、ユースケースのニーズに応じてランキングを調整できます。

柔軟性、カスタマイズ性、および上記のような高度なユースケースとの互換性を必要とする人にとって、高密度ベクターは依然として最適なオプションです。

密ベクター型のクエリを使用するにはどうすればいいですか?

dense_vectorとして定義されたフィールドの検索では、k 近傍クエリが使用されます。このクエリは、密なベクトルがクエリ ベクトルに最も近いドキュメントを見つける役割を果たします。以下は、密なベクトル フィールドに k-NN クエリを適用する方法の例です。

k-NN クエリに加えて、ドキュメントのスコアリングをカスタマイズする必要がある場合は、script_score クエリを使用して、 cosineSimilarity、dotProduct、l2normなどのベクトル比較関数と組み合わせて、より制御された方法で関連性を計算することもできます。例を参照してください:

さらに詳しく知りたい場合は、 「Elasticsearch でベクトル検索を設定する方法」の記事を参照することをお勧めします。

スパースベクトル型

sparse_vectorフィールド タイプは、ほとんどの値がゼロで、少数の項のみに重要な重みがある数値表現であるスパース ベクトルを格納するために使用されます。このタイプのベクトルは、SPLADE や ELSER (Elastic Learned Sparse EncodeR) などの用語ベースのモデルで一般的です。

スパースベクトル型をいつ、なぜ使用するのでしょうか?

スパースベクトルは、意味的インテリジェンスを犠牲にすることなく、語彙的により正確な検索が必要な場合に最適です。テキストをトークン/値のペアとして表現し、関連する重みを持つ最も関連性の高い用語のみを強調表示することで、明確さ、制御性、効率性を実現します。

このタイプのフィールドは、テキスト内の相対的な重要度に基づいて各トークンに異なる重みを割り当てる ELSER モデルや SPLADE モデルなどの用語に基づいてベクトルを生成する場合に特に役立ちます。

クエリ内の特定の単語の影響を制御したい場合には、スパースベクター型を使用すると、用語の重みを手動で調整して、結果のランキングを最適化できます。

主な利点としては、ドキュメントが関連性があると判断された理由を明確に理解できるため検索の透明性が高く、また、すべての次元を保存する密なベクトルとは異なり、ゼロ以外の値を持つトークンのみが保存されるためストレージ効率が高くなる点が挙げられます。

さらに、スパース ベクトルはハイブリッド検索戦略の理想的な補完であり、稠密ベクトルと組み合わせて語彙の精度と意味の理解を組み合わせることもできます。

スパースベクトル型のクエリを使用するにはどうすればいいですか?

sparse_vectorクエリを使用すると、トークン/値形式のクエリ ベクトルに基づいてドキュメントを検索できます。以下のクエリの例を参照してください。

トレーニング済みのモデルを使用する場合は、クエリ テキストをスパース ベクトルに自動的に変換する推論エンドポイントを使用できます。

このトピックをさらに詳しく調べるには、 「トレーニング済み ML モデルによるスパース ベクトル埋め込みの理解」を読むことをお勧めします。

セマンティックテキストタイプ

semantic_textフィールド タイプは、Elasticsearch でセマンティック検索を使用する最もシンプルで簡単な方法です。推論エンドポイントを通じて、インデックス作成時とクエリ時の両方で埋め込み生成を自動的に処理します。つまり、ベクトルを手動で生成したり保存したりする手間がかかりません。

セマンティックテキストはいつ、なぜ使用するのでしょうか?

semantic_textフィールドは、最小限の技術的労力で、ベクトルを手動で処理することなく開始したい場合に最適です。このフィールドは、埋め込み生成やベクトル検索マッピングなどの手順を自動化し、セットアップをより速く便利にします。

シンプルさと抽象化を重視する場合は、マッピング、埋め込み生成、および取り込みパイプラインを手動で構成する複雑さが排除されるため、 semantic_text使用を検討する必要があります。推論モデルを選択するだけで、残りの作業は Elasticsearch が処理します。

主な利点としては、インデックス作成とクエリの両方で実行される自動埋め込み生成と、選択した推論モデルをサポートするように事前構成された、すぐに使用できるマッピングが挙げられます。

さらに、このフィールドは長いテキストの自動分割 (テキスト チャンク) をネイティブにサポートしており、大きなテキストをそれぞれ独自の埋め込みを持つ小さな段落に分割できるため、検索の精度が向上します。これにより、特にセマンティック検索の基礎となるエンジニアリングを扱うことなく価値を迅速に提供したいチームにとって、生産性が大幅に向上します。

ただし、 semantic_textスピードとシンプルさを提供しますが、このアプローチにはいくつかの制限があります。Elasticsearch の推論エンドポイントとして利用できる限り、市場標準モデルの使用が可能になります。ただし、 dense_vectorフィールドの場合のように、外部で生成された埋め込みはサポートされません。

ベクトルの生成方法をより細かく制御する必要がある場合、独自の埋め込みを使用する場合、または高度な戦略のために複数のフィールドを組み合わせる必要がある場合は、 dense_vectorフィールドとsparse_vectorフィールドによって、よりカスタマイズされたシナリオやドメイン固有のシナリオに必要な柔軟性が得られます。

セマンティックテキストタイプのクエリの使用方法

semantic_textより前は、埋め込みの種類 (密または疎) に応じて異なるクエリを使用する必要がありました。スパースフィールドにはsparse_vectorクエリが使用されましたが、 dense_vectorフィールドには KNN クエリが必要でした。

セマンティック テキスト タイプでは、セマンティック クエリを使用して検索が実行されます。セマンティック クエリは、クエリ ベクトルを自動的に生成し、それをインデックス付けされたドキュメントの埋め込みと比較します。semantic_textタイプでは、クエリを埋め込むための推論エンドポイントを定義できますが、何も指定されていない場合は、インデックス作成時に使用されたのと同じエンドポイントがクエリに適用されます。

詳細については、 「Elasticsearch の新しい semantic_text マッピング: セマンティック検索の簡素化」という記事を読むことをお勧めします。

まとめ

Elasticsearch で埋め込みをマッピングする方法を選択するときは、ベクトルを生成する方法とベクトルに対して必要な制御レベルを理解することが重要です。シンプルさを求める場合、セマンティック テキスト フィールドを使用すると、自動かつスケーラブルなセマンティック検索が可能になり、多くの初期使用ケースに最適です。より高度な制御、微調整されたパフォーマンス、またはカスタム モデルとの統合が必要な場合は、密ベクトル フィールドと疎ベクトル フィールドが必要な柔軟性を提供します。

理想的なフィールド タイプは、ユース ケース、利用可能なインフラストラクチャ、機械学習スタックの成熟度によって異なります。最も重要なのは、Elastic が最新の、適応性に優れた検索システムを構築するためのツールを提供していることです。

参照資料

• セマンティックテキストフィールドタイプ

• スパースベクトル場型

• 密ベクトル場型

• セマンティッククエリ

• スパースベクトルクエリ

• kNN検索

• Elasticsearchの新しいsemantic_textマッピング：セマンティック検索の簡素化

• 学習済み ML モデルによるスパースベクトル埋め込みの理解

この記事で説明したすべての完全なクエリと出力は、Elasticsearch Labs コード リポジトリで確認できます。

ユースケースで Better Binary Quantization (BBQ) を実装する理由は何ですか?

数学は興味深いものですが、ベクトル検索がなぜ正確であり続けるのかを完全に理解したい場合には重要です。結局のところ、現在のベクトル検索アルゴリズムではデータの読み取り速度によって制限されることが判明しているため、これはすべて圧縮に関することです。したがって、そのデータすべてをメモリに収めることができれば、ストレージから読み取る場合と比べて速度が大幅に向上します (メモリは SSD よりも約 200 倍高速です)。

いくつか留意すべき点があります:

• HNSW (Hierarchical Navigable Small World) などのグラフベースのインデックスは、ベクター検索では最も高速です。

  • HNSW: 効率的な高次元類似性検索を可能にする多層グラフ構造を構築する近似最近傍検索アルゴリズム。

• HNSW の速度は、基本的にメモリ、または最悪の場合、ストレージからのデータ読み取り速度によって制限されます。

  • 理想的には、保存されているすべてのベクトルをメモリにロードできるようにする必要があります。

• 埋め込みモデルは通常、浮動小数点数ごとに 4 バイトの float32 精度のベクトルを生成します。

• そして最後に、ベクトルや次元の数によっては、すべてのベクトルを保存するためのメモリがすぐに不足する可能性があります。

これを当然のこととして考えると、それぞれが数百、数千の次元を持つ可能性のある数百万、数十億のベクトルを取り込み始めると、すぐに問題が発生することがわかります。「圧縮率のおおよその数値」というセクションでは、おおよその数値が示されています。

始めるには何が必要ですか?

始めるには、次のものが必要です。

• Elastic Cloud またはオンプレミスを使用している場合は、Elasticsearch のバージョン 8.18 以降が必要になります。BBQ は 8.16 で導入されましたが、この記事では 8.18 で導入されたvector_rescore使用します。

• さらに、クラスター内に機械学習 (ML) ノードがあることも確認する必要があります。(注: モデルをロードするには最低 4 GB の ML ノードが必要ですが、完全な本番環境のワークロードには、はるかに大きなノードが必要になる可能性があります。)

• Serverless を使用している場合は、ベクターに最適化されたインスタンスを選択する必要があります。

• また、ベクター データベースに関する基本的な知識も必要になります。Elastic のベクトル検索の概念にまだ慣れていない場合は、まず次のリソースを確認することをお勧めします。

  • 弾性ベクトルデータベースのナビゲート

  • 検索拡張生成の背後にある大きなアイデア

より良いバイナリ量子化（BBQ）実装

このブログをシンプルに保つために、組み込み関数が利用可能な場合はそれを使用します。この場合、機械学習ノード上の Elasticsearch 内で直接実行される.multilingual-e5-smallベクトル埋め込みモデルがあります。text_embeddingモデルを、任意の埋め込みツール ( OpenAI 、 Google AI Studio 、 Cohereなど) に置き換えることができることに注意してください。希望するモデルがまだ統合されていない場合は、独自の密なベクトル埋め込みも使用できます。

まず、特定のテキストのベクトルを生成するための推論エンドポイントを作成する必要があります。これらのコマンドはすべて、Kibana Dev Tools コンソールから実行します。このコマンドは.multilingual-e5-smallをダウンロードします。まだ存在しない場合はエンドポイントが設定されます。実行には 1 分ほどかかる場合があります。予想される出力は、Outputs フォルダー内のファイル01-create-an-inference-endpoint-output.jsonで確認できます。

これが返されると、モデルが設定され、次のコマンドを使用してモデルが期待どおりに動作するかどうかをテストできます。期待される出力は、Outputs フォルダー内のファイル02-embed-text-output.jsonで確認できます。

トレーニング済みのモデルがどのノードにも割り当てられないという問題が発生した場合は、モデルを手動で起動する必要がある場合があります。

ここで、埋め込みモデルからの出力と一致するように、標準テキスト フィールド ( my_field ) と 384 次元の密なベクトル フィールド ( my_vector ) の 2 つのプロパティを持つ新しいマッピングを作成しましょう。index_options.type to bbq_hnswもオーバーライドします。予想される出力は、Outputs フォルダー内のファイル03-create-byte-qauntized-index-output.jsonで確認できます。

Elasticsearch がベクトルを生成するようにするには、 Ingest Pipelineを利用できます。このパイプラインには、エンドポイント ( model_id )、ベクトルを作成するinput_field 、およびそれらのベクトルを格納するoutput_fieldの 3 つが必要です。以下の最初のコマンドは、内部で推論サービスを使用する推論取り込みパイプラインを作成し、2 番目のコマンドはパイプラインが正しく動作していることをテストします。予想される出力は、Outputs フォルダー内のファイル04-create-and-simulate-ingest-pipeline-output.jsonで確認できます。

これで、以下の最初の 2 つのコマンドを使用してドキュメントを追加し、3 番目のコマンドで検索が機能することをテストする準備が整いました。予想される出力は、Outputs フォルダー内のファイル05-bbq-index-output.jsonで確認できます。

この投稿で推奨されているように、圧縮の利点を活用しながら高い再現精度を維持するのに役立つため、大量のデータに拡張する場合は、再スコアリングとオーバーサンプリングが推奨されます。Elasticsearch バージョン 8.18 以降では、 rescore_vectorを使用してこの方法で実行できます。予想される出力は、Outputs フォルダー内のファイル06-bbq-search-8-18-output.jsonにあります。

これらのスコアは、生データで得られるスコアと比べてどうでしょうか?上記のすべてをindex_options.type: hnswを使ってもう一度実行すると、スコアが非常に似ていることがわかります。予想される出力は、Outputs フォルダーのファイル07-raw-vector-output.jsonで確認できます。

圧縮比のおおよその数値

ベクトル検索を使用する場合、ストレージとメモリの要件がすぐに大きな課題になる可能性があります。次の内訳は、さまざまな量子化手法によってベクター データのメモリ フットプリントがいかに劇的に削減されるかを示しています。

ベクトル（V）

寸法（D）

生（V x D x 4）

int8 (V x (D x 1 + 4))

int4 (V x (D x 0.5 + 4))

バーベキュー（V×（D×0.125+4））

10,000,000

384

14.31GB

3.61GB

1.83GB

0.58GB

50,000,000

384

71.53GB

18.07GB

9.13GB

2.89GB

1億

384

143.05GB

36.14GB

18.25GB

5.77GB

まとめ

BBQ は、精度を犠牲にすることなくベクター データを圧縮するために適用できる最適化です。これはベクトルをビットに変換することで機能し、データを効果的に検索できるようにし、AI ワークフローを拡張して検索を高速化し、データ ストレージを最適化できるようにします。

さらなる学習

バーベキューについてさらに詳しく知りたい場合は、次のリソースをぜひチェックしてください。

• LuceneとElasticsearchにおけるバイナリ量子化（BBQ）

• より良いバイナリ量子化（BBQ）と積量子化

• 最適化されたスカラー量子化：さらに優れたバイナリ量子化

• より良いバイナリ量子化（BBQ）：バイトからBBQへ、より良いベクトル検索の秘密 by Ben Trent

バイナリ量子化対決

高次元ベクトルを元の形式で保存すると、メモリを大量に消費する可能性があります。量子化技術はこれらのベクトルをコンパクトな表現に圧縮し、メモリフットプリントを大幅に削減します。その後、検索は圧縮された空間で実行されるため、計算の複雑さが軽減され、特に大規模なデータセットでは検索が高速化されます。

Elastic は、Lucene を最高のパフォーマンスを発揮するベクター エンジンにすることに注力しています。Elasticsearch 8.16 では Lucene をベースにBetter Binary Quantization (BBQ) を導入し、8.18 および 9.0 でさらに進化させました。BBQ は、float32 次元をビットに削減するスカラー量子化の新しいアプローチに基づいて構築されており、高いランキング品質を維持しながら約 95% のメモリ削減を実現します。

一方、OpenSearch は、nmslib (現在は非推奨)、Lucene、FAISS といった複数のベクター エンジンを使用します。以前のブログでは、ベクトル検索について Elasticsearch と OpenSearch を比較しました。3 つの異なるデータセットを使用し、両方の製品でさまざまなエンジンと構成の組み合わせをテストしました。

このブログでは、現在両方の製品で利用可能なバイナリ量子化アルゴリズムに焦点を当てています。openai_vector Rally トラックを使用して、Elasticsearch と BBQ および OpenSearch と FAISS のバイナリ量子化を テストしました。

主な目的は、同じレベルの再現率で両方のソリューションのパフォーマンスを評価することでした。リコールとはどういう意味ですか?リコールは、検索システムによって関連結果がどれだけ正常に取得されたかを測定する指標です。

この評価では、recall@k が特に重要です。ここで、 k は検討される上位の結果の数を表します。したがって、 Recall@10 、 Recall@50、および Recall@100 は、それぞれ上位 10、50、および 100 件の取得された項目内に表示される実際の関連結果の数を測定します。再現率は 0 ～ 1 (または 0% ～ 100% の精度) のスケールで表されます。これは重要なことです。なぜなら、ここでは再現率が常に 1 (100%) となる正確な KNN ではなく、近似 KNN (ANN) について話しているためです。

kの各値に対して、最終的なランキングを適用する前に考慮される候補の数であるnも指定しました。つまり、Recall@10、Recall@50、および Recall@100 の場合、システムは最初にバイナリ量子化アルゴリズムを使用してn個の候補を取得し、次にそれらをランク付けして、上位k 個の結果に期待される関連項目が含まれているかどうかを判断します。

n を制御することで、効率と精度のトレードオフを分析できます。通常、 nが大きいほど、ランキングに使用できる候補が増えるためリコールは増加しますが、レイテンシも増加し、スループットは低下します。逆に、 nを小さくすると検索速度は上がりますが、初期セットに含まれる関連候補が少なすぎるとリコール率が低下する可能性があります。

この比較では、Elasticsearch は同一の設定で OpenSearch よりも低いレイテンシと高いスループットを示しました。

方法論

完全な構成、Terraform スクリプト、Kubernetes マニフェスト、および特定の Rally トラックは、このリポジトリのopenai_vector_bqで入手できます。

以前のベンチマークと同様に、次のもので構成される Kubernetes クラスターを使用しました。

• Elasticsearch 9.0 用の 1 つのノードプール（3 台のe2-standard-32マシン、128 GB の RAM、32 個の CPU）

• OpenSearch 2.19 用の 1 つのノード プール (3 台のe2-standard-32マシン (128 GB RAM、32 個の CPU))

• Rally 用の 1 つのノードプール（2 台のe2-standard-4マシン、16 GB の RAM と 4 つの CPU）

Elasticsearch クラスター バージョン 9.0 を 1 つと OpenSearch クラスター バージョン 2.19 を 1 つセットアップしました。

Elasticsearch と OpenSearch は両方ともまったく同じ設定でテストされました。 つまり、OpenAI の text-embedding-ada-002 モデルを使用して生成された埋め込みが強化された NQ データ セットからの 250 万のドキュメントを使用する、いくつかの変更 を 加え た openai_vector Rally トラック を使用しました。

結果には、8 つの同時クライアントを使用して検索操作を実行し、さまざまなリコール レベル (recall@10、recall@50、recall@100) で測定されたレイテンシとスループットが報告されています。単一のシャードを使用し、レプリカは使用しませんでした。

我々は以下のkn-rescoreの組み合わせを実行した。10-2000-2000、またはk:10 、 n:2000 、 rescore:2000 は、2000 件の結果に対して再スコアを適用して、n 件の候補 (2000) のうち上位 k 件 (10) を取得します (これは「オーバーサンプル係数」が 1 の場合に相当します)。各検索はウォームアップとして 1,000 回実行され、10,000 回実行されました。

リコール@10

• 10-40-40

• 10-50-50

• 10-100-100

• 10-200-200

• 10-500-500

• 10-750-750

• 10-1000-1000

• 10-1500-1500

• 2000年10月

リコール@50

• 50-150-150

• 50-200-200

• 50-250-250

• 50-500-500

• 50-750-750

• 50-1000-1000

• 50-1200-1200

• 50-1500-1500

• 50-2000-2000

リコール@100

• 100-200-200

• 100-250-250

• 100-300-300

• 100-500-500

• 100-750-750

• 100-1000-1000

• 100-1200-1200

• 100-1500-1500

• 100-2000-2000

ベンチマークを再現するために、rally-elasticsearch と rally-opensearch の両方の Kubernetes マニフェストには、関連するすべての変数が ConfigMap で外部化されており、こちら(ES) とこちら(OS) から入手できます。search_opsパラメータは、k、n、rescore の任意の組み合わせをテストするようにカスタマイズできます。

OpenSearch Rallyの設定

/k8s/rally-openai_vector-os-bq.yml

Opensearchインデックス設定

ConfigMap の変数はインデックス構成で使用され、一部のパラメータは変更されません。OpenSearch における 1 ビット量子化は、圧縮レベルを「32x」に設定することによって設定されます。

index-vectors-only-mapping-with-docid-mapping.json

Elasticsearch Rallyの設定

/k8s/rally-openai_vector-es-bq.yml

Elasticsearchインデックス設定

index-vectors-only-mapping-with-docid-mapping.json

成果

結果を解釈する方法は複数あります。レイテンシとスループットの両方について、リコールの各レベルで簡略化されたグラフと詳細なグラフをプロットしました。各指標について「高いほど良い」と考えると、違いが簡単にわかります。ただし、レイテンシはマイナス（低い方が実際には良い）であり、スループットはプラスです。簡略化されたグラフでは、 (リコール / レイテンシ) * 10000 (単に「速度」と呼びます) とリコール * スループットを使用しました。したがって、両方のメトリックは、速度とスループットが高いほど優れていることを意味します。始めましょう。

10回想 - 簡略化

この再現レベルでは、Elasticsearch BBQ は OpenSearch FAISS よりも最大5 倍高速(平均で 3.9 倍高速) で、平均で3.2 倍のスループットを実現します。

リコール@10 - 詳細

タスク

レイテンシ平均

スループット平均

平均再現率

Elasticsearch-9.0-BBQ

10-100-100

11.70

513.58

0.89

Elasticsearch-9.0-BBQ

10-1000-100

27.33

250.55

0.95

Elasticsearch-9.0-BBQ

10-1500-1500

35.93

197.26

0.95

Elasticsearch-9.0-BBQ

10-200-200

13.33

456.16

0.92

Elasticsearch-9.0-BBQ

2000年10月

44.27

161.40

0.95

Elasticsearch-9.0-BBQ

10-40-40

10.97

539.94

0.84

Elasticsearch-9.0-BBQ

10-50-50

11時00分

535.73

0.85

Elasticsearch-9.0-BBQ

10-500-500

19.52

341.45

0.93

Elasticsearch-9.0-BBQ

10-750-750

22.94

295.19

0.94

OpenSearch-2.19-faiss

10-100-100

35.59

200.61

0.94

OpenSearch-2.19-faiss

10-1000-1000

156.81

58.30

0.96

OpenSearch-2.19-faiss

10-1500-1500

181.79

42.97

0.96

OpenSearch-2.19-faiss

10-200-200

47.91

155.16

0.95

OpenSearch-2.19-faiss

2000年10月

232.14

31.84

0.96

OpenSearch-2.19-faiss

10-40-40

27.55

249.25

0.92

OpenSearch-2.19-faiss

10-50-50

28.78

245.14

0.92

OpenSearch-2.19-faiss

10-500-500

79.44

97.06

0.96

OpenSearch-2.19-faiss

10-750-750

104.19

75.49

0.96

50歳の思い出 - 簡略化

この再現率では、Elasticsearch BBQは最大5倍（平均4.2倍）高速で、平均3.9倍のスループットを実現しています。OpenSearch FAISSよりも。

詳細な結果 - 50 回のリコール

タスク

レイテンシ平均

スループット平均

平均再現率

Elasticsearch-9.0-BBQ

50-1000-1000

25.71

246.44

0.95

Elasticsearch-9.0-BBQ

50-1200-1200

28.81

227.85

0.95

Elasticsearch-9.0-BBQ

50-150-150

13.43

362.90

0.90

Elasticsearch-9.0-BBQ

50-1500-1500

33.38

202.37

0.95

Elasticsearch-9.0-BBQ

50-200-200

12.99

406.30

0.91

Elasticsearch-9.0-BBQ

50-2000-2000

42.63

163.68

0.95

Elasticsearch-9.0-BBQ

50-250-250

14.41

373.21

0.92

Elasticsearch-9.0-BBQ

50-500-500

17.15

341.04

0.93

Elasticsearch-9.0-BBQ

50-750-750

31.25

248.60

0.94

OpenSearch-2.19-faiss

50-1000-1000

125.35

62.53

0.96

OpenSearch-2.19-faiss

50-1200-1200

143.87

54.75

0.96

OpenSearch-2.19-faiss

50-150-150

43.64

130.01

0.89

OpenSearch-2.19-faiss

50-1500-1500

169.45

46.35

0.96

OpenSearch-2.19-faiss

50-200-200

48.05

156.07

0.91

OpenSearch-2.19-faiss

50-2000-2000

216.73

36.38

0.96

OpenSearch-2.19-faiss

50-250-250

53.52

142.44

0.93

OpenSearch-2.19-faiss

50-500-500

78.98

97.82

0.95

OpenSearch-2.19-faiss

50-750-750

103.20

75.86

0.96

リコール@100

この再現レベルでは、Elasticsearch BBQ は OpenSearch FAISS よりも最大 5 倍高速(平均 4.6 倍高速) で、平均で3.9 倍のスループットを実現します。

詳細な結果 - 再現率 100

タスク

レイテンシ平均

スループット平均

平均再現率

Elasticsearch-9.0-BBQ

100-1000-1000

27.82

243.22

0.95

Elasticsearch-9.0-BBQ

100-1200-1200

31.14

224.04

0.95

Elasticsearch-9.0-BBQ

100-1500-1500

35.98

193.99

0.95

Elasticsearch-9.0-BBQ

100-200-200

14.18

403.86

0.88

Elasticsearch-9.0-BBQ

100-2000-2000

45.36

159.88

0.95

Elasticsearch-9.0-BBQ

100-250-250

14.77

433.06

0.90

Elasticsearch-9.0-BBQ

100-300-300

14.61

375.54

0.91

Elasticsearch-9.0-BBQ

100-500-500

18.88

340.37

0.93

Elasticsearch-9.0-BBQ

100-750-750

23.59

285.79

0.94

OpenSearch-2.19-faiss

100-1000-1000

142.90

58.48

0.95

OpenSearch-2.19-faiss

100-1200-1200

153.03

51.04

0.95

OpenSearch-2.19-faiss

100-1500-1500

181.79

43.20

0.96

OpenSearch-2.19-faiss

100-200-200

50.94

131.62

0.83

OpenSearch-2.19-faiss

100-2000-2000

232.53

33.67

0.96

OpenSearch-2.19-faiss

100-250-250

57.08

131.23

0.87

OpenSearch-2.19-faiss

100-300-300

62.76

120.10

0.89

OpenSearch-2.19-faiss

100-500-500

84.36

91.54

0.93

OpenSearch-2.19-faiss

100-750-750

111.33

69.95

0.94

バーベキューの改良

BBQ は最初のリリース以来長い道のりを歩んできました。Elasticsearch 8.16 では、比較のために、8.16 のベンチマーク実行を現在のものと並べて含めており、それ以降、リコールとレイテンシーがどのように改善されたかを確認できます。

Elasticsearch 8.18 および 9.0 では、ベクトルを量子化するためのコア アルゴリズムを書き直しました。つまり、8.16 の BBQ は良かったのですが、最新バージョンはさらに良くなっています。それについてはこことここで読むことができます。つまり、すべてのベクトルは、最適化されたスカラー分位数を通じて個別に量子化されます。その結果、ユーザーはパフォーマンスを犠牲にすることなくベクトル検索の精度向上の恩恵を受けることができ、Elasticsearch のベクトル検索はさらに強力になります。

まとめ

Elasticsearch BBQ と OpenSearch FAISS のパフォーマンス比較では、Elasticsearch はベクトル検索において OpenSearch を大幅に上回り、さまざまなレベルのリコールで平均最大 5 倍のクエリ速度と 3.9 倍のスループットを達成しています。

主な調査結果は次のとおりです。

• Recall@10 : Elasticsearch BBQ は、OpenSearch FAISS と比較して最大 5 倍高速 (平均 3.9 倍高速) で、平均 3.2 倍のスループットを実現します。

• Recall@50 : Elasticsearch BBQ は、OpenSearch FAISS と比較して最大 5 倍高速 (平均で 4.2 倍高速) で、平均で 3.9 倍のスループットを実現します。

• Recall@100 : Elasticsearch BBQ は、OpenSearch FAISS と比較して最大 5 倍高速 (平均で 4.6 倍高速) で、平均で 3.9 倍のスループットを実現します。

これらの結果は、特に高次元ベクトル検索シナリオにおける Elasticsearch BBQ の効率性とパフォーマンスの利点を強調しています。Elasticsearch 8.16 で導入された Better Binary Quantization (BBQ) 技術は、高いランキング品質を維持しながらメモリを大幅に削減 (約 95%) するため、大規模なベクトル検索アプリケーションに最適です。

Elastic では、RAG (Retrieval Augmented Generation) を含む検索および取得ユースケースに最適なベクター データベースを提供するために、Apache Lucene と Elasticsearch を改良するための革新を絶えず続けています。最近の進歩によりパフォーマンスが劇的に向上し、Lucene 10 から得た成果を基にして、ベクター検索が以前よりも高速かつスペース効率が高くなりました。このブログは、その革新のもう一つの例です。

開発者は、統一されたジャーニー内で RAG アプリケーションを作成し、ローコードで柔軟な方法でプライベート データに基づいたチャット エクスペリエンスを実現できるようになりました。顧客や社内従業員向けの AI エージェントを構築する場合でも、ソフトウェア内で LLM 生成を活用する場合でも、Vertex AI プラットフォームでは、最小限の構成で Elasticsearch の関連性を簡単に利用できます。この統合により、本番環境のユースケースで Gemini モデルをより簡単に、より迅速に導入できるようになり、GenAI を PoC から実際のシナリオへと推進できます。

このブログでは、Elasticsearch を Google Cloud の Vertex AI プラットフォームと統合して、シームレスなデータグラウンディングと完全にカスタマイズ可能な GenAI アプリケーションの構築を実現する方法について説明します。どのようにするか見てみましょう。

Google Cloud の Vertex AI と Gemini モデルは Elasticsearch によってデータに基づいています

GenAI アプリケーションを作成するために Vertex AI サービスとツールを活用するユーザーは、新しい「Grounding」オプションにアクセスして、プライベート データを会話のやり取りに自動的に取り入れることができるようになりました。Elasticsearch は現在この機能の一部となっており、両方から使用できます。

• Vertex AI LLM API は、生成時に Google の Gemini モデルを直接強化します (推奨)。

• Grounded Generation API は、Vertex AI Agent Builder エコシステムでエージェント エクスペリエンスを構築する代わりに使用されます。

この統合により、最もダウンロードされ、導入されているベクターデータベースである Elasticsearch が、社内のエンド カスタマー対応チャットで必要な場所に適切なエンタープライズ データを提供します。これは、GenAI をビジネス プロセスに実際に導入する上で非常に重要です。

前述の API により、開発者はこの新しい提携機能をコードに採用できるようになります。ただし、迅速なエンジニアリングとテストは、アプリケーション開発において依然として重要なステップであり、初期の発見の場として機能します。これをサポートするために、Elasticsearch は Vertex AI Studio コンソール ツール内でユーザーが簡単に評価できるように設計されています。

以下に示すように、UI の「Grounding のカスタマイズ」タブ内で、必要なパラメータ (検索するインデックス、取得するドキュメントの数、必要な検索テンプレート) を使用して Elastic エンドポイントを構成するには、いくつかの簡単な手順を実行するだけです (これを機能させるには、UI と以下のコード例に「ApiKey」という単語を含む API キーを入力する必要があることに注意してください)。これで、プライベートな知識を使って生成する準備が整いました。

GenAIアプリケーションを簡単に本番環境に対応

Elastic と Google Cloud は、開発者中心で包括的かつ楽しいエクスペリエンスを提供するために連携しています。LLM と Grounding Generation API の両方で Elastic にネイティブに接続することで、Vertex AI 上で GAI アプリケーションを構築する際の複雑さとオーバーヘッドが軽減され、不要な追加 API やデータ オーケストレーションが回避され、1 回の統合呼び出しでグラウンディングが可能になります。

両方のシナリオでどのように機能するかを見てみましょう。

最初の例は LLM API を使用して実行されます。

上記の例では、Gemini 2.0 Flash へのコンテンツ生成を要求する API のretrievalフィールドを使用して、要求の検索エンジンをコンテキストに応じて設定できます。api_specを「ELASTIC_SEARCH」に設定すると、API キーやクラスターエンドポイント (Elastic クラスターへのリクエストをルーティングするために必要)、データを取得するインデックス、検索ロジックに使用する検索テンプレートなどの追加の構成パラメータが使用できるようになります。

同様に、Grounding Generation API を使用してgroundingSpecパラメータを設定することで、同じ結果を得ることができます。

どちらのアプローチでも、レスポンスには、クエリをサポートするために、Elasticsearch で見つかった最も関連性の高いプライベート ドキュメントと、関連する接続されたデータ ソースが含まれた回答が提供されます。

ただし、シンプルであることは、特定のニーズやユースケースを満たすためのパーソナライゼーションの欠如と混同しないでください。これを念頭に置いて、検索構成をシナリオに完全に適応させることができるように設計しました。

指先で完全にカスタマイズ可能な検索:検索テンプレート

検索シナリオを最大限にカスタマイズするために、Google Cloud と連携して、当社の有名な検索テンプレートをベースにしたエクスペリエンスを構築しました。Elasticsearch 検索テンプレートは、動的で再利用可能かつ保守可能な検索クエリを作成するための優れたツールです。クエリ構造を事前に定義して再利用することができます。これらは、開発時間を節約し、エラーの可能性を減らすため、異なるパラメータを使用して同様のクエリを実行する場合に特に役立ちます。テンプレートには変数のプレースホルダーを含めることができるため、クエリは動的になり、さまざまな検索要件に適応できるようになります。

Vertex AI API と Elasticsearch をグラウンディングに使用する場合は、上記のコード スニペットに示すように、検索ロジックが実装され Elasticsearch にプッシュダウンされる目的の検索テンプレートを参照する必要があります。Elastic のパワー ユーザーは、検索アプローチを非同期的に管理、構成、更新し、特定のインデックス、モデル、データに合わせてカスタマイズできます。その操作は、Vertex AI ユーザー、ウェブ アプリ開発者、AI エンジニアにとって完全に透過的な方法で実行でき、グラウンディング API でテンプレートの名前を指定するだけで済みます。

この設計により完全なカスタマイズが可能になり、Elasticsearch の広範な検索機能を Google Cloud AI 環境で利用できるようになり、モジュール性、透明性、そして Elastic に精通していない開発者にとっても使いやすさが確保されます。

BM25 検索、セマンティック検索、または 2 つの間のハイブリッド アプローチが必要なときはいつでも (リトリーバーをすでに調べましたか?)単一の検索 API 呼び出しで構成可能な検索テクニックを使用すれば、検索テンプレートでカスタム ロジックを定義でき、Vertex AI はそれを自動的に活用できます。

これは、ベクトルと結果を管理するために選択した埋め込みおよび再ランク付けモデルにも適用されます。ユースケースに応じて、Elastic の ML ノードでモデルをホストしたり、推論 API を介してサードパーティのサービスエンドポイントを使用したり、オンプレミスでローカルモデルを実行したりすることができます。これは検索テンプレートを介して実行可能であり、次のセクションでその仕組みを見ていきます。

参照テンプレートから始めて、独自のテンプレートを作成しましょう

すぐに使い始められるように、初期リファレンスとして使用できる互換性のある検索テンプレートのサンプル セットを用意しました。その後、それを基にしてカスタムの検索テンプレートを変更および構築できます。

• ELSER モデルによるセマンティック検索 (スパースベクトルとチャンキング)

• e5多言語モデルによるセマンティック検索（密ベクトルとチャンキング）

• Vertex AI テキスト埋め込みモデルを使用したハイブリッド検索

これらは、このGitHub リポジトリで見つけることができます。

1 つの例を見てみましょう。製品カタログに Google Cloud の Vertex AI API を使用して埋め込みを作成します。まず、以下に示すように Elasticsearch で検索テンプレートを作成する必要があります。

この例では、1 回の検索内で 2 つのフィールド ( title_embedding – 製品の名前を含むベクトル フィールド – とdescription_embedding – 製品の説明の表現を含むベクトル フィールド) に対して KNN 検索を実行します。

excludes構文を利用すると、LLM に不要なフィールドが返されることを回避できます。不要なフィールドが返されると、処理中にノイズが発生し、最終的な回答の品質に影響を及ぼす可能性があります。この例では、ベクターと画像の URL を含むフィールドを除外しました。

ベクトルは、以前は次のように定義されていた Vertex AI 埋め込み API googlevertexai_embeddings_004への推論エンドポイントを介して送信された入力に対して、クエリ時にオンザフライで作成されます。

Elastic の推論 API の使用方法に関する追加情報については、こちらをご覧ください。

これで、テンプレート検索をテストする準備が整いました。

paramsフィールドは、テンプレート スクリプトで二重中括弧内に設定した変数を置き換えます。現在、Vertex AI LLM および Grounded Generation API は、次の入力変数を Elastic に送信できます。

• 「クエリ」 - 検索対象となるユーザークエリ

• 「index_name」 - 検索するインデックスの名前

• 「num_hits」 - 最終出力で取得したいドキュメントの数

出力例は次のとおりです。

上記のクエリは、Google Cloud の Vertex AI が、以前に作成した検索テンプレートを参照するときに、バックグラウンドで Elasticsearch 上で実行するクエリとまったく同じです。Gemini モデルは、出力ドキュメントを使用して回答を根拠付けます。「乾式壁の補修には何が必要ですか?」と質問すると、一般的な提案ではなく、チャット エージェントが具体的な製品を提供します。

ElasticとGoogle CloudによるエンドツーエンドのGenAIジャーニー

Elastic は Google Cloud と提携して、本番環境対応のエンドツーエンドの GenAI エクスペリエンスとソリューションを作成します。先ほど見てきたように、Elastic は Vertex AI プラットフォームの UI と SDK に直接統合された最初の ISV であり、シームレスで基盤のある Gemini モデル プロンプトとエージェントが当社のベクトル検索機能を使用して実行できるようになります。さらに、Elastic はVertex AIおよびGoogle AI Studioの埋め込み、再ランク付け、補完モデルと統合し、Google Cloud 環境を離れることなくベクトルを作成およびランク付けして、責任ある AI の原則を保証します。マルチモーダルアプローチをサポートすることで、さまざまなデータ形式にわたるアプリケーションを共同で促進します。

Playgroundを介して GenAI 検索コードを調整、テスト、エクスポートできます。

しかし、検索アプリの構築だけではありません。ElasticはGeminiモデルを活用して、 Elastic AIアシスタント、攻撃検出、自動インポート機能などのIT運用を強化し、セキュリティアナリストやSREの低価値タスクによる日々の疲労を軽減し、ビジネスの改善に集中できるようにします。Elastic では、 Vertex AI の使用状況を包括的に監視し、応答時間、トークン、リソースなどのメトリックとログを追跡して、最適なパフォーマンスを確保することもできます。私たちは協力して、データの取り込みと埋め込み生成からハイブリッド検索によるグラウンディングまで、GenAI のライフサイクル全体を管理し、LLM を活用したアクションによって GenAI ツールの堅牢な観測性とセキュリティを確保します。

さらに詳しく調べて試してみてください!

これを試してみませんか？この機能は現在、Google Cloud プロジェクトで GA になっています。

Elastic Search AI Platform を使い始めて、その機能を試す最も簡単な方法の一つは、まだお試しいただいていない場合、 Elastic Cloud の無料トライアルを利用するか、 Google Cloud Marketplaceからサブスクライブすることです。

この投稿で説明されている機能のリリースとタイミングは、Elastic の独自の裁量により決定されます。現在利用できない機能は、予定どおりに提供されないか、まったく提供されない可能性があります。Elastic、Elasticsearch および関連するマークは、米国およびその他の国における Elasticsearch NV の商標、ロゴ、または登録商標です。その他すべての会社名および製品名は、それぞれの所有者の商標、ロゴ、または登録商標です。

なぜ複数のグラフを使用するのかと疑問に思うかもしれません。これは、Lucene のアーキテクチャ上の選択である不変セグメントによる副作用です。ほとんどのアーキテクチャ上の選択と同様に、長所と短所があります。たとえば、最近 Serverless Elasticsearch が GA になりました。この文脈において、私たちは不変セグメントから、効率的なインデックス レプリケーションや、インデックスとクエリの計算を分離して個別に自動スケーリングする機能など、非常に大きなメリットを得ています。ベクトル量子化の場合、セグメントのマージにより、パラメータを更新してデータ特性に適合させることができます。これに沿って、データ特性を測定し、インデックスの選択を再検討する機会を持つことで得られる他の利点もあると考えています。

この投稿では、複数の HNSW グラフを構築する際のオーバーヘッドを大幅に削減し、特にグラフのマージにかかるコストを削減するために私たちが行ってきた作業について説明します。

背景

管理可能な数のセグメントを維持するために、Lucene はセグメントをマージする必要があるかどうかを定期的に確認します。これは、現在のセグメント数が、基本セグメント サイズとマージ ポリシーによって決定されるターゲット セグメント数を超えているかどうかを確認することになります。カウントを超過すると、Lucene は制約に違反しながらセグメントのグループを結合します。このプロセスについては他の場所で詳しく説明されています。

Lucene は、書き込み増幅の対数的増加を実現するため、同様のサイズのセグメントを結合することを選択します。ベクトル インデックスの場合、書き込み増幅はベクトルがグラフに挿入される回数です。Luceneはセグメントを約10個のグループにまとめ、マージしようとします。その結果、ベクトルはグラフに約挿入されます。ここで、 はインデックス ベクトル数、 予想される基本セグメント ベクトル数です。対数増加のため、巨大なインデックスの場合でも書き込み増幅は 1 桁になります。ただし、グラフのマージに費やされる合計時間は、書き込み増幅に直線的に比例します。

HNSW グラフをマージする際には、最大セグメントのグラフを保持し、他のセグメントのベクトルをそのグラフに挿入するという、小さな最適化をすでに行っています。これが上記の 9/10 要因の理由です。以下では、マージするすべてのグラフの情報を使用することで、どのように大幅に改善できるかを示します。

HNSW グラフのマージ

これまでは、最大のグラフを保持し、他のグラフからベクトルを挿入し、それらを含むグラフは無視していました。以下で利用する重要な洞察は、破棄する各 HNSW グラフには、それに含まれるベクトルに関する重要な近接情報が含まれているということです。この情報を使用して、少なくとも一部のベクトルの挿入を高速化したいと考えています。

これは任意のマージポリシーを構築するために使用できるアトミック操作であるため、小さなグラフを大きなグラフに挿入する問題に焦点を当てます。

戦略は、 の頂点のサブセットを見つけて、大きなグラフに挿入することです。次に、小さなグラフ内のこれらの頂点の接続性を使用して、残りの頂点の挿入を高速化します。以下では、小さいグラフと大きいグラフの頂点 の隣接点をそれぞれ と で表します。図式的にプロセスは次のとおりです。

MERGE-HNSW

Inputs and

1Find to insert into using COMPUTE-JOIN-SET 2Insert each vertex into 3for do 4 5 6FAST-SEARCH-LAYER 7SELECT-NEIGHBORS-HEURISTIC 8

以下で説明する手順 (1 行目) を使用して、セットを計算します。次に、標準の HNSW 挿入手順 (2 行目) を使用して、 内のすべての頂点を大きなグラフに挿入します。挿入していない各頂点については、挿入した隣接頂点と、大きなグラフ内でのその隣接頂点を見つけます (4 行目と 5 行目)。このセットでシードされたFAST-SEARCH-LAYER手順 (6 行目) を使用して、HNSW論文からSELECT-NEIGHBORS-HEURISTICの候補を検索します (7 行目)。実際には、 SEARCH-LAYER INSERTメソッド (論文のアルゴリズム 1) の候補セットを見つけるために置き換えていますが、それ以外は変更されていません。最後に、先ほど挿入した頂点を (行 8) に追加します。

これが機能するためには、 内のすべての頂点が内に少なくとも 1 つの隣接頂点を持つ必要があることは明らかです。実際、 内のすべての頂点に対して、 (あるに対して) が最大のレイヤー接続性であることが必要です。実際の HNSW グラフでは、頂点次数がかなり広がっていることがわかります。下の図は、Lucene HNSW グラフの最下層の頂点次数の典型的な累積密度関数を示しています。

に固定値を使用することと、それを頂点次数の関数にすることを検討しました。この2番目の選択肢は、グラフの品質への影響を最小限に抑えながら大幅なスピードアップにつながるため、次の方法を採用しました。

定義により、 | は小さなグラフの頂点の次数に等しいことに注意してください。下限が 2 の場合、次数が 2 未満のすべての頂点が挿入されます。

単純な計算の議論によれば、 慎重に選択すれば、約に直接挿入するだけでよいことがわかります。具体的には、グラフの端の頂点の 1 つをに挿入すると、グラフのエッジに色を付けます。すると、 内に少なくとも 個の 隣接頂点を持つためには、少なくとも 個の 辺を色付けする必要があることがわかります。さらに、我々は

ここで、 小さなグラフ内の平均頂点次数です。J内の各頂点に対して、最大での辺を色付けします。したがって、色付けすると予想されるエッジの総数は最大でとなります。慎重に選択することで、この辺の数に近い色を塗ることができると期待しており、すべての頂点をカバーするには満たす必要がある。

これは、 を意味します。

SEARCH-LAYERが実行時間を支配すると、マージ時間を最大高速化できる可能性があります。書き込み増幅の対数的増加を考慮すると、非常に大きなインデックスの場合でも、通常は 1 つのグラフを構築する場合と比べて構築時間が 2 倍になるだけです。

この戦略のリスクは、グラフの品質が損なわれることです。最初は何も実行しないFAST-SEARCH-LAYERを試しました。これにより、特に単一のセグメントにマージするときに、レイテンシの関数としてのリコールが影響を受ける程度にグラフの品質が低下することがわかりました。次に、グラフの限定的な検索を使用して、さまざまな代替案を検討しました。結局、最も効果的な選択は最も単純なものでした。SEARCH-LAYERを使用しますが、 ef_constructionは低くします。このパラメータ化により、優れた品質のグラフを実現しながらも、マージ時間を平均で 30% 強短縮することができました。

結合セットの計算

適切な結合セットを見つけることは、HNSW グラフ カバー問題として定式化できます。貪欲ヒューリスティックは、最適なグラフカバーを近似するためのシンプルで効果的なヒューリスティックです。私たちが採用するアプローチでは、ゲインが減少する順に頂点を 1 つずつ選択してに追加します。ゲインは次のように定義されます。

ここで、 におけるベクトル の近傍の数を表し、 は 指示関数である。ゲインには、 に追加した頂点の数の変化、つまりが含まれます。これは、カバーされていない頂点を追加することで目標に近づくためです。中央のオレンジ色の頂点のゲイン計算を下の図に示します。

各頂点に対して次の状態を維持します。

1. 古くなっても、

2. そのゲイン 、

3. 内の隣接頂点の数はと表され、

4. タイブレークに使用される範囲 [0,1] 内の乱数。

結合セットを計算するための疑似コードは次のとおりです。

COMPUTE-JOIN-SET

Inputs

1 2 3for do 4 5 6 7while do 8 maximum gain vertex in 9Remove the state for from 10if is not stale then 11 12 13for do 14mark as stale if 15mark neighbors of stale if 16 17else 18 19if then 20 21return

まず 1 行目から 5 行目で状態を初期化します。

メイン ループの各反復では、最初に最大ゲイン頂点 (行 8) を抽出し、同点の場合はランダムに決定します。変更を加える前に、頂点のゲインが古くなっているかどうかを確認する必要があります。特に、 に頂点を追加するたびに、他の頂点のゲインに影響を与えます。

1. すべての隣接ノードはに追加の隣接ノードを持つため、ゲインは変化する可能性がある（14行目）

2. いずれかの隣接セルが完全にカバーされている場合、その隣接セルのゲインはすべて変化する可能性があります（14～16行目）

ゲインは遅延方式で再計算されるため、頂点をに挿入する場合にのみ、その頂点のゲインを再計算します (18 ～ 20 行目)。ゲインは常に減少するだけなので、挿入すべき頂点を見逃すことは決してありません。

いつ終了するかを決定するには、 に追加した頂点の合計増加を追跡するだけでよいことに注意してください。さらに、 の場合、少なくとも 1 つの頂点のゲインはゼロではないため、常に進歩します。

成果

私たちは、サポートされている 3 つの距離メトリック (ユークリッド、コサイン、内積) をカバーする 4 つのデータセットで実験を実行しました。

1. quora-E5-small: 522931文書、384次元、コサイン類似度を使用、

2. cohere-wikipedia-v2: 100万文書、768次元、コサイン類似度を使用。

3. 要点: 100万文書、960次元、ユークリッド距離を使用、

4. cohere-wikipedia-v3: 100 万件のドキュメント、1024 次元、最大内積を使用します。

各データセットに対して、2 つの量子化レベルを評価します。

1. int8 – 次元ごとに1バイトの整数を使用し、

2. BBQ – 次元ごとに 1 ビットを使用します。

最後に、各実験について、2 つの検索深度で検索品質を評価し、インデックスを構築した後と、単一のセグメントに強制的にマージした後を調べます。

要約すると、グラフの品質を維持しながら、インデックス作成とマージの速度を一貫して大幅に向上させ、すべてのケースで検索パフォーマンスを実現できます。

実験1: int8量子化

ベースラインから候補、つまり提案された変更までの平均的な高速化は次のとおりです。

インデックス時間の高速化: 1.28

強制マージの高速化: 1.72

これは実行時間の次の内訳に対応する。

完全性のために正確な時間は

索引

マージ

データセット

ベースライン

候補者

構築

候補者

quora-E5-small

112.41秒

81.55秒

113.81秒

70.87秒

ウィキコヒアv2

158.1秒

122.95秒

425.20秒

239.28秒

要旨

141.82秒

119.26秒

536.07秒

279.05秒

ウィキコヒアv3

211.86秒

168.22秒

654.97秒

414.12秒

以下に、複数のセグメントを持つインデックス（すべてのベクトルをインデックスした後のデフォルトのマージ戦略の最終結果）と単一セグメントへの強制マージ後のインデックスの、2 つの検索深度（recall@10 と recall@100）と、単一セグメントへの強制マージ後の、候補（破線）とベースラインを比較したリコール対レイテンシのグラフを示します。曲線が高く、左に寄っているほど良好であり、これは、より低いレイテンシでより高い再現性を意味します。

ご覧のとおり、複数のセグメント インデックスの場合、候補は Cohere v3 データセットの方が優れており、他のすべてのデータセットではわずかに劣りますが、ほぼ同等です。単一セグメントに統合した後、リコール曲線はすべてのケースでほぼ同じになります。

実験2：BBQ量子化

ベースラインから候補までの平均的な高速化は次のとおりです。

インデックス時間の高速化: 1.33

強制マージの高速化: 1.34

これは実行時間の次の内訳に対応する。

完全性のために正確な時間は

索引

マージ

データセット

ベースライン

候補者

構築

候補者

quora-E5-small

70.71秒

58.25秒

59.38秒

40.15秒

ウィキコヒアv2

203.08秒

142.27秒

107.27秒

85.68秒

要旨

110.35秒

105.52秒

323.66秒

202.2秒

ウィキコヒアv3

313.43秒

190.63秒

165.98秒

159.95秒

複数のセグメント インデックスの場合、ベースラインがわずかに優れている cohere v2 を除き、ほぼすべてのデータセットで候補の方が優れています。単一セグメントインデックスの場合、リコール曲線はすべてのケースでほぼ同じです。

まとめ

このブログで説明したアルゴリズムは、今後リリースされる Lucene 10.2 およびそれに基づく Elasticsearch リリースで利用できるようになります。ユーザーは、これらの新しいバージョンで改善されたマージ パフォーマンスと短縮されたインデックス構築時間を活用できるようになります。この変更は、Lucene と Elasticsearch をベクター検索とハイブリッド検索に高速かつ効率的にするための継続的な取り組みの一環です。

このブログでは、パート1の例を基に、後期相互作用ベクトルを大規模な本番ワークロードに対応させるために、さまざまなテクニックとElasticsearchの強力なベクトル検索ツールキットをどのように使用するかを説明します。

完全なコード例はGitHubにあります。

後期相互作用モデルの課題

ColPaliは、インデックス内のドキュメントに対してページごとに1000を超えるベクトルを作成します。

これにより、後期相互作用ベクトルを扱う際に2つの課題が生じます。

1. ディスク容量：これらのベクトルをすべてディスクに保存すると、大量のストレージ使用量が発生し、規模が大きくなるとコストが高くなります。

2. 計算：ドキュメントのランキングを行う際に、maxSimDotProduct()比較を使用すると、各ドキュメントのすべてのベクトルをクエリのN個のベクトルと比較する必要があります。

これらの問題に対処するためのいくつかの手法を見てみましょう。

後期相互作用モデルを最適化する技術

ビットベクトル

ディスク容量を減らすために、画像をビットベクトルに圧縮することができます。Pythonの簡単な関数を使用して、マルチベクトルをビットベクトルに変換できます。

この関数の基本的な概念は単純で、0より大きい値は1に、0より小さい値は0になり、これが0と1の配列となり、それをビットベクトルを表す16進数の文字列に変換するというものです。

インデックスマッピングでは、element_typeパラメータをbitに設定します。

新しいビットベクトルをすべてインデックスに書き込んだら、次のコードを使ってビットベクトルをランク付けします。

精度を少し犠牲にすることで、ハミング距離（maxSimInvHamming(...)）を使用することができます。これにより、ビットマスク、SIMDなどの最適化を活用できます。ビットベクトルとハミング距離について詳しくはブログをご覧ください。

あるいは、クエリベクトルをビットベクトルに変換せずに、完全な忠実度の後期相互作用ベクトルで検索することもできます。

これにより、非対称類似関数を用いてベクトルを比較します。

2つのビットベクトル間の通常のハミング距離について考えてみましょう。以下のドキュメントベクトルDと

クエリベクトルQがあると仮定します。

シンプルなバイナリ量子化では、ベクトルDを 10101101に、Qを11111011に変換します。ハミング距離を見つけるには、直接ビット計算が必要ですが、これは非常に高速です。この場合、ハミング距離は 01010110であり、ビット数は4です。したがって、得点はそのハミング距離の逆数になります。類似するベクトルほどハミング距離は小さくなるため、これを反転すると類似するベクトルに高いスコアが付けられるようになります。特にここで、スコアは1/4 = 0.25となります。

ただし、各次元の大きさが失われることに注意してください。1は1です。ですから、Qについては、0.01 と0.79 の違いはなくなります。単純に>0に従って量子化しているので、Qベクトルが量子化されない小さなトリックを実行できます。これではビット単位の超高速演算はできませんが、Dが量子化されたままなので、ストレージコストは低く抑えられます。

つまり、これによりQで提供される情報が保持され、距離推定の品質が向上し、ストレージが小さく抑えられます。

ビットベクトルを使用することで、ディスク容量とクエリ時の計算負荷を大幅に節約できます。しかし、できることはまだあります。

平均ベクトル

数十万、数百万のドキュメントにわたって検索をスケールするには、ビットベクトルがもたらすパフォーマンスの恩恵でさえ十分ではないでしょう。このようなタイプのワークロードにスケールするには、ElasticsearchのHNSWインデックス構造をベクトル検索に活用したいと思うでしょう。

ColpAliはドキュメントごとに約1000ベクトルを生成しますが、これは多すぎ、HNSWグラフに追加することはできません。したがって、ベクトルの数を減らす必要があります。これを行うには、画像を埋め込むときにColPaliによって生成されたすべてのドキュメントベクトルの平均を取得して、ドキュメントの意味の単一の表現を作成します。

現時点では、これはElastic自体では不可能であり、Elasticsearchに取り込む前にベクトルを前処理する必要があります。

Logstashまたは取り込みパイプラインでこれを行うことができますが、ここでは単純なPython関数を使用します。

また、ドット積類似度を使用できるようにベクトルを正規化しています。

ColPaliのベクトルをすべて平均ベクトルに変換したら、それらをdense_vectorフィールドにインデックスできます。

これによって、後期相互作用ベクトルとともにさらに多くの情報が保存されるため、合計ディスク使用量が増加することを考慮する必要があります。さらに、HNSWグラフを保持するために追加のRAMを使用して、何十億ものベクトルにわたって検索をスケールできるようにします。RAMの使用を減らすために、人気の BBQ機能を活用できます。その結果、通常では不可能な膨大なデータセットに対して高速な検索結果が得られます。

knnクエリで検索するだけで最も関連性の高いドキュメントを見つけられるようになりました。

以前最高だったマッチは残念ながら3位に落ちました。

この問題を解決するために、多段階の取得を行うことができます。最初の段階では、knnクエリを使って数百万件の文書からクエリに最適な候補を検索します。第2段階では、ColPaliの後期相互作用ベクトルの忠実度が高い上位k（ここでは10）のみを再ランクしています。

ここでは、8.18で導入されたリスコアリトリーバーを使用して結果を再ランク付けしています。再採点後、ベストマッチが再び1位になったことがわかります。

注：本番環境では、maxSim関数が以前として相対的に高パフォーマンスであるため、10よりはるかに高いkを使うことができます。

トークンプーリング

トークンプーリングは、白い背景のパッチなどの冗長な情報をプールすることで、マルチベクトル埋め込みのシーケンスの長さを短縮します。この技術により、ページのシグナルの大部分を維持しながら埋め込みの数を減らすことができます。

トークンプーリングは、クラスタリングアルゴリズムを使用して、ドキュメント内の類似したトークン埋め込みをクラスターにグループ化することによって機能します。次に、各クラスターのベクトルの平均を計算して、単一の集約表現を作成します。この集約されたベクトルはグループ内の元のトークンを置き換え、ドキュメントシグナルを大幅に失うことなくベクトルの合計数を削減します。

ColPaliの論文では、ほとんどのデータセットに対して初期プールファクター値を3とすることを提案しており、これにより元のパフォーマンスの97.8%を保持しつつ、ベクトルの総数を66.7%削減しています。

しかし、注意も必要です。非常に密度が高く、テキストが多く、余白がほとんどない「Shift」データセットは、プールファクターが増加するにつれてパフォーマンスが急速に低下します。

プールされたベクトルを作成するには、colpali_engineライブラリを利用できます。

これで、次元が約66.7%削減されたベクトルが得られました。通常通りにインデックス化し、maxSimDotProduct()機能で検索することができます。

結果の精度が若干犠牲になりますが、良好な検索結果を得ることができます。

ヒント：pool_factorを高くすれば（100-200）、平均的なベクトルソリューションとここで説明したソリューションの中間を取ることもできます。ドキュメントあたり5-10ベクトル程度であれば、HNSWインデックスを活用するためにネストされたフィールドでインデックスを作成することが可能になります。

クロスエンコーダー、後期相互作用とバイエンコーダーの比較

これまでに学んだことを踏まえて、ColPaliやColBERTなどの後期相互作用モデルを他のAI検索手法と比較すると、どのような位置づけになるでしょうか。

maxSim関数はクロスエンコーダーと比較して安価ですが、クエリとドキュメントのペアごとに2つのベクトルを比較するだけのバイエンコーダーを使用したベクトル検索よりも、依然として多くの比較と計算を必要とします。

このため、後期相互作用モデルについては、一般的にトップkの検索結果のリランキングにのみ使用することを推奨します。また、フィールドタイプの名前であるrank_vectorsにもこれを反映しています。

では、クロスエンコーダーはどうでしょうか。クエリ時に実行するコストが安いため、後期相互作用モデルの方が優れているのでしょうか。これもまた、状況によります。クロスエンコーダーは一般的に高品質な結果を生成しますが、クエリとドキュメントのペアが変換器モデルを通して完全に処理する必要があるため、多くの計算リソースを必要とします。また、ベクトルのインデキシングを必要とせず、ステートレスな方法で動作できるという利点もあります。その結果は次のようになります。

• 使用ディスク容量の削減

• よりシンプルなシステム

• 検索結果の品質向上

• レイテンシが高いため、深いリランキングが困難

一方、後期相互作用モデルでは、この計算の一部をインデックス時にオフロードできるため、クエリのコストが削減されます。その代償として、ベクトルをインデックスする必要があり、インデックスパイプラインがより複雑になり、これらのベクトルを保存するためにより多くのディスク領域が必要になります。

特にColPaliの場合、画像には大量のデータが含まれているため、画像からの情報の分析は非常に高価です。この場合、クエリ時にこの情報を評価するとリソースが大量に消費され、処理が遅くなるため、トレードオフはColPaliなどの後期相互作用モデルを使用する方に傾きます。

ColBertのように、ほとんどのクロスエンコーダーのようにテキストデータを処理する後期相互作用モデル（例：elastic-rerank-v1）では、ディスクの節約とシンプルさのメリットを享受するためにクロスエンコーダーを使用する方が有利になる可能性があります。

ユースケースに合わせてこれらの長所と短所を比較検討し、最適な検索アプリケーションを構築するためにElasticsearchが提供するさまざまなツールを試してみることをお勧めします。

まとめ

このブログでは、ColpAliのような後期相互作用モデルをElasticsearchの大規模ベクトル検索用に最適化するさまざまな手法を紹介しました。後期相互作用モデルは検索効率とランキング品質の間の強力なバランスを実現しますが、ストレージと計算に関連する課題ももたらします。

これらの課題に対処するために、私たちは次の点を検討しました。

• ハミング距離や非対称最大類似度などの効率的な類似度計算を活用しながら、ディスク容量を大幅に削減するビットベクトル。

• 複数の埋め込みを単一の密な表現に圧縮する平均ベクトル。これにより、HNSW インデックスによる効率的な検索が可能になります。

• 冗長な埋め込みを賢明にマージしながら意味の整合性を保守し、クエリ時の演算処理の負担を軽減するトークンプーリング。

Elasticsearchは、ニーズに基づいて検索アプリケーションをカスタマイズおよび最適化するための強力なツールキットを提供します。検索速度、ランキング品質、ストレージ効率のどれを優先するかに関係なく、これらのツールとテクニックを使用すると、実際のアプリケーションのニーズに応じてパフォーマンスと品質のバランスをとることができます。

効率を一切犠牲にしないという当社の使命の一環として、NVIDIA GPU という興味深いコンピューター チップを使った高速化の可能性を模索しています。このチップについて聞いたことがあるかもしれません (本当に聞いたことありませんか?)。

パフォーマンスを重視する場合、指数関数的に多くのデータをインデックスする方法、そこから洞察を取得する方法、ML モデルが関係する場合にそれを実行する方法など、検討すべき問題領域がいくつかあります。GPU があれば、利用可能なメリットをすべて引き出すことができるはずです。

この記事では、Elasticsearch での GPU アクセラレーションによるベクトル検索について探りながら、NVIDIA ベクトル検索チームとのコラボレーションについて詳しく説明します。この作業により、開発者が実際の Elasticsearch 搭載アプリで GPU と CPU を組み合わせて使用できるユースケースが実現します。楽しい時間です！

Elasticsearch GPU

Elasticsearch エンジニアリング チームが、ベクトル検索アルゴリズムのバインディングを公開する、開発者向けのオープンソース cuVS Java API エクスペリエンスの構築に協力していることをお知らせします。この作業は、パナマFFIでのこれまでの経験を活用しています。Elasticsearch と Apache Lucene は、インデックス作成中にグラフを構築するために NVIDIA cuVS API を使用します。さて、話が先に進んでしまいましたが、少し戻ってみましょう。

このコラボレーションの中心となるのは、オープンソースの C++ ライブラリであるNVIDIA cuVSです。より高いスループット、より低いレイテンシ、より速いインデックス構築時間を実現することで、ベクター検索に GPU アクセラレーションをもたらすことを目指しています。しかし、Elasticsearch と Apache Lucene は Java で書かれています。これはどのように動作するのでしょうか?

lucene-cuvsと Elastic-NVIDIA-SearchScale のコラボレーションを導入して、これを Lucene エコシステムに導入し、Elasticsearch での GPU アクセラレーションによるベクトル検索を探索します。最近の NVIDIA cuVS 25.02 リリースでは、cuVS 用の Java API が追加されました。新しい API は実験段階であり、今後も進化していきますが、現在は使用可能です。「Java からネイティブ関数の呼び出しは遅いのではないだろうか?」という疑問が生じるかもしれません。もうない！バインディングには新しいPanama FFI (Foreign Function Interface) を使用しており、Java からネイティブ ダウンコールへのオーバーヘッドが最小限に抑えられています。

私たちはしばらくの間、Elasticsearch と Lucene で Panama FFIを使用してきました。すごいですね！でも…いつも「でも」ってあるじゃないですか。FFI には、Java バージョン間での可用性に関する課題があります。私たちは、cuVS API を Java 21 にコンパイルし、その実装を Java 22 をターゲットとしたマルチリリース jar 内にカプセル化することで、この問題を解決しました。これにより、cuVS Java を Lucene および Elasticsearch で直接使用できるようになります。

さて、cuVS Java API が手に入ったので、他に何が必要でしょうか?

CPUの2つのアルゴリズムの物語

Elasticsearch は、スケーラブルな近似 KNN 検索のためのHNSW アルゴリズムをサポートしています。ただし、GPU を最大限に活用するために、GPU が提供する高度な並列処理向けに特別に設計された別のアルゴリズム、 CAGRA [ C UDA A NN GRA ph ]を使用します。

CAGRA のサポートを追加する方法に入る前に、Elasticsearch と Lucene が「コーデック形式」を通じてインデックス データにアクセスする方法を見てみましょう。これは、

1. ディスク上の表現、

2. データの読み書きのためのインターフェース

3. Lucene のセグメントベースのアーキテクチャを処理するための仕組み。

私たちは、cuVS Java API を内部的に使用して GPU 上でインデックス作成と検索を行う新しい KNN (k 近傍法)ベクトル形式を実装しています。ここから、Elasticsearch のマッピングを通じてこのコーデック タイプをインデックス内のフィールド タイプに「plumb」します。その結果、バックアップ インデックスが CAGRA グラフを使用しているか、HNSW グラフを使用しているかに関係なく、既存の KNN クエリは引き続き機能します。もちろん、ここでは多くの詳細について触れていませんが、それについては今後のブログで取り上げる予定です。以下は、GPU アクセラレーション Elasticsearch の高レベルアーキテクチャです。

この新しいコーデック形式のデフォルトは CAGRA です。ただし、CPU 上での検索のために CAGRA グラフを HNSW グラフに変換することもサポートされています。

GPUでのインデックス作成と検索：いくつかの「コア」な決定を下す

Elasticsearch Serverless のステートレスアーキテクチャではインデックス作成と検索が分離されており、責任の区分が明確になっています。私たちは、これらの独立した責任をそれぞれ果たすために最適なハードウェア プロファイルを選択します。

ユーザーは主に次の 2 つの展開戦略を検討すると予想されます。

1. GPU でのインデックス作成と検索: インデックス作成中に CAGRA グラフを構築し、検索中に使用します。これは、非常に低遅延の検索が必要な場合に最適です。

2. GPU でインデックスを作成し、CPU で検索する: インデックス作成中に、CAGRA グラフを構築し、それを HNSW グラフに変換します。HNSW グラフはインデックスに保存され、後で CPU で検索に使用できます。

この柔軟性により、さまざまな展開モデルが提供され、コストとパフォーマンスのトレードオフが可能になります。たとえば、インデックス作成サービスでは、検索には低電力の CPU を使用しながら、GPU を使用してグラフをタイムリーに効率的に構築およびマージできます。

ElasticsearchにおけるGPUアクセラレーションによるベクトル検索の計画は以下のとおりです。

私たちは、コストとパフォーマンスのバランスをとるためのさまざまなノブを提供し、パフォーマンスの向上と展開戦略の柔軟性をユーザーに提供することを楽しみにしています。この作業が詳しく発表されたNVIDIA GTC 2025 セッションはこちらです。

素晴らしいコラボレーションを実現してくれた NVIDIA と SearchScale のエンジニアリング チームに感謝します。今後のブログでは、実装の詳細とパフォーマンス分析をさらに詳しく検討します。好奇心の帽子をしっかり握ってください🎩!

この最初の部分では、埋め込みベクトルの基本とベクトル検索が内部でどのように機能するかについて、一般的な紹介を提供することに重点を置いています。

最初の記事で学んだ知識をすべて活用して、第2 部では Elasticsearch でベクトル検索を設定する方法を詳しく説明します。

パート 3では、パート 1 と 2 で学んだ内容を活用し、その知識を基にして、Elasticsearch で強力なハイブリッド検索クエリを作成する方法を詳しく検討します。

この記事の本題に入る前に、時間をさかのぼって、セマンティック検索の重要な概念であるベクトルの歴史を少し振り返ってみましょう。

ベクトルは新しいものではない

2022年11月にChatGPTが登場して以来、「ベクトル検索」について聞いたり読んだりしない日はないということは、誰もが同意するでしょう。これはどこにでも存在し、広く普及しているため、つい最近登場した最先端技術であるという印象を受けることがよくありますが、実際にはこの技術は 60 年以上前から存在しているのです。このテーマに関する研究は 1960 年代半ばに始まり、最初の研究論文は 1978 年に情報検索の専門家である Gerard Salton 氏とコーネル大学の同僚によって発表されました。Salton の密ベクトル モデルと疎ベクトル モデルに関する研究は、現代のベクトル検索テクノロジの根幹を成しています。

過去 20 年間で、彼の研究に基づいたさまざまなベクトル DBMS が作成され、市場に投入されました。これらには、2019 年にベクター検索の取り組みを開始した Apache Lucene プロジェクトを搭載した Elasticsearch が含まれます。

ベクトルは現在どこにでも存在し、広く普及しているため、ベクトルを扱う前に、まずその基礎となる理論と内部の仕組みをしっかり理解することが重要です。その詳細に入る前に、語彙検索とベクトル検索の違いを簡単に確認して、それらの違いと相互補完性について理解を深めましょう。

ベクトル検索と語彙検索

ベクトル検索を紹介する簡単な方法は、おそらく慣れている従来の語彙検索と比較することです。ベクトル検索 (セマンティック検索とも呼ばれます) と語彙検索の動作は大きく異なります。字句検索は、Elasticsearch で長年使用されてきた種類の検索です。簡単にまとめると、インデックスされてクエリされた内容の本当の意味を理解しようとするのではなく、ユーザーがクエリに入力した単語のリテラルまたはその変形（語幹、同義語など）を、TF-IDFなどの類似性アルゴリズムを使用して以前にデータベースにインデックスされたすべてのリテラルと語彙的に一致させることに多大な努力を払います。

ご覧のとおり、左上の 3 つのドキュメントはトークン化され、分析されています。次に、結果の用語は転置インデックスにインデックス付けされ、分析された用語がそれらを含むドキュメント ID に単純にマッピングされます。すべての用語は 1 回だけ存在し、どのドキュメントでも共有されないことに注意してください。「nice german teacher」を検索すると、いずれもクエリの真の意味を捉えていないにもかかわらず、さまざまなスコアで 3 つのドキュメントすべてが一致します。

下の図 2 に見られるように、多義語や同音異義語、つまり綴りは同じだが意味が異なる単語 (right、palm、bat、mean など) を扱う場合はさらに複雑になります。3 つの異なる意味を持つ「right」という単語を取り上げ、何が起こるかを見てみましょう。

「I'm not right」を検索すると、最初に返された結果とはまったく逆の意味を持つ文書が返されます。まったく同じ用語を検索しても、順序を変えて意味を変えた場合（たとえば、 「右折する」と「右折する」）、まったく同じ結果（つまり、3 番目のドキュメント「右折する」）が返されます。確かに、クエリは過度に単純化されており、フレーズ マッチングなどのより高度なクエリは使用されていませんが、これは、語彙検索ではインデックスされている内容と検索されている内容の背後にある真の意味を理解していないことを示しています。それが明確でなくても心配しないでください。3 番目の記事でこの例を再度取り上げ、この場合にベクトル検索がどのように役立つかを確認します。

語彙検索を正当に評価するには、構造化データのインデックス作成方法 (マッピング、テキスト分析、取り込みパイプラインなど) とクエリの作成方法 (巧みに作成された DSL クエリ、クエリ用語分析など) を制御できる場合、語彙検索エンジンで驚くべき成果を上げることができ、それに疑問の余地はありません。Elasticsearch の語彙検索機能に関する実績は実に素晴らしいものです。過去数年間にそれが達成したこと、そして語彙検索の分野をどれだけ普及させ、改善したかは、実に注目すべきことです。

ただし、自由形式のテキストで質問する必要があるユーザーに対して、非構造化データ(画像、ビデオ、音声、生のテキストなど) のクエリをサポートするタスクを課せられる場合、語彙検索では不十分です。さらに、クエリがテキストではなく、画像である場合もあります。これについては後ほど説明します。このような状況で語彙検索が不十分な主な理由は、非構造化データは構造化データと同じようにインデックス付けもクエリもできないことです。非構造化データを扱う場合には、セマンティクスが重要になります。セマンティクスとはどういう意味ですか?とても簡単に言えば、意味です！

画像検索エンジン（Google Image Search や Lens など）の簡単な例を見てみましょう。画像をドラッグ アンド ドロップすると、Google セマンティック検索エンジンが検索した画像に最も類似した画像を見つけて返します。下の図 3 では、左側にジャーマン シェパードの写真が表示され、右側には取得されたすべての類似写真が表示されています。最初の結果は、提供された写真と同じ写真 (つまり、最も類似した写真) です。

これは人間にとっては単純かつ論理的に聞こえますが、コンピューターにとっては全く別の話です。これを可能にするのがベクトル検索です。世界が最近目撃したように、ベクトル検索によって解き放たれる力は莫大です。ではボンネットを開けて、下に何が隠れているか見てみましょう。

埋め込みベクトル

前に説明したように、語彙検索エンジンを使用すると、テキストなどの構造化データは、用語の実際の意味に関係なく、検索時に一致できる用語に簡単にトークン化できます。ただし、非構造化データは、大きなバイナリ オブジェクト (画像、ビデオ、オーディオなど) などのさまざまな形式をとることができるため、同じトークン化プロセスにはまったく適していません。さらに、セマンティック検索の目的は、データが表す意味に基づいて検索できるようにデータをインデックス化することです。どうすればそれを達成できるでしょうか?答えは2つの言葉です:機械学習です!もっと正確に言えば、ディープラーニングです!

ディープラーニングは、データの真の意味を段階的に抽出できる複数の処理層で構成された人工ニューラル ネットワークに基づくモデルに依存する機械学習の特定の領域です。これらのニューラル ネットワーク モデルの動作方法は、人間の脳に大きく影響を受けています。下の図 4 は、入力層と出力層、および複数の隠し層を持つニューラル ネットワークの概要を示しています。

ニューラル ネットワークの真の偉業は、単一の非構造化データを、埋め込みベクトルまたは単に埋め込みと呼ばれる浮動小数点値のシーケンスに変換できることです。人間は、ベクトルを 2 次元または 3 次元の空間で視覚化すると、ベクトルが何であるかをかなりよく理解できます。ベクトルの各成分は、2D xy 平面または 3D xyz 空間内の座標を表します。

ただし、ニューラル ネットワーク モデルが動作する埋め込みベクトルは、数百または数千の次元を持つ場合があり、単純に多次元空間内の点を表します。各ベクトル次元は、非構造化データの機能または特性を表します。これを、画像を 2048 次元の埋め込みベクトルに変換するディープラーニング モデルで説明しましょう。このモデルは、図 3 で使用したジャーマン シェパードの写真を、下の表に示す埋め込みベクトルに変換します。最初と最後の 3 つの要素のみが表示されていますが、テーブルにはさらに 2,042 の列/ディメンションがあることに注意してください。

赤い

犬です

青空

…

グラスなし

ジャーマンシェパード

木

ジャーマンシェパード 埋め込み

0.0121

0.9572

0.8735

…

0.1198

0.9712

0.0512

各列はモデルの次元であり、基礎となるニューラル ネットワークがモデル化しようとする機能または特性を表します。モデルに与えられた各入力は、その入力が 2048 次元のそれぞれにどの程度類似しているかに応じて特徴付けられます。したがって、埋め込みベクトルの各要素の値は、その入力と特定の次元の類似性を示します。この例では、モデルが犬とジャーマンシェパードの間に高い類似性があること、また青空が存在することを検出したことがわかります。

語彙検索では用語が一致するか一致しないかのどちらかになりますが、ベクトル検索では、非構造化データがモデルでサポートされている各次元とどの程度類似しているかをより正確に把握できます。そのため、埋め込みベクトルは、非構造化データの優れたセマンティック表現として機能します。

秘密のソース

非構造化データがディープラーニング ニューラル ネットワークによって、多数の次元に沿ったデータの類似性を捉える埋め込みベクトルに細分化される仕組みがわかったので、それらのベクトルのマッチングがどのように機能するかを理解する必要があります。答えは非常に簡単であることがわかりました。互いに近い埋め込みベクトルは、意味的に類似したデータ部分を表します。したがって、ベクトル データベースをクエリする場合、検索入力 (画像、テキストなど) は、まず、すべての非構造化データのインデックス作成に使用されたのと同じモデルを使用して埋め込みベクトルに変換され、最終的な目標はそのクエリ ベクトルに最も近い隣接ベクトルを見つけることです。したがって、必要なのは、クエリ ベクトルとデータベースにインデックスが付けられた既存のすべてのベクトルとの間の「距離」または「類似性」を測定する方法を見つけることだけです。

距離と類似性

幸いなことに、2 つのベクトル間の距離を測定することは、ベクトル演算のおかげで簡単に解決できる問題です。それでは、Elasticsearch などの最新のベクトル検索データベースでサポートされている、最も人気のある距離と類似度の関数を見てみましょう。警告、これから数学の話になります!

L1距離

2 つのベクトル x と y の L1 距離 (マンハッタン距離とも呼ばれる) は、それらのすべての要素のペアワイズ絶対差を合計することによって測定されます。明らかに、距離 d が小さいほど、2 つのベクトルは近くなります。式は以下のように非常にシンプルです。

視覚的に、L1 距離は以下の図 5 のように表すことができます。

2 つのベクトル x と y、たとえば x = (1, 2) と y = (4, 3) を取ると、両方のベクトルの L1 距離は | 1 - 4 | + | 2 - 3 | = 4 になります。

L2距離

2 つのベクトル x と y の L2 距離 (ユークリッド距離とも呼ばれます) は、まずそのすべての要素のペアワイズ差の 2 乗を合計し、その結果の平方根を取ることによって測定されます。基本的には 2 点間の最短経路 (斜辺とも呼ばれます) です。L1と同様に、距離dが小さいほど、2つのベクトルは近くなります。

L2距離は以下の図6に示されています。

L1距離に使用したのと同じ2つのサンプルベクトルxとyを再利用すると、L2距離はとして計算できます。10 の平方根を取ると 3.16 になります。

ライン距離

2 つのベクトル x と y の Linf (L 無限大) 距離は、チェビシェフ距離またはチェス盤距離とも呼ばれ、任意の 2 つの要素間の最長距離、または軸/次元の 1 つに沿って測定された最長距離として定義されます。式は非常にシンプルで、次のようになります。

Linf 距離の表現を以下の図 7 に示します。

ここでも、同じ 2 つのサンプル ベクトル x と y を取ると、L 無限大距離を max ( | 1 - 4 | 、 | 2 - 3 | ) = max (3, 1) = 3 として計算できます。

コサイン類似度

L1、L2、Linf とは対照的に、コサイン類似度は 2 つのベクトル x と y 間の距離を測定するのではなく、それらの相対的な角度、つまり両方がほぼ同じ方向を向いているかどうかを測定します。類似度が高いほど、2 つのベクトルは「近い」ことになります。式も非常にシンプルで、次のようになります。

2 つのベクトル間のコサイン類似度を表す方法を以下の図 8 に示します。

さらに、コサイン値は常に [-1, 1] の範囲内にあるため、図 9 に示すように、-1 は反対の類似性 (つまり、両方のベクトル間の角度が 180°)、0 は無関係の類似性 (つまり、角度が 90°)、1 は同一 (つまり、角度が 0°) を意味します。

もう一度、同じサンプルベクトル x と y を再利用し、上記の式を使用してコサイン類似度を計算してみましょう。まず、両方のベクトルのドット積をとして計算します。次に、両方のベクトルの長さ（大きさとも呼ばれます）を掛けます： 最後に、ドット積を乗算した長さ 10 / 11.18034 = 0.894427 (つまり、角度 26°) で割ります。これは 1 に非常に近いため、両方のベクトルは非常に似ていると見なすことができます。

ドット積類似度

コサイン類似度の欠点の 1 つは、2 つのベクトル間の角度のみが考慮され、大きさ (長さ) は考慮されないことです。つまり、2 つのベクトルがほぼ同じ方向を指していても、一方が他方よりもはるかに長い場合、両方とも類似していると見なされます。ドット積類似度 (スカラーまたは内積とも呼ばれる) は、ベクトルの角度と大きさの両方を考慮することで類似度を改善し、より正確な類似度メトリックを提供します。

ドット積類似度を計算するために、2 つの同等の式が使用されます。1 つ目は、先ほどコサイン類似度の分子で見たものと同じです。

2 番目の式は、両方のベクトルの長さにそれらの間の角度の余弦を掛けるだけです。

ドット積の類似性は、以下の図 10 に視覚化されています。

最後にもう一度、サンプルの x ベクトルと y ベクトルを取り、最初の式を使用して、(1 4) + (2 3) = 10 として、先ほどコサイン類似度を計算したのと同じように、ドット積類似度を計算します。

2 番目の式を使用して、両方のベクトルの長さを掛けます: これに両方のベクトル間の角度 26° のコサインを掛けると、11.18034 cos(26°) = 10 になります。

注目すべき点は、すべてのベクトルが最初に正規化されている場合（つまり、長さが 1 の場合）、ドット積類似度はコサイン類似度（|x| |y| = 1 であるため）、つまり両方のベクトル間の角度のコサインとまったく同じになることです。後で説明するように、ベクトルを正規化することは、ベクトルの大きさを無関係にして類似性が角度のみに焦点を当てるようにするために採用する良い方法です。また、インデックス作成時およびクエリ時の距離計算も高速化されますが、これは数十億のベクトルを操作するときに大きな問題になる可能性があります。

簡単な要約

さて、これまで非常に多くの情報を見てきましたが、ここで少し立ち止まって、これまでの状況を簡単に振り返ってみましょう。私たちは次のことを学びました…

• …セマンティック検索は、非構造化データを多次元埋め込みベクトルに変換することに優れたディープラーニング ニューラル ネットワーク モデルに基づいています。

• …モデルの各次元は、非構造化データの機能または特性を表します。

• …埋め込みベクトルは、特定の非構造化データが各次元にどの程度類似しているかを表す類似度値のシーケンス（各次元に 1 つずつ）です。

• … 2 つのベクトルが「近い」ほど（つまり、最も近い隣り合うベクトルほど）、意味的に類似した概念を表していることになります。

• …距離関数 (L1、L2、Linf) を使用すると、2 つのベクトルがどれだけ近いかを測定できます。

• …相似関数 (コサインとドット積) を使用すると、2 つのベクトルが同じ方向にどれだけ進んでいるかを測定できます。

さて、最後に掘り下げる必要があるのは、ベクター検索エンジンそのものです。クエリが送られてくると、まずクエリがベクトル化され、次にベクトル検索エンジンがそのクエリ ベクトルに最も近い隣接ベクトルを見つけます。クエリ ベクトルとデータベース内のすべてのベクトル間の距離または類似性を測定するブルート フォース方式は、データ セットが小さい場合には有効ですが、ベクトルの数が増えるとすぐに不十分になります。言い換えれば、数百万、数十億、あるいは数兆ものベクトルをインデックス化し、クエリベクトルの最近傍を妥当な時間内に見つけるにはどうすればよいでしょうか。そこで私たちは賢くなって、ベクトルをインデックスする最適な方法を見つけ出し、精度をあまり落とさずにできるだけ早く最近傍に焦点を絞る必要があります。

ベクトル探索アルゴリズムと技術

長年にわたり、さまざまな研究チームが、非常に巧妙なベクトル検索アルゴリズムの開発に多大な労力を費やしてきました。ここでは、主なものを簡単に紹介します。使用ケースに応じて、他のものよりも適しているものがあります。

線形探索

先ほど、クエリ ベクトルをデータベース内に存在するすべてのベクトルと比較するブルート フォース手法について説明した際に、線形検索、つまりフラット インデックスについて簡単に触れました。小さなデータセットではうまく機能する可能性がありますが、ベクトルと次元の数が増えるとパフォーマンスが急激に低下します (O(n) の複雑度)。

幸いなことに、近似最近傍法(ANN) と呼ばれるより効率的なアプローチがあります。この方法では、埋め込みベクトル間の距離が事前に計算され、類似のベクトルが、たとえばクラスター、ツリー、ハッシュ、グラフなどを使用して、互いに近くなるように保存および整理されます。このようなアプローチは、通常 100% の精度を保証しないため、「近似」と呼ばれます。最終的な目標は、類似のベクトルが含まれる可能性が最も高い領域のみに焦点を当てるために、検索範囲をできるだけ早くできるだけ小さくするか、ベクトルの次元を減らすことです。

K次元ツリー

K 次元ツリー (KD ツリー) は、k 次元空間にポイントを格納するバイナリ検索ツリーの一般化であり、検索空間をベクトルがインデックス付けされた小さな左ツリーと右ツリーに連続的に二分することによって機能します。検索時には、アルゴリズムは、クエリ ベクトル (図 11 の赤い点) の周囲のいくつかのツリー ブランチを訪問するだけで、最も近い近傍 (図 11 の緑の点) を見つけることができます。k 個を超える近傍が要求された場合、アルゴリズムがさらに多くの近傍を見つけるまで黄色の領域が拡張されます。

KD ツリー アルゴリズムの最大の利点は、一部のローカライズされたツリー ブランチのみに素早く焦点を当てることができるため、ほとんどのベクトルを考慮から除外できることです。ただし、次元数が増えると、低次元空間よりも多くの分岐を訪問する必要があるため、このアルゴリズムの効率は低下します。

逆ファイルインデックス

逆ファイルインデックス (IVF) アプローチも、互いに近いベクトルを共有の重心に割り当てる空間分割アルゴリズムです。2D 空間では、図 12 に示すように、ボロノイ図でこれを視覚化するのが最適です。

上記の 2D 空間は 20 個のクラスターに分割されており、それぞれのクラスターの重心は黒い点で示されています。空間内のすべての埋め込みベクトルは、それらの重心が最も近いクラスターに割り当てられます。検索時に、アルゴリズムはまず、クエリ ベクトルに最も近い重心を見つけることで、焦点を当てるクラスターを判断し、次に、その領域と、必要に応じて周囲の領域に焦点を絞って、最も近い近傍を見つけます。

このアルゴリズムは、高次元空間で使用する場合、KD ツリーと同じ問題が発生します。これは次元の呪いと呼ばれ、空間の体積が非常に大きくなり、すべてのデータがまばらに見え、より正確な結果を得るために必要なデータの量が指数関数的に増加する場合に発生します。データがまばらな場合、これらの空間分割アルゴリズムでデータをクラスターに整理することが難しくなります。幸いなことに、この問題を軽減する他のアルゴリズムとテクニックが存在します。以下に詳細を説明します。

量子化

量子化は圧縮ベースのアプローチであり、埋め込みベクトルの精度を下げることでデータベースの合計サイズを削減できます。これは、浮動小数点ベクトル値を整数値に変換することにより、スカラー量子化 (SQ)を使用して実現できます。これにより、データベースのサイズが 8 分の 1 に縮小されるだけでなく、メモリ消費も減少し、検索時のベクトル間の距離計算が高速化されます。

もう 1 つの手法は積量子化 (PQ) と呼ばれ、最初に空間を低次元のサブスペースに分割し、次にクラスタリング アルゴリズム (k 平均法に類似) を使用して各サブスペース内で互いに近いベクトルをグループ化します。

量子化は次元削減とは異なることに注意してください。次元削減では次元数が削減され、ベクトルが単に短くなります。

階層的にナビゲート可能なスモールワールド（HNSW）

名前だけ読むと複雑に思えても心配しないでください。実際はそうではありません。つまり、Hierarchical Navigable Small Worlds は、非常に人気があり効率的な多層グラフベースのアルゴリズムです。Apache Lucene を含むさまざまなベクター データベースで使用されます。HNSW の概念的表現を以下の図 13 に示します。

最上層には、ベクトル間のリンクが最も長い少数のベクトルのグラフ、つまり、類似性が最も低い接続されたベクトルのグラフが表示されます。下の層に進んでいくと、見つかるベクトルの数が増え、グラフの密度が増し、ベクトル同士がどんどん接近していきます。最下層では、すべてのベクトルを見つけることができ、最も類似したベクトルが互いに最も近く配置されます。

検索時に、アルゴリズムは任意のエントリ ポイントの最上位レイヤーから開始し、クエリ ベクトル (灰色の点で表示) に最も近いベクトルを見つけます。次に、1 つ下のレイヤーに移動して、上のレイヤーに残したのと同じベクトルから始めて、同じプロセスを繰り返します。これを 1 レイヤーずつ続けて、最下層に到達してクエリ ベクトルに最も近い近傍を見つけます。

局所性依存ハッシュ（LSH）

これまでに紹介した他のすべてのアプローチと同様に、局所性に敏感なハッシュは、検索速度を向上させるために検索スペースを大幅に削減することを目指しています。この技術では、類似性情報を保持したまま埋め込みベクトルがハッシュ値に変換されるため、検索空間は最終的に、トラバースする必要のあるグラフやツリーではなく、検索できる単純なハッシュ テーブルになります。ハッシュベースの方法の主な利点は、任意の（大きな）数の次元を含むベクトルを固定サイズのハッシュにマッピングできるため、精度をあまり犠牲にすることなく検索時間が大幅に短縮されることです。

一般的にデータのハッシュ方法、特にベクトルの埋め込み方法は多種多様ですが、この記事ではそれぞれの詳細については説明しません。従来のハッシュ方法では、通常、非常に類似しているように見えるデータに対して非常に異なるハッシュが生成されます。埋め込みベクトルは浮動小数点値で構成されているため、ベクトル演算で互いに非常に近いと考えられる 2 つのサンプル浮動小数点値 (たとえば、0.73 と 0.74) を取り、いくつかの一般的なハッシュ関数を実行してみましょう。以下の結果を見ると、一般的なハッシュ関数では入力間の類似性を保持していないことは明らかです。

ハッシュ関数

0.73

0.74

MD5

1342129d04cd2924dd06cead4cf0a3ca

0aec1b15371bd979cfa66b0a50ebecc5

SHA1

49d2c3e0e44bff838e1db571a121be5ea874e8d9

a534e76482ade9d9fe4bff3035a7f31f2f363d77

SHA256

99d03fc3771fe6848d675339fc49eeb1cb8d99a12e6358173336b99a2ec530ea

5ecbc825ba5c16856edfdaf0abc5c6c41d0d8a9c508e34188239521dc7645663

従来のハッシュ方式では、類似したデータ間のハッシュ衝突を最小限に抑えようとしますが、局所性に敏感なハッシュの主な目的は、まさにその逆、つまり、類似したデータが高い確率で同じバケット内に含まれるようにハッシュ衝突を最大化することです。そうすることで、多次元空間内で互いに近接する埋め込みベクトルは、同じバケットに含まれる固定サイズの値にハッシュされます。LSH ではハッシュされたベクトルの近接性を維持できるため、この手法はデータのクラスタリングや最近傍検索に非常に便利です。

すべての面倒な作業は、ハッシュを計算する必要があるインデックス作成時に発生しますが、検索時には、最も近い埋め込みベクトルを含むバケットを検索するためにクエリ ベクトルをハッシュするだけで済みます。候補バケットが見つかると、通常は 2 回目のラウンドが実行され、クエリ ベクトルに最も近い隣接ベクトルが識別されます。

まとめましょう

ベクトル検索を紹介するために、この記事ではかなり広範囲にわたる内容を扱う必要がありました。語彙検索とベクトル検索の違いを比較した後、ディープラーニング ニューラル ネットワーク モデルが非構造化データのセマンティクスを捕捉し、その意味を高次元埋め込みベクトル (モデルの各次元に沿ったデータの類似性を表す浮動小数点数のシーケンス) に変換する方法を学びました。また、ベクトル検索と語彙検索は競合するものではなく、補完的な情報検索手法であることも注目に値します (このシリーズの第 3 部でハイブリッド検索について詳しく説明するときに説明します)。

その後、ベクトル検索の基本的な構成要素である距離 (および類似度) 関数を導入しました。これにより、2 つのベクトルの近接性を測定し、それらが表す概念の類似性を評価できるようになります。

最後に、ツリー、グラフ、クラスター、ハッシュをベースにした、最も人気のあるさまざまなベクトル検索アルゴリズムとテクニックを確認しました。その目的は、線形ブルート フォース検索のように空間全体を調べなくても、多次元空間の特定の領域をすばやく絞り込み、最も近い近傍を見つけることです。

この記事が気に入ったら、ぜひこのシリーズの他の部分も読んでみてください。

• パート2：Elasticsearchでベクトル検索を設定する方法

• パート3: Elasticsearchを使用したハイブリッド検索

すぐに使用できるセマンティック カーネル Elasticsearch ベクター ストア コネクタは、セマンティック カーネルベクター ストアの抽象化をサポートしており、開発者は AI エージェントの構築時に Elasticsearch をベクター ストアとしてプラグインすることが非常に簡単になります。

Elasticsearch はオープンソース コミュニティに強固な基盤を持ち、最近AGPL ライセンスを採用しました。これらのツールは、オープンソースの Microsoft Semantic Kernel と組み合わせることで、強力なエンタープライズ対応ソリューションを提供します。このコマンドcurl -fsSL https://elastic.co/start-local | sh (詳細についてはstart-localを参照) を実行して数分で Elasticsearch を起動し、ローカルで開始できます。その後、AI エージェントを本番稼働させながら、クラウドホスト バージョンまたはセルフホストバージョンに移行できます。

このブログでは、Semantic Kernel を使用する際にSemantic Kernel Elasticsearch Vector Store Connector を使用する方法について説明します。コネクタの Python バージョンは将来提供される予定です。

高レベルのシナリオ: Semantic Kernel と Elasticsearch を使用した RAG アプリの構築

次のセクションでは例を見ていきます。大まかに言うと、ユーザーの質問を入力として受け取り、回答を返す RAG (Retrieval Augmented Generation) アプリケーションを構築しています。LLM として Azure OpenAI (ローカル LLMも使用可能)、ベクター ストアとして Elasticsearch、すべてのコンポーネントを結び付けるフレームワークとして Semantic Kernel (.net) を使用します。

RAG アーキテクチャに精通していない場合は、次の記事で簡単に概要を把握できます: https://www.elastic.co/search-labs/blog/retrieval-augmented-generation-rag 。

回答は、Elasticsearch vectorstore から取得され、質問に関連するコンテキストが入力する LLM によって生成されます。応答には、LLM によってコンテキストとして使用されたソースも含まれます。

RAGの例

この具体的な例では、社内のホテル データベースに保存されているホテルについてユーザーが質問できるアプリケーションを構築します。ユーザーは例えばさまざまな基準に基づいて特定のホテルを検索したり、ホテルのリストを要求したりできます。

サンプル データベースでは、100 件のエントリを含むホテルのリストを生成しました。コネクタのデモをできるだけ簡単に試せるように、サンプル サイズは意図的に小さくなっています。実際のアプリケーションでは、特に非常に大量のデータを扱う場合、Elasticsearch コネクタは `InMemory` ベクトル ストア実装などの他のオプションよりも優位性を発揮します。

完全なデモ アプリケーションは、Elasticsearch ベクター ストア コネクタリポジトリにあります。

まず、必要な NuGet パッケージと using ディレクティブをプロジェクトに追加することから始めましょう。

これで、データ モデルを作成し、セマンティック カーネル固有の属性を指定して、ストレージ モデル スキーマとテキスト検索のヒントを定義できるようになりました。

ストレージ モデル スキーマ属性 (`VectorStore*`) は、Elasticsearch Vector Store Connector の実際の使用に最も関連しています。具体的には次のようになります。

• VectorStoreRecordKey レコード クラスのプロパティを、ベクトル ストアにレコードが格納されるキーとしてマークします。

• VectorStoreRecordData レコード クラスのプロパティを 'data' としてマークします。

• VectorStoreRecordVector レコード クラスのプロパティをベクトルとしてマークします。

これらの属性はすべて、ストレージ モデルをさらにカスタマイズするために使用できるさまざまなオプション パラメーターを受け入れます。たとえば、 VectorStoreRecordKey の場合、異なる距離関数や異なるインデックス タイプを指定することが可能です。

テキスト検索属性 ( TextSearch* ) は、この例の最後のステップで重要になります。これらについては後ほど説明します。

次のステップでは、セマンティック カーネル エンジンを初期化し、コア サービスへの参照を取得します。実際のアプリケーションでは、サービス コレクションに直接アクセスするのではなく、依存性注入を使用する必要があります。同じことがハードコードされた構成とシークレットにも当てはまります。これらは、代わりに構成プロバイダーを使用して読み取る必要があります。

vectorStoreCollectionサービスを使用してコレクションを作成し、いくつかのデモ レコードを取り込むことができるようになりました。

これは、セマンティック カーネルが、複雑なベクトル ストアの使用を、いくつかの単純なメソッド呼び出しにまで削減する方法を示しています。

内部的には、Elasticsearch に新しいインデックスが作成され、必要なすべてのプロパティ マッピングが作成されます。その後、データ セットは完全に透過的にストレージ モデルにマッピングされ、最終的にインデックスに保存されます。以下は Elasticsearch でのマッピングの様子です。

embeddings.GenerateEmbeddingsAsync()は、構成された Azure AI Embeddings Generation サービスを透過的に呼び出しました。

このデモの最後のステップでは、さらに多くの魔法が観察できます。

InvokePromptAsyncを 1 回呼び出すだけで、ユーザーがデータについて質問したときに、次のすべての操作が実行されます。

1.ユーザーの質問の埋め込みが生成される

2. ベクトルストアで関連するエントリを検索する

3. クエリの結果はプロンプトテンプレートに挿入されます

4. 最終プロンプトの形式で実際のクエリがAIチャット補完サービスに送信されます。

以前データ モデルで定義したTextSearch*属性を覚えていますか?これらの属性により、プロンプト テンプレート内の対応するプレースホルダーを使用できるようになります。これらのプレースホルダーには、ベクター ストア内のエントリからの情報が自動的に入力されます。

「屋上バーがあるホテルをすべて教えてください。」という質問に対する最終的な回答は次のとおりです。

答えは、hotels.csvの次のエントリを正しく参照しています。

この例は、Microsoft Semantic Kernel を使用すると、よく考えられた抽象化によって複雑さが大幅に軽減され、非常に高いレベルの柔軟性が実現されることを示しています。たとえば、コードの 1 行を変更するだけで、コードの他の部分をリファクタリングすることなく、使用されているベクトル ストアまたは AI サービスを置き換えることができます。

同時に、このフレームワークは、`InvokePrompt` 関数やテンプレート、検索プラグイン システムなどの膨大な高レベル機能を提供します。

完全なデモ アプリケーションは、Elasticsearch ベクター ストア コネクタ リポジトリにあります。

Elasticsearchで他に何ができるのか

• Elasticsearchの新しいsemantic_textマッピング：セマンティック検索の簡素化

• Elasticsearch におけるセマンティックリランキング（リトリーバー使用）

• 高度なRAGテクニックパート1：データ処理

• 高度なRAGテクニックパート2：クエリとテスト

• Llama 3オープンソースとElasticでRAGを構築する

• LangGraph、LLaMA3、Elasticsearchベクターストアを使用してローカルエージェントをゼロから構築するチュートリアル

Elasticsearch とセマンティックカーネル: 次は何?

• .NET で GenAI アプリケーションを構築する際に、Elasticsearch ベクター ストアを Semantic Kernel に簡単にプラグインする方法を示しました。次回の Python 統合にご期待ください。

• Semantic Kernel はハイブリッド検索などの高度な検索機能の抽象化を構築するため、Elasticsearch Connect を使用すると、.NET 開発者は Semantic Kernel を使用しながらそれらを簡単に実装できるようになります。

ハイブリッド検索の統合に加えて、検索ソリューションをさらに堅牢にする機能を追加する方法も紹介します。これには、ファセットやパーソナライズされた製品プロモーションが含まれます。さらに、Elastic の Behavioral Analytics ツールを使用して、ユーザーインタラクションをキャプチャし、貴重な洞察を生成する方法も紹介します。

この実装では、ユーザーが検索結果を表示して操作できるようにするインターフェースと、情報を返す API の両方を構築する方法について説明します。ソースコードを含むリポジトリにアクセスするには、以下のリンクを参照してください。

• https://github.com/elastic/elasticsearch-labs/tree/main/supporting-blog-content/hybrid-search-for-an-e-commerce-product-catalogue/product-store-search

• https://github.com/elastic/elasticsearch-labs/tree/main/supporting-blog-content/hybrid-search-for-an-e-commerce-product-catalogue/app-product-store

このガイドは、インデックスの作成からファセットや結果のパーソナライズなどの高度な機能の実装まで、いくつかのステップに分かれています。最後には、電子商取引のシナリオで使用できる強力な検索ソリューションが完成します。

電子商取引ハイブリッド検索の環境設定

実装を始める前に、環境を設定する必要があります。Elasticsearch を管理するには、Elastic Cloud 上のサービスまたはコンテナ化されたソリューションを使用するように選択できます。コンテナ化を選択した場合、Docker Compose 経由の構成はこのリポジトリにあります: docker-compose.yml 。

インデックス作成と製品カタログの取り込み

インデックスは、名前、説明、写真、カテゴリ、タグなどのフィールドを含む化粧品のカタログに基づいて作成されます。「名前」や「説明」などの全文検索に使用されるフィールドはtextとしてマッピングされますが、「カテゴリ」や「ブランド」などの集計に使用されるフィールドはファセットを有効にするためにkeywordとしてマッピングされます。

「説明」フィールドは、製品に関する詳細なコンテキストを提供するため、ベクター検索に使用されます。このフィールドは、説明のベクトル表現を格納するdense_vector,として定義されます。

インデックス マッピングは次のようになります。

インデックスを作成するためのスクリプトはここにあります。

埋め込み生成

製品の説明をベクトル化するために、モデル all-MiniLM-L6-v2 を使用します。この場合、アプリケーションはインデックス作成前に埋め込みを生成する必要があります。別のオプションとしては、モデルを Elasticsearch クラスターにインポートすることですが、このローカル環境では、アプリケーション内で直接ベクトル化を実行することを選択しました。

インデックスの作成には、 Kaggleで利用可能な化粧品データセットを使用し、データ取り込みの効率を向上させるためにバッチ処理を使用しました。この同じ取り込み段階で、「description」フィールドの埋め込みを生成し、新しいフィールド「description_embeddings」にインデックスを付けます。

完全なデータ取り込みプロセスは、リポジトリで利用可能なJupyter Notebookを通じて直接実行できます。このノートブックには、データがどのように読み取られ、処理され、Elasticsearch にインデックス付けされるかについてのステップバイステップのガイドが用意されており、簡単に複製および実験を行うことができます。

次のリンクからノートブックにアクセスできます: Ingestion Notebook。

ハイブリッド検索の実装

それでは、ハイブリッド検索を実装してみましょう。キーワードベースの検索では、「name」、「category」、「description」フィールドをターゲットとするmulti_matchクエリを使用します。これにより、これらのいずれかのフィールドに検索用語が含まれるドキュメントが取得されるようになります。

ベクトル検索には、 KNN クエリを使用します。クエリを実行する前に検索用語をベクトル化する必要があり、これは入力用語をベクトル化するメソッドを使用して実行されます。取り込み時に使用されたのと同じモデルが検索用語にも使用されることに注意してください。

両方の検索の組み合わせは、相互ランク融合 (RRF)アルゴリズムを使用して実現されます。このアルゴリズムは、2 つのクエリの結果を結合し、ノイズを減らすことで検索精度を向上させます。RRF を使用すると、キーワードベースの検索とベクトル検索の両方を連携させることができ、ユーザーのクエリの理解が向上します。

結果の比較: キーワード検索とハイブリッド検索

ここで、従来のキーワード検索とハイブリッド検索の結果を比較してみましょう。キーワード検索で「乾燥肌用ファンデーション」を検索すると、次のような結果が表示されます。

1. レブロン カラーステイ メイクアップ (普通肌/乾燥肌用)説明: レブロン カラーステイ メイクアップは、軽い処方で、固まったり、色落ちしたり、擦り落ちたりしない、長持ちするカバー力を提供します。タイムリリーステクノロジーを採用した、オイルフリーの水分バランスフォーミュラは、特に普通肌または乾燥肌に継続的に水分を補給するように作られています。特徴：メイクアップは快適なつけ心地で、最大24時間持続します。ミディアムからフルカバー。美しい色合いが揃っています。

2. メイベリン ドリームスムースムースファンデーション説明：気に入る理由ユニークなクリームホイップファンデーションが、100%赤ちゃんのような滑らかな肌を実現します。14時間、うるおいを保ち、肌荒れや乾燥を防ぎます。軽いつけ心地で、完璧な保湿効果を発揮します。シームレスにブレンドされ、一日中フレッシュな使い心地です。オイルフリー、無香料、皮膚科医テスト済み、アレルギーテスト済み、ノンコメドジェニック。毛穴を詰まらせません。安全です。敏感肌用。

分析：「乾燥肌用ファンデーション」を検索した場合、検索語のキーワードと製品のタイトルおよび説明が完全に一致する結果が得られました。ただし、この一致が必ずしも最良の選択を反映するとは限りません。たとえば、レブロン カラーステイ メイクアップ ノーマル / ドライ スキンは、特に乾燥肌向けに作られているので、良い選択肢です。オイルフリーでありながら、持続的な水分補給を実現する処方になっています。対照的に、メイベリン ドリーム スムース ムース ファンデーションも入手しました。オイルフリーで保湿効果もあると謳っていますが、オイルフリーの製品は乾燥肌に必要な水分補給よりも皮脂のコントロールに重点を置く傾向があるため、一般的に脂性肌や混合肌の方におすすめです。これは、乾燥肌の人々の特定のニーズを完全に満たさない製品が返される可能性がある、キーワードベースの検索の限界を浮き彫りにしています。

ここで、ハイブリッド アプローチを使用して同じ検索を実行すると、次のようになります。

1. CoverGirl アウトラスト ステイ ルミナス ファンデーション クリーミー ナチュラル (820):説明: CoverGirl アウトラスト ステイ ルミナス ファンデーションは、みずみずしい仕上がりとほのかな輝きを実現するのに最適です。オイルフリーでべたつかない処方で、肌に自然な輝きを与え、一日中持続します。この一日中使えるファンデーションは、完璧なカバー力を提供しながら肌に潤いを与えます。分析:この製品は、乾燥肌のユーザーにとって重要な保湿を重視しているため、関連性があります。「肌に潤いを与える」と「みずみずしい仕上がり」という言葉は、乾燥肌用のファンデーションを探しているユーザーの意図と一致しています。ベクター検索では、水分補給の概念を理解し、それを乾燥肌に対応するファンデーションの必要性に結び付けたと考えられます。

2. レブロン カラーステイ メイクアップ (普通肌/乾燥肌用):説明:レブロン カラーステイ メイクアップは、軽い処方で、固まったり、色落ちしたり、擦り落ちたりしない、長持ちするカバー力を提供します。タイムリリーステクノロジーを採用したこのオイルフリーの水分バランスフォーミュラは、普通肌や乾燥肌に継続的に水分を補給するために特別に配合されています。分析:この製品は、普通肌または乾燥肌向けに作られていることを明記しており、乾燥肌のユーザーのニーズに直接応えています。「モイスチャーバランス処方」と継続的な水分補給は、乾燥肌向けのファンデーションを探している人に最適です。ベクター検索では、キーワードの一致だけでなく、水分補給に重点が置かれ、ターゲット層として乾燥肌が具体的に言及されていたため、この結果が正常に取得されました。

3. セラム ファンデーション説明:セラム ファンデーションは、軽量で中程度のカバー力を持つフォーミュラで、21 色にわたる幅広い色調が揃っています。これらのファンデーションは、適度なカバー力があり、自然な仕上がりで、非常に軽い美容液のような感触です。粘度は非常に低く、付属のポンプ、または必要に応じて別途購入できるオプションのガラス製スポイトを使用して注入します。分析:この場合、説明では、自然な感触の軽い美容液ファンデーションを強調しています。これは、乾燥肌の人のニーズに合致しています。乾燥肌の方は、優しく、保湿性があり、ケーキ状にならない仕上がりの製品を求めることが多いからです。ベクター検索では、軽量で自然なカバー力と美容液のようなテクスチャーという幅広い文脈が拾われたと思われます。これらは保湿性と快適な使用感に関連し、「乾燥肌」という言葉は明示的には使われていませんが、乾燥肌との関連性が感じられます。

ファセット実装

ファセットは、検索結果を効率的に絞り込み、フィルタリングするために不可欠であり、特に電子商取引などの多種多様な製品を扱うシナリオでは、ユーザーに焦点を絞ったナビゲーションを提供します。ユーザーはカテゴリ、ブランド、価格などの属性に基づいて結果を調整できるため、検索の精度が向上します。この機能を実装するために、インデックス作成段階でkeywordとして定義されたcategoryフィールドとbrandフィールドに対して用語の集計を使用します。

実装の完全なコードはここにあります。

「乾燥肌用ファンデーション」の検索結果を以下に示します。

結果のカスタマイズ: 固定されたクエリ

場合によっては、検索結果で特定の商品を宣伝すると有益なことがあります。このため、特定の商品を結果の上部に表示できるPinned Queriesを使用します。以下では、商品を宣伝せずに「Foundation」という用語を検索します。

この例では、「グルテンフリー」のタグが付いた商品を宣伝できます。製品 ID を使用することで、検索結果で製品が優先されるようになります。具体的には、セラムファンデーション（ID：1043）、カバレッジファンデーション（ID：1042）、リアリスト インビジブルセッティングパウダー（ID：1039）の3商品をプロモーションします。

特定の製品 ID を使用することで、クエリ結果で製品が優先されるようになります。クエリ構造には、上部に「固定」する必要がある製品 ID のリスト (この場合は ID 1043、1042、および 1039) が含まれており、残りの結果は、フィールド「名前」、「カテゴリ」、「説明」のテキスト クエリなどの条件の組み合わせを使用して、検索の自然な流れに従います。この方法により、通常の関連性に基づいて残りの検索を維持しながら、アイテムを制御された方法で宣伝してそれらの可視性を確保することが可能になります。

以下に、プロモーション対象製品を使用したクエリ実行の結果を示します。

完全なクエリ コードはここにあります。

行動分析による検索行動の分析

これまでに、検索結果の関連性を向上させ、製品の発見性を高めるための機能をすでに追加してきました。ここで、ユーザーの検索行動を分析し、結果の有無や検索結果のクリックなどのパターンを識別する機能を追加して、検索ソリューションを完成させます。そのためには、Elastic が提供する行動分析機能を使用します。これにより、わずか数ステップでユーザーの検索行動を監視および分析し、検索エクスペリエンスを最適化するための貴重な洞察を得ることができます。

行動分析コレクションの作成

最初のアクションは、すべての動作分析イベントを受信するコレクションを作成することです。コレクションを作成するには、 「検索」 > 「行動分析」で Kibana インターフェースにアクセスします。以下の例では、 tracking-searchという名前のコレクションを作成しました。

インターフェースに行動分析を統合する

フロントエンドアプリケーションは JavaScript で開発されており、Behavioral Analytics を統合するには、Elastic の公式ドキュメントに記載されている手順に従って、 Behavioral Analytics JavaScript Tracker をインストールします。

JavaScriptトラッカーの実装

ここで、トラッカー クライアントをアプリケーションにインポートし、メソッドtrackPageView 、 trackSearch 、 trackSearchClickを使用してユーザー操作をキャプチャします。

免責事項: 当社はユーザーのインタラクションデータを収集するためにツールを使用していますが、 GDPRへの準拠を確実にするために不可欠です。これは、どのようなデータが収集され、どのように使用されるかをユーザーに明確に通知し、追跡をオプトアウトするオプションを提供することを意味します。さらに、収集した情報を保護し、データへのアクセスや削除などのユーザーの権利を尊重するために、強力なセキュリティ対策を実施し、すべての手順が GDPR の原則に準拠していることを確認する必要があります。

ステップ1: トラッカーインスタンスの作成

まず、インタラクションを監視するトラッカー インスタンスを作成します。この構成では、ターゲット エンドポイント、コレクション名、API キーを定義します。

ステップ2: ページビューのキャプチャ

ページビューを追跡するには、 trackPageViewイベントを設定します。

trackPageViewイベントの詳細については、このドキュメントを参照してください。

ステップ3: 検索クエリのキャプチャ

ユーザーの検索アクションを監視するには、 trackSearchメソッドを使用します。

ここでは検索用語と検索結果を収集しています。

ステップ4: 検索結果のクリックを追跡する

最後に、検索結果のクリックをキャプチャするために、 trackSearchClickメソッドを使用します。

クリックされたドキュメントの ID、検索用語、検索結果に関する情報も収集します。

Kibanaでデータを分析する

ユーザーインタラクションイベントがキャプチャされるようになったので、検索アクションに関する貴重なデータを取得できるようになりました。Kibana は、行動分析ツールを使用して、この行動データを視覚化して分析します。結果を表示するには、 「検索」>「行動分析」>「マイコレクション」に移動するだけで、キャプチャされたイベントの概要が表示されます。

この概要では、インターフェースに統合された各アクションでキャプチャされたイベントの概要を示します。この情報から、ユーザーの検索行動に関する貴重な洞察を得ることができます。ただし、特定のシナリオに関連性の高いメトリクスを使用してカスタマイズされたダッシュボードを作成したい場合、Kibana はダッシュボードを構築するための強力なツールを提供しており、メトリクスのさまざまな視覚化を作成できます。

以下に、時間の経過に伴う最も検索された用語、結果を返さなかったクエリ、最も検索された用語を強調表示するワード クラウド、最後に検索アクセスの発生元を識別する地理的な視覚化などを監視するための視覚化とグラフをいくつか作成しました。

まとめ

この記事では、キーワード検索とベクター検索を組み合わせたハイブリッド検索ソリューションを実装し、ユーザーにとってより正確で関連性の高い結果を提供します。また、ファセットやピン留めされたクエリによる結果のパーソナライズなどの追加機能を使用して、より完全で効率的な検索エクスペリエンスを実現する方法についても検討しました。

さらに、Elastic のBehavioral Analytics を統合して、検索エンジンとのやり取り中のユーザー行動をキャプチャして分析しました。trackPageView 、 trackSearch 、 trackSearchClickなどのメソッドを使用することで、検索クエリ、検索結果のクリック、ページビューを監視し、検索行動に関する貴重な分析情報を生成することができました。

参照資料

データセット

https://www.kaggle.com/datasets/shivd24coder/コスメティックブランド製品データセット

トランス

https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2

相互ランク融合

https://www.elastic.co/guide/en/elasticsearch/reference/current/rrf.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/retriever.html#rrf-retriever

Knnクエリ

https://www.elastic.co/guide/en/elasticsearch/reference/current/knn-search.html

固定されたクエリ

https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-pinned-query.html

行動分析API

https://www.elastic.co/guide/en/elasticsearch/reference/current/behavioral-analytics-apis.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/behavioral-analytics-overview.html

注: Elasticsearch C# クライアントNESTの古いバージョンに精通している場合は、NEST クライアントの廃止と新機能に関するこちらのブログ投稿をお読みください。NESTは.NETクライアントの前世代であり、Elastic.Clients.Elasticsearch package

• Blazor とは何ですか?

• ESRE とは何ですか?

• ELSER の設定

• データのインデックス作成

• 建築申請

Blazor とは何ですか?

Blazor は、開発者がクライアントまたはサーバー上で実行される Web アプリケーションを構築できるようにするために Microsoft によって作成された、オープン ソースの HTML、CSS、および C# ベースの Web フレームワークです。Blazor を使用すると、再利用可能なコンポーネントを作成してアプリケーションをより速く構築することもできます。開発者は、同じファイル内に C# で HTML ビューとアクションを構築できるため、読みやすくクリーンなコードを維持できます。さらに、Blazor Hybrid を使用すると、.NET コードを介してネイティブ プラットフォーム機能にアクセスするネイティブ モバイル アプリを構築できます。

Blazor を優れたフレームワークにする機能の一部を以下に示します。

• サーバー側とクライアント側のレンダリングオプション

• 再利用可能なUIコンポーネント

• SignalRによるリアルタイム更新

• 組み込みの状態管理

• 組み込みルーティングシステム

• 強力な型付けとコンパイル時のチェック

Blazor を選ぶ理由

Blazor は他のフレームワークやライブラリに比べていくつかの利点があります。開発者はクライアント コードとサーバー コードの両方に C# を使用できるため、強力な型指定とコンパイル時のチェックが可能になり、信頼性が向上します。.NET エコシステムとシームレスに統合され、.NET ライブラリとツールの再利用を可能にし、強力なデバッグ サポートを提供します。

ESRE とは何ですか?

Elasticsearch Relevance Engine ™ (ESRE)は、強力な Elasticsearch 検索エンジンをベースに機械学習と人工知能を使用して検索アプリケーションを構築するためのツールセットです。

ESREについて詳しく知りたい方は、こちらのブログ記事をご覧ください。

ELSER の設定

Elastic のESRE機能を活用するために、モデルプロバイダーとしてELSER を使用します。

ElasticsearchのELSERモデルを使用するには、PlatinumまたはEnterpriseライセンスと、最低4GBの専用機械学習（ML）ノードが必要です。詳細はこちらをご覧ください。

まず推論エンドポイントを作成します。

ELSER を初めて使用する場合は、モデルがバックグラウンドで読み込まれるときに 502 Bad Gateway エラーが発生する可能性があります。Kibana のMachine Learning > Trained Modelsでモデルのステータスを確認できます。デプロイが完了したら、次のステップに進むことができます。

データのインデックス作成

ここからデータセットをダウンロードし、Kibana を使用してデータをインポートできます。これを行うには、ホームページにアクセスして「データのアップロード」をクリックします。次に、ファイルをアップロードしてImportをクリックします。最後に、 Advancedタブに移動して、次のマッピングを貼り付けます。

セマンティック クエリとフルテキスト クエリを実行できるインデックスを作成します。semantic_textフィールド タイプは、データのチャンク化と埋め込みを処理します。として インデックス付けしていることに注意してください 。フィールドを と text` の 両方としてインデックス付けしたい場合は、 copy_to を使用できます 。longDescriptionsemantic_textsemantic_text

BlazorとElasticsearchを使ったアプリ構築

APIキー

最初に行う必要があるのは、Elasticsearch へのリクエストを認証するための API キーを作成することです。API キーは読み取り専用であり、 books-blazorインデックスのクエリのみに許可される必要があります。

次のような画面が表示されます。

後で必要になるので、 encoded応答フィールドの値を保存します。Elastic Cloudで実行している場合は、Cloud ID も必要になります。(こちらで確認できます)。

Blazorプロジェクトの作成

まず Blazor をインストールし、公式の手順に従ってサンプル プロジェクトを作成します。

プロジェクトを作成すると、フォルダー構造とファイルは次のようになります。

テンプレートアプリケーションにはBootstrap v5.1.0が含まれていますスタイリング用。

Elasticsearch .NETクライアントをインストールしてプロジェクトのセットアップを完了します。

この手順を完了すると、ページは次のようになります。

フォルダ構造

ここで、フォルダーを次のように整理します。

ファイルの説明:

• Components/Pages/Search.razor: 検索バー、結果、フィルターを含むメイン ページ。

• コンポーネント/ページ/Search.razor.css:ページ スタイル。

• Components/Elasticsearch/SearchBar.razor: 検索バー コンポーネント。

• Components/Elasticsearch/Results.razor: 結果コンポーネント。

• Components/Elasticsearch/Facet.razor: フィルター コンポーネント。

• Components/Svg/GlassIcon.razor: 検索アイコン。

• Components/_Imports.razor: これにより、すべてのコンポーネントがインポートされます。

• Models/Book.cs: ブックフィールドのスキーマを保存します。

• Models/Response.cs: 検索結果、ファセット、ヒット数の合計を含む応答スキーマを保存します。

• Services/ElasticsearchService.cs: Elasticsearch サービス。Elasticsearch への接続とクエリを処理します。

初期設定

まずはクリーンアップから始めましょう。

ファイルを削除します:

• コンポーネント/ページ/Counter.razor

• コンポーネント/ページ/Weather.razor

• コンポーネント/ページ/ホーム.razor

• コンポーネント/レイアウト/NavMenu.razor

• コンポーネント/レイアウト/NavMenu.razor.css

/Components/_Imports.razorファイルを確認してください。次のインポートが必要です。

プロジェクトにElasticを統合する

次に、Elasticsearch コンポーネントをインポートします。

アプリケーションのスペースを増やすために、 /Components/Layout/MainLayout.razorファイルからデフォルトのサイドバーを削除します。

次に、ユーザー シークレットの Elasticsearch 資格情報を入力します。

このアプローチを使用すると、.Net 8 は機密データをプロジェクト フォルダー外の別の場所に保存し、 IConfigurationインターフェースを使用してアクセスできるようになります。これらの変数は、同じユーザー シークレットを使用するすべての .Net プロジェクトで使用できます。

次に、 Program.csファイルを変更してシークレットを読み取り、Elasticsearch クライアントをマウントします。

まず、必要なライブラリをインポートします。

• BlazorApp.Services: Elasticsearch サービスが含まれます。

• Elastic.Clients.Elasticsearch: Elasticsearch クライアント .Net 8 ライブラリをインポートします。

• Elastic.Transport: Elasticsearch トランスポート ライブラリをインポートします。これにより、ApiKey クラスを使用してリクエストを認証できるようになります。

次に、 var app = builder.Build()行の前に次のコードを挿入します。

このコードは、ユーザー シークレットから Elasticsearch 資格情報を読み取り、Elasticsearch クライアント インスタンスを作成します。

ElasticSearch クライアントの初期化後、次の行を追加して Elasticsearch サービスを登録します。

次のステップでは、 /Services/ElasticsearchService.csファイルに検索ロジックを構築します。

まず、必要なライブラリとモデルをインポートします。

次に、クラスElasticsearchService 、コンストラクター、および変数を追加します。

検索の設定

それでは、検索ロジックを構築してみましょう。

• BuildFilters ユーザーが選択したファセットを使用して、検索クエリのフィルターを構築します。

• BuildHybridQuery 全文検索とセマンティック検索を組み合わせたハイブリッド検索クエリを構築します。

次に、検索メソッドを追加します。

• SearchBooksAsync: ハイブリッド クエリを使用して検索を実行し、ファセットを構築するための集計が含まれた結果を返します。

• FormatFacets: 集計応答を辞書にフォーマットします。

• ConvertFacetDictionary: ファセット辞書をより読みやすい形式に変換します。

次のステップでは、検索ページの結果として出力される Elasticsearch クエリのhitsで返されるデータを表すモデルを作成します。

まず、ファイル/Models/Book.csを作成し、次の内容を追加します。

次に、 /Models/Response.csファイルに Elastic レスポンスを設定し、次のコードを追加します。

基本的なUIの設定

次に、SearchBar コンポーネントを追加します。ファイル/Components/Elasticsearch/SearchBar.razorに次の内容を追加します。

このコンポーネントには、検索バーと検索を実行するためのボタンが含まれています。

Blazor は、同じファイル内で C# コードを使用して HTML を動的に生成できるようにすることで、優れた柔軟性を提供します。

その後、ファイル/Components/Elasticsearch/Results.razorで、検索結果を表示する結果コンポーネントを構築します。

最後に、検索結果をフィルタリングするためのファセットを作成する必要があります。

注: ファセットとは、製品タイプ、価格帯、ブランドなど、特定の属性やカテゴリに基づいて検索結果を絞り込むことができるフィルターです。これらのフィルターは通常、クリック可能なオプション（多くの場合チェックボックス）として表示され、ユーザーが検索を絞り込み、関連性の高い結果を見つけやすくします。Elasticsearchでは、ファセットは集計を使用して作成されます。

ファイル/Components/Elasticsearch/Facet.razorに次のコードを配置してファセットを設定します。

このコンポーネントは、 author 、 categories 、およびstatusフィールドのterms集計を読み取り、Elasticsearch に送り返すフィルターのリストを生成します。

さて、すべてをまとめてみましょう。

/Components/Pages/Search.razorファイル内:

私たちのページは機能しています!

ご覧のとおり、ページは機能しますが、スタイルが欠けています。見た目をもっと整理してレスポンシブにするために、CSS を追加してみましょう。

レイアウト スタイルの置き換えを始めましょう。Components/Layout/MainLayout.razor.cssファイル内:

Components/Pages/Search.razor.cssファイルで検索ページのスタイルを追加します。

ページの見た目が良くなり始めました:

最後に仕上げましょう:

次のファイルを作成します。

• コンポーネント/Elasticsearch/Facet.razor.css

• コンポーネント/Elasticsearch/Results.razor.css

Facet.razor.cssのスタイルを追加します:

Results.razor.cssの場合:

最終結果:

アプリケーションを実行するには、次のコマンドを使用できます。

dotnet watch

やったね！検索バーを使用して Elasticsearch インデックス内の書籍を検索し、著者、カテゴリ、ステータス別に結果をフィルタリングできるようになりました。

全文検索とセマンティック検索の実行

デフォルトでは、アプリは 全文検索 と セマンティック検索の 両方を使用して ハイブリッド検索を 実行します。フルテキスト検索用とセマンティック検索用の 2 つの別個のメソッドを作成し、いずれかのメソッドを選択してユーザーの入力に基づいてクエリを構築することで、検索ロジックを変更できます。

/Services/ElasticsearchService.csファイルのElasticsearchServiceクラスに次のメソッドを追加します。

どちらのメソッドもBuildHybridQueryメソッドと同様に動作しますが、全文検索またはセマンティック検索のみを実行します。

選択した検索方法を使用するようにSearchBooksAsyncメソッドを変更できます。

完全な申請書はここからご覧いただけます

まとめ

Blazor は、C# を使用して Web アプリケーションを構築できる効果的なフレームワークです。Elasticsearch は、検索アプリケーションを構築できる強力な検索エンジンです。両方を組み合わせることで、ESRE のパワーを活用して、セマンティック検索エクスペリエンスを短期間で実現し、堅牢な検索アプリケーションを簡単に構築できます。

• LLMとChatLanguageModelを実装して議論する ChatMemory

• チャット履歴をメモリに保持して、LLMとの以前の議論の文脈を思い出す

このブログ投稿では、次の方法について説明します。

• テキスト例からベクトル埋め込みを作成する

• ベクトル埋め込みをElasticsearch埋め込みストアに保存する

• 類似ベクトルを検索

埋め込みを作成する

埋め込みを作成するには、使用するEmbeddingModelを定義する必要があります。たとえば、前回の投稿で使用したのと同じミストラル モデルを使用できます。それは ollama で実行されていました:

モデルはテキストからベクトルを生成できます。ここで、モデルによって生成された次元の数を確認できます。

テキストからベクトルを生成するには、以下を使用します。

または、テキスト、価格、発売日などに基づいてフィルタリングできるようにメタデータも提供したい場合は、 Metadata.from()使用できます。たとえば、ここではゲーム名をメタデータ フィールドとして追加しています。

このコードを実行する場合は、 Step5EmbedddingsTest.javaクラスをチェックアウトしてください。

ベクトルを保存するためにElasticsearchを追加する

LangChain4j はメモリ内の埋め込みストアを提供します。これは簡単なテストを実行するのに便利です:

しかし、明らかに、このデータストアはすべてをメモリに保存し、サーバーに無限のメモリがないため、これよりもはるかに大きなデータセットでは機能しません。そのため、代わりに、定義上「弾性」があり、データに合わせてスケールアップおよびスケールアウトできる Elasticsearch に埋め込みを保存することができます。そのためには、Elasticsearch をプロジェクトに追加しましょう。

お気づきのとおり、Elasticsearch TestContainers モジュールもプロジェクトに追加したので、テストから Elasticsearch インスタンスを起動できます。

Elasticsearch を埋め込みストアとして使用するには、LangChain4j のインメモリ データストアから Elasticsearch データストアに切り替えるだけです。

これにより、Elasticsearch のdefaultインデックスにベクトルが保存されます。インデックス名をより意味のあるものに変更することもできます。

このコードを実行する場合は、 Step6ElasticsearchEmbedddingsTest.javaクラスをチェックアウトしてください。

類似ベクトルを検索

類似のベクトルを検索するには、まず、以前使用したのと同じモデルを使用して、質問をベクトル表現に変換する必要があります。すでにそれを行ったので、もう一度これを行うのは難しくありません。この場合、メタデータは必要ないことに注意してください。

質問をこのように表現して検索リクエストを作成し、埋め込みストアに最初の上位ベクトルを見つけるように依頼することができます。

これで、結果を反復処理して、メタデータから取得したゲーム名やスコアなどの情報を出力できます。

予想どおり、最初のヒットは「Out Run」になります。

このコードを実行する場合は、 Step7SearchForVectorsTest.javaクラスをチェックアウトしてください。

舞台裏

Elasticsearch Embedding ストアのデフォルト構成では、バックグラウンドで近似 kNN クエリが使用されます。

ただし、埋め込みストアにデフォルトの構成 ( ElasticsearchConfigurationKnn ) とは別の構成 ( ElasticsearchConfigurationScript ) を提供することでこれを変更できます。

ElasticsearchConfigurationScript実装は、script_score cosineSimilarity関数 を使用して、バックグラウンドで クエリ を実行します。

基本的に、電話をかけるときは:

これにより、次のコードが呼び出されます。

この場合、結果は「順序」の点では変化せず、スコアのみが調整されます。これは、 cosineSimilarity呼び出しでは近似値を使用せず、一致するベクトルごとにコサインを計算するためです。

このコードを実行する場合は、 Step7SearchForVectorsTest.javaクラスをチェックアウトしてください。

まとめ

テキストから埋め込みを簡単に生成する方法と、2 つの異なるアプローチを使用して Elasticsearch で最も近い近傍を保存および検索する方法について説明しました。

• デフォルトのElasticsearchConfigurationKnnオプションを使用して、近似高速knnクエリを使用する

• 正確だが遅いscript_scoreクエリをElasticsearchConfigurationScriptオプションとともに使用する

次のステップでは、ここで学んだことを基に、完全な RAG アプリケーションを構築します。

高度な RAG テクニックに関する記事のパート 2 へようこそ。このシリーズのパート 1では、高度な RAG パイプラインのデータ処理コンポーネントを設定、説明、実装しました。

この部分では、実装のクエリとテストを進めていきます。早速始めましょう！

目次

• 検索と取得、回答の生成

  • 同義語によるクエリの強化

  • HyDE（仮想文書埋め込み）

  • ハイブリッド検索

• 実験

  • 結果の要約

  • テスト 1: Elastic を監査するのは誰ですか?

    • アドバンスドRAG

    • シンプルラグ

  • テスト2：2023年の総収入

    • アドバンスドRAG

    • シンプルラグ

  • テスト 3: 成長は主にどの製品に依存しますか?いくら？

    • アドバンスドRAG

    • シンプルラグ

  • テスト4: 従業員福利厚生制度の説明

    • アドバンスドRAG

    • シンプルラグ

  • テスト 5: Elastic が買収した企業はどれですか?

    • アドバンスドRAG

    • シンプルラグ

• まとめ

• 付記

  • プロンプト

    • RAG質問回答プロンプト

    • 弾性クエリジェネレータプロンプト

    • 潜在的な質問ジェネレータプロンプト

    • HyDEジェネレータプロンプト

  • ハイブリッド検索クエリのサンプル

検索と取得、回答の生成

最初のクエリ、理想的には主に年次報告書に記載されている情報を尋ねてみましょう。いかがでしょうか:

ここで、クエリを強化するためにいくつかのテクニックを適用してみましょう。

同義語によるクエリの強化

まず、クエリの文言の多様性を高めて、Elasticsearch クエリに簡単に処理できる形式に変えてみましょう。GPT-4o の助けを借りて、クエリを OR 句のリストに変換します。次のプロンプトを書いてみましょう:

GPT-4o をクエリに適用すると、基本クエリの同義語と関連語彙が生成されます。

ESQueryMakerクラスでは、クエリを分割する関数を定義しました。

その役割は、この OR 句の文字列を取得して用語のリストに分割し、主要なドキュメント フィールドで複数の一致を実行できるようにすることです。

最終的にこのクエリに至ります:

これにより、元のクエリよりも多くのベースがカバーされ、同義語を忘れたために検索結果を見逃すリスクが軽減されることが期待されます。しかし、私たちにはもっとできることがある。

トップに戻る

HyDE（仮想文書埋め込み）

今回はHyDE を実装するために、再び GPT-4o を活用しましょう。

HyDE の基本的な前提は、仮想ドキュメント (元のクエリに対する回答が含まれる可能性のある種類のドキュメント) を生成することです。文書の事実性や正確性は問題ではありません。それを念頭に置いて、次のプロンプトを書いてみましょう。

ベクトル検索は通常、コサインベクトルの類似度に基づいて行われるため、クエリをドキュメントに一致させるのではなく、ドキュメントをドキュメントに一致させることでより良い結果を達成できるというのが HyDE の前提です。

私たちが重視するのは、構造、フロー、用語です。あまり事実ではない。GPT-4o は次のような HyDE ドキュメントを出力します。

これはかなり信憑性があり、インデックスを作成したい種類のドキュメントに最適な候補のように見えます。これを埋め込み、ハイブリッド検索に使用します。

トップに戻る

ハイブリッド検索

これが私たちの検索ロジックの中核です。語彙検索コンポーネントは、生成された OR 句の文字列になります。高密度ベクトル コンポーネントには、HyDE ドキュメント (検索ベクトルとも呼ばれます) が埋め込まれます。KNN を使用して、検索ベクトルに最も近い候補ドキュメントをいくつか効率的に識別します。デフォルトでは、語彙検索コンポーネントをTF-IDF と BM25 によるスコアリングと呼びます。最後に、語彙スコアと密なベクトルスコアは、 Wang らが推奨する 30/70 比率を使用して結合されます。

最後に、RAG 関数を組み立てることができます。クエリから回答までの RAG の流れは次のようになります。

1. クエリを OR 句に変換します。

2. HyDE ドキュメントを生成して埋め込みます。

3. 両方をハイブリッド検索への入力として渡します。

4. 上位 n 件の結果を取得し、最も関連性の高いスコアが LLM のコンテキスト メモリ内で「最新」になるように結果を逆にします (逆パッキング)。逆パッキングの例: クエリ:「Elasticsearch クエリ最適化手法」取得されたドキュメント (関連性の高い順): LLM コンテキストの順序を逆にする: 順序を逆にすることで、最も関連性の高い情報 (1) がコンテキストの最後に表示され、回答生成中に LLM からより多くの注目を受ける可能性が高くなります。

   1. 「ブールクエリを使用して、複数の検索条件を効率的に組み合わせます。」

   2. 「クエリの応答時間を改善するためのキャッシュ戦略を実装します。」

   3. 「インデックス マッピングを最適化して、検索パフォーマンスを高速化します。」

   4. 「インデックス マッピングを最適化して、検索パフォーマンスを高速化します。」

   5. 「クエリの応答時間を改善するためのキャッシュ戦略を実装します。」

   6. 「ブールクエリを使用して、複数の検索条件を効率的に組み合わせます。」

5. 生成のためにコンテキストを LLM に渡します。

クエリを実行して回答を取得してみましょう。

ニース。そうです。

トップに戻る

実験

今答えなければならない重要な質問があります。これらの実装に多大な労力と追加の複雑さを投資することで、何が得られましたか?

少し比較してみましょう。私たちが実装した RAG パイプラインと、私たちが行った機能強化のないベースライン ハイブリッド検索を比較したものです。小規模な一連のテストを実行して、大きな違いが見られるか確認します。ここで実装した RAG を AdvancedRAG と呼び、基本パイプラインを SimpleRAG と呼びます。

結果の要約

この表は、両方の RAG パイプラインの 5 つのテストの結果をまとめたものです。回答の詳細と品質に基づいて各方法の相対的な優位性を判断しましたが、これは完全に主観的な判断です。実際の回答はこの表の下に再現されていますので、ご参照ください。それでは、彼らの成果を見てみましょう!

SimpleRAG は質問 1 と 5 に答えることができませんでした。AdvancedRAG は質問 2、3、4 についても非常に詳しく説明しました。詳細度が増したことにより、AdvancedRAG の回答の質が優れていると判断しました。

テスト

質問

高度なRAGパフォーマンス

SimpleRAG パフォーマンス

AdvancedRAG レイテンシー

SimpleRAG レイテンシ

勝者

1

Elastic を監査するのは誰ですか?

監査人として PwC を正しく特定しました。

監査人を識別できませんでした。

11.6秒

4.4秒

アドバンスドRAG

2

2023年の総収益はいくらでしたか?

正しい収益数値を提供しました。前年度の収益に関する追加のコンテキストを含めました。

正しい収益数値を提供しました。

13.3秒

2.8秒

アドバンスドRAG

3

成長は主にどの製品に依存しますか?いくら？

Elastic Cloud が主要な推進力であることを正しく認識しました。全体的な収益コンテキストとより詳しい詳細が含まれています。

Elastic Cloud が主要な推進力であることを正しく認識しました。

14.1秒

12.8秒

アドバンスドRAG

4

従業員福利厚生プランの説明

退職金制度、健康プログラム、その他の福利厚生について包括的に説明しました。異なる年ごとの具体的な寄付金額が含まれています。

報酬、退職金制度、職場環境、Elastic Cares プログラムなどの福利厚生の概要をわかりやすく説明しました。

26.6秒

11.6秒

アドバンスドRAG

5

Elastic が買収した企業はどれですか?

レポートに記載されている最近の買収 (CmdWatch、Build Security、Optimyze) を正しくリストしました。いくつかの取得日と購入価格を提供しました。

提供されたコンテキストから関連情報を取得できませんでした。

11.9秒

2.7秒

アドバンスドRAG

テスト 1: Elastic を監査するのは誰ですか?

アドバンスドRAG

シンプルラグ

要約: SimpleRAGはPWCを監査人として特定しなかった

そうですね、それは実はかなり驚きました。これは SimpleRAG 側の検索失敗のようです。監査に関連する文書は取得されませんでした。次のテストでは難易度を少し下げてみましょう。

テスト2：2023年の総収入

アドバンスドRAG

シンプルラグ

要約: 両RAGとも正解: 2023年の総収益は1,068,989,000ドル

二人ともここにいました。AdvancedRAG がより広範囲の文書を入手したように思われますか?確かに、答えはより詳細で、前年からの情報が組み込まれています。私たちが行った機能強化を考えると、それは予想されることですが、判断するには時期尚早です。

難易度を上げてみましょう。

テスト 3: 成長は主にどの製品に依存しますか?いくら？

アドバンスドRAG

シンプルラグ

概要: 両方の RAG は、Elastic Cloud を主要な成長原動力として正しく認識しました。ただし、AdvancedRAG では、サブスクリプション収益と顧客の増加を考慮したより詳細な情報が含まれており、Elastic の他の製品についても明示的に言及されています。

テスト4: 従業員福利厚生制度の説明

アドバンスドRAG

シンプルラグ

概要: AdvancedRAG では、米国に拠点を置く従業員向けの 401K プランや、米国外の定義拠出金プランについてさらに詳しく取り上げています。また、健康と幸福の計画についても言及していますが、SimpleRAG が言及している Elastic Cares プログラムについては触れられていません。

テスト 5: Elastic が買収した企業はどれですか?

アドバンスドRAG

シンプルラグ

概要: SimpleRAG は買収に関する関連情報を取得せず、回答に失敗しました。AdvancedRAG は、レポートに記載されている主要な買収である CmdWatch、Build Security、Optimyze を正しくリストしています。

トップに戻る

まとめ

私たちのテストによると、私たちの高度な技術により、提示される情報の範囲と深さが拡大し、RAG 回答の品質が向上する可能性があるようです。

さらに、 Which companies did Elastic acquire?やWho audits Elasticなどのあいまいな表現の質問に対して、AdvancedRAG では正しく回答されましたが、SimpleRAG では正しく回答されなかったため、信頼性が向上する可能性があります。

ただし、5 件中 3 件では、ハイブリッド検索のみを組み込んだ基本的な RAG パイプラインで、重要な情報のほとんどを捉えた回答を生成できたという点に留意する価値があります。

データ準備フェーズとクエリフェーズに LLM が組み込まれているため、AdvancedRAG のレイテンシは通常、SimpleRAG の 2 ～ 5 倍になることに注意してください。これは大きなコストであるため、AdvancedRAG は、応答品質がレイテンシーよりも優先される状況にのみ適している可能性があります。

データ準備段階で Claude Haiku や GPT-4o-mini などの小型で安価な LLM を使用すると、大きなレイテンシ コストを軽減できます。回答生成用の高度なモデルを保存します。

これは Wang らの研究結果と一致しています。結果が示すように、行われた改善は比較的漸進的です。つまり、シンプルなベースライン RAG を使用すると、安価で高速でありながら、適切な最終製品にほぼ到達できます。私にとっては、それは興味深い結論です。速度と効率が重要となるユースケースでは、SimpleRAG が賢明な選択です。パフォーマンスを最大限に引き出す必要があるユースケースでは、AdvancedRAG に組み込まれたテクニックが解決策となる可能性があります。

トップに戻る

付記

プロンプト

RAG質問回答プロンプト

クエリとコンテキストに基づいて LLM に回答を生成させるためのプロンプト。

弾性クエリジェネレータプロンプト

同義語を使用してクエリを拡充し、OR 形式に変換するように要求します。

潜在的な質問ジェネレータプロンプト

潜在的な質問の生成を促し、ドキュメントのメタデータを充実させます。

HyDEジェネレータプロンプト

HyDEを使用して仮想文書を生成するためのプロンプト

ハイブリッド検索クエリのサンプル

最近の論文「検索拡張生成におけるベスト プラクティスの探求」では、 RAG のベスト プラクティスのセットに収束することを目的として、さまざまな RAG 強化手法の有効性を経験的に評価しています。

提案されたベストプラクティスのいくつか、つまり検索の品質を向上させることを目的としたベストプラクティス（センテンスチャンキング、HyDE、リバースパッキング）を実装します。

簡潔にするために、効率性の向上に重点を置いた手法(クエリの分類と要約)は省略します。

また、ここでは取り上げなかったものの、個人的には便利で興味深いと思われるいくつかのテクニック(メタデータの包含、複合マルチフィールドの埋め込み、クエリの強化) も実装します。

最後に、検索結果と生成された回答の品質がベースラインと比較して向上したかどうかを確認するための短いテストを実行します。さあ始めましょう！

RAGの概要

RAG は、外部の知識ベースから情報を取得して生成された回答を充実させることで、LLM を強化することを目的としています。ドメイン固有の情報を提供することで、LLM はトレーニング データの範囲外のユース ケースに迅速に適応できます。微調整よりも大幅にコストが安く、最新の状態に保つのも簡単になります。

RAG の品質を向上させるための対策は、通常、次の 2 つの点に重点を置いています。

1. ナレッジベースの品質と明確さを向上します。

2. 検索クエリの範囲と特定性を向上させます。

これら 2 つの対策により、LLM が関連する事実や情報にアクセスできる可能性が高まり、幻覚を起こしたり、古くなったり無関係になったりする可能性のある独自の知識を利用したりする可能性が低くなるという目標が達成されます。

方法の多様性を数文で説明するのは困難です。わかりやすくするために、すぐに実装に移りましょう。

目次

• ご紹介

  • 目次

• 設定

• ドキュメントの取り込み、処理、埋め込み

  • データインジェスト

  • 文レベル、トークン単位のチャンキング

  • メタデータの包含と生成

    • TextRankによって抽出されたキーフレーズ

    • GPT-4oによって生成される潜在的な質問

    • Spacyによって抽出されたエンティティ

  • 複合多体埋め込み

    • Elasticへのインデックス

• 猫の休憩

• 付記

  • 定義

設定

すべてのコードは Searchlabs リポジトリに あります 。

まずは第一に。次のものが必要になります:

1. 弾力性のあるクラウドの展開

2. LLM API - このノートブックでは、Azure OpenAI 上の GPT-4o デプロイメントを使用しています。

3. Python バージョン 3.12.4 以降

main.ipynb ノートブックからすべてのコードを実行します。

リポジトリを git clone し、supporting-blog-content/advanced-rag-techniques に移動して、次のコマンドを実行します。

完了したら、 .envを作成します。ファイルを開き、次のフィールドに入力します ( .env.exampleで参照されます)。有益なコメントをくれた共著者の Claude-3.5 に感謝します。

次に、取り込むドキュメントを選択し、ドキュメント フォルダーに配置します。この記事では、 Elastic NV Annual Report 2023 を使用します。これは非常に難しくて密度の高いドキュメントであり、RAG テクニックのストレス テストに最適です。

準備が整いましたので、摂取に移りましょう。main.ipynbを開き、最初の 2 つのセルを実行して、すべてのパッケージをインポートし、すべてのサービスを初期化します。

トップに戻る

ドキュメントの取り込み、処理、埋め込み

データインジェスト

• 個人的なメモ: LlamaIndex の便利さに驚いています。LLM や LlamaIndex が登場する前の昔、さまざまな形式のドキュメントを取り込むには、あらゆる場所から難解なパッケージを収集する、骨の折れる作業でした。今では、関数呼び出しは 1 つに減りました。野生。

SimpleDirectoryReaderはdirectory_path.内のすべてのドキュメントをロードします。 .pdfファイルの場合は、ドキュメント オブジェクトのリストを返します。このリストは、操作しやすいように Python 辞書に変換します。

各辞書には、 textフィールドにキー コンテンツが含まれています。また、ページ番号、ファイル名、ファイル サイズ、タイプなどの便利なメタデータも含まれています。

トップに戻る

文レベル、トークン単位のチャンキング

最初にやるべきことは、ドキュメントを標準的な長さのチャンクに削減することです (一貫性と管理性を確保するため)。埋め込みモデルには、固有のトークン制限 (処理できる最大入力サイズ) があります。トークンはモデルが処理するテキストの基本単位です。情報の損失（コンテンツの切り捨てや省略）を防ぐために、これらの制限を超えないテキストを提供する必要があります（長いテキストを短いセグメントに分割する）。

チャンク化はパフォーマンスに大きな影響を与えます。理想的には、各チャンクは自己完結的な情報を表し、単一のトピックに関するコンテキスト情報をキャプチャします。チャンク化の方法には、文書を単語数で分割する単語レベルのチャンク化と、LLM を使用して論理ブレークポイントを識別するセマンティック チャンク化があります。

単語レベルのチャンキングは安価で高速かつ簡単ですが、文が分割され、コンテキストが壊れるリスクがあります。セマンティック チャンキングは、特に 116 ページの Elastic 年次レポートのようなドキュメントを扱う場合には、時間がかかり、コストも高くなります。

中道的なアプローチを選択しましょう。文レベルのチャンキングは依然としてシンプルですが、単語レベルのチャンキングよりもコンテキストをより効果的に保持でき、コストも大幅に削減され、処理速度も速くなります。さらに、周囲のコンテキストの一部をキャプチャし、段落を分割することによる影響を軽減するために、スライディング ウィンドウを実装します。

Chunkerクラスは埋め込みモデルのトークナイザーを受け取り、テキストをエンコードおよびデコードします。ここで、20 個のトークンが重なり合う、それぞれ 512 個のトークンのチャンクを構築します。これを実行するには、テキストを文に分割し、それらの文をトークン化してから、トークン制限に違反することなく追加できなくなるまで、トークン化された文を現在のチャンクに追加します。

最後に、埋め込みのために文章を元のテキストにデコードし、 original_textというフィールドに保存します。チャンクはchunkというフィールドに保存されます。ノイズ（つまり、無駄なドキュメント）を減らすために、長さが 50 トークン未満のドキュメントは破棄されます。

これをドキュメント上で実行してみましょう。

そして、次のようなテキストのチャンクが返されます。

トップに戻る

メタデータの包含と生成

ドキュメントをチャンクに分割しました。次は、データを充実させる段階です。追加のメタデータを生成または抽出したい。この追加のメタデータは、検索パフォーマンスに影響を与え、強化するために使用できます。

ドキュメントのリスト (Python 辞書) とプロセッサ関数のリストを受け取る役割を持つDocumentEnricherクラスを定義します。これらの関数はドキュメントのoriginal_text列を実行し、その出力を新しいフィールドに保存します。

まず、 TextRankを使用してキーフレーズを抽出します。TextRank は、単語間の関係に基づいて重要度をランク付けすることにより、テキストから主要なフレーズと文を抽出するグラフベースのアルゴリズムです。

次に、 GPT-4oを使用してpotential_questionsを生成します。

最後に、 Spacy を使用して エンティティを抽出します 。

それぞれのコードは非常に長くて複雑なので、ここで再現することは控えます。ご興味があれば、以下のコード サンプルにファイルがマークされています。

データ拡充を実行してみましょう:

結果を見てみましょう:

TextRankによって抽出されたキーフレーズ

これらのキーフレーズは、チャンクの中核トピックの代わりとなります。クエリがサイバーセキュリティに関係する場合、このチャンクのスコアは向上します。

GPT-4oによって生成される潜在的な質問

これらの潜在的な質問はユーザーのクエリと直接一致する可能性があり、スコアの向上につながります。GPT-4o に、現在のチャンクにある情報を使用して回答できる質問を生成するように指示します。

Spacyによって抽出されたエンティティ

これらのエンティティはキーフレーズと同様の目的を果たしますが、キーフレーズ抽出では見逃される可能性のある組織や個人の名前を取得します。

トップに戻る

複合多体埋め込み

追加のメタデータでドキュメントを充実させたので、この情報を活用して、より堅牢でコンテキストを認識した埋め込みを作成できます。

プロセスの現在のポイントを確認しましょう。各ドキュメントには 4 つの興味深いフィールドがあります。

各フィールドはドキュメントのコンテキストに関する異なる視点を表し、LLM が重点を置くべき重要な領域を強調する可能性があります。

計画としては、これらの各フィールドを埋め込み、複合埋め込みと呼ばれる埋め込みの加重合計を作成することです。

運が良ければ、この複合埋め込みにより、検索動作を制御する別の調整可能なハイパーパラメータが導入されるだけでなく、システムがよりコンテキストを認識できるようになります。

まず、main.ipynb ノートブックの先頭にインポートされたローカルに定義された埋め込みモデルを使用して、各フィールドを埋め込み、各ドキュメントを更新します。

各埋め込み関数は埋め込みのフィールドを返します。これは、 _embeddingという接尾辞が付いた元の入力フィールドです。

複合埋め込みの重みを定義しましょう。

重み付けにより、ユースケースとデータの品質に基づいて各コンポーネントに優先順位を割り当てることができます。直感的に言えば、これらの重み付けの大きさは、各コンポーネントの意味的価値に依存します。チャンクテキスト自体が圧倒的に豊富なので、重み付けを 70% に割り当てます。エンティティは組織名や人名のリストだけなので最も小さいので、重み付けを 5% に割り当てます。これらの値の正確な設定は、ユースケースごとに経験的に決定する必要があります。

最後に、重み付けを適用し、複合埋め込みを作成する関数を記述しましょう。スペースを節約するために、コンポーネントの埋め込みもすべて削除します。

これで書類の処理は完了です。次のようなドキュメント オブジェクトのリストが作成されました。

Elasticへのインデックス

ドキュメントを Elastic Search に一括アップロードしてみましょう。この目的のために、私はずっと前にelastic_helpers.pyで Elastic Helper 関数のセットを定義しました。これは非常に長いコードなので、関数呼び出しに注目してみましょう。

es_bulk_indexer.bulk_upload_documents Elasticsearch の便利な動的マッピングを活用して、辞書オブジェクトの任意のリストで動作します。

Kibana にアクセスして、すべてのドキュメントがインデックスされていることを確認します。全部で224個あるはずです。こんなに大きな文書にしては悪くないですね!

トップに戻る

猫の休憩

ちょっと休憩しましょう。記事がちょっと重いのはわかっています。私の猫を見てください:

愛らしい。帽子がなくなってしまったので、彼女がそれを盗んでどこかに隠したのではないかと半分疑っています :(

ここまで来られたことおめでとうございます :)

パート 2では、RAG パイプラインのテストと評価についてご紹介します。

付記

定義

1. 文のチャンキング

• RAG システムでテキストをより小さな意味のある単位に分割するために使用される前処理手法。

• プロセス：

  1. 入力: 大きなテキストブロック（例: 文書、段落）

  2. 出力: 小さなテキストセグメント (通常は文または小さな文のグループ)

• 目的：

  • きめ細やかでコンテキストに特化したテキストセグメントを作成する

  • より正確なインデックス作成と検索が可能

  • RAGシステムで取得した情報の関連性を向上

• 特徴:

  • セグメントは意味的に意味がある

  • 独立してインデックスを作成し、検索できる

  • 多くの場合、独立した理解可能性を確保するためにある程度の文脈が保持される

• メリット：

  • 検索精度の向上

  • RAGパイプラインのより集中的な拡張を可能にします

2. HyDE（仮想文書埋め込み）

• LLM を使用して、RAG システムでのクエリ拡張用の仮想ドキュメントを生成する手法。

• プロセス：

  1. LLMへの入力クエリ

  2. LLMはクエリに答える仮説文書を生成する

  3. 生成されたドキュメントを埋め込む

  4. ベクトル検索に埋め込みを使用する

• 主な違い:

  • 従来のRAG: クエリとドキュメントを一致させる

  • HyDE: 文書を文書と照合する

• 目的：

  • 特に複雑または曖昧なクエリの検索パフォーマンスを向上します

  • 短いクエリよりも豊富な意味コンテキストをキャプチャする

• メリット：

  • LLMの知識を活用してクエリを拡張する

  • 検索された文書の関連性が向上する可能性がある

• 課題:

  • 追加のLLM推論が必要となり、レイテンシとコストが増加する

  • パフォーマンスは生成された仮想文書の品質に依存する

3. 逆パッキング

• RAG システムで、検索結果を LLM に渡す前に並べ替えるために使用される手法。

• プロセス：

  1. 検索エンジン (Elasticsearch など) は、関連性の高い順にドキュメントを返します。

  2. 順序は逆になり、最も関連性の高いドキュメントが最後に配置されます。

• 目的：

  • LLM の新しさバイアスを利用します。LLM は、それぞれのコンテキストにおける最新の情報に重点を置く傾向があります。

  • LLM のコンテキスト ウィンドウ内で最も関連性の高い情報が「最新」であることを保証します。

• 例:元の順序: [最も関連性の高い順、2番目に関連性の高い順、3番目に関連性の高い順、...] 逆の順序: [...、3番目に関連性の高い順、2番目に関連性の高い順、最も関連性の高い順]

4. クエリの分類

• クエリに RAG が必要かどうか、または LLM によって直接回答できるかどうかを判断して、RAG システムの効率を最適化する手法。

• プロセス：

  1. 使用中の LLM に固有のカスタム データセットを開発する

  2. 特殊な分類モデルをトレーニングする

  3. モデルを使用して受信したクエリを分類する

• 目的：

  • 不要なRAG処理を回避することでシステム効率を向上

  • 最も適切な応答メカニズムにクエリを直接送信する

• 要件：

  • LLM固有のデータセットとモデル

  • 精度を維持するための継続的な改良

• メリット：

  • 単純なクエリの計算オーバーヘッドを削減

  • 非RAGクエリの応答時間を改善する可能性がある

5. 要約

• RAG システムで検索された文書を圧縮する手法。

• プロセス：

  1. 関連文書を取得する

  2. 各文書の簡潔な要約を生成する

  3. RAG パイプラインでは完全なドキュメントではなく要約を使用する

• 目的：

  • 重要な情報に焦点を当ててRAGのパフォーマンスを向上させる

  • 関連性の低いコンテンツからのノイズや干渉を減らす

• メリット：

  • LLM回答の関連性が向上する可能性がある

  • コンテキスト制限内でより多くのドキュメントを含めることができます

• 課題:

  • 要約時に重要な詳細が失われるリスク

  • 要約生成のための追加の計算オーバーヘッド

6. メタデータの包含

• 追加のコンテキスト情報でドキュメントを充実させる手法。

• メタデータの種類:

  • キーフレーズ

  • タイトル

  • 日付

  • 著者詳細

  • 宣伝文句

• 目的：

  • RAGシステムで利用可能なコンテキスト情報を増やす

  • LLMに文書の内容と関連性をより明確に理解させる

• メリット：

  • 検索精度が向上する可能性がある

  • LLMの文書有用性を評価する能力を強化する

• 実装：

  • 文書の前処理中に実行できる

  • 追加のデータ抽出または生成手順が必要になる場合があります

7. 複合多体埋め込み

• 異なるドキュメント コンポーネントごとに個別の埋め込みを作成する RAG システム用の高度な埋め込み手法。

• プロセス：

  1. 関連するフィールド（例：タイトル、キーフレーズ、宣伝文句、メインコンテンツ）を特定する

  2. 各フィールドごとに個別の埋め込みを生成する

  3. これらの埋め込みを結合または保存して検索に使用します

• 標準的なアプローチとの違い:

  • 従来型: ドキュメント全体の単一の埋め込み

  • 複合: さまざまなドキュメントの側面に対応する複数の埋め込み

• 目的：

  • よりニュアンス豊かで文脈を考慮した文書表現を作成する

  • 文書内のより多様なソースから情報を取得する

• メリット：

  • 曖昧なクエリや多面的なクエリのパフォーマンスが向上する可能性があります

  • 検索時にさまざまな文書の側面をより柔軟に重み付けできます

• 課題:

  • 埋め込みストレージと検索プロセスの複雑さが増す

  • より洗練されたマッチングアルゴリズムが必要になる場合があります

8. クエリエンリッチメント

• 元のクエリを関連用語で拡張し、検索範囲を広げる手法。

• プロセス：

  1. 元のクエリを分析する

  2. 同義語や意味的に関連するフレーズを生成する

  3. クエリに以下の追加用語を追加します

• 目的：

  • 文書コーパス内の潜在的な一致の範囲を拡大する

  • 特定の言語や専門用語を含むクエリの検索パフォーマンスを向上

• メリット：

  • 元の検索語句と完全に一致しない関連文書を取得する可能性がある

  • クエリとドキュメント間の語彙の不一致を克服するのに役立ちます

• 課題:

  • 慎重に実装しないとクエリドリフトのリスクがある

  • 検索プロセスにおける計算オーバーヘッドが増加する可能性がある

トップに戻る

ベクトル検索は、特にAIや機械学習のフィールドで、類似性検索の方法に革命をもたらしています。ベクトル埋め込みモデルの採用が増えるにつれ、何百万もの高次元ベクトルを効率的に検索する機能が重要になっています。

ベクトルデータベースの実現方法に関して、ElasticとOpenSearchは著しく異なるアプローチを採用しています。Elasticは、Apache LuceneとElasticsearchがベクトル検索アプリケーションにおけるトップクラスの選択肢となるべく、これらの最適化に多額の投資を行ってきました。対照的に、OpenSearchは焦点を広げ、他のベクトル検索実装を統合し、Luceneの対象範囲を超えて模索を行っています。Elasticは戦略的にLuceneへと焦点を合わせており、弊社版Elasticsearchにおいて高度に統合されたサポートを提供できるため、各コンポーネントが他のコンポーネントの機能を補完および増幅できるという特徴が強化されています。

このブログでは、Elasticsearch 8.14とOpenSearch 2.14の詳細な比較を、異なる構成とベクトルエンジンを考慮して紹介します。このパフォーマンス分析では、Elasticsearch がベクトル検索操作に優れたプラットフォームであることが証明されました。今後追加予定の機能によりその差はさらに拡大するでしょう。OpenSearchと比較すると、すべてのベンチマークトラックで優れた結果を示し、平均で2倍から12倍高速なパフォーマンスを実現しました。これは、so_vector（2Mベクトル、768D）、openai_vector（2.5Mベクトル、1536D）、およびdense_vector（10Mベクトル、96D）を含む、さまざまなベクトル量と次元を使用したシナリオ全体で行われました。これらはすべて、Google Cloudで必要なインフラストラクチャーをプロビジョニングするためのTerraformスクリプトと、テストを実行するためのKubernetesマニフェストと共に、このリポジトリで利用可能です。

このブログで詳述されている結果は、以前に公開され、サードパーティによって検証された調査の結果を補完するものであり、最も一般的な検索分析操作（テキストクエリ、並べ替え、範囲、日付ヒストグラム、用語フィルタリング）では、ElasticsearchがOpenSearchよりも40%–140%高速であることが示されています。これに、別の差別化要因であるベクトル検索を追加します。

デフォルトの設定で最大12倍高速

4つのベクトルデータセットにわたる重点的なベンチマークには、さまざまなサイズ、次元、構成を考慮した近似KNN検索と正確なKNN検索の両方が含まれ、合計40.189.820のキャッシュされていない検索要求がありました。結果：Elasticsearchはベクトル検索においてOpenSearchより最大12倍高速であるため、必要な計算リソースが少なくなります。

図1：ElasticsearchおよびOpenSearchにおけるさまざまなタスクについて、ANNと厳密なKNNをグループ化した図。

knn-10-100のようなグループは、およびのKNN検索を意味します。HNSWベクトル検索では、はクエリベクトルから取得する最近傍の数を決定します。結果として検索する類似ベクトルの数を指定します。は各セグメントで取得する候補ベクトルの数を設定します。候補の数を増やすと精度は向上しますが、より多くの計算リソースが必要になります。

また、さまざまな量子化手法とエンジン固有の最適化を活用してテストしました。各トラック、タスク、ベクトルエンジンの詳細な結果を以下に示します。

厳密なKNNと近似KNN

さまざまなデータセットとユースケースを扱う場合、ベクトル検索に適したアプローチは異なります。このブログでは、knn-10-100のようにknn-*と記載されているすべてのタスクは近似KNNを使用し、script-score-*は正確なKNNを参照していますが、それらの違いは何で、なぜ重要なのでしょうか。

基本的に、より大規模なデータセットを扱う場合、優れた拡張性のある近似K-最近傍法（ANN）が推奨されます。フィルタリング処理が必要な場合のある、より小規模なデータセットの場合、厳密なKNN法が最適です。

正確なKNNでは、ブルートフォース法を使用して、データセット内の1つのベクトルと他のすべてのベクトルとの間の距離を計算します。次に、これらの距離を順位付けして、の最も近い近傍を見つけます。この方法では正確な一致が保証されますが、大規模で高次元のデータセットでは拡張性の課題があります。ただし、正確なKNNが必要なケースは数多くあります。

• 再スコアリング：語彙検索または意味検索の後にベクトルベースの再スコアリングを行うシナリオでは、正確なKNNが不可欠です。例えば、製品検索エンジンでは、テキストクエリ（キーワードやカテゴリなど）に基づいて最初の検索結果をフィルタリングし、フィルタリングされたアイテムに関連付けられたベクトルを使用して、より正確な類似性評価を行うことができます。

• パーソナライゼーション：多数のユーザーを扱う際、それぞれが比較的少数（100万個など）の個別のベクトルで表される場合、ユーザー固有のメタデータ（例：user_id）でインデックスをソートし、ベクトルを使用したブルートフォーススコアリングが効率的になります。このアプローチにより、個々のユーザーの好みに合わせた正確なベクトル比較に基づいて、パーソナライズされたレコメンデーションやコンテンツ配信が可能になります。

したがって、厳密なKNNでは、ベクトルの類似性に基づく最終的な順位付けと推奨が正確なものとなり、ユーザーの好みに合わせて調整されるようになります。

一方、近似KNN（またはANN）は、特に大規模で高次元のデータセットにおいて、厳密なKNNよりも高速かつ効率的にデータ検索を行う方法を採用しています。ANNは、クエリとすべての点の間の正確な最も近い距離を測定することにより計算やスケーリングの問題につながるブルートフォース的なアプローチではなく、特定の手法を使用してデータセットにおける検索可能なベクトルのインデックスと次元を効率的に再構築します。これにより若干の不正確さが生じる可能性がありますが、検索処理速度が大幅に向上するため、大規模なデータセットを処理するための効果的な代替手段となります。

このブログでは、knn-*として記載されているすべてのタスクはknn-10-100のように近似KNNを使用し、script-score-*は正確なKNNを参照します。

テスト手法

ElasticsearchとOpenSearchはBM25検索操作のAPIにおいては似ていますが、後者が前者のフォークであるため、フォーク後に導入されたベクトル検索には当てはまりません。OpenSearchはアルゴリズムに関してElasticsearchとは異なるアプローチを取り、luceneとは別にnmslibとfaissの2つのエンジンを導入しました。それぞれに特定の構成と制限があります（例：OpenSearchのnmslibでは、多くのユースケースで不可欠な機能であるフィルターが許可されていません）。

3つのエンジンはいずれも、階層型ナビゲート可能スモールワールド（HNSW）アルゴリズムを使用しています。このアルゴリズムは近似最近傍を検索するのに効率的で、特に高次元データを扱う際に強力です。faissは第2のアルゴリズムivfもサポートしていますが、データセットの事前トレーニングが必要なため、ここではHNSWのみに焦点を当てます。HNSWの中心的な考え方は、データを複数の接続されたグラフのレイヤーに整理し、各レイヤーがデータセットの異なる粒度を表すことです。検索は最も粗いビューの最上位レイヤーから始まり、ベースレベルに到達するまで、より細かいレイヤーへと進みます。

公平なテストの場を確保するために、両方の検索エンジンは制御された環境内で同一の条件下でテストされました。適用された方法は、Elasticsearch、OpenSearch、Rally専用のノードプールを使用した以前に公開されたパフォーマンス比較と似ています。terraformスクリプトは（すべてのソースとともに）Kubernetesクラスターを提供するために利用可能です。

• Elasticsearch用の3台のe2-standard-32マシン（128GB RAM、32CPU）を持つ1つのNodeプール

• OpenSearch用の3台のe2-standard-32マシン（128GB RAM、32CPU）を持つ1つのNodeプール

• Rally用の2台のt2a-standard-16マシン（64GB RAM、16CPU）を持つ1つのNodeプール

各「トラック」（またはテスト）を、異なるエンジン、異なる設定、異なるベクトルタイプを含む各設定に対して10回実行しました。各トラックには、トラックにより1000回から10000回まで繰り返すタスクがあります。ネットワークのタイムアウトなどでトラック内のタスクの1つが失敗した場合はすべてのタスクを無視したため、すべての結果は問題なく開始して終了したトラックを表します。すべてのテスト結果は統計的に検証されており、改善が偶然ではないことが保証されています。

詳細な調査結果

平均レイテンシではなく99パーセンタイルを使用して比較するのはなぜでしょうか。特定の地域の平均住宅価格の例を想像してみましょう。平均価格によれば高価な地域となっていても、よく調べてみると、ほとんどの住宅の価値ははるかに低く、わずかな高級物件が平均値を膨らませていることがわかるかもしれません。これは、平均価格がその地域の住宅価値の全範囲を正確に表現できない可能性があることを示しています。同じようなことが、応答時間についても言えます。平均値が重要な問題を隠してしまうことがあるのです。

タスク

• 近似KNN（k:10 n:50）

• 近似KNN（k:10 n:100）

• 近似KNN（k:100 n:1000）

• 近似KNN（k:10 n:50、キーワードフィルター併用）

• 近似KNN（k:10 n:100、キーワードフィルター併用）

• 近似KNN（k:100 n:1000、キーワードフィルター併用）

• 近似KNN（k:10 n:100、インデックス作成と同時実行）

• 厳密なKNN（スクリプトスコア）

ベクトルエンジン

• lucene （ElasticsearchとOpenSearchにおいて、両方ともバージョン9.10）

• faiss （OpenSearchにおいて）

• nmslib （OpenSearchにおいて）

ベクトルの種類

• hnsw （ElasticsearchとOpenSearchにおいて）

• int8_hnsw Elasticsearch内（自動8ビット量子化を備えたHNSW：リンク）

• sq_fp16 hnsw OpenSearch内（自動16ビット量子化を備えたHNSW：リンク）

すぐに使える同時セグメント検索

ご存知かと思いますが、LuceneはJavaで記述された高性能なテキスト検索エンジンライブラリであり、Elasticsearch、OpenSearch、Solrなどの多くの検索プラットフォームのバックボーンとして機能します。Luceneは本質的に、データをセグメントに整理します。セグメントは本質的には自己完結型のインデックスであり、Luceneがより効率的に検索を実行できるようにします。そのため、Luceneベースの検索エンジンに検索を発行すると、検索はそれらのセグメントで順次または並行して実行されます。

OpenSearchは同時セグメント検索をオプションのフラグとして導入しましたが、デフォルトでは使用されません。特別なインデックス設定index.search.concurrent_segment_search.enabledを使用して有効にする必要があります。詳細はこちらをご覧ください。ただし、いくつかの制限があります。

一方、Elasticsearchはすぐに使用できる状態でセグメントを同時に検索するため、このブログでの比較では、さまざまなベクトルエンジンとベクトルタイプに加えて、さまざまな構成も考慮に入れます。

• Elasticsearch ootb：同時セグメント検索検索を備えたデフォルト設定のElasticsearch

• OpenSearch ootb：同時セグメント検索が有効でない状態

• OpenSearch css：同時セグメント検索が有効な状態

それでは、テストした各ベクトルデータセットの詳細な結果を見てみましょう。

250万ベクトル、1536次元（openai_vector）

最も単純なトラックで、かつ次元の点でも最大のopenai_vectorから始めます。これは、OpenAIのtext-embedding-ada-002モデルを使用して生成された埋め込みで強化されたNQデータセットを使用します。これは、近似KNNのみをテストし、タスクが5つしかないため、最も単純です。スタンドアロン（インデキシングなし）でのテストと、インデキシングと並行してのテストが可能で、単一クライアントと8つの同時クライアントを使用します。

タスク

• standalone-search-knn-10-100-multiple-clients：8クライアントで250万ベクトルを同時に検索、k: 10およびn:100

• standalone-search-knn-100-1000-multiple-clients：8クライアントで250万ベクトルを同時に検索、k: 100およびn:1000

• standalone-search-knn-10-100-single-client：単一クライアントで250万ベクトルを検索、k: 10およびn:100

• standalone-search-knn-100-1000-single-client：単一クライアントで250万ベクトルを検索、k: 100およびn:1000

• parallel-documents-indexing-search-knn-10-100：250万ベクトルを検索しながら追加の10万ドキュメントをインデキシング、k:10およびn:100

p99の平均パフォーマンスの概要は次のとおりです。

ここで、 :10、:100でベクトル検索とインデックス作成（つまり読み取り+書き込み）を実行した場合、ElasticsearchはOpenSearchよりも3～8倍高速であり、kとnが同一のインデックス作成なしの場合には2～3倍高速であることがわかりました。:100 および:1000（standalone-search-knn-100-1000-single-clientおよびstandalone-search-knn-100-1000-multiple-clients）の場合、Elasticsearchは平均して OpenSearch より2倍から7倍高速です。

詳細な結果には、比較された具体的なケースとベクトルエンジンが示されています。

リコール

knn-recall-10-100

knn-recall-100-1000

Elasticsearch-8.14.0@lucene-hnsw

0.969485

0.995138

Elasticsearch-8.14.0@lucene-int8_hnsw

0.781445

0.784817

OpenSearch-2.14.0@lucene-hnsw

0.96519

0.995422

OpenSearch-2.14.0@faiss

0.984154

0.98049

OpenSearch-2.14.0@faiss-sq_fp16

0.980012

0.97721

OpenSearch-2.14.0@nmslib

0.982532

0.99832

1,000万ベクトル、96次元（dense_vector）

dense_vectorには、1,000万ベクトルと96次元があります。これはYandex DEEP1B画像データセットに基づいています。データセットは、「sample data」ファイルlearn.350M.fbinの最初の1,000万ベクトルから作成されます。検索操作では、「query data」ファイルクエリのベクトルを使用します。public.10K.fbin。

ElasticsearchとOpenSearchの両方がこのデータセットで非常に優れたパフォーマンスを発揮します。特に、通常読み取り専用のインデックスで実行されるforce mergeの後では顕著です。これは、インデックスをデフラグして検索用の単一の「テーブル」を作成するのと似ています。

タスク

各タスクは100リクエストでウォームアップされ、その後1000リクエストが測定されます。

• knn-search-10-100: 1000万ベクトルを検索、k: 10およびn:100

• knn-search-100-1000：1000万ベクトルを検索、k: 100およびn:1000

• knn-search-10-100-force-merge：強制マージ後の1000万ベクトルの検索、k: 10およびn:100

• knn-search-100-1000-force-merge：強制マージ後の1000万ベクトルの検索、k: 100およびn:1000

• knn-search-100-1000-concurrent-with-indexing：1000万ベクトルを検索しながらデータセットの5%を更新、k: 100およびn:1000

• script-score-query：特定の2000ベクトルの正確なKNN検索。

ElasticsearchとOpenSearchはどちらも近似KNNに対して良好なパフォーマンスを示しました。knn-search-100-1000-force-mergeおよびknn-search-10-100-force-mergeでインデックスが結合されている場合（つまり、セグメントが1つだけの場合）、nmslibおよびfaissを使用すると、いずれも約15ミリ秒で非常に近い値であるにもかかわらず、OpenSearchのパフォーマンスは他よりも優れています。

ただし、インデックスに複数のセグメントがある場合（インデックスがドキュメントの更新を受け取る典型的な状況）において、knn-search-10-100とknn-search-100-1000では、Elasticsearchは遅延を約7ミリ秒と16ミリ秒に保ちますが、他のすべてのOpenSearchエンジンはより遅くなります。

また、インデックスが検索され、同時に書き込まれる場合（knn-search-100-1000-concurrent-with-indexing）、Elasticsearchはレイテンシを15ミリ秒以下に保守し（13.8ミリ秒）、OpenSearchの出荷時（49.3ミリ秒）よりも4倍近く高速であり、同時セグメント検索が有効な場合でも（17.9ミリ秒）、依然として高速ですが、有意差があるほどではありません。

正確なKNNに関しては、その差はさらに大きくなります。Elasticsearch は OpenSearch よりも6 倍高速です（約 260 ミリ秒対約 1600 ミリ秒）。

リコール

knn-recall-10-100

knn-recall-100-1000

Elasticsearch-8.14.0@lucene-hnsw

0.969843

0.996577

Elasticsearch-8.14.0@lucene-int8_hnsw

0.775458

0.840254

OpenSearch-2.14.0@lucene-hnsw

0.971333

0.996747

OpenSearch-2.14.0@faiss

0.9704

0.914755

OpenSearch-2.14.0@faiss-sq_fp16

0.968025

0.913862

OpenSearch-2.14.0@nmslib

0.9674

0.910303

200万ベクトル、768次元（so_vector）

このトラック、so_vector、は2022年4月21日にダウンロードされたStackOverflowの投稿のダンプから派生しています。質問文書のみが含まれており、回答を表す文書はすべて削除されています。各質問タイトルは、文変換モデルmulti-qa-mpnet-base-cos-v1を使用してベクトルにエンコードされました。このデータセットには最初の200万件の質問が含まれています。

前のトラックとは異なり、ここでの各ドキュメントには、フィルタリングとハイブリッド検索を備えた近似KNNなどのテスト機能をサポートするためのベクトル以外のフィールドも含まれています。OpenSearchのnmslibはフィルターをサポートしていないため、このテストには含まれていません。

タスク

各タスクは100件のリクエストに対してウォームアップされ、その後100件のリクエストが測定されます。テストには16種類の検索タイプ*2つの異なるk値*3つの異なるn値が含まれているため、簡潔にするためにタスクがグループ化されていることに注意してください。

• knn-10-50：フィルターなしで200万ベクトルを検索、k:10およびn:50

• knn-10-50-filtered：200万ベクトルをフィルターを使用して検索、k:10およびn:50

• knn-10-50-after-force-merge：200万ベクトルを強制マージ後にフィルターを使用して検索、k:10およびn:50

• knn-10-100：フィルターなしで200万ベクトルを検索、k:10およびn:100

• knn-10-100-filtered：200万ベクトルをフィルターを使用して検索、k:10およびn:100

• knn-10-100-after-force-merge：200万ベクトルを強制マージ後にフィルターを使用して検索、k:10およびn:100

• knn-100-1000：フィルターなしで200万ベクトルを検索、k:100およびn:1000

• knn-100-1000-filtered：200万ベクトルをフィルターを使用して検索、k:100およびn:1000

• knn-100-1000-after-force-merge：200万ベクトルを強制マージ後にフィルターを使用して検索、k:100およびn:1000

• exact-knn：フィルターあり、フィルターなしの正確なKNN検索。

このテストでは、ElasticsearchはOpenSearchよりも一貫して高速であり、OpenSearchの方が高速なのは2つのケースのみで、その差はそれほど大きくありません（knn-10-100とknn-100-1000）。knn-10-50、knn-10-100、knn-100-1000をフィルターと組み合わせて使用するタスクでは、最大7倍（112ミリ秒対803ミリ秒）の差が見られます。

当然ながら、knn-10-50-after-force-merge、knn-10-100-after-force-merge、knn-100-1000-after-force-mergeで証明されているように、両方のソリューションのパフォーマンスは「強制マージ」後に均等になるようです。これらのタスクでは、 faissの方が高速です。

Exact KNNのパフォーマンスは今回も大きく異なり、ElasticsearchはOpenSearchより13倍高速です（約385ミリ秒対約5262ミリ秒）。

リコール

knn-recall-10-100

knn-recall-100-1000

knn-recall-10-50

Elasticsearch-8.14.0@lucene-hnsw

1

1

1

Elasticsearch-8.14.0@lucene-int8_hnsw

1

0.986667

1

OpenSearch-2.14.0@lucene-hnsw

1

1

1

OpenSearch-2.14.0@faiss

1

1

1

OpenSearch-2.14.0@faiss-sq_fp16

1

1

1

OpenSearch-2.14.0@nmslib

0.9674

0.910303

0.976394

ElasticsearchとLuceneが明確な勝者に

Elasticでは、Apache LuceneとElasticsearchを絶え間なく革新し、RAG（Retrieval-Augmented Generation）を含む検索および取得のユースケースに最適なベクトルデータベースを提供できるようにしています。最近の進歩により、パフォーマンスが大幅に改善され、ベクトル検索が以前よりも高速かつスペース効率的になりました。これはLucene 9.10からの成果を基に構築されています。このブログでは、最新バージョンを比較すると、ElasticsearchがOpenSearchよりも最大12倍高速であることを示す調査を紹介しました。

両方の製品が同じバージョンのLucene（Elasticsearch 8.14リリースノートおよびOpenSearch2.14 リリースノート）を使用していることは注目に値します。

Elasticのイノベーションのペースは、オンプレミスおよびElastic Cloudのお客様だけでなく、ステートレスプラットフォームを使用しているお客様にもさらに多くの成果をもたらします。int4へのスカラー量子化のサポートなどの機能は、int8のテストと同様に、顧客が再現率を大幅に低下させることなくこれらの手法を利用できるように、厳格なテストを経て提供されます。

AIおよび機械学習アプリケーションの急増により、ベクトル検索の効率は現代の検索エンジンでは交渉の余地のない機能になりつつあります。大量で複雑なベクトルデータの要求に対応できる強力な検索エンジンを探している組織にとって、Elasticsearchは決定的な答えです。

確立されたプラットフォームを拡張する場合でも、新しいプロジェクトを開始する場合でも、ベクトル検索のニーズに合わせてElasticsearchを統合することは、具体的かつ長期的なメリットをもたらす戦略的な動きです。実証済みのパフォーマンス上の優位性を備えたElasticsearchは、検索における次のイノベーションの波を支える態勢が整っています。

まさにここでベクター検索エンジンが活躍します。同じテキストをインデックス化して、そのテキストが表す意味と、類似または関連する意味を持つ他の概念との関係の両方に基づいて検索できるようにすることができます。

このブログでは、ベクトルがテキストの意味を伝えるための優れた数学的概念である理由について簡単に触れたいと思います。次に、近隣ベクトルの検索、つまり類似の意味を持つベクトルの検索と、それらのスコア付けの方法について、Elasticsearch がサポートするさまざまな類似性テクニックについて詳しく説明します。

ベクトル埋め込みとは何ですか？

この記事では、ベクトル埋め込みの複雑な部分については詳しく説明しません。このトピックをさらに詳しく調べたい場合、または続行する前に入門書が必要な場合は、次のガイドを確認することをお勧めします。

簡単に言えば、ベクトル埋め込みは機械学習プロセスを通じて得られる（例えばあらゆる種類の非構造化入力データ (生のテキスト、画像、ビデオ、音声など) を、意味と関係性を持つ数値データに変換する AI (人工知能) です。非構造化データの種類によって、各データの種類を「理解」するようにトレーニングされたさまざまな種類の機械学習モデルが必要です。

各ベクトルは、特定のデータ部分を多次元空間内の点として配置し、その位置はモデルがデータを特徴付けるために使用する一連の機能を表します。次元の数は機械学習モデルによって異なりますが、通常は数百から数千の範囲です。たとえば、 OpenAI Embeddings モデルは1536 次元を誇りますが、 Cohere Embeddings モデルは382 から 4096 次元の範囲になります。Elasticsearch の dense_vector フィールド タイプは、最新リリース時点で最大 4096 次元をサポートします。

ベクトル埋め込みの本当の特徴は、同様の意味を共有するデータ ポイントが空間内で互いに接近していることです。もう 1 つの興味深い点は、ベクトル埋め込みがデータ ポイント間の関係を捉えるのにも役立つことです。

ベクトルをどのように比較するのでしょうか?

非構造化データは機械学習モデルによって、多数の次元に沿ったデータの類似性を捉えるベクトル埋め込みに細分化されることがわかったので、次にそれらのベクトルのマッチングがどのように機能するかを理解する必要があります。答えは非常に簡単であることがわかりました。

互いに近いベクトル埋め込みは、意味的に類似したデータ部分を表します。したがって、ベクトル データベースをクエリする場合、検索入力 (画像、テキストなど) は、すべての非構造化データのインデックス作成に使用されたのと同じ機械学習モデルを使用して、まずベクトル埋め込みに変換され、最終的な目標はそのクエリ ベクトルに最も近い隣接ベクトルを見つけることです。したがって、必要なのは、クエリ ベクトルと、データベースにインデックスが付けられた既存のすべてのベクトルとの間の「距離」または「類似性」を測定する方法を見つけることだけです。とても簡単です。

距離、類似性、スコアリング

幸いなことに、ベクトル演算のおかげで、2 つのベクトル間の距離または類似性を測定することは簡単に解決できる問題です。それでは、Elasticsearch でサポートされている最も人気のある距離と類似度の関数を見てみましょう。警告、この先は数学です!

始める前に、スコアリングについて簡単に見てみましょう。実際のところ、Lucene ではスコアは正の値のみが許可されます。これから紹介するすべての距離関数と類似度関数は、2 つのベクトルがどれだけ近いか、または類似しているかの尺度を生成しますが、それらの生の数値は負になる可能性があるため、スコアとして使用するのに適することはほとんどありません。このため、最終スコアは、スコアが正になり、スコアが大きいほどランキングが高くなる（つまり、ベクトルが近い）ように、距離または類似度の値から導き出す必要があります。

L1距離

2 つのベクトルとの L1 距離 (マンハッタン距離とも呼ばれます) は、それらのすべての要素のペアワイズ絶対差を合計することによって測定されます。明らかに、距離が小さいほど、2つのベクトルは近くなります。L1距離の式（1）は、以下に示すように非常に単純です。

視覚的に、L1 距離は以下の図 (赤) のように表すことができます。

次の2つのベクトルとのL1距離を計算するととなる。

重要: L1 距離関数は、script_score DSL クエリを使用した 正確なベクトル検索(別名、ブルート フォース検索) でのみサポートされ、knn 検索オプション またはknn DSL クエリ を使用した 近似 kNN 検索 ではサポートされないことに注意してください。

L2距離

2 つのベクトルとの L2 距離 (ユークリッド距離とも呼ばれます) は、まずそれらのすべての要素のペアワイズ差の 2 乗を合計し、次にその結果の平方根をとることによって測定されます。基本的には 2 点間の最短経路です。L1と同様に、距離が小さいほど、2つのベクトルは近くなります。

L2 距離は、下の画像で赤で示されています。

距離に使用したのと同じ 2 つのサンプル ベクトル と 距離を として計算できるようになります。

スコアリングに関しては、2 つのベクトル間の距離が小さいほど、それらのベクトルは近い (つまり、類似している) と言えます。したがって、スコアを導き出すには、距離の測定を逆転させて、最小の距離で最高のスコアが得られるようにする必要があります。L2距離を用いた場合のスコアの計算方法は、以下の式（3）のようになります。

前の例のサンプルベクトルを再利用すると、スコアはになります。互いに非常に近い 2 つのベクトルのスコアは 1 に近づきますが、互いに非常に離れた 2 つのベクトルのスコアは 0 に近づく傾向があります。

L1 距離関数と L2 距離関数についてまとめると、これらを比較する良い例えは、A と B をニューヨーク市マンハッタンの 2 つの建物として考えることです。A から B まで行くタクシーは L1 パス (街路や大通り) に沿って走行する必要がありますが、鳥はおそらく L2 パス (直線) を使用するでしょう。

コサイン類似度

L1 および L2 とは対照的に、コサイン類似度は 2 つのベクトルと間の距離を測定するのではなく、それらの相対的な角度、つまり両方がほぼ同じ方向を向いているかどうかを測定します。類似度が高いほど、2 つのベクトル間の角度が小さくなり、したがって、それらのベクトルは「近く」なり、伝えられる意味は「似ている」ことになります。

これを説明するために、野外でそれぞれ異なる方向を見ている 2 人の人物を考えてみます。下の図では、青い人物はベクトルで示される方向を向いており、赤い人物はベクトルの方向を向いています。視線を同じ方向に向けるほど（つまり、ベクトルが近づくほど）、青と赤の領域で表された視野の重なり合う部分が大きくなります。視野がどの程度重なるかがコサイン類似度です。ただし、人物 B は人物 A よりも遠くを見ていることに注意してください (つまり、ベクトルが長い)。人 B は地平線の遠くの山を眺めているかもしれませんが、人 A は近くの木を眺めているかもしれません。コサイン類似度の場合、角度だけが関係するため、コサイン類似度は役割を果たしません。

それでは、コサイン類似度を計算してみましょう。式（4）は非常に単純で、分子は2つのベクトルのドット積で構成され、分母にはベクトルの大きさ（つまり長さ）の積が含まれます。

と間のコサイン類似度は、それらの間の角度の尺度として以下の画像に示されています (赤で表示)。

これらのコサイン類似度値が具体的に何を意味するのかを説明するために、少し回り道をしてみましょう。下のコサイン関数を示す画像に見られるように、値は常に範囲内で振動します。

2 つのベクトルが類似しているとみなされるためには、その角度が可能な限り鋭角で、理想的には角度に近く、完全な類似度がになる必要があることに注意してください。つまり、ベクトルは...

1. ...互いに近づくと、角度の余弦は近づきます（つまり、 に近づきます）。

1. ...無関係ですが、角度の余弦は近づきます（つまり、 に近づきます）。

1. ...反対に、その角度の余弦はに近づきます（つまり、 に近づきます）。

2つのベクトル間のコサイン類似度を計算する方法がわかり、結果の値をどのように解釈するかもよくわかったので、同じサンプルベクトルとを再利用し、先ほど見た式（4）を使用してコサイン類似度を計算できます。

コサイン類似度は となり、これは よりも に近いため、 2 つのベクトルは 多少類似して いる、つまり完全に類似しているわけではないが、完全に無関係でもなく、明らかに反対の意味を持っていないことを意味します。

任意のコサイン類似度値から正のスコアを導き出すには、次の式（5）を使用する必要があります。この式は、 範囲内で振動するコサイン類似度値をの範囲内のスコアに変換します。

したがって、サンプルベクトルとのスコアは次のようになります: 。

ドット積類似度

コサイン類似度の欠点の 1 つは、2 つのベクトル間の角度のみが考慮され、大きさは考慮されないことです。つまり、2 つのベクトルがほぼ同じ方向を指していても、一方が他方よりもはるかに長い場合、両方とも類似していると見なされます。ドット積類似度 (スカラー類似度または内積類似度とも呼ばれる) は、ベクトルの角度と大きさの両方を考慮することで類似度を改善し、より正確な類似度メトリックを提供します。ベクトルの大きさを無関係にするために、ドット積類似性では、まずベクトルを正規化する必要があります。そのため、最終的には単位長さ 1 のベクトルのみを比較することになります。

先ほどと同じ 2 人の人物でもう一度これを説明してみます。ただし今回は、彼らを円形の部屋の中央に配置し、彼らの視界の範囲 (つまり、部屋の半径) がまったく同じになるようにします。コサイン類似度と同様に、同じ方向を向くほど（つまり、ベクトルが近づくほど）、視野の重なり合う部分が多くなります。しかし、コサイン相似とは逆に、両方のベクトルの長さは同じで、両方の領域の表面積も同じなので、2 人の人物は同じ距離にあるまったく同じ画像を見ていることになります。これら 2 つの領域がどの程度重なり合っているかは、それらのドット積の類似性を示します。

ドット積の類似度の式を紹介する前に、ベクトルを正規化する方法を簡単に見てみましょう。これは非常に簡単で、2 つの簡単な手順で実行できます。

1. ベクトルの大きさを計算する

2. 各成分を1で得られた大きさで割ります。

例として、ベクトルを取ります。コサイン類似度を確認したときに見たように、その大きさを計算できます。つまり、 。次に、ベクトルの各成分をその大きさで割ると、次の正規化ベクトルが得られます。

2番目のベクトルに対して同じプロセスを実行すると、次の正規化されたベクトルが生成されます。

ドット積類似度式を導くために、正規化されたベクトルと間のコサイン類似度を式(4)を用いて以下のように計算することができる。

そして、両方の正規化されたベクトルの大きさがなったので、ドット積の相似式（6）は単純に、両方の正規化されたベクトルのドット積になります。

下の図では、正規化されたベクトルとを示しており、1 つのベクトルを他のベクトルに投影することで、それらのドット積の類似性を示しています (赤で表示)。

新しい式（6）を使用すると、2つの正規化されたベクトルのドット積類似度を計算することができ、当然のことながら、コサインの類似度とまったく同じ類似度値が得られます。

ドット積類似性を活用する場合、ベクトルに浮動小数点値が含まれているかバイト値が含まれているかに応じて、スコアの計算方法が異なります。前者の場合、スコアはコサイン類似度の場合と同じ方法で以下の式（7）を使用して計算されます。

しかし、ベクトルがバイト値で構成されている場合、スコアリングの計算方法は以下の式（8）に示すように少し異なります。ここで、 ベクトルの次元数です。

また、正確なスコアを生成するための制約の 1 つは、クエリ ベクトルを含むすべてのベクトルの長さが同じである必要があるが、必ずしも 1 である必要はないということです。

最大内積類似度

リリース 8.11 以降では、ベクトルを正規化する必要がないという点で、ドット積類似度よりも制約が少ない新しい類似度関数があります。この主な理由は以下の記事で詳しく説明されていますが、簡単にまとめると、特定のデータセットはベクトルの正規化にあまり適しておらず (例: Cohere 埋め込み)、正規化すると関連性の問題が発生する可能性があります。

最大内積類似度を計算する式は、ドット積の式とまったく同じです（6）。変わるのは、以下の式(9)に示すように、類似性が正か負かによって式が変わる区分関数を使用して最大内積類似度をスケーリングしてスコアを計算する方法です。

この区分関数は、 区間内のすべての負の最大内積類似度値と、 区間内のすべての正の値をスケーリングします。

要約すれば

数学的に言えば、これはかなり大変な話ですが、役に立つと思われるポイントをいくつか挙げておきます。

どの類似度関数を使用できるかは、最終的にはベクトル埋め込みが正規化されているかどうかによって決まります。ベクトルがすでに正規化されている場合、またはデータ セットがベクトルの正規化に依存しない場合 (つまり、関連性が損なわれない場合)、ベクトルを正規化してドット積類似度を使用できます。これは、各ベクトルの長さを計算する必要がないため、コサイン積類似度よりもはるかに高速に計算できるためです。何百万ものベクトルを比較する場合、それらの計算量は非常に多くなることがあります。

ベクトルが正規化されていない場合は、次の 2 つのオプションがあります。

1. ベクトルを正規化できない場合はコサイン類似度を使用する

2. ベクトルの大きさが意味を持つため、それをスコアリングに反映させたい場合には、新しい最大内積類似度を使用します（例：Cohere埋め込み）。

この時点で、ベクトル埋め込み間の距離または類似性を計算し、そのスコアを導き出す方法が理解できるはずです。この記事がお役に立てれば幸いです。

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

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

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

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

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

生成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」にマッピングされます。

マッピング：

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

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

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

取り込みパイプライン:

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

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

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

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

クエリ:

アウトプット：

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

クエリ:

アウトプット：

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

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

クエリ:

アウトプット：

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

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

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

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

まとめ

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

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

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

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

• セマンティック検索とは？

• 自然言語処理 (NLP) とは何ですか?

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

• 大規模なドキュメントをインジェストパイプラインでチャンク化し、ネストされたベクトルと組み合わせることで、簡単にパッセージを検索できます。

要件

このシリーズのパート 1 と同様に、この例では次の前提条件が必要です。

1. Goバージョン1.21以降のインストール

2. Go ドキュメントに記載されている推奨構造とパッケージ管理を使用して、独自の Go リポジトリを作成します。

3. 独自の Elasticsearch クラスターを作成し、Wikipedia のフレンドリーな Gopher を含む、 げっ歯類ベースのページ セットを設定します。

Elasticsearchへの接続

繰り返しになりますが、私たちの例では、Go クライアントが提供するTyped APIを使用します。クエリに対して安全な接続を確立するには、次のいずれかを使用してクライアントを構成する必要があります。

1. Elastic Cloud を利用する場合の Cloud ID と API キー

2. クラスターURL、ユーザー名、パスワード、証明書

Elastic Cloud にあるクラスターに接続すると、次のようになります。

後続のセクションで示すように、 client接続は検索に使用できます。

ハイブリッド検索の手動ブースティング

検索アルゴリズムのセットを組み合わせる場合、従来のアプローチでは、各クエリ タイプを強化するために定数を手動で構成していました。具体的には、クエリごとに係数が指定され、結合された結果セットが予想されるセットと比較され、クエリのリコールが決定されます。次に、いくつかの要因セットを繰り返し、希望する状態に最も近いものを選択します。

たとえば、 0.8倍の係数でブーストされた単一のテキスト検索クエリと、 0.2倍の係数が低い knn クエリを組み合わせるには、次の例に示すように、両方のクエリ タイプでBoostフィールドを指定します。

各クエリのBoostオプションで指定された係数がドキュメント スコアに追加されます。一致クエリのスコアを knn クエリよりも大きな係数で増加させることにより、キーワード クエリの結果の重み付けがより大きくなります。

手動によるブースティングの課題は、特に検索の専門家でない場合、望ましい結果セットにつながる要因を見つけ出すために調整が必要になることです。ランダムな値を試してみて、希望する結果セットに近づくかどうかを調べるだけです。

ハイブリッド検索とGoクライアントにおける相互ランク融合

Reciprocal Rank Fusion (RRF) は、Elasticsearch 8.9 のハイブリッド検索のテクニカル プレビューとしてリリースされました。チューニングに関連する学習曲線を短縮し、結果セットを最適化するための要素の実験にかかる時間を短縮することを目的としています。

RRF では、以下のアルゴリズムでスコアをブレンドしてドキュメント スコアが再計算されます。

RRF を使用する利点は、Elasticsearch 内で適切なデフォルト値を利用できることです。ランキング定数kデフォルトは60です。大規模なデータ セットを検索するときに、返されるドキュメントの関連性とクエリ パフォーマンスの間のトレードオフを提供するために、検討される各クエリの結果セットのサイズはwindow_sizeの値に制限されます。この値は、ドキュメントで説明されているように、デフォルトで100になります。

k また、 windows_size 、以下の例のように、Go クライアントのRankメソッド内のRrf構成内で構成することもできます。

まとめ

ここでは、 Elasticsearch Go クライアントを使用して Elasticsearch でベクトル検索とキーワード検索を組み合わせる方法について説明しました。

このシリーズのすべてのコードについては、 GitHub リポジトリをご覧ください。まだご覧になっていない方は、このシリーズのすべてのコードについてはパート 1とパート 2をご覧ください。

楽しいホリネズミ狩りを！

各種資料

1. Elasticsearchガイド

2. Elasticsearch Goクライアント

3. ベクトル検索とは何ですか?| 弾性

4. 相互ランク融合

動物、プログラミング言語、そして親しみやすい著者と同じように、検索もさまざまな方法の進化を遂げており、独自の検索ユースケースに応じてどれを選択するかを決めるのは難しい場合があります。このブログでは、ベクトル検索の概要と、 Elasticsearch および Elasticsearch Go クライアント を使用した各アプローチの 例を 紹介します。これらの例では、Elasticsearch と Go のベクトル検索を使用して、ホリネズミを見つけて、その食べ物を特定する方法を説明します。

要件

この例を実行するには、次の前提条件が満たされていることを確認してください。

1. Goバージョン1.21以降のインストール

2. 独自のGoリポジトリを作成する

3. 独自の Elasticsearch クラスターを作成し、Wikipedia のフレンドリーなGopherを含む一連のげっ歯類ベースのページを設定します。

Elasticsearchへの接続

この例では、Go クライアントが提供するTyped APIを利用します。クエリに対して安全な接続を確立するには、次のいずれかを使用してクライアントを構成する必要があります。

1. Elastic Cloud を利用する場合のクラウド ID と API キー。

2. クラスター URL、ユーザー名、パスワード、証明書。

Elastic Cloud にあるクラスターに接続すると、次のようになります。

後続のセクションに示すように、 client接続はベクトル検索に使用できます。

ベクトル検索

ベクトル検索は、検索問題をベクトルを使用した数学的な比較に変換することでこの問題を解決しようとします。ドキュメント埋め込みプロセスには、モデルを使用してドキュメントを高密度ベクトル表現、つまり単純な数値のストリームに変換する追加の段階があります。このアプローチの利点は、画像や音声などのテキスト以外のドキュメントをクエリと一緒にベクトルに変換して検索できることです。

簡単に言えば、ベクトル検索はベクトル距離の計算のセットです。下の図では、クエリGo Gopherのベクトル表現がベクトル空間内のドキュメントと比較され、最も近い結果 (定数kで示される) が返されます。

ドキュメントの埋め込みを生成するために使用するアプローチに応じて、ホリネズミが何を食べるかを調べる方法が 2 つあります。

アプローチ1: 独自のモデルを持ち込む

Platinum ライセンスでは、モデルをアップロードし、推論 API を使用して Elasticsearch 内で埋め込みを生成できます。モデルの設定には 6 つのステップがあります。

1. モデル リポジトリからアップロードする PyTorch モデルを選択します。この例では、Hugging Face のsentence-transformers/msmarco-MiniLM-L-12-v3を使用して埋め込みを生成します。

2. Elasticsearch クラスターとタスク タイプtext_embeddingsの資格情報を使用して、Python 用の Eland Machine Learning クライアントでモデルを Elastic にロードします。Eland がインストールされていない場合は、以下に示すようにDocker を使用してインポート手順を実行できます。

1. アップロードしたら、サンプル ドキュメントを使用してモデルsentence-transformers__msmarco-minilm-l-12-v3をすぐにテストし、埋め込みが期待どおりに生成されることを確認します。

1. 推論プロセッサを含む取り込みパイプラインを作成します。これにより、アップロードされたモデルを使用してベクター表現を生成できるようになります。

1. 各ドキュメントに対して生成されたベクトル埋め込みを格納するための、タイプdense_vectorのフィールドtext_embedding.predicted_valueを含む新しいインデックスを作成します。

1. 新しく作成された取り込みパイプラインを使用してドキュメントのインデックスを再作成し、各ドキュメントの追加フィールドtext_embedding.predicted_valueとしてテキスト埋め込みを生成します。

次の例に示すように、新しいインデックスvector-search-rodentsを使用して、同じ検索 API でKnnオプションを使用できるようになりました。

アンマーシャリングによる JSON 結果オブジェクトの変換は、キーワード検索の例とまったく同じ方法で実行されます。定数KとNumCandidates使用すると、返される隣接ドキュメントの数と、シャードごとに考慮する候補の数を設定できます。候補の数を増やすと結果の精度は上がりますが、比較が多く実行されるためクエリの実行時間が長くなることに注意してください。

クエリWhat do Gophers eat?を使用してコードを実行すると、返される結果は以下と同様になり、以前のキーワード検索とは異なり、Gopher の記事に要求された情報が含まれていることが強調表示されます。

アプローチ2：ハグフェイス推論API

もう 1 つのオプションは、Elasticsearch の外部で同じ埋め込みを生成し、ドキュメントの一部として取り込むことです。このオプションは Elasticsearch 機械学習ノードを使用しないため、無料利用枠で実行できます。

Hugging Face は、無料で使用できるレート制限付きの推論 API を公開しています。アカウントと API トークンを使用すると、実験やプロトタイピングを開始するために同じ埋め込みを手動で生成できます。実稼働環境での使用は推奨されません。同様のアプローチを使用して、ローカルで独自のモデルを呼び出して埋め込みを生成したり、有料の API を使用したりすることもできます。

以下の関数GetTextEmbeddingForQueryでは、クエリ文字列に対して推論 API を使用して、エンドポイントへのPOSTリクエストから返されるベクトルを生成します。

結果の[]float32型のベクトルは、 QueryVectorBuilderオプションを使用する代わりにQueryVectorとして渡され、以前に Elastic にアップロードされたモデルが活用されます。

KとNumCandidatesオプションは2つのオプションに関係なく同じままであり、埋め込みを生成するために同じモデルを使用しているため、同じ結果が生成されることに注意してください。

まとめ

ここでは、 Elasticsearch Go クライアントを使用して Elasticsearch でベクトル検索を実行する方法について説明しました。このシリーズのすべてのコードについては、 GitHub リポジトリをご覧ください。パート 3に進み、パート 1で説明した Go のキーワード検索機能とベクトル検索を組み合わせる方法の概要を確認します。

それまでは、楽しいホリネズミ狩りを！

各種資料

1. Elasticsearchガイド

2. Elasticsearch Goクライアント

3. ベクトル検索とは何ですか?| 弾性

この目標を考慮して、このブログ投稿では、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 つだけ必要です。トークナイザーは文字のストリームを受け取り、それを個々のトークン (通常は個々の単語) に分割します。以下に例を示します。

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

出力

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

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

出力

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

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

語彙マッチング

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

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

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

出力

出力を分析すると、最も関連性の高い結果は「 おもちゃ 」カテゴリの「バービードリームハウス 」製品であり、その説明には「 家具 」、「 大型」 、「バルコニー 」という用語が含まれているため関連性が高く、説明に検索クエリに一致する用語が 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によるセマンティック検索

このコード ブロックは、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 次元の密なベクトル空間にマッピングします。

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

出力

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

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

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

• セマンティック検索の有効化

• 非常に大規模なデータセットを処理できるスケーラビリティ

• 幅広いデータタイプを処理できる柔軟性

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

• ユースケースに適した埋め込みモデルの選択

• モデルが選択されると、ドメイン固有のデータセットでのパフォーマンスを最適化するためにモデルを微調整する必要がある場合があり、このプロセスにはドメイン専門家の関与が求められる。

• さらに、高次元ベクトルのインデックス作成は計算コストが高くなる可能性がある。

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

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

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

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

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

出力

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

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

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

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

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

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

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

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

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

出力

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

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

出力

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

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

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

• Elastic Stackでの情報検索の改善：ハイブリッド検索

• Elasticsearchのベクトル検索：設計の背後にある理論的根拠

• Elasticのベクターデータベースで語彙検索とAIを活用した検索を最大限に活用する方法

• Elastic Learned Sparse Encoder のご紹介: セマンティック検索のための Elastic の AI モデル

• Elastic Stackでの情報検索の改善: 新しい検索モデルElastic Learned Sparse Encoderのご紹介

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

• Elasticsearchベクターデータベース

• Elasticによるベクトル検索のユースケース

まとめ

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

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

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

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

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

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

テクノロジーの進歩に伴い、チャットボットはユーザーにパーソナライズされたエクスペリエンスを提供しながら、より複雑なタスクを迅速に処理するために使用されるようになりました。自然言語処理 (NLP) により、チャットボットはユーザーの言語を処理し、メッセージの意図を識別し、そこから関連情報を抽出できるようになります。たとえば、固有表現抽出では、テキストを一連のカテゴリに分類して重要な情報を抽出します。感情分析は感情的なトーンを識別し、質問応答はクエリに対する「答え」を識別します。NLP の目標は、アルゴリズムが人間の言語を処理し、大量のテキストの中から関連する文章を見つけたり、テキストを要約したり、新しい独自のコンテンツを生成するなど、これまでは人間だけが実行できたタスクを実行できるようにすることです。

これらの高度な NLP 機能は、ベクトル検索と呼ばれるテクノロジーに基づいて構築されています。Elastic は、ベクトル検索、正確なk 最近傍 (kNN) 検索と近似 k 最近傍検索の実行、および NLP をネイティブにサポートしており、Elasticsearch で直接カスタム モデルまたはサードパーティ モデルを使用できます。

このブログ記事では、ベクトル検索と NLP がどのように機能してチャットボットの機能を強化するかを説明し、Elasticsearch がどのようにそのプロセスを促進するかを説明します。まず、ベクトル検索の概要を簡単に説明します。

ベクトル検索

人間は書かれた言語の意味と文脈を理解できますが、機械は同じことはできません。ここでベクトルが登場します。テキストをベクトル表現（テキストの意味の数値表現）に変換することで、マシンはこの制限を克服できます。従来の検索と比較すると、キーワードや頻度に基づく語彙検索に依存するのではなく、ベクトルでは数値に対して定義された演算を使用してテキスト データの処理が可能になります。

これにより、ベクトル検索では、クエリベクトルが与えられた場合に類似性を表す「埋め込み空間」内の距離を使用して、類似の概念またはコンテキストを共有するデータを見つけることができます。データが類似している場合、対応するベクトルも同様になります。

ベクトル検索は NLP アプリケーションで利用されるだけでなく、画像やビデオの処理など、非構造化データが関係するさまざまな他の領域でも使用されます。

チャットボット フローでは、ユーザーのクエリに対して複数のアプローチが可能であり、その結果、情報検索を改善してユーザー エクスペリエンスを向上させるさまざまな方法が存在します。それぞれの選択肢には独自の利点と欠点があるため、利用可能なデータとリソース、トレーニング時間（該当する場合）、および予想される精度を考慮することが重要です。次のセクションでは、質問応答 NLP モデルのこれらの側面について説明します。

質問応答

質問応答 (QA) モデルは、自然言語で尋ねられた質問に答えるように設計された NLP モデルの一種です。ユーザーが、ドキュメント内に既存のターゲット回答がなく、複数のリソースから回答を推測する必要がある質問がある場合、生成型 QA モデルが役立ちます。ただし、これらのモデルは計算コストが高く、ドメイン関連のトレーニングに大量のデータが必要になる可能性があり、この方法はドメイン外の質問を処理するのに特に価値があるにもかかわらず、状況によっては実用的ではない可能性があります。

一方、ユーザーが特定のトピックについて質問し、実際の回答がドキュメント内に存在する場合は、抽出型 QA モデルを使用できます。これらのモデルは、ソース ドキュメントから回答を直接抽出し、透明性と検証性に優れた結果を提供するため、質問にシンプルかつ効率的に回答したい企業や組織にとって、より実用的なオプションとなります。

以下の例は、 Hugging Face で利用可能でElasticsearch にデプロイされた、事前トレーニング済みの抽出 QA モデルを使用して、特定のコンテキストから回答を抽出する方法を示しています。

トレーニング済みのモデルをデプロイします。

推論取り込みパイプラインにモデルを追加します。

ユーザーのクエリを処理して情報を取得する方法はさまざまであり、非構造化データを扱う場合には、複数の言語モデルとデータ ソースを使用することが効果的な代替手段となります。これを説明するために、選択されたドキュメントから抽出されたデータを考慮してクエリに回答するために使用されるチャットボットのデータ処理の例を示します。

チャットボットのデータ処理：NLPとベクトル検索

上記のように、チャットボットのデータ処理は 3 つの部分に分けられます。

• ベクター処理:この部分はドキュメントをベクター表現に変換します。

• ユーザー入力処理:この部分では、ユーザークエリから関連情報を抽出し、セマンティック検索とハイブリッド検索を実行します。

• 最適化:この部分には監視が含まれており、チャットボットの信頼性、最適なパフォーマンス、優れたユーザー エクスペリエンスを確保するために重要です。

ベクトル処理

処理部分では、まず各ドキュメントの構成要素を決定し、各要素をベクトル表現に変換します。これらの表現は、さまざまなデータ形式に対して作成できます。

埋め込みを計算するために使用できる方法は、事前トレーニング済みのモデルやライブラリなど、さまざまあります。

これらの表現に対する検索と取得の有効性は、既存のデータと、使用される方法の品質と関連性に依存することに注意することが重要です。

ベクトルが計算されると、 dense_vectorフィールド タイプを使用して Elasticsearch に保存されます。

チャットボットのユーザー入力処理

ユーザー側では、質問を受け取った後、先に進む前にそこから可能な限りすべての情報を抽出すると便利です。これはユーザーの意図を理解するのに役立ちます。この場合、それを支援するために名前付きエンティティ認識モデル (NER)を使用しています。NER は、名前付きエンティティを識別し、事前定義されたエンティティ カテゴリに分類するプロセスです。

必須のステップではありませんが、構造化データや上記または別の NLP モデルの結果を使用してユーザーのクエリを分類することで、フィルターを使用して kNN 検索を制限できます。これにより、処理する必要があるデータの量が削減され、パフォーマンスと精度が向上します。

セマンティック検索とハイブリッド検索

プロンプトはユーザーのクエリから生成され、チャットボットは変動性と曖昧性を持つ人間の言語を処理する必要があるため、セマンティック検索は最適です。Elasticsearch では、クエリ文字列と埋め込みモデルの ID を query_vector_builder オブジェクトに渡すことで、セマンティック検索を 1 ステップで実行できます。これにより、クエリがベクトル化され、kNN検索が実行され、クエリに意味的に最も近い上位 k 個の一致が取得されます。

エンドツーエンドの例: テキスト埋め込みモデルを展開し、セマンティック検索に使用する方法。Elasticsearch は、疎モデルであるOkapi BM25 の Lucene 実装を使用してテキストクエリの関連性をランク付けし、密モデルはセマンティック検索に使用されます。ベクトル一致とテキスト クエリから取得された 一致の両方の長所 を組み合わせる には 、 ハイブリッド検索 を実行できます。

疎モデルと密モデルの両方を組み合わせると、多くの場合、最良の結果が得られます。

通常、スパース モデルは短いクエリと特定の用語で優れたパフォーマンスを発揮しますが、密なモデルはコンテキストと関連付けを活用します。これらの方法がどのように比較され、相互に補完し合うかについて詳しく知りたい場合は、ここで、検索用に特別にトレーニングされた 2 つの高密度モデルに対して BM25 をベンチマークします。

最も関連性の高い結果は通常、ユーザーに最初に提供される回答になります。_scoreは、返されたドキュメントの関連性を判断するために使用される数値です。

チャットボットの最適化

チャットボットのユーザー エクスペリエンス、パフォーマンス、信頼性を向上させるには、ハイブリッド スコアリングを適用することに加えて、次のアプローチを組み込むことができます。感情分析:ダイアログが展開されるときにユーザーのコメントや反応を認識できるように、感情分析モデルを組み込むことができます。

GPT の機能:全体的なエクスペリエンスを向上させる代わりに、Elasticsearch の検索関連性と OpenAI の GPT 質問応答機能を組み合わせ、 Chat Completion APIを使用して、上位 k 件のドキュメントをコンテキストとして考慮し、ユーザーモデルが生成した応答を返すことができます。プロンプト:<user_question> 「このドキュメント のみを使用して、この質問<top_search_result> に回答してください」

可観測性:あらゆるチャットボットのパフォーマンスを確保することは非常に重要であり、これを実現するには監視が不可欠な要素です。チャットボットのやり取りをキャプチャするログに加えて、応答時間、待ち時間、その他の関連するチャットボットのメトリックを追跡することが重要です。これにより、パターンや傾向を特定し、異常を検出することさえ可能になります。Elastic Observabilityツールを使用すれば、こうした情報を収集・分析できます。

まとめ

このブログ記事では、NLP とベクトル検索とは何かを説明し、ドキュメントのベクトル表現から抽出されたデータを考慮してユーザーのクエリに応答するために使用されるチャットボットの例を詳しく説明します。

実証されているように、NLP とベクトル検索を使用すると、チャットボットは構造化されたターゲット データを超えた複雑なタスクを実行できます。これには、複数のデータ ソースと形式をコンテキストとして使用して推奨事項を作成し、特定の製品またはビジネス関連のクエリに回答するとともに、パーソナライズされたユーザー エクスペリエンスを提供することも含まれます。

ユースケースは、顧客からの問い合わせに対応して顧客サービスを提供することから、開発者のクエリを支援し、ステップバイステップのガイダンスを提供したり、推奨事項を提案したり、タスクを自動化したりすることまで多岐にわたります。目標と既存のデータに応じて、他のモデルや方法を活用してさらに優れた結果を達成し、全体的なユーザー エクスペリエンスを向上させることもできます。

このトピックに関して役立つと思われるリンクをいくつか紹介します。

1. 自然言語処理（NLP）の導入方法：はじめに

2. Elasticsearchにおける画像類似検索の概要

3. ChatGPTとElasticsearch: OpenAIとプライベートデータの出会い

4. Monitor OpenAI API and GPT models with OpenTelemetry and Elastic（OpenTelemetryとElasticを利用してOpenAI APIとGPTモデルを監視）

5. ITリーダーが検索エクスペリエンスを向上させるためにベクトル検索を必要とする5つの理由

Elasticsearch に NLP とネイティブベクトル検索を組み込むことで、そのスピード、スケーラビリティ、検索機能を活用し、構造化データか非構造化データかを問わず大量のデータを処理できる、非常に効率的で効果的なチャットボットを作成できます。

始める準備はできましたか?Elastic Cloud の無料トライアルを開始してください。

このブログ投稿では、それぞれの所有者が所有および運営するサードパーティ製の生成 AI ツールを使用したり、参照したりする場合があります。Elastic はサードパーティ製ツールを一切管理しておらず、そのコンテンツ、操作、使用、またそのようなツールの使用によって発生する損失や損害については一切責任を負いません。個人情報、機密情報、秘密情報を扱う AI ツールを使用する場合は注意してください。送信したデータは AI のトレーニングやその他の目的で使用される場合があります。お客様が提供する情報が安全に保管され、機密性が保たれるという保証はありません。生成 AI ツールを使用する前に、プライバシー慣行と利用規約をよく理解しておく必要があります。

Elastic、Elasticsearch および関連するマークは、米国およびその他の国における Elasticsearch NV の商標、ロゴ、または登録商標です。その他すべての会社名および製品名は、それぞれの所有者の商標、ロゴ、または登録商標です。

この投稿では、テキスト類似性検索と呼ばれる特定の手法に焦点を当てています。このタイプの検索では、ユーザーは短いフリーテキストクエリを入力し、ドキュメントはクエリとの類似性に基づいてランク付けされます。テキストの類似性は、さまざまな使用例で役立ちます。

• 質問回答:よくある質問のコレクションが与えられた場合、ユーザーが入力した質問に類似した質問を見つけます。

• 記事検索:研究記事のコレクションで、ユーザーのクエリに密接に関連するタイトルの記事を返します。

• 画像検索:キャプション付きの画像のデータセットで、ユーザーの説明に類似したキャプションを持つ画像を検索します。

類似性検索の直接的なアプローチは、クエリと共有する単語の数に基づいてドキュメントをランク付けすることです。しかし、共通する単語がほとんどない場合でも、ドキュメントがクエリと類似している可能性があります。より堅牢な類似性の概念では、構文と意味の内容も考慮されます。

自然言語処理 (NLP) コミュニティは、単語や文章を数値ベクトルとしてエンコードするテキスト埋め込みと呼ばれる手法を開発しました。これらのベクトル表現は、テキストの言語コンテンツをキャプチャするように設計されており、クエリとドキュメント間の類似性を評価するために使用できます。

この投稿では、テキスト埋め込みと Elasticsearch の dense_vector タイプを使用して類似性検索をサポートする方法について説明します。まず、埋め込み技術の概要を説明し、次に Elasticsearch を使用した類似性検索の簡単なプロトタイプを段階的に説明します。

テキスト埋め込みとは何ですか?

さまざまな種類のテキスト埋め込みと、従来の検索アプローチとの比較を詳しく見てみましょう。

単語埋め込み

単語埋め込みモデルは、単語を密な数値ベクトルとして表現します。これらのベクトルは、単語の意味特性を捉えることを目的としています。つまり、ベクトルが近い単語は、意味の点で類似しているはずです。適切な埋め込みでは、ベクトル空間の方向は単語の意味のさまざまな側面に結び付けられます。たとえば、「カナダ」のベクトルは、ある方向では「フランス」に近く、別の方向では「トロント」に近くなる可能性があります。

NLP および検索コミュニティは、かなり長い間、単語のベクトル表現に興味を抱いてきました。過去数年間、多くの従来のタスクがニューラル ネットワークを使用して再検討され、単語埋め込みへの関心が再び高まりました。word2vecやGloVeなど、いくつかの成功した単語埋め込みアルゴリズムが開発されました。これらのアプローチでは、大規模なテキスト コレクションを利用し、各単語が出現するコンテキストを調べてベクトル表現を決定します。

• word2vec Skip-gram モデルは、ニューラル ネットワークをトレーニングして、文中の単語の周囲のコンテキスト ワードを予測します。ネットワークの内部重みによって単語の埋め込みが与えられます。

• GloVe では、単語の類似性は、他の文脈上の単語と一緒に出現する頻度によって決まります。このアルゴリズムは、単語の共起カウントに基づいて単純な線形モデルをトレーニングします。

多くの研究グループが、Wikipedia や Common Crawl などの大規模なテキスト コーパスで事前トレーニングされたモデルを配布しており、ダウンロードして下流のタスクに組み込むのが便利になっています。事前トレーニング済みのバージョンが直接使用される場合もありますが、特定のターゲット データセットとタスクに合わせてモデルを調整すると役立つ場合があります。これは通常、事前トレーニング済みのモデルに対して「微調整」ステップを実行することによって実現されます。

単語埋め込みは非常に堅牢かつ効果的であることが証明されており、機械翻訳や感情分類などの NLP タスクでは、個々のトークンの代わりに埋め込みを使用するのが一般的になっています。

文の埋め込み

最近では、研究者たちは単語だけでなく、より長いテキストセクションを表す埋め込み技術に注目し始めています。現在のアプローチのほとんどは、複雑なニューラル ネットワーク アーキテクチャに基づいており、意味情報の取得を支援するためにトレーニング中にラベル付けされたデータを組み込むこともあります。

一度トレーニングされると、モデルは文を受け取り、文脈内の各単語のベクトルと文全体のベクトルを生成できるようになります。単語埋め込みと同様に、多くのモデルの事前トレーニング済みバージョンが利用可能であり、ユーザーはコストのかかるトレーニング プロセスを省略できます。トレーニング プロセスは大量のリソースを消費する可能性がありますが、モデルの呼び出しははるかに軽量です。文埋め込みモデルは通常、リアルタイム アプリケーションの一部として使用できるほど高速です。

一般的な文埋め込み手法としては、 InferSent 、 Universal Sentence Encoder 、 ELMo 、 BERTなどがあります。単語や文の埋め込みの改善は活発に研究されている分野であり、今後さらに強力なモデルが導入される可能性があります。

従来の検索アプローチとの比較

従来の情報検索では、テキストを数値ベクトルとして表現する一般的な方法は、語彙内の単語ごとに 1 つの次元を割り当てることです。テキストのベクトルは、語彙内の各用語が出現する回数に基づいて決定されます。テキストを表現するこの方法は、文の構造を考慮せずに単語の出現回数を単純に数えるため、「bag of words」と呼ばれることがよくあります。

テキスト埋め込みは、いくつかの重要な点で従来のベクトル表現と異なります。

• エンコードされたベクトルは密度が高く、比較的低次元であり、多くの場合 100 次元から 1,000 次元の範囲になります。対照的に、Bag of Words ベクトルはスパースであり、50,000 以上の次元で構成できます。埋め込みアルゴリズムは、テキストの意味をモデル化する一環として、テキストを低次元空間にエンコードします。理想的には、同義語やフレーズは、新しいベクトル空間で同様の表現になります。

• 文の埋め込みでは、ベクトル表現を決定するときに単語の順序を考慮できます。たとえば、「tune in」というフレーズは、「in tune」とはまったく異なるベクトルとしてマッピングされる場合があります。

• 実際には、文の埋め込みはテキストの大きなセクションにはうまく一般化されないことがよくあります。これらは通常、短い段落よりも長いテキストを表すために使用されません。

類似性検索に埋め込みを使用する

質問と回答の大きなコレクションがあったとしましょう。ユーザーは質問をすることができ、私たちはユーザーが回答を見つけやすくするために、コレクション内で最も類似した質問を取得したいと考えています。

テキスト埋め込みを使用すると、類似の質問を取得できるようになります。

• インデックス作成中に、各質問は文埋め込みモデルに渡され、数値ベクトルが生成されます。

• ユーザーがクエリを入力すると、同じ文埋め込みモデルが実行され、ベクトルが生成されます。回答をランク付けするために、各質問とクエリ ベクトル間のベクトル類似度を計算します。埋め込みベクトルを比較する場合、コサイン類似度を使用するのが一般的です。

このリポジトリには、 Elasticsearch でこれをどのように実現できるかの簡単な例が示されています。メイン スクリプトは、 StackOverflow データセットから約 20,000 件の質問にインデックスを付け、ユーザーがデータセットに対してフリーテキスト クエリを入力できるようにします。

スクリプトの各部分については後ほど詳しく説明しますが、まずはいくつかの例の結果を見てみましょう。多くの場合、この方法は、クエリとインデックス付けされた質問の間に強い単語の重複がない場合でも類似性を捉えることができます。

• 「ファイルを圧縮」と入力すると、「フォルダとファイルの圧縮/解凍」が返されます。

• 「何かが IP であるかどうかを判断する」は、「文字列が IP であるかホスト名であるかを判断する方法」を返します。

• 「バイトを倍精度浮動小数点数に変換する」は「Pythonでバイトを浮動小数点数に変換する」を返します。

実装の詳細

スクリプトは、 TensorFlow に埋め込みモデルをダウンロードして作成することから始まります。Google の Universal Sentence Encoder を選択しましたが、他の多くの埋め込み方法を使用することもできます。スクリプトは追加のトレーニングや微調整を行わずに、埋め込みモデルをそのまま使用します。

次に、質問のタイトル、タグ、およびベクトルとしてエンコードされた質問のタイトルのマッピングを含む Elasticsearch インデックスを作成します。

dense_vector のマッピングでは、ベクトルに含まれる次元の数を指定する必要があります。title_vector フィールドにインデックスを作成するとき、Elasticsearch はマッピングで指定されたのと同じ数のディメンションがあるかどうかを確認します。

ドキュメントのインデックスを作成するには、質問のタイトルを埋め込みモデルに渡して数値配列を取得します。この配列は、title_vector フィールドのドキュメントに追加されます。

ユーザーがクエリを入力すると、テキストは最初に同じ埋め込みモデルに渡され、パラメータ query_vector に保存されます。7.3 以降、Elasticsearch はネイティブ スクリプト言語でcosineSimilarity 関数を提供します。したがって、ユーザーのクエリとの類似性に基づいて質問をランク付けするには、script_score クエリを使用します。

新しいクエリごとにスクリプト () が再コンパイルされるのを避けるために、クエリ ベクトルをスクリプト パラメータとして渡すようにします。Elasticsearch では負のスコアが許可されないため、コサイン類似度に 1 を追加する必要があります。

|注:このブログ投稿では、元々、Elasticsearch 7.3 で使用可能だったベクトル関数の別の構文を使用していましたが、7.6 では非推奨になりました。|

重要な制限事項

script_score クエリは、制限的なクエリをラップし、返されるドキュメントのスコアを変更するように設計されています。ただし、match_all クエリを提供しているため、スクリプトはインデックス内のすべてのドキュメントに対して実行されます。これは、Elasticsearch におけるベクトル類似性の現在の制限です。ベクトルはドキュメントのスコアリングには使用できますが、最初の検索手順では使用できません。ベクトル類似性に基づく検索のサポートは、現在進行中の作業の重要な領域です。

すべてのドキュメントをスキャンすることを回避し、高速なパフォーマンスを維持するために、match_all クエリをより選択的なクエリに置き換えることができます。検索に使用する適切なクエリは、特定のユースケースによって異なる可能性があります。

上記ではいくつか有望な例を見てきましたが、結果にはノイズが多く直感的でない場合もあることに注意することが重要です。例えば、「ファイルを圧縮する」では、「部分的な.csproj」にも高いスコアが割り当てられます。ファイル」と「.pyc を回避する方法」ファイルですか？また、メソッドが予期しない結果を返す場合、その問題をデバッグする方法が必ずしも明確であるとは限りません。各ベクトル要素の意味は不透明であることが多く、解釈可能な概念に対応していません。単語の重複に基づく従来のスコアリング手法を使用すると、「なぜこのドキュメントのランクが高いのか」という質問に答えるのが簡単になることがよくあります。

前述のように、このプロトタイプは埋め込みモデルをベクトル フィールドで使用する方法の例として提供されており、本番環境で使用できるソリューションとして提供されているわけではありません。新しい検索戦略を開発するときは、一致クエリなどの強力なベースラインと比較しながら、独自のデータでそのアプローチがどのように機能するかをテストすることが重要です。確実な結果を得るには、ターゲット データセットの埋め込みモデルを微調整したり、単語レベルのクエリ拡張などの埋め込みを組み込むさまざまな方法を試したりするなど、戦略に大きな変更を加える必要がある場合があります。

結論

埋め込み技術は、テキストの言語コンテンツを取得する強力な方法を提供します。埋め込みをインデックス化し、ベクトル距離に基づいてスコアリングすることで、単語レベルの重複を超えた類似性の概念を使用してドキュメントを比較できます。

ベクター フィールド タイプに基づいた機能をさらに導入することを楽しみにしています。検索にベクトルを使用するのは、微妙で発展途上の領域です。いつものように、 Githubやディスカッション フォーラムで、皆さんの使用事例や体験談をお聞かせください。