RAGの品質保証を統計的に担保する：信頼区間とプロンプト自動チューニングによる半自動回復アーキテクチャ（未検証）

はじめに

RAG（Retrieval-Augmented Generation）を用いたシステムを実務に導入する際、必ず直面する課題があります。

「で、そのAI、どのくらいの精度が出るの？品質（SLO）はどう担保するの？」
「品質が落ちたらどうやって回復するの？」

生成AIの回答は確率的であり、従来のシステム開発のような「100%の正解」を保証することは困難です。しかし、クライアントやビジネスサイドからは、具体的な数値目標や、品質が悪化した際の回復手順（SOP） を求められます。

本記事では、以下の2つを組み合わせた独自の運用アーキテクチャ案を紹介します。

統計的アプローチ（信頼区間）によるSLO担保
プロンプト自動チューニングを用いた半自動回復

注意: あくまで設計段階の備忘録であり、実証実験はこれからです。

背景：なぜ「信頼区間」なのか？

RAGシステムの評価では、「正答率80%」のような点推定だけでは不十分です。なぜなら：

サンプル数が少ない場合、たまたま良い結果が出ただけかもしれない
「80%」という数値の信頼性が不明
クライアントに「統計的に保証できる範囲」を示せない

そこで、信頼区間（Confidence Interval） を用いることで、「95%の確率で、真の正答率は75%〜85%の範囲にある」といった統計的根拠のある品質保証が可能になります。

参考: 23-3. 母平均の信頼区間 | 統計学の時間 | 統計WEB

アーキテクチャ全体像

本設計の核心は、「生きたデータセットを常に作り続け、それを基準に統計的有意性を以てSLOを判断し、下回ったら機械的にチューニングを回す」 という自己修復ループです。

使用するツール・技術

ツール/概念	役割
Ragas	RAGパイプラインの評価フレームワーク（Faithfulness, Answer Relevance等）
信頼区間	母平均の推定によるSLO判定
Vertex AI Prompt Optimizer	プロンプトの自動最適化 (公式ブログ)
セッション管理ツール	会話の文脈ごとにデータセットを自動生成

実装詳細

1. 「生きたデータセット」の自動生成

静的なテストデータだけでは、ユーザーの多様な入力に対応しきれません。そこで、日々の会話ログから自動的に評価用データセットを生成します。

セッションID自動切り替えロジック

会話の内容（話題）が変わったことをLLMのツール呼び出しで検知し、自動的に新しいセッションIDを割り振ります。

メリット:

「1つの長い会話」でも話題ごとに分割
「脈絡のない短い会話の連続」でも文脈を保持
話題ごとに区切られた一意なデータとして蓄積

もちろん、運用チームが事前に用意した「想定質問集」もベースとして使用します。

2. 正解判定の方法：ハイブリッド評価アプローチ

RAGシステムにおける最大の課題の一つが、「何を持って正解とするか」 の定義です。本設計では、以下の3層構造のハイブリッド評価方式を採用します。

レイヤー1: LLM-as-a-Judge（主要評価軸）

最も重要な評価軸として、LLMに人間の代わりに回答の正確性を判定させる「LLM-as-a-Judge」方式を採用します。

なぜLLM-as-a-Judgeなのか？

従来の評価方法	課題	LLM-as-a-Judgeの利点
人間による評価	コストが高い、スケールしない	完全自動化、大量データに対応可能
完全一致（Exact Match）	表現の揺れに対応できない	意味的な正確性を評価できる
BLEU/ROUGEスコア	生成AIの評価には不適切	文脈を理解した評価が可能

評価の基準:

LLMに以下の3つの観点で回答を評価させます：

正確性（Correctness）: 回答が事実として正しいか、幻覚がないか
完全性（Completeness）: 必要な情報が全て含まれているか
関連性（Relevance）: 質問に対して適切な回答か

評価結果の形式:

