Il ciclo si ripete ogni pochi mesi con una puntualità sospetta. Un laboratorio annuncia una finestra di contesto più grande, l’annuncio diventa uno screenshot, e alla riunione successiva qualcuno dice la frase: « allora il RAG non ci serve più, mettiamo i documenti interi nel prompt e via ». Suona come una semplificazione, ed è esattamente ciò che tutti vogliono sentire su un’architettura che è costata mesi. È anche il tipo di semplificazione che si paga tre volte: in precisione, in fattura e nella notte in cui qualcosa risponde male e nessuno sa perché.
La tesi in una riga: « finestra di contesto grande o RAG » non è un’alternativa, perché le due cose non risolvono lo stesso problema. La finestra di contesto è una misura di capacità — quanto ci sta in una chiamata. Il retrieval è una decisione di selezione — cosa entra, fra tutto quello che hai. Aumentare la prima non risponde alla seconda. E quando rinunci a decidere cosa entra, quello che succede è misurato: la precisione crolla molto prima del limite annunciato, il costo per chiamata sale con il tariffario in mano, e il guasto smette di essere debuggabile perché non sai più quale frammento ha usato il modello.
Non si tratta di difendere un’architettura per affetto. Ci sono casi — stanno in fondo, con nome e cognome — in cui la finestra grande è effettivamente la risposta giusta e montare retrieval sarebbe sovradimensionare. Si tratta di decidere per i motivi veri e non per il titolo di un lancio.
Finestra di contesto grande o RAG: non è la stessa domanda fatta due volte
La confusione ha una radice precisa: entrambe finiscono nello stesso posto — testo davanti al modello nel momento in cui risponde — e quindi sembrano interscambiabili. Non lo sono. La finestra di contesto è lo spazio di lavoro di questa chiamata: si riempie, si usa, si svuota. Il retrieval è il meccanismo che scegli, da un corpus che non ci sta e non ci starà mai, i frammenti che meritano di occupare quello spazio. Una è la dimensione del tavolo; l’altro decide quali fogli ci metti sopra.
La tassonomia completa — contesto della conversazione, conoscenza consultabile e memoria a lungo termine, dove vive ogni livello e quanto costa — è già scritta nella guida sulla memoria di un agente IA, e riargomentarla qui non avrebbe senso. Quello che quella guida non copre, perché non è la sua domanda, è questa: cosa succede esattamente quando il mercato ti offre più tavolo e tu decidi che così risparmi chi scegli i fogli.
La prima cosa che si rompe non è il limite: è la precisione
La parte controintuitiva è che il problema compare molto prima di riempire la finestra. Un modello con un milione di token annunciati non mantiene la sua qualità fino al token 999.999 per poi cadere da un dirupo: si degrada in modo progressivo, e abbastanza presto. Il benchmark NoLiMa l’ha misurato con un disegno che evita la scorciatoia dei vecchi test « ago nel pagliaio » — in NoLiMa la domanda e il frammento rilevante non condividono quasi nessuna parola, quindi il modello non può trovarlo per corrispondenza letterale e deve inferire l’associazione, che è esattamente ciò che gli chiedi in produzione.
I risultati: GPT-4o partiva da 99,3% con contesto corto e scendeva al 69,7% a 32K token e al 56% a 128K. E non era un caso isolato: a 32K, 11 dei 13 modelli valutati scendevano alla metà o meno della propria baseline a contesto corto. Fonte: NoLiMa: Long-Context Evaluation Beyond Literal Matching, Modarressi et al., arXiv, febbraio 2025.
A questo si somma un effetto di posizione documentato prima e in modo indipendente: la precisione dipende da dove si trova l’informazione dentro il contesto. Il lavoro che ha coniato il termine descrive una curva a U — il modello recupera discretamente bene quello che sta all’inizio e alla fine, e fallisce su quello che resta in mezzo. Fonte: Lost in the Middle: How Language Models Use Long Contexts, Liu et al., Transactions of the ACL, 2024.
Insieme, i due effetti descrivono il vero modo di guasto della strategia « mettiamoci tutto ». Non è che il modello si rifiuti di rispondere: risponde con sicurezza usando quello che ha trovato, che non è necessariamente quello che contava. La risposta arriva ben scritta, ben strutturata e male fondata. È il peggior tipo di errore per un sistema aziendale, perché non si distingue da una risposta giusta senza andarla a verificare a mano.
| Cosa dice l’annuncio | Cosa misura il benchmark | Cosa implica per il tuo sistema |
|---|---|---|
| « Finestra da 1M di token » | Il degrado inizia molto sotto quel numero | Il limite annunciato è capacità di input, non garanzia di qualità |
| « Ci sta tutta la tua documentazione » | A 32K, 11 modelli su 13 scendono a ≤50% della base (NoLiMa, 2025) | Starci non è la stessa cosa che essere usato |
| « Il modello trova quello che serve » | Quello che sta in mezzo al contesto si recupera peggio (Liu et al., 2024) | L’ordine in cui impili i documenti diventa una variabile nascosta |
| « Ti risparmi il retrieval » | I benchmark non misurano né la fattura né la tracciabilità | L’ingegneria risparmiata diventa costo ricorrente e opacità |
Il fornitore che ti vende il milione di token te lo fattura al doppio
Qui non serve argomentare: basta leggere il tariffario di chi vende la finestra grande. Nel listino pubblico dell’API Gemini, due modelli hanno il prezzo diviso per lunghezza del prompt, con il taglio esattamente a 200.000 token. Su Gemini 3.1 Pro Preview, tariffa standard, l’input passa da 2,00 a 4,00 dollari per milione di token superata quella soglia, e l’output da 12,00 a 18,00. Su Gemini 2.5 Pro, da 1,25 a 2,50 in input e da 10,00 a 15,00 in output. Anche la cache di contesto raddoppia. Fonte: Gemini Developer API pricing, Google, consultato il 4 ottobre 2026.
Quello che conta non è l’importo, che cambierà. È la forma del tariffario: il fornitore che ti offre la finestra enorme ha deciso di farti pagare il doppio per usarla davvero. È una dichiarazione sul costo reale di servire quei prompt, scritta da chi lo paga. Quando qualcuno ti presenta « finestra di contesto grande o RAG » come se la prima opzione fosse quella gratis, sta ignorando che il produttore stesso l’ha tariffata come un prodotto diverso e più caro.
Ed è l’effetto composto che manda in tilt i budget. Il retrieval concentra la spesa sul costruire e mantenere un indice: un costo che esiste una volta e si ammortizza su tutte le query. Mettere tutto nel prompt sposta quella spesa sul lato variabile, dove si moltiplica per ogni chiamata, ogni giorno, per sempre. Un pilota con duecento query al mese non lo nota. Lo stesso sistema aperto a trecento persone, sì. L’aritmetica è noiosa, ed è per questo che nessuno la fa prima della riunione: moltiplica i tuoi token di input per il volume atteso e confrontalo con quanto costa un indice. La guida su quale modello usare in un agente copre gli altri assi di quella decisione, perché la dimensione della finestra è una specifica fra tante e quasi mai quella che decide.
Il guasto che non puoi debuggare
È l’argomento che non compare in nessun benchmark e che costa più caro in esercizio. Con il retrieval, quando una risposta esce male hai una traccia: sai quali frammenti sono stati recuperati, con quale query, con quale punteggio. La diagnosi si riduce a due domande con risposta — il frammento giusto era nell’indice? il retrieval l’ha tirato su? — e ognuna punta a una correzione diversa: reingerire la fonte, o tarare il retrieval.
Senza retrieval non c’è traccia, perché non c’è stata selezione da registrare. Hai passato duecentomila token e il modello ha usato quello che ha usato. Non puoi sapere su cosa si è appoggiato, non puoi riprodurre il percorso e non puoi sistemarlo con un intervento circoscritto: la tua unica leva è riordinare i documenti e riprovare, cioè debuggare per superstizione. In un sistema interno con tolleranza alta è un fastidio. In un sistema che risponde a clienti o alimenta una decisione, è la differenza fra un incidente che si chiude e uno che resta aperto.
Quando la finestra grande è davvero la risposta giusta
Montare retrieval su un corpus che non ne ha bisogno è l’altro modo di sbagliare, ed è più comune di quanto sembri. Tre situazioni in cui la finestra grande vince pulito:
- Il corpus è piccolo e stabile. Se tutto quello che il sistema deve consultare ci sta comodamente sotto la soglia in cui il modello si degrada, e non cambia ogni settimana, un indice è infrastruttura da mantenere per non guadagnare niente.
- L’evidenza è distribuita su tutto il documento. Quando il compito è sintetizzare, confrontare sezioni o individuare contraddizioni lungo un testo lungo, il retrieval lavora contro di te: spezzettare è precisamente ciò che distrugge la relazione fra le parti. Qui il contesto lungo non è un lusso, è il requisito.
- È un’analisi puntuale, non un sistema. Un contratto, un report, un export di dati analizzato una volta. Nessuno dovrebbe montare una pipeline di ingestione per una domanda che si fa una volta sola.
La lettura onesta della letteratura recente è che l’impostazione binaria è superata da entrambi i lati: il contesto lungo rende meglio quando l’evidenza è distribuita, e il retrieval rende meglio quando l’evidenza è scarsa e va trovata. L’architettura che sta vincendo non scegli: recupera per restringere l’universo al plausibile, e poi usa la finestra lunga per ragionare su quell’insieme già ridotto. Il retrieval smette di essere un filtro di precisione chirurgica e diventa un riduttore di rumore, il che allenta parecchio i requisiti sul tuo indice.
Il test di due minuti prima di buttare niente
Se qualcuno in squadra propone di togliere il retrieval perché è uscito un modello con più contesto, queste quattro domande chiudono la conversazione senza riunione di follow-up:
- Quanti token ha il corpus completo, oggi e fra dodici mesi? Se la risposta a dodici mesi supera la soglia in cui il modello si degrada — e sta molto sotto il limite annunciato —, la finestra non è una soluzione, è una proroga.
- Quanto costerebbe il volume reale di query a tariffa prompt lungo? Con il prezzo diviso a 200K token, il calcolo sta su un foglio. Fallo con il volume a cui aspiri, non con quello del pilota.
- L’evidenza tipica sta in un punto o distribuita? Puntuale e localizzata: retrieval. Distribuita su tutto il documento: contesto lungo. Entrambe secondo la domanda: ibrido, ed è la risposta più frequente.
- Cosa rispondi quando un cliente chiede da dove è uscita quella frase? Se la risposta deve essere verificabile, ti serve la traccia di cosa è entrato. Quella la dà solo la selezione.
Nessuna delle quattro si risolve con la dimensione della finestra, ed era esattamente quello che si voleva dimostrare.
Cosa cambia in esercizio
C’è una ragione meno tecnica per cui la proposta di buttare il RAG funziona così bene, e conviene nominarla: non è che la finestra grande sia migliore, è che mantenere un indice è un lavoro continuo e a nessuno va di farlo. La conoscenza invecchia, le fonti cambiano, i documenti vengono sostituiti, e se nessuno reingerisce né invalida lo scaduto, il sistema comincia a rispondere con la versione dell’anno scorso. È la vera crepa che sfrutta l’argomento del contesto infinito: promette di liberarti di una funzione operativa, non di un software.
Il problema è che la funzione non scompare, diventa solo invisibile. Se metti i documenti interi nel prompt, ti serve ancora che quei documenti siano quelli vigenti — solo che adesso non hai né indice né pipeline dove verificarlo. Per questo la freschezza della base di conoscenza è una funzione continua che si opera, non un progetto che si chiude: il refresh per fonte, l’invalidazione dello scaduto e il responsabile di ogni decisione editoriale esistono comunque, con RAG o senza.
E se la discussione che hai aperto davvero non è questa ma l’altra — se riaddestrare il modello sui tuoi dati —, è risolta altrove e con la stessa logica: il retrieval batte il fine-tuning quasi sempre, per costo e per capacità di aggiornare senza riaddestrare. Le tre conversazioni — finestra, retrieval e addestramento — si mescolano nelle stesse riunioni, e conviene tenerle separate, perché solo una di esse cambia quando esce un modello nuovo.
La conclusione operativa è corta. Più contesto è una buona notizia: ti lascia passare più evidenza rilevante per chiamata e allenta la precisione che pretendi dal tuo retrieval. Quello che non fa è decidere cosa è rilevante. Quel lavoro lo fa ancora qualcuno — un indice, una query, una policy — o non lo fa nessuno, e allora quello che hai non è un’architettura più semplice: è la stessa complessità, senza registro e a tariffa doppia.