Cos’è la tokenizzazione: come il testo diventa numeri per il modello

Quando scrivi una frase a un chatbot, dall’altra parte non arriva un testo. Arriva una sequenza di numeri. In mezzo c’è un passaggio silenzioso, la tokenizzazione, che decide come il modello leggerà tutto il resto.

È la parte meno raccontata della catena e una delle più decisive. Da lì dipendono il costo di una chiamata API, la quantità di testo che entra nel contesto e perfino qualche errore che sembra inspiegabile, come un modello che sbaglia una sottrazione elementare.

Qui trovi il meccanismo spiegato dall’inizio, un esempio passo per passo e le trappole che si incontrano guardando un tokenizer da vicino.

Che cos’è la tokenizzazione, in una frase

La tokenizzazione è la procedura che spezza un testo in unità minime e assegna a ciascuna un numero intero. Quelle unità si chiamano token, i numeri si chiamano ID.

Il modello non vede mai le lettere. Riceve solo la lista degli ID e per ognuno va a pescare una riga di numeri in una tabella interna.

La distinzione tra token e tokenizzazione sembra un cavillo e non lo è. Il token è l’unità di misura, la tokenizzazione è il processo che decide dove tagliare. Ed è una decisione presa una volta per tutte, addestrando il tokenizer su un corpus, molto prima che il modello impari qualcosa.

Perché non si può passare il testo grezzo al modello

Un modello linguistico è una funzione matematica. Riceve numeri, moltiplica matrici, restituisce numeri. Non esiste un passaggio in cui entrano lettere.

La prima idea che viene in mente è dare un numero a ogni carattere. Funziona, ma le sequenze diventano lunghissime: una pagina di duemila caratteri diventa duemila passi e il meccanismo di attenzione dei Transformer cresce in modo quadratico rispetto alla lunghezza (ne ho parlato qui).

La seconda idea è dare un numero a ogni parola del dizionario. Elegante, finché non arriva “schedatura”, “tokenizzatore”, un refuso o un nome proprio straniero. Servirebbe un vocabolario enorme e resterebbe comunque la casella della parola sconosciuta.

La soluzione adottata quasi ovunque è la via di mezzo: le sottoparole. Il vocabolario resta compatto, le sequenze restano corte e nessuna stringa resta fuori.

Le quattro fasi di una pipeline

La sequenza canonica è quella descritta nella documentazione di Hugging Face: normalizzazione, pre-tokenizzazione, modello e post-processing. Vale per la maggior parte dei tokenizer in circolazione, anche se i nomi cambiano da libreria a libreria.

1. Normalizzazione

Il testo viene ripulito e uniformato prima di essere tagliato. Spazi doppi, caratteri Unicode equivalenti, maiuscole, a volte gli accenti.

Questo passaggio spiega un comportamento che sorprende molti: in alcuni tokenizer “perché” e “perche” finiscono nello stesso token, perché la normalizzazione toglie il segno diacritico. Nei modelli multilingua recenti la normalizzazione è più conservativa e l’accento resta.

2. Pre-tokenizzazione

Qui il testo viene diviso in blocchi grossolani con regole fisse: spazi, punteggiatura, numeri. Non ci sono ancora ID, solo pezzi.

Il dettaglio che conta è che lo spazio spesso resta attaccato alla parola successiva. ” ciao” e “ciao” sono due token diversi. La distinzione tornerà utile più avanti.

3. Il modello vero e proprio

È l’algoritmo che impara dove tagliare. Tre famiglie dominano la scena.

BPE, byte pair encoding, parte dai caratteri e unisce ripetutamente la coppia adiacente più frequente. “token” e “izzazione” si fondono perché compaiono spesso insieme nel corpus di addestramento. Lo usano Llama, Gemma e buona parte dei modelli open.

WordPiece, la scelta di BERT, unisce invece la coppia che aumenta di più la probabilità del corpus. Risultato simile, criterio diverso.

Unigram fa il contrario: parte da un vocabolario grande e pota le unità meno utili, tenendo le segmentazioni più probabili. SentencePiece, usato da T5 e da molti modelli multilingua, è una libreria che implementa questi algoritmi trattando il testo come un flusso continuo di caratteri, senza bisogno di separare le parole in partenza.

4. Post-processing

Alla fine si aggiungono i token speciali che il modello si aspetta: marcatori di inizio e fine sequenza, separatori tra due frasi, eventuale padding. Si costruisce anche la maschera che dice al modello quali posizioni sono reali e quali sono riempitivo.

