I grandi modelli linguistici hanno un problema di memoria. Sanno ciò che hanno imparato durante l’addestramento. Nient’altro. Chiedi dei documenti interni della tua azienda, delle notizie di ieri o di qualsiasi cosa successa dopo il limite temporale dell’addestramento, e o tirano a indovinare o ammettono di non saperlo.

RAG risolve questo. Più o meno.

La generazione aumentata dal recupero (RAG) è esattamente ciò che suggerisce il nome: prima di generare una risposta, il sistema recupera informazioni pertinenti da fonti esterne, poi usa quelle informazioni per produrre una risposta più accurata. Il modello non deve aver memorizzato il manuale della tua azienda se può andarlo a cercare prima.

L’idea di base, in parole semplici

Pensa a come rispondi alle domande quando non sei sicuro. Non vai a intuito. Prima cerchi, poi formi la risposta in base a ciò che hai trovato. RAG funziona allo stesso modo, solo che il “cercare” avviene automaticamente prima che l’IA risponda.

Ecco cosa succede quando fai una domanda a un sistema RAG:

1. La tua domanda viene convertita in una rappresentazione numerica (un embedding)
2. Il sistema cerca in un database contenuti con rappresentazioni simili
3. I pezzi di testo più pertinenti vengono recuperati e aggiunti alla tua domanda
4. Il modello linguistico riceve sia la tua domanda sia il contesto recuperato
5. Genera una risposta basandosi su quell’input combinato

Come ha spiegato l’utente ozr su Hacker News: “It’s right there in the name - first you Retrieve relevant information (often a vector lookup) then you use it to Augment the prompt, then you Generate an answer.”

Il modello linguistico non “impara” mai i tuoi dati. Li vede solo nel momento in cui risponde, come se qualcuno gli passasse una pagina rilevante di un libro di testo subito prima di una domanda d’esame.

Perché conta

I modelli linguistici allucinano. Generano informazioni che suonano plausibili ma sono sbagliate perché riconoscono schemi, non verificano i fatti. I dati di addestramento possono essere obsoleti, incompleti o semplicemente sbagliati per la tua situazione specifica.

RAG attacca questo problema alla radice. Ancorando il modello ai documenti recuperati, gli dai fonti reali su cui lavorare invece di affidarti solo agli schemi statistici appresi in addestramento. Il modello può allucinare fino a un certo punto quando gli hai letteralmente messo davanti la risposta corretta da cui attingere.

Questo risolve tre problemi insieme:

Attualità: i modelli hanno limiti temporali di addestramento. Le informazioni cambiano. RAG ti permette di collegare un modello a fonti aggiornate continuamente senza doverlo riaddestrare.

Specificità: un modello addestrato sull’internet in generale non sa nulla dei processi interni della tua azienda, dei tuoi prodotti o della tua terminologia. RAG ti permette di puntarlo sulla tua base di conoscenza specifica.

Verificabilità: quando le risposte arrivano da fonti recuperate, puoi risalire alla fonte. Il modello non sta semplicemente inventando tutto da correlazioni statistiche.

Come ha scritto hirako2000 su Hacker News: “RAG’s point is to remove the limit LLMs alone have which is that they are limited to the training data as source of information.”

Come funziona davvero il recupero

La fase di recupero è dove le cose diventano tecnicamente interessanti. La maggior parte dei sistemi RAG usa la ricerca vettoriale, detta anche ricerca semantica. I tuoi documenti vengono trasformati in vettori numerici (embedding) che ne catturano il significato. Quando arriva una domanda, subisce lo stesso trattamento. Il sistema poi trova i documenti i cui vettori sono matematicamente più vicini al vettore della domanda.

Questo funziona meglio della ricerca per parole chiave perché cattura il significato, non solo le parole. Una domanda sulla “policy ferie dei dipendenti” può abbinarsi a un documento intitolato “Linee guida PTO” anche se non condividono nessuna parola esatta.

Ma la ricerca vettoriale non è l’unica opzione. Come ha osservato il ricercatore di IA Simon Willison su Hacker News: “You don’t have to use vector search to implement RAG. You can use other search mechanisms instead or as well.”

Alcuni professionisti preferiscono la ricerca testuale tradizionale (BM25) per certi casi d’uso. Un commentatore in un recente thread di Hacker News sul RAG locale ha osservato: “In a lot of the cases bm25 has been the best approach used in many of the projects we deployed.” Altri combinano approcci, usando sia ricerca per parole chiave sia ricerca semantica per catturare tipi diversi di pertinenza.

