Token prediction, compressione, rappresentazioni

Un language model che predice bene il prossimo token è, alla lettera, un compressore del testo. Questo capitolo chiude la Parte XIII raccogliendone tutti i fili — entropia, canali, ridondanza, compressione, complessità, informazione mutua, distorsione — e mostrando che la teoria dell’informazione è una delle lenti più affilate per capire i LLM: cosa misura davvero la loss, cosa dice la perplexity, cosa significano le scaling laws in bit, e dove questa lente smette di vedere.

Perché questo capitolo

Nel 2006 un ricercatore tedesco di nome Marcus Hutter (informatico, teorico dell’intelligenza artificiale generale) mette in palio cinquantamila euro. Il compito: comprimere il più possibile un file da 100 megabyte di testo Wikipedia in inglese, chiamato enwik9. Nessuna astuzia di formato, nessun trucco: solo bit, il più pochi possibile, da cui ricostruire il testo esatto. Il premio si chiama Hutter Prize, ed è ancora aperto.

La motivazione dichiarata di Hutter non è l’ingegneria della compressione. È una tesi sull’intelligenza: per comprimere bene il testo, sostiene, bisogna capirlo. Un compressore che sapesse davvero che “Parigi è la capitale della” è quasi sempre seguito da “Francia” spenderebbe pochissimi bit per quel “Francia”. Comprimere richiede predire, predire richiede modellare, modellare è — secondo questa tesi — una forma di comprensione.

Diciassette anni dopo, nel 2023, un gruppo di ricercatori di DeepMind tra cui lo stesso Hutter pubblica un paper dal titolo che è già un programma: Language Modeling Is Compression. Mostra, con i numeri, che i language model addestrati a predire il prossimo token sono compressori general-purpose così forti da battere i compressori specializzati su testo, immagini e audio. Il cerchio si chiude: l’intuizione del guessing game di Shannon del 1951, la tesi di Hutter sulla compressione come intelligenza, e i modelli linguistici del 2023 raccontano la stessa storia.

Questo capitolo è il punto in cui la Parte XIII smette di parlare di canali, file e codici in astratto e mostra dove tutto quel macchinario morde sull’oggetto tecnico più rilevante per chi lavora con l’AI oggi: il language model. Non spiega come è fatto un LLM dentro — quello è compito delle Parti sull’anatomia, sul training e sull’inferenza. Lo guarda da fuori, con gli occhi della teoria dell’informazione, e raccoglie i fili degli otto capitoli precedenti in una sola tesi operativa.

La tesi è questa: predire bene il prossimo token, comprimere bene il testo, e minimizzare la loss di addestramento sono tre nomi della stessa cosa. Capire questa identità cambia il modo in cui leggi una loss, una perplexity, una tabella di benchmark, un token budget. Trasforma numeri opachi in oggetti che parlano.

Perché un praticante dovrebbe spendere tempo su una lente teorica? Perché senza di essa molte decisioni quotidiane restano riti senza ragione. Si confrontano modelli guardando la perplexity, senza sapere che tra tokenizzatori diversi quel confronto è privo di senso. Si riempie il context window di testo, senza distinguere i token che portano informazione da quelli che la diluiscono. Si insegue “più dati”, senza capire perché un piccolo corpus pulito a volte batte un grande corpus sporco. La lente informazionale dà una ragione a ciascuna di queste scelte, e una ragione comune: tutto si riduce a contare bit, cioè informazione. È una di quelle prospettive che, una volta acquisite, non si disimparano più.

Conviene saperlo dall’inizio: alcune delle connessioni di questo capitolo sono identità formali, dimostrabili in poche righe; altre sono risultati empirici robusti ma datati e rivedibili; altre sono tesi filosofiche affascinanti e non risolte; altre ancora sono analogie, utili per pensare ma da non scambiare per matematica. Distinguere queste classi è metà del valore del capitolo, e il filo che lo attraversa da cima a fondo.

Contesto

Questo capitolo siede in coda alla Parte XIII e ne fa la sintesi rivolta ai modelli linguistici. Ogni capitolo precedente ha posato un mattone che qui trova il suo uso più concreto.

Informazione come riduzione di incertezza ha fissato l’entropia $H$ come sorpresa media e il source coding theorem, il pavimento sotto cui nessuna compressione lossless può scendere. Canali, rumore, capacità ha definito il canale rumoroso e la sua capacità. Ridondanza, error correction, robustezza ha mostrato come la ridondanza aggiunta deliberatamente difenda un messaggio dal rumore.

Minimum Description Length ha legato compressione e scoperta di struttura, e ha introdotto la codifica aritmetica, la tecnica che assegna a ogni simbolo un numero di bit pari alla sua sorpresa $-\log p$ . Compressione e complessità algoritmica ha portato l’idea all’estremo — l’oggetto più “compreso” come quello generato dal programma più corto — e ha incontrato l’incalcolabilità che tiene quella tesi a livello di orizzonte. Informazione mutua e dipendenza ha definito $I(X;Y)$ . Compressione lossy e perdita accettabile ha introdotto il trade-off tra bit spesi e fedeltà.

E Learning come estrazione di struttura, il capitolo immediatamente precedente, ha già fatto il ponte generale: imparare è comprimere, la loss è una lunghezza di codifica, la perplexity è l’entropia esponenziata. Quel capitolo lavora sull’apprendimento in generale. Questo prende la stessa lente e la punta su un solo bersaglio: i language model.

Cosa c’era prima che questa lente diventasse senso comune? Due fili, a lungo separati, che si intrecciano solo di recente.

Il primo è antico: Claude Shannon (1916-2001, matematico e ingegnere dei Bell Labs, fondatore della teoria dell’informazione) nel 1951 lega già la capacità di predire la lettera successiva alla comprimibilità di una lingua, e stima l’entropia dell’inglese a circa 1 bit per carattere. Il secondo e la tradizione della descrizione minima — Ray Solomonoff, Jorma Rissanen, e appunto Hutter — per cui imparare è trovare la descrizione più corta dei dati.

Il punto di incontro con i language model arriva tardi. Negli anni dei modelli a n-grammi (modelli statistici che stimano la probabilità di una parola dalle poche precedenti, dominanti fino agli anni 2000) la perplexity era già la metrica standard, e già tutti sapevano che era entropia esponenziata. Già negli anni ‘90 chi lavorava sul riconoscimento vocale e sulla traduzione automatica valutava i propri modelli in bit per parola e li usava, in alcuni casi, proprio per comprimere testo. Il legame predizione-compressione non era un segreto: era folklore tecnico.

Cosa è cambiato, allora? Due cose. La prima è che i modelli sono diventati abbastanza bravi da rendere il legame spettacolare invece che accademico: un n-gramma comprimeva il testo un po’ meglio di gzip, un LLM lo comprime molto meglio e per giunta comprime anche immagini e audio. La seconda è che con le scaling laws di OpenAI nel 2020 e con il paper di DeepMind del 2023 quel legame è passato da nota a piede di pagina a chiave di lettura centrale: non più “guarda caso predire e comprimere coincidono”, ma “leggiamo l’intero progresso dei modelli come progresso nella compressione”. Questo capitolo non inventa quel filo: lo raccoglie e lo rende esplicito.

L’intuizione

Prima del formalismo, due modi diversi di vedere lo stesso fatto. Il primo guarda il LLM come una macchina che indovina; il secondo lo guarda come una macchina che accorcia. Sono la stessa macchina vista da due lati, e averli entrambi in testa rende leggibili cose che altrimenti sembrano scollegate.

Angolo 1: il modello come giocatore al guessing game di Shannon

Nel 1951 Shannon fa un esperimento semplice. Mostra a una persona l’inizio di una frase e le chiede di indovinare la lettera successiva, una alla volta. “T-H-E Q-U-I-C-K B-R-O-W-N F-O-…” e quasi tutti dicono “X”. Dalla bravura nell’indovinare, Shannon stima quanta sorpresa media porti ogni lettera dell’inglese, e arriva a circa 1 bit per carattere — molto meno dei circa 5 bit che servirebbero per un testo del tutto casuale.

