Finestra di contesto AI: quanto testo può leggere davvero un modello

Ogni volta che un modello linguistico annuncia una nuova capacità, il numero che finisce nei titoli è sempre lo stesso: quanti token entrano nella finestra. Duecentomila. Un milione. Dieci milioni. Sono cifre che suonano come una promessa, «puoi darmi tutto, ci penso io», e che in azienda vengono lette esattamente così: carico il manuale, carico i contratti, carico tre anni di ticket, e chiedo.

Il problema è che il numero dichiarato e il numero utile non coincidono quasi mai. La finestra di contesto AI è la capienza massima del contenitore, non la garanzia che il modello userà bene tutto quello che ci metti dentro. È una distinzione tecnica che diventa in fretta una distinzione economica: sistemi progettati sul numero di marketing costano di più, rispondono più lentamente e sbagliano in modi difficili da accorgersi. Vediamo cosa dicono la documentazione ufficiale dei tre principali fornitori e i benchmark indipendenti, e cosa cambia, concretamente, quando si passa dalla demo alla produzione.

In questo articolo scoprirai:

• Cos’è la finestra di contesto di un’AI, detta senza gergo
• Finestra di contesto di Claude, Gemini e GPT: i numeri dichiarati oggi
• Finestra di contesto da 200k: perché i token dichiarati non sono quelli utili
• I benchmark sulla finestra di contesto: quanto cala davvero Claude, Gemini e GPT
• La limitazione operativa che ChatGPT e Gemini hanno in comune: il contesto non è memoria
• Perché in azienda non basta «buttare dentro tutto» la finestra di contesto: costi e latenza
• RAG, chunking e orchestrazione: come si progetta il contesto invece di riempirlo
• Architettura del contesto: perché serve un servizio, non solo un prompt

Cos’è la finestra di contesto di un’AI, detta senza gergo

La definizione più asciutta è quella di IBM: la finestra di contesto è «la quantità di testo, in token, che il modello può considerare o “ricordare” in un dato momento». Un token non è una parola: è un frammento di testo, e come stima di massima servono circa 1,5 token per ogni parola. La conversione cambia molto da lingua a lingua, uno studio citato da IBM ha misurato che la stessa frase in telugu produce oltre sette volte i token dell’inglese, pur avendo meno caratteri.

La metafora corrente è «memoria di lavoro», e regge fino a un certo punto. La documentazione di Anthropic la usa esplicitamente, precisando però che la finestra contiene tutto: il system prompt, ogni messaggio della conversazione, i risultati degli strumenti, le immagini, i documenti allegati, le definizioni dei tool e persino il ragionamento che il modello produce per rispondere. Non è uno spazio riservato ai tuoi dati: è uno spazio conteso. E anche i prefissi messi in cache continuano a occupare la finestra, il prompt caching cambia quanto paghi quei token, non il fatto che contino.

Cosa significa una finestra di contesto da 200k token, in pagine di documento

Duecentomila token corrispondono grosso modo a 130-140 mila parole: un romanzo di media lunghezza, o qualche centinaio di pagine di documentazione tecnica. Anthropic pone anche un limite parallelo non testuale: una singola richiesta può includere fino a 100 immagini o pagine PDF sui modelli da 200k token, e fino a 600 su quelli da 1 milione, come indica la documentazione sulle finestre di contesto. È un dettaglio che in azienda conta più di quanto sembri, perché chi carica scansioni e PDF tocca spesso il limite di dimensione della richiesta prima di quello dei token, lo stesso muro che si incontra con gli strumenti pensati per i documenti, come abbiamo visto parlando di NotebookLM per le aziende.

Finestra di contesto di Claude, Gemini e GPT: i numeri dichiarati oggi

Conviene prendere le cifre dalle fonti primarie, non dai comparatori. Sul lato Anthropic, la documentazione ufficiale indica una finestra da 1 milione di token per Claude Opus 4.6, 4.7, 4.8, Opus 5, Sonnet 4.6, Sonnet 5 e la famiglia Fable/Mythos 5, con 200.000 token per i modelli precedenti come Sonnet 4.5. L’output massimo in una singola richiesta è di 128.000 token, e per i modelli da 1M quella capienza è il default: niente beta header, prezzo standard.

Sul lato OpenAI, la documentazione dei modelli assegna ai flagship attuali, GPT-6 Astra e la famiglia GPT-5.6, una finestra dichiarata di 1,05 milioni di token con 128.000 token di output. Google, nella guida al long context, si limita a dire che molti modelli Gemini dispongono di finestre «da un milione di token o più», rimandando alla tabella dei modelli per i dettagli.

