判断リストによる検索クエリの関連性の評価

Elasticsearchには、ユースケースに最適な検索ソリューションを構築するための新機能が豊富に備わっています。最新の検索するAIエクスペリエンスを構築するための実践的なウェビナーで、実践の方法を学びましょう。無料のクラウドトライアルを始めるか、ローカルマシンでElasticを試すことができます。

検索エンジンに取り組んでいる開発者は、同じ問題によく遭遇します。それは、検索結果の上位に表示されると予想していたドキュメントが結果リストの3番目か4番目に表示されるため、ビジネスチームが特定の検索に満足してくれないという問題です。

ただし、この 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テストでは、どの構成がユーザーやビジネスケースに最適かをライブでテストできるため、技術的な指標と実際の指標から完全に把握できます。

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

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

規模にこだわらずとにかく始める。それぞれ50個の判断リストを持つ10,000個のクエリを用意する必要はありません。ビジネスケースの最も重要な5〜10個のクエリを特定し、結果の冒頭にどの文書が表示されたいかを定義するだけで十分です。これですでに基礎が整いました。通常は、上位クエリと結果なしのクエリから始めるのが望ましいです。また、精度のような設定が簡単な指標でテストを開始し、複雑さを上げていくこともできます。
ユーザーとともに検証する。本番環境でのA/Bテストで数値を補完します。こうすることで、指標で良さそうに見える変更が実際に効果を生んでいるかどうかを知ることができます。
リストをアクティブに保つ。ビジネスケースは進化し、重要な問い合わせも進化していきます。新たなニーズを反映するために、定期的に判断を更新してください。
フローの一部に組み込む。判断リストを開発パイプラインに統合しましょう。各構成の変更、同義語、またはテキスト分析が基本リストに対して自動的に検証されることを確認します。
技術的な知識と戦略を結び付ける。精度やリコールなどの技術的な指標の測定にとどまらず、評価結果をビジネスの成果に役立てましょう。