La conclusione è che chi indovina bene la lettera dopo ha già, implicitamente, un modello della lingua. Quel modello è ciò che permette di non sprecare bit: dove sei quasi sicuro, spendi poco; dove sei davvero incerto, spendi di più.

C’è un dettaglio del metodo di Shannon che vale la pena cogliere, perché è esattamente ciò che fa un LLM. Shannon non chiedeva solo “qual è la lettera dopo”, ma quante tentativi servivano per indovinarla: una sola tentativo nei punti facili, molti nei punti difficili. Il numero di tentativi è una misura grezza della sorpresa, e mediandolo sul testo si ottiene una stima dell’entropia. Un language model fa la versione continua e precisa dello stesso conto: invece di “quanti tentativi”, produce una probabilità per ogni token possibile, e la sorpresa $-\log p$ del token che arriva davvero è il suo “conto dei tentativi” reso esatto. La differenza tra Shannon e un LLM non è di natura, è di risoluzione: dove Shannon contava tentativi su una persona, il modello calcola sorprese su miliardi di parametri.

Un language model fa esattamente quel gioco, a ogni token, su scala industriale. Dopo “la capitale della Francia è” assegna probabilità altissima a “Parigi” e bassa a tutto il resto. La sua bravura nell’indovinare è misurata dalla sua sorpresa media — e la sorpresa media è, lo vedremo, esattamente la sua loss. Un modello bravo a predire è un modello poco sorpreso, e un modello poco sorpreso è un modello che ha imparato la struttura del testo.

Angolo 2: il modello come compressore

Capovolgi la prospettiva. Hai un file di testo e vuoi scriverlo nel minor numero di bit possibile, in modo da poterlo ricostruire esatto. La codifica aritmetica, vista nel capitolo MDL, ti dice come: dai a ogni simbolo un numero di bit pari alla sua sorpresa $-\log_2 p$ secondo un modello di probabilità. Più il modello prevede bene il simbolo che arriva, meno bit gli costa scriverlo.

Un piccolo conto rende tangibile il meccanismo. Supponi che, dopo “la capitale della Francia è”, il modello assegni a “Parigi” probabilità $0{,}9$ . La sua sorpresa è $-\log_2 0{,}9 \approx 0{,}15$ bit: per scrivere “Parigi” in quel punto bastano un settimo di bit. Se invece, dopo una frase ambigua, il modello assegna al token che arriva una probabilità di appena $0{,}01$ , la sorpresa è $-\log_2 0{,}01 \approx 6{,}6$ bit: quel token costa caro, perché il modello non se lo aspettava. La codifica aritmetica spende, token per token, esattamente questi numeri. Comprimere bene non significa altro che trovarsi spesso nel primo caso e raramente nel secondo.

Quindi qualunque cosa predica probabilità sul prossimo simbolo è, automaticamente, un compressore: basta darle in pasto a un codificatore aritmetico. Un language model predice probabilità sul prossimo token. Ne segue, senza ulteriori assunzioni, che ogni language model è un compressore di testo. Non “è come” un compressore: lo è, meccanicamente, nel momento in cui colleghi la sua uscita a un codificatore aritmetico.

E quanto comprime bene? Esattamente quanto predice bene. Il numero medio di bit che spende per token è la sua cross-entropy sul testo, cioè la quantità che durante l’addestramento chiamiamo loss. I due angoli si toccano qui: indovinare bene e comprimere bene sono la stessa abilità, misurata dallo stesso numero.

Una terza voce: è per questo che “comprimere è capire” suona vero

C’è una tentazione, a questo punto, di fare un passo in più: se comprimere bene richiede predire bene, e predire bene richiede aver colto la struttura del testo — la grammatica, i fatti, le relazioni — allora comprimere bene è una forma di capire. È la tesi di Hutter, la motivazione del suo premio.

Tieni questa voce a distanza di sicurezza. È un’intuizione potente e non priva di fondamento, ma è una tesi, non un teorema, e la sezione “Dove si rompe” la smonterà con cura. Per ora serve solo a spiegare perché la lente informazionale sui LLM è così seducente: cattura qualcosa di reale (la struttura statistica del linguaggio) e lo confonde facilmente con qualcosa di più grande (la comprensione). Tenere separate le due cose è parte del mestiere.

C’è un modo di fissare i confini di questa terza voce che richiama il capitolo sulla complessità di Kolmogorov (cap. 05). Immagina, come orizzonte, il compressore ideale: non un modello fissato, ma qualsiasi programma. La descrizione più corta di un corpus diventa allora il programma più breve che lo rigenera — la teoria più compatta che spiega tutto ciò che si è visto. Sotto questa lente, un modello che comprimesse alla perfezione avrebbe trovato la struttura ultima dei dati, e l’idea “comprimere = capire” avrebbe il suo fondamento più solido. Il problema è che quel programma minimo è incalcolabile: nessun algoritmo lo trova in generale. Un LLM non insegue quell’ideale, ne è un’approssimazione povera dentro una classe di modelli trattabili. Tenere a mente l’orizzonte ideale serve proprio a ricordare quanto un LLM ne sia lontano: comprime molto bene il testo, ma è ben distante dal “compressore perfetto” che renderebbe la tesi di Hutter un teorema invece che una scommessa.

La meccanica

Adesso il formalismo, un filo alla volta. Per ogni legame enuncio la quantità, la spiego, e ne dichiaro la classe: identità/teorema, risultato empirico, tesi, o analogia. Non sono tutti dello stesso colore.

La loss è una lunghezza di codifica per token (teorema)

Un language model autoregressivo genera il testo un token alla volta. A ogni passo $t$ , dato il prefisso $x_{<t}$ (tutti i token fin lì), produce una distribuzione di probabilità $q(x_t \mid x_{<t})$ sul prossimo token. La loss di addestramento è la cross-entropy media:

$L = -\frac{1}{T}\sum_{t=1}^{T}\log_2 q(x_t \mid x_{<t})$

In parole povere: per ogni token che arriva davvero, prendi la sorpresa del modello $-\log_2 q$ — alta se il modello non se lo aspettava, bassa se ci aveva quasi azzeccato — e fai la media su tutta la sequenza di lunghezza $T$ .

Il legame con la codifica è diretto e lo abbiamo già incontrato nel capitolo MDL: $-\log_2 q(x_t \mid x_{<t})$ è il numero di bit che un codificatore aritmetico ottimale spende per scrivere quel token, usando le probabilità del modello. La codifica aritmetica è ottima sulla lunghezza di codifica, a meno di pochi bit di overhead spalmati sull’intera sequenza. Quindi la loss media è la lunghezza di codifica media per token.

Questa non è un’analogia: è un’identità. Grégoire Delétang e colleghi (DeepMind, Language Modeling Is Compression, ICLR 2024) lo dicono in una riga: massimizzare la log-likelihood del modello equivale a minimizzare la lunghezza di codifica attesa quando si usa quel modello per comprimere con codifica aritmetica. La qualità della compressione dipende interamente dalla qualità del modello probabilistico. Classe dell’affermazione: teorema, dimostrabile dal source coding di Shannon più l’ottimalità della codifica aritmetica.

Ne segue il ribaltamento che dà il titolo al paper: addestrare un modello a predire bene il prossimo token è, alla lettera, addestrarlo a comprimere bene il testo. Non c’è nessun obiettivo “compressione” nascosto da qualche parte: la cross-entropy è già quella quantità.

La perplexity è l’entropia esponenziata (identità, già in cap. 08)

Se la loss e in bit per token, la perplexity ne è la versione esponenziata:

$\mathrm{PP} = 2^{L} \quad \text{(con loss in bit; } e^{L} \text{ con loss in nat)}$

