新規ユーザーにとって、これは高品質なベクトル検索を最も迅速に開始する方法です。すでに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について詳しくはこちら

前回の記事で見たように、関数呼び出しによってもたらされる一貫性は、単に便利な最適化ではなく、不可欠なものです。構造的なエラーを評価ループから除去したところ、標準的なシナリオ（ティア4データセットなど）の結果が劇的に向上しました。

しかし、答えるべき明白な疑問はまだ残っています。

状況が本当に複雑になってきた場合でも、このアプローチは有効でしょうか？

現実世界におけるエンティティ解決が単純なケースで失敗することはめったにありませんが、名前が言語、文化、文字体系、時代、組織の境界を越える場合に失敗します。人が名前ではなく肩書きで言及されている場合、会社名が変更された場合、音訳が一貫していない場合、そして（スペルではなく）文脈だけが言及と現実世界の実体を結びつける唯一の要素である場合、この方法は失敗します。

そこで、このシリーズの最後の記事として、このシステムにいわば究極のチャレンジを課すこととしました。

なぜこれが究極の挑戦なのでしょうか？

以前の評価では、ますます複雑になるデータセットを用いてシステムをテストしました。前回の記事で触れた第4段階に到達する頃には、すでにニックネーム、称号、多言語名、意味的な参照などが混在する状況になっていました。これらのテストにより、アーキテクチャ自体は健全であることが示されましたが、信頼性の問題、特に不正な形式のJSONが原因で、リコールが抑制されていることがわかりました。

関数呼び出しの仕組みが整ったことで、ようやく安定した基盤ができました。そのおかげで、さらに興味深い質問をする機会が得られました。

1つの統一されたパイプラインで 多くの異なる種類のエンティティ解決問題を一度に処理することは可能でしょうか？

究極のチャレンジデータセットは、まさにその側面を徹底的に追求するために設計されました。

このデータセットは、（ニックネームや音訳といった）単一の困難に焦点を当てるのではなく、 50種類以上の異なる課題タイプを組み合わせています。

• 文化的な命名規則。

• タイトルに基づく参照。

• 事業上の関係性と過去の社名変更。

• 多言語および異文字表記での言及。

• 上記のうち複数を組み合わせた複合的な課題。

重要なのは、この試みが特定の狭い用途向けに最適化することではなく、ルールがエンティティごとに変化した場合でも設計パターンが通用するかどうかをテストすることです。

データセットの概要

究極のチャレンジデータセットは以下で構成されます。

• 個人、組織、機関などの50のエンティティ。

• 構造と言語の複雑さが異なる約60本の記事。

• 大きく以下に分類される51種類の異なるチャレンジカテゴリー。

  • 文化的な命名規則。

  • 肩書きと職務上の背景。

  • 事業と組織間の関係。

  • 多言語および音訳の課題。

  • 複合シナリオとエッジケースのシナリオ。

本シリーズの前半で、生成AIを用いてデータセットを作成することは諸刃の剣であることを確認しました。生成AIがなければ十分な規模と多様性を備えたテストデータを収集することは極めて困難になりますが、このモデルは放置すると、物事をあまりにも単純化しすぎる傾向があります。

例えば、初期世代の検証段階で、モデルに「ロシアの大統領」といったフレーズがウラジーミル・プーチンの明示的な別名として含まれていることが判明しました。それは今日では妥当に思えるかもしれませんが、文脈解決能力をテストするという目的を損なうことになります。記事が1990年代のロシアについて論じている場合はどうなるでしょうか？システムは、ハードコードされたエイリアスに頼るのではなく、文脈から正しいエンティティを推論するべきです。

そのため、このデータセットはショートカットが効かないように意図的に設計されています。システムが意味を推測することが想定されている場合、別名は明示的にリスト化されません。記述的なフレーズはエンティティにあらかじめリンクされていません。正確な一致は、単なるローカルテキストだけでなく、記事レベルの文脈によって決まることが多いです。

重要な注意点：本システムは多様なシナリオにおける機能を実証していますが、これはあくまで教育用プロトタイプです。実際の制裁対象組織の監視を扱う本番システムでは、追加の検証、コンプライアンスチェック、監査証跡、および機密性の高いユースケースに対する特別な処理が必要となります。

これらのシナリオが難しい理由

このシリーズの最初の投稿で、単純であいまいな例「新しいSwiftアップデートが登場しました！」を紹介しました。課題は、「Swift」という単語が、文脈によって複数の現実世界の実体として解釈される可能性があることです。この例はより広範な真実、つまり、自然言語は本質的に曖昧であるということを捉えています。

したがって、エンティティ解決は単なる文字列照合の問題ではありません。人間は日常的に、共通の知識、文化的規範、状況的文脈に頼って参照関係を解決していますが、私たちは自分がそうしていることにほとんど気づきません。

よくあるケースをいくつか考えてみましょう。

• 「大統領」という称号は地政学的・時間的な文脈なしには意味がありません。

• 会社名は、記事がいつ書かれたかによって、親会社、子会社、または以前のブランドを指す場合があります。

• 人名は、言語や文化によって、異なる順序、書体、または音訳で表記されることがあります。

• 同じフレーズでも、文脈によって異なる対象を指す場合があり、システムは一致を受け入れるのと同じくらい確信を持って一致を拒否できなければなりません。

これらすべてを適切に処理する単一のルールセットは存在しないため、このプロトタイプは懸念事項を非常に積極的に分離しています。

• Elasticsearchは候補の範囲を効率的かつ分かりやすく絞り込みます。

• LLMは、判断が必要で、それ自体を説明しなければならない場合にのみ使用されます。

• 検索と推論は別個のステップのままです。

課題の種類が多様化するにつれて、この区分けはさらに重要になります。

システムが特別なケースなしに多様性を処理する仕組み

この評価で最も興味深い結果の一つは、変更しなかった点にあります。

• 日本語名に関する特別なロジックは追加していません。

• アラビア語の父称に関するカスタムルールは追加していません。

• ハードコーディングされたマッピングを過去の会社名に追加していません。

その代わりに、このシステムはシリーズ前半で紹介したものと同じ主要要素に依存していました。

• セマンティック検索のためにインデックス化されたコンテキスト強化エンティティ。

• Elasticsearchでのハイブリッド検索（完全検索、エイリアス、セマンティック）。

• 少数の、明確に定義された一致候補セット。

• 関数呼び出しと最小スキーマによって制約されたLLM判断。

これは、システムの柔軟性が、増え続けるルールのコレクションからではなく、表現とアーキテクチャから生まれることを示唆しています。

システムが成功するのは、適切な候補が取得され、LLMが参照が特定のエンティティにマッピングされる（またはされない）理由を説明できる十分なコンテキストがある場合です。

結果：パフォーマンスの概要

究極のチャレンジデータセットにおいて、システムは以下のような全体的な結果を生み出しました。

• 精度：約91％

• 再現率：約86％

• F1スコア：約89%

• LLM合格率：約72％

チャレンジの種類ごとのパフォーマンス

チャレンジの種類ごとに結果を分解すると、強みと限界が明らかになります。

最も優れたパフォーマンス（F1スコア100%）が見られた分野は以下のとおりです。

• 文字体系間の照合（キリル文字、韓国語、中国語の企業名）。

• ヘブライ語のシナリオ（父称、専門職称、宗教称号、音写）。

• 事業階層構造（航空宇宙、多角化製造業、多部門企業）。

• 職業上の肩書き（学術、軍事、政治、宗教）。

• 複数の文字体系を含む日本語シナリオの組み合わせ。

優れたパフォーマンス（F1スコア80～99％）には以下が含まれます。

• 国際的な政治家（98％）。

• 歴史的な名称変更（90%）。

• 複雑なビジネス階層（89％）。

• 日本の企業名（93％）。

• 異言語間の音訳（86％）。

• アラビア語の父称（86％）。

より困難な分野には以下が含まれます。

• 高度な音訳（中国語、韓国語）：0% F1。

• 特定の日本語シナリオ（敬称、名前の順序、表記体系のバリエーション）：約67% F1。

• 一部のアラビア語のシナリオ（会社名、機関の参考文献）：約40％ F1。

ここで重要なのは、なぜシステムがこれらのケースで機能不全に陥ったのかという点です。失敗の原因は、全体的なアプローチが破綻したことではなく、特定のコンポーネントの限界、特に特定の多言語シナリオにおけるセマンティック検索に使用される高密度ベクトルモデルの限界にありました。

検索と判断が明確に分離されているため、パフォーマンスを向上させるためにシステムを書き換える必要はありません。より高性能な多言語埋め込みモデルの採用、エンティティコンテキストの強化、または検索戦略の洗練により、コアアーキテクチャを変更することなく、これらのカテゴリー全体で結果が向上します。

アーキテクチャーの観点から見ると、それが真の成功指標です。

この結果が設計について教えてくれること

シリーズを振り返ると、いくつかのパターンが際立っています。

• 準備は巧みなマッチングよりも重要です。 エンティティに事前にコンテキストを付加することで、後々の曖昧さを劇的に減らすことができます。

• LLMは、レトリバーではなく、判断者として最も価値があります。したがって、検索を求めるよりも、なぜ一致が意味をなすかを説明するよう求めることの方がはるかに強力です。

• 信頼性が精度を実現します。関数呼び出しは、JSONを整理しただけでなく、取得ステップにすでに潜在していた想起を解放しました。

• 一般化は専門化に勝ります。厳選された少数の抽象化によって、独自のロジックを必要とせずに数十種類の課題に対応できました。

これが、プロトタイプが意図的にElasticsearchネイティブであり、LLMの使用方法が意図的に保守的である理由です。目標は検索を置き換えることではなく、意味が重要な状況において、検索を説明可能なものにすることです。

結びに

究極のチャレンジとは、完璧な指標を追い求めることではなく、より根本的な問いに答えることでした。

透明性が高く、検索優先で、LLMを活用したアーキテクチャは、ルールやブラックボックスに陥ることなく、現実世界のエンティティの曖昧さを処理できるでしょうか？

その回答は、この教育用プロトタイプに関しては「はい」ですが、本番環境での強化、コンプライアンス、監視、データの品質に関する明確な注意事項があります。エンティティの一致が行われた理由を正当化する必要のあるシステムを構築している場合、このパターンは真剣に検討する価値があります。このシリーズを通して、エンティティ解決は必ずしも難解なものではないということが伝われば幸いです。適切に関心事を分離することで、それは論理的に考え、測定し、改善できるものになります。

この研究はまた、より広範なアーキテクチャパターンを示唆しています。浮かび上がってくるのは、古典的な検索拡張生成（RAG）の、わずかではあるが重要な進化です。検索結果を直接生成に供給するのではなく、明示的な評価ステップを導入します。LLMはまず、取得された候補を評価し、妥当性を確認するために使用され、承認された結果のみが生成の強化に使用されます。これは、Generation-Augmented Retrieval-Augmented Generation with Evaluation、つまりGARAGEと名付けられるでしょう。うまい頭字語が嫌いな人なんていませんから。

このパターンは、他にどのような用途で活用できるでしょうか？信頼性、透明性、そして論理的な説明を必要とするシステムは、まさにうってつけの候補と言えます。この分野における今後の研究は、今回得られた成果と同様に説得力のあるものとなるはずであり、コミュニティが今後どのような展開を見せるのか、非常に楽しみです。

次のステップ：試してみましょう

究極のチャレンジが実際に動作する様子をご覧になりたいですか？実際の実装、詳細な説明、実践的な例を含む完全なウォークスルーについては、Ultimate Challenge notebookを参照してください。

完全なエンティティ解決パイプラインにより、本番での使用に必要なコアコンセプトとアーキテクチャが示されています。これを基盤に、透明性と説明可能性を維持しながら、ニュース記事を監視し、エンティティの言及を追跡し、どのエンティティがどの記事に登場するのかについての質問に回答するシステムを構築できます。

1. 新しいSwiftアップデートが登場しました！開発者たちは新しい機能を試したがっています。

2. 新しいSwiftアップデートが登場しました！新しいアルバムは来月リリースされます。

この追加されたコンテキストにより、「Swift」という名前を正しいエンティティに解決できるはずです。

前回の投稿では、ウォッチリストを設定し、追加のコンテキストでエンティティを充実させました。上記の例を見ると、リストには少なくとも「Taylor Swift」と「Swift Programming Language」の2つのエンティティが必要です。また、テキストからエンティティの言及を抽出する方法も説明しました。これらの例はどちらも「Swift」を抽出します。これらの材料、強化された監視リスト、抽出されたエンティティが揃ったところで、いよいよショーの主役であるエンティティマッチングを紹介する準備が整いました。

