Prompt caching et cache sémantique : quand réutiliser une réponse ?

Le cache sémantique permet d’éviter des appels répétés au modèle en réutilisant une réponse, tandis que le prompt caching réutilise le traitement d’un préfixe de prompt. Encore faut-il que des demandes formulées différemment puissent recevoir la même réponse sans risque. Le parcours tient en 4 étapes : créer l’embedding du prompt, rechercher les voisins, appliquer un seuil, puis renvoyer une réponse stockée ou appeler le modèle. Toute la difficulté consiste à reconnaître les cas où une correspondance proche conduit malgré tout à une mauvaise réponse.

Commencez par un centre d’aide stable ou une FAQ produit publique. Un grand modèle de langage (LLM), le système qui génère la réponse, ne devrait pas avoir à réexpliquer une politique déjà publiée chaque fois que quelqu’un reformule sa question. Gardez les soldes de compte, le suivi des commandes et les actions telles que l’émission d’un remboursement hors de ce cache partagé.

Les détails d’implémentation ci-dessous ont été vérifiés dans les documentations officielles le 21 octobre 2026. L’exemple de boutique est fictif : ses scores de similarité servent à illustrer une décision, sans provenir de mesures sur des embeddings.

Prompt caching, cache exact et cache sémantique : quelles différences ?

Un cache sémantique réutilise une réponse existante lorsqu’une nouvelle demande semble avoir le même sens. Imaginez un agent du service client qui cherche une réponse validée dans un classeur : des formulations différentes peuvent mener à la même fiche, mais il vérifie toujours à quelle politique et à quel client elle s’applique.

Un embedding est une représentation numérique du texte qui permet d’en comparer le sens. Le cache conserve l’embedding d’un ancien prompt avec sa réponse et le contexte qui permet de l’identifier. Le nouveau prompt est à son tour converti en embedding, puis une recherche vectorielle repère les entrées proches. La documentation de Microsoft sur le cache sémantique décrit ce mécanisme de réutilisation des réponses et explique l’importance du contexte de la conversation.

Ces couches de cache évitent des traitements différents :

Dans un cache de réponses exact, « Puis-je retourner ce casque ? » et « Ce casque peut-il être retourné ? » ont généralement des clés différentes. Le cache sémantique peut rapprocher ces reformulations. Aucune de ces approches ne rend fiable une réponse périmée ou utilisée hors de son périmètre.

Le prompt caching du fournisseur ne récupère pas une ancienne réponse parce que la question lui ressemble. La documentation d’Anthropic sur le prompt caching décrit la réutilisation de préfixes de prompt identiques et la distingue explicitement de la génération de la sortie. Votre application demande toujours au modèle de produire une réponse. L’article sur le cache KV explique l’état conservé côté modèle qui sous-tend cette distinction.

Ces couches peuvent coexister : consulter d’abord un cache de réponses exact, puis un cache sémantique, puis appeler le modèle en bénéficiant du prompt caching du fournisseur lorsqu’il est disponible. Évaluez le cache sémantique par rapport à cette référence déjà optimisée.

Comment mettre les réponses d’un LLM en cache sémantique en quatre étapes ?

La recherche doit trouver une réponse réutilisable dans un contexte autorisé. Définissez ce contexte avant de lancer la recherche : l’utilisateur authentifié ou l’organisation cliente, la politique applicable, la langue et tout autre élément susceptible de modifier ce que la réponse peut contenir.

1. 1

   1. Créer l’embedding du prompt

   Convertissez la question reçue en embedding avec le même modèle d’embedding et une configuration compatible avec celle des entrées stockées. Incluez le contexte de conversation nécessaire pour comprendre la demande, ou limitez le cache aux questions autonomes.

   « Et pour le mien ? » ne constitue pas une clé de cache complète. Si comprendre « le mien » nécessite des données de commande privées, contournez le cache de réponses partagé.

2. 2

   2. Rechercher les voisins

   Recherchez les embeddings de prompts proches parmi les entrées stockées, dans le périmètre autorisé. Récupérez la réponse et les métadonnées de chaque candidat, c’est-à-dire les champs qui indiquent son propriétaire, la version de sa source et son expiration.

   Le plus proche voisin est simplement l’entrée la plus proche que la recherche a trouvée. Il peut rester sans pertinence pour la demande. Trouver un résultat ne signifie pas avoir trouvé une réponse réutilisable.