L’esponenziazione la rende un numero concreto: il branching factor effettivo, cioè quante scelte equiprobabili il modello sta in media considerando per il prossimo token. Una perplexity di 8 significa che il modello è incerto come se a ogni passo dovesse scegliere tra 8 opzioni equiprobabili; una perplexity di 1 significa certezza assoluta; una perplexity pari alla dimensione del vocabolario significa un modello che non ha imparato nulla e tira a indovinare uniformemente.

Questa è la stessa identità vista in Informazione come riduzione di incertezza: la perplexity è $2^{H}$ , l’entropia esponenziata di una sorgente. Perplexity bassa significa modello poco sorpreso, cioè modello che comprime bene quel testo. È la metrica standard con cui si confrontano i language model su un corpus held-out — un testo tenuto da parte e mai visto in addestramento. Classe: identità per definizione.

Il pavimento di Shannon: c’è un limite a quanto si può comprimere (risultato empirico + teorema)

Quanto in basso può arrivare la loss? Non a zero. Il source coding theorem (cap. 01) dice che nessun compressore lossless scende sotto l’entropia vera della sorgente. Se il linguaggio ha un’entropia irriducibile — una quota di sorpresa che nemmeno il predittore perfetto può eliminare, perché il testo non è del tutto determinato dal suo passato — quella è il pavimento.

Shannon, nel 1951, stima quel pavimento per l’inglese scritto. Col guessing game arriva a un intervallo tra circa 0,6 e 1,3 bit per carattere, attorno a 1 bit/char, contro i circa 5 bit grezzi di una codifica ingenua. Significa che l’inglese scritto è ridondante per il 75-80%: tre quarti dei bit che usi per scriverlo in modo naive sono prevedibili dal contesto.

Cosa significa per i modelli: esiste un tetto alle prestazioni. I migliori language model a livello di byte si avvicinano oggi a circa 0,9-1,1 bit per carattere su testo inglese pulito — proprio nella fascia che Shannon aveva stimato a mano, con soggetti umani, settant’anni prima. È una conferma empirica indiretta sorprendentemente buona di quella stima.

Una cautela importante. La stima di Shannon non è un teorema sul “valore vero” dell’entropia dell’inglese: è una stima sperimentale, con metodo basato su pochi soggetti umani e barre d’errore larghe. L’entropia vera dipende da come definisci la sorgente e da quanto contesto consideri. Thomas Cover e Roger King, nel 1978, la raffinano con un metodo a scommessa (gambling) e arrivano a circa 1,3 bit/char. L’ordine di grandezza regge da decenni; il valore esatto resta una stima, non una costante di natura.

Le scaling laws, lette in bit (risultato empirico + inquadramento)

Se la loss è un tasso di compressione, allora le leggi che descrivono come la loss cala al crescere delle risorse sono leggi su quanto meglio si comprime spendendo di più.

Jared Kaplan e colleghi (OpenAI, Scaling Laws for Neural Language Models, arXiv:2001.08361, 2020) misurano che la loss di test cala come una legge di potenza in funzione di tre grandezze: il numero di parametri $N$ , la quantità di dati di training $D$ in token, e il compute $C$ usato per addestrare. La relazione tiene su più di sette ordini di grandezza. Schematicamente, tenendo fisse le altre risorse:

$L(N) \approx \left(\frac{N_c}{N}\right)^{\alpha_N}, \qquad \alpha_N \approx 0{,}076$

dove $N_c$ è una costante e $\alpha_N$ l’esponente misurato. In parole povere: raddoppiare i parametri non dimezza la loss, la migliora di un fattore prevedibile e piccolo, ma in modo regolare e progettabile. Letta in bit: più risorse spendi, più bit di struttura il modello estrae dai dati, meno bit gli servono per token, meglio comprime. La curva di loss è una curva di compressione.

Jordan Hoffmann e colleghi (DeepMind, Training Compute-Optimal Large Language Models, NeurIPS 2022, noto come “Chinchilla”) aggiungono il pezzo sull’allocazione. Addestrando oltre 400 modelli da 70 milioni a 16 miliardi di parametri su quantità di dati da 5 a 500 miliardi di token, trovano che per usare al meglio un budget di compute fisso bisogna scalare parametri e dati in egual misura: ogni volta che raddoppi il modello, raddoppia anche i dati. L’euristica pratica è di circa 20 token di addestramento per ogni parametro. Chinchilla, un modello da 70 miliardi di parametri addestrato su 1,4 trilioni di token, batte modelli molto più grandi (Gopher da 280 miliardi, GPT-3 da 175 miliardi) addestrati con lo stesso compute ma su meno dati. La conclusione: i grandi modelli dell’epoca erano fortemente undertrained, sotto-addestrati.

Qui va marcata una distinzione di classe. I risultati di Kaplan e Hoffmann sono empirici: leggi di potenza fittate su esperimenti, robuste ma legate all’epoca, all’architettura e ai dati usati, e infatti già oggetto di revisione. L’inquadramento informazionale che propongo — il “compute-optimal” come allocazione ottimale di risorse per estrarre informazione — è una lente di lettura, non il modo in cui i paper derivano i risultati.

L’inquadramento è questo: hai un budget di compute, e lo spendi tra due cose. Da un lato la capacità del modello, $N$ , cioè quanti bit di struttura il modello può ospitare. Dall’altro l’informazione disponibile, $D$ , cioè quanti bit di struttura ci sono effettivamente nei dati. Sbilanciare spreca: troppo modello e pochi dati significa capacità inutilizzata e tendenza a memorizzare; troppi dati e poco modello significa informazione presente che il modello non ha capacità di assorbire. Il punto di Chinchilla è l’equilibrio tra i due. È un modo utile di pensare il risultato, ma i “bit di informazione nei dati” non sono una quantità che i paper misurano: resta inquadramento concettuale, da non spacciare per teorema.

Informazione nei dati e capacità del modello (inquadramento + ricerca)

C’è una domanda che la lente informazionale fa venire naturale e che vale la pena porre con cura: quanta informazione entra davvero in un modello? Un parametro è un numero in virgola mobile, e un numero in virgola mobile può ospitare un certo numero di bit. Se i parametri sono $N$ e ciascuno trattiene una manciata di bit di informazione sui dati, il modello ha un tetto di capacità informazionale, e quel tetto limita quanto può assorbire da un corpus per quanto grande sia.

Lavori recenti hanno provato a misurarlo. Una stima che ha circolato (Morris e colleghi, 2025) colloca la capacità memorizzativa di un transformer attorno a un paio di bit per parametro: oltre quella soglia il modello smette di memorizzare gli esempi specifici e comincia a generalizzare, perché non gli resta capacità per imparare il dato a memoria e deve invece imparare la regola che lo genera. Il numero esatto è area di ricerca aperta e dipende da architettura, precisione, dati; va preso come ordine di grandezza, non come costante. Classe dell’affermazione: inquadramento con supporto empirico parziale, da maneggiare come tale.

La lettura concettuale, però, è solida e tiene insieme i fili della Parte. La capacità del modello è il numero di bit che i pesi possono trattenere dei dati — la quantità che i bound di generalizzazione del capitolo precedente chiamano $I(S; W)$ , l’informazione che i pesi assorbono dal training set (vedi Informazione mutua e dipendenza e Learning come estrazione di struttura). Quando questa capacità è piccola rispetto all’informazione nei dati, il modello è costretto a comprimere: non potendo tenere tutto, tiene la struttura, cioè ciò che si ripaga su molti esempi. Quando la capacità eccede di gran lunga l’informazione utile, il modello può permettersi di memorizzare rumore. Le scaling laws e il punto compute-optimal vivono, in questa lente, nel regime in cui capacità e informazione sono bilanciate — il regime in cui comprimere e generalizzare coincidono.

La tokenizzazione e una scelta di codifica (filiazione documentata + tesi parziale)