注意：これは、エンティティマッチングの概念を教えるために設計された教育用プロトタイプです。本番システムは、異なる大規模言語モデル（LLM）、カスタムマッチングルール、特殊な判断パイプライン、または複数のマッチング戦略を組み合わせたアンサンブルアプローチを使用する可能性があります。

問題：マッチングが難しい理由

人間の言語とは驚くべきものです。その最も興味深い特性の1つは、その無限の創造性です。無限の数の新しい文を生成し、理解することができます。そうであるなら、エンティティ解決において正確な一致が稀なのも不思議ではありません。作家は可能な限り創造的であろうと努めます。エンティティが言及されるたびにフルネームを書いたり読んだりしなければならないとしたら、かなり面倒です。そのため、厳密な一致は簡単ですが、現実には、より洗練されたエンティティ解決アプローチが必要です。それは、人間の作者の無限の創造性に少なくとも部分的には対応できるほどに堅牢なアプローチであるべきです。そのため、私たちは問題を2つのステップに分けます。まずはElasticsearchを使用して大規模な候補を取得し、次にLLMを使用してそれらの候補が実際に同じ現実世界のエンティティを指しているかどうかを判断します。

解決策：透明性の高いLLM判断による3段階のマッチング

私たちはコンピューターの使い方におけるパラダイムシフトの真っ只中にあります。インターネットの台頭がローカルコンピューティングからグローバルに接続されたネットワークへと私たちを導いたように、生成AIはコンテンツ、コード、情報の作成方法を根本的に変えています。実際、このシリーズに付随する教育プロトタイプは、作者の慎重な指示のもと、LLMを使用してほぼ「バイブコーディング」のみで作成されました。これは、LLMが人間の言語に本来備わっている生産性を実現している、あるいは実現するだろうということと同義ではありませんが、エンティティ解決を支援する強力なリソースが手に入ったことを意味します。

生成AIでよく使うパターンは、Retrieval-Augmented Generation（RAG）です。ここにおいて、取得（retrieval）とは、エンティティ候補を取得すること（回答を生成することではない）を意味し、LLMは一致の評価と説明にのみ使用されます。エンドツーエンドのエンティティ解決についてLLMに支援を依頼することもできますが、これは時間と費用の両面でコストのかかるアプローチです。RAGは、より効率的な方法でLLMにコンテキストを提供することでLLMの作業を支援し、それによってLLMがエンティティ解決を効率的に支援できるようにします。

RAGの取得部分については、再びElasticsearchを利用します。まず、正確な一致、エイリアスとの一致、そしてキーワード検索とセマンティック検索を組み合わせたハイブリッド検索という組み合わせを使用して、潜在的な一致を検索します。一致する可能性のある項目が見つかったら、LLMに送信して判断を仰ぎます。LLMは最終的な一致評価者として機能します。また、LLMにその理由を説明させます。これは他のエンティティ解決システムとの重要な差別化要因です。これらの説明がなければ、エンティティ解決はブラックボックスになります。説明があれば、一致にどんな意味があるのか自分で確認できます。

主な概念：3段階マッチング、ハイブリッド検索、透過的なLLM判断

3段階マッチングとは？このプロジェクトの開始時に、セマンティック検索がシステムの重要な一部になるという仮説を立てましたが、すべての一致にこのような高度な検索が必要なわけではありません。効率的にマッチングを見つけるために、私たちは段階的なアプローチを取ります。まず、キーワード検索で正確な一致を確認します。そのような一致が見つかった場合、作業は完了し、先に進むことができます。完全一致が失敗した場合は、エイリアス一致を使用します。このプロトタイプでは、簡素化のために、キーワードとの完全一致によるエイリアスマッチングも行われています。本番環境では、正規化、翻字ルール、あいまい一致、またはキュレートされたエイリアステーブルを使用してこのステップを拡張する場合があります。それでも最初の2つのステップで一致する可能性のあるものが見つからない場合は、Elasticsearchの逆順位融合（RRF）を使用したハイブリッド検索によるセマンティック検索を導入します。

ハイブリッド検索とは？Elasticsearchでは、セマンティック検索を使用して、コンテキストを考慮した意味のある一致を見つけることができます。Elasticsearchは、ベクトル検索とハイブリッド検索に広く使用されています。セマンティック類似性は意味を理解する上で強力ですが、構造化されたフィルタリング（例えば、時間範囲、場所、または識別子による）の代替にはならず、正確な一致が利用可能な場合は多くの場合不必要です。Elasticsearchは語彙検索で名声を博しており、これはセマンティック検索が適さないタスクに最適です。両方のアプローチを最大限に活用するために、単一のハイブリッドクエリで語彙検索とセマンティック検索を併用します。次に、結果をマージして、RRFを使用して最も一致する可能性が高いものを見つけます。このプロトタイプでは、上位2つの結果が、LLM判定に送信できる潜在的な一致となります。

LLM判定を使用する理由とは？LLMの判断と説明により、システムは曖昧さとコンテキストを透過的に処理できます。これは「the president」のような場合において重要です。コンテキストによって複数のエンティティを指す可能性がありますが、システム内でニックネームや文化的なバリエーションをうまく機能させることもできます。最後に、制裁リストからエンティティを識別するなどのミッションクリティカルなタスクを検討する場合、システムを信頼するために、一致が受け入れられた理由を把握する必要があります。重要なのは、LLMはコーパス全体を検索せず、Elasticsearchによって返された少数の候補のみを評価するということです。

実際の結果：LLM推論によるマッチング

あらゆる自然言語処理タスクにおける大きな課題は、期待される結果が何であるかを示す「答えの鍵」となるゴールデンドキュメントを作成することです。これがなければ、システムがタスクをどの程度うまく実行するかを判断することはほぼ不可能ですが、そのようなドキュメントを作成するのは面倒なプロセスになる可能性があります。エンティティ解決のプロトタイプでは、テストに使用できるデータの設定に生成AIを再度利用しました。

まず、ニックネームや翻字などのいくつかのチャレンジタイプを定義し、次にLLMに、システムにとって徐々に大きく、より困難になる階層化されたデータセットコレクションを作成するように依頼しました。データセットの作成は期待していたほど簡単ではありませんでした。LLMでは、正解を得るのがあまりにも簡単すぎるため、「チート」が行われる傾向が強くなりました。例えば、あるチャレンジタイプは意味的なコンテキストに重点を置いています。このタイプには、「ロシアの作家」を「レフ・トルストイ」に解決することなどが含まれます。LLMは誤って「ロシアの作家」を「レフ・トルストイ」の別名として入力したため、一致を見つけるためのハイブリッド検索の必要性がなくなりました。

このような問題を修正するために何度かリファクタリングを行った結果、5つのデータセット層が使用できるようになりました。第1〜4層は徐々に規模が大きくなり、チャレンジの種類も増えました。第5層は「究極のチャレンジ」データセットで、すべてのチャレンジタイプから最も難しい例で構成されていました。すべてのテストデータは包括的な評価ディレクトリで利用可能です。

プロンプトベースのエンティティ解決アプローチを評価するため、私たちは第4層データセットに注目しました。重要な注意点は、エンティティの一致品質に焦点を当てることができるように、評価が制御された実験として実施されたことです。ウォッチリストデータは事前にコンテキストで強化されており、エンティティは事前に記事から抽出され、評価で抽出精度ではなくマッチングに重点が置かれることが保証されました。これにより、一致品質が分離されます。エンドツーエンドのパフォーマンスは、抽出リコールとエンリッチメント品質にも依存します。

評価データセット

第4層の評価データセットは、システムの機能の包括的なテストを提供します。[1]

• 監視リストのエンティティ：さまざまなタイプ（人、組織、場所）にわたる66個のエンティティ。

• テスト記事：実際のエンティティ解決シナリオを網羅した69件の記事。

• 予想される一致数：すべての記事で206件のエンティティが一致すると予想。

• チャレンジタイプ：エンティティ解決のさまざまな側面をテストする15種類のチャレンジタイプ。

データセットに含まれる課題の種類は以下の通りです。

• ニックネーム： 「ボブ・スミス」→「ロバート・スミス」（7つの記事）。

• 称号と敬称：「Dr. Sarah Williams」→「Sarah Williams」（5つの記事）。

• 意味的文脈： 「ロシアの作家」→「レフ・トルストイ」（8 つの記事）。

• 多言語名：異なる文字での名前の取り扱い（6つの記事）。

• 事業体：会社名のバリエーション（7つの記事）。

• 役員紹介： 「Microsoft CEO」→「Satya Nadella」（5つの記事）。

• 政治指導者：タイトルベースの参考文献（5つの記事）。

• イニシャル： 「J. Smith」→「John Smith」（3つの記事）。

• 名前の順序のバリエーション：さまざまな名前の順序付け規則（3つの記事）。

• 切り捨てられた名前：名前の一部一致（3つの記事）。

• 名前の分割：名前がテキストに分割（3つの記事）。

• スペース/ハイフンの欠落：書式のバリエーション（2つの記事）。

• 翻字：文字間の名前の一致（2つの記事）。

• 複合チャレンジ：1つの記事に複数のチャレンジ（6つの記事）。

• 複雑なビジネス：階層的なビジネス関係（5つの記事）。

プロンプトベースのエンティティ解決がどのように機能したか見てみましょう。

全体的なパフォーマンス

結果は、LLMを活用したマッチ評価には大きな可能性があることを示していますが、重大な信頼性の問題も明らかにしています。各候補ペアはLLMによって評価される必要があるため、構造化された出力の失敗により、検索が適切に機能している場合でも受け入れと呼び出しが抑制される可能性があります。

メトリック

値

精度

83.8%

リコール

62.6％

F1スコア

71.7％

見つかった一致の合計

344

LLM合格率

44.8％

エラー率

30.2%

エラー率の問題

このプロトタイプで最初に行うステップは、Elasticsearchを使用して潜在的な一致ペアを作成することであることを思い出してください。これらの潜在的な一致はそれぞれ、LLMによって評価される必要があります。これらすべての一致を効率的に処理するために、LLM呼び出しをバッチ処理します。これにより、APIのコストと待ち時間が削減されますが、出力に不正な形式のJSONが表示されるリスクも高まります。バッチサイズが大きくなると、JSONはより長く複雑になり、LLMが無効なJSONを生成する可能性が高くなります。これがエラー率30%となる原因です。評価では、リクエストごとに5つの一致のバッチサイズを使用しました。この保守的なバッチサイズでも、JSON解析エラーが発生し、評価結果が大幅に歪んでいます。

次のステップ：LLM統合の最適化

セマンティック検索とLLMによる判断を用いてエンティティをマッチングしたことで、完全なエンティティ解決パイプラインが完成しました。ただし、このアプローチでは、モデルの判断は正しいものの、その出力が使用できない場合に、新たな障害モードが発生します。LLM統合を最適化することで、信頼性とコスト効率を向上させることができます。次の投稿では、エラーとコストを削減しながら構造と型の安全性を保証する構造化出力に関数呼び出しを使用する方法について説明します。

はじめましょう

エンティティマッチングの実際の動作を確認したいですか？実際の実装、詳細な説明、実践的な例を含む完全なウォークスルーについては、エンティティマッチングノートブックを参照してください。このノートブックでは、3段階の検索、RRFを使用したハイブリッド検索、LLMを利用した推論による判断を使用してエンティティを一致させる方法を正確に示します。

注意：これは、概念を教えるために設計された教育用プロトタイプです。本番システムを構築するときは、モデルの選択、コストの最適化、レイテンシ要件、品質検証、エラー処理、監視など、教育に重点を置いたこのプロトタイプではカバーされていない追加の要素を考慮してください。

メモ

1. これらのデータセットは合成されたもので教育用に設計されており、実際の課題に近似していますが、単一の本番ドメインを代表するものではありません。

この記事では、最小スコアパラメータを使用して、セマンティック検索結果の精度を高める方法を学びます。このブログ記事で示された例を試したい場合は関連するJupyterノートブックをご覧ください。

背景：精度と再現率

検索の関連性において、精度と再現率は重要な概念です。まだご存知でない読者の方は、これについて一読されることをおすすめします。以下は要約です。

• 精度：返される検索結果のうち、ユーザーに関連するものの割合。

• 再現率：コーパス内のすべての関連ドキュメントのうち、検索結果セットに含まれるドキュメントの割合。

つまり、言い換えれば、精度とは関連する結果のみを返すことであり、再現率はすべての関連する結果を返すことです。ご想像のとおり、これらは競合する要件であることが多いです。セマンティック検索は再現率が非常に高い傾向がありますが、精度に問題が生じる可能性があります。以下では、この特性について説明します。

