English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

invité
1 / ?
retour aux leçons

Ce qu'un Tokeniseur Mange Devient Ce qu'Il Sait

Régime du Tokeniseur : Une Définition

Un tokeniseur Harris s'entraîne sur un échantillon de corpus. Il effectue une analyse distributionnelle sur cet échantillon, sélectionne N segments qui reviennent le plus fortement, & les inscrit dans un vocabulaire. Après l'entraînement, ces N segments deviennent un alphabet fixe qu'un modèle de langue utilise pour tout : entraînement, inférence, chaque entrée, chaque sortie.


Régime du tokeniseur = un échantillon de texte sur lequel s'entraîne un tokeniseur.


Régime d'entraînement = un corpus sur lequel un modèle de langage s'entraîne.


Lorsque deux régimes diffèrent, un tokenizer apprend des segments adaptés à du texte qu'un modèle ne verra jamais. La capacité d'embedding (un emplacement par entrée du vocabulaire) est dépensée sur des segments qui ne rapportent aucune récompense pendant l'entraînement.


Régime du tokenizer & saturation


L'Erreur d'ANDREA-12M

ANDREA-12M a entraîné son tokenizer Harris sur une tête brute de megachat-v8.txt. Cette tête contenait des échantillons de code & des données d'appels d'outils. Le curriculum d'entraînement, cependant, excluait le code & les appels d'outils ; ANDREA-12M ne voyait que du texte conversationnel.


Résultat : un tokenizer a appris des segments à partir de mots-clés Python, d'accolades JSON, de flags shell. Un modèle entraîné sur des entrées de dictionnaire & du dialogue. Seulement 36,4 % des segments chevauchaient un échantillon pondéré par le curriculum. Les 63,6 % restants des slots de vocabulaire ont été alloués à des segments qu'un modèle n'aurait jamais rencontrés pendant l'entraînement.


Pourquoi C'est Important

Chaque entrée de vocabulaire consomme des paramètres d'embedding : une ligne d'une matrice d'embedding de forme V × d_model (couvert dans l'activité 4). À V = 4353 & d_model = 384, chaque slot de vocabulaire coûte 384 flottants. Gaspiller 63,6 % gaspille 63,6 % d'une matrice d'embedding sur des données qu'un modèle ne voit jamais.

Énoncer une Règle de Régime

Expliquez une règle de régime du tokenizer en une phrase. Puis décrivez un pire cas : un chercheur entraîne un tokenizer Harris sur Wikipedia (prose formelle, citations) mais entraîne un modèle sur Twitter (argot, emoji, hashtags). Qu'est-ce qui se passe mal ?

Quelle Taille Doit Avoir N

Un Balayage de Science du Vocabulaire

ANDREA-120M a réalisé une expérience de science du vocabulaire : entraîner des tokenizers Harris à différentes valeurs de N (segments demandés) sur un même corpus de 1,25 milliard de caractères. Mesurer combien de segments un tokenizer trouve réellement. Tracer les résultats.


N demandéSegments réels trouvésStatut
2,0482,048Non saturé (marge de croissance)
4,0964,096Non saturé
8,1928,192Point de saturation
16,38413,106Corpus épuisé

Ce que signifie la saturation

À petit N, un corpus présente de nombreux motifs récurrents ; un tokenizer remplit tous les emplacements demandés. À grand N, un tokenizer manque de frontières statistiquement significatives. Un corpus de 1,25 milliard de caractères contient environ 13 106 segments distincts en forme de morphèmes au-dessus d'un seuil de fréquence. Demander 16 384 donne 13 106 ; les 3 278 emplacements restants sont rembourrés ou laissés vides.


Saturation : un point où N demandé = N trouvé. Au-delà de la saturation, un tokenizer ne peut découvrir plus de segments sans diluer la qualité (abaisser les seuils de fréquence & accepter du bruit).


Sweet Spot à 8192

ANDREA-120M a choisi N = 8192. Un raisonnement :


- En dessous de 8192 (ex. 4096) : le vocabulaire sous-représente les morphèmes courants ; les séquences se fragmentent en plus de tokens ; le débit diminue.

- À 8192 : chaque emplacement de segment correspond à un motif réel et récurrent dans un corpus.

- Au-dessus de 8192 : rendements décroissants ; 13 106 < 16 384 signifie que les emplacements sont gaspillés.


Vocabulaire final ANDREA-120M : 256 + 8192 + 1 = 8449 jetons. Compression moyenne : 5,91 octets UTF-8 par jeton, ce qui signifie que chaque jeton remplace ~5,9 octets de texte brut. Ce ratio définit le contexte effectif d'un modèle : à 1024 jetons × 5,91 octets/jeton, ANDREA-120M lit environ 6 050 caractères de contexte par passe avant.

Au-dessus ou en-dessous de la saturation

Supposons qu'un chercheur envisage deux valeurs N pour un futur modèle ANDREA : N = 6144 (en-dessous de la saturation) versus N = 12288 (au-dessus de la saturation, où le nombre réel de segments trouvés = 13106 reste applicable car le corpus est fixe). Pour chacune : (a) calculez la taille finale du vocabulaire (256 + N + 1), & (b) indiquez en une phrase si chaque réglage gaspille la capacité du vocabulaire, capture tout le signal disponible, ou sous-capture. Montrez votre travail.

