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

ただし、この 1 つの問題を修正すると、すべてのケースを手動でテストすることができないため、他のクエリが誤って壊れてしまいます。しかし、1つのクエリの変更が他のクエリに波及効果をもたらすかどうかを、開発者やQAチームはどのようにテストできるでしょうか。さらに重要なのは、変更によってクエリが実際に改善されたことをどうやって確認できるかということです。

体系的な評価に向けて

ここで役に立つのが判断リストです。変更を加えるたびに手動の主観的なテストに頼るのではなく、ビジネスケースに関連するクエリの固定セットと、関連する結果を定義できます。

このセットが基準となります。変更を実装するたびに、それを使用して検索が実際に改善されたかどうかを評価します。

このアプローチの価値は、次の点にあります。

• 不確実性の排除：変更が他のクエリに影響を与えるかどうかを心配する必要はなくなり、データが教えてくれます。

• 手動テストの停止：判断セットが記録されると、テストは自動化されます。

• 変更を支援：変更のメリットを裏付ける明確な指標を示すことができます。

判断リストの作成方法

最も簡単な方法の1つは、代表的なクエリを取得して、関連するドキュメントを手動で選択することです。このリストを作成するには2つの方法があります。

• バイナリ判定：クエリに関連付けられた各ドキュメントに関連（通常「1」のスコア）とと非関連（「0」）のシンプルなタグが付けられます。

• 段階的な判断：ここでは、各ドキュメントに異なるレベルのスコアが付けられます。例えば、0から4の尺度を設定します。これはライカート尺度に似ており、0は「全く関連しない」、4は「完全に関連する」を意味し、「関連する」、「やや関連する」などのバリエーションがあります。

検索意図に明確な制限がある場合、つまり「このドキュメントは結果に含まれるべきかどうか」という場合には、バイナリ判断がうまく機能します。

段階的な判断は、グレーゾーンがある場合により役立ちます。一部の結果は他の結果よりも優れているため、「非常に良い」、「良い」、「役に立たない」という結果を取得し、結果の順序とユーザーのフィードバックを評価する指標を使用できます。ただし、段階的な評価尺度には欠点もあります。評価者によってスコアリングレベルの使い方が異なり、判断の一貫性が失われることがある点です。また、評価基準では高得点により重み付けされるため、小さな変更（評価を4ではなく3にするなど）でも、レビュー担当者の意図よりもはるかに大きな変化が評価基準に生じる可能性があります。この主観性が加わることで、段階的な判断はノイズが多くなり、時間の経過とともに管理が難しくなります。

書類を自分で分類する必要がありますか？

必ずしもそうとは限りません。なぜなら、判断リストを作成する方法はいくつかあり、それぞれに利点と欠点があるからです。

• 明示的な判断：ここでは、SMEが各クエリやドキュメントに目を通し、関連性があるかどうか（あるいはどの程度関連性があるか）を手動で判断します。これにより品質と管理は提供されますが、拡張性は低くなります。

• 暗黙的な判断：この方法では、クリック、直帰率、購入などの実際のユーザーの行動に基づいて関連するドキュメントを推測します。このアプローチにより、データを自動的に収集できますが、バイアスがかかる可能性があります。例えば、ユーザーは関連性がなくても上位の結果をクリックする傾向があります。

• AI生成の判断：この最後のオプションでは、モデル（LLMなど）を使用してクエリとドキュメントを自動的に評価します。これは、LLM審査員とも呼ばれます。スケーリングは高速かつ簡単ですが、データの品質は、使用しているモデルの品質と、LLMトレーニングデータがビジネス上の利益とどの程度一致しているかによって異なります。人間の採点者と同様に、LLM審査員も独自のバイアスや不整合を導入する可能性があるため、信頼できる判断の小さなセットに対してその出力を検証することが重要です。LLMモデルは本質的に確率的であるため、 温度 パラメータを0に設定しても同じ結果に対して異なる評価を与えるLLMモデルがよく見られます。

判断セットを作成するための最適な方法を選択するための推奨事項を以下に示します。

• ユーザーのみが適切に判断できる特徴（価格、ブランド、言語、スタイル、製品詳細など）の重要性を決定します。これらが重要な場合は、判断リストの少なくとも一部について明示的な判断が必要です。

• 検索エンジンにすでに十分なトラフィックがある場合は、暗黙的な判断を使用して、クリック、コンバージョン、滞在時間の指標を使用して使用傾向を検出できます。これらの結果は人間が注意深く解釈し、明示的な判断セットと対比させて、バイアスを防御する必要があります（例：ユーザーは、たとえ低いランクの結果がより関連性が高くても、上位にランクされた結果をクリックする傾向があります）。

これに対処するために、位置バイアス除去技術はクリックデータを調整または再重み付けして、実際のユーザーの関心をより適切に反映します。アプローチには以下のようなものがあります。

• 結果のシャッフル：一部のユーザーの検索結果の順序を変更し、位置がクリックにどのように影響するかを推定します。

• クリックモデルにはダイナミックベイジアンネットワーク（DBN）、ユーザーブラウジングモデル（UBM）が含まれます。これらの統計モデルは、スクロール、滞在時間、クリックシーケンス、結果ページへの戻りなどのパターンを使用して、クリックが単なる位置ではなく実際の関心を反映している可能性を推定します。

例：映画評価アプリ

要件

この例を実行するには、稼働しているElasticsearch 8.xクラスター、ローカルまたはElastic Cloud（HostedまたはServerless）、REST APIまたはKibanaへのアクセスが必要です。

ユーザーが映画についての意見をアップロードしたり、見たい映画を検索したりできるアプリを考えてみてください。ユーザー自身がテキストを書くため、タイプミスや表現の多様性がある可能性があります。そのため、検索エンジンがその多様性を解釈し、ユーザーにとって有益な結果を提供できることが不可欠です。

全体的な検索動作に影響を与えずにクエリを反復処理できるようにするために、会社のビジネスチームは、最も頻繁に実行される検索に基づいて、次のバイナリ判定セットを作成しました。

