RAG vs modelli a contesto lungo: quando conviene l'uno e quando l'altro

Quando deve scegliere tra incollare interi documenti nel prompt di un modello a contesto lungo e usare una pipeline RAG che recupera solo i passaggi rilevanti, la risposta dipende da tre fattori: quanti documenti ha, quanto spesso cambiano e quante domande farà. Per un contratto da leggere una volta sola, il contesto lungo vince per semplicità. Per una base documentale che cresce, interrogata migliaia di volte al mese, e che deve restare tracciabile con fonti citate, la RAG resta più economica, più veloce e più precisa.

Cos'è un context window lungo e perché sembra la scorciatoia perfetta

Il context window è la quantità di testo (misurata in token) che un modello può ricevere in un'unica richiesta, prompt più documenti allegati più la risposta che genererà. Negli ultimi anni questa finestra si è allargata molto: da qualche migliaio di token a decine o centinaia di migliaia, e in alcuni casi oltre il milione. Questo ha reso possibile una scorciatoia allettante: invece di costruire un indice di ricerca, si incollano direttamente i documenti nel prompt e si lascia che il modello li legga tutti ad ogni domanda. Niente chunking, niente database vettoriale, niente pipeline da mantenere. Se non ha ancora chiaro come funziona l'alternativa, può leggere prima come funziona il RAG, passo dopo passo: aiuta a capire da cosa si sta effettivamente semplificando.

Il problema è che questa semplicità ha un prezzo, e non è solo economico. Un contesto enorme deve essere ritrasmesso (o comunque processato) a ogni interazione, la precisione del modello non cresce linearmente con la quantità di testo fornito, e non esiste un meccanismo nativo per citare con precisione da quale pagina o paragrafo arriva un'affermazione, a meno di chiederlo esplicitamente e sperare che il modello sia coerente.

Quando lo stuffing nel contesto funziona davvero

Non è sempre un errore incollare tutto nel prompt. Ci sono situazioni in cui è la scelta più rapida e anche la più sensata:

• Un documento singolo o pochi file, letti una sola volta: un contratto da far analizzare, un bilancio, una relazione tecnica che non verrà più interrogata dopo quella sessione.
• Un prototipo o uno script usa e getta, dove costruire un indice richiederebbe più tempo di quanto ne faccia risparmiare.
• Contenuto generato al volo e diverso ad ogni richiesta: non ha senso indicizzare qualcosa che verrà usato una volta sola e poi scartato.
• Compiti che richiedono di ragionare sull'intero documento in un colpo solo, come un riassunto globale o il confronto tra due versioni di uno stesso testo.
• Un volume di domande molto basso, poche al giorno, dove il costo per singola interrogazione resta accettabile anche se ogni volta si rispedisce tutto il materiale.

Quando la RAG è più economica, veloce e precisa

La situazione cambia non appena la base documentale cresce o viene interrogata ripetutamente. In questi casi la RAG (recuperare solo i passaggi rilevanti prima di generare la risposta) diventa quasi sempre la scelta più razionale:

• La base documentale, nel suo insieme, supera comunque la finestra di contesto disponibile: centinaia o migliaia di pagine non ci stanno in nessun prompt, per quanto grande sia il modello.
• Tanti utenti pongono domande diverse sugli stessi documenti: l'indicizzazione si paga una sola volta, poi si interroga migliaia di volte a costo marginale basso.
• Serve citare la fonte esatta, pagina o paragrafo, per audit interni, compliance o semplicemente per permettere a chi legge di verificare la risposta. Su questo può essere utile approfondire come verificare una risposta dell'IA con le fonti citate.
• I documenti cambiano spesso: con la RAG si aggiorna solo l'indice del file modificato, senza dover rigenerare o ripensare l'intero prompt.
• Serve bassa latenza: recuperare pochi chunk pertinenti è più veloce che far processare al modello centinaia di migliaia di token ad ogni domanda.
• Serve isolare l'accesso per utente o per cliente (multi-tenant): con un indice è naturale filtrare per base o per permessi, cosa molto più scomoda da gestire dentro un prompt condiviso.

Il meccanismo di recupero conta quanto l'idea stessa di fare RAG: un motore che combina ricerca lessicale e semantica tende a trovare i passaggi giusti più spesso di uno che usa solo vettori o solo parole chiave, come spiegato in ricerca ibrida: perché BM25 e vettori insieme battono entrambi da soli. Anche il modo in cui i documenti vengono tagliati in porzioni, i cosiddetti chunk, incide sulla qualità delle risposte: lo trova approfondito in chunking per RAG: come dividere i documenti per risposte migliori.

Il costo reale: pagare token ad ogni domanda vs indicizzare una volta