Cosa significa una finestra di contesto da 1 milione di token

Un milione di token sono circa 700.000 parole: l’intera base di codice di un’applicazione di medie dimensioni, oppure diverse migliaia di pagine. Sulla carta risolve il problema. Nella pratica introduce quello nuovo di cui parla il resto di questo articolo: più spazio disponibile non significa più attenzione disponibile. E il costo di riempirlo non è lineare, ma quadratico, lo vedremo tra poco.

Finestra di contesto da 200k: perché i token dichiarati non sono quelli utili

Il primo lavoro che ha misurato il fenomeno in modo sistematico è «Persi nel mezzo: come i modelli linguistici usano i contesti lunghi» di Nelson F. Liu e colleghi (Stanford, 2023, pubblicato su TACL). Il risultato è una curva a U: le prestazioni sono massime quando l’informazione rilevante sta all’inizio o alla fine del contesto, e crollano quando sta nel mezzo. Redis quantifica il divario in 10-20 e più punti percentuali. Il dettaglio che pesa: anche i modelli progettati esplicitamente per contesti lunghi mostrano la stessa debolezza centrale.

Il secondo nome da conoscere è context rot, il degrado delle risposte al crescere dell’input anche quando la finestra è lontana dall’essere piena. La ricerca di riferimento è quella di Chroma su 18 modelli, Claude, GPT, Gemini e Qwen, e smonta un’assunzione comoda: che il modello tratti il diecimillesimo token con la stessa affidabilità del centesimo. Non lo fa. Basta un singolo «distrattore», un passaggio simile ma non pertinente, per far scendere l’accuratezza rispetto al caso pulito, e con quattro distrattori il calo peggiora.

Chroma segnala anche una differenza di comportamento che in azienda vale più di un punto percentuale: i modelli Claude tendono ad astenersi quando sono incerti, mentre i modelli GPT producono più spesso risposte sicure e sbagliate. Un sistema che dice «non lo so» è gestibile; uno che inventa con sicurezza no.

I benchmark sulla finestra di contesto: quanto cala davvero Claude, Gemini e GPT

Il test più citato, il «needle in a haystack», l’ago nel pagliaio, è anche il più generoso: nasconde una frase letterale in un testo lungo e chiede di ritrovarla. Chroma lo definisce «fondamentalmente un compito di recupero semplice», che misura il matching lessicale e non il ragionamento. Google stessa, nella sua documentazione sul long context, ammette che l’accuratezza vicina al 99% vale per un singolo ago: con più informazioni da recuperare insieme le prestazioni calano sensibilmente.

Prima dei numeri, un avvertimento che quasi nessuno mette per iscritto: i benchmark indipendenti che seguono sono stati eseguiti su modelli di generazione precedente, GPT-4o, Gemini 1.5 Pro, Claude 3.5 Sonnet, Llama 3.3, Mixtral-8x7b, DBRX, GPT-4-0125, non sui flagship da 1 milione di token elencati due sezioni fa. Sui modelli attuali valutazioni indipendenti equivalenti, con la stessa metodologia e lo stesso grado di terzietà, non ne esistono ancora. Quello che si trasferisce da una generazione all’altra non è la cifra: è il meccanismo, la curva a U, il context rot, la soglia oltre la quale aggiungere contesto smette di aiutare. Le percentuali qui sotto vanno lette come l’ordine di grandezza di un fenomeno, non come la scheda tecnica di Sonnet 5 o di GPT-6 Astra.

Il benchmark NoLiMa (LMU Monaco e Adobe Research) toglie

Il benchmark NoLiMa (LMU Monaco e Adobe Research) toglie proprio la scorciatoia lessicale: domanda e informazione non condividono le parole, quindi il modello deve inferire. Su 22 modelli testati, i numeri a 32.000 token, un sesto di una finestra da 200k, sono questi: GPT-4o passa dal 98,1% all’81,6%, Llama 3.3 70B dal 94,2% al 59,5%, Gemini 1.5 Pro dall’86,4% al 55,5%, Claude 3.5 Sonnet dall’85,4% al 45,7%. A 32K token, dieci modelli su ventidue scendono sotto la metà del loro punteggio su contesto breve.

Databricks è arrivata alla stessa conclusione da un’altra direzione, con oltre 2.000 esperimenti su 13 modelli in scenari RAG, anche qui, il parco modelli è quello di una generazione fa: ogni modello ha una lunghezza oltre la quale aggiungere contesto non aiuta più. Mixtral-8x7b si ferma a 4k token, DBRX a 8k, Claude-3-sonnet a 16k, Llama-3.1-405b a 32k, GPT-4-0125 a 64k. Le soglie assolute con i modelli di oggi si sono spostate più in alto; l’esistenza della soglia, no. Interessanti anche le modalità di fallimento: i rifiuti per presunto copyright di Claude-3-sonnet salgono dal 3,7% a 16k token al 49,5% a 64k. Non sbaglia la risposta: smette di darla.

