Context window: quanti token vede un modello

Chiedi a un modello di riassumere un libro di quattrocento pagine e, a un certo punto, si ferma. Non si è stancato: il libro non ci sta. Lo spazio dentro cui un modello legge, ragiona e risponde si chiama context window, con un limite preciso, misurato in token.

È uno dei numeri che compaiono più spesso nelle schede tecniche e uno dei meno capiti. Capire come funziona spiega un sacco di comportamenti che sembrano capricci: risposte che dimenticano un dettaglio detto dieci minuti prima, conversazioni che peggiorano con il passare dei messaggi, costi che salgono senza un motivo evidente.

Cos’è la context window

La context window, o finestra di contesto, è il numero massimo di token che un modello può tenere sotto gli occhi in una singola elaborazione. Non è memoria a lungo termine, non è un archivio, non è una cartella in cui salvare le cose: è lo spazio di lavoro disponibile in quel momento. Vale solo per quella richiesta.

Dentro ci finisce tutto. Le istruzioni di sistema, i messaggi precedenti della conversazione, i documenti che hai incollato e anche la risposta che il modello sta scrivendo. Se la finestra è da 128.000 token, quel budget va diviso tra tutte queste voci. Non è una quota riservata a te.

Un modo semplice per visualizzarla è pensare a una scrivania. Più è grande, più fogli ci stanno sopra contemporaneamente. Ma la scrivania non ricorda cosa ci hai messo ieri; se la riempi di carte finisce che non trovi più il foglio che ti serve, anche se è lì in mezzo.

Perché si misura in token e non in parole

Un token è un pezzo di testo. Non sempre coincide con una parola. Può essere una parola intera, un pezzo di parola, un segno di punteggiatura, uno spazio. Il modello non legge lettere e non legge parole: legge questi frammenti, li trasforma in numeri e lavora su quelli.

Il conto, in pratica, è questo: in inglese un token vale all’incirca quattro caratteri, quindi 750 parole stanno in circa mille token. In italiano la musica cambia, perché i tokenizer sono addestrati soprattutto su testi inglesi e spezzano le parole italiane più spesso. La stessa frase costa tendenzialmente il 15-30% in più rispetto all’inglese.

Ci sono poi i testi che consumano molto più del previsto: codice, JSON, URL lunghi, elenchi di numeri, emoji. Una riga di codice compatta può valere dieci token, un link con parametri anche venti. Se incolli un file di configurazione da duecento righe, il conto sale in fretta.

Regola pratica per orientarsi: 1.000 parole italiane occupano più o meno 1.400-1.700 token. Utile quando devi capire se un documento entra o no.

Cosa succede quando la finestra si riempie

Finché c’è spazio, il modello lavora con tutto quello che gli hai dato. Quando lo spazio finisce, deve succedere qualcosa. Le strade sono tre.

La prima è il troncamento: le parti più vecchie della conversazione vengono tagliate e il modello continua a lavorare solo su quelle recenti. È il comportamento più comune nelle applicazioni commerciali, ed è anche il più insidioso, perché il taglio avviene in silenzio. Tu hai l’impressione che il modello abbia letto tutto, invece le tue istruzioni iniziali sono già sparite.

La seconda è la compattazione: il sistema riassume i messaggi vecchi e li sostituisce con un riassunto più corto. Funziona meglio del taglio secco, ma introduce un passaggio di perdita: i dettagli rari spariscono nel riassunto. Spesso sono proprio quelli che servivano.

La terza è l’errore. Alcune API rifiutano la richiesta e ti restituiscono un messaggio del tipo “context length exceeded”. È il comportamento più onesto, perché ti dice chiaramente che il conto non torna.

Esiste anche una variante più elegante, la finestra scorrevole: il sistema tiene solo gli ultimi N token e scarta il resto man mano che avanza. È quello che succede, in modo automatico, nella maggior parte delle chat quando la conversazione si allunga.

Il modello non ha memoria: ogni richiesta riparte da zero

Questo è il punto che genera più confusione. Un modello linguistico, di per sé, non ricorda nulla. Non ha un archivio delle conversazioni precedenti, non ha un profilo utente, non ha una memoria condivisa tra una richiesta e l’altra.

