Mise en cache sémantique
La mise en cache sémantique stocke les réponses passées des modèles et les réutilise lorsqu'une nouvelle requête est sémantiquement similaire à une précédente — en faisant correspondre le sens via des plongements (embeddings), et non par texte exact. Elle réduit les coûts et la latence pour les requêtes répétitives ou quasi-identiques fréquentes en production.
Problème
De nombreuses requêtes en production sont des paraphrases de requêtes déjà traitées, de sorte que réexécuter le modèle complet pour chacune d'elles gaspille du budget et de la latence.
Quand l'utiliser
Utilisez la mise en cache sémantique lorsque le trafic contient de nombreuses questions similaires ou répétées et que les réponses sont suffisamment stables pour être réutilisées — FAQ, support, assistants de documentation.
Solution
Générez un embedding pour chaque requête entrante et recherchez dans un cache d'embeddings de requêtes antérieures. Si une entrée suffisamment similaire existe (au-dessus d'un seuil de similitude), renvoyez sa réponse stockée ; sinon, appelez le modèle et stockez la nouvelle paire.
Ajustez soigneusement le seuil de similitude : un seuil trop lâche renvoie des réponses erronées pour des questions subtilement différentes ; un seuil trop strict manque des correspondances valides. Ajoutez des TTL et de l'invalidation pour éviter que les réponses mises en cache ne deviennent obsolètes.
Composants
Avantages
- Coût réduit en évitant les appels répétés au modèle.
- Latence réduite lors des accès au cache (cache hits).
- Réponses plus cohérentes pour des questions similaires.
Risques
- Un seuil trop lâche renvoie des réponses erronées mises en cache.
- Cache obsolète en l'absence de TTL ou d'invalidation.
- Les réponses personnalisées ou sensibles au facteur temps se prêtent mal à la mise en cache.
Quand ne pas l'utiliser
- Lorsque la plupart des requêtes sont uniques.
- Lorsque les réponses dépendent de données fraîches, spécifiques à l'utilisateur ou au temps.
- Lorsque même de légères divergences sont inacceptables.
Technologies
Exemples
- Réutiliser la réponse à « comment réinitialiser mon mot de passe » à travers ses nombreuses formulations.
- Mettre en cache les questions fréquentes de la documentation dans un assistant de support.
- Court-circuiter les questions d'analyse identiques et répétées.
Preuves de production
- Contexte
- Déploiement OpenClaw local-first à opérateur unique observé sur 57 jours (161 sessions / 2 776 tours), agrégé à partir des traces de trajectoire de l'agent lui-même.
- Scénario
- La mise en cache des prompts et du contexte est conçue avec des marqueurs cache_control, ainsi qu'un cache de fichiers d'espace de travail et un cache de routes, de sorte que la structure répétée soit servie depuis le cache.
- Technologie
- Injection cache_control d'Anthropic sur le système et les messages, passerelle OpenRouter, cache de fichiers d'espace de travail, cache de routes et comptabilisation des coûts de lecture/écriture du cache (cache_read/write).
- Charge
- 28,1 millions de tokens au total sur 57 jours, dont environ 19,6 millions servis en lecture de cache.
- Résultats
- Environ 70 % des tokens ont été servis depuis le cache, maintenant le coût mixte à 15,21 $ par million de tokens (41 $ de lecture de cache contre 374 $ d'entrées fraîches). Déploiement local-first à opérateur unique — ce ratio reflète la répétitivité de cette charge de travail ; mesurez la vôtre.
KPI
- Taux de succès du cache
- Part des requêtes servies depuis le cache ; le levier pour réduire à la fois les coûts et la latence.
- Taux de faux positifs
- Fréquence à laquelle une correspondance sémantiquement « similaire » renvoie une réponse erronée ou obsolète — le risque central de la mise en cache par le sens.
- Coût et latence économisés par succès
- Tokens et temps évités lors des accès au cache, le bénéfice obtenu en contrepartie du risque de faux positif.
- Calibrage du seuil de similitude
- Détermine si le seuil de correspondance équilibre le taux de succès et les faux positifs ; un seuil trop lâche nuit à la qualité, un seuil trop strict annule les économies.
Modes de défaillance observés
- Faux positifs : deux requêtes sont proches dans l'espace d'embedding mais nécessitent des réponses différentes, de sorte que le cache renvoie une réponse erronée.
- Obsolescence : les réponses mises en cache deviennent périmées alors que les faits sous-jacents changent.
- Mauvais réglage du seuil : un seuil trop lâche renvoie des réponses erronées, un seuil trop strict ne génère presque aucun succès.
- Empoisonnement du cache : une mauvaise réponse est mise en cache puis servie de manière répétée.
Leçons apprises
- Ajustez le seuil de similitude par rapport au trafic réel ; c'est le paramètre décisif.
- Ne mettez jamais en cache lorsque la fraîcheur ou l'exactitude est critique sans stratégie d'invalidation.
- Valisez ou échantillonnez les accès au cache pour détecter les fausses correspondances avant les utilisateurs.
- Restreignez la portée des caches (par locataire, par contexte) pour éviter de divulguer une mauvaise réponse à d'autres utilisateurs.
FAQ
- En quoi cela diffère-t-il d'un cache normal ?
- Un cache normal fait correspondre des clés exactes ; un cache sémantique fait correspondre par le sens à l'aide d'embeddings, de sorte que les questions paraphrasées génèrent tout de même un succès.
- Quel est le risque principal ?
- Un seuil de similitude trop lâche renvoie une réponse mise en cache pour une question qui est en réalité différente. Ajustez le seuil et validez sur du trafic réel.
- Comment éviter les réponses obsolètes ?
- Définissez des TTL et invalidez les entrées lorsque les données sous-jacentes changent ; évitez de mettre en cache des réponses personnalisées ou sensibles au facteur temps.