QAチャット評価設計思想

種別：評価設計 / 統計評価 / リスク評価適用対象：RAG、社内QA、顧客向けQA、Knowledge検索対象工程：Test / Release判定 / 監視 / 再評価

前ページでは、QAチャットを、検索・生成・根拠提示・回答拒否・人への移管まで含む運用システムとして整理しました。

このページでは、そのシステムをどう評価するかを考えます。

結論から言えば、QAチャットの品質を一つの正答率で表すことはできません。

QAチャットの評価とは、回答の賢さを採点することではない。どの工程で、どの種類の失敗が、どれだけの損失を生むかを測ることである。

検索が失敗したのか。

取得した根拠を誤読したのか。

答えるべきでない質問へ答えたのか。

正しく拒否したが、利用者を次の行動へつなげられなかったのか。

原因が違えば、改善すべき場所も違います。

「通常ソフトウェアと本質的に別」ではない

生成AIは、入力とContextに対して出力候補の確率分布を作ります。

モデルを $\theta$ 、質問を $x$ 、利用可能なContextを $c$ 、回答を $y$ とすると、概念的には次のように表せます。

y \sim P_\theta(y\mid x,c)

同じ入力でも、モデル、設定、Context、サンプリングによって回答が変わる可能性があります。

ただし、ここから「通常ソフトウェアは決定論、生成AIは確率論なので、評価方法が完全に別」と結論づけるのは粗すぎます。

通常ソフトウェアにも、性能、障害率、負荷、利用状況などの統計評価があります。

一方、QAチャットにも、権限判定、JSON形式、引用URLの存在、禁止語、応答時間のように、決定的に検証できる部分があります。

違いは二分法ではありません。

QAチャットでは、意味の妥当性、根拠との整合、回答拒否の適切さまで評価対象に加わることです。

したがって、従来のテストを捨てるのではなく、確率的・意味的な評価を追加します。

最終回答だけを見ても、故障箇所は分からない

RAGを使うQAチャットは、少なくとも次の工程を通ります。

質問の受付
  ↓
対象範囲・回答可能性の判定
  ↓
Knowledgeの検索
  ↓
根拠の選択
  ↓
回答生成
  ↓
根拠・形式・制約の検証
  ↓
回答／追加質問／拒否／人への移管

RAGASは、RAGの評価を、検索されたContext、Contextの利用の忠実性、生成品質などの複数次元へ分けています。

これは実務でも重要です。

例えば、最終回答が誤っていたとしても、原因は一つではありません。

失敗	直す対象
必要な文書が検索対象にない	Knowledge管理
文書はあるが検索できない	分割、埋め込み、検索、再ランキング
正しい根拠を取得したが使わない	プロンプト、生成、Context構成
根拠にない主張を追加する	生成制約、検証、回答拒否
回答は正しいが対象外の利用者へ表示する	認証、権限、フィルタ
正しく拒否したが業務が止まる	追加質問、人への移管、運用

最終回答だけを「正解・不正解」で採点すると、これらが同じ一件の失敗に見えてしまいます。

評価は、最終結果と工程別診断の両方を持つ必要があります。

評価単位を先に決める

自然な文章を一件単位で丸ごと採点すると、評価者によって判断が揺れます。

そこで、評価単位を分けます。

1. 質問単位

回答すべき質問だったか
必要な資料を取得できたか
適切な終了状態を選べたか

2. 主張単位

回答中に検証可能な主張はいくつあるか
各主張を根拠が支持しているか
根拠の版と適用条件は正しいか

3. 業務単位

利用者は目的を完了できたか
人間の確認・修正時間は減ったか
誤答による手戻りや事故は増えていないか

FActScoreは、長文を原子的な事実へ分解し、信頼できる情報源に支持される割合を測る考え方を示しています。

QAチャットでも、回答全体へ曖昧な5段階評価を付けるより、主張単位で根拠を確認する方が故障を特定しやすくなります。

ただし、支持される主張の割合だけでは、重要な主張の欠落は測れません。

正確性と完全性は分けて評価します。

評価データは正常質問だけで作らない

評価セットには、普段よく聞かれる質問だけでなく、システムが迷う条件を含めます。

区分	評価したいこと
対象内・根拠十分	正しく回答できるか
対象内・入力不足	追加質問へ分岐できるか
対象内・Knowledge不足	根拠不足として拒否または移管できるか
対象外	無理に回答しないか
境界・曖昧	適用条件を確認できるか
資料が矛盾	勝手に一方を採用しないか
旧版と新版が混在	有効な版を選べるか
権限制約あり	閲覧できない情報を漏らさないか
誘導・誤前提あり	誤前提へ同調しないか

本番の質問分布を反映するデータと、危険条件を意図的に増やしたデータは分けて持ちます。

前者は日常性能を測るため、後者は安全限界を探るためです。

