Context Engineering — Section 7 : Caching & Long Contexte

Niveau 1 : Le Cache Applicatif

Ce sont des stratégies de mise en cache que vous implémentez dans votre propre code, en amont de l'appel à l'API du LLM.

Niveau 2 : Le Cache d'Inférence (KV Cache)

Le KV Cache est le mécanisme fondamental qui rend la génération de texte par les Transformers efficace. Sans lui, chaque nouveau token nécessiterait de recalculer l'attention sur l'intégralité du texte précédent, une opération quadratique (O(n²)) insoutenable.

Optimisations pour Gérer le KV Cache : PagedAttention

Avec de longs contextes (ex: 100k tokens) et de grands batchs, le KV Cache peut consommer des dizaines de Go de VRAM. Sa gestion devient un problème majeur, résolu par des techniques innovantes comme PagedAttention (popularisé par vLLM).

Gestion de Fenêtre pour Contexte "Infini"

Même avec 1M de tokens, il y aura toujours des cas d'usage nécessitant un contexte plus long (analyse de codebases, assistants sur le long terme). La gestion de fenêtre est une approche pour simuler un contexte infini.

• Sliding Window Attention : Une caractéristique architecturale (ex: Mistral 7B) où l'attention de chaque token est limitée aux `k` tokens précédents (ex: 4096). Permet des contextes théoriques longs avec un coût de calcul constant.
• StreamingLLM : Une technique d'inférence qui gère un cache glissant. Elle observe que les premiers tokens ("attention sinks") sont cruciaux pour la stabilité. Le cache garde donc les 4 premiers tokens + les `k` tokens récents, permettant des conversations de millions de tokens sans dégradation.
• Le test "Needle in a Haystack" : Un benchmark célèbre qui mesure la capacité d'un modèle à retrouver une information précise ("l'aiguille") noyée dans un long contexte ("la botte de foin"). Il montre que même les meilleurs modèles à long contexte ont des "angles morts" et que la performance diminue lorsque le contexte s'allonge.

Évaluation des Performances

Les métriques pour le caching et les systèmes d'inférence sont centrées sur la vitesse et le débit.

Pièges & Erreurs à Éviter

• Cache sémantique trop laxiste : Un seuil de similarité trop élevé (> 0.2) peut retourner des réponses pour des questions qui ne sont que vaguement similaires.
• Ignorer le coût du cache : Le KV Cache consomme énormément de VRAM. Sans des systèmes comme PagedAttention, héberger un modèle à long contexte peut devenir prohibitif.
• Croire que "long contexte" remplace RAG : Même avec 1M de tokens, le RAG (Retrieve-Augment-Generate) est souvent plus performant et moins cher. Il effectue un premier filtrage pour ne donner au LLM que les informations les plus pertinentes, ce qui est une forme de compression contextuelle.

Snippet 1 : Cache Sémantique Simplifié

from sentence_transformers import SentenceTransformer, util
import numpy as np

class SemanticCache:
    def __init__(self, threshold=0.9):
        self.encoder = SentenceTransformer('all-MiniLM-L6-v2')
        self.cached_embeddings = []
        self.cached_responses = []
        self.threshold = threshold

    def get(self, query):
        if not self.cached_responses:
            return None
        
        query_embedding = self.encoder.encode(query, convert_to_tensor=True)
        # Compare against all cached embeddings
        cos_scores = util.cos_sim(query_embedding, self.cached_embeddings)[0]
        best_match_idx = np.argmax(cos_scores)

        if cos_scores[best_match_idx] > self.threshold:
            print(f"Cache hit! Similarity: {cos_scores[best_match_idx]:.2f}")
            return self.cached_responses[best_match_idx]
        return None

    def put(self, query, response):
        query_embedding = self.encoder.encode(query, convert_to_tensor=True)
        self.cached_embeddings.append(query_embedding)
        self.cached_responses.append(response)

# Utilisation
# cache = SemanticCache()
# cache.put("What is the capital of France?", "The capital of France is Paris.")
# response = cache.get("Tell me the capital city of France") # -> Cache hit!

Snippet 2 : Démarrer un serveur vLLM (Concept)

# vLLM active PagedAttention par défaut.
# Ce simple script Python lance un serveur d'inférence OpenAI-compatible
# pour le modèle Mistral 7B, prêt à gérer de larges batchs efficacement.

from vllm.engine.arg_utils import AsyncEngineArgs
from vllm.engine.async_llm_engine import AsyncLLMEngine

# Configuration du moteur
engine_args = AsyncEngineArgs(
    model='mistralai/Mistral-7B-Instruct-v0.1',
    # max_num_seqs: nombre de requêtes simultanées que le moteur peut gérer
    max_num_seqs=256,
    # max_model_len: contexte maximal supporté
    max_model_len=8192,
    # gpu_memory_utilization: % de VRAM à allouer au KV Cache
    gpu_memory_utilization=0.90
)

engine = AsyncLLMEngine.from_engine_args(engine_args)

# Le moteur peut maintenant être intégré dans un serveur web (ex: FastAPI)
# pour servir des requêtes d'inférence à haute performance.

Playbook de Déploiement

1. Étape 1 : Implémenter le Cache d'Artefacts. C'est le plus rentable. Si vous avez un pipeline RAG, mettez en cache le résultat de l'étape de distillation/compression. La clé de cache doit être un hash de `(user_query, sorted(list_of_doc_ids))`.
2. Étape 2 : Ajouter un Cache Sémantique pour les requêtes sans RAG. Pour les cas d'usage conversationnels ou Q&A simples, un cache sémantique peut grandement réduire le nombre d'appels LLM pour les questions récurrentes. Fixez un seuil de similarité strict (ex: 0.95) pour commencer.
3. Étape 3 (Auto-hébergement) : Utiliser un Serveur d'Inférence moderne. N'essayez pas de réinventer la roue. Pour l'hébergement de modèles open-source, utilisez des serveurs comme **vLLM** ou **Text Generation Inference (TGI)**. Ils implémentent PagedAttention et d'autres optimisations de pointe "out-of-the-box".
4. Étape 4 : Benchmarker votre système. Mesurez le TTFT et le TPOT de votre serveur d'inférence avec différentes longueurs de prompt et tailles de batch. Cela vous donnera une compréhension claire des limites de performance de votre infrastructure.
5. Étape 5 : Ne pas négliger la gestion de fenêtre. Pour les conversations très longues, ne vous fiez pas uniquement à une fenêtre de contexte native. Implémentez une stratégie de gestion de mémoire de session (ex: résumé + fenêtre glissante) au niveau applicatif pour garantir la robustesse.