LLM for Dummies #1 — Tokenizzazione: la Tua AI Non Ha Mai Letto una Parola

Questa è la prima puntata di una serie nuova. Niente mercati, niente grafici di capex — solo come funzionano davvero i large language model, spiegati da zero, un pezzo alla volta. Il percorso: tokenizzazione, poi embedding, poi attention, poi training, poi come un modello grezzo diventa un assistente, poi l'inferenza. Alla fine sarete in grado di ragionare su cosa questi sistemi possono e non possono fare, invece di tirare a indovinare.

Si parte da dove parte ogni LLM: dal fatto scomodo che la vostra AI non ha mai letto una parola in vita sua.

Il Modello Non Ha un Alfabeto

Quando mandate del testo a un language model, il modello non riceve testo. Davanti a lui c'è un componente chiamato tokenizer che spezza la frase in pezzi e sostituisce ogni pezzo con un numero. Il modello riceve i numeri. È tutto ciò che vedrà mai.

FIG. 01 // TESTO → NUMERI

Cosa riceve davvero il modello

“I modelli linguistici leggono token, non parole.”

I40␣modelli61863␣lingu27278istici43462␣le514ggono70136␣token6602,11␣non2536␣parole87038.13

ENTRANO 11 NUMERI. IL MODELLO NON VEDE MAI UNA SINGOLA LETTERA.

Ogni pezzo viene cercato in un vocabolario fisso e sostituito dal suo ID. Notate la ␣: lo spazio iniziale fa parte del token — “modelli” con e senza spazio davanti sono due token diversi. E l'italiano si spezza più dell'inglese: “linguistici” costa 2 token, “leggono” pure. ID illustrativi (tokenizer in stile GPT-4).

ILLUSTRAZIONE: TOKENIZZAZIONE BPE · VOCABOLARIO STILE CL100K

Quei pezzi si chiamano token. Un token può essere una parola intera, un pezzo di parola, un segno di punteggiatura, perfino un singolo carattere. La mappatura vive in un vocabolario fisso — una grande tabella decisa una volta sola, prima del training, e congelata per sempre. Il vocabolario sta al modello come la tavola periodica sta alla chimica: ogni testo che leggerà o scriverà è assemblato da quei ~100.000 pezzi e da nient'altro.

Due dettagli della figura meritano un secondo sguardo. Primo, i simboli ␣: lo spazio fa parte del token. "modelli" a inizio frase e "␣modelli" dopo un'altra parola sono due voci diverse del vocabolario. Secondo, gli ID sono arbitrari: non c'è nessuna logica che collega 61863 a "modelli" — è solo un numero di riga nella tabella.

Perché Non Usare le Lettere? O le Parole?

Entrambe le opzioni esistono, ed entrambe perdono.

Le lettere darebbero un vocabolario minuscolo (qualche centinaio di simboli), ma la frase diventa brutalmente lunga — e, come vedremo più avanti nella serie, la lunghezza è il nemico: l'attention del modello deve mettere in relazione ogni posizione con ogni altra, e i costi esplodono in fretta.

Le parole intere tengono le sequenze corte, ma il vocabolario esplode: ogni lingua, ogni nome proprio, ogni refuso, ogni parola nuova mai coniata vorrebbe la sua voce — e tutto ciò che non è in tabella al momento del training diventa un buco illeggibile.

I tokenizer moderni usano un compromesso chiamato Byte Pair Encoding (BPE). L'idea è quasi imbarazzante per quanto è semplice: parti dai singoli caratteri, poi unisci ripetutamente la coppia di pezzi che compare più spesso in una montagna di testo, finché non raggiungi la dimensione di vocabolario desiderata. Le cose frequenti ("il", "zione", "modelli") finiscono in token singoli. Le cose rare ("anticostituzionalissimamente", il vostro cognome, il klingon) vengono sillabate da pezzi più piccoli. Il testo comune si comprime; il testo strano costa di più.

Quella singola scelta di design — la frequenza decide i pezzi — spiega una quantità sorprendente di comportamenti degli LLM.

La Tassa Linguistica

Il BPE impara le sue fusioni dai dati di training, e i dati di training sono in gran parte inglese. Conseguenza: l'inglese si comprime benissimo, le altre lingue meno.

FIG. 02 // LA TASSA LINGUISTICA

Stessa frase, conto in token diverso

I vocabolari dei tokenizer sono addestrati soprattutto su inglese, quindi l'inglese si comprime meglio. La stessa domanda costa ~60% di token in più in italiano — cioè più context window consumata e una bolletta API più alta a parità di contenuto. Conteggi illustrativi (tokenizer in stile GPT-4).

ILLUSTRAZIONE: TOKENIZZAZIONE BPE · 2026