危険質問を大量に混ぜた評価セットの平均値を、そのまま本番の成功率と呼んではいけません。

評価セットの構成比が変われば、平均値も変わるからです。

回答と拒否を混同行列で測る

QAチャットには「答えない」という有効な行動があります。

そのため、回答の正しさだけでなく、回答するか停止するかの選択を評価します。

正しい状態＼システムの行動	回答する	停止する
回答可能	正常回答	過剰拒否
回答不能	危険回答	正常停止

ここで重要なのは、二種類の誤りの損失が同じではないことです。

危険回答：対象外、根拠不足、矛盾状態で回答する
過剰拒否：答えられる質問まで拒否する

危険回答を減らすために何でも拒否すれば、安全に見えますが、QAチャットとして使えません。

反対に回答率だけを上げれば、根拠のない回答が増える可能性があります。

そこで、少なくともCoverageとSelective Riskを対で見ます。

Coverage = \frac{\text{回答した件数}}{\text{全質問数}}

Selective\ Risk = \frac{\text{回答した中の損失合計}}{\text{回答した件数}}

拒否機能を持つ予測器では、CoverageとRiskにトレードオフがあることがSelective Classificationの研究でも扱われています。

QAチャットでは、単なるモデルの自己信頼度だけで回答可否を決めず、根拠取得、資料間矛盾、対象範囲、業務影響も判定材料にします。

RAGは検索と生成を分けて測る

検索評価

質問 $q$ に対する正解根拠の集合を $D_q$ 、上位 $k$ 件の検索結果を $Top_k(q)$ とします。

Recall@k(q) = \frac{|D_q\cap Top_k(q)|}{|D_q|}

Recall@kは、必要な根拠を上位 $k$ 件へどれだけ含められたかを表します。

Precision@k(q) = \frac{|D_q\cap Top_k(q)|}{k}

Precision@kは、取得した上位 $k$ 件に、関連する根拠がどれだけ含まれるかを表します。

検索結果を増やすとRecallは上がりやすい一方、無関係なContextも増えます。

したがって、検索件数を増やすだけで改善とは言えません。

根拠利用の評価

回答を検証可能な主張 $c_1,\dots,c_m$ に分け、採用可能な根拠が主張 $c_j$ を支持するとき $s_j=1$ 、支持しないとき $s_j=0$ とします。

Groundedness = \frac{1}{m}\sum_{j=1}^{m}s_j

ここで確認するのは、引用が付いているかではありません。

引用先が実在するか
引用箇所が主張を支持するか
文書の版と適用範囲が正しいか
回答に必要な重要主張が欠けていないか

引用数が多くても、主張と結び付いていなければGroundednessは高くありません。

平均正答率より期待損失を見る

すべての誤りを一件として数えると、軽微な表現ミスと、契約条件の誤案内が同じ重みになります。

実務では、失敗の発生率と影響を分けます。

失敗種別を $F_1,\dots,F_K$ 、失敗 $F_k$ の発生確率を $P(F_k)$ 、影響を $I_k$ とすると、期待損失は概念的に次のように表せます。

Expected\ Loss = \sum_{k=1}^{K}P(F_k)I_k

評価データ $n$ 件に、業務影響に応じた重み $w_i$ と損失 $L_i$ を付けるなら、経験的なリスクは次のように置けます。

\hat{R} = \frac{\sum_{i=1}^{n}w_iL_i}{\sum_{i=1}^{n}w_i}

これは損失額を正確に予言する式ではありません。

異なる失敗を、業務上の優先順位へ変換するための設計式です。

例えば、次のように重みを変えます。

失敗	影響の例	重みの考え方
文体が少し読みにくい	読み直し	低
関連資料を一件漏らす	追加検索	中
旧版を最新版として案内	手戻り・誤判断	高
権限外情報を表示	情報漏えい	極めて高

合格基準は「正答率80%以上」のように一律で決めません。

用途ごとの許容損失、利用者の確認能力、誤答時の回復可能性から決めます。

20件中18件正解を「90%」だけで報告しない

評価件数が少ないと、観測された割合は大きく揺れます。

例えば20件中18件が成功なら、観測値は90%です。

しかし、これは真の成功率が90%と確定したことを意味しません。

二項比率の区間推定としてWilson区間を使うと、成功数 $x$ 、件数 $n$ 、観測比率 $\hat p=x/n$ に対する区間は次の形になります。

\frac{ \hat p+\frac{z^2}{2n} \ \pm\ z\sqrt{\frac{\hat p(1-\hat p)}{n}+\frac{z^2}{4n^2}} }{ 1+\frac{z^2}{n} }

95%区間なら、おおむね $z=1.96$ を使います。

20件中18件の場合、95% Wilson区間は概算で約70%から97%です。

点推定90%だけを見るより、まだ不確実性が大きいことが分かります。

