rag-auditor

RAG 監査

検索から生成までの全工程にわたって、RAG パイプラインを体系的に評価します。評価用クエリセットの設計、検索指標（Precision@K、Recall@K、MRR）の測定、生成品質（根拠性、完全性、ハルシネーション率）の評価、コンポーネントレベルの障害診断、対象を絞った改善策の推奨を行います。

参照ファイル

ファイル	内容	読み込むタイミング
references/retrieval-metrics.md	Precision@K、Recall@K、MRR、NDCG の定義と計算	常に
references/generation-metrics.md	根拠性、完全性、ハルシネーション検出の手法	生成評価が必要なとき
references/failure-taxonomy.md	RAG の障害カテゴリ：検索、生成、チャンク分割、埋め込み	障害診断が必要なとき
references/diagnostic-queries.md	評価用クエリセット、正解が既知の質問、難易度レベルの設計	評価の準備時

前提条件

• RAG パイプラインへのアクセス（または事後評価用の出力）
• 正解が分かっているテストクエリのセット
• パイプラインのコンポーネント（埋め込みモデル、リトリーバー、ジェネレーター）に関する理解

ワークフロー

フェーズ 1：パイプラインの棚卸し

RAG パイプラインの構成を記録します。

1. ドキュメントソース — どのドキュメントがインデックス化されていますか？形式、件数、サイズ。
2. チャンク分割 — 戦略（固定サイズ、セマンティック、段落）、チャンクサイズ、オーバーラップ。
3. 埋め込み — モデル名とバージョン、次元数。
4. ベクトルストア — 種類（FAISS、Pinecone、Chroma、pgvector）、インデックスタイプ。
5. 検索 — 手法（類似度、ハイブリッド、再ランキング）、top-K パラメーター。
6. 生成 — モデル、プロンプトテンプレート、コンテキストウィンドウの使用状況。

フェーズ 2：評価用クエリの設計

多様なテストクエリを作成します。

クエリの種類	目的	件数
正解既知（ファクトイド）	検索と生成の精度を測定する	10+
マルチホップ	複数のチャンクの情報を組み合わせる必要がある	5+
回答不能	コーパスに含まれない — 回答を控えるべき	3+
曖昧	複数の妥当な解釈が可能	3+
最新／更新済み	情報の鮮度をテストする	2+

各クエリについて、期待される回答とソースチャンクを記録します。

フェーズ 3：検索の評価

各テストクエリについて、次の項目を測定します。

1. Precision@K — 検索された K 個のチャンクのうち、関連するものはいくつですか？
2. Recall@K — コーパス内の関連チャンク全体のうち、検索されたものはいくつですか？
3. MRR（平均逆順位） — 最初の関連チャンクはどの程度上位にランク付けされていますか？
4. チャンクの関連性 — 検索された各チャンクを評価します：関連、部分的に関連、無関係。

フェーズ 4：生成の評価

検索コンテキストがある各テストクエリについて、次の項目を評価します。

1. 根拠性 — 回答内のすべての主張は、検索されたコンテキストによって裏付けられていますか？ スコア：0（ハルシネーション）～1（完全に根拠がある）。
2. 完全性 — 回答は、コンテキストに含まれる関連情報をすべて活用していますか？ スコア：0（コンテキストを無視）～1（完全）。
3. ハルシネーション検出 — コンテキストによって裏付けられていない具体的な主張を特定します。
4. 回答の保留 — 回答できないクエリに対して、モデルは「分かりません」と正しく回答しますか？

フェーズ 5：失敗の診断

誤りのある応答や品質の低い応答について、根本原因を分類します。

失敗の種類	診断	指標
検索の失敗	関連するチャンクが検索されていない	Recall@K が低い
ランキングの失敗	関連するチャンクは検索されたが、順位が低い	MRR が低く、Recall が高い
チャンク境界の問題	回答がチャンク境界で分割されている	複数のチャンクに部分的な一致がある
埋め込みの不一致	クエリの意味とチャンクの埋め込みが一致しない	関連するチャンクの類似度スコアが低い
生成の失敗	コンテキストは正しいが、回答が誤っている	検索スコアが高く、根拠との整合性が低い
ハルシネーション	モデルがコンテキストにない事実を作り出している	どのチャンクにもたどれない主張がある
過剰な回答拒否	コンテキストが十分なのに、モデルが回答を拒否する	関連するコンテキストがあるのに未回答

