専門家一覧
AI Embeddingsの検索性能を評価するためのNDCGとMRRの活用ガイド

検索精度の「感覚評価」を卒業する。NDCGとMRRによるAI検索評価の実装ガイド

約16分で読めます
文字サイズ:
検索精度の「感覚評価」を卒業する。NDCGとMRRによるAI検索評価の実装ガイド
目次

この記事の要点

  • NDCGとMRRによるAI検索の定量評価の重要性
  • 評価用データセットの具体的な作成手順
  • Pythonを用いたNDCGとMRRの実装コード例

AIプロジェクトにおいて、プロジェクトマネージャーが経営層やクライアントから検索システムの精度を問われるのは、非常に重要な局面です。

PoC（概念実証）の段階では「目視確認」による感覚的な評価で進められがちですが、本番導入においてこの曖昧さを残すことは、プロジェクトの大きなリスク要因となります。AIを単なる技術検証で終わらせず、実用的なビジネス価値へと昇華させるためには、客観的な評価基準が不可欠です。

「なんとなく良さそう」が招く本番環境での失敗

実際の開発現場において、開発側が高精度だと評価したRAG（検索拡張生成）システムが、現場のユーザーからは「使えない」と評されてしまうケースが散見されます。

この原因の多くは、開発側が「綺麗な質問」のみでテストを行い、現場特有の略語や曖昧な表現を含む実際のクエリに対しては、誤ったドキュメントを検索していたことにあります。開発段階から定量的な評価指標を設定し、多様なテストケースでスコアを計測する仕組みがあれば、リリース前にこうした問題を検知できたはずです。

感覚的な評価は、評価者の期待や懐疑的なバイアスに大きく影響されます。これらのバイアスを排除し、チーム全員が共通の基準でシステムを評価できるようにするアプローチが「定量評価」です。

ビジネスKPI（CVR、滞在時間）と検索精度の相関

検索精度を数値化することは、単なる技術的な品質保証にとどまらず、ビジネス成果（ROI）の最大化に直結します。

例えば、ECサイトの検索において、ユーザーが求める商品が1ページ目（上位10件以内）に表示されなければ、離脱率は顕著に高まります。また、社内ナレッジ検索においても、正解に到達するまでの時間が長引けば、従業員の生産性低下を招きます。

  • 検索関連度が高い = ユーザーが欲しい情報に素早く到達でき、目的を達成できる
  • 検索関連度が低い = ユーザーが何度も検索し直すことになり、フラストレーションを感じる

検索エンジンの性能評価指標（NDCGなど）の高さは、コンバージョン率（CVR）や顧客満足度（CS）の向上と強い相関関係にあります。つまり、評価指標の導入はエンジニアリングの課題であると同時に、ビジネス要件を満たすための重要なステップなのです。

継続的なモデル改善のためのベースライン作り

AI技術は日進月歩であり、新しいEmbeddingモデルやリランキング手法が次々と登場しています。モデルを乗り換える際、基準となるスコア（ベースライン）が存在しなければ、真の性能向上や特定のクエリにおける精度の悪化を正確に判断できません。

「旧モデルよりNDCG@10が0.05ポイント向上した」という客観的な事実があって初めて、モデル更新の合理的な意思決定が可能になります。定量評価の仕組みを構築することは、改善サイクルを高速化し、プロジェクトの成功確率を高めるための重要な投資と言えます。

指標の選定：MRRとNDCGの「役割」と「使い分け」

検索システムの評価指標として、実務の現場で頻繁に用いられるのが「MRR（Mean Reciprocal Rank）」と「NDCG（Normalized Discounted Cumulative Gain）」です。これらはシステムの目的に応じて適切に使い分ける必要があります。

MRR（Mean Reciprocal Rank）：正解が1つだけの質問に

MRRは、「最初の正解が何番目に出てきたか」に注目する指標です。

例えば「2023年の日本の首相は誰？」といった質問（Factoid型）に対し、正解のドキュメントが1位ならスコアは1.0、2位なら0.5、3位なら0.33というように、順位の逆数がスコアとなります。

  • 計算式イメージ: 1 / 最初の正解順位
  • 適しているケース:
    • Q&Aシステム
    • 特定の事実を検索する場合
    • ユーザーが「最上位の1件」しか見ない場合（スマートスピーカーなど）