LLMには、スコア（0-1）だけでなく、判定理由も出力させることが重要です。これにより：

人間が評価の妥当性を確認できる
問題のあるパターンを発見しやすい
運用チームが改善方針を立てやすい

精度向上のポイント:

Chain-of-Thought: 判定理由を明示的に出力させることで精度向上
複数モデルによる多数決: GPT-4、Claude、Geminiなど複数のLLMで評価し、コンセンサスを取る
Few-shot Examples: 良い回答・悪い回答の例を提示して判定基準を明確化

レイヤー2: Ground Truth + Ragasメトリクス（補助評価）

事前に用意した「理想的な回答の要素」と、Ragasの各種メトリクスを組み合わせて評価します。

Ground Truthの作り方:

必須要素のリスト（「社内ポータルから申請」「上長の承認が必要」など）
含まれてはいけない要素（よくある誤解）
参照元ドキュメント

レイヤー3: 人間による運用とガバナンス（品質保証の最終防衛線）

完全自動化だけでは見逃すリスクや、ビジネス判断が必要なケースがあるため、人間が主体となって運用する仕組みを設けます。

基本方針:

自動評価はあくまで「補助ツール」であり、最終判断は人間が行う
運用チームが定期的にレビューし、システムの健全性を確認
異常検知時は人間が介入し、根本原因を分析

運用フロー:

定期レビュー会議（週次/月次）
- 自動評価スコアのトレンド確認
- ユーザーからのフィードバック分析
- エスカレーション案件のレビュー
- Ground Truthデータセットの更新判断
エスカレーション案件の人間判定
- 問い合わせチームにエスカレーションされたケースを週次でレビュー
- 「本来は自動回答できたはず」のケースを特定
- Ground Truthデータセットに追加するか判断
Ground Truthデータセットの管理
- 運用チームメンバーが新規エントリを提案
- 別のメンバーがレビューして承認/却下
- 承認されたものをデータセットに追加
ユーザーフィードバックの収集と分析
- 👍👎フィードバック収集
- ネガティブフィードバックを毎日確認
- 問題のある回答パターンを特定
月次の品質監査
- ランダムに50-100件を抽出
- 運用チームが実際の回答品質を目視確認
- 自動評価の妥当性を検証

人間主体の運用における重要な原則:

原則	説明
自動化は補助	LLM-as-a-Judgeは人間の判断を助けるツールであり、最終判断は人間が行う
透明性	自動評価の根拠を人間が理解できる形で提示
継続的改善	人間のフィードバックをもとにシステムを改善
責任の明確化	品質に関する最終責任は運用チームが持つ

3. 信頼区間によるSLO判定

ここが本設計の最大のポイントです。単に「正答率80%」といった点推定ではなく、信頼区間を用いて評価します。

重要：正答率（二値）による信頼区間計算

信頼区間の計算には、0（不正解）か1（正解）の二値データが必要です。ハイブリッド評価の最終スコアを閾値（例: 0.75）で二値化し、正答率を計算します。

母比率の信頼区間計算:

正答率は母比率（proportion） なので、二項分布に基づく信頼区間を計算します。

正答率 = 正解数 / 全体数
標準誤差 = √(正答率 × (1 - 正答率) / サンプル数)
95%信頼区間 = 正答率 ± 1.96 × 標準誤差

サンプル数と信頼区間の幅の関係:

サンプル数	正答率80%の場合の95%信頼区間	誤差範囲
30	[63.6%, 96.4%]	±16.4%
50	[68.9%, 91.1%]	±11.1%
100	[72.2%, 87.8%]	±7.8%
200	[74.5%, 85.5%]	±5.5%
500	[76.5%, 83.5%]	±3.5%

→ サンプル数が多いほど、信頼区間が狭くなり、より正確な推定が可能

SLOの定義と判定

SLO: 「信頼区間の下限値が、設定した基準（例: 75%）を上回っていること」