La stessa domanda costa circa il 60% di token in più in italiano che in inglese. E siccome tutto si misura e si paga in token — prezzi delle API, context window, velocità di generazione — quel divario è denaro vero e capacità vera. Una "context window da 200K token" contiene circa 150.000 parole inglesi, ma sensibilmente meno parole italiane, e drammaticamente meno in lingue come il thai o l'amarico che il tokenizer ha imparato appena. Se costruite prodotti in una lingua diversa dall'inglese, state pagando una tassa invisibile decisa anni fa da un contatore di frequenze.

Perché il Modello Non Sa Contare le R di "Strawberry"

Ecco il classico trucco da salotto: chiedete a un LLM quante "r" ci sono in strawberry e guardatelo inciampare. Molti lo leggono come "l'AI è stupida". La risposta vera è più interessante: il modello non ha mai visto le lettere. Il tokenizer gli ha consegnato qualcosa come str + aw + berry — due o tre ID opachi. Chiedergli di contare le lettere è come chiedere a voi di contare le pennellate in una fotografia di un quadro: l'informazione è stata distrutta prima che arrivasse.

Lo stesso meccanismo spiega altri "misteri":

L'aritmetica gli è aliena. "12345" può tokenizzarsi come 123 + 45: il modello non manipola cifre, manipola pezzi che per caso contengono cifre. (I tokenizer moderni trattano i numeri con regole speciali, in gruppi fissi, proprio per attenuare il problema.)
Rime e giochi di parole sono difficili. Suono e ortografia vivono sotto il livello del token, dove il modello non può guardare direttamente.
Esistono i glitch token. I vocabolari contengono ogni tanto voci spazzatura imparate da angoli strani di internet (il famigerato SolidGoldMagikarp), rimaste quasi non addestrate: quando vengono attivate, il modello produce nonsense.

Niente di tutto questo è un fallimento di ragionamento. È una limitazione sensoriale, decisa prima che il modello imparasse alcunché.

I Numeri che Contano

FIG. 03 // ORDINI DI GRANDEZZA

La tokenizzazione in tre numeri

Voci in un vocabolario moderno tipico

~100K

ogni testo mai processato si mappa su questi pezzi

Testo inglese per token, in media

~4 caratteri

≈ ¾ di parola; il metro dietro ogni context window

Token extra dell'italiano rispetto all'inglese

+30-60%

stesso contenuto, conto più alto — varia col tokenizer

Quando un modello dichiara una context window da 200K token, sono circa 150.000 parole inglesi — o sensibilmente meno parole italiane.

VALORI TIPICI: TOKENIZER BPE (FAMIGLIE GPT/CLAUDE/LLAMA) · 2026

Tenete a mente questi tre e molto marketing sugli LLM diventa più facile da decifrare. Quando una pagina prezzi dice "$3 per milione di token in input", ora potete tradurre: circa 750.000 parole inglesi, un romanzo lungo, per tre dollari — e meno di così se scrivete in italiano.

Deep Dive: la Matematica Dietro il Tritatutto

La parte "for dummies" finisce qui — quello che segue assume familiarità con la notazione matematica universitaria. Se non fa per voi, saltate alla fine e ci vediamo alla puntata #2: avete già tutto quello che serve.

Il BPE, Formalmente

Si parte da un vocabolario base V₀ con tutti i 256 valori di byte, così ogni stringa UTF-8 è rappresentabile per costruzione (non può esistere alcun simbolo out-of-vocabulary). Dato un corpus di training C, il BPE esegue un ciclo greedy:

V ← V₀
ripeti k volte:
    (a, b) ← argmax sulle coppie adiacenti di count_C(a, b)
    V ← V ∪ { ab }          # nuovo simbolo fuso
    sostituisci ogni "a b" in C con "ab"

Dopo k fusioni, |V| = 256 + k (tipicamente k ≈ 50.000-200.000). La lista delle fusioni è il tokenizer: in inferenza si riapplicano le stesse fusioni nello stesso ordine. Notate qual è l'obiettivo: ogni fusione riduce al massimo il conteggio di token del corpus — il BPE è un compressore greedy a dizionario, cugino stretto di LZ78. "Numero di token" e "lunghezza compressa" sono la stessa quantità: ecco perché le stringhe frequenti costano 1 token e quelle rare vengono sillabate.

Una ruga pratica: il BPE grezzo fonderebbe allegramente attraverso spazi e punteggiatura, quindi i tokenizer reali prima spezzano il testo con una regex di pre-tokenizzazione (il pattern in stile GPT-4 separa su confini lettera/cifra/punteggiatura e limita le sequenze di cifre a tre — ecco perché "12345" diventa 123+45, e perché l'aritmetica si comporta meglio che nell'era GPT-2 dei pezzi di cifre arbitrari).

