セマンティックキャッシング（セマンティックキャッシング）
LLMへの入力をエンベディングでベクトル化し、意味的に類似した過去のクエリの応答を再利用するアプリケーション層のキャッシュ戦略。
セマンティックキャッシングとは
セマンティックキャッシング（Semantic Caching）は、LLM アプリケーションにおいて、ユーザーの入力クエリをエンベディングモデルでベクトル化し、過去に処理した類似クエリの応答結果をキャッシュから返す最適化手法である。プレフィックスキャッシングがトークン列の厳密一致に基づく低レイヤーの最適化であるのに対し、セマンティックキャッシングは意味的な類似度に基づくアプリケーション層の最適化であり、表現が異なっても同じ意図のクエリに対してキャッシュヒットを実現できる。
例えば「Pythonでリストをソートする方法」と「Pythonの配列の並べ替え方」は表現が異なるが意味は同一であり、セマンティックキャッシングではこれらを同一クエリとして扱い、最初のクエリで得られた応答を2つ目のクエリにも返すことができる。
セマンティックキャッシングのアーキテクチャ
セマンティックキャッシングシステムは、以下のコンポーネントで構成される。
ユーザークエリ → エンベディングモデル → ベクトル検索（キャッシュストア）
├── ヒット（類似度 ≥ 閾値）→ キャッシュ応答を返却
└── ミス（類似度 < 閾値）→ LLM 推論 → 応答 + キャッシュ書込
主要コンポーネント
| コンポーネント | 役割 | 推奨技術 |
|---|---|---|
| エンベディングモデル | クエリのベクトル化 | text-embedding-3-small, BGE-M3, Qwen3-Embedding |
| ベクトルストア | 類似検索 | Redis VSS, Qdrant, Pinecone, Milvus |
| 類似度関数 | ヒット判定 | コサイン類似度（閾値 0.90-0.95） |
| キャッシュストア | 応答保存 | Redis, DynamoDB, PostgreSQL |
| TTL 管理 | 鮮度制御 | 用途に応じて1時間-30日 |
類似度閾値の設定
セマンティックキャッシングの品質は閾値設定に大きく依存する。閾値が高すぎるとキャッシュヒット率が低下し、低すぎると不適切な応答が返される。
| 閾値 | ヒット率 | 精度 | 適するユースケース |
|---|---|---|---|
| 0.98-1.00 | 低（5-15%） | 最高 | 医療・法律など正確性重視 |
| 0.95-0.98 | 中（15-30%） | 高 | 技術サポート・FAQ |
| 0.90-0.95 | 高（30-50%） | 中 | 一般チャット・レコメンド |
| 0.85-0.90 | 最高（50-70%） | 低 | ドラフト生成・要約 |
実運用では0.92-0.95の範囲が多く採用されており、A/Bテストで最適値を決定することが推奨される。
実装パターン
GPTCache によるセマンティックキャッシング
GPTCache はセマンティックキャッシングのオープンソース実装で、LangChain や LlamaIndex と統合して利用できる。
主な機能として、複数のエンベディングモデル対応（OpenAI / Hugging Face / Cohere）、複数のベクトルストア対応（FAISS / Milvus / Qdrant）、LRU / FIFO / LFU などのエビクションポリシー、類似度閾値のカスタマイズがある。
Redis Semantic Cache
Redis Stack の Vector Similarity Search（VSS）機能を活用したセマンティックキャッシングも広く利用されている。Redis のインメモリ特性により、ベクトル検索のレイテンシを1ミリ秒未満に抑えることができる。
LangChain のセマンティックキャッシュ統合
LangChain は CacheBackedEmbeddings と各種ベクトルストアを組み合わせたセマンティックキャッシュをネイティブサポートしている。既存のチェーンにキャッシュレイヤーを透過的に挿入できるため、コード変更を最小限に抑えて導入可能である。
プレフィックスキャッシングとの比較
セマンティックキャッシングとプレフィックスキャッシングは異なるレイヤーで動作し、相互補完的な関係にある。
| 観点 | プレフィックスキャッシング | セマンティックキャッシング |
|---|---|---|
| 動作レイヤー | LLMプロバイダ（推論エンジン） | アプリケーション層 |
| 一致判定 | トークン列の厳密プレフィックス一致 | ベクトル空間での意味的類似度 |
| キャッシュ対象 | KVキャッシュ（中間計算結果） | LLM応答テキスト |
| レイテンシ削減 | 50-85%（計算スキップ） | 95-99%（LLM呼出自体をスキップ） |
| コスト削減 | 50-90%（入力トークン割引） | 95-100%（LLM呼出なし） |
| 精度リスク | なし（同一計算結果） | あり（類似≠同一） |
| 導入難易度 | API パラメータ追加のみ | エンベディング+ベクトルDB構築 |
最も効果的なアプローチは両者の併用である。セマンティックキャッシュで完全ヒットすればLLM呼出自体を省略し、セマンティックキャッシュミスの場合でもプレフィックスキャッシングで計算コストを削減する多層防御的な構成となる。
セマンティックキャッシングの課題
- 鮮度管理: 情報が更新されてもキャッシュが古い応答を返すリスク
- パーソナライゼーション: ユーザーごとに異なる応答が期待される場合、共有キャッシュが不適切
- エンベディングコスト: キャッシュ判定のたびにエンベディング計算が必要
- ハルシネーション伝播: 誤った応答がキャッシュされると、類似クエリ全てに誤りが伝播
- コンテキスト依存性: 会話の文脈によって同一クエリでも適切な応答が異なる場合がある
よくある質問（FAQ）
Q1: セマンティックキャッシングの導入でLLMのコストはどの程度削減できますか？
A1: ユースケースとクエリの分布に強く依存しますが、FAQボットのように繰り返しクエリが多い場合は60-80%の削減が報告されています。一方、ユニークなクエリが多いクリエイティブ系アプリケーションでは10-20%程度にとどまります。閾値0.93、TTL 24時間の標準設定で、一般的なカスタマーサポートボットでは40-60%のコスト削減が期待できます。
Q2: セマンティックキャッシングで不正確な応答が返されるリスクをどう管理しますか？
A2: 主に3つのアプローチがあります。(1) 類似度閾値を高め（0.95以上）に設定して偽陽性を抑制、(2) キャッシュヒット時にユーザーに「以前の回答を参照しています」と明示してフィードバックを促す、(3) ドメイン固有のエンベディングモデルを使用して類似度判定の精度を向上させる。医療・法律など高リスクドメインでは閾値0.98以上とし、人間によるレビューフローを併設することを推奨します。
Q3: GPTCacheとRedis Semantic Cacheはどちらが適していますか？
A3: GPTCacheはPython環境で複数のバックエンド（FAISS/Milvus/Qdrant）を柔軟に切り替えられるため、プロトタイピングや小規模運用に適しています。Redis Semantic Cacheはインメモリのベクトル検索で極めて低レイテンシ（< 1ms）を実現でき、既にRedisを運用しているインフラではシームレスに導入できます。大規模本番環境ではRedisの方が運用実績が豊富です。