Un esempio passo per passo

Prendiamo una frase breve: “La tokenizzazione non è magia.”

Un tokenizer addestrato prevalentemente sull’inglese probabilmente la spezza così:

• La: parola corta e frequente, un token
• token: la radice, con lo spazio davanti
• izzazione: suffisso frequente in italiano, non abbastanza da avere un token tutto suo in alcuni vocabolari
• non: funzione grammaticale, un token
• è: vocale accentata, spesso unita allo spazio
• mag: radice di “magia”
• ia: desinenza
• .: punteggiatura, un token a sé

Otto pezzi per ventinove caratteri. In un tokenizer più orientato all’italiano la parola “tokenizzazione” potrebbe restare intera e i pezzi scendere a sei.

Ogni pezzo riceve un ID, un numero intero senza alcun rapporto con il significato. “mag” potrebbe essere 4.812 e “ia” 361: il modello non sa che sono vicini di casa, lo imparerà solo attraverso la tabella degli embedding.

Ed è qui che si aggancia il passaggio successivo della catena: ogni ID diventa un vettore e quei vettori sono l’unica cosa che il Transformer vede davvero (cosa sono gli embedding).

Byte, non lettere: perché non esiste più la parola sconosciuta

I tokenizer moderni non partono dai caratteri ma dai byte. Il vocabolario di base contiene tutti i 256 valori possibili di un byte, quindi qualunque stringa, in qualunque alfabeto, è rappresentabile.

Conseguenza pratica: la casella della parola sconosciuta è sparita. Un nome inventato, un refuso, un ideogramma o un’emoji vengono spezzati in più pezzi, ma passano sempre.

Il prezzo lo pagano le lingue e i simboli lontani dal corpus di addestramento. Un’emoji può costare due o tre token, un ideogramma cinese occupa tre byte e quindi uno o più token. Su testi molto simbolici il conto sale in fretta.

L’italiano paga un piccolo pedaggio

I vocabolari si costruiscono sul corpus disponibile e quel corpus è largamente inglese. Ne segue un’asimmetria misurabile: a parità di contenuto, un testo italiano consuma più token dell’inglese.

Le cifre che circolano vanno prese come ordini di grandezza, non come leggi: in inglese si parla di circa quattro caratteri per token, in italiano si scende intorno a tre. Su mille parole di prosa, la differenza può valere qualche centinaio di token.

Gli accenti non aiutano. “perché”, “città”, “più”, “così” vengono spesso spezzati in due pezzi, perché la forma accentata è meno frequente della radice senza accento.

Non è un dramma, ma è un fatto da mettere in conto quando si confrontano prezzi e finestre di contesto tra lingue diverse: la stessa idea costa un po’ di più in italiano.

Perché i modelli inciampano sui numeri

I numeri vengono tokenizzati a blocchi, non una cifra alla volta. “1234” può diventare “123” più “4”, oppure “12” più “34”, a seconda del vocabolario.

Il modello quindi non vede quattro cifre allineate: vede due pezzi con un confine arbitrario in mezzo. Le addizioni a più cifre diventano un esercizio di memoria su segmentazioni incoerenti, ed è una delle ragioni per cui i modelli sbagliano con disinvoltura su conti che una calcolatrice risolve in un microsecondo.

Vale anche per le lettere: chiedere quante “r” ci sono in una parola mette il modello davanti a un problema che non può vedere, perché le lettere non esistono più nel suo input.

Token, contesto e memoria: tre effetti pratici

Il primo effetto è la finestra di contesto: quando leggi che un modello regge 128.000 token, quel numero parla di token, non di parole. In italiano corrispondono più o meno a 90.000 parole di testo, con molta variabilità (approfondimento sulla context window).

Il secondo è il costo. Le API fatturano token in ingresso e in uscita, di solito a prezzi diversi e la tokenizzazione è la ragione per cui lo stesso prompt in due lingue non costa uguale.

Il terzo è la memoria del server. La KV cache cresce con il numero di token presenti nel contesto e su richieste lunghe e parallele diventa il vincolo vero (come funziona la KV cache).

Morale operativa: se devi stimare un costo o una dimensione, conta i token, non le parole. Il rapporto cambia con la lingua, con il formato e con la quantità di codice nel testo.

Le trappole che si incontrano più spesso

Lo spazio finale. “ciao” e ” ciao” sono token diversi. In alcuni modelli la differenza si sente nella qualità della continuazione. Se stai componendo un prompt a mano, evita spazi vaganti in fondo alle righe.

