Finestra di contesto agenti AI: quanti dati aziendali leggono davvero

La domanda arriva quasi sempre allo stesso punto della conversazione, di solito dopo la demo: «Ok, ma quanti documenti aziendali riesce a leggere questo agente?». È una domanda legittima e ha una risposta numerica precisa, solo che la risposta numerica precisa è quasi sempre quella sbagliata da dare, perché il numero che i fornitori pubblicano e il numero di documenti che l’agente riesce davvero a usare bene sono due grandezze diverse, e la distanza fra le due è il posto dove i progetti si arenano dopo tre mesi.

La finestra di contesto di un modello AI è la memoria di lavoro dell’agente: tutto ciò che il modello può guardare mentre scrive la sua risposta. Oggi i modelli di punta dichiarano un milione di token. Sembra tantissimo, e in un certo senso lo è. Ma i benchmark indipendenti degli ultimi due anni raccontano una storia più scomoda: la capacità dichiarata e la capacità utile non coincidono, e il divario si allarga proprio nei casi d’uso aziendali, molti documenti, molte revisioni, molti mesi di conversazioni accumulate. Chi progetta l’architettura del vostro agente lavora esattamente su questo scarto.

In questo articolo scoprirai:

• Token, non pagine: come si misura quello che l'agente riesce a leggere
• Il milione di token è reale, il contesto davvero utilizzabile è molto più corto
• Perché l'agente peggiora quando gli date più dati: attention budget e context rot
• Quanti documenti aziendali legge davvero un agente AI, in pratica
• Chunking e RAG: cosa entra nella finestra quando l'agente cerca nei vostri documenti
• Quanto costa tenere tutto in finestra: il conto in token di un mese di lavoro
• Come si progetta un agente che non degrada dopo sei mesi

Token, non pagine: come si misura quello che l’agente riesce a leggere

Prima di rispondere «quanti documenti», serve cambiare unità di misura. I modelli non contano pagine né file: contano token, cioè frammenti di parola prodotti dalla tokenizzazione, il meccanismo di base di come funzionano gli LLM. La stima ufficiale di Anthropic, nella documentazione sulle finestre di contesto di Claude, è che 1 token corrisponda a circa 4 caratteri o 0,75 parole in inglese, con variazioni sensibili a seconda della lingua, e l’italiano, con parole mediamente più lunghe, tende a consumare più token dello stesso testo in inglese.

Un milione di token, tradotto in oggetti riconoscibili, vale circa 750.000 parole. Google, nella documentazione sul contesto lungo di Gemini, propone equivalenze utili da tenere a mente in riunione: un milione di token sono «50.000 righe di codice», «otto romanzi inglesi di lunghezza media» o «le trascrizioni di oltre 200 episodi di podcast».

Cosa occupa la finestra di contesto oltre ai vostri documenti

Qui arriva la prima sorpresa per chi si aspettava un contenitore vuoto da riempire. Secondo la documentazione ufficiale di Claude sulle finestre di contesto, nella finestra rientra tutto quello che viaggia nella richiesta: il prompt di sistema, ogni messaggio della conversazione, i risultati delle chiamate agli strumenti, le immagini, i documenti, le definizioni degli strumenti stessi e persino il ragionamento che il modello produce. Anche una singola definizione di toolset per l’uso del browser costa circa 6.600 token di input prima che l’agente abbia letto una sola riga dei vostri file.

E i documenti pesano più di quanto si immagini. Sempre nella documentazione Anthropic, una pagina web media da 10 kB vale circa 2.500 token, mentre il PDF di un paper da 500 kB ne vale circa 125.000. Fate il conto: otto PDF corposi e il milione di token è finito.

Il milione di token è reale, il contesto davvero utilizzabile è molto più corto

Questa è la parte che raramente compare nelle slide commerciali. Il numero dichiarato è la capacità massima che l’API accetta senza restituire errore; non è una promessa sulla qualità della risposta a quella lunghezza.

Il lavoro di riferimento è NoLiMa, il benchmark pubblicato nel febbraio 2025 da un gruppo di Adobe Research e della LMU di Monaco. NoLiMa estende il classico test “needle in a haystack” eliminando la scorciatoia: la domanda e l’informazione da trovare non condividono parole, quindi il modello deve inferire un’associazione invece di fare pattern matching lessicale. Il risultato su 12 modelli che dichiarano almeno 128K token di contesto è netto: a 32.000 token dieci modelli su dodici scendono sotto il 50% del loro punteggio a contesto breve, e GPT-4o passa da un quasi-perfetto 99,3% a 69,7%. Gli autori introducono anche una metrica che vale la pena rubare: la effective length, cioè la lunghezza massima a cui un modello conserva almeno l’85% delle sue prestazioni base.

