token

En profondeur

Le découpage est produit par un tokeniseur, construit en même temps que le modèle à partir de ses textes d’entraînement : il retient un vocabulaire fixe de fragments fréquents, et tout texte entrant est réécrit comme une suite de ces fragments. Le modèle ne voit donc jamais des lettres ni des mots, seulement des numéros de fragments, ce qui explique ses maladresses sur les tâches de caractères : compter les lettres d’un mot ou l’écrire à l’envers lui demande de raisonner sur une matière qu’il ne perçoit pas directement. Un token n’existe pas dans l’absolu : il n’existe que relativement au découpage d’un modèle donné, et deux modèles ne comptent pas le même texte de la même façon.

Le token est aussi l’unité de compte du système : la facturation, les limites d’usage et une bonne part du temps de réponse se mesurent en tokens, en entrée comme en sortie. Cela produit des effets contre-intuitifs. Un tableau très structuré peut coûter plus cher qu’un paragraphe qui dit la même chose, parce que la ponctuation et la mise en forme se paient. Et les langues moins représentées dans les données d’entraînement sont découpées plus finement, donc consomment davantage de tokens à contenu égal. Raisonner en pages ou en signes conduit à sous-estimer une facture ou à dépasser une limite sans comprendre pourquoi.

Deux confusions coexistent et méritent d’être séparées. La première est linguistique : le token n’est pas un mot, et les intuitions tirées du comptage de mots se transportent mal, en particulier sur les identifiants, les adresses et les chiffres, très coûteux en tokens. La seconde est de vocabulaire : dans le monde du logiciel, un token désigne aussi un jeton d’authentification, sans le moindre rapport avec le découpage du texte, et la même réunion peut donc employer le mot dans deux sens. Reste un piège pratique : un texte trop long n’est pas refusé poliment, il est tronqué, et ce qui disparaît disparaît en silence.