Come torna solo da te

Qui sotto c'è un esperimento con una variabile sola, e vale la pena farlo invece di leggerne il risultato. Prima ti presenti: scrivi una frase su di te, quella che vuoi — «mi chiamo Luca e tifo Inter» va benissimo. Quella frase diventa il primo turno vero della conversazione e il modello ti risponde. Poi c'è l'interruttore: acceso, insieme alla tua domanda parte anche tutto quello che vi siete detti prima; spento, parte solo la domanda. Infine chiedi «che cosa sai di me?» e confronti. Stesso modello, stessa domanda, stesso istante: cambia una cosa sola. Se il tuo nome sparisce quando spegni l'interruttore, non è perché il modello si sia distratto — è perché dentro di lui non esiste nessun posto in cui il tuo nome fosse rimasto.

E lo scontrino in cima alla scheda? È l'altra metà della storia. Quel numero l'ho fatto generare al tuo browser adesso, ricaricando la pagina cambia, e serve a una cosa sola: dire al server a quale finestra aperta deve tornare la risposta. Non è un documento d'identità, è un numero di guardaroba. Chi ti ridà il cappotto non ti ha riconosciuto in faccia: ha confrontato due numeri. Sotto la chat trovi anche il riquadro che mostra il testo esatto spedito al modello, con quanti caratteri pesa: è lì che la differenza fra le due condizioni si vede a occhio nudo.

Il termine tecnico è stateless, senza stato. Fra una richiesta e la successiva il modello non conserva nulla: né un file, né una variabile, né un residuo delle attivazioni del turno precedente. I suoi parametri — i miliardi di numeri fissati durante l'addestramento — restano identici mentre parli con lui: nessuna delle tue frasi ne sposta uno. Quella che chiami «conversazione» è una finzione ricomposta a ogni turno dal programma che sta in mezzo: prende il registro completo di ciò che vi siete detti, lo concatena in un unico blocco di testo, gli appende in fondo la tua nuova domanda e spedisce tutto. La documentazione delle API lo dice senza giri di parole: ogni richiesta di generazione è indipendente e stateless, e la continuità va costruita a mano rimettendo in input la risposta precedente. Il modello legge quel blocco come se lo vedesse per la prima volta, perché è esattamente ciò che gli sta capitando.

Una confusione facile, che vale la pena togliere di mezzo subito: alcune API oggi tengono lo stato sul server — le Interactions di Gemini gestiscono la storia al posto tuo, a meno che tu non chieda esplicitamente la modalità stateless — e in quel caso non sei tu a rispedire il registro. Ma qualcuno lo rispedisce comunque: il testo che entra nel modello contiene sempre tutta la conversazione, solo che a comporlo è un server invece del tuo browser. Spostare il magazzino non crea la memoria.

Quel blocco di testo ha un tetto, e si chiama finestra di contesto: il numero massimo di token che il modello può avere davanti in un colpo solo. Dentro quel budget ci sta tutto — l'istruzione di sistema, la conversazione, i documenti allegati, e anche la risposta che sta scrivendo. Molti modelli oggi dichiarano un milione di token o più; per capire l'ordine di grandezza, Google traduce quel milione in circa otto romanzi inglesi di lunghezza media, o cinquantamila righe di codice, o le trascrizioni di oltre duecento episodi di podcast.

Perché quel tetto esiste, invece di essere infinito: nel meccanismo di attenzione ogni token confronta sé stesso con tutti gli altri, quindi il numero di confronti cresce come il quadrato della lunghezza. È scritto nero su bianco nella Tabella 1 di «Attention Is All You Need», dove la complessità per strato della self-attention vale O(n²·d), con n il numero di token e d la dimensione dei vettori. Un fattore quadratico è brutale in un modo che l'intuizione non prevede: passare da mille a centomila token non moltiplica il lavoro per cento, lo moltiplica per diecimila. Da questa parabola nasce metà della ricerca sull'efficienza degli ultimi anni, catalogata già nel 2020 in una rassegna sui «transformer efficienti» che elencava decine di modi per non pagare quel quadrato per intero.

