RAG vs Long Context: Con 1M di Token Serve Ancora il Retrieval?

"RAG is dead." Lo leggi su X almeno tre volte al giorno. Ogni volta che un provider annuncia una finestra di contesto più grande, parte il coro. Un milione di token. Dieci milioni. Perché mai dovresti spezzettare i tuoi documenti in chunk, embeddare, indicizzare e cercare — tutto quel lavoro che abbiamo spiegato qualche giorno fa — quando puoi buttare tutto dentro al prompt e lasciare che il modello se la cavi da solo?

È una domanda legittima. Il problema è che i dati raccontano una storia diversa.

I deployment enterprise di vector database — l'infrastruttura su cui gira il RAG — sono cresciuti del 377% nel 2025 secondo Databricks. Il RAG è la seconda tecnica più adottata dopo il prompt design nelle aziende che usano GenAI. Mentre su Twitter si celebra il funerale, le aziende investono nella direzione opposta.

Qualcuno ha ragione e qualcuno ha torto. Oppure, come capita spesso, la realtà è più sfumata di un tweet.

Cosa Significa Davvero 1M di Token

Prima di tutto, mettiamo a terra i numeri. Un milione di token non è un'astrazione — è una quantità concreta di informazione.

1M di token equivale a circa 750.000 parole, 1.500 pagine, 50.000 righe di codice, oppure 8 romanzi di lunghezza media. Con Gemini 2.5 Pro puoi processare un'ora di video o 19 ore di audio in una singola chiamata. Llama 4 Scout, con i suoi 10M di token, sposta il limite a 15.000 pagine.

È tanto. Ma "tanto" non vuol dire "tutto". La knowledge base media di un'azienda enterprise è ordini di grandezza più grande. E anche quando il corpus ci sta, il costo di riempire quella finestra non è trascurabile.

Modello	Context Window	Costo per riempire 1M token
Gemini 2.5 Pro	1M	$1.25 (sotto 200K), $2.50 (sopra)
Claude Sonnet 4.6	1M	$3.00
GPT-5.4	1.05M	$2.50 (sotto 272K), $5.00 (sopra)
Claude Opus 4.6	1M	$5.00

Queste sono cifre per singola query, solo input. A 10.000 query al giorno con 500K token di contesto, Gemini 2.5 Pro ti costa circa 12.500 dollari al giorno. Claude Opus 4.6 il doppio. Parliamo di 4.5-9 milioni di dollari l'anno solo per il costo dei token in ingresso.

Il prompt caching cambia parzialmente le carte in tavola: Anthropic offre il 90% di sconto sui token cachati, Google il 90% su Gemini 2.5 (75% su 2.0), OpenAI dal 50% al 90% a seconda del modello (90% sulla famiglia GPT-5). Per use case dove il contesto base è sempre lo stesso — una documentazione tecnica, un corpus legale — il caching rende il long context molto più accessibile. Ma non tutti gli use case hanno contesto ripetibile.

Il Benchmark che Mette i Numeri in Fila

Il team di Elasticsearch Labs ha fatto un confronto diretto tra RAG e full context usando Gemini 2.0 Flash su un dataset reale di articoli tecnici. I risultati sono brutali.

Metrica	RAG	Full Context	Differenza
Token per query	237	1.023.231	4.317x
Tempo di risposta	1.28s	45.65s	35x
Costo per query	$0.000029	$0.102330	3.528x

RAG costa 1.250 volte meno in media e risponde 35 volte più veloce. Ma il dato più importante non è nei numeri di performance — è nell'accuratezza. RAG ha prodotto risposte corrette in tutte le iterazioni. Il full context ha generato inaccuratezze.

Rileggilo: buttare tutto nel contesto non solo costa di più e risponde più lento, ma in questo test ha anche risposto peggio.

Un benchmark non è un verdetto universale. È un singolo test su un singolo dataset con un singolo modello. Ma quando la differenza di costo è di tre ordini di grandezza e l'accuratezza non migliora, almeno merita una riflessione.

Dove il Long Context Vince Davvero

Liquidare il long context sarebbe altrettanto sbagliato. Ci sono scenari dove il retrieval è un ostacolo, non un vantaggio.

Comprensione globale del documento. Se devi fare un riassunto di un contratto di 200 pagine, non vuoi che un sistema RAG scelga 5 chunk per te. Vuoi che il modello legga tutto. La summarization richiede visione d'insieme, e il long context la fornisce nativamente.

Reasoning cross-document. Quando la risposta emerge dalla relazione tra informazioni distribuite — non da un singolo paragrafo — il long context permette al modello di ragionare sull'intero corpus. Il paper "Long Context vs. RAG" di gennaio 2025 conferma che il long context supera generalmente il RAG nei task di question-answering su Wikipedia, specialmente quando serve collegare fatti distanti.

