Technical Tutorials

Les grands modèles de langage (LLM) sont gourmands en ressources, ce qui rend le cache des réponses une stratégie essentielle pour réduire la latence et les coûts de calcul. Cependant, le déploiement de LLM dans un environnement multi-locataires introduit une complexité significative. Une stratégie de cache naïve peut entraîner deux échecs critiques : les fuites de données, où le locataire A reçoit des réponses en cache générées pour le locataire B, et les réponses obsolètes, où le modèle fournit des informations dépassées qui contredisent un contexte plus récent et spécifique au locataire. Cet article explore comment concevoir un protocole de cohérence du cache qui garantit à la fois la sécurité et la fraîcheur dans une infrastructure LLM partagée.

Le problème du cache naïf

Dans une API REST standard, le cache est souvent géré par des signatures de requête. Pour les LLM, cependant, l'« entrée » est rarement une simple chaîne de caractères. Elle inclut les invites système, l'historique de l'utilisateur, le contexte de génération augmentée par récupération (RAG) et potentiellement des paramètres spécifiques au locataire comme la température ou les valeurs top-k. Si votre clé de cache est basée uniquement sur l'invite finale de l'utilisateur, vous risquez une collision. Deux locataires différents pourraient demander « Quelle est votre politique de remboursement ? ». La politique du locataire A est stricte, tandis que celle du locataire B est flexible. Si le système met en cache la première réponse, le locataire B reçoit la politique incorrecte du locataire A, entraînant une fuite de données et un échec de la logique métier.

Concevoir une clé de cache multidimensionnelle

Pour assurer la cohérence, la clé de cache doit être un hachage composite de toutes les variables qui influencent la sortie du modèle. Cela inclut :

Identifiant du locataire : La frontière de sécurité la plus critique.
Version du modèle : Des poids de modèle ou des invites système différents nécessitent des caches séparés.
Hachage de la fenêtre de contexte : Un hachage des fragments RAG spécifiques ou des recherches en base de données utilisés pour cette requête.


import hashlib
import json

def generate_coherent_cache_key(tenant_id: str, model_version: str, prompt: str, context_chunks: list[str], params: dict) -> str:
    """
    Génère une clé de cache unique qui assure l'isolation des locataires et la fraîcheur du contexte.
    """
    # 1. Combiner tout l'état immuable
    state = {
        "tenant": tenant_id,
        "model": model_version,
        "prompt": prompt,
        "context": sorted(context_chunks), # Trier pour assurer la cohérence quel que soit l'ordre
        "params": {
            "temperature": params.get("temperature"),
            "top_k": params.get("top_k")
        }
    }
    
    # 2. Créer une représentation JSON stable
    stable_json = json.dumps(state, sort_keys=True)
    
    # 3. Hacher pour le stockage
    return hashlib.sha256(stable_json.encode('utf-8')).hexdigest()

Gestion du contexte obsolète et stratégies de TTL

Même avec une clé parfaite, les données deviennent obsolètes. Si votre pipeline RAG met à jour la base de connaissances, les caches précédents deviennent invalides. Un temps de vie (TTL) est nécessaire, mais s'y fier uniquement est dangereux. Au lieu de cela, implémentez un jeton de contexte versionné. Lorsque la base de connaissances est mise à jour, incrémentez un numéro de version. Incluez cette version dans la clé de cache.

Pour les conversations dynamiques, envisagez un TTL à fenêtre glissante. Si un utilisateur est en plein milieu d'une conversation multi-tours, le cache devrait expirer rapidement (par exemple, 30 secondes) pour s'assurer que la prochaine invite tient compte du tour précédent immédiat, qui pourrait changer l'intention sémantique de la requête suivante.

Implémentation pratique : Redis avec l'espacement des noms

En utilisant Redis, vous pouvez appliquer l'isolation via l'espacement des noms (namespacing). Bien que le hachage composite protège contre les collisions, l'utilisation d'un préfixe Redis séparé par locataire ajoute une couche de défense supplémentaire contre les erreurs logiques dans la génération des clés.


class LLMCacheService:
    def __init__(self, redis_client):
        self.redis = redis_client

    def get_or_generate(self, tenant_id: str, key_hash: str, generate_fn):
        # Clé avec espace de noms pour la défense en profondeur
        namespaced_key = f"llm:cache:{tenant_id}:{key_hash}"
        
        cached_response = self.redis.get(namespaced_key)
        if cached_response:
            return json.loads(cached_response)

        # Manqué de cache : Générer une nouvelle réponse
        response = generate_fn()
        
        # Définir avec un TTL (par exemple, 3600 secondes = 1 heure)
        self.redis.setex(namespaced_key, 3600, json.dumps(response))
        
        return response

Surveillance des anomalies

Implémentez la journalisation pour détecter les problèmes potentiels de cohérence. Suivez le taux de réussite du cache par locataire. Une chute soudaine des taux de réussite pour un locataire spécifique pourrait indiquer un bug dans leur logique de génération de contexte, provoquant des clés uniques pour chaque requête (ce qui est coûteux). Inversement, un taux de réussite élevé sur des requêtes « sensibles » à travers différents locataires devrait déclencher une alerte pour examen manuel, car cela peut indiquer une vulnérabilité de collision de clés.

Conclusion

La cohérence du cache dans les environnements LLM multi-locataires n'est pas seulement une question de performance ; c'est une impératif de sécurité. En concevant des clés de cache composites qui incluent les identifiants de locataires, les versions de modèles et les hachages de contexte, vous pouvez exploiter en toute sécurité le cache pour réduire les coûts. Associez toujours cela à une gestion robuste du TTL et à une surveillance pour vous assurer que, à mesure que votre infrastructure IA se développe, vos frontières de données restent impénétrables et vos réponses restent précises.