13 – Tokenizzazione: come un modello spezza parole, numeri e formule

Scriviamo matematica e immaginiamo una parola. Il modello, prima di elaborarla, riceve una sequenza di identificatori: con un vocabolario la divisione è mat | ematic | a, con un altro mat | emat | ica. Aggiungendo uno spazio iniziale, uno dei due passa da tre token a due. Sono risultati di una prova locale, che riprodurremo fra poco.

Nel percorso Capire l’IA abbiamo visto come le parole diventano numeri. Qui scendiamo dentro il meccanismo: come vengono scelti i frammenti, perché cambiano fra vocabolari e quali conseguenze hanno per italiano, codice, numeri e formule.

In breve

• Un token può rappresentare una parola, un frammento, punteggiatura o una sequenza di byte; i confini dipendono dal tokenizer.
• Gli ID hanno significato soltanto rispetto al vocabolario del modello.
• Spazi, maiuscole e rappresentazioni Unicode possono modificare la sequenza.
• Il conteggio va eseguito sul testo reale con il tokenizer corretto.
• Meno token può significare meno risorse a parità di condizioni, ma non dimostra una maggiore qualità delle risposte.

Dal testo agli ID: il punto di ingresso

Un tokenizer traduce il testo in unità di un vocabolario finito e assegna loro degli ID. Il modello usa questi identificatori per recuperare le rappresentazioni numeriche apprese, gli embedding. Il numero 8637 non misura quanto un frammento sia matematico o importante: identifica una voce della tabella.

La documentazione della pipeline di Hugging Face distingue normalizzazione, pre-tokenizzazione, segmentazione e post-elaborazione. Non tutte le implementazioni applicano le stesse trasformazioni: alcune normalizzano il testo, altre preservano i byte; possono inoltre aggiungere marcatori speciali richiesti dal modello. Per questo il solo nome dell’algoritmo non descrive l’intero comportamento.

Come BPE costruisce i frammenti

Il Byte Pair Encoding, o BPE, costruisce progressivamente un vocabolario unendo coppie di simboli. Durante l’addestramento del tokenizer si contano le coppie adiacenti nel corpus e si introducono fusioni. Il lavoro di Sennrich, Haddow e Birch del 2016 ha mostrato l’utilità delle unità subword per affrontare le parole rare nella traduzione neurale.

Facciamo un esempio didattico, limitato ai caratteri dentro ogni parola: casa compare quattro volte e caso tre. Le coppie c,a e a,s hanno entrambe frequenza sette. Supponiamo che il criterio di spareggio scelga la prima:

• c + a → ca: le parole diventano ca | s | a e ca | s | o.
• ca + s → cas: questa coppia compare sette volte; otteniamo cas | a e cas | o.
• cas + a → casa: la coppia compare quattro volte, contro le tre di cas,o.

L’esempio omette marcatori e altre regole delle implementazioni reali. Illustra però un punto: le fusioni nascono dalle frequenze del corpus, non da un’analisi grammaticale. Quando usiamo un tokenizer già addestrato, applichiamo il suo vocabolario e le sue regole: non lo riaddestriamo a ogni domanda. La spiegazione BPE di Hugging Face approfondisce anche la variante che parte dai byte.

Stessa parola, vocabolari diversi

Nella nostra prova cl100k_base codifica matematica con gli ID [8637, 12519, 64]; o200k_base usa [8872, 45146, 1578]. Il numero di token coincide, ma cambiano sia i frammenti sia gli identificatori.

Per " matematica", con uno spazio davanti, il primo mantiene tre token, mentre il secondo produce [164393, 1578]: lo spazio è incluso nel frammento iniziale. Tokenizzare parole isolate e sommare i conteggi può quindi dare un risultato diverso dal tokenizzare il testo completo. La prova mostra anche perché gli ID di un vocabolario non vadano trasferiti a un modello che ne usa un altro.