MRRは非常にシンプルで分かりやすい反面、「正解が複数ある場合」や「順位による重要度の違い」を反映しにくいという特徴を持っています。

NDCG（Normalized Discounted Cumulative Gain）：順位と関連度を重視する場合に

一方、NDCGは「上位に関連性の高いものがどれだけ集まっているか」を総合的に評価する指標です。

検索結果には「完全な正解（関連度3）」「まあまあ関係ある（関連度2）」「少し関係ある（関連度1）」「無関係（関連度0）」といったグラデーションが存在します。NDCGは以下の2つの要素を考慮して計算されます。

  1. 関連度: より関連度の高いドキュメントが含まれているか
  2. 順位: 関連度の高いドキュメントがより上位に来ているか（下位にあるとスコアが割り引かれる）
  • 適しているケース:
    • ECサイトの商品検索（例えば「赤い スニーカー」という検索に対し、完全に赤いスニーカーが上位、部分的に赤いものが中位に表示されるなど）
    • 文書検索（関連する複数の資料をリストアップしたい場合）
    • RAGのコンテキスト取得（LLMに関連情報を複数渡したい場合）

RAGにおいては、LLMに渡すコンテキスト（例：上位5件）に含まれる情報の質が最終的な回答精度を大きく左右するため、NDCG@k（k=5や10）が頻繁に用いられます。

あなたのユースケースにはどちらが適しているか判断フロー

どちらの指標を使うべきか迷った際は、以下の基準で論理的に選定することをおすすめします。

  1. ユーザーの目的は「正解を一つ知ること」ですか？
    • YES → MRR を採用（例：ヘルプデスクの自動応答）
  2. ユーザーの目的は「関連情報を網羅的に見ること」や「比較検討」ですか？
    • YES → NDCG を採用（例：技術文書検索、商品検索）
  3. 正解データ（Ground Truth）は「0/1（正解か否か）」で作りますか？それとも「3段階評価」などで作りますか？
    • 0/1のみ → MRRでも可（NDCGも計算可能ですがメリットが薄くなります）
    • 多段階評価 → NDCG が必須

実務においては両方を計測し、システムの特性に合わせてメインのKPIを決定するのが効果的です。特にRAGでは「関連ドキュメントを上位に集める能力」が重視されるため、NDCGを優先することをおすすめします。

評価用データセット（Ground Truth）の構築ワークフロー

指標の選定：MRRとNDCGの「役割」と「使い分け」 - Section Image

評価指標を決定した後は、計算用データセット（Ground Truth）の作成に進みます。これはAI検索評価において非常に重要な要素です。

「クエリ」と「理想的な検索結果（正解ドキュメント）」のペアが必要になりますが、膨大なドキュメントから手動で正解をラベリングするのは非現実的です。

ここでは、限られたリソースの中で質の高いデータセットを構築するための、実践的なフローを紹介します。

必要なデータ構造

評価を行うためには、最低限以下の3つの要素を含むデータセットが必要です。

  1. Query (クエリ): ユーザーが入力する検索キーワードや質問文。
  2. Document ID (正解ドキュメントID): そのクエリに対してヒットすべきドキュメントのID。
  3. Relevance (関連度スコア): そのドキュメントがどれくらいクエリに関連しているか（例：1=関連あり、0=なし。あるいは 3=完全一致、2=部分一致など）。

アノテーションの効率化：人手 vs LLMによる自動判定

すべてを人手で作業するのはコストが高いため、近年は「LLM-as-a-Judge（審判としてのLLM）」というアプローチが主流となっています。

手順:

  1. クエリ生成: ドキュメントの内容をLLM（ChatGPTなど）に読み込ませ、「このドキュメントが回答となるような質問文を作ってください」と指示し、逆生成的にクエリを作成します（Synthetic Data Generation）。
  2. 候補抽出: 生成したクエリで現在の検索システムを実行し、上位候補（例えば50件）を取得します。
  3. 自動判定: クエリと候補ドキュメントのペアを再度LLMに渡し、「このドキュメントはクエリに対して関連性がありますか？ 0〜3のスコアで評価してください」と判定させます。