E quando la finestra si riempie? Qualcosa va buttato, e i due modi correnti perdono informazione entrambi. Il troncamento: si tiene una finestra scorrevole degli ultimi n token e i turni più vecchi cadono fuori dal bordo, senza che nessuno te lo dica. Il riassunto: si chiede al modello stesso di comprimere la parte vecchia in poche righe, e da lì in avanti al posto dell'originale viaggia la sintesi. Il secondo è più elegante e più insidioso, perché ciò che il chatbot «ricorda» di una conversazione di tre ore fa non è più ciò che hai detto: è una parafrasi fatta da un sistema che a volte parafrasa male. Se ti è mai capitato che un assistente riportasse una tua richiesta in modo storto dopo una lunga sessione, spesso il colpevole è qui, non nella comprensione.

Anche restando dentro la finestra, non tutte le posizioni valgono uguale. Nel 2023 Nelson Liu e colleghi di Stanford hanno pubblicato «Lost in the Middle: How Language Models Use Long Contexts» (poi in Transactions of the ACL): spostando l'informazione utile in punti diversi di un contesto lungo, in compiti di domanda-risposta su più documenti e di recupero chiave-valore, la prestazione risulta più alta quando quell'informazione sta all'inizio o alla fine, e cala in modo netto quando finisce in mezzo. La curva ha la forma di una U, e vale anche per i modelli costruiti apposta per i contesti lunghi. È il profilo dell'effetto di posizione seriale che gli psicologi chiamano primacy ed recency, con una differenza sostanziale: qui non c'è nessuna traccia mnestica che decade, c'è una distribuzione di attenzione sbilanciata dal modo in cui il modello è stato addestrato e da come sono codificate le posizioni.

La conseguenza pratica è immediata, e la puoi applicare stasera: se scrivi un prompt lungo, l'istruzione che conta va in cima o in coda, non annegata a metà fra due pagine di contesto incollato. Ripeterla in fondo, dopo il materiale, costa venti token e funziona.

Onestà sullo stato della prova: da allora i modelli sono migliorati parecchio sui test più semplici — pescare un «ago» inserito in un pagliaio di testo è ormai quasi banale — ma il problema non è sparito, si è spostato. Il benchmark RULER (Hsieh e colleghi, COLM 2024) ha misurato diciassette modelli a contesto lungo su tredici compiti: pur dichiarando tutti 32.000 token o più, solo metà regge prestazioni accettabili a quella lunghezza, e quasi tutti peggiorano man mano che il contesto cresce. La lunghezza effettiva è quasi sempre parecchio più corta di quella pubblicizzata sulla scheda tecnica. Tienine conto quando leggi «un milione di token» in una pagina di marketing.

A questo punto sorge un sospetto ragionevole: se a ogni turno il modello si rilegge l'intera conversazione, un dialogo lungo dovrebbe diventare insostenibile. Non succede, e il motivo ha un nome: la KV cache. Nell'attenzione ogni token produce tre vettori — query, key e value; le key e i value dei token già visti non cambiano quando ne arriva uno nuovo, quindi ricalcolarli è lavoro buttato. Tenendoli in memoria, il costo per passo di generazione scende da quadratico a lineare. Sebastian Raschka lo implementa da zero e lo misura: generando 200 token con un modello da 124 milioni di parametri su un Mac Mini M4, la cache porta circa cinque volte la velocità (giugno 2025). Il prezzo lo paghi in memoria: la cache cresce a ogni token e su contesti lunghi arriva a occupare una quota proibitiva della memoria della GPU — è il motivo per cui esistono varianti come la grouped-query attention, nate per farla dimagrire.

Lo stesso principio, portato fuori dalla singola richiesta, è ciò che i fornitori vendono come context caching: il prefisso identico di una conversazione — che poi è tutto il registro tranne l'ultima domanda — viene riusato invece di essere rimacinato, e la documentazione di Google dichiara di passare automaticamente il risparmio a chi centra la cache. La morale è controintuitiva e vale la pena tenerla ferma: rispedire tutto non costa quanto sembra, ma non perché il modello ricordi. Perché il server ricorda i conti già fatti.