Compression de contexte
La compression de contexte réduit les tokens fournis à un modèle lors de chaque appel tout en préservant les informations dont il a réellement besoin pour agir. Utilisez-la sur des agents à exécution longue et des conversations prolongées pour réduire les coûts et la latence, et pour rester dans les limites de la fenêtre de contexte. Les trois leviers sont le résumé de l'historique, l'élagage du contexte non pertinent et la compression des prompts. Le risque principal est la perte d'informations : omettre le seul détail qui importait. Mesurez les informations conservées, et pas seulement les tokens économisés.
Problème
Les agents à exécution longue et les conversations multi-tours accumulent du contexte : chaque résultat d'outil, message précédent et document récupéré est rejoué lors de l'appel suivant. Le nombre de tokens augmente de manière quasi linéaire avec l'interaction, de sorte que le coût par appel et la latence grimpent, et le fenêtrage finit par déborder, tronquant silencieusement le contenu le plus ancien (parfois le plus important). Les corrections naïves — fenêtres plus grandes, troncature plus agressive — augmentent les coûts ou détruisent les informations dont le modèle a besoin pour rester cohérent.
Quand l'utiliser
S'applique lorsque le contexte croît de manière illimitée par rapport aux besoins d'une seule étape : assistants conversationnels avec de longs historiques, agents autonomes bouclant sur de nombreux appels d'outils, pipelines RAG qui récupèrent trop d'informations, et tâches par lots où la taille du prompt domine le coût. Cela convient lorsque la majeure partie du contexte accumulé est redondante ou obsolète, lorsque vous contrôlez l'assemblage du prompt et lorsque vous pouvez tolérer une certaine erreur de reconstruction. Cela ne convient pas lorsque chaque token est crucial (tâches juridiques, d'audit ou de rappel exact) ou lorsque les interactions sont suffisamment courtes pour que la fenêtre ne soit jamais sous pression.
Solution
Traisez le contexte actif comme un budget que vous gérez activement plutôt que comme un journal en ajout uniquement. Il existe trois leviers complémentaires. La synthèse remplace une partie de l'historique par un synopsis plus court — généralement un résumé glissant des échanges plus anciens, actualisé périodiquement, tandis que les échanges récents restent textuels. L'élagage supprime le contexte non pertinent pour l'étape en cours : dédupliquez, supprimez les sorties d'outils obsolètes et sélectionnez uniquement les fragments récupérés dont le score est supérieur à un seuil de pertinence. La compression de prompt (par exemple LLMLingua) utilise un modèle plus petit pour supprimer ou reformuler les tokens à faible valeur informative avant d'envoyer le prompt, troquant une légère perte de précision contre d'importantes réductions de tokens.\n\nComposez ces éléments dans un pipeline aux limites explicites : conservez une fenêtre récente textuelle, un résumé glissant de l'historique plus ancien et un emplacement de récupération rempli à la demande. Protégez une zone « épinglée » pour les faits qui ne doivent jamais être compressés — identifiants, contraintes, objectif actuel. Surtout, instrumentez le résultat : exécutez un ensemble d'évaluations comparant les réponses avec et sans compression afin de détecter toute dégradation de la qualité, et ajustez l'agressivité par charge de travail plutôt que de manière globale. La compression est un curseur entre qualité et coût, pas un gain gratuit.
Composants
Avantages
- L'envoi de moins de tokens réduit directement le coût d'entrée de chaque appel, ce qui se cumule sur les longues boucles d'agents et le trafic à haut volume.
- Des prompts plus petits signifient moins d'encodage et un délai d'obtention du premier token plus court, ce qui améliore la réactivité dans les flux interactifs et d'agents.
- Limiter le contexte actif permet aux longues conversations et aux agents multi-étapes de se poursuivre sans déborder de la fenêtre ni subir de troncature silencieuse.
- La suppression du contexte redondant et obsolète peut améliorer la qualité en réduisant les distractions, aidant ainsi le modèle à se concentrer sur ce qui importe actuellement.
Risques
- Les résumés et l'élagage peuvent écarter le détail unique qui s'avérera plus tard décisif, produisant des réponses erronées formulées avec assurance.
- Les résumés glissants synthétisent des résumés antérieurs ; de petites omissions se cumulent au fil des cycles jusqu'à ce que le fil de la conversation dérive discrètement.
- L'exécution d'un synthétiseur ou d'un compresseur ajoute sa propre latence, son coût et sa surface de défaillance, ce qui peut annuler les économies réalisées sur les interactions courtes.
- Une éviction agressive peut supprimer silencieusement des contraintes ou des instructions dont le modèle dépend encore, sans signal d'erreur évident.
Quand ne pas l'utiliser
- Lorsque chaque token est crucial — affaires juridiques, audit, conformité ou extraction précise de données —, une compression avec perte est inacceptable.
- Si les conversations mettent rarement la fenêtre sous pression, le surcoût de la compression dépasse les économies réalisées et ajoute une complexité inutile.
- Sans un harness d'évaluation de la rétention, ne déployez rien : vous ne pouvez pas savoir si la compression dégrade silencieusement les réponses.
Technologies
Exemples
- Un agent itérant sur une base de code volumineuse conserve une fenêtre récente textuelle ainsi qu'un résumé glissant des étapes précédentes, en épinglant la spécification de la tâche et les chemins de fichiers afin de ne pas perdre de vue l'objectif.
- Un bot de support multi-session synthétise les échanges précédents en un résumé de dossier compact, élaguant les sous-problèmes résolus tout en épinglant les contraintes du compte client.
- Un pipeline de récupération qui extrait de nombreux fragments applique un élagage par pertinence et une compression de prompt pour n'envoyer que les passages à fort signal, réduisant les tokens sans perdre la réponse.
Preuves de production
- Contexte
- Déploiement OpenClaw mono-opérateur, local-first, observé sur 57 jours (161 sessions / 2 776 tours), agrégé à partir des traces de trajectoire propres à l'agent.
- Scénario
- Les longs transcriptions autonomes sont compactées de manière préventive et les résultats des outils sont tronqués pour respecter le budget du prompt.
- Technologie
- Compactage préventif avec marge de sécurité, troncature des résultats d'outils, hook d'élagage de contexte et pré-vérification de dépassement en milieu de tour.
- Charge
- 2 810 événements compilés par contexte sur 2 776 tours en 57 jours.
- Résultats
- Le compactage s'est exécuté en ligne tout au long de la fenêtre, maintenant les tours autonomes multi-étapes dans le budget (p95 87,6 s par tour) sans qu'aucune défaillance par dépassement de contexte ne survienne. Déploiement mono-opérateur local-first.
KPI
- Tokens par appel (entrée)
- Le principal facteur de coût. Suivez la distribution avant et après compression ; un résultat sain se traduit par une réduction nette sans augmentation des erreurs en aval.
- Rétention de l'information / qualité de la tâche
- Comparez les réponses avec et sans compression sur un ensemble d'évaluation. Un bon résultat montre une qualité stable dans vos limites de tolérance à mesure que les tokens diminuent.
- Latence de bout en bout
- Nette du surcoût de compression. Un bon résultat est une latence totale plus faible ; veillez à ce que les appels au synthétiseur ou au compresseur n'annulent pas les économies.
- Taux de dépassement de contexte / de troncature
- Fréquence à laquelle les interactions atteignent la limite de la fenêtre. Un bon résultat consiste à ramener ce taux vers zéro sans avoir à abandonner le contenu épinglé.
Modes de défaillance observés
- Un résumé omet une contrainte mentionnée au début ; de nombreux tours plus tard, l'agent la viole car ce fait a tout simplement disparu du contexte.
- La re-synthétisation répétée amplifie les erreurs de paraphrase et les omissions jusqu'à ce que le résumé glissant ne reflète plus ce qui s'est réellement passé.
- Un budget mal configuré compresse des identifiants ou des instructions qui devaient être protégés, rompant silencieusement l'exactitude.
- Un seuil de pertinence agressif filtre un contexte important pour un cas limite, de sorte que la qualité semble correcte lors des tests mais échoue en production.
Leçons apprises
- Maximiser la réduction des tokens est trivial et n'a aucun sens en soi ; la véritable métrique est de savoir si le modèle répond toujours correctement.
- Protégez explicitement les identifiants, les contraintes et l'objectif actuel afin qu'aucune étape de compression ne puisse les évincer.
- Compressez l'historique ancien, pas le contexte actif ; les échanges les plus récents portent le signal le plus pertinent pour la décision.
- Ajustez l'agressivité par charge de travail par rapport à un ensemble d'évaluation ; ce qui est sûr pour du bavardage est imprudent pour une tâche d'audit.
FAQ
- En quoi cela diffère-t-il de la mémoire à long terme ?
- La mémoire à long terme conserve les faits en dehors du prompt et les récupère à la demande ; la compression de contexte réduit le contexte actif envoyé à chaque appel. Elles sont complémentaires : la mémoire décide de ce qu'il faut ramener, la compression décide de la compacité de son intégration dans la fenêtre.
- Synthétiser, élaguer ou compresser — que dois-je utiliser ?
- Élaguez d'abord (gratuit, sans perte lors de la suppression d'une réelle redondance), synthétisez l'historique plus ancien lorsqu'il croît de manière illimitée, et n'ajoutez la compression de prompt que si vous avez encore besoin de marge et pouvez valider le coût en qualité. La plupart des systèmes combinent les trois.
- Comment savoir si la compression nuit à la qualité ?
- Exécutez un ensemble d'évaluation avec et sans compression et comparez les résultats des tâches, pas seulement le nombre de tokens. Surveillez les réponses erronées formulées avec assurance et les contraintes abandonnées — ce sont les signatures d'une compression avec perte qui est allée trop loin.