この手法を取り入れることで、人間はサンプリングチェックを行うだけで済み、数千件規模の評価データセットを効率的かつ体系的に構築できます。

データの分割戦略：開発用とテスト用

機械学習モデルの学習プロセスと同様に、評価データも「開発用（Dev Set）」と「テスト用（Test Set）」に分割しておくことを強く推奨します。

  • 開発用: プロンプトエンジニアリングやハイパーパラメータ（チャンクサイズなど）の調整に使用します。
  • テスト用: 最終的な精度評価に使用します。開発中は一切見ないようにし、カンニングを防ぎます。

これにより、特定のデータに対する過剰適合（オーバーフィッティング）を防ぎ、未知のクエリに対するシステムの実力を正確に測定することが可能になります。

バイアスを防ぐためのクエリ選定基準

LLMが自動生成したクエリのみを使用すると、「AIが答えやすい質問」に偏るリスクがあります。そのため、以下のソースをミックスしてデータセットを構築してください。

  • 実際のログデータ: 過去にユーザーが入力した実際の検索クエリ（これが最も重要です）。
  • 失敗クエリ: 過去にクレームに繋がったり、検索結果が0件だったクエリ。
  • ドメイン固有の表現: 業界用語や社内スラングを含むクエリ。

これらをバランスよく含めることで、実際のビジネス現場で「使える」実践的な評価セットが完成します。

実装ステップ：Pythonによる評価パイプラインの構築

評価用データセット（Ground Truth）の構築ワークフロー - Section Image

データセットの準備が整ったら、Pythonを用いて評価パイプラインを構築します。ここでは、検索結果のリストからNDCGとMRRを計算する実装例を解説します。

使用ライブラリの選定

ゼロから実装することも有益ですが、実務においては保守性と信頼性の観点から、検証済みのライブラリを採用するのが賢明なアプローチです。

  • scikit-learn: 機械学習の定番ライブラリですが、ランキング指標に関しては機能が限定的な場合があります。
  • ranx: ランキング評価に特化したライブラリです。TREC形式のサポートや多彩な指標、高速な計算処理が特徴であり、検索エンジニアの間で標準的な選択肢となりつつあります。今回はこちらを推奨します。

まず、ライブラリをインストールします。

pip install ranx

検索結果の取得とスコアリング処理の実装

以下は、ranx を使用して NDCG@10 と MRR@10 を計算するコード例です。実務で扱いやすいよう、辞書形式のデータを処理するフローで記述しています。

from ranx import Qrels, Run, evaluate

# 1. Ground Truth (正解データ)
# キーはクエリID、値は {ドキュメントID: 関連度スコア}
# ※関連度スコアは通常、人間の判定やクリックログ、あるいはLLMによる判定結果を使用します
qrels_dict = {
    "q_001": {"doc_123": 1, "doc_456": 2},
    "q_002": {"doc_789": 1},
    # ... 他のクエリ
}

# 2. 検索システムの出力結果 (Run)
# キーはクエリID、値は {ドキュメントID: 検索スコア(類似度など)}
# ベクトル検索やキーワード検索のスコアをそのまま利用可能です
run_dict = {
    "q_001": {
        "doc_123": 0.9, # 検索エンジンが出したスコア
        "doc_999": 0.8,
        "doc_456": 0.7,
    },
    "q_002": {
        "doc_000": 0.5,
        "doc_789": 0.4,
    },
    # ... 他のクエリ
}

# ranxのオブジェクトに変換
qrels = Qrels(qrels_dict)
run = Run(run_dict)

# 3. 評価実行
# ndcg@10 と mrr@10 を計算
metrics = ["ndcg@10", "mrr@10"]
results = evaluate(qrels, run, metrics)

print("Evaluation Results:")
print(results)

# Tips: 個別のクエリごとのスコアを取得して分析する場合
# run.mean_scores ではなく、詳細なレポートを出力することも可能です

kの値（@10, @5など）の決め方

