Tech カテゴリのイメージ

RAGの回答をどう評価する?正しさ・根拠との一致・答えられないときの振る舞い

検索で必要な資料が見つかっても、RAGの回答が正しいとは限らない。資料にない条件を付け足す、例外を読み落とす、古い規程を引用する。検索評価の次には、回答そのものを質問と資料に照らして確かめる必要がある。

例えば、架空の規程に「申請は原則3日前まで。ただし緊急時は当日連絡」とある。「緊急時はいつ連絡するか」という質問への回答が「3日前まで」なら、資料を取得できていても答えは誤りだ。「当日連絡できるが、上長の事前承認も必要」と答えた場合は、前半は合っていても後半の条件が根拠にない。これは評価方法を説明するための架空例であり、実際の制度やモデルの測定結果ではない。

「質問に答えたか」と「資料に支えられるか」を分ける

回答の関連性は、質問が求めた内容を答えているかを見る。回答の忠実性は、回答に含まれる各主張を、渡された資料から裏付けられるかを見る。正答性は、あらかじめ確認した正解や原資料と比べ、内容が正しいかを見る。これらは似ているが一致しない。質問に関連する文章でも、根拠のない数字が一つ混ざれば忠実ではない。資料の文を忠実に写しても、質問への答えになっていなければ関連性は低い。

RAGAsとARESの研究は、回答の忠実性や関連性を、検索された文脈の適切さと区別して評価する枠組みを示している。ただし、その評価名や自動スコアを、そのまま「事実として正しい確率」と読み替えてはいけない。渡した資料自体が古い、あるいは誤っていれば、資料に忠実な回答でも現行の事実とは食い違う。

一文ずつ根拠をたどる

回答全体へ一つの点数を付ける前に、検証可能な主張へ分ける。先の例なら「原則3日前」「緊急時は当日連絡」「上長の事前承認が必要」の三つだ。各主張について、参照した文書の該当箇所、版、更新日を示せるかを確認する。最後の主張に対応する箇所がなければ、回答全体が流暢でも根拠不足として記録する。

引用リンクがあるだけでは十分ではない。引用先を開いたとき、その文が実際に条件や例外を支えているかを見る。複数の資料が矛盾するなら、どの版が適用されるかを評価データ側で定義する。回答の引用をクリックできるかという表示の確認と、引用が主張を裏付けるかという内容の確認は別の作業だ。

答えがない質問も評価に入れる

資料に申請期限の記載がない質問へ、もっともらしい期限を作って答えるのは失敗だ。この場合の正解は、資料からは判断できないと伝えることになる。一方、資料に答えがあるのに毎回「分からない」と返すシステムも役に立たない。答えられる質問と、資料だけでは答えられない質問を分け、両方で振る舞いを確認する。

評価表には質問、必要な根拠、期待する要点、答えが存在するかを保存する。回答結果には、正しい要点が入ったか、根拠のない主張があるか、必要なときに回答を控えたかを別々に記録する。単一の合格率だけを見ると、答えを避け続けることで誤答を減らす設定を良く見せてしまう。

自動採点は人の判定で確かめる

大量の回答を毎回人だけで読むのは難しい。LLMを採点者にすれば候補を絞れるが、採点者も条件や否定、版の違いを読み落とす。ARESは自動判定の誤差を抑えるため、人がラベルを付けた少数の例を使う設計を採る。OpenAIの評価に関する資料も、LLM採点を使いながら領域の専門家が判定を監査し、実際のログを直接見る重要性を述べている。

まず、例外や更新履歴を含む小さな質問集合を人が採点する。そこに自動採点を重ね、一致しない例を見直す。改善前後を比べる際は、質問、資料の版、検索条件、採点基準を固定する。検索評価で「根拠を取れたか」を確認し、回答評価で「取れた根拠から正しく答えたか」を見る。この順序なら、失敗箇所を次の修正へ結び付けやすい。

参照資料

生成AI・機械学習講座の一覧へ