検索性能評価のためのアノテーション設計

はじめに

検索性能を評価するための適切なデータセットが手元にない場合、自前でオフライン評価セットを構築することが選択肢としてあります。

ユーザー行動ログに基づく評価も有効ですが、人手で集められた高品質なデータセットを用いることで、様々な検索手法を手軽に検証することが可能になります。

本記事では、検索性能評価のためのアノテーションを設計する際に気になった点を中心に、設計ポイントを紹介します。

目次

用語の定義

• 文書: 検索対象となるドキュメント
• トピック: ユーザーが何を検索したいかという情報要求。ユーザーは情報要求を元に、クエリを入力して検索を行う。
• アノテーション: 各トピックの検索結果の文書集合に対して関連性評価を行うこと。関連・非関連の二値の評価や、より詳細な多値評価がある。
• プール: アノテーション対象となる文書集合。全ての文書に対してアノテーションを行うことは、多大な労力を要するため、通常は検索システムが返す上位k件の文書集合に対してのみアノテーションを行う。

概要

検索システムの性能評価を目的とした、アノテーションシステムを設計する際に考慮すべき以下のトピックに焦点を当てて説明します。

• 統計的な判断に基づいて性能比較を行うために必要なトピック数の決定
• 精度改善に有効なアノテーション方法（Pointwise、Pairwise、Listwiseアプローチ）
• 限られたリソースの中で効率的にアノテーションを行うためのインターフェース設計

トピック数の設計

現実的なアノテーションリソースの制約を考慮しつつ、統計的に有効な判断が可能な十分なトピック数を選定することが望ましいです。

例えばセマンティック検索を導入した場合に、キーワード検索との性能を比較したいといった場合に、どれくらいのトピック数が必要になるでしょうか。

今回はt検定を用いて、統計的に性能の差異を検証することを前提として、検証に必要なトピック数を試算してみます。

「情報アクセス評価方法論」の6章(テストコレクションの設計)[1]を参考に、Pythonスクリプトによるトピック数の計算を行います。

トピック数を計算する上で、考慮すべき主要なパラメーターは以下の通りです。

• 検出したい評価値の最小差 (min_diff)

  例えば、もしnDCGが0.1が改善された場合に、それを検知できるようにしたい場合、0.1を指定します。

  今回は仮置きで0.05としました。

• 評価値(例: nDCG) の分散 (variance)

  今回は、Designing Test Collections for Comparing Many Systems の論文を参考に、TRECのアドホックタスクでプール長が10件の場合のnDCGの分散は、ニュースコーパスで0.0773、 ウェブコーパスで0.0462となっていたため、0.07としました。[2]

これらのパラメータで、下記のスクリプトを実行すると、必要なトピックス数は222となりました。

import numpy as np
from scipy.stats import norm

def calculate_required_topics(alpha: float, power: float, min_diff: float, variance: float) -> int:
    """
    二つの検索手法の性能を評価するために必要なトピック数（クエリ数）を推定する

    :param alpha: 有意水準 (Type I errorの確率)
    :param power: 検出力 (1 - Type II errorの確率)
    :param min_diff: 二つのシステム間で検出したい評価値の最小差
    :param variance: 評価値の分散
    :return: 必要なトピック数
    """
    # 効果量の計算
    effect_size = min_diff / np.sqrt(variance)

    # Zスコアの計算
    z_alpha = norm.ppf(1 - alpha / 2)
    z_beta = norm.ppf(1 - power)

    # 必要なトピック数の計算
    required_topics = ((z_alpha - z_beta) / effect_size) ** 2 + (z_alpha**2) / 2
    return round(required_topics)

alpha = 0.05  # 有意水準
power = 0.80  # 検出力
min_diff = 0.05  # 評価値の最小差
variance = 0.07  # 評価値の分散

required_topics = calculate_required_topics(alpha, power, min_diff, variance)
print(f"必要なトピック数: {required_topics}")

ただし、評価指標によって分散が大きく異なるという点は注意が必要です。

例えば、先ほどの論文[2]ではnDCGの方が平均精度(Average Precision)よりも分散は小さいとあります。

トピック数を設計する際に評価指標もあらかじめ決めておく必要がありそうです。

これらを元にアノテーターの工数を見積もると、1ドキュメントに30秒要した場合、トータルで30秒 * 222トピック * 10ドキュメント = 18.5 hかかります。 アノテーターが1日3時間アノテーションした場合、6日程度かかることになります。

アノテーションのアプローチ

Pointwise vs Pairwise vs Listwise アプローチ

アノテーションの方法として、Pointwise/Pairwise/Listwiseアプローチがあります。

どういった方法で検索モデルの精度を改善していくかという方針があると、その改善方法に適したアプローチを取ることで効果的なモデルの改善ができそうです。

• Pointwiseアプローチ

  Pointwiseアプローチはアノテーターが各文書を個別に評価します。

  利点:

  • 絶対的な関連度の評価であるため、解釈がしやすい
  • 各文書の品質や関連性を個別に評価できる

  欠点:

  • 評価が主観的であるため、一貫性の欠如やバイアスが生じる可能性がある (明確なガイドラインが必要)
  • 特に多段階評価（例：5段階評価）は、アノテーターにとって難易度が高い

