Mémorisation sémantique avec Redis pour la recherche vectorielle

Le développement d’un produit basé sur l’IA surprend souvent les équipes moins par la qualité du modèle que par les coûts associés. Un chatbot qui semble peu coûteux avec quelques centaines d’utilisateurs peut soudainement engendrer des dépenses importantes chaque fois qu’une recherche, une recommandation ou une question déclenche une nouvelle requête d’incorporation.

Beaucoup de ces requêtes sont redondantes. Le cachage sémantique permet de réutiliser des résultats antérieurs lorsque une nouvelle requête signifie presque la même chose. Avec Redis, ce principe peut réduire les temps de réponse et les coûts d’infrastructure sans avoir à réécrire la logique métier de l’application.

Le coût caché de la recherche vectorielle

Un parcours typique de génération améliorée par la récupération de données (RAG) se présente comme suit :

User Query
     ↓
Embedding API
     ↓
Vector Database
     ↓
Retrieved Documents
     ↓
LLM

Chaque nouvelle requête implique généralement :

• une appel à un modèle d’incorporation
• des coûts liés aux délais de transmission réseau
• une recherche vectorielle
• la restitution des résultats correspondants

Les appels à l’incorporation coûtent de l’argent. Les allers-retours prennent du temps.

Considérons deux recherches effectuées à deux minutes d’intervalle :

• « meilleur ordinateur portable de jeu économique »
• « ordinateurs portables de jeu bon marché »

Les formulations diffèrent ; l’intention est à peine différente. Pourtant, de nombreux systèmes recalculent les deux résultats depuis zéro. Chez des milliers d’utilisateurs, la plateforme paie à plusieurs reprises pour presque le même travail.

Qu’est-ce que le cache sémantique ?

Les caches classiques se basent sur des chaînes de caractères exactes. Si l’on cache « chaussures rouges », seule la phrase identique sera trouvée ; « des chaussures qui sont rouges » ne sera pas retenue.

Le cache sémantique compare les sens. Chaque requête est transformée en un vecteur d’incorporation. Lorsque deux vecteurs sont suffisamment proches, la réponse stockée peut être réutilisée.

Par exemple :

Query A
"best beginner Python book"
↓
Embedding A

Plus tard :

Query B
"good Python books for beginners"

Si la similarité cosinus dépasse un seuil prédéfini — disons 0,95 — le système renvoie la réponse stockée. Aucune nouvelle génération de vecteur, aucune recherche vectorielle supplémentaire, aucun frais additionnel.

Création d’un cache à deux niveaux

Les conceptions de production emploient souvent deux caches superposés.

Niveau 1 : cache d’incorporation

C’est le niveau le plus rapide. Une chaîne de requête identique renvoie un embedding stocké au lieu d’appeler à nouveau le modèle.

Query
   ↓
Redis
   ↓
Embedding

Cela seul élimine l’une des appels payants les plus fréquents dans les applications d’IA.

Niveau 2 : cache des résultats sémantiques

Le deuxième niveau stocke les réponses finales des recherches. La correspondance s’effectue en fonction du voisinage des embeddings, et non du texte brut.

Embedding
      ↓
Redis Vector Search
      ↓
Cached Search Results

Un voisin proche signifie que la base de données vectorielle est ignorée et que l’utilisateur reçoit une réponse en cache presque instantanément.

Pourquoi Redis ?

Redis est un stockage en mémoire rapide. Grâce à Redis Stack et RediSearch, il peut également effectuer des recherches de similarité vectorielle.

Cette combinaison permet à Redis :

• de stocker des embeddings
• de comparer des vecteurs
• de renvoyer les voisins les plus proches

Expiration des entrées selon le TTL

Réponse en quelques millisecondes

Le cache cesse d’être un simple conteneur clé-valeur pour devenir une couche de recherche sémantique.

Sélection du seuil de similarité approprié

Le choix du seuil a un impact majeur sur la qualité. À 0,99, seuls les doublons quasi identiques sont reconnus — grande précision, moins de résultats. À 0,85, le taux de réponses augmente, mais des requêtes non liées peuvent se recouper (chaussures de course contre chaussures de basket).

La tolérance dépend du domaine. Le e-commerce peut souvent accepter des seuils plus souples ; la recherche médicale, en revanche, généralement pas. Certains systèmes fixent même des seuils différents pour chaque collection.

