Il vocabolario del tokenizer: chi decide quali pezzi di testo esistono

Un modello linguistico non legge parole. Legge numeri. Quei numeri escono da una lista chiusa che si chiama vocabolario. È il pezzo che quasi nessuno guarda, eppure decide quanto costa una frase, quanto testo entra nel contesto e persino quanto bene il modello scrive in italiano.

Nella lezione dedicata alla tokenizzazione ho raccontato come il testo viene spezzato. Qui faccio un passo indietro e guardo la lista: chi la costruisce, come si dimensiona, cosa ci finisce dentro e perché certi dettagli cambiano il comportamento del modello più di quanto sembri.

Ti avverto subito: è la parte meno appariscente di tutta la faccenda. Ed è quella che spiega un sacco di comportamenti strani.

Che cos’è il vocabolario di un tokenizer

Il vocabolario è l’elenco completo dei pezzi di testo che un tokenizer conosce. Ogni pezzo ha un ID, cioè un numero intero assegnato una volta e mai più cambiato. Se il vocabolario contiene 128.000 pezzi, gli ID vanno da 0 a 127.999 e nessun testo potrà mai produrre un numero fuori da quel range.

Attenzione al malinteso più comune: la parola “vocabolario” fa pensare a un dizionario di parole intere, tipo quello che si consulta per cercare un termine. Non è così. Dentro ci sono parole complete, sì, ma anche radici, suffissi, spazi iniziali, punteggiatura e sequenze di byte. “gatto” può essere un token unico, “gatt” e “o” due token separati, ” gatt” con lo spazio davanti un terzo token diverso dai primi due.

Il vocabolario è quindi un insieme di stringhe, non di concetti. “Roma” e “capitale d’Italia” stanno su piani diversi: la seconda è conoscenza appresa dal modello, la prima è solo una voce della lista.

Come si costruisce un vocabolario, in pratica

Non lo decide una persona sfogliando un dizionario. Lo costruisce un algoritmo su un corpus enorme: pagine web, libri, codice, enciclopedie, conversazioni. Il procedimento, ridotto all’osso, è una conta.

Si parte da un alfabeto di base, in genere 256 byte, che è tutto ciò che serve per rappresentare qualsiasi testo UTF-8. Poi si contano le coppie di simboli adiacenti su tutto il corpus e si fondono le più frequenti in un simbolo nuovo. La “e” più la “s” diventa “es” se quella coppia appare milioni di volte. Il ciclo si ripete finché il vocabolario raggiunge la dimensione decisa in partenza.

Il risultato dipende dal corpus. Un tokenizer addestrato su testi inglesi spenderà molte voci su “the”, “ing”, “tion”. Uno addestrato sul codice avrà voci per “function”, “return” e per l’indentazione. Uno multilingue dovrà dividersi tra decine di lingue. E qui iniziano i guai.

La parte interessante è che nessuno progetta i singoli token. Si sceglie la dimensione finale, si sceglie il corpus, si sceglie la regola di fusione. Il resto è statistica che emerge da sola.

Gli ID non significano niente

Questa è la parte che sorprende sempre. L’ID 4.321 non è “più grande” o “più importante” dell’ID 12. I numeri sono etichette, come i codici di magazzino. Se un tokenizer rimappasse tutto in ordine alfabetico, il modello funzionerebbe identico, a patto di riaddestrarlo da zero.

Perché allora non usare i numeri come se avessero un senso? Perché qualcuno ci prova, sempre. Esiste una tentazione ricorrente: pensare che token con ID vicini siano legati tra loro. Non lo sono. La prossimità diventa significativa solo dopo l’embedding, quando ogni ID viene tradotto in un vettore e quei vettori si organizzano nello spazio.

C’è un dettaglio pratico che discende da qui: gli ID sono un contratto. Se cambi l’ordine, i pesi appresi diventano rumore. Un modello è inseparabile dal suo vocabolario, come una serratura dalla sua chiave.

Quanto deve essere grande un vocabolario

Non esiste un numero giusto, esiste un compromesso. Allargando il vocabolario le frasi diventano più corte, quindi il modello processa meno token per lo stesso testo. Ma ogni voce in più è una riga in più nella matrice di embedding, ed è un token che appare di rado, quindi addestrato male.

Restringendolo succede l’opposto: matrice compatta, ma sequenze lunghe, più lente e più care. Le due spinte si incontrano in un punto che cambia con la lingua e con il tipo di contenuto.