クエリ

DocID

テキスト

ディカプリオの演技

doc1

『レヴェナント：蘇えりし者』でのディカプリオの演技は息を呑むほど素晴らしかった。

ディカプリオの演技

doc2

『インセプション』ではレオナルド・ディカプリオが最も象徴的な役柄の一つを演じています。

ディカプリオの演技

doc3

ブラッド・ピットはこの犯罪スリラーで堅実な演技を見せています。

ディカプリオの演技

doc4

見事な視覚効果を備えたアクション満載の冒険。

泣ける悲しい映画

doc5

何時間も泣いてしまった、愛と喪失の悲痛な物語。

泣ける悲しい映画

doc6

史上最も悲しい映画の1つです。ティッシュが必須。

泣ける悲しい映画

doc7

笑える軽快なコメディ

泣ける悲しい映画

doc8

アクションと興奮に満ちたSF大作。

インデックスの作成：

一括リクエスト：

以下は、このアプリが使用しているElasticsearchクエリです。

判断から指標へ

判断リスト自体は、多くの情報を提供しません。これは、クエリから得られる結果の期待値にすぎません。これらが真価を発揮するのは、検索パフォーマンスを測定するための客観的な指標の計算に使用するときです。

現在、人気の指標のほとんどには以下が含まれます。

• 精度：すべての検索結果の中で本当に関連性の高い結果の割合を測定します。

• リコール：検索エンジンがx件の結果の中で見つけた関連する結果の割合を測定します。

• 割引累積利得（DCG）：最も関連性の高い結果が上位にあるべきであることを考慮して、結果のランキングの品質を測定します。

• 平均逆順位（MRR）：最初の関連結果の位置を測定します。リストの上位にあるほど、スコアも高くなります。

同じ映画評価アプリを例に使い、リコール指標を計算して、クエリに抜け落ちている情報がないかを確認します。

Elasticsearchでは、Ranking Evaluation APIを通じて判断リストを使って指標を計算できます。このAPIは、判断リスト、クエリ、および評価する指標をインプットとして受け取り、クエリ結果と判断リストを比較した値を返します。

次の2つのクエリの判断リストを実行してみましょう。

_rank_evalには 2 つのリクエストを使用します。1つはディカプリオクエリ用、もう1つは悲しい映画用です。各リクエストには、クエリと判断リスト（評価）が含まれています。評価に含まれていない文書は判断対象外とみなされるため、すべての文書に等級を付ける必要はありません。計算を行うために、リコールは評価において関連性があると見なされるドキュメントである「関連セット」のみを考慮します。

この場合、ディカプリオのクエリのリコールは1ですが、悲しい映画のリコールは0です。つまり、最初のクエリでは関連する結果をすべて取得できましたが、2 番目のクエリでは何も取得できませんでした。したがって、平均リコールは0.5です。

クエリ内の単語の100%がドキュメント内で見つかることを要求することで、おそらく関連する結果が除外されるため、minimum_should_matchパラメータを厳しすぎるのかもしれません。minimum_should_matchパラメーターを削除して、クエリで1つの単語しか見つかっていない文書が関連性があると見なされるようにしましょう。

ご覧のように、2つのクエリのうちの1つでminimum_should_matchパラメーターを削除すると、両方のクエリの平均リコール率は1になります。

要約すると、minimum_should_match: 100%句を削除すると、両方のクエリで完璧なリコールが得られます。

これで完了でしょうか？

安心するのはまだ早いです。

リコールを改善することで、より幅広い結果を得る道が開かれます。ただし、それぞれの調整にはトレードオフが伴います。だからこそ、完全なテストケースを定義し、異なる指標を使って変更を評価することが重要です。

判断リストと指標を使用すると、変更をバックアップするデータが得られるため、変更を行うときに盲目的に変更を行うことがなくなります。検証は手動で繰り返し行う必要がなくなり、変更を1つのユースケースだけでなく複数のユースケースでテストできるようになります。さらに、A/Bテストでは、どの構成がユーザーやビジネスケースに最適かをライブでテストできるため、技術的な指標と実際の指標から完全に把握できます。

判断リストの使用に関する最終的な推奨事項

判断リストを扱うことは、単に測定することだけでなく、自信を持って反復作業を行うためのフレームワークを作ることでもあります。これを実現するには、次の推奨事項に従ってください。

1. 規模にこだわらずとにかく始める。それぞれ50個の判断リストを持つ10,000個のクエリを用意する必要はありません。ビジネスケースの最も重要な5〜10個のクエリを特定し、結果の冒頭にどの文書が表示されたいかを定義するだけで十分です。これですでに基礎が整いました。通常は、上位クエリと結果なしのクエリから始めるのが望ましいです。また、精度のような設定が簡単な指標でテストを開始し、複雑さを上げていくこともできます。

2. ユーザーとともに検証する。本番環境でのA/Bテストで数値を補完します。こうすることで、指標で良さそうに見える変更が実際に効果を生んでいるかどうかを知ることができます。

3. リストをアクティブに保つ。ビジネスケースは進化し、重要な問い合わせも進化していきます。新たなニーズを反映するために、定期的に判断を更新してください。

4. フローの一部に組み込む。判断リストを開発パイプラインに統合しましょう。各構成の変更、同義語、またはテキスト分析が基本リストに対して自動的に検証されることを確認します。

5. 技術的な知識と戦略を結び付ける。精度やリコールなどの技術的な指標の測定にとどまらず、評価結果をビジネスの成果に役立てましょう。

スコア範囲の問題

まず最初に、ハイブリッド検索が困難になる主な理由の 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 つのコマンドでローカル環境で数分以内に開始できます。

私たちの多くと同じように、私も 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 ではハイブリッド検索について再び説明します。

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

この投稿では、ハイブリッド検索をサポートするために最近追加された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 リリースですでに利用可能です。その他の例と構成パラメータについては、ドキュメントでも参照できます。ぜひお試しいただき、ハイブリッド検索エクスペリエンスがどのように改善されるかをご確認ください。皆様からのフィードバックをお待ちしております。楽しい検索を！