Il Trade-off sulla Dimensione del Vocabolario

Perché ~100K voci e non 1K o 10M? Due costi tirano in direzioni opposte.

Lunghezza di sequenza: la self-attention di un Transformer costa O(n² · d) per layer, con n token e larghezza del modello d. Vocabolario più piccolo → sequenze più lunghe a parità di testo → dolore quadratico. Se l'italiano prende 1,5× i token dell'inglese, il suo costo di attention è ~2,25× per lo stesso contenuto.

Dimensione del vocabolario: la matrice di embedding ha |V| · d parametri, e la softmax di output calcola una distribuzione su tutte le |V| voci a ogni posizione generata. Con |V| = 10M e d = 12.288, la sola tabella di embedding varrebbe ~123B parametri — più grande di interi modelli.

L'ottimo sta dove il guadagno marginale di compressione di una voce in più smette di ripagare il suo costo in parametri e softmax. Empiricamente cade nell'ordine di 10⁵ alle scale attuali, e sale man mano che i modelli crescono (i tokenizer di frontiera sono passati da 50K a 100K-200K in quattro anni).

I Token Come Compressione: la Vista in Bits-Per-Byte

Ecco il modo più pulito di vedere perché la scelta del tokenizer contamina ogni benchmark. Un language model assegna al testo una probabilità; la metrica di qualità standard, la perplexity, è definita per token:

PPL = exp( −(1/N) Σᵢ ln p(tᵢ | t₁…tᵢ₋₁) )

Ma N è il conteggio di token — una quantità che dipende dal tokenizer. Due modelli con tokenizer diversi riportano perplexity incomparabili sullo stesso identico testo. Il rimedio è normalizzare per qualcosa di indipendente dal tokenizer, il conteggio grezzo di byte B:

bits per byte = (N / B) · log₂ PPL

L'informazione totale si conserva: un tokenizer che comprime meglio (basso N/B) sposta il lavoro da "tante predizioni facili" a "poche più difficili", ma il prodotto — i bit necessari a codificare il testo — è il numero equo e confrontabile. È anche la lente onesta sulla tassa linguistica: l'N/B più alto dell'italiano non rende i modelli peggiori in italiano di per sé, ma significa che ogni context window contiene meno byte di significato italiano.

L'Altro Tritatutto: Unigram LM

Il BPE non è l'unico gioco in città. Il tokenizer Unigram di SentencePiece (usato dalla famiglia Llama e da T5) inverte la logica: invece di far crescere un vocabolario per fusioni, parte da un grande insieme di candidati e modella probabilisticamente una segmentazione s = (t₁ … tₙ) del testo:

P(s) = Πᵢ p(tᵢ)

La tokenizzazione di una stringa è la segmentazione di massima verosimiglianza — trovata con programmazione dinamica alla Viterbi su tutti i modi di spezzare la stringa, O(L²) nella lunghezza con un tetto alla lunghezza massima del token. Il training alterna EM (ristima le p(tᵢ) date le segmentazioni correnti) e pruning (elimina i token la cui rimozione riduce meno la verosimiglianza del corpus) fino alla dimensione di vocabolario voluta. L'Unigram tende a produrre spezzature un po' più naturali linguisticamente e abilita la subword regularization — campionare segmentazioni subottimali durante il training come data augmentation.

Perché Esistono i Glitch Token, Meccanicamente

Chiudiamo il cerchio su SolidGoldMagikarp: il corpus su cui si addestra il tokenizer (dove si imparano le fusioni) e il corpus su cui si addestra il modello non sono lo stesso. Una stringa frequente nel primo ma quasi assente nel secondo ottiene un token dedicato la cui riga di embedding riceve pochissimi aggiornamenti di gradiente durante il training. Resta vicina alla sua inizializzazione casuale — un vettore fuori dalla varietà appresa. Datelo in pasto al modello e ogni layer a valle processa spazzatura. La lezione generalizza: la competenza su un token è limitata dalla sua esposizione in training, cosa invisibile dall'esterno.

Prossima Tappa

I numeri del tokenizer sono solo ID — la riga 61863 non dice nulla su cosa significhi "modelli". La magia comincia al passo successivo, dove ogni ID viene trasformato in un vettore di coordinate che codificano il significato come geometria: le parole come punti nello spazio, dove "re" e "regina" finiscono vicini — e dove le segmentazioni di Viterbi e le righe di embedding appena incontrate diventano gli oggetti su cui il modello calcola davvero. Sono gli embedding — puntata #2 di questa serie.

Roadmap della serie: tokenizzazione (siete qui) → embedding → attention e il Transformer → training → da autocomplete ad assistente → inferenza. Domande a cui vorreste una risposta strada facendo? Scrivetemi.