Comprendre la fenêtre de contexte et les tokens
6 min de lecture
Mis à jour le
Comprendre la fenêtre de contexte et les tokens
Diagnostiquer un oubli dans une longue conversation et préparer une reprise vérifiable.
Réponse directe
La fenêtre de contexte est la capacité de travail disponible pour une réponse. Elle est comptée en tokens, pas en messages. Un ancien échange visible à l’écran n’est pas nécessairement présent intégralement dans ce que le modèle reçoit. Vérifie les décisions et leurs références lors d’une reprise ; un résumé utile peut conserver l’essentiel tout en perdant un détail décisif.
Glossary
Termes expliqués ici
Ouvre un terme pour lire sa définition courte, puis poursuis vers sa fiche sourcée si nécessaire.
01
Contexte, token et mémoire ne sont pas synonymes
Un token est une unité utilisée pour représenter le contenu traité par le modèle ; pour du texte, ce peut être un mot ou un fragment. Le découpage dépend du modèle et de la langue. Il n’existe pas de conversion universelle fiable entre pages, mots et tokens.
Le contexte peut contenir les instructions, des messages, des extraits de documents et des résultats d’outils ; la réponse consomme aussi un budget. La mémoire persistante, lorsqu’un produit en propose, conserve des informations entre sessions et doit les rendre accessibles à nouveau. Elle n’est ni la fenêtre de contexte ni une archive garantie de tout le dialogue.
02
Ne conclus pas trop vite à un dépassement
Exemple : après de longs journaux techniques, l’agent reprend une ancienne échéance. Vérifie d’abord la date dans le document de référence et demande à l’agent quel passage il utilise. Une contradiction peut aussi venir d’une source périmée, d’une instruction ambiguë ou d’une mauvaise lecture.
Contre-exemple : une réponse courte et fausse ne prouve pas que la fenêtre était pleine. Cherche un indicateur d’usage, une erreur de limite ou une mention de résumé dans le produit. Sans cette information, la cause reste une hypothèse.
03
Comprends ce qui peut changer en cours de route
Selon le produit, une conversation trop longue peut provoquer un refus de requête, une suppression d’anciens éléments ou une compaction en résumé. La troncature enlève du contenu ; la compaction le remplace par une représentation plus courte qui peut perdre des détails. Une grande fenêtre ne garantit pas que chaque détail soit correctement utilisé.
Consulte la limite et le comportement du modèle réellement sélectionné dans la documentation actuelle. Le quota d’usage du compte, la longueur maximale de sortie et la fenêtre de contexte sont des limites distinctes : un abonnement ou une réponse plus courte ne diagnostique pas à lui seul le problème.
04
Prépare une reprise courte et contrôlable
Conserve dans un document que tu contrôles : objectif actuel, décisions datées, contraintes, fichiers ou liens de référence, travail terminé avec sa preuve, prochaine action et questions ouvertes. Vérifie ce résumé contre les sources avant de l’utiliser dans une nouvelle conversation.
Exemple de reprise : « Échéance retenue : 18 octobre, devis v3 page 2. La date du 12 est abandonnée. Compare seulement les montants ; ne modifie rien. » Fournis le passage nécessaire et demande une reformulation de la contrainte avant de continuer. Cette reformulation contrôle la reprise, sans garantir toutes les réponses suivantes.
- Objectif actuel et prochaine étape : ce que la reprise doit produire.
- Décisions datées et contraintes : ce qui reste valable et ce qui a été remplacé.
- Références et preuves : où retrouver le passage ou le résultat original.
- Questions ouvertes : ce qui doit rester inconnu plutôt que reconstitué.
05
Reprends une seule étape, puis compare
Après la reprise, demande une sortie courte portant sur la prochaine étape, puis compare-la au document de référence. Vérifie particulièrement une ancienne décision remplacée et une contrainte encore active : ce sont des détails qu’un résumé trop vague peut omettre.
Si la même erreur revient malgré le passage fourni, arrête de rallonger l’historique. Isole la contradiction dans une demande courte, vérifie que le fichier est réellement lisible et conserve les deux versions en désaccord. Une nouvelle conversation sans cette clarification ne résout pas la cause.
À conserver
Checklist
- 01La première sortie après reprise a été comparée à une décision et à une contrainte sources.
- 02La source actuelle est identifiée.
- 03Un dépassement supposé est distingué d’un dépassement observé.
- 04Le résumé conserve décisions, contraintes et références.
- 05Les extraits nécessaires sont accessibles dans la reprise.
- 06Une décision manquante ou contradictoire est résolue avant l’action.
Sources primaires
Les affirmations techniques de ce guide sont reliées aux spécifications et documentations first-party.
- Understand and count tokens (nouvel onglet)Google · Unités de tokenisation et mesure de la taille des entrées ; aucune conversion fixe entre mots et tokens n’est reprise.
- Long context (nouvel onglet)Google · Capacité de contexte et stratégies de résumé ou de retrait de contenu ; les capacités de modèles ne sont pas figées ici.
- Context windows (nouvel onglet)Anthropic · Source primaire pour les distinctions techniques ; procédure et exemples originaux SkillCodex.
Continuer
Guides et outils associés
Comprendre → Reconnaître → Choisir → Comparer
Pack pour ton agent
Instruction pré-écrite par SkillCodex — ta demande n’est ni envoyée ni utilisée pour adapter ce texte ; aucun contenu n’est généré et copier n’exécute rien.
Implémenter correctement
Applique « Comprendre la fenêtre de contexte et les tokens » pas à pas
# Applique le guide « Comprendre la fenêtre de contexte et les tokens » dans ton agent ## Objectif La fenêtre de contexte est la capacité de travail disponible pour une réponse. Elle est comptée en tokens, pas en messages. Un ancien échange visible à l’écran n’est pas nécessairement présent intégralement dans ce que le modèle reçoit. Vérifie les décisions et leurs références lors d’une reprise ; un résumé utile peut conserver l’essentiel tout en perdant un détail décisif. ## Prérequis - Inspecte le dépôt, la documentation et les conventions existantes. - Confirme que le besoin correspond au périmètre du guide : Diagnostiquer un oubli dans une longue conversation et préparer une reprise vérifiable. - Préserve les décisions correctes déjà en place. ## Étapes du guide - 1. Contexte, token et mémoire ne sont pas synonymes — Un token est une unité utilisée pour représenter le contenu traité par le modèle ; pour du texte, ce peut être un mot ou un fragment. Le découpage dépend du modèle et de la langue. Il n’existe pas de conversion universelle fiable entre pages, mots et tokens. - 2. Ne conclus pas trop vite à un dépassement — Exemple : après de longs journaux techniques, l’agent reprend une ancienne échéance. Vérifie d’abord la date dans le document de référence et demande à l’agent quel passage il utilise. Une contradiction peut aussi venir d’une source périmée, d’une instruction ambiguë ou d’une mauvaise lecture. - 3. Comprends ce qui peut changer en cours de route — Selon le produit, une conversation trop longue peut provoquer un refus de requête, une suppression d’anciens éléments ou une compaction en résumé. La troncature enlève du contenu ; la compaction le remplace par une représentation plus courte qui peut perdre des détails. Une grande fenêtre ne garantit pas que chaque détail soit correctement utilisé. - 4. Prépare une reprise courte et contrôlable — Conserve dans un document que tu contrôles : objectif actuel, décisions datées, contraintes, fichiers ou liens de référence, travail terminé avec sa preuve, prochaine action et questions ouvertes. Vérifie ce résumé contre les sources avant de l’utiliser dans une nouvelle conversation. - 5. Reprends une seule étape, puis compare — Après la reprise, demande une sortie courte portant sur la prochaine étape, puis compare-la au document de référence. Vérifie particulièrement une ancienne décision remplacée et une contrainte encore active : ce sont des détails qu’un résumé trop vague peut omettre. ## Critères d’acceptation — Checklist - La première sortie après reprise a été comparée à une décision et à une contrainte sources. - La source actuelle est identifiée. - Un dépassement supposé est distingué d’un dépassement observé. - Le résumé conserve décisions, contraintes et références. - Les extraits nécessaires sont accessibles dans la reprise. - Une décision manquante ou contradictoire est résolue avant l’action. ## Garde-fous - Montre d’abord les changements envisagés avant toute action externe. - Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite. - Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu. ## Format de sortie - Résultat obtenu ou verdict. - Fichiers ou actions concernés. - Vérifications exécutées et preuves observables. - Blocages ou limites restantes.
- Prérequis · Le contexte réel du projet : dépôt, documentation et contraintes existantes
Pourquoi ça marche
- Les étapes viennent d’un guide publié et sourcé, pas d’une improvisation.
- La checklist transforme le conseil en critères vérifiables.
- Le périmètre déclaré évite d’étendre le guide au-delà de ses preuves.
À essayer ensuite
Ancre le guide dans le projet
# Ancre le guide dans le projet ## Objectif Transforme les étapes appliquées en conventions durables du dépôt. ## Contrôles - Relie chaque décision prise à l’étape du guide qui la justifie. - Ajoute la checklist aux revues concernées. - Note les cas hors périmètre pour les guides voisins. ## Garde-fous - Montre d’abord les changements envisagés avant toute action externe. - Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite. - Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu. ## Format de sortie - Résultat obtenu ou verdict. - Fichiers ou actions concernés. - Vérifications exécutées et preuves observables. - Blocages ou limites restantes.
sha256:1c85070020bcb99a23813b9ba590d35b8062c67e82503beedf65c4232808d72c
Diagnostiquer un problème
Diagnostique un écart au guide « Comprendre la fenêtre de contexte et les tokens »
# Diagnostique une application ratée du guide « Comprendre la fenêtre de contexte et les tokens » ## Symptôme observé [DÉCRIS ICI LE SYMPTÔME] ## Contrôles observables - Rejoue les étapes dans l’ordre et note la première qui diverge : - 1. Contexte, token et mémoire ne sont pas synonymes — Un token est une unité utilisée pour représenter le contenu traité par le modèle ; pour du texte, ce peut être un mot ou un fragment. Le découpage dépend du modèle et de la langue. Il n’existe pas de conversion universelle fiable entre pages, mots et tokens. - 2. Ne conclus pas trop vite à un dépassement — Exemple : après de longs journaux techniques, l’agent reprend une ancienne échéance. Vérifie d’abord la date dans le document de référence et demande à l’agent quel passage il utilise. Une contradiction peut aussi venir d’une source périmée, d’une instruction ambiguë ou d’une mauvaise lecture. - 3. Comprends ce qui peut changer en cours de route — Selon le produit, une conversation trop longue peut provoquer un refus de requête, une suppression d’anciens éléments ou une compaction en résumé. La troncature enlève du contenu ; la compaction le remplace par une représentation plus courte qui peut perdre des détails. Une grande fenêtre ne garantit pas que chaque détail soit correctement utilisé. - 4. Prépare une reprise courte et contrôlable — Conserve dans un document que tu contrôles : objectif actuel, décisions datées, contraintes, fichiers ou liens de référence, travail terminé avec sa preuve, prochaine action et questions ouvertes. Vérifie ce résumé contre les sources avant de l’utiliser dans une nouvelle conversation. - 5. Reprends une seule étape, puis compare — Après la reprise, demande une sortie courte portant sur la prochaine étape, puis compare-la au document de référence. Vérifie particulièrement une ancienne décision remplacée et une contrainte encore active : ce sont des détails qu’un résumé trop vague peut omettre. ## Causes possibles - Une étape a été sautée ou exécutée hors ordre. - Le besoin réel sort du périmètre du guide. - Un critère de la checklist n’a jamais été vérifié. ## Corrections bornées - Reprends uniquement l’étape divergente et ce qui en dépend. - Documente l’écart si le périmètre du guide ne couvre pas le besoin. ## Vérification finale — Checklist - La première sortie après reprise a été comparée à une décision et à une contrainte sources. - La source actuelle est identifiée. - Un dépassement supposé est distingué d’un dépassement observé. - Le résumé conserve décisions, contraintes et références. - Les extraits nécessaires sont accessibles dans la reprise. - Une décision manquante ou contradictoire est résolue avant l’action. ## Garde-fous - Montre d’abord les changements envisagés avant toute action externe. - Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite. - Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu. ## Format de sortie - Résultat obtenu ou verdict. - Fichiers ou actions concernés. - Vérifications exécutées et preuves observables. - Blocages ou limites restantes.
- Prérequis · Le contexte réel du projet : dépôt, documentation et contraintes existantes
Pourquoi ça marche
- Le diagnostic rejoue des étapes ordonnées au lieu de chercher au hasard.
- Les corrections restent bornées à la première divergence réelle.
- La checklist sert de vérification finale reproductible.
À essayer ensuite
Préviens la prochaine dérive
# Préviens la prochaine dérive ## Objectif Fais de la première étape divergente un contrôle explicite du projet. ## Contrôles - Ajoute un contrôle ciblé sur l’étape qui a divergé. - Vérifie la checklist sur un second cas réel. - Documente la limite de périmètre rencontrée. ## Garde-fous - Montre d’abord les changements envisagés avant toute action externe. - Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite. - Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu. ## Format de sortie - Résultat obtenu ou verdict. - Fichiers ou actions concernés. - Vérifications exécutées et preuves observables. - Blocages ou limites restantes.
sha256:0ad21ac6bb945029f152ef19f190afab8909cf96527051e4304f97f5b6baa7f1
Digest du Pack: sha256:5799100713c1c911c69a5f12ef7840de9e5d970ae59198f0490eb317419f706c