3. 3

   3. Appliquer le seuil et vérifier l’éligibilité

   Comparez la similarité ou la distance du candidat au seuil que vous avez calibré. Exigez ensuite une correspondance exacte sur les champs qui changent la réponse, comme l’état du produit, la version de la politique et le périmètre d’accès.

   Si le score convient mais pas le contexte, considérez que le cache n’a pas trouvé de réponse. Faites de même si le contexte nécessaire ne peut pas être établi de façon fiable.

4. 4

   4. Renvoyer la réponse ou appeler le modèle

   Lorsqu’une correspondance est acceptée, renvoyez la réponse stockée sans nouvel appel de génération. Sinon, exécutez le workflow habituel de génération ou de recherche documentaire, renvoyez son résultat et ne le stockez que s’il respecte vos règles d’admission dans le cache.

   Ne transformez pas automatiquement chaque sortie du modèle en réponse réutilisable. Les erreurs, les informations personnelles et les réponses liées à des résultats d’outils éphémères peuvent ne pas s’y prêter.

La différence essentielle avec la recherche sémantique tient à ce qui se passe après la récupération. La recherche présente des contenus pertinents ; un cache de réponses peut présenter directement une ancienne réponse comme celle à donner à la demande actuelle. Une fausse correspondance a donc davantage de conséquences.

Une réponse réutilisable et un faux ami à écarter

Une seule condition différente peut invalider une correspondance pourtant convaincante. Prenons une boutique imaginaire dont la politique autorise le retour des casques non déballés et exclut les casques déballés. Ces données servent uniquement à l’exemple ; elles ne décrivent la politique d’aucun commerçant.

Le cache contient :

• Question stockée : « Puis-je retourner un casque non déballé ? »
• Réponse stockée : « Oui. Les casques non déballés sont éligibles au retour selon la politique de cette boutique. »
• Contexte stocké : la version en vigueur de la politique de la boutique, la catégorie des casques audio, l’anglais et condition=unopened.

Pour les seuls besoins de cet exemple, supposons une similarité cosinus minimale de 0.90. La similarité cosinus compare l’orientation des vecteurs ; elle ne donne pas la probabilité qu’une réponse soit correcte. Les scores ci-dessous sont inventés pour montrer comment prendre la décision.

Les deux candidats dépassent le seuil numérique. Seule la reformulation peut réutiliser la réponse. Le faux ami reprend le produit, l’action et une bonne partie des mots, mais modifie le fait qui détermine la réponse.

Quand l’état du produit est connu, l’application devrait le transmettre dans un champ structuré. Si elle doit l’extraire du texte, toute incertitude devrait la renvoyer vers le traitement habituel de la demande. Une nouvelle comparaison d’embeddings ne remplace pas la connaissance de l’état réel du produit.

Quels réglages rendent la réutilisation fiable ?

Le seuil, la durée de vie et le périmètre agissent ensemble. Régler uniquement le seuil laisse le cache exposé à des demandes parfaitement similaires qui exigent pourtant des réponses différentes.

Seuil de similarité : le calibrer sur les mauvaises réponses

Un seuil plus strict sacrifie certaines correspondances utiles pour réduire les fausses correspondances. Un seuil plus souple augmente la réutilisation et peut aussi augmenter les erreurs. À partir de votre propre trafic, constituez un jeu annoté de reformulations et de contre-exemples difficiles, c’est-à-dire de questions proches dont les réponses doivent différer.

Incluez des changements de date, des variantes de produit, des négations, des devises, des rôles de compte et des historiques de conversation. Évaluez si la réponse stockée est valable pour la nouvelle demande, plutôt que de vérifier seulement si les prompts parlent du même sujet.

Avant de modifier le réglage, comprenez la métrique. Redis Vector Library (RedisVL), une bibliothèque destinée aux applications utilisant la recherche vectorielle de Redis, exprime distance_threshold en unités de distance COSINE de Redis, de 0 à 2 : plus la valeur est basse, plus la correspondance exigée est stricte. Un seuil minimal de similarité fonctionne généralement dans l’autre sens. Référence de l’API RedisVL.

Il n’existe aucun seuil universel à reprendre d’un modèle d’embedding, d’un jeu de données ou d’un produit à l’autre. Changer de modèle d’embedding exige aussi de planifier la migration de l’index et de refaire le calibrage ; on ne peut pas mélanger anciens et nouveaux vecteurs sans précaution.

Durée de vie : l’expiration reste un filet de sécurité

La durée de vie (TTL, pour time to live) définit combien de temps une entrée reste éligible avant d’expirer. Choisissez-la selon la durée pendant laquelle vous pouvez tolérer une ancienne réponse, et non selon la capacité du cache à la conserver.