最小スコアパラメーターの導入

「min_score」パラメーターを使用すると、最小スコアを設定して精度を向上させることができます。これにより、定義されたしきい値未満のスコアを持つ一致が削除され、結果セットが切り捨てられます。以下は簡単な例です。

スコアの正規化

最小スコアを設定するのは良いことですが、すべてのセマンティックモデルが静的しきい値に適したスコアを返すわけではありません。例えば、ELSERは無制限のスコアを返します。一部の高密度モデルのスコアは密集してクラスター化されており、特定のクエリのコンテキストでのみ意味を持ちます。

ほとんどのセマンティック検索では、「min_score」を適用する前に正規化アプローチを使用することをお勧めします。正規化により、ドキュメントのスコアが定義された範囲内に収まるようになります。Elasticsearchレトリバーは、「l2_norm」と「minmax」という2つの正規化機能を提供します。最もよく使用されるのは「minmax」です。これは理解しやすく、多くのシナリオでうまく機能するためです。「minmax」の主な特性は次のとおりです。

• ドキュメントのスコアは0から1の間で配分されます。

• 最も高いスコアを持つドキュメントには常に1のスコアが付けられます。

• 最も低いスコアを持つドキュメントには常に0のスコアが付けられます。

  • これにより、キーワード検索に適さなくなる可能性があります。詳細については「ハイブリッド検索」セクションをご覧ください。

以下は、 min_scoreを使用した正規化されたセマンティッククエリの例です。ランクウィンドウのサイズが500に増え、100から始まるより長い検索結果のリストを返すことができます。

サイズは、通常の本番環境で見られるサイズよりも高い値に設定されています。これは、検索結果の品質を検査し、結果を調整できるようにするためです。

線形レトリバーを使用したハイブリッド検索

ハイブリッド検索の場合、最も簡単な方法は、すべてのスコアを正規化し、重みを割り当て、最小スコアを適用することです。合計が1になる重みを選択すると、合計スコアが0～1の範囲内に保たれることに注意してください。これにより、最終スコアの理解やmin_scoreのチューニングが容易になります。以下はその例です。

RRFを使用したハイブリッド検索

BM25では、多くの場合、 AND演算子やminimum_should_matchを使用するなど、他の手段で精度を制御します。さらに、単一で、正確で、まれな用語からなるクエリは、自然に検索結果の少ない検索結果を引き起こし、多くの場合、すべてが非常に関連性の高いものです。これにより、次のことが発生する可能性があります。

• 絶対的なBM25スコアが最大スコアのヒットに近い場合でも、結果内のさらに後ろの結果にはBM25レトリバーで低い正規化スコアが割り当てられます。

• 非常に低いBM25スコアをセマンティックスコアに追加すると、合計がセマンティックスコアとして近似されます。

• BM25スコアの寄与が不足すると、ドキュメントがmin_score thresholdによって破棄される可能性があります。

解決策として、BM25とセマンティック結果を組み合わせるために、逆順位融合（RRF）を使用することができます。RRFは、各結果セット内の位置に焦点を当てることで、異なる検索アルゴリズムのスコアを比較するという課題を回避します。この場合、min_scoreはセマンティックレトリバーにのみ適用されます。

まとめ

min_scoreを使用することで、セマンティック検索アルゴリズムの高い再現率によって引き起こされる結果セット内の誤検出の数を減らす方法を示しました。レトリバーの詳細については、こちらのブログ記事とElasticsearchのドキュメントをご覧ください。

カスタムコネクターを使用すると、既存のChatGPTコネクターをElasticsearchなどの追加のデータソースと組み合わせて、包括的な回答を得ることができます。

この記事では、内部のGitHubの課題とプルリクエストに関する情報を含むElasticsearchインデックスにChatGPTを接続するMCPサーバーを構築します。これにより、Elasticsearchデータを使用して自然言語クエリに回答できるようになります。

Google ColabのFastMCPとngrokを使ってMCPサーバーをデプロイし、ChatGPTが接続できる公開URLを取得し、複雑なインフラ構築の必要性を排除します。

MCPとそのエコシステムの包括的な概要については、MCPの現在の状態をご参照ください。

要件

始める前に必要なものは次のとおりです。

• Elasticsearchクラスター（8.X以降）

• インデックスへの読み取りアクセス権を持つ Elasticsearch APIキー

• Googleアカウント（Google Colab用）

• Ngrokアカウント（無料プランでも可）

• Pro/Enterprise/BusinessまたはEduプランのChatGPTアカウント

ChatGPT MCPコネクターの要件を理解する

ChatGPT MCPコネクターには、searchとfetchの2つのツールを実装する必要があります。詳細については、OpenAIドキュメントをご覧ください。

検索ツール

ユーザークエリに基づいて、Elasticsearchインデックスから関連する結果のリストを返します。

受け取るもの：

• ユーザーの自然言語クエリを含む単一の文字列。

• 例：「Elasticsearch移行に関連するイシューを見つけて」

返されるもの：

• 結果オブジェクトの配列を含むresultキーを持つオブジェクト。各結果には以下が含まれます。

  • id - 一意の文書識別子

  • title - イシューまたはPRタイトル

  • url - イシュー/PRへのリンク

実装内容：

フェッチ・ツール

特定の文書の完全な内容を取得します。

受け取るもの：

• 検索結果からElasticsearch文書IDを入力する単一の文字列

• 例：「PR-578の詳細を教えてください。」

返されるもの：

• 以下を含む完全な文書オブジェクト：

  • id - 一意の文書識別子

  • title - イシューまたはPRタイトル

  • text - 完全なイシュー・PRの説明と詳細

  • url - イシュー/PRへのリンク

  • type - 文書の種類（issue, pull_request）

  • status - 現在のステータス（open, in_progress, resolved）

  • priority - 優先度レベル（low, medium, high, critical）

  • assignee - イシュー/PRの担当者

  • created_date - 作成された時期

  • resolved_date - 解決された時期（該当する場合）

  • labels 文書に関連するタグ

  • related_pr - 関連するプルリクエストID

注：この例では、すべてのフィールドがルートレベルにあるフラット構造を使用しています。OpenAIの要件は柔軟で、ネストされたメタデータオブジェクトもサポートしています。

GitHubのデータセットとプルリクエストデータセット

このチュートリアルでは、イシューとプルリクエストを含む内部GitHubデータセットを使用します。これは、ChatGPTを通じてプライベートな内部データをクエリするシナリオを表しています。

データセットはこちらからご覧いただけます。そして、Bulk APIを使ってデータのインデックスを更新します。

このデータセットには以下が含まれます。

• 説明、ステータス、優先順位、担当者に関する問題

• コード変更、レビュー、導入情報を含むプルリクエスト

• イシューとPRの関係（例：PR-578がISSUE-1889を修正）

• ラベル、日付、その他のメタデータ

インデックスマッピング

インデックスは、ELSERとのハイブリッド検索をサポートするために以下のマッピングを使用します。text_semanticはセマンティック検索に使用され、他のフィールドはキーワード検索を可能にします。

MCPサーバーを構築する

当社のMCPサーバーは、OpenAI仕様に従って2つのツールを実装しています。ハイブリッド検索を使用してセマンティックマッチングとテキストマッチングを組み合わせることで、より良い結果が得られます。

検索ツール

RRF（相互ランク融合）を用いたハイブリッド検索を使用し、セマンティック検索とテキストマッチングを組み合わせています。

主なポイント：

• RRFを用いたハイブリッド検索： より良い結果を得るために、セマンティック検索（ELSER）とテキスト検索（BM25）を組み合わせます。

• 複数一致クエリ：ブースティングを使用して複数のフィールドを検索します（title^3, text^2, assignee^2）。キャレット記号（^）は関連性スコアを乗算し、コンテンツよりもタイトルの一致を優先します。

• あいまい一致： fuzziness: AUTO は近似一致を許可することでタイプミスやスペルミスを処理します。

• RRFのパラメーター調整：

  • rank_window_size: 50 - マージする前に、各リトリーバー（セマンティックとテキスト）からの上位結果をいくつ考慮するかを指定します。

  • rank_constant: 60 - この値は、個々の結果セット内の文書が最終的なランク付け結果にどの程度影響を与えるかを決定します。

• 必須フィールドのみを返す： id、title、urlはOpenAIの仕様に従い、追加のフィールドを不必要に公開しないようにします。

フェッチ・ツール

文書IDが存在する場合は、そのIDで文書の詳細を取得します。

主なポイント：

• 文書IDのフィールドで検索：カスタム idフィールドに用語クエリを使用します

• 完全な文書を返す： すべてのコンテンツを含む完全なtextフィールドが含まれます

• フラットな構造：すべてのフィールドがルートレベルにあり、Elasticsearchのドキュメント構造に一致します。

Google Colabにデプロイする

Google Colabを使用してMCPサーバーを実行し、ngrokで公開することで、ChatGPTが接続できるようにします。

ステップ1：Google Colabノートブックを開く

事前設定されたノートブックElasticsearch MCP for ChatGPTにアクセスします。

ステップ2：認証情報を設定する

次の3つの情報が必要になります。

• Elasticsearch URL：お客様のElasticsearchクラスタリングURL。

• Elasticsearch API キー：インデックスへの読み取りアクセス権を持つAPIキー。

• Ngrok認証トークン：ngrokからの無料トークン。ngrokを使ってMCPのURLをインターネットに公開し、ChatGPTが接続できるようにします。

ngrokトークンの取得

1. ngrokで無料アカウントに登録します。

2. ngrokダッシュボードにアクセスします。

3. 認証トークンをコピーします。

Google Colabにシークレットを追加する

Google Colabノートブック内で：

1. 左側のサイドバーにあるキーアイコンをクリックして、シークレットを開きます。

2. 次の3つのシークレットを追加します。

3. 各シークレットのノートブックアクセスを有効にします。

ステップ3：ノートブックを実行する

1. ランタイムをクリックし、次にすべて実行をクリックして、すべてのセルを実行します。

2. サーバーの起動を待ちます（約30秒）。

3. 公開ngrok URLを示す出力を探します。

4. 出力は次のようになります。

ChatGPTに接続する

次に、MCPサーバーをあなたのChatGPTアカウントに接続します。

1. ChatGPTを開き、設定に移動します。

2. コネクターに移動します。Proアカウントを使用している場合は、コネクタで開発者モードをオンにする必要があります。

ChatGPT EnterpriseまたはBusinessを使用している場合は、コネクターを職場に公開する必要があります。

3. 作成をクリックします。

注：Business、Enterprise、Eduワークスペースでは、ワークスペースの所有者、管理者、およびそれぞれの設定が有効になっているユーザー（Enterprise/Eduの場合）のみがカスタムコネクターを追加できます。通常のメンバーロールのユーザーには、自分でカスタムコネクターを追加する権限がありません。

コネクターが所有者または管理者ユーザーによって追加され有効化されると、ワークスペースのすべてのメンバーが使用できるようになります。

4. 必要な情報と、/sse/で終わるngrokのURLを入力します。「sse」の後の「/」に注意してください。これがない場合、動作しません。

• Name: Elasticsearch MCP

• Description: GitHubの内部情報を検索および取得するためのカスタムMCP。

5. 作成を押してカスタムMCPを保存します。

サーバーが稼働していれば、接続は瞬時に完了します。追加の認証は不要で、Elasticsearch APIキーはサーバー上で設定されています。

MCPサーバーをテストする

質問する前に、ChatGPTが使用するコネクターを選択する必要があります。

プロンプト1：イシューを検索する

「Elasticsearchの移行に関連するイシューを見つけて」と質問し、アクションツールの呼び出しを確認します。

ChatGPT はクエリを使用してsearchツールを呼び出します。利用可能なツールを検索し、Elasticsearchツールを呼び出す準備をし、ツールに対して何らかのアクションを実行する前にユーザーに確認していることがわかります。

ツール呼び出しリクエスト：

ツールの応答：

ChatGPTは結果を処理し、自然で会話的な形式で提示します。

仕組み

プロンプト：「Elasticsearch移行に関連するイシューを見つけて」

1. ChatGPTの呼び出し search(“Elasticsearch migration”)

2. Elasticsearchがハイブリッド検索を実行する

• セマンティック検索は「アップグレード」や「バージョン互換性」などの概念を理解します。

• テキスト検索で「Elasticsearch」と「migration」の完全一致を見つけます。

• RRFは両方のアプローチの結果を組み合わせてランク付けします。

3. id、titleを含むトップ10のマッチングイベントを返します。 url

4. ChatGPTは「ISSUE-1712: migrate from Elasticsearch 7.x to 8.x」を最も関連性の高い結果として特定します。