La limitazione operativa che ChatGPT e Gemini hanno in comune: il contesto non è memoria

Un limite accomuna ChatGPT, Gemini e Claude, e non dipende da quanti token entrano nella finestra: la finestra di contesto non è memoria, è uno spazio di lavoro che si azzera. Quello che il modello «sa» della tua conversazione esiste solo finché sta dentro la finestra della richiesta in corso. Chiusa quella, non resta nulla, a meno che qualcuno non abbia progettato un livello esterno che conservi lo stato.

Il secondo limite è il comportamento al riempimento. Nelle interfacce di chat il meccanismo è spesso a scorrimento: le parti più vecchie escono silenziosamente, e l’utente non riceve alcun avviso. Via API il comportamento è più esplicito: Anthropic documenta un errore 400 prompt is too long quando l’input da solo eccede la finestra, e sui modelli 4.5 e successivi la generazione si interrompe con stop_reason: "model_context_window_exceeded". In produzione questa differenza conta: un errore lo intercetti, un troncamento invisibile no.

Come visualizzare la finestra di contesto in Claude Code e via API

Negli strumenti agentici la questione è diventata operativa. Claude Code espone il consumo della finestra con un comando dedicato (/context), che mostra quanto pesano system prompt, strumenti e cronologia. Via API, ogni risposta riporta il consumo nel campo usage, suddiviso tra token normali, letti dalla cache e scritti in cache; esiste inoltre una token counting API per stimare una richiesta prima di inviarla. Su Sonnet 5, Sonnet 4.6, Sonnet 4.5 e Haiku 4.5 Anthropic ha aggiunto la context awareness: il modello riceve il proprio budget residuo e lo aggiorna dopo ogni chiamata a strumento, così gestisce compiti lunghi sapendo quanto spazio gli resta.

Perché in azienda non basta «buttare dentro tutto» la finestra di contesto

Finora abbiamo parlato di qualità. C’è anche un conto da fare. L’attenzione dei transformer ha costo quadratico: come spiega IBM, se i token in ingresso raddoppiano servono quattro volte più risorse di calcolo, perché il meccanismo calcola le relazioni tra ogni coppia di token. Questo si traduce in due voci che un CFO riconosce subito.

Quanto costa riempire la finestra di contesto

La prima è il prezzo. Redis fa i conti con le tariffe di riferimento di GPT-4.1: a 2 dollari per milione di token in input, una richiesta da 100.000 token costa 0,20 dollari, e 10.000 richieste al mese fanno 2.000 dollari di solo input, prima dell’output, che costa quattro volte tanto. Moltiplica per il numero di dipendenti che useranno lo strumento ogni giorno e hai il budget annuale.

Latenza e memoria al crescere della finestra di contesto

La seconda è la latenza. Il tempo al primo token cresce con la lunghezza dell’input, perché l’intero contesto va elaborato prima che la generazione cominci. Google lo conferma nella sua documentazione; Redis riporta un test in cui una pipeline RAG rispondeva in circa un secondo mentre la configurazione a contesto lungo impiegava dai 30 ai 60 secondi sullo stesso carico. Per un assistente interno usato in tempo reale, quella differenza non è un dettaglio tecnico: è la differenza tra uno strumento adottato e uno abbandonato dopo due settimane, ed è il tipo di attrito che poi si presenta come resistenza dei dipendenti all’adozione, quando la causa vera è architetturale.

C’è infine un limite meno visibile: la memoria. Al crescere del contesto, la KV cache e le attivazioni possono superare il peso del modello stesso, e il sistema può fallire dentro i limiti dichiarati perché a saturarsi è la banda di memoria, non la capacità di calcolo.

RAG, chunking e orchestrazione: come si progetta il contesto invece di riempirlo

La conclusione operativa di tutto questo non è «il contesto lungo non serve». È che curare cosa entra nella finestra conta quanto quanto spazio hai a disposizione, formulazione che, non a caso, sta nella documentazione ufficiale di Anthropic, non in un blog critico. Anthropic chiama questa disciplina context engineering e la distingue dal prompt engineering: il prompt è un compito discreto, il contesto è un ciclo che va raffinato di continuo, perché un agente in loop genera dati a ritmo costante. Il concetto chiave è l’attention budget: un modello ha una quantità finita di attenzione, e ogni token superfluo la consuma.