Une réponse issue d’une documentation stable et une réponse sur la disponibilité des stocks en temps réel n’ont pas les mêmes exigences de fraîcheur. Mieux vaut parfois ne pas mettre la seconde en cache. Une correction urgente de politique doit invalider immédiatement les entrées concernées, même si leur TTL n’est pas écoulé.

Intégrez une version de source ou de politique à la vérification d’éligibilité. Lorsqu’elle change, les anciennes entrées cessent de correspondre. RedisVL propose un TTL par défaut et des valeurs spécifiques à chaque entrée, mais c’est à l’application de choisir la durée appropriée. API de cache RedisVL.

Périmètre par utilisateur : l’identité doit être une limite exacte

Réservez le cache partagé aux réponses destinées à être partagées. Un tenant correspond à une organisation cliente ; se limiter à ce périmètre ne suffit pas lorsque les employés de cette organisation ont des droits d’accès différents.

Une réponse propre à un compte exige un périmètre qui reflète l’utilisateur authentifié et ses autorisations actuelles. « Quelle est ma date de renouvellement ? » ne doit pas déclencher une recherche parmi toutes les personnes ayant posé la même question. Obtenez l’identité à partir de l’authentification fiable de l’application, jamais d’une phrase fournie par l’utilisateur ou d’un embedding.

Appliquez les filtres de périmètre avant de sélectionner le candidat, puis vérifiez l’autorisation avant de le renvoyer. Les changements de droits et les suppressions doivent empêcher les réutilisations concernées. Les paramètres filterable_fields et filter_expression de RedisVL fournissent les mécanismes de filtrage ; ils ne définissent pas automatiquement votre politique d’autorisation. Paramètres de filtrage.

Contexte et versions : conserver les hypothèses de la réponse

Délimitez les entrées en fonction des éléments qui influencent la réponse : prompt système, exigences du modèle, schéma de sortie, langue et version de la source. Un paragraphe en cache ne peut pas satisfaire une nouvelle demande qui exige une autre structure de réponse.

Dans un cache de conversations, une même phrase finale peut renvoyer à des sujets précédents différents. L’explication de Microsoft sur la fenêtre de contexte décrit explicitement ce risque. Commencez par des questions autonomes, sauf si vous savez représenter et valider l’historique pertinent.

Quelle implémentation choisir : passerelle, Redis ou bibliothèque ?

Choisissez le point d’intégration selon l’endroit où vous pouvez faire respecter les limites de validité de la réponse. Les solutions ci-dessous sont des exemples d’implémentation, pas un classement de produits interchangeables.

À la passerelle : Kong AI Semantic Cache

Kong AI Semantic Cache, un plugin de l’offre AI Gateway Enterprise de Kong, place le cache de réponses sémantique au niveau de la passerelle, le point d’entrée par lequel transitent les requêtes destinées aux modèles. Sa documentation décrit une recherche fondée sur les embeddings avec des configurations Redis ou pgvector. La référence de configuration expose cache_ttl, message_countback et vectordb.threshold.

Cette approche convient aux flux de requêtes répétitifs gérés de façon centralisée. Sa principale limite tient au contexte applicatif : une passerelle ne peut faire respecter que les distinctions présentes dans sa configuration et dans les requêtes. Vérifiez l’isolation entre utilisateurs et la gestion de l’historique avant de l’activer pour des conversations personnalisées.

Attention également au nom des options : la présentation du plugin précise qu’activer le cache exact ne désactive pas les correspondances fondées sur la similarité. N’interprétez pas ce réglage comme un mode de sécurité limité aux correspondances exactes.

Mettre en place un cache sémantique avec Redis

Redis, un système de stockage de données doté de capacités de recherche vectorielle, laisse l’application piloter la recherche et le traitement des demandes sans correspondance. Le composant SemanticCache documenté dans RedisVL propose les opérations check et store, des métadonnées, des filtres et des réglages de TTL. Documentation de RedisVL.

Ce schéma convient lorsque votre application connaît déjà l’organisation cliente, la politique et les versions des enregistrements, et doit les contrôler avant de renvoyer un résultat. La même architecture peut s’appuyer sur un autre système de stockage vectoriel adapté : les vecteurs des prompts repèrent les candidats, tandis que les réponses stockées et les métadonnées déterminent ce qui peut être réutilisé.

En contrepartie, vous en assumez la responsabilité. Un index vectoriel ne fournit ni règles d’admission dans le cache, ni invalidation, ni autorisation, ni réponse correcte. Vous devez implémenter et surveiller ces comportements, et exploiter un déploiement capable de prendre en charge vos requêtes vectorielles.

