Token e Tokenizzazione

Cos'è un token

Un token è l'unità minima di testo che un modello di linguaggio elabora, e non coincide con la parola: può essere una parola intera, un pezzo di parola, un carattere o perfino un byte. Il modello non legge come leggiamo noi: converte tutto in una sequenza di numeri interi, ognuno associato a una voce di un vocabolario deciso in partenza. In aula la domanda torna a ogni corso: perché un modello che ti scrive una relazione decente poi sbaglia a contare le lettere di una parola? Perché le lettere non le vede: legge token.

La tokenizzazione è il processo che converte il testo grezzo in questa sequenza di token. È il primo passo di qualsiasi pipeline NLP basata su Transformer e influenza direttamente prestazioni, costi e limiti del modello. Spiega anche perché due testi della stessa lunghezza in caratteri possono avere costi e tempi molto diversi.

Byte Pair Encoding (BPE)

Il BPE (Byte Pair Encoding) è l'algoritmo di tokenizzazione più usato nei LLM moderni, inclusi GPT-4, Claude e Llama. Funziona così: si parte da un vocabolario di singoli caratteri (o byte) e si fondono iterativamente le coppie di simboli più frequenti nel corpus di training.

1. Si parte dal vocabolario di base (es. tutti i byte ASCII + Unicode).
2. Si conta la frequenza di ogni coppia adiacente nel corpus.
3. Si fonde la coppia più frequente in un nuovo simbolo (es. "t" + "h" diventa "th").
4. Si ripete finché il vocabolario raggiunge la dimensione desiderata (tipicamente 32K-100K token).

Il risultato è che le parole comuni diventano un token solo («the», «and», «che») mentre quelle rare vengono spezzate in pezzi. Così si tiene insieme l'efficienza sui testi normali e la capacità di rappresentare qualsiasi cosa. La variante byte-level BPE, usata da GPT-4 e da Claude, lavora sui byte UTF-8 invece che sui caratteri: nulla resta fuori dal vocabolario, ed emoji, ideogrammi e caratteri rari passano sempre, al prezzo di più token. È anche il motivo per cui l'italiano costa più dell'inglese: le nostre parole vengono spezzettate di più.

WordPiece e SentencePiece

WordPiece, usato da BERT e modelli Google, è simile a BPE ma usa una metrica probabilistica (likelihood) invece della frequenza grezza per scegliere le fusioni. I sotto-token non iniziali sono marcati con il prefisso "##" (es. "playing" diventa ["play", "##ing"]).

SentencePiece è un framework che implementa sia BPE che un modello unigram. Lavora direttamente sul testo grezzo, senza una pre-tokenizzazione basata sugli spazi: per questo regge le lingue che non separano le parole con lo spazio (cinese, giapponese) e tratta tutte le lingue allo stesso modo. Il modello unigram, in particolare, parte da un vocabolario ampio e rimuove progressivamente i token meno utili, scegliendo la segmentazione più probabile per ogni testo: un approccio statisticamente più robusto rispetto alle semplici fusioni gerarchiche del BPE.

Context window

La context window (finestra di contesto) è il numero massimo di token che un modello può elaborare in una singola richiesta, includendo sia l'input (prompt) che l'output (risposta). È il limite fisico della "memoria di lavoro" del modello.

Le finestre di contesto sono cresciute molto in fretta:

• GPT-3 (2020): 4.096 token (~3.000 parole)
• GPT-4 (2023): 8K / 32K / 128K token
• Claude (2024): fino a 200K token (~150.000 parole, un intero libro)
• Gemini 1.5 (2024): fino a 1M+ token
• Oggi (settembre 2026): 1M token sui modelli di punta di tutte e tre le famiglie, Claude Opus 5 e Sonnet 5, GPT-6 e Gemini 3.1 Pro

Nonostante finestre più grandi, le prestazioni del modello tendono a degradare per informazioni posizionate nel "centro" di contesti molto lunghi (fenomeno "lost in the middle"). Per questo la RAG serve ancora: recupera solo i frammenti che c'entrano, invece di infilare tutto nel contesto. Riempire la finestra fino al limite aumenta latenza e costi: conviene tenere il contesto corto e mettere le informazioni che pesano di più all'inizio e alla fine del prompt.

Contare i token

Contare i token prima di mandare le richieste serve a non avere sorprese in bolletta. Gli strumenti:

• tiktoken (Python, libreria OpenAI): tiktoken.encoding_for_model("gpt-4") per il conteggio esatto dei token GPT.
• Tokenizer di Hugging Face: AutoTokenizer.from_pretrained("meta-llama/Llama-3") per modelli open source.
• Per Claude serve l'API: il conteggio esatto lo dà l'endpoint messages.count_tokens di Anthropic. Contare i token di Claude con tiktoken dà un numero sbagliato, perché è il tokenizer di un'altra azienda.
• Tool online: platform.openai.com/tokenizer per test rapidi.

Regola empirica per l'italiano: 1 token corrisponde mediamente a 3-4 caratteri o circa 0.6 parole. Un testo di 1.000 parole produce circa 1.500-1.800 token. Per l'inglese il rapporto è più favorevole: ~0.75 parole per token.

Token e costi API

Le API dei LLM fatturano per token elaborati, distinguendo tra input token (il prompt) e output token (la risposta generata). Gli output token costano tipicamente 3-5x in più degli input. Questi sono i listini di settembre 2026, presi dai siti dei produttori, e cambiano spesso:

Per ottimizzare i costi: riduci il prompt al minimo necessario, usa modelli più piccoli per task semplici, metti in cache le risposte alle query che si ripetono e manda le richieste in batch. Molti provider offrono anche il prompt caching, che abbatte il costo delle porzioni di prompt ripetute (come istruzioni di sistema o documenti di riferimento) fino al 90%: conta su chatbot e applicazioni che rimandano ogni volta lo stesso contesto.

Implicazioni per il prompt engineering

La tokenizzazione ha conseguenze pratiche su come si scrivono i prompt:

• Lunghezza del contesto: il prompt di sistema + la conversazione + la risposta attesa devono rientrare nella context window. Un prompt di sistema lungo riduce lo spazio per conversazione e risposta.
• Parole rare e lingue non inglesi: richiedono più token per la stessa quantità di informazione. Un prompt in italiano costa ~30% in più dello stesso contenuto in inglese.
• Codice e formattazione: spazi, indentazione e sintassi consumano token. Il codice minimizzato usa meno token ma è meno leggibile per il modello.
• Numeri: i numeri vengono tokenizzati cifra per cifra o in gruppi irregolari, ed è per questo che i modelli sbagliano i conti.
• Output strutturato: richiedere JSON o formati strutturati consuma più token di output del testo libero, e quindi costa di più.

Capire i token ti dice perché una richiesta costa dieci volte l'altra, e senza si va a sensazione. Il passo successivo è come i token diventano significato: sta in Embedding e Vector Database.