検索の取りこぼしか、生成の失敗か――根拠付き回答を切り分ける

検索拡張生成（RAG）の誤答を調べるとき、最初に問うべきなのは「モデルがなぜ間違えたか」ではない。必要な根拠がそもそも検索・取得されなかったのか、それとも根拠はモデルに渡されたのに回答へ正しく反映されなかったのか、である。この二つは見た目の似た誤答を生むが、修正すべき箇所は異なる。前者なら検索やチャンク分割を、後者ならプロンプトに組み立てた文脈や生成処理を調べる必要がある。

検索結果だけでなく、実際にモデルへ渡した抜粋を確認することが、この切り分けの要点だ。検索システムが関連文書を返していても、後段のフィルタリングやトークン上限によって必要な箇所が入力から落ちていることがある。逆に、根拠が入力に含まれていても、モデルが無視したり、内容を誤読したり、根拠のない主張を付け加えたりすることがある。正答率だけを見ていると、こうした別々の失敗が一つの数値に隠れてしまう。

検索結果とモデル入力を分けて追跡する

「取得された」と「回答に使われた」は別の状態

RAGの流れは、概ね「質問の処理」「検索」「検索結果の選別」「文脈の組み立て」「モデルによる回答生成」に分けられる。失敗を診断するには、各段階の出力を区別して記録する。特に、検索システムが返した文書と、プロンプトに最終的に含めた文書・抜粋を、同じものとして扱ってはならない。

たとえば、正解に必要な情報が元文書には存在していても、検索クエリとの表現のずれやチャンク境界のために検索候補に上がらないことがある。候補には入っていても、順位付けや重複排除で落ちる場合もある。候補から選ばれていても、文脈長の上限に合わせて切り詰めた結果、答えを支える一文が消える可能性がある。これらはすべて、モデルが受け取った時点で根拠が不足している「検索・文脈構成側」の失敗として検討すべきだ。

一方、必要な根拠が実際のモデル入力に含まれているのに、回答がそれと矛盾する、根拠のない説明を加える、または必要な条件を落とすなら、主な調査対象は生成側となる。ここで「検索に成功した」という判定を、単に関連文書が検索結果に含まれていたことだけで下すと、後段で根拠が失われたケースを見逃してしまう。

まず保存すべきログ

原因を後から再現できるよう、少なくとも次の情報をひとまとまりで保存する。

• 元の質問と、検索に実際に使ったクエリ
• 取得候補の文書識別子、順位、スコア
• チャンクの本文、出典、境界情報
• 選別・切り詰め後にモデルへ渡した文脈
• 文脈の並び順と、各抜粋の位置
• モデルの回答と、使用した構成・設定

この記録により、「該当文書は取得候補にあったか」「必要な一節はプロンプトに残っていたか」「モデルの回答はその一節から支持できるか」を順番に確認できる。検索ログだけでは、モデル入力に何が入ったのかは確定しない。反対に、回答だけを保存しても、根拠の欠落と根拠の誤用を区別できない。

取得の網羅性と回答の忠実性を別々に評価する

検索側は「必要な根拠が入ったか」を測る

検索側の評価では、質問に答えるために必要な根拠をあらかじめ定義し、取得・投入された文脈がそれを含むかを確認する。正解文書そのものの取得だけでなく、回答に必要な事実や条件が含まれているかを調べるのが重要だ。正解に関係する文書が返っていても、該当する記述がチャンクから欠けていれば、回答に使える根拠を取得したとは言いにくい。

RAGASは、取得文脈に必要な情報が含まれるかをみるContext Recallと、回答の主張が取得文脈に支えられているかをみるFaithfulnessを、別々の観点として扱う枠組みを示している。[1] この分離によって、「根拠が入力に届かなかった」失敗と「届いた根拠を回答が正しく使わなかった」失敗を、単一の正答率よりも明瞭に区別できる。

生成側は「回答の主張が文脈で支持されるか」を測る

回答の忠実性を評価するときは、回答全体の印象ではなく、個々の検証可能な主張を取り出して、実際に渡した文脈がそれを支持するかを確認する。回答に含まれる数字、条件、因果関係、適用範囲などを分けて見ると、どの部分が根拠と一致し、どの部分が逸脱したかを記録しやすい。必要な根拠が投入文脈にあるのに、回答が反対の内容を述べた場合は、検索順位を調整する前に、文脈の配置や生成段階の処理を調査する理由がある。

ARESも、文脈関連性、回答忠実性、回答関連性を分けて評価する方法を提示している。合成データを使った判定器の調整に加えて、人手ラベルをPrediction-Powered Inferenceに用いる構成が含まれる。[2] 実務では自動評価だけで診断を確定せず、境界事例や誤判定が業務上重要なケースを人が確認する設計が望ましい。評価値は失敗候補を絞る手掛かりであり、ログに残された具体的な入力と回答が原因確認の基礎になる。

チャンクと文脈長は取得の成否を左右する