La tendenza recente è chiara: vocabolari sempre più grandi. Qualche anno fa 32.000 voci erano lo standard, oggi i modelli multilingue viaggiano tra 128.000 e 256.000. Il motivo è economico: con cento lingue da coprire, un vocabolario piccolo costringe ognuna di esse a spezzare le parole in pezzi minuscoli.

I token speciali: le istruzioni nascoste nel vocabolario

Dentro la lista ci sono voci che non rappresentano testo normale. Si chiamano token speciali e servono a segnalare struttura: inizio e fine sequenza, riempimento, separatore tra messaggi, maschera per il training. Il modello li tratta come token qualsiasi, ma il loro significato è convenzionale.

Qualche esempio concreto: BOS e EOS aprono e chiudono una sequenza, PAD riempie i batch per avere righe della stessa lunghezza, UNK rappresenta l’ignoto nei tokenizer che non usano i byte. Nei modelli conversational compaiono anche token di ruolo, uno per l’utente e uno per l’assistente, che sono stringhe riservate.

Qui c’è una conseguenza che pochi considerano: i token speciali si possono iniettare. Se scrivi in un prompt la stringa esatta che il tokenizer riserva alla fine del messaggio, il modello può interpretarla come un cambio di turno. È uno dei motivi per cui i tokenizer moderni dichiarano quelle stringhe riservate e le filtrano in input.

Il vocabolario è la prima riga della rete

Qui il vocabolario smette di essere un file di testo e diventa un parametro. La matrice di embedding ha una riga per ogni voce: con 128.000 token e 4.096 dimensioni sono 524 milioni di parametri solo per l’ingresso. In un modello da 8 miliardi di parametri è il 6,5% del totale, mentre in un modello da un miliardo sarebbe metà della rete.

Questo spiega perché il vocabolario non è un dettaglio da appendice. Cambia il bilancio dei parametri, il costo del primo strato e la qualità della rappresentazione per i token rari. Molti modelli legano la matrice di output a quella di ingresso, tecnica chiamata weight tying, proprio per non raddoppiare quella spesa.

Se vuoi il quadro completo di cosa succede dopo, la lezione su cosa sono gli embedding entra nel merito. Qui basti sapere che il vocabolario è l’indice, non il significato.

Un vocabolario per cento lingue: chi paga il conto

Questo è il punto dolente dei modelli multilingue. Il vocabolario è uno solo, ma le lingue sono tante e ognuna vorrebbe più voci. Il risultato è una spartizione sbilanciata: le lingue con più testo nel corpus di addestramento si prendono più token, le altre si arrangiano con pezzi più piccoli.

L’effetto si misura con un numero, la fertilità: token per parola. In inglese una parola comune costa uno o due token. In italiano termini come “infrastruttura” o “paleontologia” si spezzano in tre o quattro pezzi. In finlandese o in turco, lingue agglutinanti, la media sale ancora.

Non è solo una questione di eleganza. Se la stessa frase costa il 20% di token in più, costa il 20% in più in API, occupa il 20% in più di contesto e lascia meno spazio a tutto il resto. Un pedaggio invisibile, pagato a ogni singola chiamata.

Quando il vocabolario cambia, i modelli si rompono

I tokenizer non sono interoperabili. Ogni famiglia di modelli ha il suo e a volte cambia anche dentro la stessa famiglia. Passare da un tokenizer all’altro non è come cambiare formato di file: è come cambiare alfabeto a metà libro.

Questo ha conseguenze molto concrete. I pesi non si trasferiscono tra vocabolari diversi, quindi un fine-tuning non è portabile. Le stime di costo e di lunghezza vanno rifatte per ogni modello. I prompt ottimizzati a mano su un tokenizer, per esempio quelli che contano i caratteri per stare dentro un limite, possono sbarellare su un altro.

Capita anche il caso opposto: un’azienda aggiorna il modello e scopre che il conteggio dei token cambia del 15%. I budget di contesto e le finestre di chunking dei sistemi RAG vanno ricalcolati, altrimenti i documenti iniziano a essere troncati a metà frase, con l’aria di un bug del modello che non esiste.

Vocabolario e context window: due numeri che si parlano

La finestra di contesto è misurata in token, non in caratteri. Quindi la domanda “quanto testo ci sta” non ha una risposta unica: dipende dalla lingua, dal tipo di contenuto e dal vocabolario. La lezione sulla context window spiega il limite, qui aggiungo il tassello mancante: quel limite è relativo.

Un esempio pratico. 8.000 token di prosa inglese sono circa 6.000 parole. Gli stessi 8.000 token di prosa italiana, con lo stesso contenuto, coprono meno parole. Se il documento è pieno di sigle, codici, numeri e URL, la resa peggiora ancora, perché quei caratteri si spezzano in molti pezzi.

