Quand on parle de LLM, le "contexte" c'est l'ensemble de ce qu'on envoie au modèle à chaque appel : le system prompt, l'historique de conversation, les documents récupérés via RAG, les résultats d'outils, les instructions métier. Tout ça forme la fenêtre de contexte, le seul espace mémoire que le modèle possède au moment de générer sa réponse.
Un modèle comme GPT-4o ou Claude 3.5 accepte aujourd'hui des fenêtres de 128K à 200K tokens. En théorie, beaucoup d'espace. En pratique, ça donne l'illusion qu'on peut tout mettre dedans sans conséquences. C'est là où ça coince.
Le contexte, c'est quoi exactement ?
La fenêtre de contexte agrège toutes les sources d'information disponibles : system prompt avec les instructions métier, historique de la conversation en cours, chunks récupérés via la recherche vectorielle (RAG), et résultats d'outils (API, SQL, fonctions). Le modèle génère sa réponse uniquement à partir de ce qu'il reçoit dans cette fenêtre.
Sa qualité détermine directement la qualité de l'output. Pas la taille du modèle. Pas le nombre de paramètres. La qualité du contexte.
Context bloat : quand plus devient moins
Le context bloat, c'est l'accumulation non maîtrisée d'information dans la fenêtre de contexte. Ça arrive naturellement, progressivement, souvent sans qu'on s'en rende compte.
Historique de conversation non purgé. Une session de chatbot accumule 30 échanges depuis le début. Les premiers messages ne sont plus pertinents, mais ils restent là, occupent des tokens, et diluent le signal utile.
RAG trop généreux. Le pipeline récupère les 10 chunks les plus proches sémantiquement, même quand 3 suffiraient. Résultat : le modèle reçoit des informations contradictoires ou redondantes, et la réponse se noie dans la masse.
System prompts qui grossissent. Au fil des itérations, l'équipe produit ajoute des règles, des exemples, des exceptions. Le prompt passe de 200 tokens à 3 000. Chaque ajout semble justifié. L'ensemble devient ingérable.
Résultats d'outils verbeux. Un appel API retourne un JSON de 2 000 tokens, dont 1 800 ne sont pas utiles pour la tâche. Tout est injecté quand même parce que personne n'a pris le temps de filtrer.
Des études empiriques sur GPT-4 montrent que la précision de récupération d'information chute significativement quand les éléments pertinents sont noyés dans un contexte large. C'est le lost in the middle : le modèle traite mieux ce qui apparaît en début ou en fin de contexte. Tout ce qui se trouve au milieu est souvent ignoré.
L'amélioration continue du contexte, en pratique
Ce n'est pas un problème qu'on règle une fois au démarrage du projet. C'est une discipline opérationnelle, au même titre que le monitoring des performances ou la gestion des dépendances.
Audit régulier du system prompt. Prendre le prompt de production, identifier chaque bloc d'instructions, et se poser la question : est-ce que cette règle est encore nécessaire ? Un bon prompt fait 400 à 800 tokens bien construits, pas 3 000 tokens en désordre.
Compression active de l'historique. Plutôt que de couper brutalement l'historique au-delà d'une certaine longueur, on peut demander au modèle lui-même de produire un résumé structuré des échanges passés. Ce résumé remplace les 20 derniers messages verbeux. On conserve la mémoire, on réduit le bruit.
Sélection rigoureuse dans les pipelines RAG. Le nombre de chunks récupérés doit être calibré dynamiquement selon la complexité de la requête, pas fixé à 5 ou 10 par défaut. Un reranker (Cohere, BGE Reranker) permet de ne garder que les chunks vraiment pertinents. Et la pertinence se mesure, ce n'est pas une intuition.
Nettoyage des résultats d'outils. Avant d'injecter un résultat d'API ou de requête SQL dans le contexte, une étape de transformation doit extraire uniquement ce qui est utile pour la tâche en cours. C'est du travail d'ingénierie, pas du prompt engineering.
Métriques de contexte en production. Suivre l'évolution du ratio tokens utiles / tokens totaux. Tracker la distribution de la taille des contextes sur les appels réels. Si la moyenne monte sans raison fonctionnelle, c'est un signal d'alarme.
Ce que ça coûte de ne rien faire
Les conséquences du context bloat ne sont pas abstraites.
| Dimension | Contexte non maîtrisé | Contexte optimisé |
|---|---|---|
| Coût d'inférence | x2 à x4 (chaque token input/output est facturé) | Prévisible, ratio token utile maîtrisé |
| Latence | +800ms à 2s, prefill plus long sur contexte large | Stable, temps de réponse prévisible |
| Qualité output | Dégradation progressive, variance élevée sur les cas complexes | Stable, moins de variance sur les cas limites |
| Hallucinations | Risque élevé, contradictions internes non détectées | Réduit, contexte cohérent, moins de conflits |
| Maintenabilité | Difficile, prompts de 3K tokens illisibles | Maîtrisée, chaque paramètre devient un levier de pilotage |
Pourquoi c'est ignoré
La réponse honnête : parce que le système fonctionne quand même. Pas parfaitement, mais assez bien pour que personne ne tire la sonnette d'alarme.
Le context bloat est un problème de dégradation progressive, pas de panne franche. Il n'y a pas d'alerte dans les logs. Pas d'exception levée. Les réponses restent générées, les utilisateurs continuent à utiliser le système. La qualité baisse lentement, sans signal clair.
C'est aussi un problème qui nécessite d'avoir pensé à l'évaluation en amont. Si vous n'avez pas de baseline de qualité définie, des cas de test, des métriques d'output, vous ne pouvez pas détecter une régression. Dans la majorité des projets qu'on voit, cette baseline n'existe pas au moment de passer en production.
Ce qui change quand on le traite sérieusement
Gérer le contexte comme un actif à optimiser en continu, c'est une posture qui change plusieurs choses.
D'abord, les coûts d'inférence deviennent prévisibles et maîtrisés. On sait ce qu'on paie et pourquoi. On peut faire des arbitrages éclairés entre qualité, latence et coût. Ensuite, la qualité des outputs est plus stable. Moins de variance, moins de cas limites qui se comportent bizarrement.
Et surtout, les équipes reprennent le contrôle. Au lieu de subir des dégradations incompréhensibles, elles ont des leviers concrets : la taille du prompt, le nombre de chunks RAG, la politique de compression de l'historique. Ces paramètres deviennent des variables de pilotage, pas des constantes figées depuis le premier déploiement.
Le contexte d'un LLM n'est pas un détail d'implémentation. C'est le principal levier de qualité et de coût d'un système IA en production. Le laisser grossir sans contrôle parce que "ça marche quand même", c'est accepter une dégradation lente et coûteuse. Ce n'est pas un problème de modèle. C'est un problème d'ingénierie opérationnelle.