Quello che un Tokenizer Mangia Diventa Quello che Sa
Dieta del Tokenizer: Una Definizione
Un tokenizer Harris si allena su un campione di corpus. Esegue un'analisi distributiva su quel campione, seleziona N segmenti che ricorrono più fortemente, & li scrive nel vocabolario. Dopo l'allenamento, quei N segmenti diventano un alfabeto fisso che un modello linguistico usa per tutto: allenamento, inferenza, ogni input, ogni output.
Dieta del tokenizer = un campione di testo su cui si allena un tokenizer.
Dieta di addestramento = un corpus su cui si addestra un modello linguistico.
Quando due diete differiscono, un tokenizer impara segmenti ottimizzati per testi che un modello non vedrà mai. La capacità di embedding (uno slot per voce del vocabolario) viene spesa su segmenti che non guadagnano ricompensa durante l'addestramento.
L'Errore di ANDREA-12M
ANDREA-12M ha addestrato il suo tokenizer Harris su un raw head di megachat-v8.txt. Quel head conteneva campioni di codice & dati di tool-call. Il curriculum di addestramento, tuttavia, ha escluso codice & tool calls; ANDREA-12M ha visto solo testo conversazionale.
Risultato: un tokenizer ha imparato segmenti da parole chiave Python, parentesi graffe JSON, flag shell. Un modello addestrato su voci di dizionario & dialoghi. Solo il 36.4% dei segmenti si sovrapponeva a un campione pesato dal curriculum. Il restante 63.6% degli slot del vocabolario è stato allocato a segmenti che un modello non incontrerebbe mai durante l'addestramento.
Perché È Importante
Ogni voce del vocabolario consuma parametri di embedding: una riga di una matrice di embedding di forma V × d_model (coperto nell'attività 4). A V = 4353 & d_model = 384, ogni slot del vocabolario costa 384 float. Sprecare il 63.6% spreca il 63.6% di una matrice di embedding su dati che un modello non vede mai.
Enuncia una Regola Dietetica
Quanto Grande Deve Essere N
Un'Analisi Scientifica del Vocabolario
ANDREA-120M ha condotto un esperimento di scienza del vocabolario: addestra tokenizer Harris con diversi valori di N (segmenti richiesti) sullo stesso corpus firehose di 1.25B caratteri. Misura quanti segmenti il tokenizer trova effettivamente. Traccia i risultati.
| N richiesti | Segmenti effettivi trovati | Stato |
|---|---|---|
| 2,048 | 2,048 | Insaturo (spazio per crescere) |
| 4,096 | 4,096 | Insaturo |
| 8,192 | 8,192 | Punto di saturazione |
| 16,384 | 13,106 | Corpus esaurito |
Cosa significa la saturazione
Con N piccolo, un corpus ha molti pattern ricorrenti; un tokenizer riempie ogni slot richiesto. Con N grande, un tokenizer esaurisce i confini statisticamente significativi. Un corpus di 1,25 miliardi di caratteri contiene circa 13.106 segmenti distinti a forma di morfema sopra una soglia di frequenza. Chiedendone 16.384 se ne ottengono 13.106; i restanti 3.278 slot vengono riempiti o lasciati vuoti.
Saturazione: un punto in cui N richiesto = N trovato. Oltre la saturazione, un tokenizer non può scoprire più segmenti senza diluire la qualità (abbassando le soglie di frequenza & accettando rumore).
Punto Dolce a 8192
ANDREA-120M ha scelto N = 8192. Un ragionamento:
- Sotto 8192 (es. 4096): il vocabolario sottocattura i morfemi comuni; le sequenze si frammentano in più token; il throughput cala.
- A 8192: ogni slot di segmento mappa su un pattern reale e ricorrente in un corpus.
- Sopra 8192: rendimenti decrescenti; 13.106 < 16.384 significa che gli slot vengono sprecati.
Vocabolario finale ANDREA-120M: 256 + 8192 + 1 = 8449 token. Compressione media: 5,91 byte UTF-8 per token, il che significa che ogni token sostituisce ~5,9 byte di testo grezzo. Quel rapporto imposta il contesto effettivo di un modello: a 1024 token × 5,91 byte/token, ANDREA-120M legge circa 6.050 caratteri di contesto per forward pass.
Sopra o Sotto la Saturazione
Da Dove Viene il 63.6%
Contare gli Slot Sprecati
Il tokenizer di ANDREA-12M addestrato su megachat-v8.txt grezzo (4096 segmenti richiesti, trovati). Un team ha campionato un sottoinsieme pesato sul curriculum: un corpus pesato in base a quanto spesso ogni sorgente è stata selezionata da un bandit. Hanno rieseguito un'analisi Harris su quel campione pesato & hanno chiesto: quanti dei 4096 segmenti originali appaiono ancora?
Risultato: 36.4% di sovrapposizione. 1.491 dei 4.096 segmenti corrispondevano al peso del curriculum. I restanti 2.605 segmenti provenivano da sorgenti escluse dal modello.
Il 63,6% degli slot di vocabolario è stato allocato a byte che il modello non ha mai visto.
Costo di Embedding
Ogni voce del vocabolario occupa una riga di una matrice di embedding di forma (V, d_model). Per ANDREA-12M:
- V = 4353 (256 + 4096 + 1)
- d_model = 384
- Parametri di embedding = V × d_model = 4353 × 384 = 1.671.552 parametri
Il 63,6% di quei parametri è rimasto inutilizzato per l'addestramento conversazionale. 1.063.107 parametri allocati, 0 segnale di ricompensa. ANDREA-12M sopravvive perché 256 byte base coprono sempre qualsiasi carattere; ma la capacità per parametro è calata bruscamente.
Come ANDREA-120M Ha Risolto
Il tokenizer di ANDREA-120M è stato addestrato su un firehose completo (1,25B caratteri, 21 fonti) a saturazione N = 8192. Un corpus di addestramento = lo stesso firehose. Allineamento dietetico: 100%. Sovrapposizione risultante su campione pesato per chat: 36,5%. (Nota: 36,5% è sovrapposizione, non copertura; la chat da sola è un sottoinsieme del firehose completo, quindi questo numero si comporta diversamente dal 36,4% di 12M.)
Compressione effettiva: 5,91 byte UTF-8 per token. Matrice di embedding di ANDREA-120M: 8449 × 768 = 6.488.832 parametri. Ogni parametro guadagna un segnale di ricompensa perché ogni segmento mappa su testo su cui il modello si addestra effettivamente.
Copertura Versus Sovrapposizione
Perché 5,91 Byte Per Token Importano
Un Rapporto di Compressione
I byte UTF-8 medi per token misurano quanto testo grezzo comprime ogni voce del vocabolario. ANDREA-120M fa in media 5,91. Un modello con pezzi più corti (3 byte/token) legge meno contesto per forward pass; un modello con pezzi più lunghi (8 byte/token) ne legge di più ma si addestra più lentamente (ogni pezzo ha bisogno di più campioni per essere imparato bene).
Contesto Efficace
| Quantità | Valore |
|---|---|
| Finestra di contesto token | 1.024 token |
| Byte medi per token | 5,91 |
| Contesto efficace in caratteri | 1024 × 5,91 ≈ 6.050 |
Circa 6.000 caratteri UTF-8 entrano in un forward pass di ANDREA-120M. Una pagina di prosa inglese densa conta ~3.000-4.000 caratteri; ANDREA legge circa una pagina e mezza per pass.
La Dieta Migliora la Compressione
Un tokenizer ben allineato comprime meglio. Quando un tokenizer impara segmenti che ricorrono in un corpus di addestramento, più testo entra per token. Il tokenizer mal allineato di ANDREA-12M comprimeva peggio sulle chat (più byte spesi su frammenti di fallback byte perché i segmenti delle chat erano più sparsi nel vocabolario). Il tokenizer diet-aligned di ANDREA-120M mantiene un pezzo a forma di chat su un percorso veloce & script rari su un fallback byte.
Attività 4 Continua
L'Attività 4 (grow_a_language_model_embeddings) copre cosa succede a quelle 8449 voci del vocabolario: diventano righe di una matrice di embedding di forma V × d_model, poi aggiungono embedding di posizione appresi prima di fluire nel primo blocco transformer.