Context rot: la finestra di contesto non viene usata in modo uniforme

Lo studio Context Rot di Chroma (luglio 2025), condotto su 18 modelli di Anthropic, OpenAI, Google e Alibaba, arriva alla stessa conclusione da un’altra strada: i modelli non usano il proprio contesto in modo uniforme, e le prestazioni si degradano all’allungarsi dell’input anche su compiti banali. Due risultati sono particolarmente istruttivi per l’uso aziendale: basta un singolo distrattore, un documento simile ma non pertinente, per far scendere l’accuratezza sotto la baseline, e con quattro distrattori il degrado si compone. Nei test conversazionali su LongMemEval a 113.000 token, il divario fra un prompt mirato da ~300 token e il contesto completo è ampio: la stessa domanda, con più materiale attorno, riceve una risposta peggiore.

Perché l’agente peggiora quando gli date più dati: attention budget e context rot

La ragione non è un bug di implementazione, è architettura. In un transformer ogni token deve essere confrontato con ogni altro token: n token generano n² relazioni. Come spiega bene la guida di Redis sui context window, un contesto da 10.000 token richiede circa 100 milioni di confronti, uno da 100.000 token ne richiede 10 miliardi. Raddoppiare il contesto quadruplica il lavoro, e a un certo punto il collo di bottiglia diventa la banda di memoria della GPU, non l’intelligenza del modello.

Attention budget: la finestra di contesto ha rendimenti decrescenti

Anthropic ha dato al fenomeno un nome che ormai è entrato nel gergo. Nel documento Effective context engineering for AI agents (settembre 2025) definisce il context rot così: «man mano che il numero di token nella finestra di contesto aumenta, la capacità del modello di richiamare accuratamente le informazioni diminuisce». Da qui la formulazione che dovrebbe stare appesa sopra la scrivania di chi progetta agenti: «il contesto va trattato come una risorsa finita con rendimenti marginali decrescenti». Il modello ha un attention budget, e ogni token che aggiungete lo consuma.

La conseguenza pratica ribalta l’intuizione del cliente. «Diamogli tutto il gestionale così sa tutto» non è una strategia prudente: è il modo più rapido per ottenere un agente che risponde peggio di quando gli davate tre documenti scelti bene. Il principio guida che Anthropic propone al posto dell’abbondanza è chirurgico: trovare «il più piccolo insieme di token ad alto segnale che massimizza la probabilità del risultato desiderato». Vale la pena leggerlo accanto a come funziona davvero un modello di AI, perché è lì che il meccanismo dell’attenzione diventa comprensibile senza matematica.

Quanti documenti aziendali legge davvero un agente AI, in pratica

Adesso possiamo rispondere alla domanda del cliente con dei numeri, e con le condizioni al contorno.

Sul fronte della capacità dichiarata, la documentazione Anthropic indica una finestra da 1 milione di token per Claude Opus 5, Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 5 e Sonnet 4.6, con un tetto di 128.000 token di output per singola richiesta; gli altri modelli, incluso Sonnet 4.5, si fermano a 200.000. C’è anche un limite fisico spesso ignorato: una singola richiesta può includere al massimo 600 immagini o pagine PDF (100 sui modelli da 200k), e con allegati pesanti si sbatte contro il limite di dimensione della richiesta prima ancora che contro quello dei token.

Il numero onesto: da 300 a 500 pagine di documenti reali

Combinando i due vincoli, capacità nominale e degrado misurato, la risposta operativa è che un agente ben costruito lavora in modo affidabile su qualche centinaio di pagine per singola sessione, non su tutto l’archivio. L’esperimento su larga scala di Databricks sul long context RAG (oltre 2.000 esperimenti su 13 modelli) mostra che la saturazione delle prestazioni arriva intorno ai 96-128k token, e che il punto di caduta è molto specifico per modello: alcuni degradano dopo 16k, altri reggono stabili fino a 125k. Il benchmark VELC-Bench pubblicato da AIMultiple nell’agosto 2026, che testa la capacità di verificare una metrica dentro un contesto enorme, misura sul modello migliore circa il 90% di accuratezza a 850k token, ottimo risultato, ma resta un 10% di errori su un compito di sola verifica.

