• Projects
  • Service
  • About
  • branding.bz
  • Podcast
  • Tips
  • FAQ
  • Recruit
  • Download
  • Contact
  • branding.bz(ブランド構築SaaS)
  • DESIGN NOW(デザインメディア)
  • X
  • LinkedIn
  • Spotify
  • Facebook

213-0011 神奈川県川崎市高津区久本3-6-7-303

© 2026 ID INC. All rights reserved

claude-skills/スキル
SKILLOfficialdatabase

redis-semantic-cache

プラグイン
redis-development
ライセンス
MIT
ソース
GitHub で見る ↗
説明

Redis LangCache を使用して、Redis Cloud 上で LLM(大言語モデル)の応答をセマンティックキャッシング(意味的な内容で判定するキャッシング)するためのガイドです。SDK またはREST API 経由で検索・登録を実行し、類似度の閾値(判定基準)を調整し、タスクの種類ごとにキャッシュを分離し、カスタム属性でフィルタリングできます。 **次のような場合に使用:** - LLM の完成応答や RAG(検索拡張生成)の答えをキャッシュして、API コストと応答遅延を削減したい - OpenAI / Anthropic など複数の LLM サービスの前に、キャッシュ層を構築したい - キャッシュヒット率と精度のバランスを調整したい - 1つのアプリケーションの LLM 処理を複数の LangCache に分割して管理したい

原文を表示

Redis LangCache guidance for semantic caching of LLM responses on Redis Cloud — calling search/set via the SDK or REST API, tuning the similarity threshold, separating caches per task type, and filtering with custom attributes. Use when caching LLM completions or RAG answers to cut API cost and latency, building a cache-aside layer in front of OpenAI / Anthropic / etc., tuning hit rate vs precision, or splitting one app's LLM workloads into multiple LangCache caches.

ユースケース
  • LLMの応答をキャッシュしてAPI コスト削減したい
  • セマンティック検索でキャッシュヒット率を向上させたい
  • 複数のLLMサービス間にキャッシュ層を構築したい
  • タスクごとにキャッシュを分離して管理したい
本文(日本語訳)

Redis セマンティック キャッシュ

Redis Cloud の LangCache サービスを使用した、LLM(大規模言語モデル)の応答に対するセマンティック キャッシュ(意味的な内容の類似性を判定するキャッシュ)。プロンプト(指示文)を埋め込み(数値化した表現)として保存し、その後、意味的に類似したプロンプトが来た場合は、キャッシュされた応答を返して、モデルを再度呼び出さないようにします。

LangCache は現在、Redis Cloud でプレビュー段階です。機能と動作は変更される可能性があります。

いつ使用するか

  • LLM 呼び出し(OpenAI、Anthropic など)にキャッシュ層を被せ、コストと応答時間を削減したい
  • RAG(検索拡張生成)の回答、分類結果、その他の決定的な LLM 処理をキャッシュしたい
  • セマンティック キャッシュの精度とヒット率のバランスを調整したい
  • 1 つのアプリケーションの LLM 処理を複数のキャッシュ インスタンスに分散したい

1. キャッシュ・アサイド・フロー

LangCache は標準的なキャッシュ・アサイド・パターン(キャッシュを経由してデータを取得する方式)として、任意の LLM 呼び出しの前に配置されます:

  1. ユーザーのプロンプトを LangCache の search に送信する
  2. キャッシュ ヒット — 保存された応答を直接返す
  3. キャッシュ ミス — LLM を呼び出し、その後 set で応答を保存し、今後、類似したプロンプトがヒットするようにする
from langcache import LangCache
import os

lang_cache = LangCache(
    server_url=f"https://{os.getenv('HOST')}",
    cache_id=os.getenv("CACHE_ID"),
    api_key=os.getenv("API_KEY"),
)

result = lang_cache.search(prompt="What is Redis?", similarity_threshold=0.9)
if result:
    response = result[0]["response"]
else:
    response = llm.generate("What is Redis?")
    lang_cache.set(prompt="What is Redis?", response=response)

SDK が使えない場合は、REST(POST /v1/caches/{cacheId}/entries/search と POST /v1/caches/{cacheId}/entries)でも同じ操作が利用できます。

完全な SDK と REST のサンプル、属性ベースの保存については、references/langcache-usage.md を参照してください。

2. 類似度のしきい値を調整する

しきい値は、新しいプロンプトがキャッシュされたプロンプトにどのくらい近い(埋め込みの余弦距離)かを判定し、ヒットとするかどうかを制御します。高いほど厳密な照合になり、誤検出が減ります。低いほどヒット数が増えますが、的外れな回答が返される危険が高まります。