D'où vient les 63,6 %

Comptage des emplacements gaspillés

Le tokenizer d'ANDREA-12M entraîné sur megachat-v8.txt brut (4096 segments demandés, trouvés). Une équipe a échantillonné un sous-ensemble pondéré par curriculum : un corpus pondéré par la fréquence à laquelle chaque source a été tirée par un bandit. Ils ont re-exécuté une analyse Harris sur cet échantillon pondéré & ont demandé : combien des 4096 segments originaux apparaissent encore ?


Résultat : 36,4 % de chevauchement. 1 491 des 4 096 segments correspondent à la pondération curriculum. Les 2 605 segments restants proviennent de sources exclues par le modèle.


63,6 % des emplacements de vocabulaire ont été alloués à des octets qu'un modèle n'a jamais vus.


Coût d'Embedding

Chaque entrée de vocabulaire occupe une ligne d'une matrice d'embedding de forme (V, d_model). Pour ANDREA-12M :


- V = 4353 (256 + 4096 + 1)

- d_model = 384

- Params d'embedding = V × d_model = 4353 × 384 = 1 671 552 paramètres


63,6 % de ces paramètres sont restés inutilisés pour l'entraînement conversationnel. 1 063 107 paramètres alloués, 0 signal de récompense. ANDREA-12M survit parce que 256 octets de base couvrent toujours n'importe quel caractère ; mais la capacité par paramètre a chuté fortement.


Comment ANDREA-120M a résolu le problème

Le tokenizer d'ANDREA-120M a été entraîné sur un flux complet (1,25 milliard de caractères, 21 sources) à saturation N = 8192. Un corpus d'entraînement = le même flux. Alignement diététique : 100 %. Chevauchement résultant sur un échantillon pondéré par chat : 36,5 %. (Note : 36,5 % est le chevauchement, pas la couverture ; le chat seul est un sous-ensemble du flux complet, donc ce chiffre se comporte différemment de celui des 36,4 % de 12M.)


Compression efficace : 5,91 octets UTF-8 par token. Matrice d'embeddings d'ANDREA-120M : 8449 × 768 = 6 488 832 paramètres. Chaque paramètre gagne un signal de récompense parce que chaque segment correspond à un texte sur lequel le modèle s'entraîne réellement.

Couverture versus Chevauchement

Le corpus du tokenizer d'ANDREA-120M correspond à son corpus d'entraînement. Pourtant, une 'couverture de segments sur un échantillon pondéré par chat' s'est élevée à 36,5 %, similaire aux 36,4 % de 12M. Pourquoi 36,5 % n'est pas un problème pour 120M alors que 36,4 % l'était pour 12M ? Utilisez une phrase sur quel sous-ensemble est quoi.

Pourquoi 5,91 Octets Par Token Importe

Un Ratio de Compression

Les octets UTF-8 moyens par token mesurent combien de texte brut chaque entrée du vocabulaire compresse. ANDREA-120M fait en moyenne 5,91. Un modèle avec des morceaux plus courts (3 octets/token) lit moins de contexte par passage avant ; un modèle avec des morceaux plus longs (8 octets/token) lit plus mais s'entraîne plus lentement (chaque morceau a besoin de plus d'échantillons pour bien apprendre).


Contexte effectif


QuantitéValeur
Fenêtre de contexte en tokens1 024 tokens
Octets moyens par token5,91
Contexte effectif en caractères1024 × 5,91 ≈ 6 050

Environ 6 000 caractères UTF-8 tiennent dans un passage avant d'ANDREA-120M. Une page de prose anglaise dense fait ~3 000-4 000 caractères ; ANDREA lit environ une page et demie par passage.


Le régime resserre la compression

Un tokenizer bien aligné compresse mieux. Quand un tokenizer apprend des segments qui se répètent dans un corpus d'entraînement, plus de texte tient par token. Le tokenizer mal aligné d'ANDREA-12M compressait moins bien sur le chat (plus d'octets dépensés sur des fragments de repli par octet car les segments de chat étaient plus rares dans le vocabulaire). Le tokenizer aligné sur le régime d'ANDREA-120M garde un morceau en forme de chat sur un chemin rapide & les scripts rares sur un repli par octet.


Activité 4 se poursuit

L'Activité 4 (grow_a_language_model_embeddings) couvre ce qui arrive à ces 8449 entrées de vocabulaire : elles deviennent des lignes d'une matrice d'embeddings de forme V × d_model, puis ajoutent des embeddings de position appris avant de couler dans un premier bloc transformer.

Choisissez un N

Réfléchissez à un compromis : un futur modèle ANDREA devrait-il utiliser N = 4096 (entraînement plus rapide, plus d'octets-par-token = contexte effectif plus long) ou N = 16384 (segments plus longs mais plus rares, moins de tokens par morceau de texte, mais saturation passée donc slots gaspillés) ? Choisissez-en un & donnez une raison en une phrase. Pas de mauvaise réponse.