Context window: cos’è, quanti token servono e come configurarla

La context window, o finestra di contesto, è la quantità massima di informazioni che un modello di intelligenza artificiale può ricevere e utilizzare durante una singola elaborazione. Viene misurata in token e comprende molto più del testo appena scritto dall’utente.

Dentro la finestra devono trovare spazio le istruzioni di sistema, la conversazione precedente, i documenti recuperati da un sistema RAG, i risultati degli strumenti, eventuali immagini o trascrizioni e i token necessari a generare la risposta. Quando lo spazio si esaurisce, una parte del contenuto deve essere eliminata, riassunta o esclusa.

Una finestra più grande può essere utile, ma non rende automaticamente il modello più intelligente. Può aumentare memoria richiesta, latenza e costo, mentre informazioni importanti nascoste in mezzo a molto testo possono diventare più difficili da recuperare.

Indice

• Che cos’è realmente la context window
• Che cosa occupa lo spazio disponibile
• Un esempio semplice
• Perché più contesto non significa sempre più qualità
• Context window, memoria e RAG
• Quanto contesto serve davvero
• Context window e AI locale
• Come configurarla in Ollama
• Come progettare prompt e documenti lunghi
• Checklist operativa
• FAQ

Che cos’è realmente la context window

Un modello non consulta automaticamente tutta la cronologia del nostro account, i file presenti sul computer o ogni documento caricato in passato. Per produrre una risposta può lavorare soltanto sugli elementi che l’applicazione gli invia nella richiesta corrente.

La context window è quindi paragonabile a un tavolo di lavoro: possiamo disporvi istruzioni, appunti e documenti, ma lo spazio non è infinito. Se riempiamo il tavolo con materiale irrilevante, trovare il dato importante diventa più difficile anche quando, tecnicamente, tutto riesce a entrarvi.

Il limite è espresso in token, unità in cui il modello divide testo e altri contenuti. Un token non coincide sempre con una parola: punteggiatura, parti di parola, codice e lingue differenti possono produrre conteggi diversi. Per approfondire è disponibile la scheda dedicata ai token.

Che cosa occupa lo spazio disponibile

La finestra non contiene soltanto l’ultima domanda. In un’applicazione reale può includere:

1. istruzioni del sistema e regole dell’assistente;
2. profilo, preferenze o contesto dell’utente;
3. messaggi precedenti della conversazione;
4. testo della nuova richiesta;
5. documenti selezionati da un sistema RAG;
6. risultati di ricerche, API e tool calling;
7. descrizioni di strumenti disponibili;
8. spazio riservato all’output;
9. rappresentazioni di immagini, audio o video nei modelli multimodali.

Questo spiega perché una chat molto lunga può iniziare a dimenticare dettagli iniziali anche se non viene mostrato alcun errore. L’applicazione può rimuovere i messaggi più vecchi, comprimerli in una sintesi oppure selezionare soltanto quelli ritenuti pertinenti.

Un esempio semplice

Immaginiamo un modello con una finestra complessiva di 32.000 token. L’applicazione usa:

Il valore dichiarato dal produttore non equivale quindi alla quantità di testo che possiamo incollare liberamente. Se i documenti recuperati diventano troppo numerosi, l’applicazione deve ridurli oppure sacrificare cronologia e spazio di risposta.

I numeri della tabella sono un esempio progettuale, non una regola universale: tokenizer, formato della richiesta e gestione di input e output cambiano tra modelli e servizi.

Perché più contesto non significa sempre più qualità

Una finestra estesa risolve il problema della capacità, ma non garantisce che il modello utilizzi ogni elemento con la stessa precisione.

Lo studio Lost in the Middle ha mostrato che diversi modelli analizzati recuperavano meglio informazioni collocate all’inizio o alla fine del contesto rispetto a dati presenti nella parte centrale. Il lavoro non dimostra che tutti i modelli moderni si comportino sempre allo stesso modo, ma introduce una distinzione fondamentale: poter ricevere un’informazione non significa saperla usare in modo affidabile.

Anche la documentazione di Google dedicata al long context invita a considerare prestazioni, latenza, costo e posizione della domanda. Per carichi ripetuti propone inoltre il caching del contesto, utile quando una base informativa ampia viene riutilizzata in più richieste.

In pratica, un contesto troppo grande può introdurre:

• più elementi irrilevanti o contraddittori;
• maggiore latenza prima della risposta;
• aumento dei token elaborati e del costo nei servizi cloud;
• maggiore occupazione di memoria nei modelli locali;
• difficoltà nel verificare quali fonti abbiano influenzato l’output;
• prompt injection nascoste dentro documenti o pagine recuperate.