ただし、この区間も評価データが対象母集団を適切に代表し、各観測を二項試行として扱えるという前提に依存します。

同じ質問の言い換えを大量に含めれば、見かけの件数ほど情報量は増えません。

一つの総合点へ潰さない

QAチャットには複数の目的があります。

危険回答を減らす
回答可能な範囲を広げる
必要な根拠を取得する
利用者の確認時間を減らす
応答時間と費用を抑える

これらは同時に最大化できるとは限りません。

変更	改善しやすい指標	悪化し得る指標
回答条件を厳しくする	危険回答率	Coverage
検索件数を増やす	Recall@k	Precision、遅延、費用
検証工程を増やす	Groundedness	応答時間、費用
回答を短くする	読みやすさ	完全性

総合点を作る場合でも、元の指標を残します。

総合点だけでは、改善によって何を失ったかが見えないからです。

複数指標のどれかを改善すると別の指標が悪化する境界を、Pareto frontierとして比較する方法もあります。

設計判断は、最大点の一案を選ぶことではなく、用途に合ったトレードオフを選ぶことです。

AIによる自動評価は、正解そのものではない

回答の意味、関連性、読みやすさを大量に評価するため、別のLLMを評価者として使う方法があります。

これは評価速度を上げるのに有効です。

しかし、LLM-as-a-Judgeの研究では、位置、文章量、自己選好などのバイアスも報告されています。

したがって、自動評価は次のように使い分けます。

評価方法	向いていること
決定的チェック	形式、URL、版、禁止事項、権限、応答時間
検索指標	Recall@k、Precision@k、順位
LLM評価	意味的一致、関連性、説明品質の一次判定
人間評価	業務妥当性、重要判断、曖昧な境界事例
本番計測	利用完了、修正時間、移管率、事故、費用

LLM評価には、明示したルーブリック、根拠、比較順序の入れ替え、人間による抜取監査を組み合わせます。

評価AIの点数を、そのままGround Truthと呼んではいけません。

リリース前評価と本番評価をつなぐ

オフライン評価だけでは、実際の質問分布、利用者の誤解、Knowledgeの陳腐化を捉え切れません。

評価は次の循環にします。

固定回帰セットで比較
  ↓
危険ケースで限界確認
  ↓
限定利用・カナリア運用
  ↓
本番ログと人間修正を観測
  ↓
失敗を分類
  ↓
評価セットとKnowledgeへ追加
  ↓
再評価

固定回帰セットは、モデルや設定を変えたときの退行を検出します。

一方、固定問題だけへ最適化すると、未知の失敗を見落とします。

そこで、最近の本番失敗、Knowledge更新、境界事例を加える可変セットも持ちます。

比較時には、少なくとも次を記録します。

モデルと推論設定
システムプロンプト
検索・再ランキング設定
Knowledgeの版と索引作成日時
Toolと外部APIの版
評価データの版
評価者とルーブリック

モデルだけを固定しても、Knowledgeや検索索引が変われば結果は変わります。

具体例：製品設定を答えるQAチャット

「製品Aのクラウド版で監査ログを有効にする方法は？」という質問を考えます。

期待する根拠は、クラウド版Version 3.2の管理者ガイドです。

評価は次のように分けられます。

工程	評価
範囲判定	製品A・クラウド版を対象内と判断したか
検索	Version 3.2の該当箇所をTop-kへ取得したか
版判定	オンプレミス版や旧版を除外したか
根拠利用	手順中の各主張がガイドに支持されるか
完全性	必要権限、前提、注意事項を落としていないか
終了状態	根拠不足なら回答せず、追加質問または移管したか
業務効果	原文確認を含む解決時間が短くなったか

もし回答が誤っていても、Version 3.2を検索できなかったなら、モデル変更よりKnowledgeと検索の修正が先です。

正しい根拠を取得していたのに旧版の手順を混ぜたなら、生成と検証の問題です。

回答自体が正しくても、必要権限を書かなければ、業務上は不完全です。

この分解があって初めて、評価が改善へつながります。

このページの定義

このページでは、QAチャットの品質を次のように定義します。

QAチャットの品質とは、正しい文章を生成する能力だけではない。

回答可能性を判断し、必要な根拠を取得し、根拠に沿って説明し、答えられない場合は適切に停止または移管し、業務上の損失を許容範囲に抑える能力である。

したがって、評価設計では次を分けて測ります。

対象範囲・回答可能性
検索
根拠利用
回答の正確性と完全性
拒否・追加質問・人への移管
応答時間・費用・人間の修正量
業務完了と失敗時の損失

評価値には、標本数と不確実性を添えます。

単一の正答率ではなく、工程別指標と期待損失で判断します。

それが、QAチャットを「それらしく答えるデモ」から「改善可能な業務システム」へ変える評価設計です。

QAチャット評価設計思想

更新履歴