Compression-de-contexte

Stratégies de Compression de Contexte

Lorsque les sessions d'agent génèrent des millions de jetons d'historique de conversation, la compression devient obligatoire. L'approche naïve est une compression agressive pour minimiser les jetons par requête. Le bon objectif d'optimisation est les jetons par tâche : le total des jetons consommés pour accomplir une tâche, y compris les coûts de récupération lorsque la compression perd des informations critiques.

Quand Activer

Activez cette compétence lorsque :

• Les sessions d'agent dépassent les limites de la fenêtre de contexte
• Les bases de code dépassent les fenêtres de contexte (systèmes de 5M+ jetons)
• Vous concevez des stratégies de résumé de conversation
• Vous déboguez des cas où les agents « oublient » les fichiers qu'ils ont modifiés
• Vous construisez des cadres d'évaluation pour la qualité de la compression
• Vous créez des résumés de passation durables qui préservent les décisions, les fichiers, les risques et les actions suivantes

N'activez pas cette compétence pour les travaux adjacents pris en charge par d'autres compétences :

• Tactiques générales d'optimisation des jetons telles que le masquage, la mise en cache de préfixes ou le partitionnement : context-optimization.
• Diagnostiquer pourquoi un long contexte échoue avant de choisir une atténuation : context-degradation.
• Écrire des sorties brutes, des journaux ou des plans dans des fichiers sans les résumer : filesystem-context.
• Concevoir une mémoire sémantique à long terme entre les sessions : memory-systems.
• Le modèle qui décide quand et où réécrire son propre contexte : self-managed-context. Cette compétence définit toujours ce que le texte de remplacement doit préserver.

Concepts Fondamentaux

La compression de contexte échange des économies de jetons contre une perte d'informations. Choisissez parmi trois approches prêtes pour la production en fonction des caractéristiques de la session :

1. Résumé Itératif Ancrée : Implémentez ceci pour les sessions longues où le suivi des fichiers est important. Maintenez des résumés structurés et persistants avec des sections explicites pour l'intention de la session, les modifications de fichiers, les décisions et les prochaines étapes. Lorsque la compression se déclenche, résumez uniquement la portion nouvellement tronquée et fusionnez-la avec le résumé existant plutôt que de le régénérer à partir de zéro. Cela évite la dérive qui s'accumule lorsque les résumés sont régénérés en bloc — chaque régénération risque de perdre des détails que le modèle considère comme de faible priorité mais que la tâche exige. La structure force la préservation car les sections dédiées agissent comme des listes de contrôle que le résumeur doit remplir, capturant ainsi la perte silencieuse d'informations.

2. Compression Opaque : Réservez ceci pour les sessions courtes où les coûts de récupération sont faibles et où des économies de jetons maximales sont requises. Elle produit des représentations compressées optimisées pour la fidélité de reconstruction, atteignant des taux de compression de 99%+ mais sacrifiant totalement l'interprétabilité. Le compromis est important : il n'y a aucun moyen de vérifier ce qui a été préservé sans évaluation par sondes, donc ne l'utilisez jamais lorsque le débogage ou le suivi des artefacts est critique.

3. Résumé Régénératif Complet : Utilisez ceci lorsque la lisibilité du résumé est critique et que les sessions ont des limites de phases claires. Il génère des résumés structurés détaillés à chaque déclencheur de compression. La faiblesse est la perte cumulative de détails sur des cycles répétés — chaque régénération complète est un nouveau passage qui peut déprioriser les détails préservés dans les résumés antérieurs.

Sujets Détaillés

Optimiser pour les Jetons-Par-Tâche, Pas les Jetons-Par-Requête

Mesurez le total des jetons consommés du début à la fin de la tâche, pas les jetons par requête individuelle. Lorsque la compression supprime les chemins de fichiers, les messages d'erreur ou la justification des décisions, l'agent doit ré-explorer, relire les fichiers et redériver les conclusions — gaspillant beaucoup plus de jetons que la compression n'en a économisés. Une stratégie qui économise 0,5% de jetons en plus par requête mais qui provoque 20% de récupérations supplémentaires coûte plus cher globalement. Suivez la fréquence de récupération comme signal de qualité principal : si l'agent demande à plusieurs reprises de relire des fichiers déjà traités, la compression est trop agressive.

