Chiedete a un modello linguistico quante «r» ci sono in «strawberry» e c’è una buona probabilità che sbagli. Non perché non sappia contare, ma perché non ha mai visto la parola «strawberry» lettera per lettera: l’ha vista come due o tre blocchi opachi, frammenti di parola trattati come unità indivisibili. Quei blocchi si chiamano token, e il processo che li produce — la tokenizzazione — è la prima cosa che accade a qualunque testo prima di entrare in un LLM. È anche una delle più sottovalutate: molti comportamenti apparentemente misteriosi dei modelli si spiegano guardando cosa succede in questo passaggio.
Il dilemma del vocabolario e il Byte Pair Encoding, con l’esempio svolto e trenta righe di Python, sono nel libro.
Leggi «Come si spezza il testo: il Byte Pair Encoding» nel libro →
Il problema: i modelli mangiano numeri, non lettere
Una rete neurale non elabora testo: elabora numeri. Serve quindi una convenzione per trasformare «il gatto dorme» in una sequenza di interi. La soluzione ingenua ha due estremi, entrambi scomodi.
Primo estremo: un numero per ogni parola. Il vocabolario esploderebbe — l’italiano ha centinaia di migliaia di forme flesse, e ogni refuso, ogni nome proprio, ogni parola nuova («dobbiamo aggiungere ‘agentico’?») resterebbe fuori. Le parole mai viste diventerebbero un unico simbolo «sconosciuto», un buco nero informativo.
Secondo estremo: un numero per ogni carattere. Il vocabolario sarebbe minuscolo e niente resterebbe fuori, ma le sequenze diventerebbero lunghissime: una frase di venti parole richiederebbe oltre cento passi di elaborazione, e il modello spenderebbe la sua capacità a reimparare da zero che «g-a-t-t-o» forma un’unità di significato.
La tokenizzazione moderna è il compromesso tra i due estremi: frammenti di parola, detti subword. Le parole frequenti restano intere («gatto» è un token unico), quelle rare vengono spezzate in pezzi riutilizzabili («gattopardesco» diventa qualcosa come «gatto» + «pard» + «esco»). Nessuna parola è mai davvero sconosciuta, e le sequenze restano corte.
BPE: comprimere spesso, tagliare bene
L’algoritmo dominante si chiama Byte Pair Encoding, ed è nato nel 1994 come tecnica di compressione dati; è stato adattato al linguaggio naturale nel 2016. L’idea è di una semplicità quasi imbarazzante, ed è più facile capirla come una ricetta:
- Parti da un vocabolario minimo: i singoli caratteri (o, nella variante byte-level, i 256 byte possibili).
- Scorri un corpus enorme di testo e conta quale coppia di simboli adiacenti compare più spesso.
- Fondi quella coppia in un nuovo simbolo unico e aggiungilo al vocabolario.
- Ripeti: ad ogni giro nasce un simbolo nuovo, sempre più lungo, sempre più «parola».
- Fermati quando il vocabolario raggiunge la dimensione voluta — tipicamente tra 32.000 e 100.000 e passa token nei modelli attuali.
È come costruire un frasario per un viaggio: all’inizio hai solo l’alfabeto, poi impari le sillabe che senti in continuazione («zio», «che»), poi le parole intere più comuni («grazie», «quanto costa»), e solo alla fine — se c’è spazio nel frasario — le espressioni rare. Ciò che è frequente merita una voce propria; ciò che è raro si ricostruisce componendo i pezzi.
Il risultato è un vocabolario che riflette le statistiche del corpus di addestramento. E qui cominciano le conseguenze interessanti.
Dalla parola ai numeri: cosa vede davvero il modello
Una volta costruito il vocabolario, tokenizzare un testo nuovo significa applicare le fusioni imparate, nello stesso ordine, e sostituire ogni frammento con il suo indice numerico. La parola «straordinariamente», ad esempio, potrebbe diventare tre token — qualcosa come «stra», «ordinaria», «mente» — e quindi tre interi. È tutto ciò che il modello riceve: tre numeri. Non le lettere, non l’etimologia, non i confini di parola così come li percepiamo noi.
La pipeline di tokenizzazione: una parola rara viene spezzata in subword presenti nel vocabolario, e ogni subword diventa un id numerico. Gli id mostrati sono di fantasia: dipendono dal tokenizer specifico.
Questa rappresentazione spiega il caso «strawberry»: per contare le lettere di una parola il modello dovrebbe prima «smontare» token che ha sempre trattato come atomi. È come chiedere a qualcuno quante mattonelle ci sono sotto la moquette di casa sua: ci vive sopra ogni giorno, ma non le ha mai viste una per una.
Un LLM non legge lettere e non legge parole: legge un alfabeto statistico costruito su misura del suo corpus di addestramento. Tutto ciò che quel corpus rappresentava male, il modello lo vedrà male.
Le conseguenze pratiche: costi, lingue, numeri
La prima conseguenza è economica. Le API dei modelli si pagano a token, e la tokenizzazione decide quanti token costa il vostro testo. Poiché i vocabolari sono costruiti su corpus dove l’inglese domina, l’inglese è la lingua più «compressa»: una frase inglese usa spesso meno token della sua traduzione italiana, e molte lingue non latine ne usano ancora di più. A parità di contenuto, scrivere in italiano costa di più e consuma più in fretta la finestra di contesto. Non è una scelta politica: è statistica del corpus. Ma l’effetto è reale.
La seconda riguarda i numeri e il codice. Un numero come 12345 può essere spezzato in modi poco intuitivi — magari «123» + «45» — e questo rende l’aritmetica più fragile di quanto sarebbe con una rappresentazione cifra per cifra. Per il codice sorgente vale il contrario: i tokenizer moderni sono addestrati anche su repository di software, e trattano bene indentazioni e simboli che un tokenizer «letterario» sprecherebbe.
La terza è più sottile: i confini dei token sono invisibili ma influenzano il comportamento. Uno spazio prima di una parola può cambiarne la tokenizzazione (in molti vocabolari " gatto" e "gatto" sono token diversi), e stringhe insolite — sequenze rare finite per caso nel vocabolario — possono produrre risposte anomale. Quando un prompt funziona in un modo e la sua variante apparentemente identica in un altro, la tokenizzazione è uno dei primi posti dove guardare.
Un compromesso, non una legge di natura
Vale la pena ricordare che BPE è una scelta ingegneristica, non un teorema. Esistono alternative con filosofie simili e dettagli diversi, e una linea di ricerca attiva esplora modelli che lavorano direttamente sui byte, senza vocabolario appreso, delegando alla rete anche il compito di scoprire dove finisce un’unità di significato e ne comincia un’altra. Se questi approcci matureranno, alcune delle stranezze descritte qui sopra spariranno — insieme, forse, a qualche vantaggio di efficienza che oggi diamo per scontato.
Fino ad allora, il tokenizer resta il paio d’occhiali attraverso cui ogni LLM guarda il mondo: non lo si nota finché funziona, ma deforma tutto ciò che passa.
Perché ti riguarda
Se usi gli LLM via API, la tokenizzazione è la voce nascosta della tua bolletta: stimare i token del tuo testo italiano — non delle parole — è il modo corretto di prevedere i costi e di capire quanto contesto ti resta davvero. Se costruisci applicazioni, sapere che numeri, spazi e lingue diverse vengono spezzati in modo diseguale ti evita bug sottili nei prompt e nelle valutazioni. E se semplicemente usi un chatbot, ora sai perché a volte inciampa su richieste che sembrano banali: non è stupidità, è che gli hai chiesto di contare le mattonelle sotto la moquette.

I commenti sono riservati agli iscritti.
Accedi per commentare