Prima ancora che il modello veda il testo, il testo viene segmentato in token. Questa segmentazione è una scelta di codifica, e non è un caso che l’algoritmo più usato per farla nasca dalla compressione.

Il Byte-Pair Encoding (BPE) è stato introdotto da Philip Gage nel 1994, in un articolo intitolato A New Algorithm for Data Compression, come tecnica di compressione dati: trova la coppia di byte adiacenti più frequente nel testo, sostituiscila con un nuovo simbolo, e ripeti. Ogni sostituzione accorcia il testo catturando un pattern ricorrente. Rico Sennrich, Barry Haddow e Alexandra Birch (ACL 2016, Neural Machine Translation of Rare Words with Subword Units) riprendono lo stesso algoritmo e lo applicano alla traduzione neurale come tokenizzazione sub-word, per gestire parole rare scomponendole in pezzi ricorrenti. Da lì diventa lo standard: GPT-2, GPT-3, BERT e moltissimi altri usano BPE o sue varianti.

Classe del legame BPE-compressione: filiazione documentata. Non è un’analogia suggestiva — è letteralmente lo stesso algoritmo, nato per comprimere e riusato per tokenizzare. Costruisce un dizionario di sequenze frequenti, esattamente come un compressore a dizionario alla Lempel-Ziv (cap. 01).

C’e però una sfumatura da non perdere. Che BPE sia un algoritmo di compressione è un fatto. Che il “tokenizer ottimo” coincida col “compressore ottimo” è invece una tesi parziale. La tokenizzazione è una pre-compressione che cambia cosa il modello deve poi modellare, e Delétang e colleghi notano che l’interazione tra tokenizzazione e compressione finale non è banale: comprimere di più nel tokenizer non è sempre meglio per il modello. La codifica giusta per un compressore puro e la codifica giusta per un modello che deve poi imparare regolarità non sono necessariamente la stessa.

Il decoding come navigazione della distribuzione (meccanica + analogia)

Finora abbiamo guardato il modello mentre legge. Quando invece genera, a ogni passo produce dei logits — punteggi grezzi per ogni token del vocabolario — che la funzione softmax (vista in Dalla somma alla probabilità) trasforma nella distribuzione $q(x_t \mid x_{<t})$ . Poi qualcuno deve scegliere il token. Quel “qualcuno” è la strategia di decoding.

La manopola più importante è la temperatura $T$ , che riscala i logits prima della softmax: si calcola $\text{softmax}(z/T)$ invece di $\text{softmax}(z)$ . Con $T < 1$ le differenze tra logits si amplificano, la distribuzione si affila, l’entropia scende e il modello diventa più deterministico. Con $T > 1$ i logits si appiattiscono, la distribuzione si spalma, l’entropia sale e l’output diventa più vario. Al limite $T \to 0$ si prende sempre il token più probabile (greedy), al limite $T \to \infty$ si campiona uniformemente.

Il legame con la teoria dell’informazione è diretto: la temperatura è una manopola sull’entropia della distribuzione di output a ogni passo (cap. 01, entropia come incertezza). Generare a bassa entropia dà testo prevedibile — e quindi molto comprimibile — ma tende al ripetitivo e al degenere; generare ad alta entropia dà più sorpresa, più varietà, più rischio di derive. Classe: il legame temperatura-entropia è meccanico, la temperatura modifica letteralmente l’entropia del softmax. L’immagine del “navigare la distribuzione di probabilità che il modello ha imparato” è invece un’analogia, utile per l’intuizione. La meccanica fine del decoding — greedy, beam search, top-k, top-p, min-p — vive nei capitoli di anatomia LLM e inferenza, output-logits (in preparazione) e greedy-beam (in preparazione); qui interessa solo che è un gioco sull’entropia.

Il canale rumoroso uomo-LLM (analogia, dichiarata come tale)

C’è un ultimo modo di usare la Parte XIII sui LLM, e va maneggiato con la pinza più lunga, perché è il più facile da prendere per più di quello che è.

Pensa al prompt come a un messaggio che attraversa un canale (cap. 02, Canali, rumore, capacità). L’intenzione dell’utente è il messaggio sorgente; il prompt scritto è la sua codifica; il modello è il ricevitore che decodifica; l’output è ciò che arriva dall’altra parte. Il rumore è l’ambiguità del linguaggio, le formulazioni imprecise, lo scarto tra ciò che l’utente intende e ciò che il modello inferisce.

In questa lente, la ridondanza che mettiamo nei prompt — gli esempi few-shot, le ripetizioni, i formati espliciti, l’istruzione “spiega passo passo” — è una codifica ridondante per robustezza al rumore, lo stesso meccanismo dei codici a correzione d’errore (cap. 03, Ridondanza, error correction, robustezza). Si aggiungono bit non strettamente necessari per avere margine contro il fraintendimento.

Classe dell’affermazione: analogia, e va detto chiaramente. Non c’è un canale di Shannon formale, con una capacità misurabile in bit al secondo, tra l’utente e il modello; non si applica il teorema di Shannon-Hartley; nessuno misura la “capacità del canale uomo-LLM” in modo quantitativo. È una lente concettuale per ragionare sul prompt design, non un modello numerico. Il suo valore è spiegare perché la ridondanza nel prompt aiuta — per lo stesso motivo per cui aiuta in un codice a correzione d’errore: dà margine contro il rumore — senza pretendere che sia la stessa matematica. Scambiare questa analogia per un teorema è esattamente l’errore che la disciplina sulle classi di affermazioni serve a evitare.

Cosa “comprime” un LLM nelle sue rappresentazioni (dibattito aperto)

Resta una domanda più interna: cosa tengono e cosa buttano via le rappresentazioni intermedie di un modello? L’information bottleneck (Tishby, Pereira, Bialek, 1999, già in cap. 06 e 08) propone una lente: una rappresentazione $T$ dell’input $X$ è buona se massimizza $I(T;Y)$ — quanto è predittiva del target $Y$ — minimizzando $I(X;T)$ — quanto comprime l’input, buttando via ciò che non serve a predire.

Applicata al deep learning, l’idea ha generato una tesi forte (Shwartz-Ziv e Tishby, 2017): il training attraverserebbe due fasi, prima fitting e poi una lunga compression in cui la rete getta informazione irrilevante. La tesi è seducente e tornerebbe perfetta per i LLM: il modello comprime l’input tenendo solo ciò che serve a predire il prossimo token.

Qui il capitolo deve essere onesto. Andrew Saxe e colleghi (On the Information Bottleneck Theory of Deep Learning, ICLR 2018) contestano empiricamente: la fase di compressione dipende dalla funzione di attivazione (compare con la tangente iperbolica, spesso non con le ReLU di oggi) e dal modo fragile in cui l’informazione mutua viene stimata in alta dimensione. Classe dell’affermazione: dibattito aperto, non risolto. L’information bottleneck è un framework concettuale ricco, ma la tesi specifica che “i transformer generalizzano perché comprimono in due fasi” non è consenso. Stimare $I(X;T)$ per un modello con miliardi di parametri è oltre lo stato dell’arte affidabile. Usalo come lente, non come spiegazione chiusa del cosa accade dentro un LLM.

Generazione lossy: il filo rate-distortion

Resta un capitolo della Parte XIII da raccogliere: la teoria rate-distortion (cap. 07, Compressione lossy e perdita accettabile), che misura il minimo di bit per ricostruire un segnale entro una distorsione accettabile. Sui language model il filo è più sottile, perché la compressione del testo di cui abbiamo parlato finora è lossless — il codificatore aritmetico ricostruisce il testo esatto. Ma appena si guarda alla generazione, la perdita rientra in scena.

Quando un modello riassume un documento, sta facendo compressione lossy: butta via dettagli per tenere il significato, e la “distorsione” è quanto significato si perde. Quando si addestra un modello generativo con un collo di bottiglia — un autoencoder variazionale, un modello che passa per un codice latente più piccolo dell’input — l’obiettivo ha esplicitamente due termini, uno di quantità di bit nel codice (il rate) e uno di fedeltà della ricostruzione (la distorsione), e le soluzioni si dispongono lungo la frontiera rate-distortion vista nel capitolo dedicato. La lente è la stessa, applicata a un compito dove perdere informazione è ammesso e perfino voluto.