Ecco perché la domanda giusta non è «quanti documenti entrano» ma «quali documenti servono a questa domanda». Ed è anche il motivo per cui il lavoro sulla qualità dei dati viene prima di quello sul modello: se l’archivio è pieno di versioni duplicate e near-duplicate, avete costruito una fabbrica di distrattori. Il tema è trattato per esteso in data readiness per agenti AI, ed è la fase che in pratica decide l’esito del progetto.

Chunking e RAG: cosa entra nella finestra quando l’agente cerca nei vostri documenti

Se non si può caricare tutto, bisogna scegliere. Il meccanismo che sceglie si chiama retrieval, e il modo standard di realizzarlo è la RAG (Retrieval-Augmented Generation): i documenti vengono spezzati in blocchi (chunk), trasformati in vettori numerici e indicizzati; a ogni domanda il sistema recupera solo i blocchi più vicini semanticamente e mette in finestra quelli.

Nell’esperimento Databricks il setup era esplicito: chunk da 512 token con stride 256, embedding OpenAI, vector store FAISS. Sono parametri, non dettagli: la dimensione del chunk decide se un articolo di contratto arriva intero o tagliato a metà, e lo stride decide quanto contesto di bordo sopravvive. Un chunking sbagliato produce risposte sbagliate anche con il modello migliore del mondo, perché la clausola giusta non entra mai nella finestra.

Distrattori nella finestra di contesto: il documento vicino invece di quello giusto

C’è poi un fallimento più subdolo, tipico dei sistemi vettoriali: il retrieval restituisce il documento vicino invece di quello giusto. È lo stesso fenomeno che abbiamo raccontato parlando di similarità coseno, e si sposa malissimo con il risultato di Chroma sui distrattori: un documento simile ma non pertinente non è neutro, peggiora attivamente la risposta.

Vale la pena registrare un dissenso onesto fra le fonti, perché è reale. Google, nella documentazione su Gemini, incoraggia a fornire «tutte le informazioni rilevanti direttamente» invece di ricorrere a riassunti o a RAG con database vettoriali. Databricks arriva alla conclusione opposta e più sfumata: contesto lungo e RAG sono «sinergici», perché una finestra più ampia permette di includere più documenti recuperati e quindi alza la probabilità che quello giusto ci sia. Nella nostra esperienza il secondo punto di vista regge meglio in azienda, dove le fonti si aggiornano ogni giorno e le query sono migliaia: non si può ricaricare l’archivio a ogni domanda. Ma è una scelta di architettura, non una verità, e va misurata sui vostri dati.

Quanto costa tenere tutto in finestra: il conto in token di un mese di lavoro

Il vincolo economico è il secondo motivo per cui «mettiamo dentro tutto» non regge. Il listino ufficiale Anthropic è pubblico e permette di fare i conti a mente: Claude Opus 5 e Opus 4.8 costano 5 dollari per milione di token di input e 25 in output; Sonnet 5 costa 2 dollari in input e 10 in output; Haiku 4.5 sta a 1 e 5. Buona notizia sul contesto lungo: sui modelli 4.6 e successivi l’intera finestra da 1M è fatturata a tariffa standard, una richiesta da 900k token costa quanto una da 9k moltiplicata per cento, senza sovrapprezzi.

Il problema non è quindi il prezzo unitario, è la moltiplicazione. Una conversazione agentica rispedisce al modello l’intera cronologia a ogni turno: se avete riempito 500.000 token, quei token li pagate a ogni singolo turno successivo. Venti turni su Opus 5 con la finestra mezza piena fanno 10 milioni di token di input, cioè 50 dollari, per una conversazione sola.

Prompt caching e Batch API: come si abbassa il costo del contesto lungo

Da qui l’importanza di due leve, entrambe documentate nel listino ufficiale Anthropic. La prompt caching fattura le riletture a 0,1x il prezzo base: un cache hit costa il 10% dell’input standard, e si ripaga già dopo una singola rilettura sulla cache da 5 minuti. La Batch API sconta del 50% input e output per tutto ciò che non è interattivo. Nella stessa pagina di listino Anthropic pubblica un esempio significativo: 10.000 ticket di supporto da ~3.700 token medi processati con Haiku 4.5 costano circa 37 dollari in totale. La differenza fra 37 dollari e migliaia sta interamente nelle scelte architetturali, quale modello, quanto contesto, cosa in cache. Se state costruendo il conto per la direzione, i numeri per modello sono raccolti anche nella nostra analisi sui costi delle API di Claude.

Come si progetta un agente che non degrada dopo sei mesi

