Accueil > Glossaire > Vocabulary

Vocabulary (Vocabulaire d’un Modele de Langage)

Composition du vocabulaire

Le vocabulaire d’un LLM contient plusieurs categories de tokens. Les tokens de base representent les caracteres individuels ou les bytes (pour le byte-level BPE), assurant que tout texte est representable. Les tokens de sous-mots sont les unites apprises par l’algorithme de tokenisation : des morceaux de mots comme « tion », « ment », « ing », « pre ». Les tokens de mots complets correspondent aux mots suffisamment frequents pour avoir leur propre entree : « le », « the », « de », « est ». Les tokens speciaux incluent les marqueurs de debut/fin de sequence, le token de padding et le token inconnu (UNK).

Chaque token est associe a un index entier (son token ID) et a un vecteur d’embedding de dimension d_model (par exemple, 4096 dimensions pour un modele de 7B de parametres). La matrice d’embedding (aussi appelee embedding table) est une matrice de taille vocabulaire x d_model, qui constitue l’un des plus grands blocs de parametres du modele.

Les tokens les plus frequents dans les donnees d’entrainement tendent a avoir des embeddings mieux entraines, car ils ont ete vus des millions de fois. Les tokens rares (en queue de distribution) ont des embeddings de moindre qualite, ce qui peut affecter les performances sur les textes contenant ces tokens.

Taille du vocabulaire : compromis et tendances

La taille du vocabulaire est un hyperparametre critique qui affecte plusieurs aspects du modele. Un vocabulaire plus petit (30K-50K) produit des sequences de tokens plus longues (les mots sont decomposes en plus de morceaux), ce qui consomme plus de fenetre de contexte. Un vocabulaire plus grand (100K-256K) produit des sequences plus courtes mais augmente la taille de la matrice d’embedding et le cout de la couche de sortie (softmax).

La tendance est clairement a l’augmentation des vocabulaires. Passer de 32K a 128K tokens permet de tokeniser le francais avec 20 a 40% de tokens en moins, et le chinois ou le japonais avec une reduction encore plus importante. Cela reduit directement le cout des API facturees au token et augmente la fenetre de contexte effective.

Impact sur le support multilingue

L’efficacite du vocabulaire varie enormement selon la langue. Un vocabulaire entraine principalement sur de l’anglais aura de nombreux tokens qui correspondent a des mots anglais complets, tandis que les mots francais, chinois ou arabes seront decomposes en de nombreux fragments. Cela cree une inegalite : un meme paragraphe en anglais utilise moins de tokens (et coute moins cher via l’API) que le meme paragraphe traduit en francais.

Les vocabulaires modernes (Llama 3, GPT-4o, Gemini) ameliorent cette situation en incluant des donnees d’entrainement diversifiees pour le tokenizer. GPT-4o a ete explicitement concu pour reduire cet ecart, avec un vocabulaire de 200K qui inclut de meilleurs tokens pour les langues non-latines. En pratique, l’amelioration est significative : un texte en hindi peut necessiter 50% de tokens en moins avec GPT-4o qu’avec GPT-3.5.

Tokens speciaux

Chaque vocabulaire inclut des tokens speciaux qui jouent des roles fonctionnels dans le modele. Le token BOS (Beginning of Sequence) marque le debut d’une sequence. Le token EOS (End of Sequence) signale la fin de la generation. Le token PAD est utilise pour aligner les sequences a la meme longueur dans un batch. Le token UNK (Unknown) remplace les tokens non reconnus, bien qu’avec le byte-level BPE il ne soit pratiquement jamais utilise.

Certains modeles ajoutent des tokens speciaux pour des fonctionnalites specifiques : tokens de role (system, user, assistant) pour les chatbots, tokens de code (debut/fin de bloc de code), tokens d’outils (function calling), ou tokens de controle (debut/fin de reflexion pour les modeles de raisonnement).

Vocabulaire et couts d’API

Les API des LLMs facturent au token. Le vocabulaire determine directement combien de tokens un texte donne consomme, et donc son cout. Comprendre la tokenisation permet d’optimiser les couts : reformuler des prompts de maniere plus concise, utiliser des modeles avec des vocabulaires plus efficaces pour votre langue, ou estimer les couts avant de lancer des traitements en masse.

Certains tokens speciaux (comme les tokens de chat formatting) sont ajoutes automatiquement par l’API et consomment de la fenetre de contexte sans etre visibles dans le texte de l’utilisateur. Il est utile de comprendre cette surcharge pour estimer correctement l’utilisation de la fenetre de contexte.

Comment un vocabulaire est construit

Le processus de construction suit les etapes de l’algorithme de tokenisation choisi. Pour BPE, on part des caracteres/bytes de base et on fusionne les paires les plus frequentes. Pour Unigram, on part d’un vocabulaire large et on elague les tokens les moins utiles. La qualite du vocabulaire depend directement de la qualite et de la diversite du corpus d’entrainement du tokenizer.

Un point souvent meconnu : le corpus d’entrainement du tokenizer n’est pas necessairement le meme que le corpus d’entrainement du modele. On peut entrainer un tokenizer sur un corpus equilibre (50% anglais, 10% francais, 10% code, etc.) puis entrainer le modele sur un corpus different. Cela permet d’optimiser le vocabulaire independamment des proportions des donnees d’entrainement du modele.