Résoudre d'Abord le Problème de la Piste d'Artefacts

L'intégrité de la piste d'artefacts est souvent la dimension la plus faible dans les évaluations de compression (claim-context-compression-factory-benchmark). Traitez ce problème de manière proactive car le résumé général ne peut pas le maintenir de manière fiable.

Préservez ces catégories explicitement dans chaque cycle de compression :

• Quels fichiers ont été créés (chemins complets)
• Quels fichiers ont été modifiés et ce qui a changé (incluez les noms de fonctions, pas seulement les noms de fichiers)
• Quels fichiers ont été lus mais non modifiés
• Identifiants spécifiques : noms de fonctions, noms de variables, messages d'erreur, codes d'erreur

Implémentez un index d'artefacts séparé ou un suivi d'état de fichiers explicite dans l'échafaudage de l'agent plutôt que de compter sur le résumeur pour capturer ces détails. Même le résumé structuré avec des sections de fichiers dédiées a du mal à être complet sur de longues sessions.

Structurer les Résumés avec des Sections Obligatoires

Construisez des résumés structurés avec des sections explicites qui empêchent la perte silencieuse d'informations. Chaque section agit comme une liste de contrôle que le résumeur doit remplir, rendant les omissions visibles plutôt que silencieuses.

## Intention de la Session
[Ce que l'utilisateur essaie d'accomplir]

## Fichiers Modifiés
- auth.controller.ts : Correction de la génération de jetons JWT
- config/redis.ts : Mise à jour du regroupement de connexions
- tests/auth.test.ts : Ajout de la configuration simulée pour la nouvelle configuration

## Décisions Prises
- Utilisation d'un pool de connexions Redis au lieu de connexions par requête
- Logique de nouvelle tentative avec backoff exponentiel pour les défaillances transitoires

## État Actuel
- 14 tests réussis, 2 échoués
- Restant : configuration simulée pour les tests du service de session

## Prochaines Étapes
1. Corriger les échecs de test restants
2. Exécuter la suite de tests complète
3. Mettre à jour la documentation

Adaptez les sections au domaine de l'agent. Un agent de débogage a besoin de « Cause Racine » et « Messages d'Erreur » ; un agent de migration a besoin de « Schéma Source » et « Schéma Cible ». La structure importe plus que les sections spécifiques — tout schéma explicite surpasse le résumé libre.

Choisir Stratégiquement les Déclencheurs de Compression

Le moment du déclenchement de la compression importe autant que la méthode de compression. Choisissez une stratégie de déclenchement en fonction de la prévisibilité de la session :

Stratégie	Point de Déclenchement	Compromis
Seuil fixe	70-80% d'utilisation du contexte	Simple mais peut compresser trop tôt
Fenêtre glissante	Conserver les N derniers tours + résumé	Taille de contexte prévisible
Basé sur l'importance	Compresser d'abord les sections de faible pertinence	Complexe mais préserve le signal
Limite de tâche	Compresser aux fins logiques de tâche	Résumés propres mais timing imprévisible

Par défaut, utilisez la fenêtre glissante avec des résumés structurés pour les agents de codage — elle offre le meilleur équilibre entre prévisibilité et qualité. Utilisez les déclencheurs de limite de tâche lorsque les sessions ont des transitions de phase claires (par exemple, recherche puis implémentation puis test).

Évaluer la Compression avec des Sondes, Pas des Métriques

Les métriques traditionnelles comme ROUGE ou la similarité d'intégration échouent à capturer la qualité fonctionnelle de la compression. Un résumé peut obtenir un score élevé de chevauchement lexical tout en manquant le seul chemin de fichier dont l'agent a besoin pour continuer.

Utilisez l'évaluation par sondes : après la compression, posez des questions pour tester si les informations critiques ont survécu. Si l'agent répond correctement, la compression a préservé les bonnes informations. Sinon, il devine ou hallucine.