Un agente in produzione non vive una conversazione: ne vive migliaia, e accumula. È il momento in cui il context rot smette di essere una curiosità da benchmark e diventa un ticket di assistenza, «una volta funzionava meglio». Le contromisure esistono, sono documentate, e sono decisioni di architettura che vanno prese prima, non dopo.

Nel documento Effective context engineering for AI agents Anthropic ne elenca quattro. La compaction riassume automaticamente la parte più vecchia della conversazione quando ci si avvicina al limite, preservando ciò che conta, decisioni prese, problemi aperti, dettagli implementativi, e scartando il resto; è disponibile lato server sui modelli 4.6 e successivi. Il note-taking strutturato sposta lo stato fuori dalla finestra, in una memoria persistente che l’agente rilegge quando serve: quanta memoria conservare fuori dalla finestra è una decisione a parte rispetto a cosa entra in finestra, e l’abbiamo affrontata partendo dalla ricerca IBM su quanta memoria serve a un agente. Le architetture a sub-agenti affidano i compiti circoscritti ad agenti specializzati, e all’agente principale torna «solo un riassunto condensato e distillato». Il just-in-time retrieval, infine, tiene in contesto identificatori leggeri, percorsi, ID, riferimenti, e carica i dati veri solo al momento del bisogno, che è poi il modo in cui lavora un umano competente con un archivio.

A queste si aggiungono strumenti più fini: la rimozione dei vecchi risultati degli strumenti, la gestione dei blocchi di ragionamento, e la context awareness, alcuni modelli Claude ricevono dall’API un budget esplicito e un avviso sui token residui dopo ogni chiamata, così da regolarsi invece di tirare a indovinare. Chi collega l’agente ai sistemi interni conosce bene questo problema anche dal lato opposto, quello delle integrazioni: ne abbiamo scritto in MCP Server e in integrare agenti AI con ERP e CRM.

Perché queste scelte non si comprano con una licenza

Nessuna di queste decisioni è nel listino di un prodotto. Quanto grande fare i chunk, quando compattare, cosa vale la pena tenere in memoria a lungo termine e cosa no, quale modello mettere su quale passaggio: sono parametri che dipendono dai vostri documenti, dalle vostre domande ricorrenti e dal vostro budget, e vanno misurati sul campo. È la ragione per cui in MIMIR l’onboarding non è una formalità di attivazione ma la fase in cui si costruisce e si taglia su misura l’architettura del contesto, e per cui continuiamo a seguirla nel tempo, perché un archivio che cresce sposta il punto di degrado. Il prodotto è l’agente; il servizio è tenerlo utile mentre i vostri dati cambiano. Se volete capire dove passa il confine, l’abbiamo raccontato in agenti AI custom vs SaaS generalisti.

Il numero dichiarato è l’inizio della conversazione, non la fine

Se dovessimo condensare tutto in una riga: la finestra di contesto dice quanto entra, non quanto viene capito. Chi vende un agente citando solo il milione di token sta rispondendo alla domanda sbagliata, e chi lo compra su quella base scoprirà lo scarto fra i due numeri qualche mese dopo, quando l’archivio sarà cresciuto e le risposte saranno peggiorate senza che nulla sia formalmente rotto.

Per un quadro d’insieme sul funzionamento di questi sistemi, la nostra guida agli agenti AI è il punto di partenza naturale; sul fronte dei rischi vale la pena leggere anche perché il modello da solo non basta, visto che tutto ciò che entra in finestra è anche superficie d’attacco.

Se in azienda avete un archivio da mettere al lavoro e la domanda «quanti documenti riesce a leggere» è ancora senza risposta, è esattamente il tipo di problema su cui possiamo sederci insieme: parlatene con noi di MIMIR e valutiamo il vostro caso concreto, quali fonti, quante query, quale profondità serve davvero. Progettare bene il contesto all’inizio costa molto meno che rimediare a un agente che ha smesso di essere utile.

Fonti:

• Google — documentazione sul contesto lungo di Gemini
• Anthropic — documentazione ufficiale sulle finestre di contesto di Claude
• NoLiMa: Long-Context Evaluation Beyond Literal Matching (arXiv, 2025)
• Chroma — Context Rot: how increasing input tokens impacts LLM performance
• Redis — guida ai context window degli LLM
• Anthropic — Effective context engineering for AI agents
• Databricks — Long context RAG performance of LLMs
• AIMultiple — AI context window benchmark (VELC-Bench)
• Anthropic — listino ufficiale dei modelli Claude