• Pairwiseアプローチ

  Pairwiseアプローチはアノテーターは2つの文書のうち、どちらがより関連するかを判断します。

  利点:

  • 相対的な比較は、アノテーターにとってより直感的かつ簡単
  • Pairwise ランキング学習に適している (例: XGBoost XGBRanker)
  • 同じ関連度評価を受けた複数の文書間の細かな比較が可能
    • 例えば、Pointwiseアプローチでは「関連している」というラベルを持つ複数の文書が存在する場合、どちらがより関連しているかの判定ができない

  欠点:

  • 文書の組み合わせが多くなると、必要な比較の数が増加する
  • どちらの文書がより好ましいかの情報のみで、絶対的な関連度はわからない
  • 矛盾する評価（例：d1 > d2, d2 > d3, d3 > d1）が発生する可能性がある

• Listwiseアプローチ

  Listwiseアプローチは、ランク付けされた複数の文書が一度に評価されます。検索結果全体のリストを評価することに焦点を当てています。

  利点:

  • 全体の検索結果の品質を評価することができる
  • 文書間の相対的な関連性だけでなく、全体の検索結果としてのコンテキストを考慮する
  • ランキング全体の最適化に焦点を当てた学習アルゴリズムに適している

  欠点:

  • アノテーションの複雑性が増し、時間がかかる
  • 個々の文書の評価よりも、全体のランキングの品質評価に重きを置くため、個別の文書の詳細な評価は行われにくい

Pointwise, Pairwise, Listwiseアプローチの比較

これら三つのアプローチは、アノテーションの方法として異なる特徴を持っています。Pointwiseアプローチは個々の文書の絶対的な関連度に焦点を当て、Pairwiseアプローチは2つの文書間の相対的な比較に重点を置きます。一方で、Listwiseアプローチは検索結果全体のリストとしての品質を評価することに重点を置いています。これらのアプローチはそれぞれ利点と欠点があり、使用するシナリオや目的によって選択する必要があります。

例えば、RAG(Retrieval Augmented Generation)のようなアプリケーションで、参考情報を選択する際に、非関連文書が含まれると回答の精度が低下する傾向にあります。この場合、関連・非関連を識別する絶対的な関連度が重要であるため、Pointwiseアプローチが適切な選択となる可能性があります。

一方で、相対的なランキングの最適化が求められる場合には、PairwiseやListwiseアプローチが有効です。

再利用可能なデータセットの構築

アノテーションの目的は、現在の検索手法を評価するだけでなく、将来の検索手法の変更にも対応できる再利用可能なデータセットを構築することです。

キーワード検索だけでなく、セマンティック検索やリランキングなど、新しい検索技術やランキング手法を使用した際も柔軟に評価できるように、多様な文書集合に対してアノテーションされていることが望ましいです。

例えばTREC(情報検索システム性能評価・改善のための国際的なワークショップ)では、参加チームが提出する上位k件のランク付けされた文書リストの和集合を用いて、プールを作成しています。このプールは、様々な検索手法に適用可能な評価用の文書集合として機能するようにラベル付けされています。

効率的なアノテーションのためのデザイン

一般的なアノテーションでは、あらかじめ定義されたクエリとそのプールに対してラベル付けを行いますが、様々な検索クエリが同じトピック(情報要求) に対して存在し、どのような検索クエリを利用するかが大きく異なる場合、プールの選定が困難になります。そのため、特定のトピックに対してプールされた文書集合が、実際には適合する文書を含まない可能性があります。

インタラクティブな検索インターフェース

ユーザーの情報要求を満たすクエリが事前にわからない場合、アノテーターに可能な限り関連するドキュメントを検索し、適合文書を探してもらうことが考えられます。

例えば、質問応答システムで、質問に回答するためのリファレンスを検索する場合、アノテーター自身がどのようなクエリで検索すべきかを考え検索することで、関連性の高い文書をより効率的に見つけられることがあります。

この方法ではアノテーターに与えれた情報要求を満たすために、クエリを入力し検索してもらい、ランク付けされた検索結果の文書に対してアノテーションをしてもらいます。

注意点としては、どのようなクエリを入力するかに依存するため、アノテーターのドメイン知識や検索スキルが求められます。

また、ランク付けされた検索結果に対してアノテーションを行うため、検索結果上位にある文書が関連性が高いという先入観(ポジションバイアス)が発生する可能性があります。

この辺りは「情報検索 検索エンジンの実装と評価」の12.4.1 [3]や Efficient Construction of Large Test Collections [4]に詳細が書かれているので参照ください。

LLMを利用した自動評価

他のアノテーション効率化の方法として、LLMによる自動関連性評価があります。例えばGPTで関連性評価を行い、人手の評価と適合しているかを検証した上で、評価精度が担保できれば、自動評価を行うことで、アノテーション工数を大幅に削減できます。

おわりに

アノテーションシステムを設計する際に、個人的に特に気になった点を中心に調査を行い、必要なトピック数の試算方法や、適合性判定における各アプローチと、効率的なアノテーションを行うためのインターアクティブなインターフェースについて紹介しました。

検索性能評価のためのアノテーションシステムを導入する際の参考になれば幸いです。

参考

[1] www.coronasha.co.jp

[2] Tetsuya Sakai. 2014. Designing Test Collections for Comparing Many Systems. In Proceedings of the 23rd ACM International Conference on Conference on Information and Knowledge Management (CIKM '14). Association for Computing Machinery, New York, NY, USA, 61–70. https://doi.org/10.1145/2661829.2661893 Table5を参照

[3] www.morikita.co.jp

[4] Gordon V. Cormack, Christopher R. Palmer, and Charles L. A. Clarke. 1998. Efficient construction of large test collections. In Proceedings of the 21st annual international ACM SIGIR conference on Research and development in information retrieval (SIGIR '98). Association for Computing Machinery, New York, NY, USA, 282–289. https://doi.org/10.1145/290941.291009