RAGの回答が間違うのはなぜ？精度を上げる前に見るポイント

もっともらしい答えの、どこが違ったのか

説明用の例として、社員が「展示会の備品を立て替えて購入してもいいですか」と聞く場面を考えます。AIは経費精算の案内を引用して「申請できます」と回答しました。しかし、購買規程の別紙には事前承認が必要と書かれています。文章は自然でも、この答えのまま買えば手続きで困ります。

このとき、単に「不正解」と記録するだけでは改善先が分かりません。購買規程が取り込まれていなかったのか、検索では見つかったのに回答に使われなかったのか、使ったのに承認条件を落としたのか。利用者が次に何をするかまで考えると、必要な情報の抜けを具体的に指摘できます。

評価用には、質問と実際の回答に加え、「事前承認の必要性を伝える」「確認先を案内する」のような必須要素を残します。模範文と一字一句同じである必要はありません。正しい行動へ進める回答になっているかを、業務を知る担当者と確かめます。

モデルを変える前に、検索と回答を切り分ける

RAGには、資料を探す工程と、その資料から答えを作る工程があります。Microsoftの評価資料も、取得した文書の評価、根拠への整合性、回答の関連性や情報の充足を区別しています。この区別を使えば、最終回答の点数だけでは見えない問題を追えます。

開発会社には、間違えた質問について「検索候補」「回答生成へ実際に渡した箇所」「出力した答え」を並べてもらいましょう。必要な原文が候補になければ、まず取り込みや検索を調べます。候補にあっても渡されていなければ、資料を選ぶ工程が問題です。資料が届いて初めて、生成の指示やモデルを比較する意味が出てきます。

元資料同士が矛盾している場合は、AIだけでは正式な答えを決められません。最新版や適用日を社内で確定する作業が先です。すべてをモデルの性能に結び付けないことが、不要な調整費用を増やさないためにも役立ちます。

参考：Microsoft Learn：Retrieval-Augmented Generation (RAG) evaluators

きれいな質問より、現場で出る聞き方を集める

評価の質問を資料の見出しから作ると、検索しやすい言葉ばかりになることがあります。現場では、略称を使い、前提を省き、違う制度名で尋ねる人もいます。問い合わせ履歴を利用できるなら必要な加工を行い、実際の言い回しを残した質問を集めます。

よくある質問に加えて、困り方の違う質問も必要です。「来月からのルールですか」「この案件だけ例外にできますか」のように、日付や個別判断が関わる場面を含めます。以下は質問を選ぶための比較です。単に難問を増やすのではなく、日常の仕事で起こる違いを押さえます。

表が収まらない場合は横にスクロールできます。

「正答率が高い」だけでは、導入を決められない

正答率を見るときは、何を質問し、何を正解としたかを一緒に読みます。資料の場所を聞く質問が中心の試験と、契約条件を説明する試験では難しさも影響も違います。数字が似ていても、自社の業務で同じように使えるとは限りません。

また、難しい質問をすべて保留にすれば、回答した分だけの正答率は高くなることがあります。答えた件数、保留した件数、処理が失敗した件数を分けると、人に戻る仕事量まで見えます。回答できた範囲での正確さと、全体のどこまで扱えたかの両方が必要です。

社外に誤った条件を案内する、権限外の資料が出る、といった重大な失敗は平均に埋めません。該当する用途は止める、下書きとしてのみ使うなど、結果に応じて利用範囲を決めます。有限の試験で問題が出なかったことは、今後も誤らない保証ではありません。

採点をAIへ任せる場合も、人が基準を作る

毎回すべてを人が読むのは負担になるため、評価の一部を自動化する方法があります。形式の確認はプログラムで行い、文章と根拠の対応には別のモデルによる採点を使うなど、役割を分けられます。LangSmithの公式資料でも、人・コード・LLMによる評価を扱い、LLMの採点結果を点検する必要性が説明されています。

まず業務担当者が判断した回答を基準にして、自動採点との食い違いを見ます。特に、丁寧だが肝心の条件がない回答や、もっともらしい引用を付けた誤答を高く評価していないかが大切です。採点用の指示やモデルを変えたら、評価する物差しも変わり得ます。

依頼先が評価ツールを持っているかだけで選ぶより、採点理由を説明できるかを見ましょう。点数と併せて、根拠箇所、欠けた条件、業務での影響を示してもらえると、社内でも導入判断を共有しやすくなります。

参考：LangChain：Evaluation concepts

改善を頼むなら、変更前後の答えを見せてもらう

検索方法、文書の分け方、プロンプトを一度に変えると、何が効いたか分かりにくくなります。まず原因に合う変更を試し、同じ質問で以前の回答と比較します。良くなった質問だけでなく、以前答えられた質問が悪化していないかも見ます。

調整に使った質問とは別に、最終確認用の質問を用意します。知られている問題だけに合わせた仕組みでは、初めての問い合わせへの対応力を判断できません。質問の役割、根拠文書の版、設定、回答と採点理由を残すと、納品後の変更にも同じ考え方を使えます。

評価にかかる費用を相談するときは、質問作成、業務側の採点、原因調査、再評価のどこまで含むかを決めます。「精度を上げる一式」よりも、直したい失敗と確認方法が明らかな方が投資を判断できます。導入後に新しく見つかった質問も、次の評価へ加えていきます。

検討・発注前のチェックリスト

担当者と確認状況を添えて、社内の検討メモや打ち合わせの議題にご活用ください。

確認日：________________ / 担当者：________________

• □現場の言い回しを残した質問を集めた。確認状況・メモ：
• □回答に欠かせない条件と正式な根拠を決めた。確認状況・メモ：
• □検索結果と、生成へ渡した資料を確認できる。確認状況・メモ：
• □保留や処理失敗を、回答した件数と分けて集計する。確認状況・メモ：
• □重大な誤りが出た用途の扱いを決めた。確認状況・メモ：
• □調整に使わない最終確認用の質問を用意した。確認状況・メモ：

よくある質問

参考資料

製品の仕様・提供条件は変更されることがあります。採用時には公式資料と契約内容をご確認ください。

• Retrieval-Augmented Generation (RAG) evaluatorsMicrosoft Learn
• Evaluation conceptsLangChain