検索拡張生成（RAG）
検索拡張生成（RAG）は、まず文書群を検索し、取得した文章を素材として言語モデルに渡すことで質問に回答する方式です。モデルは記憶した内容ではなく取得した文章に基づいて答えるため、出典を示すことができ、文書が更新されれば回答も変わります。
RAGの処理はどう流れるのか
- 取り込み：文書を、単独で取得し読める大きさの文章単位に分割します。
- 索引付け：各文章をベクトルとして埋め込み保存します。多くの場合キーワード索引も併設します。
- 検索：質問を埋め込み、近い文章を返します。通常はキーワード検索も組み合わせます。
- 生成：取得した文章をモデルに渡し、それに基づいて答え、情報が不足する場合はそう述べるよう指示します。
- 出典提示：根拠とした文章を添えて回答を返し、読み手が検証できるようにします。
回答品質の上限を決めるのは検索の品質です。誤った3件の文章を渡されたモデルは、その誤った3件から流暢な回答を作ります。取得されなかった事実は、後段のプロンプト調整では取り戻せません。
RAGが失敗しやすい箇所
- 分割の失敗：表を見出しから切り離す、条項をその定義から切り離すなど。
- ベクトル検索のみの利用：型番や規程番号など、語の一致が重要な問い合わせで取りこぼします。
- 索引の陳腐化：文書は更新されたが索引は更新されず、古い内容を自信をもって答えます。
- 不足を認める経路の欠如：文書群が扱っていないと述べる代わりに、不十分な材料から回答します。
- アクセス制御を画面側だけに適用：索引が、画面で隠している内容を漏らします。
アクセス制御は検索の時点に置くべきです。利用者が閲覧を許されていない文章がモデルの文脈に入りうるなら、回答がそれを言い直すことができ、チャット画面の前段にある権限確認は迂回されています。
RAGとファインチューニングのどちらを選ぶか
| RAG | ファインチューニング | |
|---|---|---|
| 新しい事実の追加 | 可能。再索引後すぐ反映 | 再学習が必要で時間がかかる |
| 出典の提示 | 可能 | 不可 |
| 頻繁な更新への対応 | 適する | 適さない |
| 書式や文体の学習 | 弱い | 適する |
| 変更のコスト | 該当文書の再索引 | 学習ジョブの実行 |
両者は別の課題を解くもので、併用されることも多くあります。検索は変化する事実を供給し、ファインチューニングは書き方や従うべき規約を整えます。ナレッジベースは検索の課題であり、それを学習の課題として扱うことは、出典を示せない回答を得るための最も高価な方法です。
よくある質問
- 検索拡張生成とは何ですか。
- 検索拡張生成は、まず文書群を検索し、取得した文章を素材として言語モデルに渡して回答する方式です。モデルは学習時に記憶した内容ではなく取得した文章に基づくため、出典を示すことができ、文書の更新が回答に反映されます。
- RAGを使えばモデルの作り話は止まりますか。
- 回答の材料を与え、文書群が扱っていないと述べる経路を用意することで大きく減りますが、なくなるわけではありません。文章の読み違いや欠落の補完は起こりうるため、使用した文章を添えて回答を返すべきです。
- RAGとファインチューニングではどちらが優れていますか。
- 解く課題が異なります。RAGは変化する事実を供給し出典を示せます。ファインチューニングは書式、文体、規約を学習させます。毎週更新されるナレッジベースは検索の課題であり、それをファインチューニングで扱うのは、出典を示せない回答を得るための高価な手段です。
- RAGが誤った回答を返すのはなぜですか。
- ほとんどの場合、検索が誤った文章を返したためです。分割によって表が見出しから切り離された、ベクトル検索が型番などの語の一致を取りこぼした、索引が古いままだった、といった原因です。検索品質が回答品質の上限であり、後段の調整では取得されなかった事実を補えません。
- RAGでアクセス制御はどう機能しますか。
- 検索の時点で強制する必要があり、文章がモデルに届く前に、要求元利用者の権限で索引を絞り込みます。画面側だけに適用すると、利用者が開けない内容をモデルが言い直せてしまい、権限の境界が表示上の設定にすぎなくなります。
- RAGを完全にオンプレミスで運用できますか。
- 運用できます。埋め込みモデル、ベクトルストア、検索層、生成モデルのすべてをローカルのハードウェアで実行でき、オンプレミスやエアギャップ環境のナレッジ支援はこの構成を前提とします。この方式自体は外部サービスに依存しません。