Un esperimento su italiano, inglese, codice e formule

Ho eseguito il confronto il 23 ottobre 2026 con tiktoken 0.14.0 e i due encoding indicati. Sono conteggi delle stringhe esatte riportate sotto, senza messaggi di chat o marcatori aggiuntivi. Non sono state effettuate chiamate a un modello generativo.

La frase italiana occupa nove token con il primo encoding e sette con il secondo. Quella inglese passa invece da cinque a sei. Due esempi non misurano l’efficienza di un’intera lingua, ma bastano a smentire l’idea che un vocabolario più grande produca sempre meno token su qualunque stringa.

Perché l’italiano merita una misura propria

Un archivio italiano può contenere forme flesse, apostrofi, nomi di enti, sigle e riferimenti amministrativi. Per capire quanto spazio occupa davvero, prenderei un campione rappresentativo di quei documenti e misurerei token, caratteri e byte per ciascun encoding candidato, mantenendo costante la preparazione dei testi.

Il rapporto token/parola è utile come descrizione del campione, purché sia definito anche come contiamo le parole. Trasformarlo in una regola universale per stimare qualunque documento può portare a budget sbagliati. Per un sistema documentale contano inoltre tabelle, elenchi e metadati, non soltanto la prosa.

1729 non entra necessariamente come un unico numero

Nella prova 1729 diventa 172 | 9 in entrambi gli encoding. Il codice che li definisce contiene una pre-segmentazione delle cifre in gruppi lunghi fino a tre: è una scelta implementativa precisa, non una legge della matematica.

Con 1.729,00 € otteniamo sei token: cifre, separatori e simbolo monetario contribuiscono alla sequenza. Da questo non segue che il modello sappia interpretare correttamente un importo italiano o calcolarne l’IVA. Per somme, confronti e riconciliazioni, proporrei verifiche numeriche e strumenti di calcolo: il tokenizer descrive la rappresentazione, non certifica il risultato.

Codice e formule: il testo è anche una struttura

Il codice print(1729) usa cinque token in entrambi i casi. Il tokenizer non sostituisce il parser di Python: parentesi e cifre sono parti dell’input, mentre la validità del programma deve essere controllata con gli strumenti del linguaggio. La stessa attenzione vale per indentazione, nomi e stringhe.

La notazione x² + y² = 1 richiede otto token; x^2 + y^2 = 1 ne richiede dieci. Sono due rappresentazioni leggibili della stessa equazione in un contesto matematico, ma non istruzioni intercambiabili in ogni software: in Python l’operatore di potenza è **. Analogamente, \frac{1}{2} usa sette token e 1/2 tre. La scelta del formato deve preservare significato e compatibilità, prima di inseguire un conteggio più basso.

Accenti Unicode: uguale aspetto, sequenze diverse

La parola caffè può contenere la lettera precomposta è (U+00E8), oppure e seguita dall’accento combinante (U+0065 e U+0300). Le due stringhe possono apparire uguali sullo schermo, ma hanno byte diversi. Nel nostro controllo hanno lo stesso numero di token per ciascun encoding, con ID differenti.

Contare soltanto i token non rivela dunque tutte le differenze nell’input. La normalizzazione Unicode può essere utile in una pipeline documentale, ma va progettata conservando l’originale e verificando gli effetti sul dominio. Ricopiare il testo attraverso editor diversi può cambiare ciò che stiamo misurando.

Quanto incide su costi e contesto

Se un servizio tariffa separatamente input e output per milione di token, una stima elementare è C = (Nᵢ × Pᵢ + Nₒ × Pₒ) / 1.000.000. I prezzi vanno verificati sul servizio concreto; cache, altri componenti e modalità di elaborazione possono richiedere voci distinte. Anche il formato della conversazione aggiunge materiale rispetto alle sole stringhe della nostra prova.

