La tokenizzazione

Un LLM non vede lettere e nemmeno parole. Vede token: pezzi di testo di lunghezza variabile, convertiti in numeri interi. Ogni modello ha il suo vocabolario — l’elenco di tutti i token possibili — e il suo tokenizer, l’algoritmo che fa a pezzi il testo.

Che aspetto ha

Testo:      "Il gatto dorme sul divano"
Token:      ["Il", " gatto", " dorme", " sul", " div", "ano"]
Numeri:     [2460, 78432, 35271, 9182, 1847, 5523]

Nota “divano”: spezzato in “div” + “ano”, perché come pezzo unico non sta nel vocabolario. Nota anche lo spazio attaccato davanti alle parole: fa parte del token.

Perché non usare le parole

Sembrerebbe più naturale, e invece non funziona. Il vocabolario esploderebbe: milioni di parole in tutte le lingue, e ogni voce costa memoria. Le parole nuove sarebbero ingestibili: neologismi, nomi propri, refusi. E si perderebbe la morfologia: “corr-ere”, “corr-endo”, “corr-iamo” condividono una radice che i pezzi di parola permettono di sfruttare.

E allora perché non i singoli caratteri? Perché le sequenze diventerebbero lunghissime — e con l’attention che costa il quadrato della lunghezza, il conto sale in fretta. Ogni carattere inoltre porta pochissima informazione, e il modello dovrebbe faticare per ricostruire il senso.

I pezzi di parola sono il compromesso: vocabolari da 32.000 a 150.000 voci, sequenze gestibili, e nessun testo che il tokenizer non sappia digerire.

Come nasce il vocabolario: BPE

L’algoritmo più diffuso si chiama Byte Pair Encoding, e la sua logica sta in tre mosse ripetute molte volte.

Corpus:              "abab cdab abcd"
Vocabolario iniziale: {a, b, c, d, spazio}

1. conta le coppie:   (a,b) → 4 volte   ← la più frequente
                      (c,d) → 2 volte
2. fondi la coppia:   a + b → "ab"
3. ricomincia:        {a, b, c, d, spazio, ab}

Ripetendo migliaia di volte su un corpus enorme, le sequenze frequenti diventano token singoli. Ecco perché le parole comuni sono un token solo e quelle rare vengono spezzate.

Le conseguenze pratiche

L’italiano costa più dell’inglese. I vocabolari sono addestrati soprattutto su testo inglese, quindi le nostre parole si spezzano più spesso. In inglese un token vale circa 0,75 parole; in italiano circa 0,6-0,7. La stessa frase, tradotta, consuma più contesto e — sulle API a pagamento — più soldi.

I numeri sono fragili. Un numero lungo può essere spezzato in modi imprevedibili, e questa è una delle ragioni per cui l’aritmetica non è il forte dei modelli.

Contare le lettere è difficile. La domanda “quante r ci sono in ferrovia?” mette in crisi i modelli proprio perché non vedono lettere: vedono pezzi già impacchettati.

Come i messaggi diventano token

Questo è il pezzo che manca a chi passa dalla chat all’uso via programma e non capisce perché il modello si comporti in modo strano.

Un modello non riceve “un messaggio dell’utente”: riceve una sequenza piatta di token. La conversazione a ruoli viene appiattita usando marcatori speciali, secondo uno schema che si chiama chat template ed è specifico del modello.

Quello che scrivi tu:
  sistema:   Sei un assistente conciso.
  utente:    Ciao

Quello che riceve davvero il modello:
  <|im_start|>system
  Sei un assistente conciso.<|im_end|>
  <|im_start|>user
  Ciao<|im_end|>
  <|im_start|>assistant

L’ultima riga, lasciata aperta, è il segnale che ora tocca al modello. Formati diversi usano marcatori diversi: ogni famiglia ha il suo.

Perché conta: usando lo schema sbagliato il modello risponde male senza dare alcun errore. Continua il testo invece di rispondere, ignora le istruzioni di sistema, non capisce quando fermarsi. Gli strumenti come Ollama e LM Studio applicano lo schema giusto da soli; usando le librerie di basso livello diventa una tua responsabilità.

C’è anche un risvolto di sicurezza: quei marcatori sono token riservati, e un utente che li scrive nel proprio messaggio può provare a confondere i ruoli. È una delle vie della cosiddetta prompt injection.

Regola pratica: se un modello locale risponde in modo bizzarro, prima di dare la colpa al modello controlla lo schema dei messaggi.

Nessun testo è fuori vocabolario

Viene naturale chiedersi cosa succeda con un carattere mai visto prima: un ideogramma raro, un simbolo matematico, un’emoji nuova.

La risposta è che il vocabolario non parte dai caratteri ma dai 256 byte possibili. Qualunque testo, in qualunque codifica, si scompone in byte — quindi non esiste un input che il tokenizer non sappia rappresentare.

Carattere assente dal vocabolario
    → scomposto nei suoi byte
    → ogni byte è un token valido
    → nessun errore, ma molti token per un solo carattere

Il prezzo è l’efficienza: un carattere raro può costare tre o quattro token invece di uno. Ecco perché i testi pieni di emoji, formule o alfabeti non latini consumano contesto molto in fretta.

Vale la pena sapere anche che il BPE non è l’unico algoritmo in circolazione. Ce ne sono altri, con differenze pratiche modeste, tranne una utile: alcuni non presuppongono che le parole siano separate da spazi, il che li rende adatti alle lingue che non li usano, come il giapponese o il cinese.

Dai token al conto da pagare

È il calcolo che conviene saper fare a mente, perché è quello che decide fra servizio a pagamento e modello in casa.

Le API si pagano a token, con prezzi diversi fra ingresso e uscita: generare costa tipicamente da tre a cinque volte più che leggere.

Esempio: un assistente sui documenti, 200 richieste al giorno

  contesto medio per richiesta   4.000 token in ingresso
  risposta media                   500 token in uscita

  al giorno   200 × 4.500  =    900.000 token
  al mese                   = 27 milioni di token

Su volumi del genere la scelta del modello si misura in centinaia di euro al mese, e diventa la voce che decide l’architettura di tutto il sistema.

Tre modi per far scendere il conto, in ordine di efficacia. Tagliare il contesto inutile: mandare l’intero documento quando bastavano due paragrafi è l’errore più comune e più caro, e un buon recupero per similarità riduce l’ingresso di un ordine di grandezza. Usare il modello giusto: classificare o estrarre dati non richiede il modello più capace, e spesso un modello piccolo in locale fa lo stesso lavoro a costo zero. Sfruttare la cache del prompt: diversi fornitori scontano molto la parte che si ripete identica, purché stia all’inizio.

E torna qui quanto detto sopra sulle lingue: la stessa richiesta in italiano costa circa il venti-trenta per cento in più che in inglese. Su volumi alti, scrivere le istruzioni di sistema in inglese è un’ottimizzazione legittima.

In sintesi

Concetto	In una riga
Token	Pezzo di testo di lunghezza variabile, convertito in un numero
Vocabolario	L’elenco dei token possibili, da 32k a 150k voci
BPE	Fonde ripetutamente le coppie più frequenti per costruire il vocabolario
Costo per lingua	L’italiano consuma più token dell’inglese a parità di testo
Limiti noti	Aritmetica e conteggio di lettere soffrono per come è fatto il tokenizer
Chat template	I ruoli diventano marcatori: lo schema sbagliato rompe tutto in silenzio
Byte-level	Nessun testo è fuori vocabolario, ma i caratteri rari costano molti token
Costo	Si paga a token: tagliare il contesto inutile è la leva più efficace