Cache sémantique Redis
Mise en cache sémantique pour les réponses LLM avec le service LangCache de Redis Cloud. Stocke les prompts sous forme d'embeddings ; les prompts ultérieurs sémantiquement similaires retournent la réponse mise en cache sans rappeler le modèle.
LangCache est actuellement en aperçu sur Redis Cloud. Les fonctionnalités et le comportement peuvent changer.
Quand l'appliquer
- Envelopper un appel LLM (OpenAI, Anthropic, etc.) avec une couche de cache pour réduire le coût et la latence.
- Mettre en cache les réponses RAG, les résultats de classification ou toute charge de travail LLM déterministe.
- Régler le compromis précision/taux de hit pour un cache sémantique.
- Répartir les charges de travail LLM d'une application sur plusieurs instances de cache.
1. Le flux cache-aside
LangCache s'intègre devant tout appel LLM selon le pattern cache-aside standard :
- Envoyer le prompt de l'utilisateur à la fonction
searchde LangCache. - Cache hit — retourner la réponse stockée directement.
- Cache miss — appeler le LLM, puis
setla réponse afin que les prompts similaires futurs soient 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)
Les mêmes opérations sont disponibles via REST (POST /v1/caches/{cacheId}/entries/search et POST /v1/caches/{cacheId}/entries) quand un SDK n'est pas une option.
Voir references/langcache-usage.md pour les exemples SDK + REST complets et le stockage basé sur les attributs.
2. Régler le seuil de similarité
Le seuil contrôle à quel point (en distance cosinus de l'embedding) un nouveau prompt doit être proche d'un prompt mis en cache pour compter comme un hit. Plus élevé = correspondance plus stricte, moins de faux positifs. Plus bas = plus de hits, plus de risque de retourner une réponse hors sujet.
| Seuil | Comportement | À utiliser quand |
|---|---|---|
| 0,95+ | Correspondance quasi exacte requise | Réponses face aux clients où une mauvaise réponse coûte cher |
| 0,9 | Défaut équilibré | La plupart des charges de travail — commencez par là |
| 0,8 | Correspondance sémantique loose | Outils internes, requêtes exploratoires, déduplication de FAQ |
# Plus strict — moins de faux positifs
result = lang_cache.search(prompt="What is Redis?", similarity_threshold=0.95)
# Plus loose — taux de hit plus élevé
result = lang_cache.search(prompt="What is Redis?", similarity_threshold=0.8)
Ajustez en observant le taux réel de cache-hit et en vérifiant spot que les réponses retournées sont toujours pertinentes.
Voir references/best-practices.md.
3. Caches séparés par type de tâche
Les différentes charges de travail LLM ne doivent pas partager un seul cache — un prompt de « question de code » est sémantiquement proche d'autres questions de code mais n'a rien à voir avec une requête de support de réinitialisation de mot de passe, et les croiser retourne des ordures.
support_cache = LangCache(server_url=..., cache_id="support-cache-id", api_key=...)
code_cache = LangCache(server_url=..., cache_id="code-cache-id", api_key=...)
Créez des IDs de cache distincts dans Redis Cloud par tâche, et routez chaque appel vers le bon. Comme alternative plus granulaire, stockez et cherchez avec des attributs personnalisés (p. ex. {"category": "database"}) pour garder les tâches dans le même cache mais isolées par filtre d'attribut — utile quand le même format de prompt s'étend sur plusieurs sous-thèmes.