Type de Sonde	Ce qu'elle Teste	Exemple de question
Rappel	Rétention factuelle	« Quel était le message d'erreur d'origine ? »
Artefact	Suivi des fichiers	« Quels fichiers avons-nous modifiés ? »
Continuation	Planification des tâches	« Que devons-nous faire ensuite ? »
Décision	Chaîne de raisonnement	« Qu'avons-nous décidé concernant le problème Redis ? »

Noter la Compression sur Six Dimensions

Évaluez la qualité de la compression pour les agents de codage sur ces dimensions. La précision et la préservation de la piste d'artefacts ont tendance à mieux séparer les méthodes que la similarité lexicale (claim-context-compression-factory-benchmark), donc la compression nécessite un traitement spécialisé au-delà du résumé général.

1. Précision : Les détails techniques sont-ils corrects — chemins de fichiers, noms de fonctions, codes d'erreur ?
2. Conscience du Contexte : La réponse reflète-t-elle l'état actuel de la conversation ?
3. Piste d'Artefacts : L'agent sait-il quels fichiers ont été lus ou modifiés ?
4. Exhaustivité : La réponse répond-elle à toutes les parties de la question ?
5. Continuité : Le travail peut-il continuer sans récupérer d'informations ?
6. Respect des Instructions : La réponse respecte-t-elle les contraintes énoncées ?

Conseils Pratiques

Appliquer le Flux de Travail de Compression en Trois Phases pour les Grandes Bases de Code

Pour les bases de code ou les systèmes d'agent dépassant les fenêtres de contexte, compressez en trois phases séquentielles. Chaque phase réduit le contexte afin que la phase suivante fonctionne dans les limites du budget.

1. Phase de Recherche : Explorez les diagrammes d'architecture, la documentation et les interfaces clés. Compressez l'exploration en une analyse structurée des composants, dépendances et limites. Résultat : un seul document de recherche qui remplace l'exploration brute.

2. Phase de Planification : Convertissez le document de recherche en un cahier des charges d'implémentation avec des signatures de fonctions, des définitions de types et un flux de données. Une base de code de 5M de jetons se compresse à environ 2 000 mots de spécification à ce stade.

3. Phase d'Implémentation : Exécutez selon le cahier des charges. Le contexte reste concentré sur le cahier des charges plus les fichiers de travail actifs, et non sur l'exploration brute de la base de code. Cette phase a rarement besoin d'une compression supplémentaire car le cahier des charges est déjà compact.

Utiliser des Exemples d'Artefacts comme Graines de Compression

Lorsqu'un exemple de migration manuelle ou une PR de référence est fourni, utilisez-le comme modèle pour comprendre le modèle cible plutôt que d'explorer la base de code à partir de zéro. L'exemple révèle des contraintes que l'analyse statique ne peut pas détecter en surface : quels invariants doivent tenir, quels services se cassent lors des changements et à quoi ressemble une implémentation propre.

Cela est particulièrement important lorsque l'agent ne peut pas distinguer la complexité essentielle (exigences métier) de la complexité accidentelle (solutions de contournement héritées). L'artefact exemple encode cette distinction implicitement, économisant des jetons qui seraient autrement consacrés à une exploration par essais et erreurs.

Implémenter le Résumé Itératif Ancrée Étape par Étape

1. Définissez des sections de résumé explicites correspondant au domaine de l'agent (débogage, migration, développement de fonctionnalités)
2. Lors du premier déclencheur de compression, résumez l'historique tronqué dans ces sections
3. Lors des compressions suivantes, résumez uniquement le contenu nouvellement tronqué — ne re-résumez pas le résumé existant
4. Fusionnez les nouvelles informations dans les sections existantes plutôt que de les régénérer, en dédoublonnant par chemin de fichier et identité de décision
5. Étiquetez les informations provenant de chaque cycle de compression — cela permet le débogage lorsque les résumés dérivent

Choisir la Bonne Approche pour le Profil de Session

Utilisez le résumé itératif ancré lorsque :

• Les sessions sont longues (100+ messages)
• Le suivi des fichiers est important (codage, débogage)
• La vérification des informations préservées est nécessaire