NDCG@kのk（カットオフ値）は、実際のユーザー体験（UX）やシステムの用途に基づいて論理的に設定します。

  • スマホアプリの検索: 画面領域が限られており、ファーストビューで上位3件程度しか視認されない場合 → @3
  • RAG（検索拡張生成）のコンテキスト: ChatGPTやClaudeなどの生成AIモデルに渡す参考ドキュメント（チャンク）数が5つである場合 → @5
  • PCブラウザの検索: 1ページに10件の検索結果が表示される一般的なUIの場合 → @10

RAGの実装においては、LLMのコンテキストウィンドウの制限やAPIコストの兼ね合いから、上位5〜10件の精度が回答品質に直結するため、k=5やk=10を重点的に評価します。

評価実行の自動化（CI/CDへの組み込み）

評価スクリプトは単発の実行で終わらせず、継続的な品質管理プロセスへ組み込むことを推奨します。

GitHub Actions等のCI/CDパイプラインに組み込み、プルリクエストごとに小規模なテストセット（ゴールデンセット）で評価を実行する仕組みを構築します。これにより、検索ロジックの変更やインデックスの更新によるスコア悪化を自動的に検知し、予期せぬ精度低下（リグレッション）を未然に防ぐことができます。

評価結果の分析と精度改善サイクル

評価指標の算出は、あくまで改善サイクルの起点に過ぎません。「NDCG@10 = 0.65」という結果が自社のユースケースにおいて十分な水準であるかを読み解く力が、プロジェクトマネージャーには求められます。数値はシステムの「健康診断結果」であり、そこから具体的な改善策を導き出すプロセスこそが重要です。

数値だけでなく、失敗事例（エラー分析）をどう見るか

平均スコアを確認するだけでなく、スコアが著しく低いクエリ（外れ値）を抽出し、必ず目視で確認してください。失敗のパターンは、主に以下の2つに大別されます。

  1. 検索漏れ（Recallの問題）
    • 現象: 回答に必要な情報が含まれるドキュメントが、検索結果の上位に出てこない、あるいは全くヒットしない。
    • 原因: ユーザーの検索語句とドキュメント内の用語が一致していない（表記ゆれや専門用語）、またはEmbeddingモデルが業界固有の文脈を捉えきれていないことが考えられます。
    • 対策: ベクトル検索だけでなくキーワード検索を組み合わせる「ハイブリッド検索」の導入や、クエリ拡張（ユーザーの質問をLLMで言い換えてから検索する手法）が有効です。
  2. ノイズ混入（Precisionの問題）
    • 現象: 上位に無関係なドキュメントが並んでおり、LLMの回答生成を妨げている。
    • 原因: チャンクサイズが不適切で文脈が途切れている、あるいはベクトル空間上で距離が近いだけの「偽陽性」が発生しています。
    • 対策: チャンク分割の粒度（Chunk Size）やオーバーラップの見直し、または検索結果を再評価するReranker（リランキングモデル）の導入を検討します。

「ハルシネーション」と「検索漏れ」の関係

RAGシステムにおいて、検索精度の低さは致命的なハルシネーション（もっともらしい嘘）に直結します。LLMはコンテキスト内に正解が存在しない場合、自身の学習データから無理やり回答を生成しようとする傾向があるためです。

「回答が不正確である」というフィードバックに対して、すぐにプロンプトの調整に走るのは得策ではありません。まずは「検索結果に正解が含まれていたか（Recall@kの確認）」を実施してください。回答精度の問題の多くは、生成側（LLM）ではなく検索側（Retriever）に起因しています。

改善施策の優先順位付け