判定例:

ケース1: SLO達成
正答率: 82%, 95%信頼区間: [78.2%, 85.8%]
✅ SLO達成: 信頼区間下限 78.2% >= 75%

ケース2: SLO未達
正答率: 76%, 95%信頼区間: [71.5%, 80.5%]
❌ SLO未達: 信頼区間下限 71.5% < 75%
→ プロンプト自動チューニングを起動

ケース3: サンプル不足
正答率: 80%, 95%信頼区間: [60.2%, 99.8%]（サンプル数20）
⚠️ 警告: 信頼区間が広すぎます（誤差範囲 ±19.8%）
→ より多くのデータを収集してください

メリット:

統計的に正しい: 二項分布に基づく正確な信頼区間
説得力: 「95%の確率で正答率は75%以上」と明言できる
データ不足の検知: 信頼区間が広すぎる場合、サンプル不足を警告

4. プロンプト自動チューニングによる回復（Self-Healing）

SLOを下回った場合、人手でプロンプトを修正するのではなく、まずは自動チューニングを試みます。

自動チューニングフロー

Vertex AI Prompt Optimizerなどのツールを利用
評価用データセットを用いてプロンプトの最適化を実行
ループ実行: 改善が見られるまで（またはSLOを満たすまで）、一定回数（3〜5回程度）を上限にチューニングをループ
SLO達成したら、運用チームに承認依頼
上限回数に達してもSLO未達の場合、運用チームにアラート

5. ガバナンスと承認フロー

自動チューニングで「SLOを満たすプロンプト」が生成されたとしても、勝手に本番適用はしません（ハルシネーション等の予期せぬリスクがあるため）。

承認フロー

通知: チューニング結果（Before/Afterのプロンプトと評価スコア）を、メールやSlackで運用チームに通知
承認: 運用チームが内容を確認し、「承認」した場合のみ本番環境のプロンプトを更新
最終手段: 自動チューニングの上限回数に達してもSLOが回復しない場合は、運用チームによる専門的な解析（データセットの見直し、検索ロジックの修正など）に移行

システム全体のフロー図

データ収集と評価のフロー

期待されるメリット

メリット	説明
説得力のある品質保証	「なんとなく良さそう」ではなく、統計的根拠（信頼区間）に基づいたSLO提示が可能
運用コスト削減	プロンプト修正の工数を、自動チューニングで代替（一次対応）
安全性の担保	最終的なデプロイ判断は人間が行うことで、AIの暴走を防止
継続的改善	会話ログから自動的にデータセットが蓄積され、評価精度が向上

今後の課題と検証項目

まだ構想段階のため、以下の点を実証実験で検証する予定です。

セッションID切り替えロジックの精度（誤検知率）
LLM-as-a-Judgeと人間判定の一致率
自動チューニングの収束率（何%のケースで回復するか）

まとめ

RAGシステムの品質保証は、従来のソフトウェア開発とは異なるアプローチが必要です。本記事で紹介した信頼区間によるSLO担保とプロンプト自動チューニングの組み合わせは、実務での説得力と運用効率を両立させる一つの解になり得ると考えています。

重要なのは、自動化に頼りすぎず、人間が主体的に運用するという原則です。LLM-as-a-Judgeはあくまで補助ツールであり、最終的な品質責任は運用チームが持つべきです。

実証実験の結果は、また別の記事で共有する予定です。
RAGの品質管理に悩む方の参考になれば幸いです。

参考文献

評価フレームワーク

Ragas Documentation - RAG評価フレームワークの公式ドキュメント
LLM-as-a-Judge: A Survey - LLMを評価者として使う手法の研究

プロンプト最適化

Announcing Vertex AI Prompt Optimizer - Google Cloudのプロンプト自動最適化ツール

統計・信頼区間

母平均の信頼区間 | 統計学の時間 | 統計WEB - 信頼区間の基礎