Côté bibliothèque : GPTCache

GPTCache, une bibliothèque de création de caches sémantiques, sépare la génération des embeddings, le stockage des réponses, la recherche vectorielle et l’évaluation de la similarité en composants configurables. Sa documentation avertit explicitement que toutes les combinaisons de modules ne sont pas compatibles.

Cette approche convient aux développeurs qui souhaitent expérimenter avec les composants de recherche et d’évaluation au sein d’une application. Sa principale limite est la responsabilité d’intégration : vérifiez les adaptateurs choisis avec le SDK de votre modèle et votre déploiement actuels, et conservez les mêmes contrôles de périmètre et de fraîcheur autour de la bibliothèque. Son abstraction ne garantit pas qu’une correspondance sémantique donne la bonne réponse.

Si vous choisissez également la couche de routage des requêtes, consultez le comparatif des passerelles IA et LiteLLM vs OpenRouter pour éclairer cette décision plus large. Le cache est un critère parmi d’autres, aux côtés du routage, des identifiants d’accès et de l’observabilité.

Calculer les économies à partir de vos propres requêtes

Un cache ne fait économiser de l’argent que si les coûts de génération évités dépassent ceux des embeddings, de la recherche, du stockage et de l’exploitation. Comptez aussi les recherches infructueuses : elles supportent le surcoût du cache et appellent quand même le modèle.

Utilisez une seule période de mesure et une seule devise. Soit N le nombre de requêtes éligibles qui atteignent la couche sémantique, après les éventuelles réponses du cache exact ; H le nombre de correspondances sémantiques acceptées ; G le coût de génération par requête, dans l’hypothèse simplificatrice d’un coût identique pour chacune ; E le coût d’embedding et de recherche par requête éligible ; W le coût d’écriture dans le cache après chaque recherche infructueuse ; et F les coûts fixes d’infrastructure et d’exploitation sur la période.

Le calcul est le suivant :

• Sans couche sémantique : N × G
• Avec cette couche : (N − H) × G + N × E + (N − H) × W + F
• Économie nette : H × G − N × E − (N − H) × W − F

Appliquez-le à vos journaux : multipliez les correspondances acceptées par le coût du modèle qu’elles ont évité, soustrayez les coûts de recherche pour toutes les requêtes éligibles, puis les écritures liées aux recherches infructueuses et les coûts fixes. Utilisez les coûts de génération après les éventuelles réductions liées au prompt caching du fournisseur, pas le tarif catalogue sans cache.

Sous ces hypothèses, la condition de rentabilité est :

H > [N × (E + W) + F] / (G + W)

Pour une charge hétérogène, remplacez H × G par la somme des coûts de génération effectivement évités pour les requêtes servies depuis le cache. Comptez les écritures réelles si certaines réponses ne sont pas admises. Incluez les nouvelles tentatives, les appels d’évaluation et le travail d’exploitation dans les totaux concernés. Le taux de réponses servies depuis le cache ne suffit pas à établir sa rentabilité.

Le même raisonnement s’applique à la latence. Une correspondance acceptée supprime la génération de son parcours ; une recherche infructueuse ajoute l’embedding et la recherche avant la génération. Mesurez les deux parcours, y compris les latences les plus élevées. Une charge composée surtout de demandes uniques peut devenir plus lente, même si ses rares réponses en cache sont rapides.

Quelles promesses du cache sémantique faut-il relativiser ?

Un sens proche ne garantit pas des réponses équivalentes. Le cache sélectionne une réponse existante ; il ne prouve pas qu’elle reste correcte, autorisée ou à jour.

La métrique la plus trompeuse est un taux de correspondances en hausse sans audit des correspondances erronées. Assouplir le seuil peut embellir le tableau de bord tout en donnant davantage de corrections à traiter au support. Confrontez les réponses du cache aux nouvelles demandes, surtout celles qui se situent au plus près de votre seuil d’acceptation.

Le cache de réponses ne remplace pas non plus la génération augmentée par récupération (RAG), dans laquelle un modèle reçoit des contenus sources récupérés pour l’aider à produire sa réponse. Un cache peut intervenir avant ce workflow, mais éviter le workflow signifie aussi renoncer à une nouvelle recherche dans les sources. Associez les réponses en cache aux versions des sources, ou contournez la réutilisation lorsque les faits sous-jacents doivent être à jour.