Quepid は、検索品質評価プロセスにおいて検索チームをサポートします。

• クエリセットを構築する

• 判断リストを作成する

• 検索品質指標を計算する

• 計算された検索品質指標に基づいて、さまざまな検索アルゴリズム/ランカーを比較します

私たちのブログでは、映画レンタル店を運営しており、検索結果の品質を向上させることを目標としていると仮定しましょう。

要件

このブログでは、es-tmdb リポジトリのデータとマッピングを使用します。データはThe Movie Databaseから取得されています。手順に沿って、マッピングを使用して tmdb というインデックスを設定し、データにインデックスを付けます。ローカルインスタンスをセットアップするか、Elastic Cloud デプロイメントを使用するかは問題ではありません。どちらでも問題なく動作します。このブログでは、Elastic Cloud のデプロイメントを想定しています。データのインデックス作成方法については、es-tmdb リポジトリの README を参照してください。

検索するデータがあることを確認するには、 rockyのタイトル フィールドで単純な一致クエリを実行します。

8 件の結果が表示されます。

Quepidにログイン

Quepid は、ユーザーが検索結果の品質を測定し、オフライン実験を実行して品質を向上できるようにするツールです。

Quepid は 2 つの方法で使用できます: https://app.quepid.comで公開されている無料のホストバージョンを使用するか、または、アクセスできるマシンに Quepid をセットアップします。この投稿では、無料のホスト バージョンを使用していることを前提としています。ご使用の環境に Quepid インスタンスを設定する場合は、インストール ガイドに従ってください。

どちらの設定を選択する場合でも、まだアカウントをお持ちでない場合はアカウントを作成する必要があります。

Quepidケースの設定方法

Quepid は「ケース」を中心に構成されています。ケースには、関連性調整設定と検索エンジンへの接続を確立する方法とともにクエリが保存されます。

• 初めて使用する場合は、 「最初の関連性ケースを作成する」を選択します。

• 再度アクセスしたユーザーは、トップレベルのメニューから[関連性ケース]を選択し、 [+ ケースを作成] をクリックできます。

ベースライン検索の測定と改善を開始するため、ケースに説明的な名前を付けます (例:「映画検索ベースライン」)。

[続行]を選択して名前を確認します。

次に、Quepid から検索エンジンへの接続を確立します。Quepid は、Elasticsearch を含むさまざまな検索エンジンに接続できます。

構成は、Elasticsearch と Quepid の設定によって異なります。Quepid を Elastic Cloud デプロイメントに接続するには、Elastic Cloud デプロイメントに対して CORS を有効にして構成し、API キーを用意する必要があります。詳細な手順は、 Quepid ドキュメントの対応するハウツーに記載されています。

