Module 5 — Compaction intentionnelle fréquente — Context Engineering — le pack Praktik

Objectif

À la fin de ce module, tu sauras compacter ton contexte à 70% d’utilisation, structurer les résumés, et vérifier qu’aucune info critique n’est perdue.

Pourquoi compacter ?

L’historique de messages grossit silencieusement. Après 20-30 tours, il peut occuper 70-80% de la fenêtre. L’agent ne montre aucun symptôme visible jusqu’à ce que la qualité s’effondre brutalement.

Règle d’or : Compacter à 70-80% d’utilisation. Pas à 90%. Pas quand l’agent commence à délirer.

Les 3 approches de compression

Approche	Ratio	Qualité	Quand l’utiliser
Anchored Iterative	98.6%	3.70/5	Sessions longues, tracking de fichiers
Regenerative	98.7%	3.44/5	Lisibilité humaine, phases claires
Opaque	99.3%	3.35/5	Max de tokens, re-fetching peu coûteux

Source : Factory Research (Dec 2025), évaluation sur 36K messages.

Anchored Iterative Summarization (recommandé)

Principe

Maintenir un résumé structuré persistant. Quand la compaction se déclenche, résumer seulement la partie nouvellement tronquée et la fusionner avec le résumé existant.

Structure obligatoire

## Session Intent
[Ce que l'utilisateur essaie d'accomplir]

## Files Modified
- auth.controller.ts : JWT token generation fix
- config/redis.ts : connection pooling
- tests/auth.test.ts : mock setup

## Decisions Made
- Utiliser Redis connection pool au lieu de per-request
- Retry logic avec exponential backoff

## Current State
- 14 tests passants, 2 échouent
- Reste : mock setup pour session service

## Next Steps
1. Fix remaining test failures
2. Run full test suite
3. Deploy to staging

Étapes

Définir les sections explicites selon le domaine
Au premier trigger, résumer l’historique tronqué dans ces sections
Aux triggers suivants, résumer SEULEMENT le nouveau contenu tronqué
Fusionner avec le résumé existant (pas régénérer)
Taguer la source de chaque info (cycle 1, cycle 2…)

Comment déclencher la compaction

Stratégie par seuil fixe (simple)

if context_tokens / context_limit > 0.75:
    context = compact_context(context)

Stratégie par fenêtre glissante (prévisible)

Garder les N derniers tours + résumé. Taille de contexte constante.

Stratégie par frontière de tâche (propre)

Compacter à la fin de chaque phase logique (research → plan → implement).

Recommandation : Fenêtre glissante + résumé structuré pour les agents de code.

Évaluer la compression avec des probes

Les métriques classiques (ROUGE, similarité d’embedding) échouent à capturer la qualité fonctionnelle. Un résumé peut avoir un bon score lexical tout en manquant le chemin de fichier critique.

Probe-based evaluation : Poser des questions qui testent si l’info critique a survécu.

Type de probe	Ce que ça teste	Exemple
Recall	Rétention factuelle	“Quel était le message d’erreur original ?”
Artifact	Tracking de fichiers	“Quels fichiers avons-nous modifiés ?”
Continuation	Planification	“Que devons-nous faire ensuite ?”
Decision	Chaîne de raisonnement	“Qu’avons-nous décidé sur Redis ?”

Workflow de compaction dans Claude Code

# 1. Vérifier l'utilisation
/claude context

# 2. Si > 75%, demander la compaction
/claude compact

# 3. Vérifier le résumé généré
# Relire les sections Files Modified et Decisions Made

# 4. Continuer avec le résumé comme nouveau contexte

Checklist de validation

Je compacte à 70-80%, pas à 90%+
Mon résumé a des sections explicites (Files, Decisions, State, Next)
Je fusionne incrémentalement, pas je régénère tout
Je teste avec des probes après compaction
Je surveille la fréquence de re-fetching (signe de perte)

Compacter sous pression. → Quand le modèle qui compacte est lui-même sous pression contextuelle (>85%), sa qualité de résumé dégrade. Il omet les objectifs, les contraintes utilisateur, et l’état nuancé. Si tu dois compacter tard, utilise un appel de modèle séparé avec un contexte propre contenant seulement le matériel à résumer.

Prochaine étape

→ Module 6 (Observation masking et KV-cache) pour optimiser avant de compacter