分割方式は、どの情報が一つの検索単位にまとまるかを決める。固定トークン数、文単位、意味ベースなど、方式ごとに情報のまとまり方が異なるため、「チャンクが検索されたか」だけでは十分な診断にならない。必要な条件と結論が別チャンクに分かれた場合、片方だけが取得されることで、回答に必要な関係が失われることがある。

2026年のNatural Questionsを用いた分析では、複数の分割方式、チャンク長、重なり、文脈長が比較された。同研究の報告では、10～20％の重なりを加えても、BERTScoreの差は最大0.004、Exact Matchの差は最大0.001で、測定可能な改善は見られなかった。また、文単位分割は約5,000トークンまで意味ベース分割に近い性能を示し、文脈が約2,500トークンを超えると品質が落ちる「context cliff」も報告されている。[3] これらは特定のデータと評価条件での観察であり、あらゆるコーパスに適用できる固定の最適値ではない。分割設定は、自分たちの質問分布と評価指標で検証する必要がある。

失敗原因に応じて検査する場所を変える

根拠が入力にない場合

必要な根拠がプロンプトに見当たらないなら、モデルを変更する前に検索経路を調べる。検索クエリが元文書の用語とずれていないか、分割によって識別子や条件が文脈から切り離されていないか、候補選別やトークン制限で該当箇所が除かれていないかを確認する。対処後は、質問ごとに根拠の取得状況を再評価する。生成側の設定を変えても、モデルに存在しない証拠を回答へ正確に反映させることはできない。

根拠が入力にあるのに回答が逸脱する場合

根拠が入力にある場合は、文脈の並び順、重複、長さ、指示の競合、回答の生成過程を調べる。関連情報を長い入力の中央に置くと利用されにくくなる傾向は、「Lost in the Middle」の実験で示されている。同研究では関連情報の位置を変えた際に性能が変化し、長い入力の中央にある情報は先頭や末尾にある情報より利用されにくい場合があった。[4] そのため、検索上位の断片を機械的に連結するだけでなく、必要な根拠が入力のどこに置かれたかも記録し、回答と照合する価値がある。

診断の順序は、次のように整理できる。

なお、これらの区分は実務上の調査順を整えるもので、失敗原因が常に一つとは限らない。取得した根拠が一部不足し、さらにモデルが入力内の条件も誤読するような複合例では、検索と生成の双方に問題がある。各段階の証跡を残せば、単一の原因に無理に帰属させず、複数の寄与を分けて検討できる。

複数モデルの比較では、入力条件を固定する

モデル間の比較を、検索品質の評価と混同してはならない。同じ質問でも、各実行で検索結果や投入文脈が違えば、回答の差がモデルによるものか、根拠の差によるものか判別できない。まず一組の検索結果と最終投入文脈を固定し、その条件でモデルの回答を比較する。別の実験として検索側を変える場合は、モデルと生成条件を固定する。こうすれば、取得処理と回答生成の寄与を別々に観察しやすい。

たとえばAI Plazaは、GPT-6.1 Sol、Claude-Haiku-5.5、Gemini-3.8-Flash、Grok-4.7などのモデルを利用できるマルチモデル環境の一例であり、固定した検索抜粋を各モデルに渡して生成段階の違いを比較するワークフローに使える。モデルのカタログは継続的に更新されるため、比較時には使用モデルと実行条件を記録する必要がある。[5] ここでの目的はモデルの順位付けではなく、同じ根拠に対して回答がどう変わるかを見て、生成側の失敗を検索側の失敗から切り離すことだ。

長期的には「回答」より「根拠の経路」が運用対象になる

RAGの品質管理では、最終回答の正誤だけを測る運用から、根拠がどこで取得され、どのように選ばれ、どう回答へ反映されたかを追跡する運用へ移る必要がある。検索、文脈構成、生成を別々に評価すれば、改善後にどの段階の指標が動いたかも比較できる。たとえば、検索設定の変更後に根拠の取得率が上がっても忠実性が変わらないなら、次に見るべきなのは回答への反映や文脈配置である。

この考え方は、チャンク方式やモデルを一度選んで終わりにしないためにも重要だ。文書群、質問の形式、回答に必要な精度が変われば、検索に必要な単位や適切な文脈量も変わり得る。評価用の質問と必要な根拠を継続的に点検し、ログに残る実際の入力と回答を照合することで、どの失敗が増えたかを特定しやすくなる。根拠付き回答の信頼性は、モデル単体の性質だけでなく、証拠を見つけてモデルに届け、回答がそれに従ったかを確認する一連の仕組みによって支えられる。

参考資料

https://arxiv.org/html/2309.15217v1

https://arxiv.org/abs/2311.09476v1

https://arxiv.org/html/2601.14123v1

https://cs.stanford.edu/~nfliu/papers/lost-in-the-middle.arxiv2023.pdf

https://aiplaza.app

References

[1] https://cs.stanford.edu/~nfliu/papers/lost-in-the-middle.arxiv2023.pdf [2] https://arxiv.org/html/2309.15217v1 [3] https://arxiv.org/abs/2311.09476v1 [4] https://arxiv.org/html/2601.14123v1 [5] https://aiplaza.app