Comprendre · IA
Gérer la fenêtre de contexte d’un agent IA
Tokens, dégradation sur un long contexte, compaction, sous-agents, chargement à la demande et cache de prompt : garder un agent précis sur une longue session.
Jetons et fenêtre de contexte
Un modèle ne lit pas des mots mais des jetons (tokens) : des fragments de texte d’environ quatre caractères en anglais, un peu moins en français, et souvent moins encore pour du code. La fenêtre de contexte est le nombre maximal de jetons que le modèle peut prendre en compte en une fois : consignes, historique, fichiers lus et réponse comprise.
Un agent est sans mémoire : à chaque tour, le harness renvoie au modèle l’ensemble de la conversation. Chaque fichier lu, chaque sortie de commande reste dans le contexte et se repaye à chaque tour suivant.
Plus long n’est pas meilleur
Les fenêtres actuelles comptent des centaines de milliers de jetons, parfois un million. Mais la précision ne reste pas constante : plus le contexte contient d’informations sans rapport avec la tâche, plus le modèle risque de se tromper de détail, d’oublier une consigne donnée au début ou de mélanger deux fichiers.
Le bon objectif n’est donc pas de remplir la fenêtre, mais d’y mettre le minimum utile : ce qui sert à la tâche en cours, et rien d’autre.
Ce qui remplit le contexte
- Les sorties de commandes : un log complet, un
git log -pou une suite de tests verbeuse peuvent coûter des dizaines de milliers de jetons. - Les fichiers lus en entier alors qu’une fonction suffisait.
- Les instructions permanentes trop longues, chargées à chaque session.
- Les tâches successives sans rapport dans une même session.
# Coûteux : toute la sortie entre dans le contexte, et y reste jusqu'à la fin de la session.
cat logs/application.log
git log -p
# Économe : seul ce qui sert à la décision entre dans le contexte.
grep -n "ERROR" logs/application.log | tail -20
git log --oneline -n 10 -- src/Service/Facturation.phpLes techniques d’économie
| Technique | Principe |
|---|---|
| Chargement à la demande | Seuls le nom et la description des skills sont permanents ; le contenu arrive quand il sert. |
| Lecture ciblée | Chercher d’abord (grep, recherche de symbole), puis lire la plage de lignes utile. |
| Sous-agents | Une exploration volumineuse se fait dans un contexte séparé ; seule la conclusion revient dans la conversation principale. |
| Compaction | Quand la fenêtre se remplit, le harness remplace l’historique par un résumé. Utile, mais des détails se perdent : mieux vaut ne pas en arriver là. |
| Nouvelle session | Un nouveau sujet, une nouvelle session. L’état à conserver va dans un fichier (plan, notes), pas dans l’historique. |
| Plans écrits | Pour une tâche longue, un plan en Markdown avec des cases à cocher sert de mémoire externe, relisible après une compaction ou le lendemain. |
Le cache de prompt
Puisque chaque tour renvoie tout l’historique, les fournisseurs d’API proposent un cache de prompt : le début de la requête, identique d’un tour à l’autre (consignes, outils, messages précédents), est facturé bien moins cher et traité plus vite s’il a déjà été vu récemment.
Le cache ne fonctionne que sur un préfixe exact. Modifier les consignes système au milieu d’une session, ou réordonner les outils, l’invalide. C’est une raison de plus pour garder des instructions stables et de placer ce qui change (la demande du moment) à la fin.
Une routine de travail
- Des instructions permanentes courtes, qui renvoient vers des skills et des documents.
- Une tâche par session ; un plan écrit dès qu’elle dépasse quelques étapes.
- Des commandes à la sortie bornée, des lectures ciblées.
- Les explorations larges confiées à un sous-agent.
- Une session qui dérive (réponses imprécises, consignes oubliées) se termine : on note l’état dans le plan et on repart d’un contexte propre.