Quando il RAG non serve (e cosa fare invece)
Capita spesso: qualcuno impara a costruire un RAG, funziona, e da quel momento ogni problema che coinvolge dei documenti diventa "un altro RAG". Cartella con dodici PDF? RAG. Foglio Excel con le vendite del trimestre? RAG. Un manuale da rileggere ogni tanto? RAG. È il classico effetto del martello nuovo: tutto sembra un chiodo.
Il problema è che un RAG ha un costo nascosto. Vanno scelti i chunk, un modello di embedding, un vector database; va tenuto tutto aggiornato; e ogni risposta sbagliata ti obbliga a indagare se il guaio è nel recupero o nella generazione. È infrastruttura, e come ogni infrastruttura si giustifica solo quando serve davvero. In parecchi casi c'è una strada più semplice, più economica e più precisa. Questo articolo elenca quei casi e ti dà un modo per decidere prima di scrivere una riga di codice.
Cosa risolve davvero il RAG
Prima di dire quando non serve, mettiamo a fuoco a cosa serve. Il RAG risolve un problema molto specifico: hai troppa conoscenza per infilarla tutta nel prompt, quella conoscenza cambia nel tempo, e per ogni domanda te ne serve solo un pezzetto. Recuperi i pezzi rilevanti, li metti nel contesto, e il modello risponde su quelli.
Se togli anche una sola di queste tre condizioni — troppa roba, che cambia, di cui serve solo una parte — il RAG smette di essere la scelta ovvia. Ed è esattamente lì che la maggior parte dei progetti fatti in casa sbaglia: costruisce una pipeline di recupero per un problema che non richiede recupero.
I casi in cui il RAG è la scelta sbagliata
Quando i documenti ci stanno già nel contesto
Il RAG è nato quando le finestre di contesto erano minuscole: qualche migliaia di token, e dovevi per forza selezionare cosa mostrare al modello. Oggi i modelli di punta leggono centinaia di migliaia — spesso un milione — di token in una volta. Un contratto, un manuale di prodotto, persino un piccolo insieme di documenti spesso ci stanno interi.
Se il tuo materiale entra comodamente nella finestra di contesto, dare al modello tutto il testo batte quasi sempre un RAG in qualità: niente si perde nel taglio dei chunk, niente viene "mancato" dal recupero. Un lavoro di ricerca che ha confrontato sistematicamente le due strade lo dice chiaro: a parità di risorse, il long context tende a superare il RAG sulle domande di comprensione, perché il RAG paga il pedaggio della selezione. La contropartita è il costo per token: se interroghi lo stesso documento centinaia di volte al giorno, ricaricarlo ogni volta diventa caro. Ma per volumi normali, la semplicità vince.
Quando la domanda è su dati strutturati
"Quanti clienti abbiamo perso a giugno?" "Qual è il margine medio per categoria?" Domande così non hanno bisogno di recupero semantico: hanno bisogno di un calcolo su dati strutturati. Se la tua fonte è un database, un CSV o un foglio di calcolo, spezzarlo in chunk e cercare per similarità è il modo peggiore di rispondere: gli embedding sono bravissimi a trovare testi simili, e pessimi a fare aritmetica o a filtrare righe con precisione.
La risposta giusta è far generare al modello una query — SQL su un database, o codice su un dataframe — eseguirla, e restituire il risultato. È più preciso (i numeri sono giusti al 100%, non "plausibili") e verificabile: la query si può leggere e controllare.
Quando serve un termine esatto
Il recupero vettoriale eccelle sui significati, ma inciampa sugli identificatori precisi: un codice prodotto, un numero d'ordine, il nome esatto di una funzione, un riferimento normativo come "Articolo 50". Sono stringhe, non concetti, e la ricerca semantica non è fatta per loro. Per questi casi una vecchia, onesta ricerca full-text (per parola chiave) trova il documento giusto molto meglio — e in un istante.
Quando il compito non è recuperare, ma trasformare
Riassumere un testo che hai già, tradurlo, riscriverlo in un altro tono, estrarne una tabella: qui non c'è nulla da "cercare". Il documento è davanti al modello per definizione. Aggiungere un RAG a un compito di trasformazione è puro sovraccarico. Stesso discorso quando ciò che vuoi non è un fatto ma uno stile o un formato costante: quello si ottiene con buoni esempi nel prompt o, nei casi seri, con il fine-tuning — non con il recupero.
Cosa fare invece
La buona notizia è che le alternative sono quasi tutte più semplici del RAG.
Metti tutto nel contesto. Se i documenti ci stanno, incollali (o allegali) e fai la domanda. Zero infrastruttura, qualità massima. È il punto di partenza da cui misurare tutto il resto: costruisci un RAG solo se questa strada non basta.
Fai generare una query. Per dati in tabelle o database, chiedi al modello di produrre SQL o codice, eseguilo tu, e passagli il risultato. È il pattern giusto per la business intelligence conversazionale e per qualsiasi domanda che finisce in un numero.
Usa la ricerca full-text, o una ricerca ibrida. Quando contano i termini esatti, la ricerca per parola chiave è imbattibile. E quando ti servono entrambe le cose — significato e precisione — la ricerca ibrida (vettori + parole chiave) è spesso la vera risposta, anche dentro un RAG.
Lascia cercare all'agente. Una tendenza recente e concreta: invece di pre-indicizzare tutto in un vector database, dai al modello degli strumenti — una ricerca full-text, l'accesso a un filesystem, una API — e lascia che sia lui a decidere cosa aprire e leggere, un passo alla volta. È l'agentic search: meno impianto da mantenere, e per basi documentali che cambiano di continuo spesso più robusto di un indice da tenere sincronizzato.
Fai fine-tuning per stile e formato, non per i fatti. Se il problema è "voglio che risponda sempre in questo modo", il fine-tuning è lo strumento. Se il problema è "voglio che conosca questi documenti che cambiano ogni settimana", non lo è: per la conoscenza mutevole restano il contesto o il recupero.
La decisione, in pratica
Nessuna di queste strade esclude le altre. I sistemi seri del 2026 non scelgono "RAG o contesto" una volta per tutte a inizio progetto: mettono davanti un piccolo strato di instradamento che decide query per query. Un lavoro di Google DeepMind ha formalizzato l'idea con un metodo chiamato Self-Route: il modello stesso valuta se una domanda si può risolvere con il solo recupero economico o se serve dare in pasto l'intero contesto, e instrada di conseguenza. Il risultato è la qualità del long context al costo tipico del RAG.
Non ti serve costruire tutto questo al primo giorno. Ti serve la mentalità: prima di aprire il vector database, chiediti se il problema che hai davanti è davvero un problema di recupero da tanta conoscenza mutevole. Se non lo è, la soluzione più semplice non è un ripiego — è la scelta migliore.
Prova subito
Prendi un compito su cui staresti per costruire (o hai già costruito) un RAG e passalo attraverso quattro domande, in ordine:
- I documenti ci stanno nel contesto? Se sì, incollali e fai la domanda. Confronta la risposta con quella del tuo RAG: nove volte su dieci è almeno pari, spesso migliore.
- La risposta è un numero o un filtro su dati strutturati? Se sì, chiedi al modello di scriverti la query (SQL o codice), eseguila e verifica il risultato a mano.
- La domanda contiene un termine esatto (codice, nome, riferimento)? Se sì, prova una ricerca full-text prima di quella semantica.
- Il compito è trasformare un testo che ho già (riassunto, traduzione, riformattazione)? Se sì, non ti serve alcun recupero.
Se dopo queste quattro domande sei ancora nel caso "tanta conoscenza, che cambia, di cui serve solo un pezzo", allora sì: il RAG è la scelta giusta, e sai anche perché. In tutti gli altri casi ti sei appena risparmiato un'infrastruttura da mantenere.