検索拡張生成（Retrieval-Augmented Generation、通常はRAG）は、言語モデルが回答を作るその時点で、選択された情報を与える仕組みです。学習時に得たパターンだけに頼るのではなく、アプリケーションが文書集合を検索し、関連する抜粋をリクエストに加え、その根拠に基づいて回答するようモデルに求めます。
基本の流れは三つです。検索が候補となる抜粋を見つけ、拡張がそれらの抜粋を指示とユーザーの質問とともにまとめ、生成が与えられた資料に根ざした回答を作ります。このパターンは、知識が非公開である、頻繁に変わる、あるいは引用が必要な場合に有効です。
RAGはモデルを本質的に真実だけを話すものにはしません。検査し、改善できるコンポーネントの連鎖を作るのです。検索器は適切な文書を見落としたり、古い版を選んだり、キーワードは共通でも意味が異なる抜粋を返したりすることがあります。プロンプトが根拠付けを要求できない場合もあります。その結果、モデルは有効な抜粋を組み合わせて、裏付けのない結論を作ってしまうかもしれません。
文書の準備が結果の大部分を左右します。ファイルには安定した識別子、有用なメタデータ、アクセス規則、そして周辺の意味を十分に保てるチャンクが必要です。チャンクが大きすぎればコンテキストを浪費し関連性をぼかし、小さすぎれば主張がその定義、日付、例外、表の見出しから切り離されます。
検索にはキーワード検索、ベクトル類似度、意味的な順位付け、またはハイブリッド方式を使えます。キーワード検索は名前、コード、完全一致の句に強く、ベクトル検索は表現が異なっても概念的に関連する抜粋を見つけられます。両方の信号を組み合わせるハイブリッド検索は多くの場合でより良い初期設定ですが、実際の質問に対する評価は依然として必要です。
アクセス制御は、生成後の免責文ではなく検索の段階に組み込みます。ユーザーが閲覧を許可されていない抜粋を取得できてはなりません。取得した文書も信頼できない入力として扱う必要があります。文書の中に、アプリケーションの規則を上書きしようとする指示が含まれることがあるからです。システムのポリシーは分離し、下流のツールが実行できることを制限してください。
プロンプトでは各ソースチャンクを識別し、事実に関する主張には引用を求め、根拠が不十分なときのフォールバックを定めます。また、意見が食い違う場合の扱いも指示します。黙って一方を選ぶのではなく、日付と引用を添えて異なる記述を示すようにします。こうした要件があると、誤りを診断しやすくなります。
検索と生成は別々に測定します。検索テストでは、裏付けとなる抜粋が上位の結果に現れたかを問います。生成テストでは、回答が根拠に支えられているか、完全か、正しく引用されているか、不確実性を適切に示しているかを問います。整った回答は弱い検索を隠せますし、完璧な検索でも不適切な要約が後に続くことがあります。
コンテキストは多ければよいとは限りません。関連性の低い抜粋はトークンを消費し、回答を最も強い根拠から引き離すことがあります。関連性のしきい値を設け、重複を除き、鮮度が重要なら現在の版を優先し、回答用の領域を十分に残します。複雑な質問では、複数の焦点を絞った検索に分解する必要があるかもしれません。
RAGは、事実が変化する、または非公開のコーパスにあるときに適した手段です。現在の知識を注入するのではなく、振る舞い、文体、タスクの遂行能力を変えることが目的なら、通常はファインチューニングの方が適しています。より大きなワークフローの一部として、いつ、どこで検索するかをシステムが判断する必要がある場合には、エージェント用ツールが役立ちます。
信頼できるRAGの画面は、情報源を示し、コーパスが答えられないときはそれを認め、訂正を可能にするべきです。本当の製品は生成された段落ではありません。読者がその段落を信頼に値するか判断できる、根拠への経路です。
一次情報、製品ドキュメント、実際の利用シーンをもとに、あなたのワークフローに合うツールかどうかを判断しやすくする記事を作成しています。