Prima di incolpare il modello per un troncamento, insomma, conta i token reali. È un controllo da due minuti che risolve settimane di dubbi. Vale anche per capire perché lo stesso prompt costa diverso su due fornitori.

La coda lunga: i token che il modello ha visto poco

Ogni voce del vocabolario riceve aggiornamenti solo quando appare nel testo. Le prime migliaia di token compaiono milioni di volte e hanno rappresentazioni solidissime. Le ultime decine di migliaia compaiono poche volte e restano fragili: è il motivo per cui i nomi propri rari, i termini tecnici e le parole straniere producono risposte meno precise.

C’è un rimedio noto, la composizione. Se il modello non ha mai visto “Baldassarri” come token unico, lo vede come “Bald” più “ass” più “arri”: quei pezzi li conosce bene. Sa ricostruire la forma della parola anche senza averla incontrata. Non è comprensione, è un buon trucco statistico che funziona sorprendentemente spesso.

Il rovescio della medaglia: il modello può produrre parole plausibili ma inesistenti, perché i pezzi sono tutti legittimi mentre l’insieme no. Le allucinazioni sui nomi propri nascono spesso proprio qui, in una catena di sillabe che suona bene e non corrisponde a niente.

Come guardare dentro un vocabolario

Non serve fidarsi. Si può aprire. Le librerie di tokenizzazione sono pubbliche e ogni modello espone il suo vocabolario: Hugging Face lo mette nei file del repository, OpenAI lo distribuisce con le librerie tiktoken, Meta lo include nei pesi di Llama.

Due esperimenti che valgono il tempo speso. Primo: tokenizza la stessa frase in italiano e in inglese e confronta il numero di pezzi. Secondo: cerca nel vocabolario parole italiane intere e guarda quali esistono e quali no. Scoprirai che i termini comuni della lingua ci sono, mentre quelli di nicchia vengono ricomposti da pezzi.

Se lavori con le API, il conteggio si fa con la funzione dedicata, non con una regola del pollice. “Un token vale quattro caratteri” è una media che sull’italiano sbaglia di parecchio. Su un testo di codice sbaglia ancora di più.

Domande frequenti sul vocabolario del tokenizer

Il vocabolario di un modello è come un dizionario?

No. Un dizionario elenca parole con il loro significato, il vocabolario elenca pezzi di testo con il loro ID. Non contiene definizioni, non contiene grammatica e non dice niente su cosa significhi una parola. È un elenco di etichette con una corrispondenza verso stringhe.

Due modelli con vocabolari diversi possono condividere i pesi?

No, non direttamente. I pesi sono indicizzati per ID, quindi lo stesso numero indica cose diverse nei due vocabolari. Esistono tecniche per mappare un vocabolario sull’altro e inizializzare i nuovi embedding come media dei pezzi che li compongono, ma richiedono un passaggio di riaddestramento. Non è un copia e incolla.

Perché l’italiano consuma più token dell’inglese?

Perché il corpus su cui il tokenizer è stato costruito contiene molta più lingua inglese. Le fusioni più frequenti premiano le sequenze inglesi e all’italiano restano pezzi più corti. Il divario si assottiglia nei modelli recenti, che addestrano il tokenizer su corpora multilingue più bilanciati, ma non sparisce.

Posso aggiungere parole al vocabolario di un modello?

Sì, è una pratica reale e si chiama estensione del vocabolario. Si aggiungono le voci nuove, si allarga la matrice di embedding e si inizializzano le righe nuove in modo sensato. Poi serve un fine-tuning, perché quei token sono appena nati e il modello non sa usarli. Conviene quando hai un dominio molto specifico, per esempio una lingua poco rappresentata o un linguaggio di programmazione interno.

Cosa succede se scrivo un token speciale dentro un prompt?

Dipende dal filtro in ingresso. Se la stringa viene tokenizzata come token speciale, il modello può leggerla come un marcatore strutturale e cambiare comportamento. Per questo i tokenizer riservano quelle stringhe e molte API le rimuovono o le spezzano prima di passarle al modello. Non è exploits da film, ma è un dettaglio che chi costruisce applicazioni dovrebbe conoscere.

Un vocabolario più grande significa un modello migliore?

Non da solo. Un vocabolario grande accorcia le sequenze e aiuta le lingue meno rappresentate, ma consuma parametri e lascia molte voci poco addestrate. Un vocabolario piccolo è più compatto ma allunga tutto. La scelta giusta dipende dal mix di lingue, dal tipo di testi e dal budget di calcolo, non da un record da battere.