Il tokenizer è inoltre associato al modello: non possiamo sceglierne arbitrariamente uno più compatto e passargli quei nuovi ID. La ricerca di Dagan, Synnaeve e Rozière studia proprio l’impatto delle scelte di tokenizzazione e gli interventi necessari nell’adattamento. Per chi sviluppa un’applicazione, il primo passo pratico è misurare il carico reale con la configurazione corretta.

Prova anche tu: un laboratorio in Colab

Esegui il seguente codice. Nella prima cella di Colab togli il commento davanti a %pip install; in un terminale usa python -m pip install tiktoken==0.14.0. La libreria non richiede una chiave API per questa prova; al primo uso può scaricare i file dei vocabolari.

# Prima cella di Colab:
# %pip install tiktoken==0.14.0
import tiktoken
from importlib.metadata import version
testi = [
    "La matematica è bellissima.",
    "Mathematics is beautiful.",
    "matematica", " matematica",
    "1729", "1.729,00 €", "print(1729)",
    "x^2 + y^2 = 1", "x² + y² = 1",
    r"\frac{1}{2}", "1/2",
]
print("tiktoken", version("tiktoken"))
for nome in ("cl100k_base", "o200k_base"):
    enc = tiktoken.get_encoding(nome)
    for testo in testi:
        ids = enc.encode(testo)
        parti = [
            enc.decode_single_token_bytes(i) for i in ids
        ]
        assert b"".join(parti) == testo.encode("utf-8")
        assert enc.decode(ids) == testo
        print(nome, repr(testo), len(ids), ids, parti)

Confronta i conteggi con la tabella, poi sostituisci i testi con un riferimento amministrativo, una riga di codice e una formula tuoi. Le due istruzioni assert verificano la ricostruzione del testo. La stampa delle parti come byte evita di confondere una porzione di carattere UTF-8 con un carattere completo.

Dove le cose si complicano

Il nostro esperimento osserva due vocabolari su undici stringhe. Non misura comprensione, accuratezza matematica, velocità di generazione o costi di un servizio commerciale. Per collegare tokenizzazione e qualità servirebbero compiti definiti, dati sufficienti e confronti che controllino anche le altre differenze fra modelli.

Inoltre BPE è una famiglia di tecniche, non l’unica soluzione. SentencePiece offre strumenti per apprendere unità subword direttamente da frasi grezze. Algoritmo, normalizzazione, vocabolario e marcatori concorrono al comportamento effettivo: conviene documentare l’intera configurazione.

Una checklist pratica

• Sto usando il tokenizer e il formato di input previsti dal modello?
• Ho misurato il testo completo, inclusi spazi, simboli e istruzioni aggiuntive?
• Il campione rappresenta davvero lingua e documenti dell’applicazione?
• Conservo gli originali e controllo gli effetti della normalizzazione?
• Valuto separatamente conteggio dei token e correttezza delle risposte?

Il primo modo di capire come un modello legge un testo è osservare le unità con cui quel testo gli viene presentato.

DALLA MIA BIBLIOTECA

• Sebastian Raschka — Sviluppare Large Language Model. Costruire da zero LLM su misura. Un percorso pratico dalla preparazione dei testi alle componenti di un modello, già recensito su Angolo 1729.

Per approfondire

• R. Sennrich, B. Haddow, A. Birch, Neural Machine Translation of Rare Words with Subword Units, ACL 2016.
• T. Kudo, J. Richardson, SentencePiece: A simple and language independent subword tokenizer and detokenizer for Neural Text Processing, EMNLP 2018.
• Hugging Face, spiegazione di BPE e pipeline di tokenizzazione.
• Repository ufficiale tiktoken, usato nella prova con versione 0.14.0.
• G. Dagan, G. Synnaeve, B. Rozière, Getting the most out of your tokenizer for pre-training and domain adaptation, 2024.

Nel percorso: 03 — Context engineering per il budget di contesto; 09 — LLM in produzione per costi e prestazioni.

← Torna al percorso Dentro l’IA