Chatbot d'IA : comment le semantic catching fait baisser les coûts d'appels API
Les LLM coûtent encore cher en 2026, très cher. Que ce soit en mode API ou on-device, chaque appel à un LLM de grande taille engendre d'importants frais. La réduction du nombre d'appels API ou de tokens consommés figure donc parmi les priorités des entreprises qui ont déployé un chatbot d'entreprise ou un assistant de service client. Ces derniers sont de gros consommateurs de tokens : chaque question utilisateur nécessite un appel au modèle et engendre des coûts plus ou moins importants selon la charge.
Pour limiter le coût des prompts fixes, le prompt caching s'est largement démocratisé chez les éditeurs. Mais une technique encore plus efficace reste sous-exploitée : le semantic caching. Elle promet une diminution de latence considérable et une réduction drastique du nombre d'appels au modèle. Explications.
La limite du prompt caching
Massivement déployé chez les éditeurs de modèles depuis fin 2024, OpenAI, Google, Anthropic (mais pas Mistral AI, bizarrement), le prompt caching offre déjà une réduction significative de la consommation de tokens. Le principe : les parties fixes d'un prompt (celles qui ne changent jamais d'une requête à l'autre) sont mises en cache. Résultat : le modèle ne les retraite pas à chaque appel, ce qui permet d'économiser environ 90% du coût sur ces tokens en input. Concrètement, vous ne payez le prix fort que pour les tokens variables, pas pour le contexte stable déjà en cache. Et ce, dès la deuxième requête.
Mais ce système a ses limites. Il ne permet de cacher que l'input du prompt stable, pas la réponse qui sera de toute manière régénérée par le modèle. Impossible donc de faire des économies sur la sortie. De même, si un prompt est sémantiquement proche d'un autre mais n'a pas exactement la même formulation, le prompt caching ne s'appliquera pas. Ainsi, dans un chatbot d'entreprise ou de service client, vos collaborateurs ou clients qui posent souvent les mêmes questions avec des formulations différentes ne pourront pas pleinement profiter du prompt caching.
Le semantic caching, pour les prompts sémantiquement proche
Pour résoudre cette limitation structurelle, le semantic caching s'est développé depuis plusieurs mois. Il permet de limiter drastiquement non pas le nombre de tokens utilisés par le modèle, mais bien les appels API directs, que le modèle soit déployé en local ou via une API cloud. Le but ? Qu'une requête avec le même objectif (donc sémantiquement très proche) ne déclenche qu'une seule fois l'appel API. Les fois suivantes, si la requête est très proche de la précédente, on expose directement la réponse stockée sans solliciter à nouveau le modèle.
Exemple de trois prompts sémantiquement très proche ou la même réponse peut être proposée :
Prompt 1 : "Mon imprimante ne marche plus, que faire ?"
Prompt 2 : "L'imprimante est en panne, comment la réparer ?"
Prompt 3 : "J'ai un problème avec mon imprimante, elle ne fonctionne pas"
Le principe est simple, mais comment cela fonctionne techniquement ? Pour mettre en place ce système, il suffit de vectoriser les requêtes utilisateurs (avec un moteur d'embeddings), de les stocker dans un index sémantique, puis de stocker la réponse générée par l'API. Une fois qu'une seconde requête arrive, on compare les vecteurs entre eux en utilisant une formule pour mesurer leur similarité (on utilise la similarité cosinus, pour les plus matheux).
La similarité peut être réglée selon le niveau de précision souhaité. Il faut dans tous les cas définir un seuil de similarité supérieur à 80% (0,8) pour des tâches basiques et de 95 à 98% (0,95 à 0,98) pour une fiabilité accrue. Mathématiquement, plus le seuil est élevé, moins grandes sont les chances d'identifier deux requêtes similaires. Un seuil de 85% (0,85) est donc assez conservateur sans être trop restrictif. Si la similarité est supérieure ou égale au seuil que vous avez défini, vous exposez directement la réponse déjà générée correspondant au vecteur précédent. Simple comme bonjour, non ? Les gains sont clairs et varient selon les études, mais le semantic caching permettrait d'économiser en moyenne, selon le contexte de déploiement, entre 40 et 70% d'appels API. De même, la vitesse est drastiquement augmentée car le modèle ne calcule plus la réponse : le système envoie simplement la réponse stockée en cache.
Mettre en place le semantic caching dans vos projets
Des frameworks prêts à l'usage ont fleuri ces derniers mois sur GitHub. L'un des plus célèbres, GPTCache, a récemment été intégré dans le framework LangChain. Il est facile à utiliser et la documentation ne manque pas. Côté cloud providers, des solutions clés en main sont également proposées. Microsoft propose de nombreux exemples sur la construction d'un chatbot en utilisant sa base vectorielle Azure Cosmos DB ou via son service Azure OpenAI pour faire du semantic caching. De son côté, Google propose un guide complet pour créer un système de semantic caching en se basant sur son moteur d'embedding Vertex AI Text Embeddings avec Vector Search. AWS propose aussi une solution basée sur son modèle d'embedding Titan en utilisant MemoryDB. Bref : les solutions ne manquent pas.
Dans quel cas le semantic caching prend-t-il tout son sens ?
Vous l'aurez compris, le semantic caching ne remplace pas le prompt caching : il ajoute une couche supplémentaire pour éviter les appels API. Il sera particulièrement pertinent dans les cas où vos utilisateurs posent les mêmes questions mais avec des formulations différentes. C'est typiquement le cas d'un chatbot interne (les mêmes questions RH peuvent être posées par différents collaborateurs) ou d'un chatbot de service client où les mêmes réponses reviennent régulièrement (politique de retour, question sur un produit spécifique…). Dans ces cas, la technique prend tout son sens et évite de solliciter le modèle.
De son côté, le prompt caching reste pleinement efficace pour les chatbots généralistes qui sont avant tout utilisés pour leur fonction utilitaire (génère-moi un texte, résume ceci, fais cela...). Les questions seront là drastiquement différentes d'un utilisateur à l'autre, mais le prompt système et le contexte d'utilisation seront souvent les mêmes. Inutile dès lors de déployer du temps et de l'énergie dessus.