プロンプト2：完全な詳細を取得する

質問：「ISSUE-1889の詳細を教えて」

ChatGPTは、あなたが特定のイシューに関する詳細な情報を求めていることを認識し、fetchツールを呼び出し、ツールに対して何らかのアクションを起こす前にユーザーに確認します。

ツール呼び出しリクエスト：

ツールの応答：

ChatGPTは情報を統合し、明確に提示します。

仕組み

プロンプト：「ISSUE-1889の詳細を教えて」

1. ChatGPT呼び出し fetch(“ISSUE-1889”)

2. Elasticsearchが完全な文書を取得する

3. すべてのフィールドがルートレベルにある完全な文書を返す

4. ChatGPTは情報を統合し、適切な引用で回答する

まとめ

この記事では、専用の検索およびフェッチMCPツールを使用してChatGPTをElasticsearchに接続するカスタムMCPサーバーを構築し、プライベートデータに対する自然言語クエリを可能にしました。

このMCPパターンは、自然言語を使用してクエリしたい任意のElasticsearchインデックス、ドキュメント、製品、ログ、またはその他のデータで機能します。

スコア範囲の問題

まず最初に、ハイブリッド検索が困難になる主な理由の 1 つである、スコア範囲の多様性について確認しましょう。私たちの古い友人BM25は無制限のスコアを生成します。言い換えれば、BM25 は 0 に近い値から (理論的には) 無限大までの範囲のスコアを生成できます。対照的に、 dense_vectorフィールドに対するクエリでは、0 から 1 の範囲のスコアが生成されます。この問題をさらに悪化させるのは、 semantic_text埋め込みのインデックス作成に使用されるフィールド タイプが難読化されるため、インデックスと推論エンドポイントの構成に関する詳細な知識がない限り、クエリのスコアの範囲がどうなるかを判断するのが難しい場合があることです。これは、語彙検索結果と意味検索結果をインターリーブしようとするときに、意味検索結果の関連性が高い場合でも、語彙検索結果が意味検索結果よりも優先される可能性があるため、問題が発生します。この問題に対する一般的に受け入れられている解決策は、結果をインターリーブする前にスコアを正規化することです。Elasticsearch には、これを実行するためのツールとして、線形リトリーバーとRRFリトリーバーの 2 つがあります。

RRFリトリーバーは、ドキュメントのランクを関連性の尺度として使用し、スコアを破棄して、 RRF アルゴリズムを適用します。スコアは考慮されないため、スコア範囲の不一致は問題になりません。

線形リトリーバーは線形結合を使用してドキュメントの最終スコアを決定します。これには、ドキュメントの各コンポーネント クエリのスコアを取得し、それを正規化し、合計して合計スコアを生成することが含まれます。数学的には、この操作は次のように表現できます。

ここで、 Nは正規化関数であり、SX はクエリ X のスコアです。ここで重要なのは正規化関数です。正規化関数は各クエリのスコアを同じ範囲を使用するように変換します。リニア リトリーバーの詳細については、こちらをご覧ください。

詳しく見てみる

ユーザーはこれらのツールを使用して効果的なハイブリッド検索を実装できますが、インデックスに関するある程度の知識が必要です。線形リトリーバーを使用して、2 つのフィールドを持つインデックスをクエリする例を見てみましょう。

1. semantic_text_fieldは、テキスト埋め込みモデルであるE5を使用するsemantic_textフィールドです。

2. text_fieldは標準のtextフィールドです

1. Elasticsearch 8.18/9.0でサポートされたsemantic_textフィールドでmatchクエリを使用します。

クエリを構築するときは、 semantic_text_fieldテキスト埋め込みモデルを使用するため、このクエリでは 0 から 1 の間のスコアが生成されることに留意する必要があります。また、 text_fieldは標準のtextフィールドであるため、これに対するクエリによって無制限のスコアが生成されることも知っておく必要があります。適切な関連性を持つ結果セットを作成するには、クエリ スコアを結合する前に正規化するリトリーバーを使用する必要があります。この例では、 minmax正規化を備えた線形リトリーバーを使用して、各クエリのスコアを 0 から 1 の間の値に正規化します。

この例のクエリ構築は、関係するフィールドが 2 つだけなので、非常に簡単です。ただし、さまざまなタイプのフィールドが追加されると、すぐに複雑になる可能性があります。これは、効果的なハイブリッド検索クエリを記述するには、クエリ対象のインデックスに関するより深い知識が必要になることが多く、組み合わせる前にコンポーネント クエリ スコアが適切に正規化される必要があることを示しています。これは、ハイブリッド検索のより広範な導入の障害となります。

クエリのグループ化

例を拡張してみましょう。1 つのtextフィールドと 2 つのsemantic_textフィールドをクエリしたい場合はどうなるでしょうか。次のようなクエリを作成できます。

表面的には良さそうですが、潜在的な問題があります。これで、 semantic_textフィールドの一致が合計スコアの 2/3 を占めることになります。

これは、不均衡なスコアを作成するため、おそらく望ましい結果ではありません。この例のようにフィールドが 3 つしかない場合、影響はそれほど顕著ではないかもしれませんが、より多くのフィールドをクエリすると問題が生じます。例えば、ほとんどの索引には意味フィールド（つまりdense_vector 、 sparse_vector 、またはsemantic_text )。上記のパターンを使用して、9 つの語彙フィールドと 1 つの意味フィールドを持つインデックスをクエリするとどうなるでしょうか?語彙の一致がスコアの 90% を占めることになり、意味検索の有効性が鈍ってしまいます。

これに対処する一般的な方法は、クエリを語彙と意味のカテゴリにグループ化し、その 2 つに均等に重み付けすることです。これにより、どちらかのカテゴリーが合計スコアを支配することが防止されます。

それを実践してみましょう。この例では、線形リトリーバーを使用する場合、グループ化されたクエリのアプローチはどのようになるでしょうか?

うわー、これは冗長になってきましたね!クエリ全体を確認するには、上下に何度もスクロールする必要があったかもしれません。ここでは、2 つのレベルの正規化を使用してクエリ グループを作成します。数学的には次のように表現できます。

この 2 番目のレベルの正規化により、 semantic_textフィールドとtextフィールドに対するクエリが均等に重み付けされるようになります。この例では、語彙フィールドが 1 つしかないため、 text_fieldの 2 番目のレベルの正規化を省略し、冗長性をさらに軽減していることに注意してください。

このクエリ構造はすでに扱いにくく、クエリするフィールドは 3 つだけです。より多くのフィールドをクエリするにつれて、熟練した検索実践者にとっても管理がますます困難になります。

複数フィールドのクエリ形式

これらすべてを簡素化するために、Elasticsearch 8.19、9.1、 サーバーレスの 線形および RRF リトリーバーに マルチフィールド クエリ形式 を追加しました。次のようにするだけで、上記と同じクエリを実行できます。

これにより、クエリが 55 行から 9 行に短縮されます。Elasticsearch はインデックス マッピングを自動的に使用して次の処理を実行します。

• クエリされた各フィールドのタイプを決定する

• 各フィールドを語彙または意味のカテゴリにグループ化します

• 最終スコアでは各カテゴリーを均等に重み付けする

これにより、使用されるインデックスや推論エンドポイントの詳細を知らなくても、誰でも効果的なハイブリッド検索クエリを実行できるようになります。

RRF を使用する場合、ランクは関連性の代理として使用されるため、 normalizerを省略できます。

フィールドごとのブースティング

リニア リトリーバーを使用する場合、フィールドごとにブーストを適用して、特定のフィールドでの一致の重要度を調整できます。たとえば、2 つのsemantic_textフィールドと 2 つのtextフィールドの 4 つのフィールドをクエリするとします。

デフォルトでは、各フィールドはグループ内（語彙または意味）で均等に重み付けされます。スコアの内訳は次のようになります。

つまり、各フィールドは合計スコアの 25% を占めます。

field^boost構文を使用して、任意のフィールドにフィールドごとのブーストを追加できます。semantic_text_field_1とtext_field_1に2のブーストを適用してみましょう。

スコアの内訳は次のようになります。

各クエリ グループの重みは均等ですが、グループ内のフィールドの重みは次のように変更されました。

• semantic_text_field_1 セマンティッククエリグループスコアの66％、合計スコアの33％

• text_field_1 語彙質問グループスコアの66％、総スコアの33％

ℹ️ フィールドごとのブーストを適用しても、合計スコアの範囲は変更されないことに注意してください。これはスコア正規化の意図された副作用であり、語彙クエリスコアと意味クエリスコアが互いに直接比較可能のままになることを保証します。

ℹ️ フィールドごとのブースティングは、Elasticsearch 9.2 以降の RRF リトリーバーでも使用できます。

ワイルドカード解決

複数のフィールドを一致させるには、 fieldsパラメータで*ワイルドカードを使用できます。上記の例を続けると、このクエリは機能的にはemantic_text_field_1 、 semantic_text_field_2 、 text_field_1明示的にクエリすることと同等です。

興味深いことに、 *_field_1パターンはtext_field_1とsemantic_text_field_1の両方に一致します。これは自動的に処理され、各フィールドが明示的にクエリされたかのようにクエリが実行されます。semantic_text_field_1が両方のパターンに一致することも問題ありません。すべてのフィールド名の一致は、クエリの実行前に重複が排除されます。

ワイルドカードはさまざまな方法で使用できます。

• プレフィックス一致（例： *_text_field ）

• インラインマッチング（例： semantic_*_field ）

• サフィックス一致（例： semantic_text_field_* ）

*_text_field_*のように、複数のワイルドカードを使用して上記の組み合わせを適用することもできます。

デフォルトのクエリフィールド

マルチフィールド クエリ形式を使用すると、何も知らないインデックスをクエリすることもできます。fieldsパラメータを省略すると、 index.query.default_field インデックス設定で指定されたすべてのフィールドがクエリされます。

デフォルトでは、 index.query.default_fieldは*に設定されています。このワイルドカードは、用語クエリをサポートするインデックス内のすべてのフィールド タイプ (ほとんど) に解決されます。例外は次のとおりです:

• dense_vector フィールド

• rank_vector フィールド

• ジオメトリフィールド: geo_point 、 shape

この機能は、サードパーティが提供するインデックスに対してハイブリッド検索クエリを実行する場合に特に便利です。マルチフィールド クエリ形式を使用すると、適切なクエリを簡単な方法で実行できます。fieldsパラメータを除外するだけで、該当するすべてのフィールドが照会されます。

まとめ

スコア範囲の問題により、特にクエリ対象のインデックスや使用中の推論エンドポイントに関する情報が限られている場合、効果的なハイブリッド検索の実装が困難になる可能性があります。リニア リトリーバーと RRF リトリーバーのマルチフィールド クエリ形式では、自動化されたクエリ グループ化ベースのハイブリッド検索アプローチをシンプルで使いやすい API にパッケージ化することで、この煩わしさを軽減します。フィールドごとのブースト、ワイルドカード解決、デフォルトのクエリ フィールドなどの追加機能により、機能が拡張され、多くのユース ケースをカバーできます。

今すぐマルチフィールドクエリ形式をお試しください

無料トライアル では、完全に管理された Elasticsearch Serverless プロジェクトで、マルチフィールド クエリ形式を使用した線形リトリーバーと RRF リトリーバーを試すことができます。8.19 および 9.1 以降のスタック バージョンでも利用できます。

1 つのコマンドでローカル環境で数分以内に開始できます。

検索は死んでいない、ただ移動しただけだ

そのため、主にテキスト ボックスでコンテキストを検索し、返された情報 (コンテキスト) を使用して自分で回答を構築するという方法から、自然言語を使用してエージェントに必要なものを伝え、エージェントが自動的に回答を調査してまとめる方法へと移行しました。テクノロジー業界の多くの人々は、この変化を指摘し、「検索は死んだ」と主張しています（まあ、SEO とアドワーズの世界は確実に変化しています。GEOはどうですか？）。しかし、検索は依然として代理店の業務にとって絶対に不可欠です。ただ、現在では主にツールを介して目に見えない形で実行されているだけです。

以前は、主観的な関連性の主な判断者は人間でした。各ユーザーには検索を実行する独自の理由があり、個人的な経験が結果の相対的な正確性に影響を与えていました。エージェントが私たちと同じ（あるいはそれ以上の）結論に達することができると信頼するには、エージェントがアクセスできるコンテキスト情報が私たちの主観的な意図に可能な限り近いことを保証する必要があります。私たちはその目標に向けて、LLM に提供するコンテキストを設計する必要があります。

ハイブリッド検索によるコンテキストの生成

