Vos utilisateurs posent la même question de 40 façons différentes, et vous payez votre LLM pour répondre à chaque fois depuis le début. « Comment réinitialiser mon mot de passe ? » « J’ai oublié mes identifiants, aidez-moi » « Je ne peux pas accéder à mon compte » Même réponse. Trois appels complets au modèle. Le cache normal ne peut pas détecter cela. Il ne fonctionne que lorsque le texte correspond exactement, caractère par caractère. Le cache sémantique reconnaît le SENS. Une question arrive. Elle est transformée en embedding. Le cache vérifie si vous avez déjà répondu à une question suffisamment proche. Hit ? La réponse enregistrée est renvoyée instantanément. Aucun appel au modèle. Miss ? Le modèle répond, et cette réponse est enregistrée pour la prochaine fois. Redis propose désormais cela en tant que service géré appelé LangCache. Aucune base de données supplémentaire à déployer, TTL et éviction gérés pour vous. Ils affirment des taux de hit jusqu’à 15 fois plus rapides et des réductions importantes de votre facture API. Mais voici la partie que personne ne mentionne. Le seuil de similarité est l’endroit où cela échoue. Définissez-le trop largement, et « comment faire pour faire pivoter ma clé API » renvoie la réponse à « comment révoquer ma clé API ». Proche en sens. Résultat très différent. Commencez donc strictement. Journalisez chaque hit pendant une semaine. Assouplissez uniquement là où vous avez vérifié que les réponses sont véritablement interchangeables. Vos économies dépendent de la répétitivité réelle de votre trafic. Les bots d’assistance et les assistants de documentation interne gagnent énormément. Les requêtes créatives ou ponctuelles à peine. Vérifiez vos journaux avant de consulter la page tarifaire. suivez @cyrilXBT https://t.co/tQmQCsxVlo