Le CAG (Cache-Augmented Generation) consiste à charger toute la base de connaissances directement dans le contexte du LLM — pas de retrieval — et à mettre en cache les KV (key-value) côté inférence pour éviter de recalculer à chaque requête. C’est devenu envisageable depuis les modèles à 1M tokens de contexte (Gemini 1.5+, GPT-4.1, Claude 4).
En pratique
Cas typique : la documentation produit complète d’une PME (50k tokens) tient dans le contexte d’un Gemini 2.5. Au lieu d’un RAG :
- On charge toute la doc une fois.
- Le KV cache du modèle est persisté (Anthropic prompt caching, Gemini context caching).
- Chaque requête utilisateur paie ~10 % du prix initial des tokens cachés.
Pas de chunking, pas de vector DB, pas de rerank — pipeline simplifié à l’extrême.
CAG vs RAG
| Critère | CAG | RAG |
|---|---|---|
| Volume max | ~500k tokens utiles (lost-in-the-middle) | illimité |
| Coût marginal/requête | bas (cache) | bas (retrieval) |
| Coût initial | élevé (charge complète) | bas |
| Mise à jour | recharger tout | re-vectoriser le delta |
| Précision sur petit volume | excellente | bonne |
Pourquoi c’est important pour votre projet IA
- Sweet spot CAG : base figée < 200k tokens (FAQ produit, catalogue stable, manuel interne).
- RAG reste indispensable pour les bases mouvantes ou volumineuses (> 500k tokens).
- Souvent : prototype CAG en 2 jours pour valider le besoin, puis RAG si volume explose.
Liens utiles
- RAG — définition
- Context window — définition
- Prompt caching — définition
- Audit IA Kezify — choisir CAG ou RAG pour votre cas.
← Retour au glossaire
#CAG#cache augmented generation#long context#KV cache