パート I でもう一度お伝えしましたが、Elastic のハイブリッド検索は、従来のキーワードベースの検索の強み (構文の柔軟性、キーワードの精度、関連性のスコアリング) とベクトル類似性検索の意味理解を組み合わせ、複数の再ランキング手法を提供します。この相乗効果（この言葉のより正確な使い方はこれまで見つかりませんでした！）クエリによってコンテンツをターゲットする方法がより細かく指定できるため、関連性の高い結果を得ることができます。主観的関連性を検索段階の1 つとして適用できるというだけでなく、実際には、第 1 段階の検索に関連性スコアリングを他のすべてのモードとともに一度に含めることができるのです。

優れた精度と効率

分散検索、取得、再ランク付け機能を備えたデータ プラットフォームを主要なコンテキスト検索エンジンとして使用することは、非常に理にかなっています。高度なクエリ構文を使用して、主観的な意図の欠落したコンポーネントを追加し、返されるコンテキスト情報の価値を損なったり不明瞭にしたりする可能性のあるコンテンツを除外できます。利用可能な個々の構文オプションから選択することも、モダリティを単一の検索に組み合わせて、各データの種類を最もよく理解できる方法でターゲットにし、それらを再ランク付けして組み合わせたり並べ替えたりすることもできます。不要なデータを除外し、必要なフィールド/値のみが含まれるように応答をフィルタリングできます。エージェントにとって、このターゲティングの柔軟性により、コンテキストを非常に正確に取得できるツールを構築できます。

コンテキストの洗練（集約と非コンテンツシグナル）

集約は、ツールがコンテキスト ウィンドウに配信するコンテンツを形成する際に特に役立ちます。集計により、返されるコンテキスト データの形状に関する数値ベースの事実が自然に提供されるため、LLM による推論がより容易かつ正確になります。集計は階層的にネストできるため、LLM に複数レベルの詳細を追加して、より微妙な理解を深めることが簡単にできます。集計はコンテキスト ウィンドウのサイズの管理にも役立ちます。10 万件のドキュメントのクエリ結果を、集約された分析情報の数百トークンに簡単に減らすことができます。

非コンテンツ シグナルは、データに内在する指標であり、見ているものの全体像を示します。つまり、人気、鮮度、地理的位置、カテゴリ、ホストの多様性、価格帯など、結果の追加特性です。これらの情報は、エージェントが受け取ったコンテキストの重要性をどのように評価するかをエージェントに通知するのに役立ちます。これを最もよく説明するために、いくつかの簡単な例を挙げます。

• 最近公開されたコンテンツや人気コンテンツの強化- 記事のナレッジ ベースがあると想像してください。ユーザーのクエリに関連する記事を見つけたいが、最近の記事であり、他のユーザーに役立つと判断された記事（「いいね」の数が多いなど）を優先したいとします。このシナリオでは、ハイブリッド検索を使用して関連する記事を見つけ、公開日と人気度の組み合わせに基づいて記事を再ランク付けすることができます。

• 売上と在庫調整を伴う電子商取引の検索- 電子商取引の設定では、検索語に一致する製品を顧客に表示したいだけでなく、売れ行きがよく在庫がある製品を宣伝したいとも考えます。顧客の不満を避けるために、在庫が少ない商品のランクを下げることもできます。

• バグ トラッカーで重大度の高い問題を優先する- ソフトウェア開発チームにとって、問題を検索する際には、重大度が高く、優先度が高く、最近更新された問題を最初に表示することが重要です。「重要度」や「最も議論されている」などの非シグナルを使用して、さまざまな要素を個別に評価し、最も重要で活発に議論されている問題が最上位に表示されるようにすることができます。

これらのサンプルクエリおよびその他の詳細は、付属の Elasticsearch Labsコンテンツ ページにあります。

セキュリティ強化

コンテキストエンジニアリングに Elastic のような検索を活用したスピードレイヤーを活用する重要な利点は、セキュリティ フレームワークが組み込まれていることです。Elastic のプラットフォームは、きめ細かなロールベースのアクセス制御 (RBAC) と属性ベースのアクセス制御 (ABAC) を通じて、エージェントおよび生成 AI オペレーションに提供されるコンテキストが機密性の高い非公開情報を尊重して保護することを保証します。これは、クエリが効率的に処理されるだけでなく、エージェントまたはリクエストを開始したユーザーの特定の権限に応じて結果がフィルタリングされることを意味します。

エージェントは認証されたユーザーとして実行されるため、プラットフォームに組み込まれたセキュリティ機能を通じてセキュリティが暗黙的に適用されます。

• きめ細かな権限:ドキュメント、フィールド、さらには用語レベルでアクセスを定義し、AI エージェントが表示を許可されているデータのみを受信するようにします。

• ロールベースのアクセス制御 (RBAC):エージェントまたはユーザーにロールを割り当て、定義された責任に基づいて特定のデータセットまたは機能へのアクセスを許可します。

• 属性ベースのアクセス制御 (ABAC):データ、ユーザー、または環境の属性に基づいて動的なアクセス ポリシーを実装し、適応性の高いコンテキスト認識型のセキュリティを実現します。

• ドキュメント レベルのセキュリティ (DLS) とフィールド レベルのセキュリティ (FLS):これらの機能により、取得したドキュメント内でも許可された部分のみが表示されるようになり、機密情報の漏洩を防止できます。

• エンタープライズ セキュリティとの統合:既存の ID 管理システム (LDAP、SAML、OIDC など) とシームレスに統合し、組織全体で一貫したセキュリティ ポリシーを適用します。

これらのセキュリティ対策をコンテキスト取得メカニズムに直接統合することで、Elastic は安全なゲートキーパーとして機能し、AI エージェントが定義されたデータ境界内で動作し、不正なデータ公開を防ぎ、データプライバシー規制へのコンプライアンスを維持できるようにします。これは、機密情報や独自情報を扱うエージェント AI システムへの信頼を構築する上で非常に重要です。

追加のボーナスとして、エンタープライズ データ ソース上で統合されたデータ スピード レイヤーを使用することで、エージェント ツールによって作成されるリポジトリでの予期しないアドホック クエリ負荷を軽減できます。ほぼリアルタイムであらゆるものを検索できる単一の場所と、セキュリティとガバナンスの制御を適用できる単一の場所が提供されます。

ハイブリッド検索ベースのツール

Elastic プラットフォームには、コンテキスト エンジニアリングの追求を加速させるコア機能がいくつかあります (今後もさらに増える予定です)。ここで重要なのは、このプラットフォームが、AI エコシステムの進化に合わせて方法を適応、変更、拡張できる柔軟性を備え、さまざまな達成方法を提供していることです。

エージェントビルダーの紹介

Elastic Agent Builder は、Elastic にすでに保存されているデータと対話するために構築されたエージェント AI ツールの領域への最初の進出です。Agent Builder は、ユーザーが Kibana 内で独自のエージェントとツールを作成および管理できるようにするチャット インターフェースを提供します。組み込みの MCP および A2A サーバー、プログラム API、Elasticsearch インデックスのクエリと探索、および自然言語からの ES|QL クエリの生成用の一連の構築済みシステム ツールが付属しています。Agent Builder を使用すると、表現力豊かなES|QLクエリ構文を通じてエージェントに返されるコンテキスト データをターゲットにして整形するカスタム ツールを作成できます。

ES|QL はハイブリッド検索をどのように実行するのでしょうか?コア機能は、 semantic_textフィールド タイプとFORK / FUSEコマンドの組み合わせによって実現されます (FUSE はデフォルトでRRFを使用して各フォークの結果をマージします)。架空の製品検索の簡単な例を次に示します。

上記の例の各 FORK ブランチに含まれるEVAL句は厳密には必須ではありません。これは、特定の結果がどの検索モダリティから返されたかを追跡する方法を示すためだけに含まれています。

検索テンプレート

独自の外部エージェントツールを Elastic デプロイメントにポイントするとします。また、ES|QL の代わりに、マルチステージ リトリーバーを使用したり、開発した既存の DSL 構文を再利用したり、クエリが受け入れる入力、検索を実行するために使用される構文、および出力で返されるフィールドを制御できるようにしたいと考えています。検索テンプレートを使用すると、ユーザーは一般的な検索パターンの定義済み構造を定義できるため、データ取得の効率と一貫性が向上します。これは、定型コードの標準化と検索ロジックの高速な反復処理を可能にするため、検索 API と対話するエージェント ツールにとって特に有益です。そして、これらの要素のいずれかを調整する必要がある場合は、検索テンプレートを更新するだけで、変更が実装されます。エージェントツールで実際に実行される検索テンプレートの例を探している場合は、Elasticsearch Labs のブログ「 MCP for intelligent search 」をご覧ください。このブログでは、外部 MCP サーバーからのツール呼び出しの背後で検索テンプレートが使用されています。

統合ワークフロー (最高!)

新しいエージェント AI の世界で最も扱いにくいことの 1 つは、半自律型で自己指向的な「推論」エージェントの非決定論的な性質です。コンテキスト エンジニアリングは、エージェント AI にとって非常に重要な分野です。これは、エージェントが生成できる可能性のある結論を、私たちが知っている事実に絞り込むのに役立つ手法です。非常に正確で関連性の高いコンテキスト ウィンドウがあっても、(数値的事実の領域から外れると) エージェントの応答が完全に再現可能で信頼できるという安心感がまだ少し欠けています。

エージェントに対して同じリクエストを複数回実行すると、応答に わずかな違いがあるだけ で、回答は 基本的に 同じになる可能性があります。これは通常、単純なクエリでは問題なく、ほとんど気づかれない程度で、コンテキスト エンジニアリング手法を使用して出力を調整することができます。しかし、エージェントに要求するタスクが複雑になるにつれて、1 つ以上のサブタスクによって差異が生じ、最終結果がわずかに変わる可能性が高くなります。エージェント間のコミュニケーションにさらに依存するようになると、状況はさらに悪化し、差異が累積していくでしょう。これは、エージェントが対話するツールは、コンテキスト データを正確にターゲットにするために非常に柔軟かつ調整可能である必要があり、予期される出力形式で応答する必要があるという考えを再び示しています。また、多くのユースケースでは、エージェントとツールのやり取りを誘導する必要があることも示しています。ここでワークフローが登場します。

Elastic ではまもなく、プラットフォームの中核に完全にカスタマイズ可能なワークフローが組み込まれる予定です。これらのワークフローはエージェントやツールと双方向に操作できるため、ワークフローはエージェントやツールを呼び出すことができ、エージェントやツールはワークフローを呼び出すことができます。これらの機能が、すべてのデータが存在する同じ検索 AI プラットフォームに完全に統合されることで、ワークフローの可能性は大きく変化します。もうすぐ、もうすぐ登場です！

統合メモリバンクとしてのElastic

Elastic は、ほぼリアルタイムの検索向けに作られた分散データ プラットフォームであるため、エージェント AI システムの長期メモリ機能を自然に実行します。組み込みの Agent Builder チャット エクスペリエンスにより、短期記憶とチャット履歴の追跡と管理も行えます。また、プラットフォーム全体が API ファーストであるため、エージェントのコンテキスト ウィンドウを圧倒する可能性のあるツールのコンテキスト出力を永続化するためのプラットフォームとして Elastic を利用する（そして後で参照できるようにする）ことは非常に簡単です。この手法は、コンテキスト エンジニアリングの分野では「メモを取る」と呼ばれることもあります。

同じ検索プラットフォームに短期記憶と長期記憶の両方を持つことで、多くの本質的なメリットが生まれます。チャット履歴と永続的なコンテキスト応答を、将来のチャットのやり取りに対する意味的影響要因の一部として使用したり、脅威分析を実行したり、頻繁に繰り返されるツール呼び出しから自動的に生成される永続的なデータ製品を作成したりできるようになることを想像してみてください。可能性は無限です。

まとめ

大規模言語モデルの出現により、コンテンツを一致させる方法や、データを調査するために使用する手法が変化しました。私たちは、人間が自らの疑問に答えるために調査、状況の考慮、論理的推論を行う現在の世界から、それらのステップがエージェント AI によって大部分が自動化される世界へと急速に移行しつつあります。生成された回答を信頼するには、エージェントが応答を生成する際に最も関連性の高い 情報（主観的関連性の要素を含む） をすべて 考慮したという保証が必要です。エージェント AI を信頼できるものにするための主な方法は、RAG とコンテキスト エンジニアリング技術を通じて追加のコンテキストを取得するツールを基盤化することですが、それらのツールが最初の取得をどのように実行するかが応答の精度に非常に重要になる場合があります。

