RAG（検索拡張生成）は、質問に関連する外部資料を検索し、その内容を生成AIへ渡して回答を作る構成です。社内FAQや商品資料等の参照に使えます。ただし、資料が古い、必要箇所を検索できない、回答で読み違える場合もあり、導入だけで正確さが保証されるものではありません。
資料準備・検索・回答を一連で設計する
- 利用可能な資料を収集し、版・出所・閲覧条件を付けます。
- 検索に適した単位へ整理し、検索用の索引を作ります。
- 質問に応じて関連箇所を取得します。
- 質問と取得資料をAIへ渡し、回答案を作ります。
- 出所と回答を照合し、必要なら人へ引き継ぎます。
Google CloudのRAG解説でも検索と生成を組み合わせる構成が説明されています。検索方法には複数の選択肢があるため、特定のデータベースやフレームワークを使うこと自体を目的にせず、自社の質問と資料で評価します。
通常検索・長い入力・追加学習と比較する
| 方式 | 主な検討点 |
|---|---|
| 通常の検索 | 利用者が原文を読むだけで用事を終えられるか |
| 資料を直接入力 | 対象資料が限られ、入力範囲と費用に収まるか |
| RAG | 資料の量、更新、権限に対応した検索と引用が必要か |
| 追加学習 | 必要な出力傾向等を、学習と評価で調整すべきか |
RAGは、その場で取得した資料を入力へ加える方法で、モデルの重みを更新する追加学習とは異なります。更新情報への対応が必要でも、資料の取り込みが止まれば古い回答になります。方式は組み合わせる場合もあります。
資料の版と閲覧権限を先に決める
- 文書ごとに更新担当、版、公開範囲と有効期間を管理する。
- 削除・廃止した資料を検索対象から外せるようにする。
- 利用者が読めない文書を、検索結果や回答へ混ぜない。
- 資料内の命令を、システムの指示として実行しない。
- 資料に答えがない場合の案内先を用意する。
例えば商品保証への回答では、対象型番と購入条件が異なる規約を混ぜないようにします。文書名を示すだけでなく、回答の条件を支える箇所へたどれるかを確認してください。これは設計例で、導入成果の事例ではありません。
検索の失敗と生成の失敗を分ける
| 段階 | 評価すること |
|---|---|
| 検索 | 必要な資料・該当箇所が取れたか、権限を守ったか |
| 生成 | 取得内容に忠実か、条件や例外を落としていないか |
| 回答不可 | 不足・矛盾を示し、推測で埋めないか |
| 運用 | 待ち時間、費用、更新と障害時の対応 |
正解の根拠を用意した質問で試し、検索結果と最終回答を両方記録します。通常例に加えて、古い資料、表、略語、資料不足、権限外の質問も含めます。出所が表示されていても、その出所が結論を支えるかは別に確認してください。
関連するAPI連携の設計、導入支援の役割も参考になります。Web上の情報案内の課題はお問い合わせからご相談いただけます。
コメント