RAGが解決するのは一部だけ
検索拡張生成は、回答の前に関連する文書をモデルへ渡します。知識が変わりやすい場合や、すべてをプロンプトに入れたくない場合に役立ちます。しかし文書を真実に変える機能ではなく、別の権限領域を検索しない保証もありません。難しさは境界の設計に残ります。
先に決める四つの境界
- 何を索引に入れ、誰が見つけられるか。
- 一つの要求が使える時間と計算量。
- 証拠が弱いときにどう返すか。
- 文書を置き換えたり削除したりした後、古い断片を出さない方法。
安定した処理をエッジへ置く
Workerには、要求サイズの確認、言語の正規化、権限の絞り込み、キャッシュの読み取り、追跡IDの付与のような予測可能な処理が向いています。モデルを呼ぶ前に実行すれば、不要な処理を減らし、提供者が変わっても観測点を保てます。
意図的に小さい索引にする
最初からすべてを索引に入れる必要はありません。担当者とライフサイクルが明確な文書を選び、有効期間をメタデータとして持たせ、実際の質問で検索結果を確認します。管理されていない大きな集合より、更新される小さな集合の方が信頼できます。
- ワークスペースと権限範囲で文書を分ける。
- 各断片に出典、版、適用時点を残す。
- 類似度だけでなく権限の範囲も検査する。
- 文書の置換や削除に再索引の経路を用意する。
コストは製品の性質である
無料の構成では、不要な呼び出しが実ユーザーの余白を奪います。入力の長さ、取得する断片、再試行、待ち時間を早い段階から計測して制限します。上限を超えたら、黙って要求を増やすのではなく、質問を絞るように案内します。
安全な答えは「わからない」でもよい
取得した断片が十分に関連しなければ、確認の質問を返すか、対象の知識には答えがないと伝えます。回答には出典を付け、推測と引用を分け、モデルに内部リンクを作らせません。適切に断ることはUXの一部です。
信頼できるRAGはすべてに答えるのではなく、何を話せるかと、いつ止まるかを知っている。
まとめ
エッジ中心の構成は小さく始められます。Workerで認証と検証を行い、保存層で文書のライフサイクルを持たせ、制限内で検索し、証拠があるときだけモデルを呼びます。成長してもコスト、プライバシー、提供者の選択をチームが管理できます。