La scelta dipende dai tuoi dati. Documenti tecnici densi, con terminologia specifica, possono funzionare meglio con la ricerca per parole chiave. Contenuti conversazionali, con formulazioni variabili, potrebbero richiedere abbinamento semantico. Per il codice in particolare, uno sviluppatore ha osservato: “Don’t use a vector database for code, embeddings are slow and bad for code. Code likes bm25+trigram.”

Cosa RAG non può fare

Capire male i limiti di RAG causa la maggior parte dei fallimenti. La tecnica è potente, ma ha un perimetro ristretto.

RAG non rende i modelli linguistici più intelligenti. Gli dà accesso a informazioni che altrimenti non avrebbero. Ma se il modello non sa ragionare bene su quelle informazioni, o se il recupero tira fuori i documenti sbagliati, ottieni comunque risposte scadenti.

Un utente di Hacker News ha offerto un’analogia memorabile: “Using RAG feels like asking an acquaintance to write a book report by giving them semi-randomly cut out paragraphs from the book.”

Questa è la limitazione fondamentale: RAG recupera pezzi, non comprensione. Se la tua domanda richiede di sintetizzare informazioni lungo un intero documento, o di collegare intuizioni da più fonti in modi complessi, il recupero a pezzi potrebbe non dare al modello ciò che gli serve.

Un altro commentatore nello stesso thread ha spiegato il vincolo in modo più preciso: “Simple RAG works well when questions are highly correlated with specific chunks of documents. It does not allow an LLM to synthesize an entire corpus to an answer (e.g. a book report).”

RAG inoltre non impedisce del tutto le allucinazioni. Riduce il rischio fornendo un ancoraggio fattuale, ma i modelli possono comunque:

• Interpretare male i documenti recuperati
• Generare risposte sicure di sé a partire da fonti ambigue
• Riempire i vuoti tra i pezzi recuperati con dettagli inventati
• Combinare citazioni accurate in conclusioni sbagliate

La tecnologia funziona meglio quando le domande hanno risposte chiare e localizzate dentro la tua raccolta di documenti. Fa fatica con domande che richiedono comprensione o sintesi “a tutto campo” su grandi volumi di testo.

RAG vs fine-tuning

Una domanda comune: quando dovresti usare RAG invece di fare fine-tuning di un modello sui tuoi dati?

Il fine-tuning regola i pesi del modello in base ai tuoi dati, insegnandogli di fatto nuovi schemi. RAG lascia il modello invariato ma gli fornisce informazioni esterne al momento della richiesta.

Servono a cose completamente diverse.

Il fine-tuning cambia il modo in cui il modello scrive e ragiona. È utile per insegnare a un modello il tono della tua azienda, la terminologia del tuo settore o il formato di output che preferisci. Non aggiunge in modo affidabile nuovi fatti. I modelli faticano a distinguere le informazioni apprese in fine-tuning da quelle dell’addestramento di base.

Come ha detto un professionista: “Fine tuning is not good for really adding/removing facts but is great for changing the form of the output.”

RAG aggiunge accesso alle informazioni. Permette ai modelli di rispondere a domande su contenuti che non hanno mai visto durante l’addestramento. Lo stile del modello resta lo stesso, ma la sua conoscenza si espande.

Per la maggior parte delle applicazioni aziendali, li vuoi entrambi, insieme: un modello con fine-tuning per il tuo stile di comunicazione, collegato via RAG alla tua documentazione attuale. Nessuno dei due, da solo, risolve il problema completo.

Quando RAG ha senso

RAG funziona bene per:

Sistemi di assistenza clienti: collega un chatbot alla tua documentazione di supporto. Le domande vengono abbinate agli articoli più pertinenti e il modello genera risposte in linguaggio naturale ancorate ai tuoi contenuti di assistenza reali.

Basi di conoscenza interne: lascia che i dipendenti facciano domande su policy aziendali, procedure e documentazione senza rovistare in cartelle o wiki.

Documentazione di prodotto: gli utenti possono fare domande in linguaggio naturale su come funzionano i prodotti e ottenere risposte estratte dalla documentazione reale.

Conformità legale o normativa: quando le risposte devono essere tracciabili a documenti sorgente specifici, RAG fornisce la “pista di carta” che i soli output del modello non possono dare.