Traitez « annuler ma commande » comme une action, pas comme une question réutilisable. Une ancienne confirmation ne prouve en rien qu’une nouvelle action a été autorisée ou exécutée. Conservez l’exécution et son résultat actuel dans le parcours normal de l’application.

Qui devrait se lancer, et par où commencer ?

Les développeurs confrontés à des questions publiques répétitives peuvent commencer maintenant, sur un périmètre restreint. Choisissez une intention stable, définissez son périmètre autorisé et gardez le cache exact comme référence. L’intérêt est de réduire les appels de génération répétés sans élargir les catégories de réponses que l’application peut réutiliser.

Les équipes d’exploitation devraient commencer par une évaluation en mode miroir. Journalisez la réponse du cache qui aurait été renvoyée tout en continuant à servir la réponse habituelle. Annotez les véritables reformulations et les faux amis, puis calibrez le seuil en fonction des erreurs inacceptables. Mesurez le surcoût du cache, le comportement à l’expiration et la qualité de la réponse stockée elle-même.

Les acheteurs devraient demander des preuves d’isolation et d’invalidation. Une case « cache sémantique » dans une liste de fonctionnalités ne suffit pas. Demandez comment le système gère des questions identiques posées par des utilisateurs différents et ce qui se passe immédiatement après une modification de politique.

Attendez si la plupart des questions dépendent de données changeantes ou d’un contexte de conversation à plusieurs tours que vous ne pouvez pas isoler. Si les répétitions exactes couvrent déjà le trafic réutilisable, la recherche sémantique peut apporter peu. Le prompt caching du fournisseur peut tout de même être utile pour les préfixes d’entrée répétés, sans imposer de réutiliser une réponse terminée.

Dès lundi : prenez une intention de votre centre d’aide, rassemblez ses reformulations et des variantes volontairement trompeuses, définissez le périmètre du cache et sa règle d’invalidation, puis rejouez ces demandes en mode miroir. N’activez la réutilisation qu’une fois les cas susceptibles de produire une mauvaise réponse écartés de manière fiable.

Questions fréquentes

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

Il stocke des réponses antérieures et les retrouve grâce à une similarité fondée sur le sens. Leur réutilisation devrait aussi exiger un contexte concordant, des autorisations valides et une fraîcheur suffisante.

Quels sont les trois types de cache ?

Pour ce choix lié aux LLM, distinguez le cache de réponses exact, le cache de réponses sémantique et le cache de prompts du fournisseur. Cette comparaison est utile dans le cadre de l’article ; ce n’est pas une classification universelle de tous les caches informatiques.

Comment implémenter un cache sémantique ?

Définissez le périmètre autorisé, créez les embeddings des prompts entrants, récupérez les candidats, appliquez un seuil calibré et les vérifications d’éligibilité, puis renvoyez la réponse stockée ou appelez le modèle. Prévoyez l’expiration, l’invalidation et la surveillance des correspondances erronées avant d’activer la réutilisation.

Un CDN est-il simplement un cache ?

Non. Un réseau de diffusion de contenu (CDN) répartit la distribution des contenus entre plusieurs emplacements ; le cache est l’un des mécanismes qu’il utilise. Voir l’architecture CDN de Cloudflare.

Cloudflare est-il un CDN ou un WAF ?

Cloudflare propose à la fois des services CDN et un pare-feu applicatif web (WAF), qui filtre le trafic des applications. Aucune de ces étiquettes ne désigne à elle seule un cache sémantique de réponses de LLM. Architecture de Cloudflare.

Quelle différence entre un CDN et Redis ?

Un CDN distribue des contenus sur un réseau de périphérie. Redis est un système de stockage de données qu’une application peut utiliser pour la mise en cache, y compris dans une architecture de cache sémantique configurée à cet effet. Ils occupent des places différentes dans le système.

Cloudflare se limite-t-il au CDN ?

Non. Cloudflare décrit aussi des services DNS, de pare-feu et d’autres services en périphérie dans son architecture de référence.

Kafka est-il meilleur que Redis ?

Ils répondent à des besoins différents. Apache Kafka est une plateforme de streaming d’événements. Ce n’est pas un remplacement direct de l’architecture de cache de réponses sémantique Redis décrite ici.

Netflix utilise-t-il Redis ?

Oui. Redis documente l’utilisation de Redis par Netflix pour des files d’attente prioritaires, avec un lien vers l’article de Netflix consacré à Timestone. Cet exemple historique ne démontre pas un usage de cache sémantique pour les LLM et ne justifie pas son activation dans votre application.

Pour des conseils pratiques sur la création d’applications IA fiables, abonnez-vous à la newsletter.