Elastic Search AI プラットフォームは、ハイブリッド検索の柔軟性と利点に加えて、エージェント AI の精度、パフォーマンス、スケーラビリティを向上させるいくつかの組み込み機能を提供します。つまり、Elastic はコンテキスト エンジニアリングのさまざまな側面に対応する素晴らしいプラットフォームを実現します。検索プラットフォームを介したコンテキスト検索の標準化により、エージェントツールの操作がいくつかの面で簡素化されます。「速度を落としてスピードを上げる」という矛盾した表現と同様に、コンテキスト生成レイヤーの簡素化は、より高速で信頼性の高いエージェントAIを意味します。

私たちの多くと同じように、私も AI の能力が進化している速さに興奮すると同時に驚いています。大規模言語モデル (LLM) とベクトル検索によって、キーワードで検索する必要がなくなったセマンティック革命が初めて実現しました。その後、LLM は、チャット インターフェースを使用して自然言語によるリクエストを応答に変換し、膨大な知識ベースから簡単に利用できる要約を抽出するなど、データと対話する新しい方法を教えてくれました。私たちは今（すでに！）「エージェント AI」ワークフローの形で自動化された LLM 駆動型ロジックが始まります。このワークフローは、受信したリクエストを意味的に理解し、実行する手順を推論し、利用可能なツールから選択してアクションを反復的に実行し、目標を達成します。

エージェント AI の可能性により、私たちは、主に「プロンプト エンジニアリング」を使用して生成 AI のインタラクションを形成することから、エージェント ツールが LLM が応答を生成する際に考慮する必要がある最も関連性の高い効率的な追加情報を取得できるようにする方法に重点を置くように進化することを余儀なくされています。つまり、「コンテキスト エンジニアリング」が次のフロンティアです。ハイブリッド検索は、関連するコンテキストを明らかにするための最も強力で柔軟な手段であり、Elastic の Search AI プラットフォームは、コンテキストエンジニアリングに役立つデータを活用するまったく新しい方法を実現します。この記事では、LLM が情報検索の世界をどのように変えたかを 2 つの角度から説明し、さらに、LLM がどのように連携してより優れた成果を上げることができるかについて説明します。カバーすべき領域はかなり広いです…

パート1: LLMが検索に与えた影響

まず、LLM が情報にアクセスし取得する方法をどのように変えたかという観点から始めましょう。

私たちの語彙の遺産

私たちは皆、長い間、ある程度制限された語彙検索の世界で（できるだけうまく）生きてきました。検索は、調査をしたり新しいプロジェクトを開始したりするときに最初に使用するツールであり、最近まで、語彙検索エンジンが理解できる方法でクエリを言い表すのは私たち次第でした。語彙検索は、コンテンツが構造化されているか非構造化されているかに関係なく、何らかの形式のクエリ用語をドキュメント コーパスで見つかったキーワードと一致させることに依存します。語彙検索で文書がヒットとして返されるためには、そのキーワードに一致している必要があります (または、概念的なつながりを作るために同義語リストや辞書などの制御された語彙が必要です)。

語彙の 複数一致 クエリの 例

少なくとも検索エンジンには、関連性スコア付きのヒットを返す機能があります。検索エンジンは、インデックスされたデータを効果的にターゲットするための豊富なクエリ構文オプションと、ユーザーのクエリ構文の意図に応じて結果をスコア付けする組み込みの関連性アルゴリズムを提供します。検索エンジンは、関連性ランキング アルゴリズムの数十年にわたる進歩の恩恵を受けており、クエリとの関連性に基づいてスコア付けされ、並べ替えられた結果を提供できる効率的なデータ検索プラットフォームとなっています。データを取得する主な方法として SQL を使用するデータベースやその他のシステムは、ここでは不利です。データベース クエリには関連性の概念がなく、せいぜいアルファベット順または数字順に結果を並べ替えることしかできないからです。良いニュースとしては、これらのキーワードでヒットするものがすべて得られる (リコール) ことですが、それらは必ずしも、検索を求めた理由に対して役立つ順序 (精度) になっているわけではありません。これは重要なポイントです。すぐにわかります…

（意味論的）ドラゴンの登場

キーワード検索の代替として情報のベクトル表現の可能性は、かなり長い間研究されてきました。ベクトルは、キーワードのみのコンテンツ一致モードから抜け出すことができるため、大きな可能性を秘めています。ベクトルは用語と重みの数値表現であるため、トレーニング領域で用語が互いにどのように関連しているかについての言語モデルの理解に基づいて、概念を数学的に近づけることができます。汎用ベクトル検索の長い遅延は、モデルが主に特定のドメインに限定されていたためであり、異なるコンテキスト内で用語が表す可能性のあるさまざまな概念を十分に理解できるほどモデルが大きくなかったのです。

ベクトル検索が実用的になったのは、数年前に大規模言語モデル (LLM) が登場し、トランスフォーマーとアテンションを使用してはるかに大量のデータをトレーニングできるようになったときでした。LLM のサイズと深さにより、ベクトルは最終的に十分なニュアンスを保存できるようになり、実際に意味を捉えることができるようになりました。理解の深さが突然増加したことにより、LLM は、以前はロックされていた多数の自然言語処理 (NLP) 機能を提供できるようになり、おそらく最も影響力があるのは、これまでのシーケンスの内容に基づいて、シーケンス内で最も可能性の高い次の用語を推測する機能です。推論は、生成 AI に人間に近いテキスト生成能力を与えるプロセスです。AI によって生成されたテキストは、LLM がトレーニング データ内で用語がどのように関連しているかを理解した上で生成され、また、リクエストのフレーズを使用して、用語が出現する可能性のあるさまざまなコンテキスト間の曖昧さを解消します。

生成 AI は魔法のようですが、LLM には品質と精度のエラー (一般に幻覚と呼ばれる) を引き起こす制限があります。幻覚は、LLM が真実に基づいた回答をするための情報にアクセスできない (または正しいコンテキストに誘導されない) 場合に発生します。そのため、LLM は役に立とうとして、代わりに自信に満ちたもっともらしい応答をでっち上げで生成します。原因の一部は、LLM が多様な情報の大規模な領域内で言語の使用法を学習する一方で、ある時点でトレーニングを停止する必要があるため、理解に適時性の要素があることです。つまり、モデルはトレーニングを停止した時点までの正確さしか認識できないということです。幻覚を引き起こすもう 1 つの要因は、モデルが非公開データ (パブリック インターネットで利用できないデータ) を認識しないことです。これは、データに特定の用語や命名法が含まれている場合に特に重要です。

ベクターデータベース

LLM は、テキスト埋め込みと呼ばれる手法を使用してコンテンツをモデル空間にベクトル化します。テキスト埋め込みとは、受信したトレーニングに基づいて、モデルの世界観内にコンテンツの意味を埋め込む、つまりマッピングすることを指します。埋め込み用のコンテンツを準備して処理するには、チャンク化とトークン化（およびサブワードトークン化）など、いくつかの手順が必要です。結果は通常、ベクトル空間内でのコンテンツ チャンクの意味に関するモデルの理解を表す密なベクトルのセットになります。チャンキングは、埋め込みを生成するためのモデルの処理制約の制限内にコンテンツを収めることを目的とした不正確なプロセスであり、文や段落のインジケーターなどのセマンティック構造を使用して関連するテキストをチャンクにグループ化しようとします。

チャンク化の必要性により、埋め込まれたドキュメントでは、個々のチャンクが同じドキュメントの他のチャンクと完全に関連付けられていないため、多少の意味的損失が生じる可能性があります。ニューラル ネットワークの本質的な不透明性により、この損失が悪化する可能性があります。LLM はまさに「ブラック ボックス」であり、トレーニング中に作成された用語と概念間の接続は非決定論的であり、人間が解釈することはできません。これにより、説明可能性、再現性、無意識の偏見に関する問題が発生し、信頼性と正確性が失われる可能性があります。それでも、クエリ時に特定のキーワードに縛られずにアイデアを意味的に結び付ける機能は非常に強力です。

セマンティック クエリの 例

ベクター データベースに関して考慮すべきもう 1 つの問題があります。ベクター データベースは検索エンジンではなく、データベースなのです。ベクトル類似性検索を実行すると、クエリ用語がエンコードされ、モデルのベクトル空間内の一連の (埋め込み) 座標が検索されます。これらの座標は、ブルズアイとして使用され、ブルズアイに「最も近い」近傍にあるドキュメントが検索されます。つまり、ドキュメントのランク (または結果の配置) は、クエリの座標からのそのドキュメントの座標の計算された類似距離によって決まります。ランキングはどの方向を優先すべきでしょうか、考えられるコンテキストのうちどれがユーザーの意図に最も近いでしょうか?私がこれを例えると、映画「スターゲイト」のワンシーンになります。そのシーンでは、交差する 6 つの座標点が目的地 (的) を示しますが、ユーザーの主観的な意図を表す出発点の座標である「7 番目のシンボル」を知らないとそこに到達できません。したがって、ベクトルの相対的なランキングが常に拡大し区別のない類似性の領域に基づくのではなく、表現構文と関連性スコアリングを通じてクエリの主観的な意図を考慮することによって、段階的な主観的関連性の円筒に似たものを得ることができます。

LLM の推論機能は、クエリに対して最も可能性の高いコンテキストを識別するのに役立つ可能性がありますが、問題は、支援がなければ、着信クエリの座標はモデルが最初にトレーニングされた方法によってのみ決定できることです。

ある意味、ベクトル類似性は厳密なキーワード一致とは正反対の極限にあると言えます。その強みは用語の不一致の問題を克服する能力にありますが、それはほとんど欠点でもあります。LLM は関連する概念を区別するのではなく、統合する傾向があります。ベクトル類似性により、コンテンツを意味的に一致させる能力は向上しますが、モデルによって十分に明確にされていない正確なキーワードや具体的な詳細を見落とす可能性があるため、精度は保証されません。ベクトル類似性検索はそれ自体強力ですが、ベクトル データベースから取得した結果と他の取得方法の結果を相関させる方法が必要です。

再ランキング手法

ここで、結果セットを統一されたランク順に再スコアリングまたは正規化する、再ランク付けと呼ばれる一般的な手法について説明するのが良いでしょう。再ランク付けが必要になるのは、複数のソースからの結果や、ランク付け/スコアリング メカニズムが異なる (または SQL の場合はまったくメカニズムがない) 検索方法による場合です。また、非セマンティック ソースからの結果をユーザーのクエリに意味的に合わせるために再ランク付けを使用する場合もあります。再ランキングは第2段階の操作であり、何らかの初期検索方法（つまり、その後、検索クエリ (SQL、語彙検索、ベクトル検索) は、異なるスコアリング方法で並べ替えられます。

利用可能なアプローチはいくつかありますが、その中にはLearning-To-Rank (LTR)やReciprocal Rank Fusion (RRF)などがあります。LTR は、検索結果の特徴 (いいね、評価、クリックなど) をキャプチャし、それらを使用して結果にスコアを付けたり、結果をブーストしたり、バイアスをかけたりするのに役立ちます。RRFは、異なるクエリモダリティから返された結果をマージするのに最適です（例：語彙データベース検索とベクトルデータベース検索を 1 つの結果リストにまとめます。Elastic は、線形再ランキング方式を使用してスコアを調整する柔軟性も提供します。

ただし、最も効果的な再ランキング手法の 1 つは、セマンティック再ランキングです。これは、LLM のセマンティック理解を使用して、クエリと結果の両方のベクトル埋め込みを分析し、関連性スコアリング/再スコアリングを適用して最終的な順序を決定します。もちろん、セマンティック再ランク付けには再ランク付けモデルへの接続が必要です 。Elasticsearch は、組み込みモデル ( Elastic Rerank )、 インポートされた サードパーティモデル、または Cohere や Google Vertex AI などの外部でホストされるサービスを活用する 再ランク付け エンドポイントを作成できる推論 API を提供します。次に、リトリーバークエリ抽象化構文を使用して再ランク付けを実行できます。

多段階リトリーバー再ランキング操作の例

素晴らしいですね。さまざまなソースからの結果の再ランキングを実行し、あらゆる種類のコンテンツの意味的理解に近づくことができます。意味的再ランキングは、計算コストと必要な処理時間の両方でコストがかかる可能性があり、そのため、意味的再ランキングは限られた数の結果に対してのみ実行できます。つまり、最初の結果をどのように取得するかが重要になります。

文脈検索方法が重要

