Cache sémantique dans n8n : réduire coûts et latence IA avec Redis

Un chatbot support qui répond à 500 questions par jour repose souvent sur une réalité simple : la majorité de ces questions se ressemblent. « Comment réinitialiser mon mot de passe ? », « J'ai oublié mon mot de passe, que faire ? » et « Mot de passe perdu, comment je fais ? » sont trois formulations différentes de la même intention — et pourtant, sans rien de particulier en place, ce sont trois appels payants à un LLM, avec trois fois la latence. Le cache sémantique règle exactement ce problème : au lieu de comparer les questions mot à mot, il compare leur sens, via des embeddings, et renvoie une réponse déjà générée dès qu'une question suffisamment proche a déjà été posée.

Cache classique vs cache sémantique

Un cache classique (clé-valeur) ne fonctionne que sur une correspondance exacte : la même chaîne de caractères produit le même résultat. C'est parfait pour une réponse d'API déterministe, mais inutile face au langage naturel — deux utilisateurs ne posent presque jamais une question mot pour mot identique.

Le cache sémantique change de logique :

1. La question entrante est transformée en embedding (un vecteur qui capture son sens) via un modèle comme text-embedding-3-small d'OpenAI.
2. Ce vecteur est comparé par similarité cosinus aux vecteurs déjà en cache.
3. Si le meilleur score dépasse un seuil (souvent 0,95+), la réponse associée est renvoyée directement — zéro appel au LLM.
4. Sinon, le LLM est appelé normalement, et la nouvelle paire question/réponse est ajoutée au cache pour la prochaine fois.

Une étude de Regmi et Phakami Pun publiée en 2024, GPT Semantic Cache: Reducing LLM Costs and Latency via Semantic Embedding Caching, formalise précisément cette architecture avec Redis comme magasin d'embeddings en mémoire, et rapporte une réduction sensible des appels API redondants sur des charges de requêtes réelles. Sur le même terrain, l'article fondateur GPTCache: An Open-Source Semantic Cache for LLM Applications (Bang, 2023) mesure des taux de succès de cache dépassant 60 % sur des jeux de questions variés, avec des réponses restituées plusieurs fois plus vite qu'un nouvel appel au modèle. Les deux travaux convergent sur le même constat : une part importante du trafic vers un LLM en production est redondante en intention, même quand elle ne l'est pas mot pour mot.

Pourquoi Redis plutôt que Supabase/pgvector ici

Le guide RAG avec Supabase et pgvector de ce blog utilise Postgres pour stocker des milliers de fragments de documents, interrogés occasionnellement. Le cache sémantique a un profil d'usage différent : des lectures très fréquentes, une faible latence exigée (on veut gagner du temps, pas en reperdre dans la recherche), et des données qui peuvent expirer. Redis, en mémoire, avec son module de recherche vectorielle (RediSearch, inclus dans Redis Stack), est taillé pour ce profil : latence de l'ordre de la milliseconde, et surtout un TTL natif par clé — la donnée s'auto-expire sans job de nettoyage à écrire. Si votre infrastructure n8n tourne déjà en mode queue avec Redis, l'instance existe déjà : il suffit d'y ajouter cet usage, sans nouveau service à opérer.

Construire le workflow dans n8n

Le pipeline s'insère entre la réception de la question (webhook de chat, message Slack, requête API) et l'appel au LLM :