Classe dell’affermazione: framework formale solido per i generativi con bottleneck, una delle letture possibili e non l’unica. Lo segnalo perché chiude il cerchio della Parte: ogni capitolo, dall’entropia alla distorsione, trova un uso quando si guardano i modelli linguistici con gli occhi della teoria dell’informazione.

Una sola storia, classi diverse

Prima degli esempi, conviene fissare la mappa, perché la cosa più facile da sbagliare non è la matematica ma la classe di ciascun legame.

Sono identità o teoremi, non opinabili: la loss è la lunghezza di codifica media per token; la perplexity è l’entropia esponenziata; il source coding theorem mette un pavimento alla compressione.

Sono risultati empirici, robusti ma datati e rivedibili: i LLM battono i compressori specializzati (Delétang et al.); la loss cala come legge di potenza nelle risorse (Kaplan); l’allocazione compute-optimal è circa 20 token per parametro (Hoffmann). La stima di Shannon di ~1 bit/char è empirica anch’essa.

Sono filiazioni documentate: BPE nasce come algoritmo di compressione e viene riusato per la tokenizzazione.

Sono tesi o prospettive, affascinanti ma non stabilite: “comprimere = capire” (Hutter, radicata in Solomonoff); il “compute-optimal come allocazione ottimale di informazione” come inquadramento.

Sono analogie, utili per pensare ma non matematica: il canale uomo-LLM e la ridondanza-come-error-correction nel prompt.

È un dibattito aperto: l’information bottleneck come spiegazione delle rappresentazioni interne.

Quando in un thread o in un paper leggi “il modello comprime quindi capisce”, la prima domanda da farsi è: in quale di queste colonne sta quella frase?

La tabella mette in fila le affermazioni del capitolo con la loro classe, perché è la cosa che più conviene tenere a portata di mano:

Affermazione	Classe	Solidità
Loss = lunghezza di codifica media per token	Teorema	piena
Perplexity = entropia esponenziata	Identità	piena
Source coding theorem: pavimento alla compressione	Teorema	piena
LLM batte i compressori specializzati su testo, immagini, audio	Risultato empirico	alta (col caveat del peso del modello)
Loss = legge di potenza nelle risorse (scaling laws)	Risultato empirico	alta, ma datata e rivedibile
BPE nasce come algoritmo di compressione	Filiazione documentata	piena
Compute-optimal = allocazione ottimale di informazione	Inquadramento	lente, non derivazione dei paper
Comprimere = capire / intelligenza	Tesi / prospettiva	aperta, non dimostrata
Canale uomo-LLM, ridondanza nel prompt = error correction	Analogia	euristica, non quantitativa
Information bottleneck spiega le rappresentazioni interne	Dibattito aperto	contestata

La regola pratica è leggere ogni affermazione informazionale sui LLM scendendo questa scala: dall’alto, dove c’è poco da discutere, verso il basso, dove serve cautela crescente. Il valore della lente sta tutto nel non trattare la riga in fondo come se fosse quella in cima.

Esempi

Esempio numerico: dalla loss alla compressione di un mini-modello

Stai addestrando un piccolo language model che lavora a livello di byte, su testo inglese. All’inizio, prima di qualsiasi apprendimento, assegna probabilità uniforme ai 256 byte possibili. La sua cross-entropy è $\log_2 256 = 8$ bit per byte: esattamente la dimensione grezza del testo. Non comprime nulla, e la sua perplexity è $2^8 = 256$ , il branching factor di chi tira a indovinare tra tutti i byte.

Dopo l’addestramento la loss scende a, diciamo, 1,1 bit per byte. Quel numero ha un significato fisico immediato. Usato come compressore con una codifica aritmetica, il modello scriverebbe il testo a 1,1 bit per byte invece di 8: un fattore di compressione di circa $8 / 1{,}1 \approx 7{,}3\times$ . La perplexity è $2^{1{,}1} \approx 2{,}14$ , cioè a ogni byte il modello è incerto come se scegliesse tra poco più di due opzioni equiprobabili.

È rivelatore confrontare con il pavimento di Shannon. La stima di circa 1 bit/char per l’inglese dice che un modello a 1,1 bit/byte è già molto vicino al limite teorico: il margine di miglioramento residuo è sottile, perché il grosso della ridondanza dell’inglese è già stato spremuto. Un modello che arrivasse a 0,8 bit/byte non comprimerebbe “il doppio meglio”: guadagnerebbe quegli ultimi decimi che separano un ottimo modello dal predittore quasi perfetto.

Esempio in codice: perché bisogna passare a bits-per-byte

Lo stesso conto, e il motivo per cui confrontare perplexity nude tra modelli con tokenizzatori diversi inganna.

import math

# Due modelli sullo stesso testo inglese (1000 caratteri).
# Modello A: tokenizer a parole, 200 token per il testo.
# Modello B: tokenizer a caratteri, 1000 token per il testo.

loss_A_nat = 4.0   # nat per token (token lunghi = più sorpresa per token)
loss_B_nat = 1.0   # nat per token (token corti = meno sorpresa per token)

# perplexity per token: NON confrontabili, contano su unità diverse
ppl_A = math.exp(loss_A_nat)   # ~54.6
ppl_B = math.exp(loss_B_nat)   # ~2.72

# bits-per-byte: normalizza sul testo grezzo, confrontabile
n_caratteri = 1000
bits_A = (loss_A_nat / math.log(2)) * 200    # bit totali = bit/token * token
bits_B = (loss_B_nat / math.log(2)) * 1000
bpb_A = bits_A / n_caratteri
bpb_B = bits_B / n_caratteri

print(round(ppl_A, 1), round(ppl_B, 1))   # 54.6 2.7  -> sembra B molto meglio
print(round(bpb_A, 3), round(bpb_B, 3))   # 1.155 1.443 -> in realtà A comprime meglio

La perplexity per token dice che B è enormemente migliore di A (2,7 contro 54,6). I bits-per-byte raccontano l’opposto: A spende 1,155 bit per carattere del testo grezzo, B ne spende 1,443. A comprime meglio. La perplexity per token premiava B solo perché i suoi token sono più corti, non perché capisca meglio il testo. Per confrontare modelli con tokenizzatori diversi serve sempre una misura per-byte; è proprio per questo che Delétang e colleghi misurano in bits-per-byte e contano il peso del modello.

Scenario reale: Chinchilla comprime ImageNet, col caveat che conta

Delétang e colleghi prendono Chinchilla 70B — un modello addestrato quasi solo su testo — e lo usano come compressore general-purpose, dandogli in pasto dati che non ha mai visto in quel formato. I numeri sono sorprendenti. La tabella riassume i risultati chiave (più piccola è la percentuale, migliore è la compressione):

Dato	Compressore specializzato	Chinchilla 70B
Immagini (patch ImageNet)	PNG: 58,5%	43,4%
Audio (LibriSpeech)	FLAC: 30,3%	16,4%

Su patch di immagini di ImageNet, Chinchilla comprime al 43,4% della dimensione grezza, battendo PNG che si ferma al 58,5%. Su campioni audio di LibriSpeech comprime al 16,4%, contro il 30,3% di FLAC, il compressore audio lossless specializzato. Su testo batte gzip di larghissimo margine. Il punto da non perdere è che PNG è nato per le immagini e FLAC per l’audio: un modello addestrato sul testo li supera entrambi sul loro stesso terreno, semplicemente perché ha imparato regolarità statistiche così generali da valere anche su byte di natura diversa.

È la dimostrazione più concreta della tesi del capitolo: un buon predittore è un buon compressore, anche di modalità per cui non era nato, perché ha colto regolarità statistiche così generali da valere oltre il testo.

