検索拡張生成 (RAG)
RAG · grounding
ひとことで
リトリーバー拡張生成は、質問に関連する文書集合から関連箇所を検索し、それをモデルのプロンプトに挿入して、モデルにそれらを使用して回答させます。モデルの重みは変更されず、知識は要求時にコンテキストとして提供されるため、文書を更新すれば即座に回答が変わります。
RAGは二つの側面から成ります。事前にドキュメントをチャンクに分割し、埋め込みに変換してインデックス化します。リクエスト時に質問を埋め込み、最も近いチャンクを取得します（通常はキーワード検索と組み合わせ） — そして、それらと指示をプロンプトに追加し、それらからだけ回答し、出典を引用するようにします。 それが企業向け導入で優位になる理由は、技術的なものではなく運用上の理由です：知識はドキュメントストアにあります。ドキュメントを変更すれば次の回答も変わります。リトレーニングや遅延が不要で、取得時に権限を enforcement（適用）できるため、ユーザーは許可されていない箇所を見ることはありません。 障害モードは一つの場所に集中しています。 RAGの多くは検索問題である。純粋なベクトル類似性は、請求書番号、製品コード、人名などの正確な識別子に対して弱いです。キーワード検索が得意な領域です。そのため、ハイブリッド検索（両方を実行し、ランキングを統合）が実務上のデフォルトとなっています。定義と例外を分割するチャンク境界、メタデータフィルタの欠如、取得件数が少なすぎることなどが残りの大部分を占めています。 取得と生成を分けて評価し、質問と正解となる箇所のペアを使います。最終的な回答だけを評価するチームは、どちらの半分を修正すべきかを判別できません。詳細な解説はRAGの仕組みを参照してください。
よくある質問
- RAGはファインチューニングよりも優れているのか？
- それぞれ異なる問題に取り組んでいます。RAGはモデルが知らない情報を提供します。微調整は、形式やトーン、あるいは特定のスキルを形成します。欠落している知識はRAGの問題です。
- RAGシステムがまだ間違った答えを出すのはなぜですか？
- ほぼ常に、取得した文章が間違っているからです。実際に取得された文章を確認してから、モデルを責めるのではなく — — その文章からは、慎重な人間でも答えられなかったなら、モデルは答えるチャンスがなかったのです。