Stratégie de compression du contexte sur 5 niveaux

Aperçu

Dans les scénarios de conversations longues, le nombre de tokens du contexte se rapproche progressivement de la limite de la fenêtre de contexte du modèle. Le système adopte une approche en cascade reposant sur une architecture à trois couches et cinq stratégies de compression, qui gère intelligemment la longueur du contexte tout en garantissant la qualité de la conversation.

Vue d'ensemble des stratégies

Layer 1 : troncature préventive des résultats d'outils

Moment de déclenchement : exécuté automatiquement avant chaque appel LLM (de manière préventive, sans attendre qu'un dépassement se produise).

Stratégie ① — Troncature d'un seul résultat d'outil

Lorsqu'un résultat d'outil unique dépasse 50 % de la fenêtre de contexte, il est tronqué au budget :

                      
                      Sortie d'outil brute (trop longue)
│
├── Conservation des N premiers caractères (point de coupure sur un saut de ligne)
└── Ajout d'un marqueur : [truncated: output exceeded context limit]

                    

Constante clé :

• SINGLE_TOOL_RESULT_CONTEXT_SHARE = 0.5 (part maximale pour un seul outil)

Stratégie ② — Compactage des anciens résultats d'outils

Lorsque l'entrée totale dépasse 75 % de la fenêtre de contexte, le compactage commence par les résultats d'outils les plus anciens :

                      
                      Historique des appels d'outils (série chronologique)
│
├── Résultats d'outils les plus récents → contenu intégral conservé
├── Résultats d'outils plus récents → contenu intégral conservé
├── Résultats d'outils plus anciens → [compacted: tool output removed to free context]
└── Résultats d'outils les plus anciens → [compacted: tool output removed to free context]

                    

Mécanisme de liste blanche : le compactage n'est appliqué qu'aux outils à sortie volumineuse suivants :

• Read File, Bash, Grep, Glob, Search Files, Web Fetch, Edit

Les sorties des outils de type Write/Create sont toujours conservées, car elles servent de base aux opérations ultérieures.

Constante clé :

• CONTEXT_INPUT_HEADROOM_RATIO = 0.75 (part maximale de l'entrée totale)

Layer 2 : détection des dépassements et élagage de l'historique des messages

Moment de déclenchement : déclenché de manière passive lorsque le LLM renvoie une erreur de dépassement du contexte.

Stratégie ③ — Élagage de l'historique des messages

Élagage des messages intermédiaires de l'historique, tout en conservant les messages clés :

                      
                      Historique des messages
│
├── System Prompt                    ← toujours conservé
├── Premier message utilisateur       ← toujours conservé
├── Messages avec _pin: true          ← toujours conservés
├── ........ historique intermédiaire ........       ← élagué (remplacé par une notification)
├── [context compacted: X earlier messages removed]
├── N messages les plus récents        ← conservés (N = min(6, ⌊total/3⌋))
└── Message actuel                     ← conservé

                    

Après l'élagage, les paires d'outils orphelines (un tool_use sans tool_result correspondant, ou inversement) sont automatiquement réparées afin de garantir la validité du format des messages.

Layer 3 : résumé intelligent par LLM

Moment de déclenchement : déclenché lorsque l'élagage de la Layer 2 ne suffit toujours pas à soulager la pression sur le contexte.

Stratégie ④ — Résumé complet

Un appel LLM dédié est utilisé pour produire un résumé structuré des messages de l'historique :

Format de résumé en 9 sections :

1. Intention et objectifs de l'utilisateur
2. Concepts et terminologie clés
3. Fichiers et chemins concernés
4. Erreurs rencontrées et solutions
5. Démarche de résolution des problèmes
6. Messages clés de l'utilisateur
7. Tâches à accomplir
8. Progression actuelle du travail
9. Prochaines étapes

Stratégie de découpage : lorsque les messages dépassent 50 000 caractères, ils sont divisés en 4 blocs au maximum, résumés séparément, puis fusionnés en un résumé final.

Stratégie ⑤ — Dégradation vers un résumé partiel

Lorsque le résumé complet échoue, une dégradation à trois niveaux est appliquée :

Récapitulatif des constantes clés

Calibrage EMA des tokens

Le système utilise une moyenne mobile exponentielle pour calibrer dynamiquement l'estimation du nombre de caractères par token :

Diagramme du flux de compression

                      
                      Avant chaque appel LLM
    │
    ├── Layer 1: enforceToolResultBudget()
    │   ├── Troncature d'un seul outil (>50 % du contexte)
    │   └── Compactage des anciens outils (entrée totale >75 % du contexte)
    │
    ├── shouldPreemptiveCompact() ?
    │   └── Oui → compact() (élagage Layer 2)
    │
    └── Appel LLM
        │
        ├── Succès → poursuite
        └── Erreur de dépassement → getRetryStrategy()
            │
            ├── compact() (Layer 2)
            │   │
            │   └── Toujours insuffisant → compactWithSummary() (Layer 3)
            │       ├── summarizeMessagesFull() (stratégie ④)
            │       ├── Échec → summarizeMessagesPartial() (stratégie ⑤ Level 1-2)
            │       └── Échec total → bare notice (stratégie ⑤ Level 3)
            │
            └── Nouvelle tentative d'appel LLM (5 fois au maximum)

                    

Ce que cela signifie pour vous

La compression du contexte est la raison du phénomène « l'Agent a oublié le contenu précédent » que vous pouvez ressentir dans les conversations longues. Ce n'est pas un bug, mais un mécanisme par lequel le système gère intelligemment l'information dans une fenêtre de contexte limitée.

Phénomènes que vous pouvez observer :

• Dans une longue conversation, l'Agent « ne se souvient » soudainement plus du besoin que vous aviez mentionné au début → c'est que la Layer 2/3 a compressé les premiers messages
• L'Agent dit « d'après la discussion précédente... » mais les détails peuvent ne pas être tout à fait exacts → seul le résumé a été conservé après la compression
• Les résultats historiques des appels d'outils deviennent [compacted] → c'est que la Layer 1 a compacté les anciennes sorties d'outils

Comment y faire face :

• Dites « merci de retenir » pour les informations clés : cela déclenche le stockage par le système de mémoire, à l'abri de la compression du contexte
• Reformulez les besoins essentiels : dans une longue conversation, reformulez périodiquement vos besoins fondamentaux
• Choisissez un modèle à grand contexte : GPT-4.1 (1M) ou Claude (200K) conservent davantage de contexte que DeepSeek (64K)
• Ouvrez une nouvelle conversation : si la conversation est déjà très longue et confuse, ouvrir une nouvelle conversation peut être plus efficace que de la poursuivre

Documents connexes

• Moteur de boucle de l'Agent — la place de la gestion du contexte dans la boucle
• Configuration des modèles — la taille de la fenêtre de contexte de chaque modèle
• Liste des modèles pris en charge — matrice des capacités des modèles