プロジェクトのROIを最大化するためには、コスト対効果が高い順に施策を打つことが重要です。以下の順序で検討を進めることを推奨します。

  1. データの前処理改善（最重要）:
    • ノイズの除去や、適切なチャンクサイズへの変更。インフラの変更を伴わず、試行錯誤のコストも低いため、最初に取り組むべき領域です。
  2. ハイブリッド検索の導入:
    • ベクトル検索の「意味理解」と、キーワード検索の「完全一致」を組み合わせることで、特に専門用語が多いドメインでの精度を底上げします。
  3. Reranker（リランキング）の追加:
    • 一次検索で多めに（例えば50件）取得し、それを高精度なモデル（Cross-Encoder等）で再順位付けして上位数件をLLMに渡します。計算コストは増加しますが、精度向上の切り札として非常に有効です。
  4. Embeddingモデルの変更:
    • 最新の高性能モデルや多言語対応モデルへの切り替え。インデックスの再作成が必要になるため、工数は大きくなります。
  5. ファインチューニング:
    • Embeddingモデル自体を自社データで学習させる手法。高度な専門知識と膨大な計算リソースが必要となるため、最終手段と位置づけるのが賢明です。

まずは手軽な前処理や検索パラメータの調整から着手し、数値の変化を定量的にモニタリングする体制を整えましょう。

運用フェーズ：品質監視の定着化

システムをリリースした後も、評価は継続して行う必要があります。ドキュメントの更新や検索トレンドの変化に加え、利用中のLLMやEmbeddingモデルのアップデート・廃止といった外部要因も発生するためです。

評価の一発屋で終わらせないための運用ルール

運用フェーズにおいても、定期的に評価を実行する「モニタリング」体制を構築します。外部APIの仕様変更やモデルの世代交代がシステムの品質に直結するため、継続的な監視が不可欠です。

  • 週次/月次の自動評価: 定期的にベンチマークを実行し、スコアの推移をグラフ化して可視化します。
  • モデル更新・廃止への対応: AIモデルプロバイダーは、定期的にモデルの刷新を行います。旧モデルの廃止（Deprecation）や、より高性能な最新モデルへの移行が発表された際、即座に新旧モデルでの精度比較を行えるよう準備しておくことが重要です。
  • アラート設定: スコアが急激に低下した場合（例：誤ったデータの投入、モデルの挙動変化など）、管理者に即座に通知が飛ぶ仕組みを設けます。

ユーザーフィードバック（クリックログなど）との突き合わせ

オフライン評価（NDCGなど）と、オンライン評価（実際のユーザー行動）の相関を確認することも非常に重要です。

  • CTR（クリック率）
  • ゼロ件ヒット率
  • 「役に立った」ボタンの押下率

「NDCGのスコアは高いが、実際のクリック率が低い」といった場合、評価用データセット（Ground Truth）の正解基準が実際のユーザーニーズとズレている可能性があります。その際は、データセットの再構築を検討する必要があります。

ドキュメント更新時の回帰テストとしての活用

ドキュメントの改訂時には、古い情報がヒットしてしまうなどの問題が発生しがちです。更新のバッチ処理後に評価スクリプトを実行し、「検索性が損なわれていないか」を担保する回帰テスト（リグレッションテスト）として活用することで、システムの品質を維持できます。

まとめ

ndcg@10 と mrr@10 を計算 - Section Image 3

AI検索の精度評価には確かに手間がかかりますが、「なんとなく」の感覚的な評価でリリースしたシステムは、ユーザーの信頼を損ない、プロジェクト全体を失敗させるリスクを孕んでいます。

  • 指標の定義: 目的（正解探索か、情報収集か）に合わせてMRRとNDCGを論理的に使い分ける。
  • データの準備: LLMを活用し、効率的かつ体系的にGround Truthを作成する。
  • 実装と分析: Pythonを用いて評価を自動化し、客観的な数値に基づいて改善サイクルを回す。

このプロセスを確立することで、チームは自信を持ってAIシステムをリリースできるようになります。また、モデルの廃止や新モデルが登場した際にも、客観的な数値に基づくスムーズな移行判断が可能となります。

実際のプロジェクト現場では、「自社データ特有の癖で精度が出ない」「Ground Truth作成のためのリソースが不足している」といった課題に直面することもあるでしょう。だからこそ、評価基盤の構築は最初の設計段階からしっかりと組み込んでおくことが重要です。

検索精度の「感覚評価」を卒業する。NDCGとMRRによるAI検索評価の実装ガイド - Conclusion Image

コメント

コメントは1週間で消えます
0 / 150
コメントを読み込み中...