Un numero migliore può nascondere un’unità diversa
Stiamo scegliendo un modello linguistico per leggere rapporti di manutenzione. Due candidati sono valutati sullo stesso testo: il primo ha perplexity 2, il secondo circa 3,17. Sapendo che una perplexity più bassa è solitamente preferibile, saremmo tentati di scegliere il primo. Ma che cosa conta il denominatore? Se un modello divide una parola in tre frammenti e l’altro la tratta come un unico elemento, stanno facendo un numero diverso di previsioni. Confrontare direttamente i due valori può premiare il modo di dividere il testo anziché la probabilità assegnata al testo stesso.
Abstract. Deriviamo la perplexity dalla probabilità dei token e mostriamo un’inversione della classifica con tre modelli probabilistici sintetici. Normalizziamo poi la sorpresa totale per i byte dello stesso testo, distinguendo questo aggiustamento da una valutazione universale delle capacità. Analizziamo aggregazione dei documenti, Unicode, contesto e differenza fra probabilità di una tokenizzazione e probabilità di una stringa. Non addestriamo né eseguiamo una rete neurale: le probabilità condizionate sono dati didattici espliciti e tutti i risultati numerici vengono ricalcolati in Python.
Token e probabilità: che cosa viene previsto
Un tokenizer trasforma il testo in una sequenza di elementi chiamati token. Possono corrispondere a parole, frammenti, spazi o altre unità del vocabolario. Un modello autoregressivo assegna una probabilità al token successivo usando quelli precedenti. Per valutare un testo già noto, guardiamo la probabilità che il modello assegna proprio ai token osservati, non a quelli che avrebbe scelto come risposta più probabile. In questo articolo consideriamo soltanto questo tipo di valutazione causale.
La probabilità di un percorso di token si ottiene moltiplicando le probabilità condizionate. “Condizionata” significa che ogni valore può dipendere dal prefisso: non stiamo assumendo token indipendenti. Per evitare prodotti molto piccoli sommiamo i logaritmi negativi. Con logaritmi in base 2, la quantità si misura in bit e viene spesso interpretata come sorpresa: un evento con probabilità 1/2 vale un bit, uno con probabilità 1/4 vale due bit.
N è il numero dei token effettivamente valutati; L_bits è la sorpresa totale. La perplexity, abbreviata PPL, esponenzia la sorpresa media per token. Si può calcolare anche con logaritmi naturali ed esponenziale: il risultato è uguale se base e operazione inversa sono coerenti. PPL non è una percentuale di risposte corrette. Una probabilità zero per un token osservato produce sorpresa infinita: eventuali approssimazioni numeriche devono essere dichiarate, non corrette silenziosamente.
La frase guida: “motore caldo”
Manteniamo la stessa frase italiana in tutte le versioni dell’articolo, perché cambiarla cambierebbe l’esperimento. “motore caldo” contiene dodici byte UTF-8: sei lettere, uno spazio e cinque lettere. Il modello sintetico A la divide in [mo, to, re, spazio, cal, do], sei token. Assegna probabilità 1/2 a ciascun token osservato, dato il suo prefisso. La probabilità del percorso è (1/2)⁶=1/64, la sorpresa totale sei bit e PPL=2^(6/6)=2.
Il modello B usa invece tre token: [motore, spazio, caldo], con probabilità 1/4 ciascuno. Otteniamo (1/4)³=1/64 e ancora sei bit totali. Ma la media è ora due bit per token: PPL=2^(6/3)=4. Il valore è raddoppiato senza cambiare la probabilità del percorso corrispondente alla frase. Non abbiamo dimostrato che A capisca meglio il dominio: abbiamo cambiato il numero delle unità su cui facciamo la media.
Il modello C usa i tre token di B ma probabilità [1/2, 1/4, 1/4]. Il prodotto è 1/32: assegna alla sequenza il doppio della probabilità di A. La sorpresa scende a cinque bit. Tuttavia PPL=2^(5/3)≈3,1748, ancora superiore a 2. Una classifica ingenua sceglierebbe A, pur avendo C assegnato più probabilità al percorso della frase. È il caso promesso nell’apertura. Le altre probabilità del vocabolario non sono simulate: possono ricevere la massa residua necessaria a completare ciascuna distribuzione.
| Modello | Token | Probabilità percorso | Bit totali | PPL | Bit/byte |
|---|---|---|---|---|---|
| A | 6 | 1/64 | 6 | 2 | 0.5 |
| B | 3 | 1/64 | 6 | 4 | 0.5 |
| C | 3 | 1/32 | 5 | 3.1748 | 0.4167 |
Usare un denominatore comune: i byte del testo
Per togliere questa particolare differenza di unità dividiamo la sorpresa totale per B, il numero di byte UTF-8 del testo effettivamente valutato. Chiameremo il risultato BPB, bits per byte. La lettera B qui è un conteggio, non il nome del modello della tabella. Il denominatore deve riferirsi esattamente agli stessi contenuti che contribuiscono al numeratore:
Nel caso guida A e B danno entrambi 6/12=0,5 bit per byte. C dà 5/12≈0,4167. Il confronto torna coerente con la probabilità dei percorsi: A e B sono equivalenti per questa frase, C assegna più probabilità. La seconda forma della formula spiega perché non basta confrontare PPL: bisogna conoscere anche N e B, non soltanto il numero pubblicato. Una normalizzazione diversa non crea nuove evidenze; rende esplicita l’unità della misura che abbiamo già calcolato.
Un byte non è una lettera, e una lingua non è un’altra
Il caso ASCII è comodo perché ogni carattere occupa un byte, ma UTF-8 non funziona così per tutto il testo. Il programma verifica che “é” precomposta occupa due byte, la sequenza visivamente simile “e” più accento combinante ne occupa tre e il carattere cinese “热” ne occupa tre. La normalizzazione Unicode NFC porta le prime due rappresentazioni alla stessa forma, ma applicarla è una scelta di preprocessing da fissare prima della valutazione, identica per tutti i candidati.
Confrontare modelli sullo stesso corpus byte per byte elimina l’ambiguità del denominatore. Non rende però equivalenti un corpus italiano e la sua traduzione cinese: cambiano byte, costruzioni linguistiche e distribuzioni dei contenuti. Un BPB più basso in una lingua non dimostra da solo competenza superiore in quella lingua. Nei nostri quattro testi editoriali la traduzione preserva il ragionamento, mentre la stringa sperimentale resta intenzionalmente identica.
Come sommare i documenti senza cambiare la domanda
Supponiamo un documento di 12 byte con sorpresa di 6 bit e uno di 120 byte con sorpresa di 12 bit. I BPB individuali sono 0,5 e 0,1. La media semplice è 0,3, ma il corpus contiene 132 byte e 18 bit: il BPB complessivo è 18/132≈0,13636. La media semplice dà lo stesso peso a ogni documento; il rapporto delle somme dà lo stesso peso a ogni byte. Entrambe sono statistiche definibili, ma rispondono a domande diverse. Non si deve presentare la prima come se fosse il secondo.
La stessa cautela vale per PPL: non si ottiene la perplexity del corpus facendo la media aritmetica delle perplexity dei documenti. Si sommano le perdite dei token valutati, si divide per il loro conteggio e poi si esponenzia. Se l’obiettivo aziendale è dare peso uguale a ciascuna pratica, un’aggregazione per pratica può essere voluta, ma deve essere dichiarata e affiancata alla misura del corpus. Il denominatore è una scelta di valutazione, non un dettaglio del report.
Contesto, maschere e confini fanno parte della misura
Il modello non assegna una probabilità al token nel vuoto: la assegna dato un contesto. Se un metodo di valutazione dimentica il testo precedente ogni volta che apre un nuovo blocco, modifica il problema predittivo. La documentazione Hugging Face sulla perplexity discute finestre disgiunte e scorrevoli, con codice per evitare di contare due volte i token sovrapposti. Abbiamo letto definizione, metodo e listato; non abbiamo eseguito il benchmark GPT-2 riportato dalla fonte e non ne adottiamo i numeri come nostri risultati.
Nel nostro esempio tutte le probabilità del percorso vengono conteggiate a partire da un contesto iniziale convenzionale. Non includiamo un token di fine sequenza: valutiamo la continuazione testuale, non la decisione di terminare lì. In un confronto reale bisogna mantenere coerenti inizio, fine, prompt, template, separatori fra documenti e token esclusi dalla perdita. Se si contano soltanto alcune risposte, non si può dividere la perdita per tutti i byte del prompt e della risposta: il risultato sarebbe artificialmente più basso.
Anche assegnare la stessa finestra di 1.000 token a due tokenizer non garantisce lo stesso contesto testuale: possono coprire quantità diverse del rapporto. Il confronto deve indicare quale opportunità informativa viene concessa a ciascun modello. Per il caso sintetico questa difficoltà non si presenta: la frase è breve e ogni probabilità è definita sul proprio intero prefisso. Per un corpus reale resta una scelta sperimentale da documentare, non un problema risolto automaticamente dai bit per byte.
La cautela più sottile: percorso e stringa non sono sempre la stessa probabilità
Finora abbiamo detto deliberatamente “probabilità del percorso”. Se due sequenze diverse di token si decodificano nello stesso testo, la probabilità complessiva di quel testo deve sommare i contributi delle sequenze ammesse, secondo una convenzione coerente di confine e terminazione. Un tokenizer deterministico può scegliere un percorso canonico, ma il modello generativo potrebbe assegnare probabilità anche ad altri percorsi che producono gli stessi caratteri. Valutare soltanto il percorso canonico non esegue quella somma.
Un esempio astratto rende visibile la differenza: due percorsi completi e mutuamente esclusivi, entrambi decodificati come “ab”, hanno probabilità 0,02 e 0,08. La probabilità della stringa è 0,10, mentre un valutatore che seleziona il primo registra 0,02. Non abbiamo implementato la marginalizzazione su tutti i percorsi di un tokenizer reale. I BPB del nostro esperimento vanno quindi letti come perdita normalizzata del percorso scelto, non come promessa di una likelihood testuale esatta e indipendente da qualsiasi tokenizzazione.
Che cosa scegliere per un modello verticale
Su rapporti di manutenzione tenuti fuori dall’addestramento, una perdita linguistica può misurare quanto il modello considera prevedibile il testo del dominio. Non misura automaticamente se identifica il guasto corretto, conserva le unità, rispetta una procedura o inventa una causa. Un modello può assegnare alta probabilità a frasi frequenti ma inutili per la decisione. La selezione deve quindi affiancare alla misura linguistica prove del compito, con errori rilevanti e protocollo separato. Non riportiamo qui risultati applicativi che non abbiamo eseguito.
Risposta: prima della classifica, chiarire l’unità
Due perplexity diverse non indicano necessariamente due qualità linguistiche diverse: possono mediare la sorpresa su unità diverse. Nel nostro caso A ottiene 2 e C circa 3,17, ma C assegna più probabilità alla sequenza della stessa frase. Normalizzare per i byte rende evidente questo fatto, senza risolvere da solo contesto, preprocessing, percorsi alternativi o utilità nel compito. La domanda corretta è dunque quale perdita abbiamo misurato, su quali contenuti e con quali condizioni. Solo dopo ha senso confrontare i numeri.
Il listato riproduce i tre punteggi. Nell’archivio sono inclusi token espliciti, probabilità, controlli sulla ricostruzione della frase, aggregazione, esempi Unicode e dati del grafico. Tutto è deterministico, senza seed. Il calcolo dei punteggi percorre una volta N probabilità, quindi costa O(N); i risultati non comprendono il costo di inferenza di un modello reale. La figura deriva dai numeri salvati in JSON. La fonte documentale seguente sostiene definizione e cautela metodologica; gli esempi numerici sono analisi didattica autonoma.
Fonte e codice
Hugging Face Transformers — Perplexity of fixed-length models.
from math import log2
text = "motore caldo"
for name, probs in [("A", [.5]*6), ("B", [.25]*3), ("C", [.5,.25,.25])]:
bits = -sum(log2(p) for p in probs)
ppl = 2**(bits/len(probs))
bpb = bits/len(text.encode("utf8"))
print(name, bits, ppl, bpb)
Codice, dati e istruzioni · JSON. Calcoli didattici eseguiti con Python 3.14.0; figure con Matplotlib 3.11.2. Analisi con assistenza AI, senza dichiarare peer review o revisione umana. Copertina originale ImageGen, illustrativa: non documenta persone, sedi o installazioni EL-AI. Fonti consultate il 3 ottobre 2026.