Quello che sembra memoria è un trucco del client. Ogni volta che invii un messaggio, l’applicazione rimanda al modello tutta la conversazione, dal primo messaggio in poi. Il modello rilegge tutto da capo e produce la risposta successiva. La “memoria” è quindi un file di testo che viaggia insieme a ogni richiesta.

Da qui derivano due conseguenze concrete. La prima: più la conversazione è lunga, più token vengono rimandati ogni volta. La seconda: quando la finestra si satura, i messaggi più vecchi vengono tagliati. Il modello letteralmente non sa più cosa gli avevi detto all’inizio.

Contesto lungo non significa contesto capito

Qui arriva la parte meno intuitiva. Avere una finestra grande non garantisce che il modello usi bene tutto quello che ci sta dentro. Nel 2023 un gruppo di ricerca ha pubblicato uno studio diventato famoso, “Lost in the Middle”, con un risultato piuttosto netto: le informazioni collocate all’inizio o alla fine del contesto vengono recuperate molto meglio di quelle messe in mezzo.

In pratica, se metti un dato importante nella posizione centrale di un documento lunghissimo, hai buone probabilità che il modello lo salti. Non è pigrizia: è il modo in cui funziona l’attenzione su sequenze molto lunghe, dove il segnale si diluisce. Il fenomeno è collegato a come il modello pesa le posizioni, lo stesso meccanismo che sta dietro al positional encoding.

C’è poi una differenza tra trovare un’informazione e ragionarci sopra. I test tipo “ago nel pagliaio” misurano la prima capacità: nascondono una frase in un testo enorme e chiedono di ripeterla. Il modello la trova, quasi sempre. Ma se gli chiedi di confrontare tre documenti e trarre una conseguenza che nessuno dei tre contiene esplicitamente, le prestazioni calano molto prima di quanto cali il recupero.

Gli esperimenti sui contesti da un milione di token mostrano un altro dettaglio: oltre una certa soglia, la qualità tende a peggiorare anche sui compiti semplici. La finestra è grande, ma l’attenzione non è infinita. I modelli sono bravi a gestire testi lunghi, non a leggerli come li legge una persona che prende appunti.

Quanto costa un contesto lungo

Il costo ha due facce. Nessuna delle due è banale.

La prima è computazionale. Il meccanismo di self-attention confronta ogni token con tutti gli altri: raddoppi la lunghezza del contesto e il lavoro cresce all’incirca di quattro volte. È il motivo per cui i contesti enormi costano tanto in termini di calcolo e di tempo di risposta. Le varianti come la multi-head attention migliorano la qualità della lettura, ma non cambiano l’ordine di grandezza del problema.

La seconda è la memoria. Durante la generazione il modello conserva una struttura chiamata KV cache, che tiene traccia dei calcoli già fatti sui token precedenti. Questa struttura cresce in modo lineare con la lunghezza del contesto e occupa memoria della GPU. Un contesto da un milione di token può richiedere decine di gigabyte solo per la cache, prima ancora di calcolare qualsiasi cosa.

Poi c’è il costo che vedi in fattura. I provider fatturano per token. I token di input costano meno di quelli di output, ma vengono conteggiati ogni volta. In una chat di trenta messaggi, il primo messaggio viene riletto e ripagato trenta volte. È il motivo per cui conversazioni lunghissime diventano care anche se ogni singola risposta è breve.

Come usare bene la finestra di contesto

Non serve riempirla. Serve usarla con criterio. Alcune abitudini fanno una differenza enorme.

• Istruzioni ai due estremi. Le due estremità del contesto sono le zone che il modello legge meglio.
• Solo ciò che serve. Se ti servono tre pagine di un documento da cento, incolla quelle tre. Il resto è rumore che diluisce il segnale.
• Riassumi ogni tanto. In una chat lunga, fai produrre al modello un riassunto delle decisioni prese e riparti da quello.
• Compiti a blocchi. Un documento da duecento pagine si affronta a capitoli, non tutto insieme.
• Recupero mirato. Se hai un archivio, conviene cercare i passaggi rilevanti e passare solo quelli, invece di incollare l’archivio intero.
• Risposte brevi. Anche l’output consuma finestra. In una conversazione lunga ogni risposta diventa materiale per il turno successivo.

Finestra grande o recupero mirato