Le maiuscole. “Roma” e “roma” possono essere due token distinti, con embedding diversi. Nei nomi propri conviene scrivere la forma corretta, non la scorciatoia.

I refusi. Una lettera sbagliata non rende la parola quasi giusta: la spezza in più pezzi e il modello perde il riferimento. Correggere i typo non è pignoleria, è igiene del prompt.

I token rari. Esistono stringhe finite nel vocabolario ma quasi assenti nel corpus di addestramento. Il caso celebre è SolidGoldMagikarp, un nome utente comparso in un dataset e finito nel vocabolario: chiedere al modello di ripeterlo produceva risposte stranianti. Sono le cosiddette glitch token.

Il codice. Rientri e spazi contano e i tokenizer addestrati sul codice hanno regole dedicate. Un prompt con un blocco di Python consuma più token di quanto sembri a occhio.

Il viaggio di ritorno: la detokenizzazione

Il modello genera ID, non testo. Alla fine della catena c’è un passaggio inverso che ricompone i pezzi e restituisce la stringa.

Il ritorno non è sempre identico all’andata. La normalizzazione può aver cambiato spazi o accenti e alcuni tokenizer non conservano lo spazio iniziale. È il motivo per cui due spazi consecutivi in input possono diventare uno in output.

C’è anche un dettaglio che riguarda la sicurezza: se un filtro controlla il testo per parole chiave, ma il modello ragiona per token, esistono scritture che eludono il controllo senza cambiare il senso. Non è una curiosità da laboratorio, è il motivo per cui i filtri seri lavorano anche a livello di token.

Come valutare un tokenizer

La prima cosa da guardare è la dimensione del vocabolario. Vocabolari grandi accorciano le sequenze ma gonfiano la tabella degli embedding e il conteggio dei parametri. Vocabolari piccoli fanno l’opposto. I numeri tipici vanno da 32.000 a 256.000 unità.

La seconda è la copertura della tua lingua. Un test empirico costa cinque minuti: prendi un tuo testo di mille parole, passalo nel playground del tokenizer e guarda quanti token escono. Se il rapporto supera 1,6 token per parola, quella lingua è trattata male.

La terza è la presenza di un template di chat coerente con i token speciali. È il punto in cui si rompono i modelli usati via API senza leggere la documentazione.

Una cosa da non fare: cambiare tokenizer a un modello già addestrato. Gli ID non hanno significato intrinseco, quindi un vocabolario nuovo rende inutili tutti gli embedding appresi. Si riparte da zero e non conviene quasi mai.

Domande frequenti sulla tokenizzazione

La tokenizzazione è la stessa cosa dell’embedding?

No. La tokenizzazione trasforma il testo in ID, cioè numeri interi che indicano una posizione in un vocabolario. L’embedding trasforma quegli ID in vettori di numeri decimali con un significato geometrico. Sono due passaggi consecutivi e diversi.

Quanti token ci sono in una pagina di testo?

Una pagina di circa 500 parole in italiano sta tra 700 e 900 token, a seconda del vocabolario e della quantità di nomi propri e numeri. Il codice sale, perché rientri e simboli si spezzano.

Perché lo stesso testo costa di più in italiano?

Perché i vocabolari sono sbilanciati verso l’inglese. Radici e suffissi italiani compaiono meno nel corpus di addestramento, quindi vengono spezzati in più pezzi. Il fenomeno è noto come fertilità del tokenizer, ed è uno dei motivi per cui i prezzi dichiarati per token vanno letti con attenzione.

Posso usare lo stesso tokenizer per tutte le lingue?

Sì, ed è quello che fanno i modelli multilingua, ma con efficienze diverse. Un vocabolario costruito su cento lingue dedica a ciascuna meno spazio di uno monolingua, quindi le sequenze si allungano. Il compromesso è tra copertura e compattezza.

I token corrispondono alle sillabe?

Qualche volta, per caso. Non c’è nessuna regola linguistica dietro: il taglio nasce da frequenze e da un algoritmo di compressione. Per questo “zione” può essere un token e “stra” no.

La tokenizzazione influenza la qualità delle risposte?

Sì, in modo indiretto ma reale. Una segmentazione sfortunata nasconde informazioni, per esempio i confini tra le cifre o le lettere di una parola. Anche per questo i modelli più recenti investono in vocabolari più ampi e in tokenizer migliori per codice e numeri.

Fonti tecniche: documentazione Hugging Face sui tokenizer e sul riepilogo degli algoritmi BPE, WordPiece e Unigram.