Objectifs pédagogiques
- Expliquer en une phrase ce qu’un tokenizer fait au texte avant que le modèle n’en voie quoi que ce soit.
- Tokeniser le même passage avec deux tokenizers différents et rendre compte de l’écart entre les comptes de tokens.
- Énumérer chaque composant d’une requête qui consomme la fenêtre de contexte, y compris la sortie réservée.
- Calculer le budget de tokens d’une requête réaliste et dire si elle tient dans une fenêtre de contexte donnée.
- Choisir et justifier une politique de troncature ou de résumé lorsque le budget est dépassé.
- Démontrer que le texte non anglophone, le code source et les emoji coûtent plus de tokens qu’une prose anglaise équivalente.
- Épingler une révision de modèle avec le tokenizer et le chat template appariés, et expliquer pourquoi ce trio doit évoluer d’un seul bloc.
Matériel nécessaire
- Un poste par participant, avec un environnement Python et une bibliothèque de tokenisation installés à l’avance.
- Deux tokenizers issus de familles de modèles différentes, téléchargés avant la séance pour que personne n’attende le réseau.
- Un jeu de textes préparé : un paragraphe en anglais, sa traduction française, un court extrait de code et une ligne d’emoji.
- Un vidéoprojecteur pour la démonstration de tokenisation en direct, avec une police assez grande pour montrer les frontières de chaque token.
- Une fiche de budget, imprimée ou partagée : invite système, historique, schémas d’outils, passages récupérés, entrée utilisateur, sortie réservée.
- Repli hors ligne : les comptes de tokens de tout le jeu de textes, calculés à l’avance et exportés en CSV, pour que les deux ateliers tiennent sans accès réseau.
Déroulé minute par minute
| Heure | Durée | Séquence |
|---|---|---|
| 0:00 | 10 min | Cadrage : le modèle ne voit jamais votre texte, seulement des identifiants de tokens. |
| 0:10 | 15 min | Concept 1 : ce qu’est réellement un token — mots, fragments, ponctuation, espaces, octets. |
| 0:25 | 20 min | Atelier A : tokeniser le même passage avec deux tokenizers et comparer les comptes. |
| 0:45 | 10 min | Débriefing de l’atelier A : pourquoi le même texte donne des comptes différents, et ce que cela coûte. |
| 0:55 | 5 min | Pause. |
| 1:00 | 25 min | Atelier B : construire le budget complet d’une requête et décider quoi couper en cas de dépassement. |
| 1:25 | 15 min | Concept 2 : politiques de troncature et de résumé, et la sortie réservée. |
| 1:40 | 10 min | Concept 3 : contrôles opérationnels — épingler les révisions, tester les cas limites, mesurer pour de vrai. |
| 1:50 | 10 min | Atelier C et clôture : la liste de vérification d’épinglage et la limite honnête. |
Messages clés à faire passer
- Le modèle consomme des identifiants de tokens, pas des caractères. Tout raisonnement sur le coût, la latence et les limites se mène dans l’espace des tokens.
- Les tokens sont spécifiques au modèle. La même chaîne tokenisée par deux tokenizers différents donne deux comptes différents, et aucun des deux n’est faux.
- Un token n’est pas un mot. Ce peut être un mot entier, un fragment de mot, un signe de ponctuation, une espace initiale, ou une suite d’octets bruts.
- Le budget couvre toute la requête : instructions système, historique de conversation, schémas d’outils, passages récupérés, entrée utilisateur, et la sortie que vous réservez.
- Si le total dépasse la fenêtre de contexte, quelque chose est supprimé. Choisissez explicitement la politique de troncature ou de résumé, sinon le moteur d’exécution en choisira une à votre place.
- Les estimations par caractères ne sont que des aides à la planification. Tout ce qui conditionne une requête doit être mesuré avec le tokenizer exact apparié à la révision du modèle.
Pièges fréquents
Les participants supposent qu’un token vaut un mot et cessent de compter.
Tokenisez une phrase en direct et lisez les morceaux à voix haute, espaces initiales comprises. Voir « token » et « izer » séparés à l’écran met fin à cette croyance plus vite que n’importe quelle explication.
Quelqu’un estime avec un ratio fixe caractères par token et traite le résultat comme exact.
Faites-lui appliquer le même ratio au français, à du JSON et à une ligne d’emoji, puis comparez aux comptes mesurés. Le ratio est une aide à la planification, pas un contrôle de limite.
La fiche de budget ne compte que l’invite utilisateur et oublie la sortie réservée.
Demandez ce qui arrive quand on réclame une réponse de 900 tokens alors qu’il en reste 200 dans la fenêtre. La réponse tronquée rend l’oubli concret.
Les schémas d’outils et les instructions système sont oubliés parce qu’ils sont invisibles dans l’interface.
Affichez une fois la requête entièrement rendue, chat template inclus, et comptez-la. L’écart entre l’invite visible et la charge réelle est en général la surprise de la séance.
Un participant utilise un tokenizer d’une révision différente de celle du modèle qu’il budgétise.
Montrez que les comptes divergent, et exigez que l’identifiant du tokenizer figure à côté de chaque compte sur la fiche. Un nombre sans identifiant de tokenizer n’est pas un résultat.
La séance dérive vers une comparaison des fournisseurs au coût par token.
Annoncez d’emblée que les prix et les limites changent et que toute comparaison est datée. Enseignez la méthode de mesure, qui reste valable, et non la grille tarifaire du moment.