Per anni la risposta è stata una sola: contesti più grandi, sempre. Oggi la prospettiva è più equilibrata, perché i due approcci risolvono problemi diversi.

Il contesto lungo è imbattibile quando il documento è coerente e va letto insieme: un contratto, un codice sorgente, un saggio, una trascrizione. Lì il modello ha bisogno di vedere tutto per capire i rimandi interni. Nessun recupero a pezzi restituisce la stessa comprensione.

Il recupero mirato, cioè la ricerca dei passaggi rilevanti prima di passarli al modello, vince quando l’archivio è grande, eterogeneo e in continuo aggiornamento: una base di documenti aziendali, una wiki, un catalogo. Non ha senso caricare tutto. Soprattutto non ha senso pagarlo a ogni domanda.

La soluzione che si usa sempre più spesso è ibrida: recupero i passaggi candidati, li passo al modello con un contesto ampio ma non enorme. Lascio che sia il modello a scartare quello che non serve. Il contesto largo fa da rete di sicurezza, il recupero evita di sprecare la finestra.

Quanto è grande una finestra, in pratica

Per orientarsi senza perdersi nei numeri, qualche riferimento concreto.

• 8.000 token: un articolo lungo o un capitolo. È la dimensione tipica dei modelli più vecchi e dei contesti “base”.
• 32.000 token: un racconto breve, un documento tecnico di media lunghezza.
• 128.000 token: circa 90.000 parole in inglese, cioè un romanzo di media lunghezza. È la fascia più diffusa tra i modelli di punta.
• 200.000 token: un romanzo lungo più note e appunti.
• 1.000.000 di token: diverse centinaia di migliaia di parole, nell’ordine di sei-otto libri. Qui però entrano in gioco i limiti di attenzione di cui parlavo prima.

Il numero da solo dice poco. Un modello con una finestra da un milione di token che si perde a metà documento è meno utile di un modello con 128.000 token che li legge bene. La domanda giusta non è “quanto è grande”, ma “quanto è affidabile su quello che ci metto dentro”.

Domande frequenti

La context window è la stessa cosa della memoria del modello?

No. La finestra di contesto è lo spazio di lavoro di una singola richiesta. La memoria del modello, quella che viene dai pesi appresi durante l’addestramento, è un’altra cosa e resta identica tra una conversazione e l’altra. Quella che chiamiamo “memoria della chat” è in realtà la cronologia che il client rimanda ogni volta.

Cosa succede se il mio testo supera la finestra di contesto?

Dipende dall’applicazione. Alcune rifiutano la richiesta con un errore, altre tagliano le parti più vecchie, altre riassumono la conversazione. Nel caso del taglio, spesso spariscono le istruzioni iniziali, quindi il modello può sembrare improvvisamente distratto o fuori tema.

Una finestra più grande rende il modello più intelligente?

No, sono due cose separate. La finestra dice quanto testo il modello può vedere, non quanto bene lo capisce. Un modello con un contesto enorme può restare mediocre nel ragionamento. Uno con una finestra più piccola può essere più preciso sui compiti che gli competono.

Perché la chat diventa più lenta e costosa andando avanti?

Perché ogni messaggio rimanda al modello tutta la conversazione precedente. Più la cronologia cresce, più token vengono elaborati a ogni turno. Il costo in fattura e il tempo di risposta salgono di conseguenza. È il motivo per cui conviene ripartire da un riassunto quando una conversazione si allunga troppo.

Quanti token consuma una pagina di testo in italiano?

Una pagina di circa 500 parole in italiano occupa all’incirca 700-850 token. Il valore esatto dipende dal tokenizer del modello: alcuni spezzano le parole italiane in modo più aggressivo, quindi il conteggio può variare anche del 20% da un modello all’altro.

Posso aumentare la context window di un modello?

Non con un’impostazione. La finestra è una caratteristica dell’architettura e dell’addestramento, non un parametro che si regola dall’esterno. Esistono tecniche di estensione del contesto applicate dopo l’addestramento, ma richiedono competenze tecniche e non sono disponibili nelle normali interfacce di uso.

Detto questo, la finestra di contesto è una di quelle cose che si capiscono davvero solo quando ci si sbatte contro. La prossima volta che un modello “dimentica” qualcosa, prima di dargli del distratto, controlla quanti token gli hai messo davanti.