Qui scatta però il caveat che separa l’entusiasmo dall’onestà. Quel 43,4% conta solo i bit del messaggio compresso, non i bit del compressore. PNG e gzip stanno in poche decine di kilobyte; Chinchilla 70B sono centinaia di gigabyte di parametri. Se comprimi un singolo file piccolo e devi spedire anche il compressore, il LLM perde rovinosamente. Il confronto è onesto solo in due regimi: quando comprimi una quantità enorme di dati e il costo fisso del modello si ammortizza su tutti, oppure quando il modello è già disponibile a entrambe le parti e non va trasmesso (compressione condizionata). “Il LLM batte gzip” è vero, ma solo nella contabilità giusta. Fuori da quella, è un titolo fuorviante.

Il conto del pareggio si fa in poche righe e chiarisce quando il LLM conviene davvero:

# Quanti dati servono perché il LLM batta gzip, contando anche il modello?
# Idea: il LLM paga un costo fisso enorme (i suoi pesi) ma un costo
# variabile basso (pochi bit/byte); gzip paga zero fisso ma più bit a byte.

modello_bit = 70e9 * 16            # 70B parametri a 16 bit = peso del compressore
bpb_llm  = 1.0                     # il LLM comprime a ~1 bit/byte
bpb_gzip = 2.5                     # gzip comprime a ~2,5 bit/byte (testo)

# costo totale = peso del modello (solo per il LLM) + bit del messaggio
# LLM:  modello_bit + bpb_llm  * n_byte
# gzip:        0    + bpb_gzip * n_byte
# pareggio quando i due costi totali sono uguali:
n_byte_pareggio = modello_bit / (bpb_gzip - bpb_llm)
print(f"{n_byte_pareggio/1e9:.0f} GB")   # ~747 GB

Sotto la soglia di pareggio — qui centinaia di gigabyte — gzip vince perché non deve trasmettere se stesso. Sopra, il LLM vince perché il suo peso enorme si spalma su una quantità di dati ancora più enorme, e il suo bit/byte migliore prende il sopravvento. È il motivo per cui i risultati di Delétang vanno letti con i numeri sotto gli occhi: la compressione condizionata a un modello già disponibile è impressionante, la compressione autocontenuta di un file piccolo è perdente. Entrambe le frasi sono vere; sono frasi diverse.

Un quarto esempio: il token budget come budget di bit

Hai un context window di, diciamo, 200.000 token e devi decidere cosa metterci. La lente informazionale rende la scelta meno arbitraria. Il context è un budget di codifica: ogni token è un’unità, e quanti token costa un testo dipende da quanto è comprimibile.

Un blocco di JSON molto ripetitivo, con le stesse chiavi mille volte, è a bassa entropia: porta poca informazione per token, e potresti comprimerlo o riassumerlo senza perdere quasi nulla. Un paragrafo denso di fatti specifici — nomi, numeri, vincoli — è ad alta entropia: ogni token conta, riassumerlo perde informazione vera. Lo stesso prompt scritto in modo verboso ma prevedibile spreca token senza aggiungere informazione; scritto in modo conciso ma denso, usa il budget meglio.

Pensare “in bit” non cambia il codice che scrivi, cambia l’intuizione: il context non si riempie di parole, si riempie di informazione, e le due cose non coincidono. La meccanica del context window e dei suoi costi vive nei capitoli su kv-cache (in preparazione) e context engineering; qui interessa la lente.

Un quinto esempio: il prompt ridondante come codifica con margine

Confronta due prompt che chiedono la stessa cosa. Il primo è scarno: “Estrai le date.” Il secondo è ridondante: “Estrai tutte le date dal testo seguente. Restituiscile in formato ISO (AAAA-MM-GG), una per riga. Se non trovi date, scrivi NESSUNA. Esempio: dal testo ‘riunione il 3 marzo 2024’ estrai 2024-03-03.” Il secondo prompt costa molti più token, ma è più robusto: ha meno modi di essere frainteso.

Nella lente del canale rumoroso (cap. 02), questa è esattamente la logica di un codice a correzione d’errore (cap. 03). Il messaggio sorgente — l’intenzione “voglio le date in un formato pulito” — viaggia verso il modello attraverso un canale rumoroso, dove il rumore è l’ambiguità: cosa conta come “data”?, in che formato?, cosa fare se non ce ne sono? Il prompt scarno lascia che il modello riempia quei buchi a modo suo, e a ogni buco può sbagliare. Il prompt ridondante aggiunge bit che chiudono i buchi prima che il rumore li raggiunga, come i bit di parità in un codice difendono i bit di dato.

La cosa importante è che è un trade-off, non un “più è meglio”. Ogni token di ridondanza costa budget e attenzione; oltre un certo punto, aggiungere istruzioni non riduce più il rumore ma diluisce il segnale. Il prompt design ottimale, in questa lettura, è lo stesso problema del progetto di un codice: quanta ridondanza serve per avere margine contro il rumore atteso, senza sprecare capacità del canale. Resta un’analogia — non c’è una capacità di canale misurabile in bit qui — ma è un’analogia che dà un criterio, e un criterio è più di una metafora.

Applicazioni pratiche

Leggere ogni loss come un tasso di compressione. Quando un report dice “loss 0,9 nat per token”, traducilo: $0{,}9 / \ln 2 \approx 1{,}3$ bit per token, perplexity $e^{0{,}9} \approx 2{,}46$ . Quel numero ti dice quante opzioni equiprobabili il modello sta considerando in media, e quindi quanto ha imparato. Una perplexity vicina al numero di scelte “ovvie” del dominio segnala che il modello ha estratto la struttura; una perplexity alta segnala che brancola.

Confrontare modelli solo via bits-per-byte. Come mostrato nell’esempio in codice, la perplexity per token non è confrontabile tra tokenizzatori diversi. Le tabelle di benchmark che mettono in fila perplexity nude di modelli con vocabolari diversi sono ingannevoli. Se devi confrontare, pretendi bits-per-byte o bits-per-character.

Usare la perplexity come sensore di drift. La perplexity di un modello su nuovo traffico di produzione è un allarme di concept drift letto in bit: se schizza in alto, la distribuzione dei dati reali si è spostata rispetto a quella di addestramento. Il modello è “più sorpreso” dal mondo, e probabilmente sta peggiorando senza che nessuna metrica di task lo segnali ancora.

Capire perché più dati di qualità aiutano. Le scaling laws dicono che più dati abbassano la loss, ma non tutti i dati sono uguali in bit. Dati di qualità hanno più struttura e meno rumore: più informazione utile per token. La deduplicazione (cap. 03, ridondanza) rimuove informazione già presente, che il modello rivedrebbe senza imparare nulla di nuovo. Pensare “quanti bit nuovi di struttura aggiunge questo dato” è una guida migliore che pensare “quanti token in più”.

Mettere ridondanza nei prompt con cognizione di causa. Few-shot, formati espliciti, istruzioni ripetute: nella lente del canale, sono codifica ridondante contro il rumore del fraintendimento. Aiutano per lo stesso motivo per cui un codice a correzione d’errore aiuta — margine — ma, come ogni ridondanza, costano bit (qui: token). La scelta giusta bilancia robustezza e budget, esattamente come nel progetto di un codice.

Regolarizzazione come limite di informazione. Weight decay, dropout, early stopping si lasciano leggere come modi di limitare l’informazione che il modello assorbe dai dati specifici di training (il ponte è in Learning come estrazione di struttura). Non è “rendere il modello più stupido”: è impedirgli di memorizzare ciò che non generalizza.

