RAGの精度はどう評価する？社内文書検索AIのテスト項目と改善の切り分け

RAGの品質を一つの正答率で済ませない

RAGは、資料を検索し、その結果を使って回答を生成する構成です。正しい資料が見つからない場合と、見つかったのに説明を誤った場合では、直す箇所が異なります。回答だけを見て「精度が低い」と判断すると、不要なモデル変更やデータ追加につながります。

Microsoftの評価ガイドは、生成された回答を根拠との整合など複数の観点から評価する考え方を示しています。本記事ではそれを参考に、発注者が確認できる業務テストの形へ整理します。以下のテスト設計と記録表は当社の提案であり、特定製品の公式な合格基準ではありません。

導入全体の準備は社内文書検索AIの導入ガイドを参照してください。ここでは、試作品ができた後に「使ってよいか」を確かめる評価へ焦点を当てます。

実際の質問を、答え方の種類で分ける

質問を作る担当者は、正解文だけでなく、正解の根拠となる資料と箇所、適用条件を記録します。正解自体が曖昧な問題は先に業務部門で整理します。実際の質問履歴を使う場合は、利用範囲と個人情報の取り扱いを確認してください。

よくある質問だけに偏ると、まれでも重大な失敗を見落とします。日常利用の品質を測るセットと、権限漏れなどを調べる安全性のセットは分けて管理する案を推奨します。

同じ条件で比較できる記録を残す

評価では質問文、利用者の権限、検索された資料、生成回答、参照元、判定理由、所要時間を記録します。資料とモデル・設定の版も残し、後から再現できる範囲を確保します。機密内容を含む評価ログの保存範囲には注意が必要です。

文章の自然さと、業務上の正しさは別々に見ます。AIを採点補助に使う場合も、正解根拠のない採点を鵜呑みにせず、重要な失敗は担当者が確認します。評価者の判断が割れた問題も改善対象として残します。

原因ごとに、直す場所を変える

必要な情報が資料に存在しなければ、文書を整備する必要があります。存在するのに検索されなければ、文書の分割や検索条件を見直します。検索できているのに回答を誤るなら、入力する文脈や回答の指示、モデルの選択を検討します。

古い版が混じる場合は、モデルより先に有効期間や更新・削除の処理を確認します。権限を越える情報が出るなら、検索前の絞り込みから出力まで、どの経路で混入したかを調べます。回答末尾に注意書きを追加するだけで解決したとは考えません。

複数の条件を同時に変更すると、何が効いたか分かりにくくなります。変更点を記録し、同じ問題で比較します。ただし、その問題へ過度に合わせないよう、改善に使っていない評価問題も残しておきます。

評価例：「答えない方がよい質問」を用意する

架空の社内規程を使い、資料には国内出張の手続きしかない状態で、海外出張の申請条件を尋ねます。国内の条件を流用して答えるのではなく、必要な資料がないと分かるかを試します。正答の文字列だけでは、この動作は評価しにくいため、許容する回答条件を文章で定めます。

次に、同じ質問を権限の異なる二人の利用者で試します。閲覧できない資料の題名や引用文が回答に混ざらないかを確認します。検索画面で見えなくても、回答生成の文脈に入っていれば漏れる可能性があるため、最終出力まで確認します。

試験は一度の成功で終わらせず、重要な条件は繰り返して結果の揺れを記録します。新しいモデルが通常質問で改善しても、答えのない質問で断定が増えるなら、単純な平均点だけで採用しないようにします。

このような試験を正解例と一緒に残すと、文書追加や設定変更のたびに同じ観点を確かめられます。利用者から報告された失敗も、再発確認に使える評価問題へ変えていきます。

本番化の基準は業務リスクで決める

全社共通の「正答率何%以上なら安全」という値は、本記事では置きません。誤回答の影響や、回答を使う前に人が確認するかで基準が変わるためです。通常質問での使いやすさと、重大な情報漏れなどの停止条件を分けて合意します。

本番開始後も、文書更新や検索設定の変更時に再評価します。誤回答の報告窓口を用意し、どの版でどんな問題が起きたかを残します。答えられない場合に元資料へ誘導できることも、利用者が仕事を続けるための設計です。

開発会社への依頼では、回答画面だけでなく、評価データ、判定記録、既知の制限、再評価の手順を成果物に含めてください。RFPの作り方とPoCから本番化への確認事項につなげると、受け入れ条件を揃えられます。