この記事で分かること／分からないこと
- 分かること: RAGでキャッシュが「何を」対象にする手法かの整理
- 分かること: キャッシュが効きやすい条件と効きにくい条件の区別
- 分かること: 確定配信(実行時0 LLM)とキャッシュの設計思想の違い
- 分からないこと: 自社導入時のヒット率やコスト削減効果(実測値が無い)
- 分からないこと: 具体的なキャッシュ実装(TTLやキー設計)の推奨値
キャッシュが対象にするのは主に3か所
RAGで費用が発生するのは、主に検索(埋め込み計算とベクトル照合)と生成(LLM呼び出し)の2箇所である。キャッシュはこのどちらか、あるいは両方に対して、同じか類似した入力が再度来た際に計算をやり直さず前回の結果を返す仕組みである。対象は入力クエリの埋め込みベクトル、検索でヒットした文書の組み合わせ、生成された応答の3か所であり、どこに置くかで効く条件も無効化の設計も変わる。
本記事の時点で、自社実装にキャッシュ機構を導入した実測データは無い。以下は一般的な設計上の整理であり、自社のヒット率やコスト削減額を示すものではない。
効きやすい条件
キャッシュが効きやすいのは、同じ、あるいは表記ゆれの範囲に収まる質問が繰り返し来る場合である。想定質問の種類が有限で、対象データの更新頻度が低いほど、一度計算した結果を使い回せる期間が長くなる。質問の言い回しを正規化してキーにできる構成であるほど、同じ意図の異なる文字列がヒットとして扱われやすい。確定配信の「想定質問と根拠のペアを事前に作り込む」という考え方(確定配信という選択の記事を参照)は、この条件を極端に推し進め、事前計算の対象を全件に広げたものと捉えられる。
効きにくい条件
逆に、入力がほぼ毎回ユニークになる用途(自由記述の相談、個別の文脈を多く含む質問)ではヒット自体が発生しにくい。対象データの更新頻度が高い場合も、無効化・再計算のコストが節約できるコストを上回ることがある。応答に利用者ごとの文脈を含める(パーソナライズする)設計では、同じキャッシュを複数の利用者で共有できず効果は限定的になる。
確定配信とキャッシュは別の設計思想
キャッシュは「当たれば効く、当たらなければ通常の処理に戻る」確率的な仕組みである。これに対して確定配信は、想定質問をあらかじめ全て検証済みの索引に格納し、実行時は常に索引を引く前提で設計する(確定配信という選択の記事を参照)。両者は排他ではなく、確定配信の範囲を広げるほどキャッシュの出番は小さくなり、逆に想定外の質問を都度生成で処理する構成では、キャッシュがヒット率に応じて費用を下げる。どちらを選ぶかは、想定質問をどこまで事前に洗い出せるかに依存する。
よくある質問
Q1. RAGにおけるキャッシュは何を対象にするのか
入力クエリの埋め込みベクトル、検索でヒットした文書の組み合わせ、生成された応答の3か所が対象になり得る。どこに置くかで効く条件が変わる。
Q2. キャッシュが効きやすいのはどんな条件か
同じ、あるいは表記ゆれの範囲に収まる質問が繰り返し来る場合や、対象データの更新頻度が低い場合に効きやすい。
Q3. キャッシュが効きにくいのはどんな条件か
入力がほぼ毎回ユニークになる用途、更新頻度が高く無効化コストが大きい場合、応答をパーソナライズする設計では効きにくい。
Q4. 確定配信とキャッシュはどう違うのか
確定配信は想定質問を事前に全て索引へ格納し常に索引を引く設計、キャッシュは当たれば効く確率的な仕組みである。両者は排他ではなく組み合わせて考えるものである。
近い発想の手法として、埋め込みの再利用は埋め込みの再利用の記事、モデル切替はモデル切替の判断軸の記事、レイテンシ計測はレイテンシ計測の記事を参照してほしい。RAGの運用コスト設計について相談したい方は、お問い合わせから編集部までご連絡いただきたい。
- ハブ記事: RAGサービス比較15選
- 関連記事: RAGのレイテンシ計測
- 関連記事: 埋め込みを作り直さずに済ませる
- 関連記事: 用途ごとにモデルを切り替える判断