Many-shot in-context learning. Il paper presentato a NeurIPS 2024 dimostra che passare centinaia o migliaia di esempi nel contesto — non pochi, non decine, ma centinaia — migliora significativamente le performance su task generativi e discriminativi. In alcuni casi, many-shot ICL supera i bias del pretraining e rende superfluo il fine-tuning. Senza una finestra di contesto grande, questo approccio non esiste.

Corpus statici e piccoli. Se il tuo dataset è sotto 1M di token, non cambia mai, e fai poche query al giorno, il RAG è overengineering. Buttare tutto nel prompt è la soluzione più semplice. E spesso la soluzione più semplice è quella giusta.

Il Fantasma nel Mezzo: Lost in the Middle

C'e' un problema di cui si parla meno ma che condiziona tutto: i modelli non trattano tutte le posizioni del contesto allo stesso modo.

Il paper "Lost in the Middle" (Liu et al., 2023, pubblicato su TACL 2024) ha dimostrato che gli LLM ottengono risultati significativamente meglio quando l'informazione rilevante si trova all'inizio o alla fine del contesto, con un calo marcato nel mezzo. E non parliamo di una sfumatura — parliamo di una degradazione del 30-60% della performance originale per informazioni posizionate nella zona centrale.

Google afferma di aver risolto il problema con la famiglia Gemini, che raggiunge il 99.7% di recall nel needle-in-haystack test a 1M di token (dato documentato per Gemini 1.5 Pro). Ma c'è un'avvertenza importante: il needle-in-haystack test misura se il modello trova UN fatto specifico nascosto in un pagliaio di testo. Trovare un ago è molto diverso dal ragionare su pattern distribuiti in 1.500 pagine.

I benchmark sintetici mascherano un problema reale. Quando servono analisi che richiedono di collegare informazioni distribuite nel mezzo di documenti lunghi, le performance calano. I benchmark indipendenti lo confermano con risultati misti, anche sui modelli più recenti.

RAG, per design, evita completamente il problema. Il retrieval seleziona i chunk rilevanti e li posiziona in un contesto compatto dove il modello li vede tutti senza zone morte.

Dove il RAG Vince Ancora

Anche nel 2026, con finestre di contesto da 1M di token disponibili ovunque, il RAG mantiene vantaggi strutturali che il long context non può replicare.

Dati che cambiano. Se la tua knowledge base si aggiorna ogni giorno — nuovi ticket, nuovi documenti, nuove policy — il long context richiede di re-ingestionare tutto ad ogni query. RAG aggiorna l'indice incrementalmente. La differenza è tra rileggere l'intera enciclopedia e consultare il capitolo giusto.

Source attribution. Quando un utente chiede "da dove viene questa informazione?", RAG può puntare al documento e al paragrafo esatto. Il long context ti da una risposta, ma risalire alla fonte specifica nel milione di token in input è un esercizio di fiducia, non di tracciabilità.

Scalabilità prevedibile. RAG ha performance costanti indipendentemente dalla dimensione del corpus: 10.000 documenti o 10 milioni, il tempo di retrieval resta nell'ordine dei millisecondi. Il long context scala linearmente con la dimensione dell'input — più token, più lento, più costoso.

Latenza real-time. 1.28 secondi contro 45 secondi. Per un chatbot di customer service, per un tool di ricerca interna, per qualsiasi UX che richiede risposte rapide, 45 secondi di attesa non sono accettabili.

Il benchmark LaRA presentato a ICML 2025 dal team NLP di Alibaba ha testato 2.326 casi su 11 LLM diversi e ha concluso con una frase che vale più di qualsiasi hot take: "Neither RAG nor long-context LLMs are a silver bullet." La scelta ottimale dipende dal modello, dal tipo di task, dalla lunghezza del contesto e dalle caratteristiche dei chunk recuperati.

RAG nel 2026: Non è Morto, si è Evoluto

Il RAG che la gente dichiara morto è il RAG del 2023 — retrieve-then-generate con chunk a lunghezza fissa e un singolo step di retrieval. Quello sì, è effettivamente superato per corpus statici sotto 1M di token.

Ma il RAG nel 2026 è un'altra cosa.

Agentic RAG. L'LLM non esegue più una pipeline fissa. Decide se fare retrieval, formula la query ottimale, sceglie la strategia di ricerca (lessicale, semantica, multimodale), valuta i risultati e reitera se non sono abbastanza buoni. Il retrieval diventa un tool che l'agente usa quando serve, non un passaggio obbligato.

GraphRAG. Combinare vector search con knowledge graph strutturati. LinkedIn lo ha implementato nel customer service con risultati notevoli: +77.6% di MRR (Mean Reciprocal Rank) e -28.6% di tempo di risoluzione. Non è applicabile ovunque — funziona meglio con dati fondamentalmente strutturati e relazionali — ma dove si applica, i margini di miglioramento sono enormi.

