mcpField
R
redis-semantic-cache

redis-semantic-cache

github.com/redisデータ・データベース1711.9k 回インストール7 週間前に更新
リポジトリ

redis-semantic-cache について

redis-semantic-cache は、LLM アプリケーションにセマンティックキャッシュを導入する開発者向けのガイドです。Redis Cloud の LangCache が埋め込み表現でプロンプトを照合する仕組みと、ヒット率と一致精度の調整方法を説明します。

主な機能

  1. 01LangCache のセマンティックキャッシュ手順
  2. 02SDK と REST による操作
  3. 03類似度しきい値の調整
  4. 04タスク別のキャッシュ分割
  5. 05カスタム属性によるキャッシュ絞り込み

活用シーン

  1. 01LLM 呼び出しのキャッシュによる重複リクエスト削減
  2. 02RAG の回答や分類結果のキャッシュ
  3. 03誤一致リスクに応じたヒット率の調整
  4. 04異なるタスクのキャッシュ分離

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/redis/agent-skills --skill redis-semantic-cache

インストール後、Claude Code で/redis-semantic-cacheを入力して読み込まれたか確認します。

同梱ファイルreferences/best-practices.mdreferences/langcache-usage.md

詳細

Redis Semantic Cache

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 の重複排除
# 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)

実際のキャッシュヒット率を確認し、返された回答の関連性を抜き取りでチェックしながら調整してください。

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"})を指定して保存・検索することもできます。同じキャッシュ内でタスクを管理しながら、属性フィルターで分離できます。これは、同じプロンプト形式が複数のサブトピックにまたがる場合に便利です。

参考資料

コメント