La strategia corretta non è riempire la finestra, ma selezionare il contesto minimo sufficiente per completare il compito.

Context window, memoria e RAG

Questi tre concetti vengono spesso confusi.

La memoria non è automaticamente presente nella finestra. Un’applicazione deve recuperare il dato salvato e reinserirlo nel contesto. Analogamente, un archivio vettoriale non viene “conosciuto” interamente dal modello: il sistema seleziona alcuni frammenti tramite gli embedding e li aggiunge alla richiesta.

Per un manuale di 300 pagine, inserire tutto può essere meno efficace di una buona architettura RAG. Recuperare soltanto i paragrafi pertinenti riduce rumore, latenza e consumo di risorse, consentendo anche di mostrare fonti e applicare permessi per documento. La guida completa al RAG approfondisce questo processo.

Quanto contesto serve davvero

La dimensione corretta dipende dal lavoro, non dal desiderio di scegliere il numero più alto disponibile.

Conversazioni e scrittura breve

Per domande isolate, email e testi brevi è generalmente più importante fornire istruzioni chiare che disporre di centinaia di migliaia di token.

Analisi di documenti

Occorre considerare lunghezza, numero di allegati, spazio di risposta e necessità di citare le fonti. Per documenti ripetitivi può essere preferibile segmentare e recuperare solo le sezioni utili.

Programmazione

Un assistente di codice deve ricevere file, dipendenze, errori e convenzioni pertinenti. Caricare l’intero repository può introdurre file generati, librerie e codice non collegato al problema. Una mappa del progetto seguita dal recupero selettivo è spesso più gestibile.

Agenti AI

Gli agenti accumulano istruzioni, piani, risultati degli strumenti e cronologia delle azioni. Senza una politica di compattazione il contesto cresce rapidamente. Servono sintesi verificabili, stato strutturato e limiti al numero di risultati restituiti dagli strumenti.

Audio, video e multimodalità

Immagini, trascrizioni e video consumano token secondo regole specifiche del modello. La durata in minuti o la dimensione del file non permettono da sole di stimare il contesto necessario: bisogna consultare il metodo di conteggio del servizio utilizzato.

Context window e AI locale

Con un servizio cloud il consumo della finestra è visibile soprattutto come costo e latenza. Nell’AI locale si traduce anche in memoria RAM o VRAM.

Durante la generazione, il runtime conserva una KV cache con informazioni utili sui token già elaborati. Aumentando il contesto cresce la memoria necessaria per questa cache. Il consumo effettivo dipende da architettura, precisione della cache, numero di richieste parallele e implementazione del runtime: non è corretto applicare una singola formula a tutti i modelli.

Un contesto dichiarato molto ampio nel file del modello può quindi non essere la configurazione migliore per il proprio PC. Se parte del modello o della cache viene spostata dalla GPU alla CPU, la risposta può rallentare sensibilmente.

La quantizzazione dei pesi riduce la memoria del modello, mentre la quantizzazione della KV cache può ridurre la memoria legata al contesto. Sono interventi diversi e possono avere conseguenze differenti sulla qualità.

Come configurarla in Ollama

La documentazione ufficiale di Ollama indica che una context window più grande richiede più memoria e consente di modificare il valore dall’applicazione, dalla variabile d’ambiente o tramite API.

Per impostare un valore predefinito quando si avvia il servizio:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

Durante una sessione interattiva:

/set parameter num_ctx 8192

In una richiesta API:

{
  "model": "nome-del-modello",
  "prompt": "Analizza questo documento",
  "options": {
    "num_ctx": 8192
  }
}

Il valore deve restare entro le capacità effettive del modello. Dopo la modifica conviene eseguire:

ollama ps

La colonna CONTEXT mostra il contesto allocato, mentre PROCESSOR aiuta a capire se il modello è interamente sulla GPU o se viene eseguito in parte sulla CPU. Con richieste parallele la memoria può crescere ulteriormente; la FAQ ufficiale di Ollama specifica che il requisito può scalare con il prodotto tra parallelismo e lunghezza del contesto.

Per la configurazione completa del runtime sono disponibili le guide su installazione di Ollama e Open WebUI con Ollama.

Come progettare prompt e documenti lunghi

Una buona gestione del contesto segue alcune regole semplici:

1. Dichiara il compito prima dei documenti. Spiega cosa cercare, quale output produrre e come segnalare informazioni mancanti.
2. Separa le fonti. Usa titoli, identificatori e delimitatori chiari per distinguere un documento dall’altro.
3. Rimuovi il rumore. Menu, firme email, duplicati, intestazioni ripetute e log non pertinenti consumano spazio.
4. Metti in evidenza i vincoli. Scadenze, esclusioni, formato e criteri di verifica non devono restare nascosti in mezzo al testo.
5. Chiedi citazioni puntuali. Il modello dovrebbe indicare documento e sezione da cui ricava ogni affermazione importante.
6. Verifica le assenze. Inserisci domande la cui risposta non compare nei documenti per controllare se il sistema ammette di non sapere.
7. Prova più posizioni. Sposta deliberatamente un’informazione importante all’inizio, al centro e alla fine del contesto.
8. Misura prima di aumentare. Registra accuratezza, latenza, memoria e costo con una configurazione di base, poi aumenta gradualmente.

Checklist operativa

Prima di scegliere o aumentare la finestra di contesto, verifica:

• quanti token usa realmente il caso d’uso;
• quanto spazio deve restare per la risposta;
• quali elementi possono essere sintetizzati o rimossi;
• se un RAG selettivo è più adatto dell’inserimento completo;
• se il modello recupera informazioni collocate in punti diversi;
• latenza e costo per richiesta;
• RAM, VRAM e percentuale di offload nell’esecuzione locale;
• effetto delle richieste parallele;
• presenza di fonti non fidate o prompt injection;
• log di versione, fonti e parametri usati nel test.

Errori comuni

Confrontare modelli solo dal numero massimo di token

Il limite dichiarato è una caratteristica di capacità, non una misura diretta di ragionamento, accuratezza o capacità di recupero.

Incollare tutto “per sicurezza”

Ogni elemento irrilevante compete per attenzione, memoria e budget. Il contesto deve essere curato come un dataset temporaneo.

Dimenticare lo spazio per l’output

Un input vicino al limite può lasciare troppo poco spazio per una risposta completa, una tabella o del codice.

Aumentare num_ctx senza controllare la memoria

Su Ollama e altri runtime locali il modello può rallentare o essere spostato parzialmente sulla CPU. Misura sempre prima e dopo.

Confondere cronologia e memoria

Una conversazione lunga non equivale a una memoria affidabile. Le informazioni persistenti devono essere salvate, selezionate e reinserite con criteri espliciti.

FAQ

Quante parole corrispondono a 1.000 token?

Non esiste una conversione universale. Dipende dal tokenizer, dalla lingua e dal tipo di contenuto. Codice, tabelle e termini tecnici possono produrre rapporti molto diversi dal testo narrativo.

La risposta occupa parte della context window?

Dipende dall’API e dal modello. Input e output possono condividere il limite complessivo oppure avere limiti coordinati distinti. Bisogna consultare la scheda della versione effettivamente utilizzata.

Se un PDF entra nella finestra, il modello lo ricorda tutto?

No. Il contenuto può essere disponibile senza essere recuperato correttamente. Per attività importanti occorrono domande di controllo, citazioni e test sulla posizione delle informazioni.

Una context window grande elimina la necessità del RAG?

Non sempre. Il RAG resta utile per aggiornare le fonti, applicare permessi, ridurre il rumore, mostrare citazioni e contenere il costo. In alcuni casi le due tecniche vengono combinate.

Quale valore devo usare con Ollama?

Parti dal minimo sufficiente per il compito e aumenta gradualmente, controllando ollama ps, latenza e qualità. Il valore massimo teorico del modello non è necessariamente la scelta migliore per l’hardware disponibile.

Conclusioni

La context window non è la memoria totale dell’intelligenza artificiale e non misura quanto un modello sia intelligente. È il budget informativo disponibile durante una singola elaborazione.

Una progettazione efficace seleziona il contesto pertinente, conserva spazio per la risposta e misura qualità, latenza, costi e memoria. Nei sistemi locali questo significa configurare la finestra in funzione di RAM e VRAM; nei sistemi RAG e negli agenti significa limitare documenti, risultati degli strumenti e cronologia alle informazioni realmente necessarie.

La domanda utile non è quindi “qual è la finestra più grande?”, ma “qual è il contesto minimo che permette di ottenere una risposta corretta e verificabile?”

Fonti

• Google AI for Developers – Long context
• Ollama – Context length
• Ollama – FAQ
• Liu et al. – Lost in the Middle: How Language Models Use Long Contexts

Vuoi ricevere altre guide operative su AI locale, modelli e RAG? Iscriviti gratuitamente alla newsletter di BASI DI AI.