Cache sémantique en production : 3 mois de mesures sur le hit rate réel

L'idée du cache sémantique est simple : si deux requêtes sont sémantiquement proches, retourner la réponse déjà calculée pour la première plutôt que d'appeler le LLM une deuxième fois. Économie de tokens, réduction de latence, amélioration de la consistance des réponses.

En théorie. En pratique, le hit rate réel dépend fortement du comportement des utilisateurs, et les chiffres publiés dans les benchmarks ne se reproduisent pas toujours.

Voici ce qu'on a mesuré sur 3 mois, sur un assistant documentaire interne pour une entreprise de 200 personnes.

Architecture du cache

On a utilisé GPTCache comme couche de cache, avec Qdrant comme backend vectoriel pour les embeddings de requêtes.

from gptcache import cache
from gptcache.adapter import openai
from gptcache.embedding import Onnx
from gptcache.manager import CacheBase, VectorBase, get_data_manager
from gptcache.similarity_evaluation.distance import SearchDistanceEvaluation

# Configuration du cache sémantique
onnx = Onnx()  # modèle d'embedding léger, ONNX runtime, ~30ms par requête

cache.init(
    embedding_func=onnx.to_embeddings,
    data_manager=get_data_manager(
        CacheBase("sqlite"),           # stockage des réponses
        VectorBase("qdrant",           # stockage des vecteurs
            host="localhost",
            port=6333,
            collection_name="semantic_cache",
            dimension=onnx.dimension,
        ),
    ),
    similarity_evaluation=SearchDistanceEvaluation(),
)
cache.set_openai_key()

# Ensuite, openai.ChatCompletion.create fonctionne normalement
# et passe par le cache automatiquement

Le seuil de similarité par défaut de GPTCache est 0,95. Trop conservateur pour notre cas d'usage, le hit rate était quasi nul. On l'a descendu progressivement.

Les chiffres sur 3 mois

Volume : 18 400 requêtes sur la période, corpus de 1 800 documents internes (procédures RH, notes de service, documentation produit).

Seuil de similarité 0,95 (semaine 1-2) :

• Hit rate : 2,1 %
• Économie tokens : négligeable

Seuil 0,90 (semaine 3-6) :

• Hit rate : 8,4 %
• Économie tokens : ~7 % du volume total
• Faux positifs observés manuellement : 3 sur 50 réponses cachées vérifiées (6 %)

Seuil 0,85 (semaine 7-12) :

• Hit rate : 17,3 %
• Économie tokens : ~15 % du volume total
• Faux positifs : 9 sur 50 réponses vérifiées (18 %)

À 0,85, le taux de faux positifs est devenu inacceptable pour ce client. Des requêtes légèrement différentes retournaient une réponse mise en cache pour une variante proche mais pas identique. Les utilisateurs remarquaient la différence.

Seuil retenu : 0,88, hit rate de 11,7 %, économie de 10 % sur la facture LLM, faux positifs estimés à 8 %.

Sur GPT-4o à 2,50 USD / million de tokens input, 10 % d'économie sur 18 400 requêtes avec un prompt moyen de 2 000 tokens représente environ 90 USD d'économie sur 3 mois. Le cache en lui-même coûte du compute embedding (~0,003 USD par requête via ONNX en self-hosted), soit ~55 USD sur la période.

Bilan net : +35 USD d'économie sur 3 mois. Ce n'est pas le jackpot, mais le gain en latence (les hits sont servis en < 50 ms vs 2-4 s pour un appel LLM) a autant de valeur perçue que l'économie financière.

Les effets de bord inattendus

Effet de date. Les requêtes du type "quelles sont les procédures en vigueur" retournaient parfois une réponse mise en cache 6 semaines plus tôt. Le corpus avait été mis à jour entre-temps. On a ajouté une invalidation automatique du cache à chaque réingestion de document source.

Effet de contexte utilisateur. L'assistant était en mode multi-tenant implicite : tous les utilisateurs partageaient le même cache. Une requête "quel est mon solde de congés" d'un utilisateur A retournait la réponse calculée pour l'utilisateur B si les formulations étaient proches. On a isolé le cache par tenant en préfixant l'embedding de requête avec l'identifiant du département.

Hit rate non uniforme. Les 20 % de requêtes les plus fréquentes représentaient 70 % des cache hits. Le cache était quasi inutile pour les requêtes de longue traîne (questions spécifiques, rares). Le gain réel était concentré sur un nombre limité de motifs.

Quand le cache sémantique vaut le coup

Le ROI est positif si :

• Le volume de requêtes est élevé (> 10 000/mois)
• Les requêtes sont répétitives, même base d'utilisateurs, même corpus de questions
• Le corpus source change peu fréquemment

Le ROI est faible ou négatif si :

• Les requêtes sont très variées (longue traîne dominante)
• Le corpus est mis à jour en continu (invalidation fréquente)
• Le modèle LLM utilisé est déjà bon marché (gpt-4o-mini, le gain absolu est faible)

Le cache sémantique est pertinent sur un assistant avec une base d'utilisateurs qui posent régulièrement les mêmes types de questions : support client, FAQ interne, assistant de conformité réglementaire. Il est moins pertinent sur un assistant de recherche exploratoire où chaque requête est nouvelle.

La limite qu'on n'a pas encore résolue : comment calibrer dynamiquement le seuil de similarité par type de requête détecté, pour maximiser le hit rate sur les requêtes factuelles tout en conservant un seuil haut sur les requêtes contextuelles ?