Tokens et fenêtre de contexte
Ce qu'un modèle de langage lit vraiment, pourquoi il « oublie » le début d'une longue conversation et ce que ça change quand on écrit un prompt.
Mis à jour le
Pourquoi on voit ça
Les modèles de langage sont devenus un outil de travail en DevOps. Tu leur fais relire un script, expliquer un message d’erreur, résumer des logs, rédiger un playbook. De plus en plus d’équipes les appellent aussi par API, depuis un pipeline ou un outil interne.
Dans tous ces usages, deux notions reviennent sans arrêt : le token et la fenêtre de contexte. Elles expliquent des comportements qui surprennent au début. Pourquoi l’assistant « oublie » une consigne. Pourquoi coller dix mille lignes de logs donne un moins bon résultat. Pourquoi la facture d’une API grimpe.
C’est la première leçon du parcours parce que tout le reste s’appuie dessus : écrire un bon prompt, c’est d’abord décider ce qu’on met dans la fenêtre.
Le modèle ne lit pas des mots
Un modèle de langage ne voit ni lettres ni mots. Avant d’arriver au modèle, le texte passe par un tokenizer qui le découpe en morceaux appelés tokens. Un token peut être un mot entier, un bout de mot, un espace ou un signe de ponctuation.
Ce découpage est une illustration. Le découpage exact dépend du modèle : chaque famille de modèles a son tokenizer.
Comme ordre de grandeur, un token vaut environ trois quarts d’un mot en anglais. Ce n’est pas une règle de calcul, juste un repère pour estimer. Le français en consomme un peu plus, parce que ses mots sont plus souvent coupés en plusieurs morceaux.
Une analogie : le tokenizer fait comme quelqu’un qui découpe un texte en syllabes ou en groupes de lettres fréquents. Les mots courants restent entiers. Les mots rares ou longs partent en plusieurs morceaux.
La fenêtre de contexte
La fenêtre de contexte est la quantité maximale de tokens que le modèle peut prendre en compte en une seule fois. Tout y entre :
- les consignes de départ ;
- toute la conversation jusqu’ici ;
- les fichiers et documents fournis ;
- la réponse en train d’être écrite.
Imagine un bureau de taille fixe. Tout ce dont le modèle a besoin doit tenir dessus : les consignes, les documents, la feuille sur laquelle il écrit. Quand le bureau est plein, il faut retirer quelque chose pour poser autre chose.
Pas de mémoire en dehors de la fenêtre
Le modèle n’a pas de mémoire en dehors de cette fenêtre. S’il « se souvient » de ton message précédent, c’est parce que ce message lui est renvoyé à chaque tour. Il ne se rappelle pas la conversation : il la relit en entier à chaque réponse.
Deux conséquences :
- Une nouvelle conversation repart de zéro. Rien de la précédente n’est visible, sauf si un système de mémoire séparé le réinjecte dans le contexte.
- Quand une conversation dépasse la fenêtre, une partie doit sortir. Les anciens messages sont coupés ou résumés, et le modèle n’y a plus accès tels quels.
Ce que ça change en pratique
| Situation | Conséquence |
|---|---|
| Conversation très longue | Les premiers messages finissent coupés ou résumés |
| Gros document collé en entier | Moins de place pour le reste, et un coût plus élevé |
| Consigne importante noyée au milieu | Elle risque d’être moins bien suivie |
Trois réflexes utiles :
- Donner seulement ce qui sert à la tâche, pas tout ce qu’on a sous la main.
- Placer les consignes importantes au début ou à la fin, là où elles sont le mieux suivies.
- Repartir d’une conversation neuve, avec un résumé, quand la première devient trop longue.
Exemple concret. Un service plante et tu as un fichier de logs de plusieurs milliers de lignes. Plutôt que de tout coller, filtre d’abord :
grep -i "error" app.log | tail -n 50
Tu envoies cinquante lignes utiles au lieu de milliers. Le modèle a moins de bruit à trier, et il te reste de la place pour la suite de l’échange.
Les tokens, c’est aussi la facture
Les API de modèles facturent au token, en entrée et en sortie. Les tokens de sortie coûtent en général plus cher que ceux d’entrée.
Un prompt deux fois plus long coûte donc à peu près deux fois plus cher en entrée, à chaque appel. Dans une conversation, c’est encore plus net : comme tout l’historique est renvoyé à chaque tour, chaque nouveau message fait repayer les précédents en entrée.
Les prix et la taille de la fenêtre changent d’un modèle à l’autre et évoluent vite. Va toujours les lire dans la documentation du fournisseur plutôt que de les retenir.
À retenir
- Le modèle traite des tokens, pas des mots. Un token ≈ trois quarts d’un mot en anglais, en ordre de grandeur.
- La fenêtre de contexte est tout ce qu’il peut voir en une fois, réponse comprise.
- Ce qui n’est pas dans la fenêtre n’existe pas pour lui : pas de mémoire d’une conversation à l’autre.
- Conversation trop longue : les anciens messages sont coupés ou résumés. Redonne la consigne ou repars d’un résumé.
- Les tokens se paient, en entrée et en sortie : donne seulement ce qui sert à la tâche.
Entraînement
12 questions, dont 3 à compléter. Tu réponds, on passe à la suivante. La note arrive à la fin.
Ta note
Cartes · 6
Réviser les cartes ici
Pourquoi