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

主要AIや機械学習プラットフォームとシームレスに連携できます。無料のクラウドトライアルを開始してElasticの生成AI機能を探索するか、今すぐローカルマシンでお試しください。

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

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

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

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

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

BEIRデータセットの構造

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例1：

例2：

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

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

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

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

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

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

よくあるご質問