La fenêtre de contexte est la quantité maximale de tokens qu’un modèle peut prendre en compte pendant une requête. Un token n’est pas exactement un mot : il peut représenter un morceau de mot, un mot court, de la ponctuation ou un espace selon le tokenizer. Dire “128k tokens” ne signifie donc pas “128k mots”.
Repère documentaire : documentation officielle du fonctionnement présenté.
Budget entrée/sortie
Le budget total peut inclure l’entrée et la sortie. Exemple fictif : si un modèle accepte 8 000 tokens et que votre prompt, documents et historique consomment 6 500 tokens, il ne reste pas automatiquement 8 000 tokens pour répondre. Selon l’API et les réglages, vous devrez réserver une sortie maximale, par exemple 1 000 tokens, et garder une marge. Les limites peuvent varier selon moteur, modèle, endpoint et paramètres applicatifs.
Troncature ou erreur
Quand le contexte dépasse, le comportement n’est pas universel. Certains systèmes renvoient une erreur, d’autres tronquent, d’autres résument ou suppriment une partie de l’historique côté application. Il faut lire le comportement de l’outil utilisé. Une troncature silencieuse est dangereuse : le modèle peut répondre avec assurance alors qu’une source importante a disparu.
Mémoire applicative ≠ contexte modèle
Une application peut avoir une “mémoire” longue durée : base de données, historique utilisateur, profil, documents. Le modèle ne voit pas tout cela par magie. À chaque requête, l’application choisit ce qu’elle remet dans la fenêtre de contexte. Une mauvaise sélection de mémoire peut coûter cher et dégrader la réponse.
Long contexte ne garantit pas bonne qualité
Un modèle peut accepter beaucoup de tokens et tout de même rater une information au milieu, confondre deux sections ou privilégier la fin. Pour un gros dossier, structurez : sommaire, citations, extraits pertinents, consigne de priorité, noms de fichiers. Tester “tout coller” est utile pour un prototype, mais une production doit mesurer la précision sur des questions de contrôle.
Décision pratique
- Pour un chat court : historique récent + résumé suffisent souvent.
- Pour un audit documentaire : retrieval ciblé et citations valent mieux qu’un dump.
- Pour du code : fichiers pertinents, tests et erreurs exactes en priorité.
- Pour un agent : réserver du contexte aux observations d’outils et aux décisions.
La fenêtre de contexte est donc une ressource à budgéter. Plus elle est grande, plus elle offre de possibilités, mais elle ne remplace ni la sélection d’information ni la vérification.
Exemple de découpage fictif
Imaginez un audit de 20 000 tokens alors que votre budget utile est de 8 000. Vous pouvez envoyer un résumé global de 1 000 tokens, trois extraits prioritaires de 1 500 tokens chacun, 500 tokens de consignes et garder 2 000 tokens de sortie. Ce découpage fictif montre qu’il faut choisir, pas seulement compresser au hasard.
Risque des historiques de chat
Un historique trop long peut contenir d’anciennes décisions devenues fausses. Si l’application réinjecte tout, le modèle peut suivre une consigne périmée. Mieux vaut maintenir un résumé vivant avec date, décisions actives et éléments annulés, puis joindre les sources actuelles quand la précision compte.
Contrôle de couverture
Quand vous résumez un long dossier, posez quelques questions dont vous connaissez la réponse et qui se trouvent à différents endroits du document. Si le modèle réussit seulement le début et la fin, le problème vient peut-être de la sélection ou de l’exploitation du contexte.
Pour les bases : définition d’un modèle de langage.
