

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Implémentation d'un cache sémantique avec ElastiCache for Valkey
<a name="semantic-caching-implementation"></a>

La procédure pas à pas suivante montre comment implémenter un cache sémantique à lecture intégrale à l'aide de for ElastiCache Valkey avec Amazon Bedrock.

## Étape 1 : créer un cluster ElastiCache for Valkey
<a name="semantic-caching-step1"></a>

Créez un cluster ElastiCache for Valkey avec la version 8.2 ou ultérieure en utilisant : AWS CLI

```
aws elasticache create-replication-group \
  --replication-group-id "valkey-semantic-cache" \
  --cache-node-type cache.r7g.large \
  --engine valkey \
  --engine-version 8.2 \
  --num-node-groups 1 \
  --replicas-per-node-group 1
```

## Étape 2 : Connexion au cluster et configuration des intégrations
<a name="semantic-caching-step2"></a>

À partir du code de votre application exécuté sur votre instance Amazon EC2, connectez-vous au ElastiCache cluster et configurez le modèle d'intégration :

```
from valkey.cluster import ValkeyCluster
from langchain_aws import BedrockEmbeddings

# Connect to ElastiCache for Valkey
valkey_client = ValkeyCluster(
    host="mycluster.xxxxxx.clustercfg.use1.cache.amazonaws.com",  # Your cluster endpoint
    port=6379,
    decode_responses=False
)

# Set up Amazon Bedrock Titan embeddings
embeddings = BedrockEmbeddings(
    model_id="amazon.titan-embed-text-v2:0",
    region_name="us-east-1"
)
```

Remplacez la valeur de l'hôte par le point de terminaison de configuration de votre ElastiCache cluster. Pour obtenir des instructions sur la manière de trouver le point de terminaison de votre cluster, consultez la section [Accès à votre ElastiCache cluster](accessing-elasticache.md).

## Étape 3 : Création de l'index vectoriel pour le cache sémantique
<a name="semantic-caching-step3"></a>

Configurez un ValkeyStore qui intègre automatiquement les requêtes à l'aide d'un index HNSW avec une distance COSINE pour la recherche vectorielle :

```
from langgraph_checkpoint_aws import ValkeyStore
from hashlib import md5

store = ValkeyStore(
    client=valkey_client,
    index={
        "collection_name": "semantic_cache",
        "embed": embeddings,
        "fields": ["query"],           # Fields to vectorize
        "index_type": "HNSW",          # Vector search algorithm
        "distance_metric": "COSINE",   # Similarity metric
        "dims": 1024                   # Titan V2 produces 1024-d vectors
    }
)
store.setup()

def cache_key_for_query(query: str):
    """Generate a deterministic cache key for a query."""
    return md5(query.encode("utf-8")).hexdigest()
```

**Note**  
ElastiCache for Valkey utilise un index pour fournir une recherche vectorielle rapide et précise. La `FT.CREATE` commande crée l'index sous-jacent. Pour plus d'informations, consultez la section [Recherche vectorielle pour ElastiCache](search.md).

## Étape 4 : Implémentation des fonctions de recherche et de mise à jour du cache
<a name="semantic-caching-step4"></a>

Créez des fonctions pour rechercher dans le cache des requêtes sémantiquement similaires et pour stocker de nouvelles paires requêtes-réponses :

```
def search_cache(user_message: str, k: int = 3, min_similarity: float = 0.8):
    """Look up a semantically similar cached response from ElastiCache."""
    hits = store.search(
        namespace="semantic-cache",
        query=user_message,
        limit=k
    )
    if not hits:
        return None

    # Sort by similarity score (highest first)
    hits = sorted(hits, key=lambda h: h["score"], reverse=True)
    top_hit = hits[0]
    score = top_hit["score"]

    if score < min_similarity:
        return None  # Below similarity threshold

    return top_hit["value"]["answer"]  # Return cached answer


def store_cache(user_message: str, result_message: str):
    """Store a new query-response pair in the semantic cache."""
    key = cache_key_for_query(user_message)
    store.put(
        namespace="semantic-cache",
        key=key,
        value={
            "query": user_message,
            "answer": result_message
        }
    )
```

## Étape 5 : Implémentation du modèle de cache à lecture directe
<a name="semantic-caching-step5"></a>

Intégrez le cache dans le traitement des demandes de votre application :

```
import time

def handle_query(user_message: str) -> dict:
    """Handle a user query with read-through semantic cache."""
    start = time.time()

    # Step 1: Search the semantic cache
    cached_response = search_cache(user_message, min_similarity=0.8)

    if cached_response:
        # Cache hit - return cached response
        elapsed = (time.time() - start) * 1000
        return {
            "response": cached_response,
            "source": "cache",
            "latency_ms": round(elapsed, 1),
        }

    # Step 2: Cache miss - invoke LLM
    llm_response = invoke_llm(user_message)  # Your LLM invocation function

    # Step 3: Store the response in cache for future reuse
    store_cache(user_message, llm_response)

    elapsed = (time.time() - start) * 1000
    return {
        "response": llm_response,
        "source": "llm",
        "latency_ms": round(elapsed, 1),
    }
```

## Commandes Valkey sous-jacentes
<a name="semantic-caching-valkey-commands"></a>

Le tableau suivant indique les commandes Valkey utilisées pour implémenter le cache sémantique :


| Opération | commande Valkey | Latence typique | 
| --- | --- | --- | 
| Création d’un index | FT.CREATE semantic\_cache SCHEMA query TEXT answer TEXT embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 1024 DISTANCE\_METRIC COSINE | One-time configuration | 
| Recherche dans le cache | FT.SEARCH semantic\_cache "\*=>[KNN 3 @embedding $query\_vec]" PARAMS 2 query\_vec [bytes] DIALECT 2 | Microsecondes | 
| Réponse du magasin | HSET cache:{hash} query "..." answer "..." embedding [bytes] | Microsecondes | 
| Réglez TTL | EXPIRE cache:{hash} 82800 | Microsecondes | 
| Inférence LLM (échec) | Appel d'API externe vers Amazon Bedrock | 500 à 6 000 ms | 