RAGの回答が間違うとき、検索と生成のどちらを直すべきか

社内RAGに質問すると、読みやすい回答が返ってくる。でも、元の資料を開くと内容が違う。開発チームから「回答の指示を調整します」と言われたものの、それで直るのか判断できない。

そんなとき、最初に見たいのが回答を作ったときに、AIへどの資料が渡っていたかです。必要な情報が届いていなければ、その手前を調べる。届いているのに答えが違えば、回答を作る工程を調べる。この順序で、次に直す場所を絞れます。

この記事では、同じ質問に対する3つの失敗例を使って、誤回答の調べ方を説明します。最後に、そのまま打ち合わせで使える記録表を載せています。

誤回答を1件選び、AIに渡った資料を開く

調査の出発点には、「この答えは違う」と業務担当者が判断できる質問を選びます。元の資料を見ても正解が決まらない質問は、原因を切り分ける最初の例には向きません。

開発チームに用意してもらうのは、次の3点です。

• 利用者が入力した質問。
• その質問を処理したときに、実際にAIへ渡した資料の本文。
• AIが返した回答。

業務担当者は、これに「本来参照すべき資料」と「回答に必要な要点」を添えます。例えば、手続きの説明なら、申請先だけでなく、申請するタイミングや例外条件も要点になります。

出典リンクが付いているだけでは、必要な箇所がAIに渡っていたかまでは分かりません。 ファイルの名前と、回答に使われた本文を分けて確認してください。

MicrosoftのRAG評価資料でも、検索した情報を評価する工程と、回答が根拠に沿っているか・必要な情報を含むかを評価する工程が分けられています。Microsoft Learn：RAG evaluators

同じ誤回答でも、直す場所は3通りある

ここからは、編集部が作った説明用の例です。実際の会社の規程や導入事例ではありません。

利用者が「業務用モニターを買う前に、申請は必要ですか」と質問したとします。最新版の備品購入ガイドには、次のように書かれています。

備品の購入は、原則として購入前に申請する。故障による緊急交換に限り、上長の承認を得たうえで購入後の申請を認める。

ところがRAGは、「購入後に申請すれば大丈夫です」と回答しました。この回答だけを見ても、原因はまだ決まりません。

最新版が検索されていないなら、取り込みと検索を調べる

検索結果を開くと、購入後の申請を認めていた旧版しか見つからない。AIにも、その旧版が渡っている。これなら、まず最新版にたどり着ける状態を作る必要があります。

最初に確かめるのは、最新版が検索対象に取り込まれているかです。未取り込みなら、反映の処理を調べます。取り込み済みなら、検索したときに候補へ入るか、旧版との区別に使う版や日付が記録されているかを追います。

この時点での修正案は、「回答を丁寧にする」よりも具体的です。「最新版の反映漏れを直し、同じ質問で最新版が取得されるか試す」と、作業と確認方法をセットにできます。

最新版は見つかるのに一部しか渡らないなら、資料の受け渡しを調べる

検索結果には最新版がある。それでも、AIに渡った本文を見ると、「購入後の申請を認める」という一節しか入っていない。

この場合、検索で見つかったことと、回答に必要な文脈が届いたことを分けて考えます。「故障による緊急交換に限り」という条件が、どこで抜けたかを追ってください。

文書を検索用に分割した段階で条件と結論が離れたのか。検索後に渡す範囲を選ぶ処理で、条件の部分を外したのか。確認する場所によって、直す処理も変わります。

Google Cloudの参照構成にも、検索したデータと質問を組み合わせ、それをLLMへ送る工程があります。検索結果と、LLMへの実際の入力を両方残すと、この間で起きた抜けを調べられます。Google Cloud：RAG reference architecture

必要な条件がすべて届いているなら、回答を作る工程を調べる

AIへの入力には、購入前の申請が原則であることも、緊急交換だけが例外であることも含まれている。それでも、購入後でよいと答えている。

ここまで確認できたら、回答時の指示や、一緒に渡した他の情報を調べる段階です。原則と例外を区別する指示があるか、旧版の説明も同時に渡していないかを見ます。

指示を変えるなら、この例では「購入前の申請が原則であることを伝える」「利用者が述べていない緊急交換の条件を、勝手に当てはめない」を確認項目にできます。同じ資料を渡したまま試し、どの変更で回答が変わったかを記録します。

一度正しく答えた段階では、修正の候補が見つかった状態です。他の質問への影響も確かめてから、採用を判断します。

資料に答えがないときは、確認先を案内できるかを見る

同じガイドに対して、「自宅用に買ったモニターも経費になりますか」と聞かれたらどうでしょう。ガイドにその条件の記載がなければ、この資料だけで可否は決められません。

この質問では、「資料からは判断できない」と伝え、会社が定めた確認先を案内する回答を期待結果にできます。確認先自体も分からないなら、窓口を創作させず、どこへ引き継ぐかを業務側で決めます。

評価用の質問には、答えが書いてあるものと、追加確認が必要なものの両方を入れておきます。正しく答える試験に加え、根拠が足りない場面で断定しない試験も必要です。

修正の前後を比べられる形で記録する

打ち合わせには、次のような表を1件分持っていくと、調べる場所を共有できます。下の記入例も、先ほどの架空のガイドを使ったものです。

実際の記録には、実行日、資料の版、使った設定も添えます。質問や本文に機密情報が含まれる場合は、共有できる範囲へ置き換えてください。

修正したら、この質問に加えて、以前は正しく答えられていた質問も再実行します。今回の例なら、通常購入、緊急交換、資料にない条件の3種類です。「例外を説明しなくなったため、通常購入だけは正しくなった」といった変化も見ます。

複数箇所を一度に変えると、何が効いたかを追いにくくなります。まずは一つの変更を試し、良くなった回答と、悪くなった回答を残す進め方を勧めます。

次の打ち合わせには、誤回答1件の記録を持っていく

業務担当者が用意するのは、質問、正しい資料、回答に含めてほしい要点。開発チームに出してもらうのは、検索結果、AIへの入力、実際の回答です。

これらを同じ質問で並べると、「最新版を取り込む」「条件が抜ける処理を直す」「回答時の指示を見直す」といった、次の作業を相談できます。最初の1件が、その後の誤回答を調べる見本になります。

社内RAGの評価や改善の進め方を相談したい場合は、Arcamへお問い合わせください。対象の業務と、共有可能な質問・誤回答の例があると、困っている箇所を具体的に伝えられます。