Le tecniche consolidate sono quattro. La compaction riassume automaticamente le parti più vecchie della conversazione per farla proseguire oltre il limite, Anthropic la offre lato server in beta dai modelli 4.6 in avanti, affiancata dal context editing per ripulire i risultati degli strumenti. Il note-taking strutturato fa scrivere all’agente appunti persistenti fuori dal contesto. Le architetture a sub-agent assegnano i compiti specifici ad agenti con finestre pulite, che restituiscono riassunti condensati nell’ordine di 1.000-2.000 token. Il just-in-time retrieval tiene in contesto solo identificatori leggeri, percorsi, query, e carica i dati a runtime, come un essere umano che non impara a memoria l’archivio ma sa dov’è il faldone.

RAG o contesto lungo: come si sceglie cosa entra nella finestra

Il dibattito «RAG contro contesto lungo» è mal posto. Redis lo sintetizza bene: su 12 dataset di question answering le due strade danno la stessa identica risposta in circa il 60% dei casi, e divergono sul resto, il contesto lungo vince quando serve ragionare sull’intero documento, il RAG vince quando servono precisione fattuale, tracciabilità della fonte e controllo dei costi. Il RAG regge meglio anche i dati che cambiano spesso, perché aggiorni l’indice invece di ricaricare tutto.

Il pattern che si sta affermando è ibrido: si recuperano i pezzi pertinenti con la ricerca vettoriale, e si carica il documento completo nella finestra ampia solo quando l’analisi lo richiede davvero. Il chunking, come tagli i documenti prima di indicizzarli, smette di essere un dettaglio implementativo e diventa la variabile che decide cosa il modello vedrà: è il punto in cui un archivio sparso tra Drive, mail e chat diventa o non diventa una memoria aziendale davvero interrogabile.

Architettura del contesto: perché serve un servizio, non solo un prompt

Rileggi l’elenco delle decisioni che abbiamo attraversato: quale modello e quale finestra, dove tagliare i documenti, cosa indicizzare e cosa caricare interamente, quando comprimere la cronologia, dove tenere lo stato tra una sessione e l’altra, come misurare che la qualità non degradi quando il contesto cresce. Nessuna di queste è una scelta che si fa scrivendo un prompt migliore: sono scelte di architettura, e vanno riviste ogni volta che un fornitore cambia i numeri, cosa che, come si è visto, succede ogni pochi mesi.

Quando l’assistente degrada: finestra di contesto non progettata

È qui che la differenza tra comprare un prodotto e avere un partner smette di essere una formula commerciale. Un assistente AI aziendale che funziona il primo giorno e degrada al terzo mese quasi sempre non ha un problema di modello: ha un problema di contesto non progettato, troppa roba dentro, nessuna strategia di compressione, nessuna misura del degrado, che è esattamente ciò che si dovrebbe verificare testando l’agente prima del go-live. Mimir nasce come agente AI per le aziende proprio su questo presupposto: l’architettura del recupero, del chunking e dell’orchestrazione è parte del servizio, non un compito lasciato all’utente finale.

Ed è il motivo per cui l’onboarding è accompagnato invece che documentato: le scelte descritte in questo articolo dipendono dai tuoi documenti, dai tuoi volumi e dai tuoi tempi di risposta accettabili, e non esiste una configurazione predefinita che vada bene per tutti, vale la pena sapere in anticipo cosa preparare prima di far entrare un partner AI in azienda.

Se stai valutando come portare l’AI dentro i processi della tua azienda e preferisci essere accompagnato nell’adozione invece di scoprire i limiti in produzione, puoi parlarne con il team di Tinke in una consulenza dedicata. Si parte da cosa devi far leggere davvero al modello, che è sempre meno di quello che verrebbe da caricare, e quasi mai quello che ci si aspetta.

Fonti:

• Anthropic, Context windows (documentazione ufficiale)
• Anthropic Engineering, Effective context engineering for AI agents
• OpenAI, Models (documentazione ufficiale)
• Google, Long context (Gemini API docs)
• Liu et al., «Persi nel mezzo: come i modelli linguistici usano i contesti lunghi» (TACL, 2023)
• Chroma Research, Context Rot: How Increasing Input Tokens Impacts LLM Performance
• Adobe Research / LMU, NoLiMa: Long-Context Evaluation Beyond Literal Matching
• Databricks, Long Context RAG Performance of LLMs
• Redis, RAG vs large context window: the real trade-offs for AI apps
• IBM, What is a context window?