Elasticsearch エンドポイント情報 ( https://YOUR_ES_HOST:PORT/tmdb/_search ) と接続に必要な追加情報 (詳細設定オプションの Elastic Cloud デプロイメントの場合は API キー) を入力し、 pingをクリックして接続をテストし、 [続行] を選択して次のステップに進みます。

ここで、ケースに表示するフィールドを定義します。人間の評価者が後で特定のクエリに対するドキュメントの関連性を評価するのに役立つものをすべて選択します。

titleタイトル フィールドとして設定し、 _id ID フィールドのままにして、 overview, tagline, cast, vote_average, thumb:poster_path追加表示フィールドとして追加します。最後のエントリには、結果内の映画の小さなサムネイル画像が表示され、私たちと人間の評価者に視覚的にガイドします。

[続行]ボタンを選択して表示設定を確認します。

最後のステップは、ケースに検索クエリを追加することです。入力フィールドから「スターウォーズ」 、 「ハリソンフォード」 、 「ベストアクション映画」の3 つのクエリを 1 つずつ追加し、 「続行」をクリックします。

理想的には、ケースには実際のユーザークエリを表し、さまざまな種類のクエリを示すクエリが含まれます。現時点では、スターウォーズは映画のタイトルのすべてのクエリを表すクエリ、ハリソンフォードはキャストメンバーのすべてのクエリを表すクエリ、ベストアクション映画は特定のジャンルの映画を検索するすべてのクエリを表すクエリであると想像できます。これは通常、クエリ セットと呼ばれます。

実稼働シナリオでは、確率比例サイズサンプリングなどの統計手法を適用してイベント トラッキング データからクエリをサンプリングし、これらのサンプリングされたクエリを Quepid にインポートして、頻度に応じて先頭 (頻繁に発生するクエリ) と末尾 (発生頻度の低いクエリ) のクエリを含めます。つまり、まれなクエリを除外することなく、より頻度の高いクエリに偏向させるということです。

最後に、 「完了」を選択すると、定義された 3 つのクエリが表示されるケース インターフェイスに移動します。

クエリと情報ニーズ

判断リストという全体的な目標に到達するには、人間の評価者が特定のクエリに対する検索結果 (通常はドキュメント) を判断する必要があります。これはクエリ/ドキュメント ペアと呼ばれます。

場合によっては、クエリを見るとユーザーが何を望んでいたかが簡単にわかるようです。クエリharrison fordの目的は、俳優のハリソン・フォードが主演する映画を見つけることです。クエリactionについてはどうでしょうか?ユーザーの意図はアクション ジャンルに属する映画を見つけることだと言いたくなるでしょう。でもどれですか？最新のもの、最も人気のあるもの、ユーザーの評価による最高のものはありますか?あるいは、ユーザーは「アクション」と呼ばれるすべての映画を見つけたいのでしょうか?映画データベースには「アクション」というタイトルの映画が少なくとも 12 本 (!) あり、それらの名前は主にタイトルに含まれる感嘆符の数によって異なります。

意図が不明瞭なクエリの場合、2 人の評価者の間で解釈に違いが生じる可能性があります。情報ニーズの登場:情報ニーズとは、情報に対する意識的または無意識的な欲求のことです。情報ニーズを定義すると、人間の評価者がクエリに対して文書を判断するのに役立つため、判断リストを構築するプロセスで重要な役割を果たします。専門ユーザーまたは主題の専門家は、情報ニーズを指定するのに適しています。検索結果はユーザーのニーズを満たす必要があるため、ユーザーの視点から情報ニーズを定義することをお勧めします。

「映画検索ベースライン」のケースのクエリに必要な情報:

1. スターウォーズ: ユーザーはスターウォーズシリーズの映画や番組を見つけたいと考えています。関連性がある可能性があるのは、スターウォーズに関するドキュメンタリーです。

2. ハリソン・フォード: ユーザーは俳優ハリソン・フォードが主演する映画を見つけたいと考えています。関連性がある可能性があるのは、ハリソン・フォードがナレーターなどの別の役割を担っている映画です。

3. 最高のアクション映画: ユーザーはアクション映画、できれば平均ユーザー投票数の多い映画を見つけたいと考えています。

Quepidで情報ニーズを定義する方法

Quepid で情報ニーズを定義するには、ケース インターフェースにアクセスします。

1. クエリ (たとえば、スターウォーズ) を開き、 [Toggle Notes] を選択します。

2. 最初のフィールドに情報ニーズを入力し、2 番目のフィールドに追加のメモを入力します。

3. 「保存」をクリックします。

少数のクエリの場合、このプロセスは適切です。ただし、ケースを 3 クエリから 100 クエリに拡張する場合 (Quepid のケースでは、多くの場合、クエリは 50 ～ 100 クエリの範囲です)、Quepid の外部で (たとえば、スプレッドシートで) 情報ニーズを定義し、それを[インポート] からアップロードして[情報ニーズ] を選択する必要がある場合があります。

Quepidでチームを作成し、ケースを共有する

共同判断により関連性評価の品質が向上します。チームを設定するには:

1. 最上位メニューの「Teams」に移動します。

2. [+ 新規追加]をクリックし、チーム名 (例:「検索関連性評価者」) を入力して、 [作成] をクリックします。

3. メールアドレスを入力し、 「ユーザーの追加」をクリックしてメンバーを追加します。

4. ケースインターフェースで、 「ケースの共有」を選択します。

5. 適切なチームを選択して確認します。

Quepidで判定ブックを作成する

Quepid のブックでは、複数の評価者がクエリ/ドキュメントのペアを体系的に評価できます。作成するには:

1. ケースインターフェースの「判決」に移動し、 「+ ブックを作成」をクリックします。

2. ブックにわかりやすい名前を付けてチームに割り当て、採点方法 (DCG@10 など) を選択し、選択戦略 (単一または複数の評価者) を設定します。ブックには次の設定を使用します。

• 名称：「映画検索0-3スケール」

• この本を共有するチーム: 作成したチームのボックスにチェックを入れます

• 得点者: DCG@10

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

名前は説明的で、検索対象（「映画」）に関する情報と、評価のスケール（「0～3」）が含まれています。選択したスコアラー DCG@10 によって、検索メトリックの計算方法が決まります。「DCG」は「Discounted Cumulative Gain」の略で、「@10」は指標を計算する際に考慮される上位からの結果の数です。

この場合、情報ゲインを測定し、それを位置の重み付けと組み合わせるメトリックを使用しています。他にもユースケースに適した検索メトリックが存在する可能性があり、適切なものを選択すること自体が課題となります。

クエリとドキュメントのペアをブックに入力する

関連性評価のためにクエリ/ドキュメントのペアを追加するには、次の手順に従います。

1.ケース インターフェースで、「判決」に移動します。

2. 作成したブックを選択します。

3. 「ブックに入力」をクリックし、「ブックのクエリ/ドキュメント ペアを更新」を選択して確認します。

このアクションにより、各クエリの上位の検索結果に基づいてペアが生成され、チームによる評価の準備が整います。

人間の評価チームに判断させる

これまでに完了した手順は、かなり技術的かつ管理的なものでした。必要な準備が完了したので、審査員チームに作業を任せることができます。本質的に、審査員の仕事は、与えられたクエリに対する特定の文書の関連性を評価することです。このプロセスの結果は、判断されたクエリ ドキュメント ペアのすべての関連性ラベルを含む判断リストです。次に、このプロセスとそのインターフェースについてさらに詳しく説明します。

人間評価インターフェースの概要

Quepidの人間評価インターフェースは、効率的な評価ができるように設計されています。

• クエリ:検索用語を表示します。

• 情報ニーズ:ユーザーの意図を示します。

• 採点ガイドライン:一貫した評価を行うための指示を提供します。

• ドキュメント メタデータ:ドキュメントに関する関連詳細を表示します。

• 評価ボタン:評価者は対応するキーボード ショートカットを使用して判断を割り当てることができます。

人間評価インターフェースを使用する

人間の評価者として、私は本の概要からインターフェースにアクセスします。

1. ケース インターフェイスに移動し、 [判決]をクリックします。

2. 「より多くの判断が必要です!」をクリックします。

システムはまだ評価されておらず、追加の判断が必要なクエリ/ドキュメントのペアを提示します。これは、ブックの選択戦略によって決まります。

• 単一の評価者: クエリ/ドキュメントのペアごとに 1 つの判断。

• 複数の評価者: クエリ/ドキュメントのペアごとに最大 3 つの判断。

クエリとドキュメントのペアを評価する

いくつかの例を見てみましょう。このガイドに従うと、さまざまな映画が表示される可能性が高くなります。ただし、評価の原則は変わりません。

最初の例は、映画「Heroes」でクエリ「harrison ford」を検索するものです。

まずクエリを確認し、次に情報ニーズを確認し、最後に指定されたメタデータに基づいて映画を判断します。

この映画は、ハリドソン・フォードが出演しているため、私たちの検索に関連する結果です。私たちは主観的には最近の映画の方が関連性が高いと考えるかもしれませんが、これは私たちの情報ニーズには含まれません。したがって、この文書は当社の評価尺度で 3 に相当する「完璧」と評価されます。

次の例は、映画「フォードvsフェラーリ」のクエリ「harrison ford」です。

同じ慣例に従い、クエリ、情報ニーズ、そしてドキュメントのメタデータが情報ニーズにどの程度一致しているかを見て、このクエリ/ドキュメントを判断します。

これは悪い結果です。この結果は、おそらく、クエリ用語の 1 つである「ford」がタイトルに一致していることを示していると思われます。しかし、ハリソン・フォードはこの映画でも他の役でも何の役も演じていない。したがって、この文書は「悪い」と評価され、これは当社の評価尺度では 0 に相当します。

3番目の例は、クエリ「ベストアクション映画」に対する映画「アクションジャクソン」です。

これはアクション映画のように見えるので、情報ニーズは少なくとも部分的に満たされています。しかし、投票平均は10点満点中5.4点です。そのため、この映画はおそらく私たちのコレクションの中で最高のアクション映画ではないでしょう。したがって、審査員である私としては、この文書を「普通」と評価します。これは、当社の評価尺度では 1 です。

これらの例は、特に Quepid を使用してクエリ/ドキュメントのペアを評価するプロセスを、高レベルと全般にわたって示しています。

人間評価者の最適な活用のヒント

示された例を見ると、明確な判断に至るのは簡単そうに思えるかもしれません。しかし、信頼できる人間による評価プログラムを構築するのは簡単なことではありません。これは、データの品質を簡単に損なう可能性のある課題に満ちたプロセスです。

• 人間の評価者は反復的な作業で疲れてしまうことがあります。

• 個人的な好みにより判断が歪む可能性があります。

• 分野の専門知識のレベルは裁判官によって異なります。

• 評価者は多くの場合、複数の責任を同時にこなします。

• ドキュメントの認識された関連性は、クエリに対する実際の関連性と一致しない場合があります。

これらの要因により、一貫性のない低品質の判断が生じる可能性があります。しかし、心配する必要はありません。これらの問題を最小限に抑え、より堅牢で信頼性の高い評価プロセスを構築するのに役立つ、実証済みのベスト プラクティスがあります。

• 一貫した評価:クエリ、情報ニーズ、ドキュメント メタデータを順番に確認します。

• ガイドラインを参照してください:一貫性を保つためにスコアリング ガイドラインを使用します。採点ガイドラインには、どのグレードをいつ適用するかの例など、審査プロセスを示すものが含まれます。最初の一連の判断の後に人間の評価者とチェックインすることは、困難なエッジケースや追加のサポートが必要な場所を知るための良い方法であることが証明されました。

• オプションを活用する:不明な場合は、「後で判断します」または「わかりません」を使用し、必要に応じて説明を加えます。

• 休憩を取る:定期的に休憩を取ると判断力を維持するのに役立ちます。Quepid は、人間の評価者が一連の判定を終えるたびに紙吹雪を飛ばして、定期的な休憩を促します。

これらの手順に従うことで、Quepid で判断リストを作成するための構造化された共同アプローチを確立し、検索関連性の最適化の取り組みの有効性を高めることができます。

今後の見通し

ここからどこへ行くのでしょうか?判断リストは、検索結果の品質を向上させるための基本的なステップの 1 つにすぎません。次の手順は次のとおりです。

指標を計算して実験を始める

判断リストが利用可能になると、その判断を活用して検索品質メトリックを計算するのは自然な流れになります。Quepid は、判断が可能な場合、現在のケースに対して構成されたメトリックを自動的に計算します。メトリックは「スコアラー」として実装されており、サポートされているメトリックにお気に入りのメトリックが含まれていない場合は、独自のメトリックを提供できます。

ケース インターフェイスに移動し、 [スコアラーの選択]に移動して、 DCG@10を選択し、 [スコアラーの選択]をクリックして確認します。Quepid はクエリごとに DCG@10 を計算し、全体的なクエリの平均も計算して、ケースの検索結果の品質を定量化します。

検索結果の品質が定量化されたので、最初の実験を実行できます。実験は仮説を立てることから始まります。評価を行った後のスクリーンショットの 3 つのクエリを見ると、検索品質メトリックの点から見ると 3 つのクエリのパフォーマンスが大きく異なることが明らかです。 「スターウォーズ」のパフォーマンスはかなり良好で、 「ハリソンフォード」も悪くありませんが、最も大きな可能性を秘めているのは「ベストアクション映画」です。

このクエリを拡張すると、その結果が表示され、細かい詳細まで掘り下げて、ドキュメントが一致した理由やスコアに影響を与えるものを調べることができます。

「クエリの説明」をクリックして「解析」タブに入ると、クエリがキャスト、概要、タイトルの3つのフィールドを検索するDisjunctionMaxxQueryであることがわかります。

通常、検索エンジニアとして私たちは、検索プラットフォームに関するドメイン固有の情報をある程度知っています。この場合、ジャンルフィールドがあることが分かります。これをクエリに追加して、検索品質が向上するかどうかを確認しましょう。

ケース インターフェースで[関連性の調整] を選択すると開く クエリ サンドボックス を使用します。検索するジャンルフィールドを追加して、これを探索してみましょう。

「検索を再実行」をクリックしてください。そして結果を確認します。彼らは変わったのでしょうか？残念ながらそうではありません。現在、探索できるオプションは多数あり、基本的には Elasticsearch が提供するすべてのクエリ オプションがあります。

• ジャンルフィールドのフィールドウェイトを増やすことができます。

• 投票平均によってドキュメントをブーストする関数を追加できます。

• ジャンルの一致が強い場合にのみ投票平均によってドキュメントをブーストする、より複雑なクエリを作成することもできます。

• …

これらすべてのオプションを Quepid で検討することの最大の利点は、改善しようとしている 1 つのクエリだけでなく、この場合のすべてのクエリへの影響を定量化できる点です。これにより、他のクエリの検索結果の品質を犠牲にして、パフォーマンスの低いクエリを改善することが防止されます。リスクなしで迅速かつ安価に反復して仮説の価値を検証できるため、オフライン実験はすべての検索チームの基本的な機能になります。

評価者間の信頼性を測定する

タスクの説明、情報のニーズ、そして Quepid が提供するような人間の評価者インターフェースがあっても、人間の評価者の間で意見の相違が生じる可能性があります。

意見の相違自体は悪いことではありません。むしろその逆です。意見の相違を測定することで、取り組むべき問題が明らかになることがあります。関連性は主観的である可能性があり、クエリはあいまいであり、データは不完全または不正確である可能性があります。Fleiss の Kappaは評価者間の一致を測る統計的尺度であり、Quepid には使用できるサンプルノートブックがあります。これを見つけるには、最上位のナビゲーションで[ノートブック]を選択し、 例の フォルダーにあるノートブック Fleiss Kappa.ipynb を選択します。

まとめ

Quepid は、最も複雑な検索関連性の課題にも対処できるようにし、進化し続けています。バージョン 8 では、Quepid は AI 生成の判断をサポートしており、これは判断生成プロセスを拡大したいチームにとって特に便利です。

Quepid ワークフローを使用すると、スケーラブルな判断リストを効率的に作成できるため、最終的にはユーザーのニーズを真に満たす検索結果が得られます。判断リストを確立すると、検索の関連性を測定し、改善を繰り返し、ユーザー エクスペリエンスを向上させるための強固な基盤が得られます。

先に進む際には、関連性の調整は継続的なプロセスであることを忘れないでください。判断リストを使用すると進捗状況を体系的に評価できますが、実験、メトリック分析、反復的な改善と組み合わせると最も強力になります。

参考資料

• Quepid ドキュメント:

  • 関連性はチームスポーツ

  • 人間の評価者のためのQuepid

  • QuepidをElastic Cloudに接続する方法

• Quepid Githubリポジトリ

• 電子商取引の検索を改善するブログシリーズ「Pete」

• 関連性Slack ：#quepidチャンネルに参加する

Open Source Connections と提携して 検索機能と AI 機能を変革し、チームが継続的に進化できるようにします。当社の実績は世界中に広がっており、クライアントは一貫して検索品質、チーム能力、ビジネス パフォーマンスの劇的な改善を達成しています。詳細については、今すぐお問い合わせください。

フィルターとファセットの違い

始める前に、フィルターとファセットとは何かを定義しましょう。フィルターは、結果セットを制限するために使用される定義済みの属性です。たとえば、マーケットプレイスでは、検索を実行する前でもフィルターを利用できます。ユーザーは、 「PS5」 を検索する前に 「ビデオゲーム」 などのカテゴリを選択し、データベース全体ではなく、より具体的なサブセットに検索を絞り込むことができます。これにより、より関連性の高い結果を得られる可能性が大幅に高まります。

ファセットはフィルターと同様に機能しますが、検索を実行した後にのみ使用できます。つまり、検索によって結果が返され、それに基づいて絞り込みオプションの新しいリストが生成されます。たとえば、PS5 コンソールを検索する場合、ストレージ容量、送料、色などの側面が表示され、ユーザーが理想的な製品を選択できるようになります。

フィルターとファセットを定義したので、次に、従来のアプローチと機械学習 (ML) ベースのアプローチがそれらの実装と使用に与える影響について説明しましょう。それぞれの方法には、検索効率に影響する利点と課題があります。

フィルターとファセットに対する従来のアプローチ

このアプローチでは、フィルターとファセットは事前定義されたルールに基づいて手動で定義されます。つまり、検索を絞り込むために使用できる属性は、カタログ構造とユーザーのニーズを考慮して事前に固定され、計画されています。

たとえば、マーケットプレイスでは、「エレクトロニクス」や「ファッション」などのカテゴリに、ブランド、フォーマット、価格帯などの特定のフィルターがある場合があります。これらのルールは静的に作成されるため、検索エクスペリエンスの一貫性は確保されますが、新しい製品やカテゴリが登場するたびに手動で調整する必要があります。

このアプローチでは、表示されるフィルターとファセットの予測可能性と制御が可能になりますが、動的な改良を必要とする新しいトレンドが生まれた場合には制限される可能性があります。

長所:

• 予測可能性と制御:フィルターとファセットは手動で定義されるため、管理が容易になります。

• 複雑さが低い:モデルをトレーニングする必要はありません。

• メンテナンスの容易さ:ルールが事前に定義されているため、調整や修正を迅速に行うことができます。

短所:

• 新しいフィルターには再インデックスが必要です:新しい属性をフィルターとして使用する必要がある場合は、ドキュメントにこの情報が含まれていることを確認するために、データセット全体のインデックスを再作成する必要があります。

• 動的適応の欠如:フィルターは静的であり、ユーザーの行動の変化に自動的に適応しません。

フィルター/ファセットの実装 – 古典的なアプローチ

開発ツールの Kibanaでは、従来のアプローチを使用してフィルター/ファセットのデモを作成します。

まず、インデックスを構造化するためのマッピングを定義します。

ブランドおよびストレージフィールドはキーワードとして設定されており、集計 (ファセット) で直接使用できます。価格フィールドはfloat型であり、価格範囲の作成を可能にします。

次のステップでは、製品データがインデックス化されます。

ここで、ブランド、ストレージ、価格帯別に結果をグループ化して、クラシック ファセットを取得してみましょう。クエリでは、size:0 が定義されました。このシナリオでは、クエリに対応するドキュメントを含めずに、集計結果のみを取得することが目標です。

応答には、 Brand 、 Storage 、 Priceのカウントが含まれ、フィルターとファセットの作成に役立ちます。

フィルターとファセットに対する機械学習/AIベースのアプローチ

このアプローチでは、人工知能 (AI) 技術を含む機械学習 (ML) モデルがデータ属性を分析して、関連するフィルターとファセットを生成します。ML/AI は、事前定義されたルールに依存するのではなく、インデックス化されたデータ特性を活用します。これにより、新しいファセットとフィルターを動的に検出できるようになります。

長所:

• 自動更新:新しいフィルターとファセットは自動的に生成され、手動で調整する必要はありません。

• 新しい属性の検出:これまで考慮されていなかったデータ特性をフィルターとして識別し、検索エクスペリエンスを充実させることができます。

• 手作業の削減: AI が利用可能なデータから学習するため、チームはフィルタリング ルールを継続的に定義および更新する必要がありません。

短所:

• メンテナンスの複雑さ:モデルを使用する場合、生成されたフィルターの一貫性を確保するために事前検証が必要になる場合があります。

• ML と AI の専門知識が必要:このソリューションでは、モデルのパフォーマンスを微調整および監視する資格のある専門家が必要です。

• 無関係なフィルターのリスク:モデルが適切に調整されていない場合、ユーザーにとって役に立たないファセットが生成される場合があります。

• コスト: ML および AI の使用にはサードパーティのサービスが必要になる場合があり、運用コストが増加する可能性があります。

適切に調整されたモデルと適切に作成されたプロンプトを使用しても、生成されたファセットはレビュー手順を経る必要があることに注意してください。この検証は手動で行うことも、モデレーション ルールに基づいて行うこともできます。これにより、コンテンツが適切かつ安全であることが保証されます。必ずしも欠点ではありませんが、ファセットをユーザーに提供する前に、その品質と適合性を確認することは重要な考慮事項です。

フィルター/ファセットの実装 - AIアプローチ

このデモでは、AI モデルを使用して製品の特性を自動的に分析し、関連する属性を提案します。適切に構造化されたプロンプトを使用して、カタログから情報を抽出し、それをフィルターとファセットに変換します。以下に、プロセスの各ステップを紹介します。

最初に、 Inference API を使用して、ML サービスとの統合のためのエンドポイントを登録します。以下はOpenAI のサービスとの統合の例です。

ここで、プロンプトを実行し、モデルによって生成された新しいフィルターを取得するためのパイプラインを定義します。

「PlayStation 5」製品用にこのパイプラインのシミュレーションを実行すると、次のようになります。

驚異的なゲーム体験: 驚異的なグラフィックスに驚嘆し、新しい PS5 の機能を体験してください。

息を呑むような没入感: 触覚フィードバック、アダプティブ トリガー、3D オーディオ テクノロジーのサポートにより、より奥深いゲーム体験を体験できます。

スリムなデザイン: PS5 デジタル エディションでは、洗練されたコンパクトなデザインで強力なゲーミング テクノロジーをゲーマーに提供します。

1TB のストレージ: 1TB の内蔵 SSD ストレージで、お気に入りのゲームをいつでもプレイできます。

下位互換性とゲームブースト: PS5 コンソールは 4,000 以上の PS4 ゲームをプレイできます。Game Boost を使用すると、最高の PS4 コンソール ゲームの一部で、より高速でスムーズなフレーム レートを楽しむことができます。

このシミュレーションから生成されたプロンプト出力を観察してみましょう。

これで、AI によって生成されたファセットを保存するための新しいフィールドdynamic_facetsが新しいインデックスに追加されます。

Reindex API を使用して、プロセス中に generate_filter_ai パイプラインを適用し、 videogames インデックスを videogames_1 に再インデックスします。このパイプラインは、インデックス作成中に動的ファセットを自動的に生成します。

ここで、検索を実行して新しいフィルターを取得します。

結果：

ファセットの実装を象徴するシンプルなフロントエンドを以下に示します。

提示された UI コードはここにあります。

まとめ

フィルターとファセットを作成する両方のアプローチには、利点と注意点があります。手動ルールに基づく従来のアプローチでは、制御が可能になりコストも削減されますが、継続的な更新が必要となり、新しい製品や機能に動的に適応することができません。

一方、AI と機械学習ベースのアプローチでは、ファセット抽出が自動化されるため、検索がより柔軟になり、手動による介入なしに新しい属性を発見できるようになります。ただし、このアプローチは実装と維持が複雑になる可能性があり、一貫した結果を確保するために調整が必要になります。

従来のアプローチと AI ベースのアプローチのどちらを選択するかは、ビジネスのニーズと複雑さによって異なります。データ属性が安定していて予測可能な、より単純なシナリオでは、従来のアプローチの方が効率的で保守が容易になり、インフラストラクチャと AI モデルによる不必要なコストを回避できます。一方、ML/AI を使用してファセットを抽出すると、検索エクスペリエンスが向上し、フィルタリングがよりインテリジェントになるため、大きな価値が付加されます。

重要なのは、自動化が投資を正当化するかどうか、あるいはより従来型のソリューションがすでにビジネス ニーズを効果的に満たしているかどうかを評価することです。

このブログでは、大規模言語モデル (LLM) を使用して同義語を自動的に識別および生成し、これらの用語をプログラムで Elasticsearch の同義語 API に読み込むことができる方法について説明します。

同義語はいつ使用すればよいですか?

同義語を使用すると、ベクトル検索に比べて高速かつコスト効率の高いソリューションになります。埋め込みに関する深い知識や複雑なベクトル取り込みプロセスを必要としないため、実装はより簡単です。

さらに、ベクトル検索ではインデックス作成と検索を埋め込むために大きなストレージ容量とメモリが必要になるため、リソースの消費量が少なくなります。

もう一つの重要な側面は、検索の地域化です。同義語を使用すると、現地の言語や習慣に応じて用語を適応させることができます。これは、埋め込みが地域的な表現や国固有の用語と一致しない可能性がある場合に役立ちます。たとえば、一部の単語や頭字語は地域によって意味が異なる場合がありますが、現地のユーザーにとっては当然同義語として扱われます。ブラジルでは、これはかなり一般的です。「アバカシ」と「アナナス」は同じ果物（パイナップル）ですが、北東部の一部の地域では後者の用語の方が一般的に使用されています。同様に、南東部でよく知られている「pão francês」は、北東部では「pão careca」として知られている場合があります。

LLM を使用して同義語を生成するにはどうすればよいでしょうか?

同義語を自動的に取得するには、用語のコンテキストを分析して適切なバリエーションを提案する LLM を使用できます。このアプローチにより、同義語を動的に拡張できるため、固定辞書に依存せずに、より広範で正確な検索が可能になります。

このデモでは、LLM を使用して電子商取引製品の同義語を生成します。多くの検索では、検索語句のバリエーションにより、結果がほとんど返されないか、まったく返されません。同義語を使用すると、この問題は解決できます。たとえば、「スマートフォン」を検索すると、さまざまな種類の携帯電話が検索されるため、ユーザーは探している製品を見つけることができます。

要件

始める前に、環境を設定し、必要な依存関係を定義する必要があります。Elastic が提供するソリューションを使用して、 Elasticsearch と Kibana を Docker でローカルに実行します。コードは Python v3.9.6 で記述され、次の依存関係があります。

製品インデックスの作成

最初は、同義語をサポートしない製品のインデックスを作成します。これにより、クエリを検証し、同義語を含むインデックスと比較できるようになります。

インデックスを作成するには、Kibana DevTools で次のコマンドを使用して製品データセットを一括ロードします。

LLMによる同義語の生成

このステップでは、LLM を使用して同義語を動的に生成します。これを実現するために、OpenAI API を統合し、適切なモデルとプロンプトを定義します。LLM は製品のカテゴリと名前を受け取り、同義語が文脈的に適切であることを確認します。

作成された製品インデックスから、「エレクトロニクス」カテゴリ内のすべてのアイテムを取得し、その名前を LLM に送信します。予想される出力は次のようになります。

生成された同義語は、Synonyms API を使用して Elasticsearch に登録できます。

Synonyms API による同義語の管理

シノニム API は、システム内でシノニム セットを直接管理する効率的な方法を提供します。各同義語セットは同義語ルールで構成され、検索では単語のグループが同等として扱われます。

同義語セットの作成例

これにより、「my-synonyms-set」というセットが作成され、そこでは「hello」と「hi」が「bye」と「goodbye」と同様に同等として扱われます。

製品カタログの同義語作成の実装

以下は、同義語セットを構築して Elasticsearch に挿入するメソッドです。同義語ルールは、LLM によって提案された同義語のマッピングに基づいて生成されます。各ルールには、スラッグ形式の製品名に対応する ID と、LLM によって計算された同義語のリストがあります。

以下は、同義語セットを作成するためのリクエスト ペイロードです。

クラスターにシノニム セットが作成されたら、次のステップに進み、定義したセットを使用してシノニムをサポートする新しいインデックスを作成します。

LLM によって生成された同義語と、Synonyms API によって定義された同義語セットの作成を含む完全な Python コードは次のとおりです。

同義語サポート付きのインデックスの作成

新しいインデックスが作成され、 productsインデックスのすべてのデータが再インデックスされます。このインデックスは、以前に作成されたproducts-synonyms-setを適用するsynonyms_filterを使用します。

以下はシノニムを使用するように構成されたインデックス マッピングです。

productsインデックスの再インデックス

ここで、 Reindex API を使用して、 productsインデックスからシノニムのサポートを含む新しいproducts_02インデックスにデータを移行します。Kibana DevTools で次のコードが実行されました。

移行後、 products_02インデックスが作成され、構成された同義語セットを使用して検索を検証できるようになります。

同義語による検索の検証

2つのインデックス間の検索結果を比較してみましょう。両方のインデックスに対して同じクエリを実行し、結果を取得するために同義語が使用されているかどうかを検証します。

productsインデックスで検索（同義語なし）

Kibana を使用して検索を実行し、結果を分析します。「分析 > 検出」メニューで、作成したインデックスのデータを視覚化するためのデータ ビューを作成します。

Discovery 内で、データ ビューをクリックし、名前とインデックス パターンを定義します。「 products 」インデックスでは、「 products 」パターンを使用します。次に、「 products_02」 パターンを使用して、「 products_02 」インデックスの新しいデータ ビューを作成するプロセスを繰り返します。

データ ビューを構成したら、分析 > 検出に戻り、検証を開始できます。

ここで、DataView 製品を選択し、「タブレット」という用語で検索を実行すると、「Kindle Paperwhite」や「Apple iPad Air」などの製品があることがわかっているにもかかわらず、結果は表示されません。

products_02インデックスで検索 (同義語をサポート)

シノニムをサポートする「 products_synonyms 」データ ビューで同じクエリを実行すると、製品が正常に取得されました。これは、構成された同義語セットが正しく機能していることを示しており、検索された用語のさまざまなバリエーションが期待どおりの結果を返すことが保証されています。

同じクエリを Kibana DevTools で直接実行することで、同じ結果を得ることができます。Elasticsearch Search API を使用して、products_02 インデックスを検索するだけです。

まとめ

Elasticsearch に同義語を実装することで、製品カタログ検索の精度と範囲が向上しました。主な差別化要因はLLMの使用であり、これにより同義語が自動的かつ文脈に応じて生成され、事前定義されたリストの必要性がなくなりました。モデルは製品名とカテゴリを分析し、電子商取引に関連する同義語を確保しました。

さらに、同義語 API により辞書管理が簡素化され、同義語セットを動的に変更できるようになりました。このアプローチにより、検索はより柔軟になり、さまざまなユーザーのクエリ パターンに適応できるようになりました。

このプロセスは、新しいデータとモデルの調整によって継続的に改善され、ますます効率的な研究体験を保証します。

参照資料

Elasticsearchをローカルで実行する

https://www.elastic.co/guide/en/elasticsearch/reference/current/run-elasticsearch-locally.html

同義語API

https://www.elastic.co/guide/en/elasticsearch/reference/current/synonyms-apis.html

このブログでは、パート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は、ニーズに基づいて検索アプリケーションをカスタマイズおよび最適化するための強力なツールキットを提供します。検索速度、ランキング品質、ストレージ効率のどれを優先するかに関係なく、これらのツールとテクニックを使用すると、実際のアプリケーションのニーズに応じてパフォーマンスと品質のバランスをとることができます。