Il filo comune: situazioni in cui ti serve che il modello lavori con informazioni specifiche, delimitate e verificabili, invece che con conoscenza generale.

Quando valutare alternative

RAG non è sempre la scelta giusta.

Modelli con contesto lungo: modelli con finestre di contesto enormi (100K+ token) a volte possono contenere intere raccolte di documenti direttamente. Se la tua base di conoscenza è abbastanza piccola, potresti non aver bisogno del recupero. Come ha osservato un professionista: “85% of the time we don’t need the vectordb” dopo aver scoperto che approcci più semplici risolvevano il suo caso d’uso.

Interrogazioni su dati strutturati: se le informazioni vivono in database con schemi puliti, i sistemi di interrogazione tradizionali potrebbero servirti meglio della ricerca vettoriale. RAG eccelle sul testo non strutturato, non sui dati tabellari.

Informazioni in tempo reale: RAG presume che la tua base di conoscenza sia già pronta. Per dati davvero “live” (prezzi azionari, meteo, notizie correnti), ti servono integrazioni API, non recupero documentale.

Compiti di ragionamento complessi: domande che richiedono ragionamento multi-passaggio su molte fonti mettono in difficoltà l’approccio a pezzi di RAG. Alcuni problemi richiedono sistemi agentici che sappiano cercare, ragionare e iterare, invece di recuperare-una-volta-e-generare.

La realtà dell’implementazione

Costruire sistemi RAG in produzione comporta più decisioni di quanto suggeriscano i tutorial. La dimensione dei chunk conta: troppo piccoli e perdi contesto; troppo grandi e sprechi l’attenzione del modello su contenuti irrilevanti. La qualità del recupero varia enormemente in base alla scelta del modello di embedding e ai parametri di ricerca.

Molti professionisti hanno scoperto che approcci più semplici spesso battono quelli complessi. Il panorama degli strumenti è ancora instabile. Alcuni sviluppatori trovano utili le piattaforme RAG commerciali. Altri preferiscono costruire con componenti semplici. “SQLite works shockingly well,” un commentatore di Hacker News ha notato a proposito del suo sistema in produzione.

Un’altra osservazione dalla comunità dei professionisti: “A little BM25 can get you quite a way with an LLM.” L’implicazione è chiara. Parti semplice. Misura i risultati. Aggiungi complessità solo quando le misurazioni dimostrano che ti serve.

Ciò che funziona dipende molto dai tuoi dati specifici, dalle domande e dai requisiti di accuratezza. Le aziende che stanno ottenendo valore reale da RAG di solito sono partite in modo semplice, hanno misurato con attenzione e hanno iterato in base alle prestazioni reali, non alle migliori pratiche teoriche.

Il quadro generale

RAG rappresenta una scelta architetturale specifica: tenere il modello linguistico generale, ma collegarlo a conoscenza specializzata al momento della richiesta. Questo scambia una parte di capacità con flessibilità. Le tue informazioni restano in fonti che controlli, gli aggiornamenti avvengono senza riaddestrare e le risposte possono essere verificate rispetto ai documenti recuperati.

Come ha scritto minimaxir su Hacker News: “RAG is the one paradigm of modern AI that’s completely uncontroversial (hallucinations aside) and will persist even if there’s an AI-industry crash.”

L’idea di base di aumentare la generazione con il recupero risolve un problema reale che non scompare con modelli di base migliori.

Quello che è meno certo è se le implementazioni attuali catturino tutto il potenziale. I sistemi RAG di oggi fanno perlopiù una semplice ricerca di similarità seguita da una generazione “one-shot”. Esistono approcci più sofisticati: quelli che cercano in modo iterativo, verificano le informazioni recuperate o sintetizzano su molte fonti. Queste restano aree di sviluppo attivo.

La tecnica ha dimostrato il suo valore per query ristrette e basate su fatti, su basi di conoscenza strutturate. Che possa scalare a applicazioni più disordinate e ambiziose resta una domanda aperta. Le aziende che implementano RAG con successo di solito sono state oneste sui suoi limiti, usandolo dove aiuta davvero invece di forzarlo su problemi che richiedono soluzioni diverse.

Per la maggior parte delle organizzazioni che esplorano l’IA, vale la pena capire RAG. Non perché risolva tutto. Perché sapere cosa fa, e cosa non fa, ti aiuta a scegliere meglio dove l’IA può davvero aiutare il tuo lavoro.