Scegliere il livello di un benchmark di compressione come proxy di capacità. Quando si confrontano modelli candidati per un compito, la perplexity (o meglio i bits-per-byte) su un corpus rappresentativo del dominio target è un primo filtro veloce ed economico: misura quanto il modello ha già “compreso” la distribuzione del dominio, prima ancora di valutarlo su task specifici. Non sostituisce le eval di task — un modello può comprimere bene e ragionare male — ma è un sensore precoce e a basso costo, e va letto come tale: un modello con bits-per-byte molto alto sul dominio quasi certamente faticherà; uno con bits-per-byte basso ha almeno le basi statistiche giuste, da verificare poi sul comportamento.

Dove si rompe

Questa sezione è ampia di proposito: la lente informazionale sui LLM è potente proprio dove rischia di sembrare onnipotente, e sapere dove smette di vedere vale quanto saperla usare.

“Predire bene significa capire.” È la tesi forte, quella di Hutter e dello Hutter Prize, ed è qui che il capitolo deve essere più severo con se stesso. L’identità compressione-predizione è un teorema; il salto da lì a “comprensione” è una tesi filosofica separata. Un modello può comprimere ottimamente un testo sfruttando regolarità statistiche superficiali senza alcun modello del mondo nel senso in cui un umano lo intende. La complessità di Kolmogorov, che dà fondamento teorico all’idea (cap. 05), è per giunta incalcolabile: non esiste un algoritmo che trovi il programma più corto. MDL è la sua versione domestica, ma solo relativa a una classe di modelli scelta. “Comprimere = capire” resta un programma di ricerca e una posizione filosofica, non un risultato consolidato sul machine learning pratico.

“Comprimere è tutto ciò che un LLM fa.” No. La lente compressione-predizione descrive il pretraining, l’addestramento a predire il prossimo token su grandi corpus. Ma i modelli moderni passano poi per fasi che ottimizzano obiettivi diversi: il fine-tuning supervisionato, l’RLHF (apprendimento per rinforzo da feedback umano), l’addestramento al ragionamento. Questi non minimizzano la cross-entropy di pretraining; allineano il comportamento, premiano risposte utili, insegnano a usare il test-time compute. Un modello reasoning che “pensa” più a lungo prima di rispondere spende compute a inferenza in un modo che la pura perplexity di pretraining non cattura affatto. La lente informazionale è di pretraining, e di pretraining soltanto.

“Comprimere è ragionare.” Distinto dal punto precedente e altrettanto importante. La compressione cattura struttura statistica predittiva, non necessariamente ragionamento multi-step, pianificazione, o verifica di una conclusione. Un compressore eccellente può non saper sommare due numeri grandi che non ha mai visto, perché sommare non è una regolarità statistica del testo ma una procedura. Leggere i LLM solo come compressori rende invisibile tutto ciò che riguarda il ragionamento — che è oggetto di una Parte intera dedicata al reasoning e al test-time compute.

“Comprimere è agency.” Un compressore non agisce nel mondo, non chiama tool, non ha obiettivi, non mantiene stato tra una sessione e l’altra. Tutto ciò che fa di un LLM un agente — l’uso di strumenti, la memoria, il loop percezione-azione — è fuori dal raggio della lente informazionale. La teoria dell’informazione è muta sull’agency, e va bene così: è una lente, non una teoria del tutto.

Loss bassa è compatibile con output dannosi. Allineamento, sicurezza, calibrazione, tossicità, veridicità: nessuna di queste è una quantità informazionale. Un modello con perplexity bassissima può produrre testo fluentissimo, comprimibilissimo, e completamente falso o dannoso. La loss misura quanto il modello prevede la prossima parola, non se quella parola è vera o sicura. Confondere “comprime bene” con “è affidabile” è un errore di categoria.

Il caveat del peso del modello, di nuovo. Vale la pena ripeterlo perché è il punto più sfruttato nei titoli sensazionalistici: “il LLM batte gzip” è onesto solo se il confronto conta il costo del compressore o lo ammortizza su molti dati. Su un singolo file piccolo, con il modello da trasmettere, gzip vince sempre. La compressione di Chinchilla al 43,4% su ImageNet è reale e impressionante, ma è una compressione condizionata a un modello che da solo pesa quanto un piccolo data center.

Le scaling laws non sono leggi di natura. I numeri di Kaplan e Hoffmann sono fit empirici, legati a un’epoca, a un’architettura, a un mix di dati. Sono già stati rivisti: lavori successivi hanno discusso discrepanze tra le leggi di Kaplan e quelle di Chinchilla, e le costanti cambiano con i dati e con le tecniche. Trattarle come costanti universali è leggerle troppo letteralmente. E inoltre, l’inquadramento “compute-optimal = allocazione ottimale di informazione” è una lente concettuale: i “bit di informazione nei dati” non sono una quantità che quei paper misurano.

L’information bottleneck non spiega i transformer. Come visto, la tesi delle due fasi è contestata, e la stima dell’informazione mutua interna in alta dimensione è fragile. Non dare per assodato che “il modello generalizza perché comprime le rappresentazioni” sia un meccanismo stabilito: è un dibattito aperto.

Confondere i due “comprimere”. Nel capitolo “comprimere” compare in due sensi distinti. Uno: il modello comprime il testo — la loss come bit per token, l’identità predizione-compressione, solida. L’altro: il modello comprimerebbe le sue rappresentazioni interne dell’input — l’information bottleneck, dibattuto. Sono affermazioni di solidità opposta su oggetti diversi. Tenerle separate è una delle protezioni più semplici contro l’entusiasmo informazionale mal riposto.

Comprimere bene ha un rovescio: la memorizzazione. La lente “il modello comprime i dati” suona benigna finché non ci si ricorda che comprimere alla perfezione un esempio raro significa averlo, di fatto, memorizzato. Un modello con capacità in eccesso rispetto all’informazione utile dei dati può spendere quella capacità per ricordare alla lettera frammenti del training set — numeri di carta, indirizzi, codice proprietario — invece che per la struttura generale. È il lato oscuro dell’identità compressione-predizione: lo stesso meccanismo che rende un modello un buon compressore lo rende anche capace di rigurgitare dati specifici. La quantificazione di questo rischio (la training-data extraction, la membership inference) è oggetto dei capitoli di privacy e sicurezza; qui basta segnalare che “comprime bene” non è sempre una virtù, e che la capacità informazionale dei pesi è anche una superficie di rischio.

L’in-context learning, visto come compressione, è suggestivo ma non chiuso. Delétang e colleghi notano che la capacità di un modello di “imparare” da pochi esempi dentro il prompt si lascia leggere come compressione adattiva: il contesto fornisce informazione che riduce la sorpresa sui token successivi, quindi accorcia la loro codifica. È una lettura elegante e coerente con tutto il capitolo. Ma il come l’in-context learning funzioni internamente resta in larga parte aperto, e ridurlo a “compressione adattiva” descrive l’effetto, non il meccanismo. Anche qui: la lente informazionale illumina cosa succede in bit, non perché succeda nei circuiti del modello.

Cosa portarsi a casa

Se di tutto il capitolo dovesse restare una sola cosa, è questa: pensare in bit rende leggibili i numeri con cui si lavora ogni giorno sui LLM. Tre traduzioni concrete, che valgono per chiunque addestri, valuti o usi un modello.

Una loss è un tasso di compressione, una perplexity è un branching factor. Quando vedi una loss, non è un numero astratto da minimizzare per fede: è quanti bit per token il modello spende per scrivere il testo. Dividila per $\ln 2$ se è in nat, esponenziala per avere la perplexity, e leggi quel numero come “quante opzioni equiprobabili il modello sta considerando in media”. Una perplexity di 2 su testo significa un modello quasi sempre sicuro; una perplexity di 50 su un dominio che dovrebbe conoscere segnala che non ha estratto la struttura. E ricordati la regola d’oro del confronto: tra modelli con tokenizzatori diversi, solo i bits-per-byte sono onesti.