1. Webhook / Trigger — réception de la question utilisateur.
2. Node Embeddings (OpenAI ou le node natif n8n) — transforme la question en vecteur.
3. Node Redis (ou HTTP Request vers l'API Redis) — exécute une commande FT.SEARCH sur l'index vectoriel, récupère le meilleur candidat et son score de similarité.
4. Node If — teste le score contre le seuil choisi :
   • Au-dessus du seuil → branche « cache hit » : la réponse stockée est renvoyée directement, sans appel au modèle.
   • En dessous → branche « cache miss » : le node IA (Agent, chaîne LLM, ou appel direct à Claude/GPT comme décrit dans notre guide pour connecter Claude ou GPT à n8n) génère la réponse normalement.
5. Node Redis (écriture) sur la branche miss uniquement — stocke le nouveau couple (embedding, réponse) avec un TTL adapté à la volatilité du contenu (quelques heures pour du support produit, quelques minutes pour des données qui changent vite).

Concrètement, la commande de recherche ressemble à :

FT.SEARCH idx:cache_qa "*=>[KNN 1 @embedding $vec AS score]"
  PARAMS 2 vec <embedding_binaire>
  SORTBY score
  DIALECT 2

et l'écriture d'une nouvelle entrée à :

HSET cache:qa:<uuid> question "..." reponse "..." embedding <bytes>
EXPIRE cache:qa:<uuid> 21600

Le score renvoyé par FT.SEARCH est une distance (plus petit = plus proche) plutôt qu'une similarité directe selon la métrique choisie à l'indexation ; vérifiez dans la configuration de votre index si vous utilisez COSINE, L2 ou IP, et adaptez le sens de la comparaison dans le node If en conséquence.

Dimensionner le seuil de similarité

C'est le réglage qui détermine si le cache fait gagner de l'argent ou casse la qualité des réponses :

• Trop permissif (seuil bas, ex. 0,85) : des questions différentes mais proches en surface reçoivent la même réponse — dangereux dès que la nuance compte (tarifs, éligibilité, procédure de sécurité).
• Trop strict (seuil très haut, ex. 0,99) : quasiment aucune reformulation ne matche, le cache reste vide et n'apporte rien.

Un point de départ raisonnable est 0,95-0,97 pour un usage support ou documentaire, à valider sur un échantillon réel de questions passées avant mise en production — exactement la même logique de test que celle recommandée dans notre article sur les évaluations n8n pour workflows IA. Pour des cas à fort enjeu (conseil juridique, médical, financier), désactivez purement et simplement le cache sur ces intentions plutôt que de risquer une réponse mal appariée.

Ce que ça change concrètement

• Coût : chaque cache hit évite entièrement l'appel au LLM — sur un chatbot à fort volume de questions récurrentes (FAQ produit, support de premier niveau), la part de trafic évitable dépasse souvent 40-60 % une fois le cache chauffé, dans la même fourchette que celle mesurée par les études citées plus haut.
• Latence : une lecture Redis en mémoire répond en quelques millisecondes, contre plusieurs centaines de millisecondes à quelques secondes pour un aller-retour vers un LLM — perceptible immédiatement côté utilisateur.
• Résilience : en cas de rate limit ou d'erreur 429 côté fournisseur IA, un cache déjà chaud continue de répondre aux questions fréquentes même si les nouveaux appels échouent temporairement.

Pièges fréquents

• Cacher des réponses personnalisées : si la réponse dépend du contexte utilisateur (son compte, son historique), cacher la question seule produit des réponses hors sujet pour d'autres utilisateurs — incluez les éléments variables dans la clé ou excluez ces intentions du cache.
• TTL trop long sur du contenu qui change : un tarif ou une disponibilité mis en cache sans expiration devient une source d'erreurs silencieuses ; alignez le TTL sur la fréquence réelle de changement de l'information.
• Ne jamais purger : sans limite de taille sur l'index (MAXMEMORY + politique d'éviction allkeys-lru sur l'instance Redis), le cache grossit indéfiniment ; une politique d'éviction évite d'avoir à y penser.
• Oublier de logger les hits/miss : sans métrique de taux de succès, impossible de savoir si le cache vaut la peine d'être maintenu ni d'ajuster le seuil en connaissance de cause.

Pour aller plus loin

Ce mécanisme de cache s'ajoute naturellement en amont des workflows IA du Pack Assistant RAG (119 €), dont le chatbot à citations gagne en coût et en réactivité dès que les questions se répètent — un cas fréquent sur une base documentaire stable (procédures, FAQ, politique interne). Si votre instance n8n ne tourne pas encore avec Redis, notre guide sur le mode queue avec Redis couvre la mise en place initiale du service, réutilisable ensuite pour ce cache comme pour la montée en charge de vos workflows IA.