根拠付き回答とRAGの改善

検索結果を、そのまま回答だとは考えない

前の節のRetrieverは、質問に関連する文書の候補を返す窓口でした。その候補から利用者の質問に答えるのが、生成の段階です。この節では、そのつなぎ方と改善を扱います。

RAGでは、Retrieverが返したDocumentをモデルの入力へ組み込みます。その際、本文だけを無造作に並べるのではなく、どの文章がどの資料に属するかを分かるようにして渡します。資料の識別子を付けておくと、モデルが根拠を指し示す出力を作りやすくなり、後から対応を確認できます。

たとえば「出張規程の第3項では申請が必要とされ、別の補足には日帰り時の例外がある」とします。どちらも質問に必要なら、両方を渡す必要があります。モデルは検索範囲の外にある補足を、当然に知っているとは限りません。RAGの回答は、今回取得して渡した情報に左右されます。

回答方針は、根拠の範囲と不足時の扱いを決める

資料に基づく回答では、「参考資料の範囲で説明する」「根拠が無い項目は不明とする」「出典を示す」といった方針を入力に含めます。これにより、一般知識を使った自由な回答とは異なる仕事をモデルへ伝えます。ただし、指示しただけで必ず守られるとは限らないため、出力の確認も必要です。

出典を表示する場合、リンクの形式だけを検査しても不十分です。実在する資料へのリンクでも、回答の主張を支えていない場合があります。「申請は前日まで」と答えているなら、その期限を確認できる記述が、引用した資料の中にあるかを見る必要があります。

問題を、検索と生成に分けて調べる

回答が間違っているとき、最初に検索結果を確認します。必要な資料を取得できていないなら、モデルへの指示を変更するだけでは根本的に改善しない可能性があります。資料が読み取れているか、分割で条件を切り離していないか、古い版が残っていないか、検索条件が狭すぎないかを見ます。

必要な根拠を取得しているのに回答が誤る場合は、生成側を調べます。資料の渡し方が分かりにくい、無関係な候補が多い、適用条件が明示されていない、モデルが指示に従えていない、などが考えられます。この場合は入力構成や候補の整理、モデルの選択などが改善の対象になります。

検索と生成を一つの成功率だけで見ると、どちらが良くなったのか分かりません。少なくとも、必要な資料を取得できたか、回答が資料に支えられているか、利用者の質問に答えているかを分けて比較します。

第9節の架空の規程には、申請先と領収書の扱いがあり、期限は書かれていませんでした。その例に戻ると、次のように原因を分けられます。

代表的な改善方法と、その意味

質問の書き換えは、利用者の短い言い方を、検索しやすい問い合わせへ変換する方法です。第7節の大阪出張についての会話を踏まえて、「日帰りなら？」を「大阪への日帰り出張に適用される交通費の申請条件」のように補うと、検索対象が明確になることがあります。ただし、大阪出張という文脈が無いのに場所を足すなど、利用者が伝えていない条件を追加すると、別の質問を検索してしまいます。

検索語を複数作るクエリ拡張や、キーワード検索とベクトル検索を合わせる方法は、候補の取りこぼしを減らすために使えます。再ランキングは、取得した候補を、質問への関連性などで並べ直す段階です。いずれも処理が増えるので、時間や費用、誤った変換が入る可能性も考慮します。

一度に多くの変更を加えるより、同じ質問集合を使い、検索方法や分割方法などを一つずつ変える方が、改善の理由を判断しやすくなります。特定の一問にだけ合う調整と、全体の品質が上がる調整を区別することも大切です。

取得した文章は、参照データとして扱う

取得したWebページや文書に、「これまでの指示を無視しなさい」のような文章が含まれる可能性があります。それは資料の中身であり、アプリケーションの回答方針を書き換える権限を持つ命令ではありません。外部の文章に引きずられて振る舞いが変わる問題は、プロンプトインジェクションとして知られています。

資料と指示の区別に加え、取得前の権限確認、渡す範囲の制限、根拠の確認などを組み合わせます。RAGにすれば自動的に安全になるわけではありません。第6章では、こうした制御と評価を、LangChainの実行の中へどう組み込むかを説明します。

ここまでは、検索してから生成する順序を決めた構成でした。次の章では、検索などの機能を「ツール」としてモデルへ知らせ、必要に応じて利用させる方法へ進みます。RAGで学んだ検索の部品は、その場合にも利用できます。