RAGの品質とコストを定量評価する方法 — 評価ハーネスを使った実測アプローチ

RAG（Retrieval-Augmented Generation）システムは、LangChainやLlamaIndexなどのライブラリを使えば、数時間で動作するプロトタイプを作成できます。しかし、そのRAGが本当に「使える」品質かどうかは別問題です。検索精度は十分か、ハルシネーションは許容範囲内か、運用コストは現実的か——これらを感覚ではなく数値で把握することが、プロダクション環境への移行には不可欠です。

今回紹介する取り組みは、自作RAGシステムに対して評価ハーネスを構築し、検索品質・ハルシネーション抑制・コストの3軸で定量評価を実施した記録です。この実践から、RAG評価の具体的手法と測定上の限界が明らかになりました。

検索品質の評価

検索品質の評価では、クエリに対して適切なドキュメントチャンクが取得できているかを測定します。一般的には以下の指標が用いられます:

評価ハーネスでは、事前に正解ラベル付きのクエリセットを用意し、システムの検索結果と照合することでこれらの指標を算出します。

ハルシネーション抑制の測定

ハルシネーション（LLMによる事実と異なる回答生成）の評価は、RAGで最も重要かつ難しい課題です。測定アプローチとしては:

この実践では、おそらく評価用のテストセットに対して回答を生成し、その正確性を複数の方法で検証したと考えられます。

1クエリあたりのコスト計測

コスト評価は見落とされがちですが、ビジネス判断には必須の指標です:

評価ハーネスでは、各クエリ処理時のトークン消費量と処理時間を記録し、平均値と分散を算出することで、運用時の予想コストを見積もります。

従来の評価手法との決定的な違い

従来、RAGシステムの評価は「いくつかのクエリを試して目視確認」という定性的アプローチが主流でした。これに対し、評価ハーネスを使った定量評価は以下の点で優れています:

**再現性**: 同じテストセットで繰り返し測定できるため、改善効果を客観的に確認できます。チャンクサイズを変更した、埋め込みモデルを変えた、プロンプトを調整した——これらの変更が実際に指標を改善したかを数値で追跡できます。

**ボトルネック特定**: 3つの指標を独立して測定することで、問題の所在を特定できます。例えば、検索品質は高いのにハルシネーションが多い場合、問題は検索ではなくLLMのプロンプト設計やモデル選択にあると判断できます。

**コストの可視化**: 感覚的に「遅い」「高い」ではなく、「平均応答時間2.3秒」「1クエリ0.05ドル」といった具体的な数値で議論できます。これはステークホルダーへの説明や予算策定に不可欠です。

メリットと注意すべき限界

**メリット**:

1. **継続的改善の基盤**: CI/CDパイプラインに組み込めば、コード変更のたびに品質劣化を検出できます

2. **A/Bテストの実施**: 複数の構成を客観的に比較し、最適な設定を選択できます

3. **ドキュメント化**: 測定結果自体がシステムの性能仕様書として機能します

**注意点と限界**:

1. **テストセットの品質依存**: 評価は作成したテストセットの質に完全に依存します。実際のユーザークエリ分布と乖離していれば、測定結果は実運用の性能を反映しません

2. **ハルシネーション評価の難しさ**: LLM-as-a-Judgeは便利ですが、評価者LLM自身がハルシネーションを起こす可能性があります。人手評価は精度が高いものの、コストとスケーラビリティに課題があります

3. **コンテキストの欠如**: 定量指標だけでは、ユーザー体験の質（回答の自然さ、文脈理解の深さ）を完全には捉えられません

4. **測定コスト**: 評価ハーネス自体の構築と維持にも相応の工数がかかります

適用すべきシーンと優先順位

このアプローチは以下の状況で特に有効です:

逆に、小規模な実験や概念実証（PoC）段階では、評価ハーネスの構築コストが見合わない場合もあります。その場合は、まず少数のクエリでの定性評価から始め、本番化の決定後に評価基盤を整備するアプローチが現実的です。

1. ミニマルなテストセットから始める

評価ハーネスは大規模である必要はありません。まずは以下のステップで小さく始めましょう:

1. 実際のユーザーが尋ねそうな質問を10〜20個リストアップ

2. 各質問に対する理想的な回答（またはエビデンス文書）を記録

3. CSVやJSONで管理し、バージョン管理システムに登録

これだけで、コード変更前後の比較が可能になります。

2. コスト測定を自動化する

以下のような簡単なコードで、クエリごとのコストをロギングできます:

import time
from typing import Dict

def measure_query_cost(query: str) -> Dict:
    start_time = time.time()
    
    # RAG処理の実行
    response, metadata = rag_system.query(query)
    
    elapsed_time = time.time() - start_time
    
    return {
        "query": query,
        "latency_seconds": elapsed_time,
        "input_tokens": metadata.get("input_tokens", 0),
        "output_tokens": metadata.get("output_tokens", 0),
        "estimated_cost_usd": calculate_cost(metadata)
    }

毎回のクエリでこの情報をログに記録すれば、統計分析が可能になります。

3. LLM-as-a-Judgeで半自動評価を導入

完全な自動化は難しくても、LLMを使った初期スクリーニングは有効です:

evaluator_prompt = """
以下の質問、取得文書、回答を評価してください。

質問: {query}
取得文書: {retrieved_docs}
回答: {response}

評価基準:
1. 回答は取得文書に基づいていますか？（Yes/No）
2. 回答は質問に正確に答えていますか？（Yes/No）
3. 不適切な推測や事実でない情報が含まれていますか？（Yes/No）

JSON形式で回答してください。
"""

この評価を全テストケースに対して実行し、問題がある回答だけを人手で詳細確認すれば、効率的に品質チェックができます。

この情報は @Hal-Hanami さんの投稿を参考にしています。

RAGシステムの品質向上において、評価ハーネスによる定量測定は「あれば便利」ではなく「なければ改善不可能」なレベルの重要性を持ちます。デモリポジトリが公開されていることで、実際の測定手法を学べるのは貴重な機会です。

測定には限界もありますが、まず測定することで初めて、現状の課題が見え、改善の方向性が定まります。小さなテストセットからでも構わないので、今日から評価基盤の構築を始めることをお勧めします。