Hybrid search come standard. La combinazione di ricerca semantica e lessicale (BM25), seguita da cross-encoder reranking, è diventata il default nel 2026. Rispetto alla sola ricerca semantica o alla sola keyword search, l'ibrido migliora sensibilmente l'accuratezza rispetto a ciascun approccio usato da solo.

Il RAG non sta morendo. Si sta trasformando da pipeline rigida a componente intelligente di sistemi più complessi.

L'Approccio Ibrido: Il Vero Vincitore

Se c'è un pattern che emerge chiaramente dai dati, è questo: le implementazioni più efficaci nel 2026 non scelgono tra RAG e long context. Usano entrambi.

Il pattern si chiama Smart Layering e funziona così:

RAG per il pre-filtraggio. Vector search + metadata filtering + hybrid search per identificare i documenti rilevanti da un corpus potenzialmente enorme.
Long context per il reasoning. I documenti recuperati — già filtrati e reranked — vengono iniettati nella finestra di contesto del modello per l'analisi approfondita.

Invece di scegliere tra "cerco 5 chunk" e "butto dentro 1M di token", combini il meglio di entrambi: la precisione chirurgica del retrieval con la capacità di reasoning del long context.

Il pattern si osserva chiaramente nei use case di regulatory compliance: il long context eccelle sulle query semplici che richiedono visione d'insieme, ma il RAG è nettamente superiore sulle query che richiedono sintesi tra documenti di periodi diversi. L'approccio ibrido cattura entrambi i vantaggi.

Context Engineering: La Skill che Conta

Andrej Karpathy lo ha sintetizzato in un tweet che vale più di molti paper: "Context engineering is the delicate art and science of filling the context window with just the right information for the next step."

Il concetto è potente — ne abbiamo parlato a fondo nell'articolo sul context engineering e nella guida pratica. L'LLM è una CPU. La finestra di contesto è la RAM. Come un sistema operativo decide con cura cosa caricare in RAM, un buon sistema AI decide con cura cosa inserire nel contesto. RAG è uno dei meccanismi per farlo, ma non l'unico.

Il context engineering include: task descriptions, few-shot examples, documenti recuperati via RAG, tool definitions, stato della conversazione, compacting e summarization. Il retrieval è un componente — spesso il più importante — ma il valore sta nell'orchestrazione complessiva.

Il futuro non è RAG vs long context — è costruire sistemi intelligenti che usano entrambi strategicamente.

Questo sposta la conversazione dal "quale approccio è meglio" al "come costruisco il sistema che usa l'approccio giusto al momento giusto". È una domanda da ingegnere, non da evangelista.

Decision Framework: Quando Usare Cosa

Se devi prendere una decisione tecnica oggi, ecco un framework pragmatico.

Usa il long context puro quando:

Il corpus è statico e sta sotto 1M di token
Serve comprensione globale (summarization, analisi completa)
La latenza non è critica (30-60 secondi accettabili)
Le query sono poche (non 10.000 al giorno)
Il prompt caching è applicabile (stesso contesto riutilizzato)

Usa RAG quando:

Il corpus è dinamico o si aggiorna frequentemente
Il corpus è grande (molto oltre 1M di token)
Serve latenza sotto i 2 secondi
Il costo per query è critico
Serve source attribution e tracciabilità
Molte query concorrenti (scalabilità)

Usa l'approccio ibrido quando:

Serve sia retrieval preciso sia analisi approfondita
Hai un mix di query semplici e complesse
Stai costruendo sistemi agentici con tool use
Vuoi ottimizzare il budget: RAG per le query cost-sensitive, long context per le analisi full-corpus

La domanda giusta non è "RAG o long context?". È "per questo specifico task, con questo corpus, a questa scala, con questo budget, cosa mi serve nel contesto?".

Il Paradosso dell'Adozione

C'e' qualcosa di ironico in tutto questo dibattito.

Il discorso "RAG is dead" vive quasi esclusivamente su Twitter/X, alimentato dall'annuncio di ogni nuovo modello con context window più grande. Nel frattempo, le aziende che costruiscono sistemi AI in produzione vanno nella direzione opposta: investono in infrastruttura RAG più sofisticata, hybrid search, GraphRAG, agentic retrieval.

Non è che le aziende non conoscano il long context. È che hanno fatto i conti. A 10.000 query al giorno, il costo del long context non scala. La latenza di 45 secondi non è accettabile per le loro UX. E l'assenza di source attribution è un problema di compliance, non una preferenza tecnica.

Se il 2024 è stato l'anno dell'hype RAG e il 2025 l'anno della disillusione, il 2026 è l'anno della maturità architetturale. Il RAG base del 2023 è morto. Il retrieval come disciplina ingegneristica è più vivo che mai. E il long context non è il nemico — è il complemento naturale.

Chi costruisce sistemi AI nel 2026 non sceglie una fazione. Costruisce pipeline che sanno quando cercare, quando caricare tutto, e quando fare entrambe le cose.

Fonti: