La context window è tutto ciò che il modello può vedere nello stesso momento: le tue istruzioni, la conversazione fino a quel punto, i documenti incollati e la risposta che sta scrivendo. Non è memoria. Nulla sopravvive alla fine della richiesta.
Quinto articolo di una serie su come funzionano davvero i modelli linguistici.
Una sola window, condivisa da tutto
Un modello che dichiara una window da 200.000 token sta descrivendo un unico budget condiviso. System prompt, cronologia della chat, documenti recuperati, definizioni dei tool, risultati dei tool e risposta consumano tutti la stessa disponibilità. Nulla è gratis, e la risposta compete con l’input.
Questo sorprende soprattutto quando sono coinvolti dei tool. Ogni tool che il modello può chiamare è descritto dentro la window, e quelle descrizioni sono sempre presenti indipendentemente dal fatto che il tool venga usato. Venti definizioni verbose possono consumare una parte significativa del budget prima ancora che l’utente abbia scritto qualcosa.
Lungo non significa uniformemente buono
Una window grande significa che il modello accetterà quella quantità di testo. Non significa che la userà tutta allo stesso modo. Misurando molti modelli, il recupero di un fatto specifico è più forte quando quel fatto si trova vicino all’inizio o alla fine del contesto e più debole nel mezzo — il cosiddetto effetto “lost in the middle”.
La risposta ingegneristica è semplice ed efficace. Metti le istruzioni in alto e la domanda vera e propria in basso, così ciò che vuoi venga rispettato maggiormente si trova in una posizione forte. E preferisci selezionare cinque paragrafi rilevanti invece di incollarne cinquanta sperando che funzioni. Un contesto più piccolo ma meglio scelto supera regolarmente uno più grande, e costa meno.
Non esiste memoria tra richieste
Ogni chiamata API è autonoma. Un’interfaccia chat sembra continua perché reinvia silenziosamente i turni precedenti ogni volta. Nulla di ciò che hai detto viene ricordato come stato della conversazione. Un provider può mettere in cache il calcolo su un prefisso ripetuto, come descritto sotto, ma è un’ottimizzazione delle prestazioni, non memoria, e non cambia ciò che il modello può richiamare.
Ne seguono due cose. Le conversazioni diventano progressivamente più costose, perché ogni turno reinvia tutto ciò che lo precede. E quando una chat lunga inizia a “dimenticare”, di solito è perché i turni più vecchi sono stati tagliati per rientrare nel limite — l’informazione non è decaduta, è stata rimossa.
Qualunque cosa debba persistere davvero deve vivere da qualche parte sotto il tuo controllo — database, file, oppure un riepilogo che reinietti deliberatamente. Questa è l’intera base del design della memoria negli agenti: un normale problema di storage con vestiti insoliti.
La cache cambia l’economia
Poiché la parte costosa di un prompt lungo è rielaborare lo stesso prefisso più e più volte, i provider permettono di metterlo in cache. Mantieni il materiale stabile — system prompt, definizioni dei tool, documento di riferimento — all’inizio e invariato, e le chiamate successive riutilizzano quel lavoro con un forte sconto.
Questo premia una disposizione precisa: contenuto stabile prima, contenuto variabile dopo. Inserire un timestamp in cima a un prompt altrimenti fisso invalida la cache a ogni chiamata. Spostarlo in fondo non costa nulla e conserva lo sconto.
Che cosa portarsi a casa
La context window è un tavolo di lavoro, non un archivio. È condivisa da ogni parte della richiesta, non viene richiamata in modo uniforme, si svuota completamente tra una chiamata e l’altra e la sua parte iniziale è il posto più economico dove mettere ciò che non cambia. Progetta attorno a questi quattro fatti e i sistemi long-context diventano prevedibili anziché misteriosi.
Articoli precedenti della serie: come funziona un modello linguistico, che cosa sono i token, come l’attention decide che cosa conta e che cosa controlla davvero la temperature.