主観的な意図は、結果の正確性を判断し、関連性を評価する上で重要な要素です。クエリを実行するユーザーの意図（柔軟な構文または第 2 段階の再ランク付けによって表現される）を考慮する機能がなければ、モデル空間内にすでにエンコードされている既存のコンテキストから選択することしかできません。このコンテキストの欠如に対処する一般的な方法は、検索拡張生成 (RAG)などの手法を使用することです。RAG の仕組みは、文脈的に関連するデータの事前クエリから返された追加の関連用語を含めることで、クエリの座標を効果的にシフトすることです。そのため、追加のコンテキストを提供するエンジンと、検索を実行するための初期方法が、コンテキストの正確さにとってさらに重要になります。

さまざまなコンテキスト取得方法と、それが RAG 操作にどのように役立つか、または悪影響を与えるかを確認しましょう。

• 検索エンジンを使用しないハイブリッド検索では、依然として主観的な関連性が欠けています。RAG を提供するプラットフォームが主に SQL ベースである場合 (ほとんどの「データ レイク」プラットフォームが含まれます)、最初の検索段階で関連性スコアリングが欠如しています。多くのデータ レイク プラットフォームは、独自のハイブリッド検索 (検索ではない) を提供しており、通常は SQL ベースの検索とベクター データベースの結果にセマンティック リランキングや RRF などの再ランキング手法を組み合わせています。単純なソートは主観的なランキング付けには明らかに不十分ですが、第 2 段階のセマンティック リランキング操作の基礎として使用した場合でも、第 1 段階の検索としての SQL では、セマンティック リランキングが「上位 k」のヒットに対してのみ実行される場合に問題が生じます。検索時に結果にスコアを付ける方法がなければ、最善の結果が実際に上位の結果にあるという保証はありません。

• ベクトルの類似性だけでは RAG には不十分です。これは実際には、一連の問題が複合的に絡み合った結果です。つまり、埋め込みの損失、単純なチャンク化方法、類似性の計算方法、そして主観的な意図という重要な要素が欠落しているという問題です。RAG の主な目標の 1 つは、生成 AI のインタラクションを客観的な真実に基づいて確立することです。これにより、幻覚を防ぐと同時に、トレーニング中に認識されなかったプライベート情報を LLM に通知します。RAG を通じて提供される追加のコンテキストを使用して、手近の質問に答えるために最も重要であることがわかっている接続と詳細を考慮するように LLM を制限および指示できます。そのためには、意味論的アプローチと語彙的アプローチの両方を使用する必要があります。

• ファイルベースの grep/regex RAG。エージェント AI の世界では、外部の検索プラットフォームではなく、RAG の grep と regex を介してローカル ファイルにアクセスする、大幅に拡大されたコンテキスト ウィンドウの使用を指摘する声も上がっています。その考え方は、はるかに大きなコンテキスト ウィンドウを利用できることで、LLM が、関連情報を収集するために断片的な情報や複数の検索方法/プラットフォームに頼るのではなく、独自の思考空間内で概念的なつながりを構築できるようになるというものです。理論上は、文書全体があれば文書セグメントよりも完全な画像が得られるというのは本当ですが、これは小さなデータドメインでのみ機能します (または、たとえば、 vibecodingにファイルを提供する場合)。また、その場合でも、最初の検索方法は、キーワードのみが一致するすべての文書をスキャンすることです。

検索は単なる回収以上のもの

検索エンジンは、クエリを可能な限り高速かつ柔軟に実行することを目的として構築されています。内部的には、さまざまな種類のデータをそれらのデータ型に適した方法で保存および取得するための特殊なデータ構造を利用します。Elasticsearchは、非構造化/全文語彙検索（一致、フレーズ、近接、複数一致）、高速キーワード（完全一致）マッチングとフィルタリング、数値範囲、日付、IPアドレスなど、基本的にすべてのタイプのデータの最適化された保存とクエリを提供し、ドキュメント構造（例：ネストされたドキュメントやフラット化されたドキュメントなど)。Elasticsearch は、スパース ベクトル タイプと密ベクトル タイプの両方を保存およびクエリできるネイティブ ベクトル データベースでもあり、ベクトル化されたコンテンツに関連する速度、スケーラビリティ、コストを改善しながら検索の忠実度を維持するための革新的な方法 ( Better Binary Quantization (BBQ)やDiskBBQなど) を継続的に模索しています。Elasticsearch プラットフォームには、組み込みのデータ回復力と高可用性も備わっており、検索可能なスナップショットなどのデータライフサイクル管理機能も含まれています。検索可能なスナップショットを使用すると、アクセス頻度の低いデータや長期保存データをコスト効率の高いオブジェクトストレージに保存しながらも、完全に検索可能です。

ハイブリッド検索はあらゆる面で最高です

ハイブリッド検索(単なるハイブリッド取得ではありません!)従来の語彙検索の長所と、LLM の意味理解およびベクトル類似性検索を組み合わせます。この相乗効果により、検索エンジンが提供する柔軟なクエリ構文オプション（意図主導型の構文オプションと関連性スコアリング、マルチモーダル データ検索、フィルタリング、集約、バイアスなど）を通じて、検索段階で関連性の高い結果をターゲットにすることができます。ES|QLやマルチステージリトリーバーなどの検索構文を使用すると、従来の検索とセマンティック検索、フィルター、複数の再ランキング手法をすべて 1 つのリクエストで柔軟に組み合わせることができます。

ハイブリッド検索の最大の利点の 1 つは、クエリで複数の異なるデータ タイプに同時に特殊な構文を使用できることです。これらのさまざまなクエリ構文は、結果の検索だけでなく、結果のフィルターや集計としても使用できます。たとえば、他の構文と頻繁に組み合わせられる最も一般的なクエリ タイプの 1 つは、地理空間分析です。特定のポイントから指定された距離内の地理座標を持つ結果をクエリしたり、地域別に結果の集計を要求したり、ゾーンへの出入りの動きを追跡してアラートを発する集計を実行したりできます。ハイブリッド検索を使用すると、構文を柔軟に組み合わせて、最も正確な方法で結果をターゲットにし、コンテキストに最も近いコンテンツを取得できます。

休憩

この最初の部分では、ベクトル検索によってデータの取得方法がどのように変化したかを説明し、LLM がデータの操作に使用するクエリ メカニズムにもたらした変化の基礎を説明します。LLM がコンテキストを失うことなく理解できるように、これを複数の部分に分割する必要があったと仮定します... ;-)これがなぜ重要なのかについては、パート II: エージェント AI とコンテキスト エンジニアリングの必要性で詳しく説明し、パート III ではハイブリッド検索について再び説明します。

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

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

この取り組みの「全体像」について詳しくは、ブログ「Elasticsearch を使用した AI エージェントワークフローの構築」をお読みください。より実践的な入門書として、「初めての Elastic エージェント: 単一のクエリから AI を活用したチャットまで」もご覧ください。

ただし、このブログでは、チャットを開始したときに最初に起こることの 1 つに焦点を絞り、最近行った改善点のいくつかについて説明します。

ここで何が起こっているのですか?

Elasticsearch データとチャットする場合、デフォルトの AI エージェントが次の標準フローを実行します。

1. プロンプトを検査します。

2. どのインデックスにそのプロンプトの回答が含まれている可能性があるかを特定します。

3. プロンプトに基づいて、そのインデックスのクエリを生成します。

4. そのクエリでそのインデックスを検索します。

5. 結果を統合します。

6. 結果はプロンプトに対応できますか?はいの場合は応答してください。そうでない場合は、別の方法を試しながら繰り返します。

これはあまり目新しいものではないはずです。これは単に Retrieval Augmented Generation (RAG) です。そして当然のことですが、応答の質は最初の検索結果の関連性に大きく左右されます。そのため、応答品質の向上に取り組む中で、ステップ 3 で生成してステップ 4 で実行するクエリに細心の注意を払ってきました。そして、私たちは興味深いパターンに気づきました。

多くの場合、最初の応答が「悪い」場合、それは実行したクエリが悪かったからではありません。クエリを実行するために間違ったインデックスを選択したためです。通常、ステップ 3 と 4 は問題ではありません。問題はステップ 2 です。

私たちは何をしていたのでしょうか?

当初の実装はシンプルでした。私たちは、 _cat/indicesを効果的に実行して利用可能なすべてのインデックスをリストし、これらのインデックスのうちどれがユーザーのメッセージ/質問/プロンプトに最も一致するかを LLM に識別させるツール (index_explorer と呼ばれる) を構築しました。このオリジナルの実装はここで見ることができます。

これはどれくらいうまく機能しましたか?よく分かりませんでした！うまく機能していない明確な例はありましたが、私たちにとっての本当の最初の課題は、現状を定量化することでした。

ベースラインの確立

それはデータから始まる

私たちが必要としていたのは、ユーザーのプロンプトと既存のインデックス セットに基づいて適切なインデックスを選択するツールの有効性を測定するためのゴールデン データ セットでした。そして、手元にそのようなデータセットがなかったので、それを生成しました。

謝辞: これは「ベスト プラクティス」ではないことは承知しています。しかし、時には、自転車を捨てるよりも前進する方が良いこともあります。進歩、シンプルな完璧さ。

このプロンプトを使用して、いくつかの異なるドメインのシードのインデックスを生成しました。次に、生成されたドメインごとに、このプロンプトを使用してさらにいくつかのインデックスを生成しました (ここでの目標は、ハードネガティブと分類が難しい例を使用して LLM に混乱を引き起こすことです)。次に、生成された各インデックスとその説明を手動で編集しました。最後に、このプロンプトを使用してテストクエリを生成しました。次のようなサンプルデータが得られました。

そして次のようなテストケース:

テストハーネスの作成

ここからのプロセスは非常に簡単でした。次の機能を備えたツールをスクリプト化します。

1. ターゲット Elasticsearch クラスターを使用してクリーンな状態を確立します。

2. ターゲット データセットで定義されているすべてのインデックスを作成します。

3. 各テスト シナリオに対して、 i ndex_explorerツールを実行します (便利なことに、実行ツール API があります)。

4. 結果のインデックスを予想インデックスと比較し、結果を取得します。

5. すべてのテストシナリオを終了したら、結果を表にまとめます。

調査によると…

当初の結果は予想通り平凡なものでした。

全体として、正しいインデックスを識別する精度は 77.14% です。これは、すべてのインデックスに意味的に意味のある適切な名前が付けられている「最良のケース」のシナリオでした。`PUT test2/_doc/foo {...} ` を実行したことがある人なら、インデックスの名前が必ずしも意味のあるものではないことはご存じでしょう。

つまり、ベースラインがあり、改善の余地が十分にあることがわかります。さあ、科学の時間です！🧪

実験

仮説1: マッピングは役立つ

ここでの目標は、元のプロンプトに関連するデータが含まれるインデックスを識別することです。インデックスに含まれるデータを最もよく表す部分は、インデックスのマッピングです。インデックスの内容のサンプルを取得しなくても、インデックスに double 型の価格フィールドがあることがわかれば、そのデータは販売されるものを表していることがわかります。テキストタイプの著者フィールドは、何らかの非構造化言語データを意味します。これら 2 つを組み合わせると、データが書籍、物語、詩であることを意味する可能性があります。インデックスのプロパティを知るだけで、意味上の手がかりを数多く得ることができます。そこでローカルブランチで`.index_explorer`を調整しましたインデックスの完全なマッピング (およびその名前) を LLM に送信して決定を下すツール。

結果（Kibana ログより）:

ツールの最初の作成者はこれを予期していました。インデックスのマッピングは情報の宝庫ですが、非常に冗長な JSON ブロックでもあります。そして、多数のインデックス (評価データセットでは 20 個が定義されています) を比較する現実的なシナリオでは、これらの JSON BLOB が加算されます。したがって、LLM に、すべてのオプションのインデックス名だけでなく、それぞれの完全なマッピングほどではなく、決定のためのより多くのコンテキストを提供したいと考えています。

仮説2: 妥協案としての「フラット化された」マッピング（フィールドリスト）

私たちは、インデックス作成者が意味的に意味のあるインデックス名を使用するという前提から始めました。その仮定をフィールド名にも拡張するとどうなるでしょうか?前回の実験は、JSON のマッピングに大量の煩わしいメタデータと定型句が含まれているため失敗しました。

たとえば、上記のブロックは 236 文字で、Elasticsearch マッピング内の 1 つのフィールドのみを定義します。一方、文字列「description_text」は 16 文字だけです。これは文字数が約 15 倍に増加していることを意味しますが、そのフィールドが利用可能なデータについて何を意味するかを説明する意味的な改善は見られません。すべてのインデックスのマッピングをフェッチしたが、それを LLM に送信する前に、フィールド名のリストだけに「フラット化」するとどうなるでしょうか?

試してみました。

これは素晴らしいですね！全面的に改善されました。しかし、もっと良い方法はないでしょうか?