しきい値 動作 使用場面
0.95 以上 ほぼ完全一致が必須 顧客向けの回答で、誤った応答がコストになる場合
0.9 バランスの取れたデフォルト ほとんどのワークロード — ここから始める
0.8 緩い意味的照合 社内ツール、探索的なクエリ、FAQ の重複排除
# より厳密 — 誤検出が少ない
result = lang_cache.search(prompt="What is Redis?", similarity_threshold=0.95)

# より緩い — ヒット率が高い
result = lang_cache.search(prompt="What is Redis?", similarity_threshold=0.8)

実際のキャッシュ ヒット率を監視し、返された回答がまだ関連性があるかを抽出検査しながら調整してください。

references/best-practices.md を参照してください。

3. タスク種ごとにキャッシュを分ける

異なる LLM 処理は 1 つのキャッシュを共有してはいけません — 「コード質問」プロンプトは他のコード質問と意味的に近いかもしれませんが、「パスワード リセット」サポート質問とは無関係で、混ぜるとおかしな結果が返ります。

support_cache = LangCache(server_url=..., cache_id="support-cache-id", api_key=...)
code_cache    = LangCache(server_url=..., cache_id="code-cache-id",    api_key=...)

Redis Cloud でタスクごとに異なるキャッシュ ID を作成し、各呼び出しを適切なキャッシュにルーティングしてください。より細かく分ける方法として、カスタム属性(例えば {"category": "database"})と共に保存・検索すると、タスクを同じキャッシュ内に置きながら属性フィルタで分離できます — 同じプロンプト形式が複数の部分トピックにまたがる場合に便利です。

参考資料

  • LangCache ドキュメント
原文(English)を表示

Redis Semantic Cache

Semantic caching for LLM responses with Redis Cloud's LangCache service. Stores prompts as embeddings; subsequent semantically-similar prompts return the cached response without re-calling the model.

LangCache is currently in preview on Redis Cloud. Features and behavior may change.

When to apply

  • Wrapping an LLM call (OpenAI, Anthropic, etc.) with a cache layer to cut cost and latency.
  • Caching RAG answers, classification outputs, or any deterministic LLM workload.
  • Tuning the precision/hit-rate trade-off for a semantic cache.
  • Splitting one application's LLM workloads across multiple cache instances.

1. The cache-aside flow

LangCache fits in front of any LLM call as a standard cache-aside pattern:

  1. Send the user's prompt to LangCache's search.
  2. Cache hit — return the stored response directly.
  3. Cache miss — call the LLM, then set the response so future similar prompts hit.
from langcache import LangCache
import os

lang_cache = LangCache(
    server_url=f"https://{os.getenv('HOST')}",
    cache_id=os.getenv("CACHE_ID"),
    api_key=os.getenv("API_KEY"),
)

result = lang_cache.search(prompt="What is Redis?", similarity_threshold=0.9)
if result:
    response = result[0]["response"]
else:
    response = llm.generate("What is Redis?")
    lang_cache.set(prompt="What is Redis?", response=response)

The same operations are available via REST (POST /v1/caches/{cacheId}/entries/search and POST /v1/caches/{cacheId}/entries) when an SDK isn't an option.

See references/langcache-usage.md for full SDK + REST samples and attribute-based storage.

2. Tune the similarity threshold

The threshold controls how close (in embedding cosine distance) a new prompt must be to a cached one to count as a hit. Higher = stricter match, fewer false positives. Lower = more hits, more risk of returning an off-topic answer.

Threshold Behavior Use when
0.95+ Near-exact match required Customer-facing answers where wrong responses are costly
0.9 Balanced default Most workloads — start here
0.8 Loose semantic match Internal tools, exploratory queries, FAQ deduplication
# Stricter — fewer false positives
result = lang_cache.search(prompt="What is Redis?", similarity_threshold=0.95)

# Looser — higher hit rate
result = lang_cache.search(prompt="What is Redis?", similarity_threshold=0.8)

Adjust by watching the actual cache-hit rate and spot-checking that returned answers are still relevant.

See references/best-practices.md.

3. Separate caches per task type

Different LLM workloads should not share one cache — a "code question" prompt is semantically close to other code questions but has nothing to do with a password-reset support query, and crossing them returns garbage.

support_cache = LangCache(server_url=..., cache_id="support-cache-id", api_key=...)
code_cache    = LangCache(server_url=..., cache_id="code-cache-id",    api_key=...)

Create distinct cache IDs in Redis Cloud per task, and route each call to the right one. As a finer-grained alternative, store and search with custom attributes (e.g. {"category": "database"}) to keep tasks in the same cache but isolated by attribute filter — useful when the same prompt format spans subtopics.

References

  • LangCache documentation

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。