セマンティックキャッシュ（セマンティックキャッシュ）
LLMへのクエリを意味的な類似度に基づいてキャッシュし、同義・類似の質問に対して過去の応答を再利用する技術。完全一致ではなくベクトル類似検索を用いることで、表現が異なる同意の問い合わせにもキャッシュヒットを実現し、推論コストと応答遅延を大幅に削減する。
セマンティックキャッシュとは
セマンティックキャッシュは、LLM（大規模言語モデル）への問い合わせを意味レベルで類似判定し、過去の応答を再利用するキャッシュ機構である。従来のキャッシュがクエリ文字列の完全一致に依存するのに対し、セマンティックキャッシュはテキスト埋め込み（embedding）によるベクトル類似検索を活用する。
例えば「Pythonでファイルを読む方法」と「Pythonのファイル読み込み手順」は文字列としては異なるが、意味的にはほぼ同一である。セマンティックキャッシュはこのような同義クエリを検出し、LLMへの再推論を回避してキャッシュ済みの応答を即座に返す。
仕組みと構成要素
セマンティックキャッシュの基本アーキテクチャは以下の構成要素で成り立つ。
| 構成要素 | 役割 | 代表的な選択肢 |
|---|---|---|
| Embedding Model | クエリをベクトル化 | OpenAI text-embedding-3-small, BGE-M3, Qwen3-Embedding |
| Vector Store | ベクトル類似検索 | Redis Stack, Qdrant, Pinecone, pgvector |
| 類似度閾値 | ヒット判定の精度制御 | コサイン類似度 0.90〜0.98 |
| TTL管理 | キャッシュの鮮度維持 | 時間ベースまたは利用頻度ベース |
| Response Store | 応答本体の格納 | Redis, DynamoDB, PostgreSQL |
処理フローは次の通りである。(1) ユーザークエリを embedding モデルでベクトル化、(2) ベクトルストアで類似検索を実行、(3) 類似度が閾値以上ならキャッシュヒットとして保存済み応答を返却、(4) 閾値未満ならLLMに推論を依頼し、結果をキャッシュに保存する。
類似度閾値の設計
セマンティックキャッシュの品質を左右する最重要パラメータが類似度閾値（similarity threshold）である。閾値が高すぎるとヒット率が低下し、低すぎると誤ヒット（意味が異なるクエリに古い応答を返す）が発生する。
| 閾値範囲 | ヒット率 | 誤ヒットリスク | 推奨用途 |
|---|---|---|---|
| 0.98以上 | 低い | ほぼゼロ | 正確性最優先（医療/法律） |
| 0.95〜0.97 | 中程度 | 非常に低い | 汎用チャットボット |
| 0.90〜0.94 | 高い | 低〜中 | FAQ/カスタマーサポート |
| 0.85〜0.89 | 非常に高い | 中程度 | コスト最優先の大量処理 |
実運用では A/B テストを行い、誤ヒット率とコスト削減のバランスが最適な閾値を決定することが推奨される。GPTCache の開発チームの報告では、OpenAI のembedding を使用した場合 0.95 前後が多くのユースケースで最適とされている。
主要ツールとフレームワーク
| ツール名 | 開発元 | 特徴 | ベクトルDB |
|---|---|---|---|
| GPTCache | Zilliz | 最も成熟したOSSライブラリ | Milvus, Faiss, pgvector等 |
| LangChain CacheBackedEmbeddings | LangChain | LangChain エコシステムに統合 | 任意 |
| Redis Semantic Cache | Redis | Redis Stack に統合、低遅延 | Redis自体 |
| LiteLLM Caching | BerriAI | LLMゲートウェイに組み込み | Redis, s3 |
| Momento | Momento | サーバーレスキャッシュサービス | マネージド |
GPTCache は最も広く使われているオープンソース実装で、embedding モデル・類似度評価・ベクトルストアの各レイヤーをプラグインとして差し替え可能な設計である。LiteLLM は LLM ゲートウェイとしてのキャッシュ機能を備え、セマンティックキャッシュをAPIプロキシレベルで透過的に適用できる。
コスト削減効果
セマンティックキャッシュの導入による効果は、アプリケーションのクエリパターンに大きく依存する。FAQ やカスタマーサポートのように類似質問が頻出する用途では高い効果が得られる。
- コスト削減: キャッシュヒット時はLLM APIコールが不要となり、GPT-4oクラスのモデルで1リクエストあたり$0.01〜$0.05のAPI費用を節約
- レイテンシ改善: LLM推論が500ms〜3sかかるのに対し、キャッシュヒット時は10〜50msで応答可能
- スループット向上: LLMのレート制限やトークン制限に影響されず、大量の同時リクエストに対応可能
GPTCacheの公開ベンチマークでは、FAQボットで最大68%のキャッシュヒット率を達成し、API費用を約60%削減した事例が報告されている。
課題と限界
セマンティックキャッシュには以下の技術的課題がある。
文脈依存性: 同じ質問でも会話の文脈によって最適な応答が異なる場合、キャッシュヒットが不適切な応答を返す可能性がある。マルチターン会話では直前のコンテキストをキャッシュキーに含める工夫が必要である。
鮮度管理: 時事的な質問（株価、天気、ニュース）に対してキャッシュが古い情報を返すリスクがある。TTL（Time-To-Live）の適切な設定と、特定カテゴリのクエリをキャッシュ対象から除外するロジックが必要である。
Embedding計算コスト: キャッシュ判定のために毎回 embedding を計算する必要があり、この計算自体にコストがかかる。ただし embedding モデルのコストはLLM推論の1/100〜1/1000程度であるため、ヒット率が数%以上あれば十分にペイする。
よくある質問
Q1: セマンティックキャッシュと通常のキャッシュの違いは何ですか？
通常のキャッシュはクエリ文字列の完全一致でヒット判定を行うため、1文字でも異なるとキャッシュミスとなる。セマンティックキャッシュはテキストのベクトル表現を比較するため、「LLMとは何ですか？」と「大規模言語モデルについて教えて」のように表現が異なる同義クエリにもヒットする。ヒット率が大幅に向上するが、embedding計算のオーバーヘッドと誤ヒットのリスクが生じる。
Q2: セマンティックキャッシュの導入に適したユースケースは？
類似質問が繰り返し発生するアプリケーションで最も効果が高い。具体的にはFAQボット、カスタマーサポートチャット、社内ナレッジ検索、教育用AIアシスタントなどが適している。一方、クリエイティブな文章生成や毎回異なる出力が期待される用途（小説執筆、ブレインストーミング等）には不向きである。
Q3: キャッシュのウォームアップは必要ですか？
初期状態ではキャッシュが空のため、運用初期はヒット率が低い（コールドスタート問題）。FAQ データや過去のログからよくある質問と回答のペアを事前にキャッシュに投入するウォームアップが効果的である。GPTCache では seed_data 機能でウォームアップ用のQ&Aペアを一括投入できる。