Un token budget è un budget di bit. Il context window non si riempie di parole, si riempie di informazione. Lo stesso contenuto scritto in modo verboso ma prevedibile costa token senza portare bit nuovi; scritto in modo denso, usa il budget meglio. Quando devi decidere cosa tenere nel contesto e cosa riassumere, la domanda giusta è “quanta informazione perdo”, non “quante parole taglio”. Materiale ad alta entropia — fatti specifici, numeri, vincoli — va tenuto; materiale ridondante a bassa entropia si comprime senza danno.

Più dati di qualità aiutano perché portano più bit utili. Le scaling laws dicono che più dati abbassano la loss, ma la lente informazionale spiega quali dati. Dati di qualità hanno più struttura e meno rumore: più informazione estraibile per token. Dati duplicati non aggiungono bit nuovi — è per questo che la deduplicazione conta, e per questo un piccolo corpus pulito può valere più di un grande corpus sporco. “Quanti bit nuovi di struttura aggiunge questo dato” è una guida migliore di “quanti token in più”.

A queste tre si aggiunge la disciplina che attraversa il capitolo: quando senti dire “il modello comprime, quindi capisce”, fermati e chiediti in quale colonna sta quella frase — identità, risultato empirico, tesi, analogia. La parte solida (predire bene è comprimere bene) è un teorema; la parte seducente (comprimere è capire) è una tesi. Confonderle è l’errore più comune di chi usa la lente informazionale senza la pinza.

Ponte verso il resto della wiki

Questo capitolo chiude la Parte XIII guardando il language model da fuori: come un predittore, come un compressore, come una macchina che spende bit. È la prospettiva giusta per capire cosa misura una loss e cosa promette una scaling law, ma è muta sulla meccanica interna. Le Parti successive aprono la scatola.

L’anatomia di un LLM riprende la tokenizzazione (di cui qui abbiamo dato la lettura informazionale) e ne mostra il funzionamento token per token; riprende i logits e la temperatura (qui visti come manopola sull’entropia) e ne mostra il decoding in dettaglio. Il training riprende loss, perplexity e scaling laws (qui la cornice in bit) e li sviluppa come capitoli propri, con il compute-optimal e i dati di pretraining. L’inferenza riprende il decoding e il context window (qui il budget di bit) e ne mostra i costi reali, il KV cache, le ottimizzazioni. In tutti e tre i casi, la lente informazionale di questo capitolo resta sullo sfondo come griglia di lettura: ciò che lì è meccanica, qui era la ragione informazionale per cui quella meccanica esiste.

Collegamenti

Informazione come riduzione di incertezza: l’entropia come sorpresa media, il source coding theorem che mette il pavimento alla compressione, e la perplexity come $2^{H}$ . Il fondamento di tutto il capitolo, incluso il limite di ~1 bit/char dell’inglese.
Canali, rumore, capacità: il canale rumoroso da cui prende forma l’analogia uomo-LLM. Il prompt come messaggio attraverso un canale, con la cautela che è analogia, non un canale di Shannon formale.
Ridondanza, error correction, robustezza: la ridondanza aggiunta per robustezza al rumore, che illumina perché few-shot e formati espliciti aiutano nei prompt, e perché la deduplicazione dei dati conta.
Minimum Description Length: la codifica aritmetica e l’identità tra log-loss e lunghezza di codifica, il cuore tecnico dell’affermazione “predire = comprimere”.
Compressione e complessità algoritmica: la radice della tesi “comprimere = capire” in Solomonoff e Kolmogorov, e l’incalcolabilità che la tiene a livello di programma filosofico più che di teorema operativo.
Informazione mutua e dipendenza: la quantità $I(\cdot;\cdot)$ con cui si formula l’information bottleneck delle rappresentazioni interne e la capacità del modello di assorbire informazione dai dati.
Compressione lossy e perdita accettabile: il trade-off rate-distortion che fa da lente sui modelli generativi con bottleneck e a cui l’information bottleneck è formalmente imparentato.
Learning come estrazione di struttura: il capitolo gemello che fa il ponte generale verso l’apprendimento. Questo capitolo ne è l’applicazione mirata ai language model; loss come codifica, perplexity, regolarizzazione come limite di informazione vengono da lì.
Entropia, cross-entropy, KL divergence: la macchina formale della cross-entropy che è la loss di ogni LLM, e la sua decomposizione in entropia più KL.
Dalla somma alla probabilità: la softmax che trasforma i logits in distribuzione di probabilità, e su cui agisce la temperatura nel decoding.
tokenizzazione-intro e bpe (in preparazione): la meccanica del Byte-Pair Encoding e della tokenizzazione sub-word, di cui qui si dà la lettura informazionale come scelta di codifica.
output-logits e greedy-beam (in preparazione): le strategie di decoding in dettaglio, di cui qui si tratta solo l’angolo entropia (temperatura come manopola sull’incertezza).
scaling-laws, compute-optimal e loss-perplexity (in preparazione): i capitoli di training che sviluppano Kaplan e Chinchilla, qui letti in chiave di bit e allocazione di informazione.
cot-intro e test-time-scaling (in preparazione): il reasoning e il test-time compute, ciò che la lente della compressione di pretraining non cattura e che marca uno dei limiti del capitolo.
privacy-modelli e membership-inference (in preparazione): il rovescio della medaglia della compressione, dove memorizzare bene un esempio raro diventa un rischio di estrazione dei dati di training.

Per andare oltre

Delétang, G., Ruoss, A., … Hutter, M., Veness, J. (2024). Language Modeling Is Compression, ICLR 2024 (arXiv:2309.10668). Il paper che mostra coi numeri che i LLM sono compressori general-purpose, batte i compressori specializzati su testo, immagini e audio, e discute il caveat del peso del modello. Il riferimento centrale del capitolo.
Shannon, C. E. (1951). Prediction and Entropy of Printed English, Bell System Technical Journal, 30, 50-64. L’esperimento del guessing game che stima l’entropia dell’inglese a ~1 bit/char e lega, già nel 1951, la predizione alla comprimibilità. La radice intuitiva di tutto.
Kaplan, J. et al. (2020). Scaling Laws for Neural Language Models (arXiv:2001.08361). La loss come legge di potenza nelle risorse, da leggere insieme a Hoffmann, J. et al. (2022), Training Compute-Optimal Large Language Models (arXiv:2203.15556, “Chinchilla”) per l’allocazione compute-optimal e l’euristica dei ~20 token per parametro.
Sennrich, R., Haddow, B., Birch, A. (2016). Neural Machine Translation of Rare Words with Subword Units, ACL 2016 (arXiv:1508.07909). Il paper che porta il BPE — algoritmo di compressione di Gage (1994) — nella tokenizzazione, documentando la filiazione compressione-tokenizzazione.
MacKay, D. J. C. (2003). Information Theory, Inference, and Learning Algorithms, Cambridge University Press (gratuito online). Il testo che intreccia teoria dell’informazione, codifica aritmetica, perplexity e modelli predittivi con esempi visivi; lo sfondo unificante della Parte XIII.
Hutter, M. The Hutter Prize for Lossless Compression of Human Knowledge (prize.hutter1.net). La pagina del premio, attivo dal 2006, che mette in palio denaro per chi comprime al meglio un file di testo Wikipedia. Utile per vedere, da chi la sostiene, la tesi “comprimere è capire” nella sua forma più netta e i suoi criteri operativi.
Cover, T. M. & King, R. C. (1978). A Convergent Gambling Estimate of the Entropy of English, IEEE Transactions on Information Theory. Raffina la stima di Shannon dell’entropia dell’inglese con un metodo a scommessa, confermandone l’ordine di grandezza (~1,3 bit/char). Da leggere accanto a Shannon (1951) per vedere come la stessa quantità venga misurata con metodi diversi.
Cover, T. M. & Thomas, J. A. (2006). Elements of Information Theory, 2a ed., Wiley. Il manuale di riferimento per le identità su cui poggia il capitolo: source coding, entropia condizionata, codifica e il legame tra gambling, predizione e compressione. Il posto dove i teoremi qui solo enunciati sono dimostrati per esteso.