Utilisez la compression opaque lorsque :

• Des économies de jetons maximales sont requises
• Les sessions sont relativement courtes
• Les coûts de récupération sont faibles (par exemple, pas d'accès au système de fichiers nécessaire)

Utilisez les résumés régénératifs lorsque :

• L'interprétabilité du résumé est critique pour l'examen humain
• Les sessions ont des limites de phases claires
• Un examen complet du contexte est acceptable à chaque déclencheur de compression

Calibrer les Taux de Compression par Méthode

Méthode	Taux de Compression	Score de Qualité	Compromis
Itératif Ancrée	98,6%	3,70	Meilleure qualité, compression légèrement inférieure
Régénératif	98,7%	3,44	Bonne qualité, compression modérée
Opaque	99,3%	3,35	Meilleure compression, perte de qualité

Utilisez ces chiffres comme des références spécifiques à la source, pas comme des constantes universelles (claim-context-compression-factory-benchmark). Pour toute tâche où des coûts de récupération existent, ce compromis favorise généralement les approches structurées.

Exemples

Exemple 1 : Compression de Session de Débogage

Contexte d'origine (89 000 jetons, 178 messages) :

• Erreur 401 sur le point de terminaison /api/auth/login
• Traçage via le contrôleur d'authentification, middleware, magasin de sessions
• Trouvé une connexion Redis obsolète
• Correction du regroupement de connexions, ajout de la logique de nouvelle tentative
• 14 tests réussis, 2 échoués

Résumé structuré après compression :

## Intention de la Session
Déboguer l'erreur 401 Non autorisé sur /api/auth/login malgré des informations d'identification valides.

## Cause Racine
Connexion Redis obsolète dans le magasin de sessions. JWT généré correctement mais la session n'a pas pu être persistée.

## Fichiers Modifiés
- auth.controller.ts : Aucune modification (lecture seule)
- middleware/cors.ts : Aucune modification (examiné)
- config/redis.ts : Correction de la configuration du regroupement de connexions
- services/session.service.ts : Ajout de la logique de nouvelle tentative pour les défaillances transitoires
- tests/auth.test.ts : Mise à jour de la configuration simulée

## État des Tests
14 réussis, 2 échoués (problèmes de configuration simulée)

## Prochaines Étapes
1. Corriger les échecs de test restants (simuler le service de session)
2. Exécuter la suite de tests complète
3. Déployer en préproduction

Exemple 2 : Qualité de la Réponse par Sonde

Après compression, demander « Quelle était l'erreur d'origine ? » :

Bonne réponse (résumé structuré) :

« L'erreur d'origine était une réponse 401 Non autorisé du point de terminaison /api/auth/login. Les utilisateurs ont reçu cette erreur avec des informations d'identification valides. La cause racine était une connexion Redis obsolète dans le magasin de sessions. »

Mauvaise réponse (compression agressive) :

« Nous déboguions un problème d'authentification. La connexion échouait. Nous avons corrigé certains problèmes de configuration. »

La réponse structurée préserve le point de terminaison, le code d'erreur et la cause racine. La réponse agressive perd tous les détails techniques.

Directives

1. Optimisez pour les jetons-par-tâche, pas les jetons-par-requête
2. Utilisez des résumés structurés avec des sections explicites pour le suivi des fichiers
3. Déclenchez la compression à 70-80% d'utilisation du contexte
4. Implémentez la fusion incrémentielle plutôt que la régénération complète
5. Testez la qualité de la compression avec une évaluation par sondes
6. Suivez la piste d'artefacts séparément si le suivi des fichiers est critique
7. Acceptez des taux de compression légèrement inférieurs pour une meilleure rétention de la qualité
8. Surveillez la fréquence de récupération comme signal de qualité de la compression

Pièges

1. Ne compressez jamais les définitions ou schémas d'outils : La compression des schémas d'appels de fonction, des spécifications d'API ou des définitions d'outils détruit entièrement la fonctionnalité de l'agent. L'agent ne peut pas invoquer

…

[tronqué pour la traduction]