仮説3: マッピング_meta内の説明

追加のコンテキストのないフィールド名だけでこれほど大きな変化が生じたのであれば、実質的なコンテキストを追加すればさらに良くなると思われます。すべてのインデックスに説明を添付することが必ずしも慣例ではありませんが、マッピングの _meta オブジェクトにあらゆる種類のインデックス レベルのメタデータを追加することは可能です。生成されたインデックスに戻り、データセット内のすべてのインデックスに説明を追加しました。説明が極端に長くない限り、完全なマッピングよりも少ないトークンが使用され、インデックスに含まれるデータに関するはるかに優れた洞察が提供されるはずです。私たちの実験はこの仮説を検証しました。

若干の改善があり、現在では全体的に 90% を超える精度を実現しています。

仮説4：全体は部分の合計よりも大きい

フィールド名により結果が向上しました。説明により結果が向上しました。したがって、説明とフィールド名の両方を利用すると、さらに良い結果が得られるはずです。

データは「いいえ」（前回の実験から変化なし）を示しました。ここでの主な理論は、説明はそもそもインデックス フィールド/マッピングから生成されたため、これら 2 つのコンテキストの間には、組み合わせたときに何か「新しい」ものを追加するのに十分な情報がないというものでした。さらに、20 個のテスト インデックスに送信するペイロードもかなり大きくなっています。これまで私たちが辿ってきた考え方はスケーラブルではありません。実際、これまでの私たちの実験は、数百または数千のインデックスから選択できる Elasticsearch クラスターでは機能しないと考えられる十分な理由があります。インデックスの合計数が増加するにつれて、LLM に送信されるメッセージ サイズが直線的に増加するアプローチは、おそらく一般化可能な戦略にはなりません。

私たちに本当に必要なのは、多数の候補から最も関連性の高い選択肢だけを絞り込むのに役立つアプローチです...

ここで問題となるのは検索の問題です。

仮説5：意味検索による選択

インデックスの名前に意味がある場合は、ベクトルとして保存し、意味的に検索することができます。

インデックスのフィールド名に意味がある場合は、それらをベクトルとして保存し、意味的に検索することができます。

インデックスに意味を持つ記述がある場合は、それもベクトルとして保存し、意味的に検索することができます。

現在、Elasticsearch インデックスではこの情報を検索可能にしていません (検索可能にすべきかもしれませんが) が、そのギャップを回避できるものをハックするのは非常に簡単でした。Elastic のコネクタ フレームワークを使用して、クラスター内のすべてのインデックスのドキュメントを出力するコネクタを構築しました。出力ドキュメントは次のようになります。

これらのドキュメントを、次のように手動でマッピングを定義した新しいインデックスに送信しました。

これにより、単一の semantic_content フィールドが作成され、セマンティックな意味を持つ他のすべてのフィールドがチャンク化され、インデックスが作成されます。このインデックスの検索は、次のようにするだけで簡単になります。

修正されたindex_explorerツールは、LLM へのリクエストを行う必要がなくなり、代わりに指定されたクエリに対して単一の埋め込みをリクエストして効率的なベクトル検索操作を実行できるため、大幅に高速化されました。トップヒットを選択したインデックスとして取得すると、次の結果が得られました。

このアプローチはスケーラブルです。このアプローチは効率的です。しかし、このアプローチはベースラインよりわずかに優れているだけです。しかし、これは驚くことではありません。ここでの検索アプローチは信じられないほど単純です。ニュアンスがない。インデックスの名前と説明は、インデックスに含まれる任意のフィールド名よりも重視されるべきであるという認識がありません。正確な語彙の一致を同義語の一致よりも重視するアフォーダンスはありません。ただし、非常に微妙なニュアンスのあるクエリを構築するには、手元のデータについて多くのことを想定する必要があります。これまで、インデックス名とフィールド名には意味があるという大きな仮定をすでに立ててきましたが、さらに一歩進んで、インデックス名とフィールド名がどの程度の意味を持ち、互いにどのように関連しているかを仮定する必要があります。そうしないと、最上位の結果として最適な一致を確実に特定することはできないかもしれませんが、最上位 N 個の結果のどこかに最上位の一致があると言える可能性が高くなります。意味情報をそれが存在するコンテキスト内で消費し、意味的に異なる方法で自身を表現する別のエンティティと比較し、それらを判断できるものが必要です。LLM のようなものです。

仮説6: 候補セットの削減

他にも簡単に触れる実験はいくつかありましたが、重要な突破口となったのは、純粋にセマンティック検索から最適な一致を選択したいという欲求を捨て、代わりにセマンティック検索をフィルターとして活用して、LLM の検討対象から無関係なインデックスを除外したことです。検索では、リニア リトリーバー、RRF を使用したハイブリッド検索、 semantic_textを組み合わせて、一致する上位 5 つのインデックスに結果を制限しました。

次に、一致ごとに、インデックスの名前、説明、フィールド名を LLM のメッセージに追加しました。結果は素晴らしかったです。

これまでのどの実験よりも最高の精度です!また、このアプローチではインデックスの合計数に比例してメッセージ サイズが増加しないため、このアプローチははるかにスケーラブルです。

成果

最初の明らかな結果は、ベースラインを改善できるということでした。振り返ってみるとこれは明らかなようですが、実験が始まる前に、 index_explorerツールを完全に放棄して、ユーザーからの明示的な構成に依存して検索空間を制限すべきかどうかについて真剣な議論がありました。これはまだ実行可能かつ有効なオプションですが、この調査では、そのようなユーザー入力が利用できない場合にインデックス選択を自動化するための有望な道筋があることが示されています。

次の明らかな結果は、問題に対して説明文字をさらに追加するだけでは、効果は減少するということです。この調査を行う前、Elasticsearch のフィールドレベルのメタデータ保存機能を拡張することに投資すべきかどうかについて議論していました。現在、これらのmeta値は 50 文字に制限されており、フィールドの意味を理解できるようにするにはこの値を増やす必要があると想定されていました。これは明らかに事実ではなく、LLM はフィールド名だけでかなりうまく機能しているようです。これについては後でさらに調査するかもしれませんが、もはや緊急の問題ではないように思われます。

逆に言えば、これは「検索可能な」インデックス メタデータを持つことの重要性を明確に示しています。これらの実験のために、インデックスのインデックスをハッキングしました。しかし、これを Elasticsearch に直接組み込むか、管理するための API を構築するか、少なくとも規則を確立することを調査することはできます。私たちは選択肢を検討し、社内で議論する予定ですので、お楽しみに。

最後に、この取り組みにより、時間をかけて実験し、データに基づいた意思決定を行うことの価値が確認されました。実際、これにより、Agent Builder 製品には強力な製品内評価機能が必要になることが再確認されました。インデックスを選択するツール専用のテスト ハーネス全体を構築する必要がある場合、お客様は反復的な調整を行う際にカスタム ツールを定性的に評価する方法が絶対に必要になります。

私たちが何を構築するのか楽しみにしています。皆さんも楽しみにしていただければ幸いです。

リニアレトリーバーに会いましょう！

この投稿では、ハイブリッド検索をサポートするために最近追加されたlinearリトリーバーを紹介します。rrfとは異なり、 linearリトリーバーはドキュメントに一致したすべてのクエリの加重合計を計算します。このアプローチにより、結果セット内の各ドキュメントの相対的な重要度が維持され、各クエリが最終スコアに与える影響を正確に制御できるようになります。その結果、ハイブリッド検索を微調整するためのより直感的で柔軟な方法が提供されます。

最終スコアが次のように計算される線形リトリーバーを定義します。

それは次のように簡単です:

いかにシンプルで直感的であるかに気づきましたか?（そしてrrfと本当に似ています！）この構成により、相対的な順位のみに依存するrrfとは異なり、各クエリ タイプが最終的な順位にどの程度寄与するかを正確に制御できます。

注意点が 1 つあります: 使用される類似度メトリックに応じて、 knnスコアは厳密に制限される場合があります。たとえば、コサイン類似度または単位正規化ベクトルのドット積では、スコアは常に[0, 1]範囲内になります。対照的に、 bm25スコアは予測しにくく、明確に定義された境界がありません。

スコアのスケーリング：kNN vs BM25

ハイブリッド検索の課題の 1 つは、異なるリトリーバーが異なるスケールでスコアを生成することです。たとえば、次のシナリオを考えてみましょう。

クエリAのスコア:

ドキュメント1

ドキュメント2

ドキュメント3

ドキュメント4

わかる

0.347

0.35

0.348

0.346

bm25

100

1.5

1

0.5

クエリBのスコア:

ドキュメント1

ドキュメント2

ドキュメント3

ドキュメント4

わかる

0.347

0.35

0.348

0.346

bm25

0.63

0.01

0.3

0.4

上記の差異を見ると、 kNNスコアは 0 から 1 の範囲であるのに対し、 bm25スコアは大きく変動する可能性があります。この違いにより、結果を組み合わせるための静的な最適な重みを設定することが難しくなります。

正規化による救済：MinMax正規化

この問題を解決するために、次の数式を使用して、クエリごとに独立してスコアを[0, 1]範囲にスケーリングするオプションのminmaxノーマライザーを導入しました。

これにより、クエリの結果セット内の各ドキュメントの相対的な重要度が保持され、異なるリトリーバーからのスコアを簡単に組み合わせることができます。正規化すると、スコアは次のようになります。

クエリAのスコア:

ドキュメント1

ドキュメント2

ドキュメント3

ドキュメント4

わかる

0.347

0.35

0.348

0.346

bm25

1.00

0.01

0.005

0.000

クエリBのスコア:

ドキュメント1

ドキュメント2

ドキュメント3

ドキュメント4

わかる

0.347

0.35

0.348

0.346

bm25

1.00

0.000

0.465

0.645

すべてのスコアが[0, 1]範囲内に収まるようになり、絶対スコアではなく結果の (クエリに対する相対的な) 重要度を取得し、クエリ間で一貫性を維持できるようになったため、加重合計の最適化がはるかに簡単になりました。

リニアリトリーバーの例

ここで例を見て、上記がどのようになっているか、またlinearリトリーバーがrrfの欠点のいくつかをどのように解決しているかを見てみましょう。RRF は相対的なランクのみに依存し、実際のスコアの違いは考慮しません。たとえば、次のスコアがあるとします。

ドキュメント1

ドキュメント2

ドキュメント3

ドキュメント4

わかる

0.347

0.35

0.348

0.346

bm25

100

1.5

1

0.5

rrfスコア

0.03226

0.03252

0.03200

0.03125

rrf はドキュメントを次のようにランク付けします。

ただし、doc1 は他のものと比べてbm25スコアが大幅に高くなっていますが、 rrf相対的な順位のみを見ているため、これを捕捉できません。linearリトリーバーは正規化と組み合わせることで、スコアとその差異の両方を正しく考慮し、より意味のあるランキングを生成します。

ドキュメント1

ドキュメント2

ドキュメント3

ドキュメント4

わかる

0.347

0.35

0.348

0.346

bm25

1

0.01

0.005

0

上記のように、doc1 の優れたランキングとbm25のscoreが適切に考慮され、最終スコアに反映されています。さらに、すべてのスコアが[0, 1]範囲内にあるため、より直感的な方法でスコアを比較および組み合わせることができます (さらに、オフラインの最適化プロセスを構築することもできます)。

すべてをまとめると

正規化を伴うlinearリトリーバーを最大限に活用するには、検索リクエストは次のようになります。

このアプローチは、両方の長所を組み合わせたものです。つまり、 linearリトリーバーの柔軟性と直感的なスコアリングを維持しながら、MinMax 正規化による一貫したスコア スケーリングを保証します。

すべてのリトリーバーと同様に、 linearリトリーバーは、説明可能性、一致の強調表示、フィールドの折りたたみなどをサポートし、階層的なリトリーバー ツリーの任意のレベルに統合できます。

リニアレトリーバーを選ぶべきタイミングとそれが重要な理由

linearレトリーバー:

• ランクだけでなく実際のスコアを活用して相対的な重要性を維持します。

• さまざまなクエリからの重み付けされた寄与による微調整を可能にします。

• 正規化を使用して一貫性を強化し、ハイブリッド検索をより堅牢かつ予測可能にします。

まとめ

linearリトリーバーは、Elasticsearch Serverless、8.18 および 9.0 リリースですでに利用可能です。その他の例と構成パラメータについては、ドキュメントでも参照できます。ぜひお試しいただき、ハイブリッド検索エクスペリエンスがどのように改善されるかをご確認ください。皆様からのフィードバックをお待ちしております。楽しい検索を！