フェーズ 6：改善案

失敗分析に基づいて、具体的な改善策を提案します。

失敗パターン	推奨事項
チャンク境界の問題	オーバーラップを増やし、セマンティックチャンク分割を試す
Precision@K が低い	K を減らし、再ランキングの段階を追加する
Recall@K が低い	K を増やし、ハイブリッド検索を試す
埋め込みの不一致	別の埋め込みモデルを試し、クエリ拡張を追加する
ハルシネーション	プロンプトの根拠付け指示を強化し、温度を下げる
過剰な回答拒否	プロンプトの回答拒否基準を緩和する

出力形式

## RAG Audit Report

### Pipeline Configuration
| Component | Value |
|-----------|-------|
| Documents | {N} ({format}) |
| Chunking | {strategy}, {size} tokens, {overlap}% overlap |
| Embedding | {model} ({dimensions}d) |
| Retrieval | {method}, K={N} |
| Generation | {model}, temperature={T} |

### Evaluation Dataset
- **Total queries:** {N}
- **Known-answer:** {N}
- **Multi-hop:** {N}
- **Unanswerable:** {N}

### Retrieval Quality

| Metric | Score | Target | Status |
|--------|-------|--------|--------|
| Precision@{K} | {score} | {target} | {Pass/Fail} |
| Recall@{K} | {score} | {target} | {Pass/Fail} |
| MRR | {score} | {target} | {Pass/Fail} |

### Generation Quality

| Metric | Score | Target | Status |
|--------|-------|--------|--------|
| Groundedness | {score} | {target} | {Pass/Fail} |
| Completeness | {score} | {target} | {Pass/Fail} |
| Hallucination rate | {score} | {target} | {Pass/Fail} |
| Abstention accuracy | {score} | {target} | {Pass/Fail} |

### Failure Analysis

| # | Query | Failure Type | Root Cause | Recommendation |
|---|-------|-------------|------------|----------------|
| 1 | {query} | {type} | {cause} | {fix} |

### Recommendations (Priority Order)
1. **{Recommendation}** — addresses {N} failures, expected impact: {description}
2. **{Recommendation}** — addresses {N} failures, expected impact: {description}

### Sample Failures

#### Query: "{query}"
- **Expected:** {answer}
- **Retrieved chunks:** {chunk summaries with relevance scores}
- **Generated:** {response}
- **Issue:** {diagnosis}

評価の調整ルール

1. コンポーネントの分離。 検索と生成を個別に評価します。出力結果だけを確認すると、優れた検索器と性能の低い生成器の組み合わせを、検索の失敗と誤認する可能性があります。
2. 既知の回答から始める。 正解が明確な事実確認型の質問から始めます。複数の情報をたどる必要があるクエリや曖昧なクエリは、評価がより困難です。
3. 定量化し、評価語で片付けない。 「検索の性能が悪い」は分析結果とは言えません。「Precision@5 は 0.3（目標：0.8）で、失敗の 70％はチャンク境界での分割が原因です」なら、具体的な対策につながります。
4. 失敗を詳しくサンプリングする。 集計指標から問題がどこにあるかが分かり、個々の失敗分析からその理由が分かります。

エラー処理

問題	解決策
正解が分かっているクエリがない	ドキュメントコーパスからクエリを作る方法を支援します。10 個の事実を選び、それをもとに質問を作成します。
パイプラインにアクセスできない	記録済みの入力と出力を使って評価します。クエリ・コンテキスト・応答の組み合わせがあれば、事後評価が可能です。
コーパスが大きすぎて確認できない	サンプリングに基づいて評価します。代表的なドキュメントを選び、それらをもとにクエリを作成します。
複数の失敗の種類が同時に発生している	まず検索の失敗に対処します。生成品質が検索品質を超えることはありません。

監査を行わない場合

次の場合は、まず別の対応を行うよう提案してください。

• パイプラインがまだ構築されていない場合 — まず設計し、その後で監査します
• コーパスのドキュメント数が 10 件未満の場合 — 意味のある検索評価を行うには少なすぎます
• 埋め込みモデルを比較したい場合 — これは監査ではなく、ベンチマークのタスクです