Con il contesto lungo, ogni domanda rispedisce (o fa comunque elaborare) l'intero blocco di documenti come token in ingresso, e la fattura cresce con il numero di domande moltiplicato per la dimensione del materiale. Con la RAG, il costo di indicizzazione (estrarre il testo, suddividerlo, calcolare gli embedding) si paga una volta sola quando il documento viene caricato; ogni domanda successiva costa poco perché il modello riceve solo i pochi passaggi effettivamente rilevanti, non l'intero archivio.

Se vuole stimare con più precisione cosa comporta mantenere un indice (storage, calcolo degli embedding, hosting), può consultare costo di un database vettoriale: cosa si paga davvero. Su un marketplace come Kopik, invece, l'indicizzazione è inclusa nella creazione della base: si caricano i documenti, Kopik estrae il testo, lo suddivide e lo indicizza per la ricerca ibrida, e da lì si paga solo a consumo, per domanda posta o con un abbonamento a gauge mensile.

Il problema del 'lost in the middle': più contesto non significa più precisione

Un'idea diffusa è che allargare la finestra di contesto risolva automaticamente il problema della copertura documentale: basta che ci stia tutto. La realtà è più sfumata. Diversi studi sul comportamento dei modelli di linguaggio hanno osservato che la qualità del recupero di un'informazione dipende anche dalla sua posizione all'interno del prompt: un'informazione collocata all'inizio o alla fine del testo tende ad essere usata meglio di una sepolta nel mezzo di un contesto molto lungo, anche quando il modello ha tecnicamente accesso a tutto il materiale. In pratica, riempire il prompt con centinaia di pagine non garantisce che la risposta tenga conto del paragrafo giusto: aumenta la probabilità che il modello si concentri sulle parti più visibili e trascuri il resto.

La RAG attenua questo rischio alla radice: invece di affidare al modello il compito di trovare l'ago nel pagliaio dentro un contesto enorme, è il motore di ricerca a selezionare in anticipo solo i pochi passaggi davvero pertinenti. Il modello riceve meno testo, ma più mirato, e questo tende a tradursi in risposte più precise e più facilmente verificabili. È lo stesso principio alla base di come ridurre le allucinazioni dell'IA con risposte basate sulle fonti.

Architetture ibride: usare RAG e contesto lungo insieme

Le due tecniche non si escludono: nella pratica, molte applicazioni serie le combinano. Si usa la ricerca per selezionare le sezioni più rilevanti tra migliaia di pagine, poi si inserisce nel contesto un volume moderato di testo (non tutto l'archivio, ma più di un singolo chunk), lasciando al modello margine per ragionare su più fonti correlate senza pagare il costo e il rischio del 'lost in the middle' su un prompt enorme. È un buon compromesso quando le domande richiedono di collegare informazioni sparse in più documenti, ma la base resta comunque troppo grande per entrare tutta nel prompt.

Su Kopik questo si traduce in due modalità di interrogazione: una risposta già formulata con le fonti citate, oppure solo i passaggi grezzi più pertinenti (modalità 'passages') da passare a un proprio modello o a un agente. Le basi si possono interrogare dal sito, via API con chiavi dedicate, oppure tramite un server MCP utilizzabile da Claude, Cursor, ChatGPT e altri client compatibili: una scelta utile per chi costruisce agenti che devono decidere da soli quando cercare informazioni. Se non ha mai collegato un client MCP a una base di conoscenza, la guida collegare Claude, Cursor o ChatGPT a una base di conoscenza spiega i passaggi.

Come scegliere in pratica: una checklist rapida

1. Conti quante pagine totali ha la Sua base documentale e verifichi se superano la finestra di contesto del modello che userebbe.
2. Stimi quante domande riceverà al mese: poche decine (il contesto lungo può bastare) o migliaia (la RAG diventa necessaria).
3. Verifichi se serve citare la fonte esatta per motivi di compliance, ad esempio in settori regolati o per rispettare obblighi di trasparenza legati al GDPR o all'AI Act.
4. Consideri quanto spesso cambiano i documenti: aggiornamenti frequenti favoriscono un indice incrementale rispetto a un prompt da ricostruire ogni volta.
5. Valuti la latenza accettabile per chi userà il sistema: un assistente interattivo tollera meno attesa di un report generato una volta al mese.

Se, fatti i conti, la risposta è RAG, non è necessario costruire la pipeline da zero: estrazione del testo, chunking, embedding, ricerca ibrida e citazione delle fonti sono esattamente il lavoro che fa un servizio di RAG as a service. Per capire come si posiziona questo tipo di soluzione rispetto a un database vettoriale gestito in proprio, può leggere piattaforme RAG as a service a confronto o, se preferisce un approccio più artigianale, alternative a Pinecone per piccoli team.

Domande frequenti

Prima di chiudere, rispondiamo ad alcune domande pratiche che spesso si pongono chi deve decidere tra le due strade.