2026年9月26日。RAGで検索件数やプロンプトを調整すると、平均点は上がっても「根拠のない回答を止める」「閲覧できない文書を返さない」といった重要な条件が悪化することがあります。改善を判断する単位を平均点だけにすると、この退行を見落とします。
この記事は公開資料をもとにした評価設計案です。以下のスキーマと判定手順は未実装・未検証であり、自社環境での改善実績や性能値ではありません。想定読者は、RAGの検索や回答生成を変更し、品質を説明してからリリースしたいエンジニアとテックリードです。
技術的な問い：何が改善されたらリリースしてよいか
たとえば社内文書を検索するRAGでは、利用者が期待するのは「近い文書」ではなく、許可された有効な根拠に沿う回答、または回答できないという判断です。検索漏れ、古い文書の混入、引用の誤りは、それぞれ直す場所が違います。
Microsoftの検索評価ガイドは、正解文書を持つテスト質問からPrecision@K、Recall@K、MRRなどを測る方法を示しています。一方、Amazon BedrockのRAG評価指標は検索だけの評価と検索・生成を合わせた評価を分け、生成側で忠実性や引用を扱います。この境界をそのまま失敗の切り分けに使います。
設計選択肢：評価をどの単位で見るか
| 方式 | 得られるもの | 見落としやすいもの |
|---|---|---|
| 回答の平均点だけを見る | 変更候補を素早く比較できる | 権限外の参照や回答不能質問での誤回答 |
| 検索と回答を別々に測る | 検索漏れと生成の失敗を分離できる | 特定の質問群だけに起きる退行 |
| 段階別指標に失敗分類と質問群別の差分を加える | 修正箇所とリリース可否を説明できる | ラベル作成と人手確認の費用が増える |
本番候補には3番目を選びます。検索の総合点が改善しても、権限、版、回答不能といった条件で退行したら止めるためです。ただし、すべての質問に細かい人手ラベルを付けると維持できません。初期は障害につながりやすい質問群を厚くし、通常質問は代表例に絞ります。
評価セット：正解文だけでなく失敗条件を保存する
一件の評価ケースに、質問だけでなく、検索対象の版、利用者の権限、必要な根拠、期待する応答動作を保存します。次は設計用のデータ例で、実在の業務データではありません。
{
"caseId": "q-014",
"slice": "outdated_conflict",
"question": "現在の受付期限はいつか",
"corpusRelease": "docs-v2",
"principal": "viewer-a",
"requiredEvidenceIds": ["policy-current#section-2"],
"forbiddenEvidenceIds": ["policy-expired#section-2"],
"expectedBehavior": "answer_with_citation"
}
requiredEvidenceIds は答えに必要な根拠、forbiddenEvidenceIds は使ってはいけない旧版や権限外の根拠です。複数文書が必要な質問では、1件だけ検索できても成功としません。反対に、根拠が存在しない質問は expectedBehavior: "abstain" とし、検索Recallの分母へ機械的に混ぜず、回答保留の成否を別に数えます。
最初に用意する質問群は次のように分けます。
| 質問群 | 期待する確認 | 主な失敗ラベル |
|---|---|---|
| 通常の単一根拠 | 必要な文書が検索され、引用に結び付く |
retrieval_miss、citation_mismatch
|
| 複数根拠 | 必要な文書をすべて取得し、条件を落とさない |
partial_evidence、answer_omission
|
| 該当文書なし | 根拠を作らず回答を保留する | unsupported_answer |
| 旧版との競合 | 有効版だけを採用する | stale_evidence |
| 権限外の文書が近い | 検索前に認可し、結果にも混入させない | unauthorized_evidence |
ラベルの対象は「回答がなんとなく良いか」ではありません。retrieval_miss なら検索・取り込み・権限フィルター、citation_mismatch なら回答生成後の主張と引用の対応、というように修正箇所へつなげます。権限外の候補が検索結果に現れた時点で、最終回答に表示されなくても失敗とします。
実装の要点：同じ条件で基準版と候補版を比較する
評価時は、文書スナップショット、利用者の権限、評価ケース、モデル識別子、検索設定、プロンプト版を記録します。検索方式を比較する間に文書版も変えると、差分の原因が分からなくなるためです。生成には揺れがあるので、同一ケースの回答評価は再実行結果と人手確認の対象を残します。Microsoftの回答評価ガイドも、生成結果の非決定性と複数指標の併用を説明しています。
同じ評価ケース・同じ文書版・同じ権限で
基準版と候補版の検索結果を保存
必要な根拠の取得と禁止根拠の混入を判定
回答、引用、保留判断を保存
回答の忠実性と網羅性を人手または評価器で判定
質問群ごとに改善・退行・未判定を集計
禁止根拠の混入、権限逸脱、根拠なしの断言があればリリース保留
それ以外も重要な質問群に退行があれば原因調査
品質の改善が確認でき、遅延と費用が許容範囲なら候補にする
自動評価器の点数は調査の入口にします。正解ラベルや評価器自身が誤る可能性があるため、重大失敗と基準版・候補版で判定が割れた例は人が原文と照合します。合格の閾値は業務上許せる誤り、保留率、人手確認の容量から決め、根拠のない一律の数値を置きません。
失敗しやすい変更とトレードオフ
Top-Kを増やすと必要な文書を拾いやすくなる一方、無関係な文書や旧版が混ざり、生成の入力長・遅延・費用も増えます。検索Recallだけで採用せず、引用と回答保留も同じケースで比較します。
プロンプトだけを変えると、検索漏れを隠したもっともらしい回答が出ることがあります。根拠を取得できたかを先に判定し、取得できていないケースを生成の改善として数えません。
評価ケースを同じデータから量産すると、似た質問ばかりになり、実際の言い換えや権限境界を測れません。公開可能な合成質問に加え、運用時には適切に匿名化・権限確認した失敗例をラベル付きで追加する設計にします。ここでの本番ログ収集は提案であり、実施済みの主張ではありません。
本番運用：失敗を次の評価ケースへ戻す
運用ログには追跡ID、文書版、検索設定版、取得した文書ID、引用ID、失敗分類、保留理由、検索・生成それぞれの遅延を残す設計にします。質問本文や文書本文を無条件に複製せず、保存範囲と期間を決めます。モデルや評価器への送信先も、扱う情報の権限に合わせて選びます。
監視は総合点だけでなく、質問群別の検索漏れ、禁止根拠の混入、根拠なし回答、保留率、人手確認の滞留、評価・生成の費用を追います。失敗が出たら、原因が確定した例を評価セットへ追加して同じ退行を検出できるようにします。人手確認の件数を無視して自動保留を増やすと、回答の誤りを別の待ち行列へ移すだけです。
事業面で期待できるのは、設定変更の良し悪しを説明し、危険な退行を公開前に止めることです。工数削減額やROIは未計測であり、この設計案からは算定しません。
次に検証すること
公開可能な小さな文書集合で五つの質問群を作り、基準版と候補版の検索結果を保存します。まず禁止根拠と回答保留の判定を人手で確認し、その後に検索設定を一つずつ変えます。評価器と人の判定が食い違うケースを残し、ラベルの定義を直してからリリース条件を固定します。
参考リンク
同様の仕組みの設計・構築・運用については相談可能。
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。