Maintien de la fraîcheur du cache

Les réponses en mémoire cache ne sont utiles que tant qu’elles restent exactes. Les « prix les plus récents de l’iPhone » peuvent devenir obsolètes en une nuit sans plan de mise à jour. Deux approches courantes couvrent la plupart des cas.

Expiration basée sur le temps

Affectez une durée de vie TTL afin que Redis supprime automatiquement les entrées — utile pour des catalogues qui changent fréquemment.

Invalidation basée sur des événements

Lorsque l’application détecte un changement — mise à jour des stocks, modification des prix, nouveaux documents, suppressions — elle supprime immédiatement les clés concernées au lieu d’attendre la fin de la durée TTL.

Comment Redis recherche les embeddings

Redis moderne stocke les embeddings sous forme de vecteurs flottants et les indexe à l’aide de structures telles que :

• FLAT
• HNSW

Une nouvelle requête ne parcourt pas tous les vecteurs de force ; les index localisent rapidement les voisins, ce qui permet aux recherches sémantiques de se terminer souvent en quelques millisecondes.

Assemblage de l’ensemble

Le parcours d’une requête du début à la fin ressemble à ceci :

User Query
      ↓
Embedding Cache
      ↓
Hit?
      ↓
Yes → Use Cached Embedding
No
 ↓
Embedding API
 ↓
Redis Semantic Cache
 ↓
Hit?
 ↓
Yes → Return Cached Results
No
 ↓
Vector Database
 ↓
Store Results in Redis
 ↓
Return Results

Le processus coûteux d’embedding suivi de recherche n’est exécuté que en cas d’échec. Tout le reste reste rapide.

Quel type d’amélioration pouvez-vous attendre ?

Les chiffres varient en fonction du produit, mais de nombreux rapports de production ressemblent à ceci :

• la recherche sémantique générale affiche souvent un taux de réussite d’environ un cinquième à un tiers
• l’autocomplétion et les requêtes répétées peuvent représenter environ la moitié du trafic
• les accès au cache répondent généralement en quelques millisecondes
• une recherche qui échoue lorsqu’elle utilise des embeddings et effectue une recherche bout en bout peut prendre quelques centaines de millisecondes

Chaque réussite élimine une appel à l’API d’embedding. Avec des milliers de requêtes, cela se traduit par des économies réelles en coûts et en latence.

Péchés capitaux courants

Toxification du cache

Une réponse incorrecte stockée dans le cache peut nuire à des requêtes similaires ultérieures. Un suivi rigoureux ainsi qu’une expiration adaptée réduisent l’impact négatif.

Croissance de la mémoire

Les embeddings sont volumineux : ils comprennent des centaines ou des milliers de nombres flottants chacun. Les collections augmentent rapidement. Définissez des plafonds de mémoire et des politiques d’éviction avant le lancement.

Démarrages en froid

Un déploiement nouveau commence vide, ce qui fait que le trafic initial paie le prix plein. Les requêtes fréquentes réchauffent progressivement le cache ; certaines équipes préchargent à l’avance les recherches courantes lors du déploiement pour raccourcir cette période d’adaptation.

Lorsque le cache sémantique n’est pas la bonne solution

Cette approche est efficace lorsque de nombreux utilisateurs posent des questions similaires. Elle perd en efficacité lorsque les réponses sont fortement personnelles ou extrêmement fraîches :

• « Restaurants à proximité »
• Recommandations personnalisées
• Tableaux de bord spécifiques à l’utilisateur
• Inventaire en temps réel
• Prix qui changent rapidement

Dans de tels cas, afficher une réponse sémantique stockée pour un utilisateur voisin peut être tout simplement inapproprié.

Conclusions finales

Au fur et à mesure que le trafic généré par l’IA augmente, les coûts d’infrastructure entrent souvent en concurrence avec la qualité des modèles pour attirer l’attention. Le cache sémantique constitue une solution pragmatique : il permet de reconnaître les intentions communes et d’éviter les calculs redondants d’incorporation et de recherche. Redis rend cela possible en combinant la vitesse en mémoire vive avec une recherche vectorielle native — des réponses plus rapides, moins d’appels payants pour l’incorporation, et une scalabilité optimisée. Parfois, la meilleure optimisation n’est pas un modèle amélioré, mais l’évitement de tâches qui n’avaient jamais besoin d’être exécutées.