Cos'è il RAG: far leggere i tuoi documenti a un modello

Un modello linguistico ha letto mezzo internet, ma non ha letto le tue cose: il manuale interno dell’azienda, gli appunti del corso, i venti PDF che hai scaricato e mai riaperto. Quella conoscenza è congelata al momento dell’addestramento e non contiene niente di tuo.

Il RAG — retrieval augmented generation, generazione aumentata dal recupero — risolve il problema nel modo più semplice possibile: prima cerca nei tuoi documenti, poi risponde usando quello che ha trovato. È la differenza fra un esame a libro chiuso e uno a libro aperto. Lo studente a libro aperto non sa più cose: sa dove cercarle.

Il problema, detto senza giri

Tu:  "Cosa dice il capitolo 5 del mio manuale?"
LLM: "Non ho accesso ai tuoi documenti. Posso spiegarti i concetti generali..."

Tu:  "Qual è la procedura per le ferie nella mia azienda?"
LLM: "In genere le aziende prevedono..."   ← risposta generica, cioè inutile

Il modello può sapere tutto di diritto del lavoro e non sapere nulla del tuo regolamento. E quando non sa, spesso non tace: riempie il vuoto con qualcosa di plausibile. Ancorare le risposte a documenti veri è anche il modo più efficace per ridurre quel comportamento.

Le tre fasi

Il RAG si divide in una fase che fai una volta e due che si ripetono a ogni domanda.

1. Indicizzazione — una volta sola. I documenti vengono letti, spezzati in pezzi, trasformati in vettori e archiviati.

PDF, appunti, pagine
      │
      ▼
[CARICAMENTO]   legge PDF, Markdown, DOCX, HTML
      │
      ▼
[CHUNKING]      divide in pezzi da poche centinaia di parole
      │              (la scelta più delicata di tutta la pipeline)
      ▼
[EMBEDDING]     ogni pezzo diventa una lista di numeri che ne
      │              rappresenta il significato
      ▼
[ARCHIVIO]      i vettori finiscono in un database pensato per
                   cercare per somiglianza

2. Recupero — a ogni domanda. La domanda viene trasformata in un vettore con lo stesso modello usato per i documenti, e si cercano i pezzi più vicini.

"Come funziona il rimborso spese?"
      │
      ▼
[EMBEDDING DELLA DOMANDA]  stesso spazio dei documenti
      │
      ▼
[RICERCA PER SOMIGLIANZA]  quali pezzi puntano nella stessa direzione?
      │
      ▼
[PRIMI K RISULTATI]        i 3-5 pezzi più pertinenti

3. Generazione. I pezzi recuperati vengono infilati nel prompt insieme alla domanda, e il modello risponde leggendoli.

SISTEMA: Rispondi solo usando il contesto qui sotto.
         Se la risposta non c'è, dillo.

CONTESTO: [pezzo 1: "Le spese vanno rendicontate entro..."]
          [pezzo 2: "Il massimale giornaliero è..."]

DOMANDA:  Come funziona il rimborso spese?

Il modello non ha imparato niente di nuovo: sta leggendo. La conoscenza vive nell’archivio, non nei suoi pesi. È il punto che spiega quasi tutti i comportamenti del RAG, buoni e cattivi.

Perché non basta Ctrl+F

La ricerca classica cerca parole. Il RAG cerca significati, perché lavora sugli embedding: testi che vogliono dire la stessa cosa finiscono vicini nello spazio anche senza condividere un vocabolo.

Cerchi: "polimorfismo"

Ctrl+F  trova:     "Il polimorfismo è un concetto..."
        non trova: "la capacità di un oggetto di assumere forme diverse"

RAG     trova:     "Il polimorfismo è un concetto..."
        trova:     "la capacità di un oggetto di assumere forme diverse"
        trova:     "override e overloading sono i due meccanismi..."

Vale anche il contrario, ed è un limite reale: su un codice prodotto, una sigla o un nome proprio la ricerca testuale è più precisa di quella semantica. Per questo i sistemi seri usano entrambe e fondono i risultati.

I pezzi che compongono un RAG

Componente	Cosa fa	Esempi
Caricatore	Legge i formati e ne estrae il testo	PyMuPDF, Unstructured
Divisore	Spezza i documenti in pezzi	divisori ricorsivi, per struttura
Modello di embedding	Trasforma testo in vettori	nomic-embed-text, BGE-M3
Database vettoriale	Archivia e cerca per somiglianza	Chroma, FAISS, Qdrant
Recuperatore	Sceglie i pezzi da passare al modello	ricerca per somiglianza, riordino
Modello linguistico	Scrive la risposta leggendo i pezzi	quello che già usi in locale

Cinque di questi sei pezzi non sono il modello. È la cosa più utile da capire prima di iniziare: la qualità di un RAG si decide quasi tutta fuori dall’LLM.

Quando serve e quando è sovrastruttura

Situazione	Serve il RAG?	Perché
Un capitolo solo, da capire	No	Incollalo nel prompt e basta
Venti PDF in cui cercare un concetto	Sì	Nessuno li rilegge a mano
Documentazione che cambia ogni settimana	Sì	Si aggiorna l’archivio, non il modello
Confrontare come tre fonti spiegano la stessa cosa	Sì	Recupera i pezzi paralleli
Dare al modello un tono o un formato fisso	No	Quello è un lavoro da system prompt

La prima riga è quella che si sbaglia più spesso. Con le finestre di contesto di oggi, un documento di trenta pagine ci sta dentro tutto: costruirci sopra una pipeline di recupero è lavoro in più che peggiora il risultato. Il RAG inizia ad avere senso quando i documenti non ci stanno, o quando cambiano di continuo.

RAG o fine-tuning?

Sono due risposte a due domande diverse, e vengono confuse di continuo.

	RAG	Fine-tuning
Cosa cambia	Quello che il modello legge	Come il modello si comporta
Conoscenza	Aggiornabile in un secondo	Congelata nei pesi
Costo di aggiornamento	Aggiungi un file all’archivio	Riaddestri
Fonti citabili	Sì	No
Buono per	Fatti, documenti, procedure	Tono, formato, gergo di settore

Regola pratica: se ti serve che il modello sappia qualcosa, RAG. Se ti serve che risponda in un certo modo, fine-tuning. Nei casi seri si usano insieme, ma quasi mai si inizia dal secondo.

Dove si rompe

Il RAG fallisce quasi sempre negli stessi punti, e nessuno di questi è colpa del modello.

Documenti confusi restano confusi. Se il manuale originale è scritto male, il recupero trova pezzi scritti male. Non c’è modello che compensi una fonte scadente.

Il chunking sbagliato. Pezzi troppo piccoli perdono il contesto e diventano incomprensibili; pezzi troppo grandi mescolano troppi argomenti e non risultano vicini a nessuna domanda in particolare. È l’errore numero uno, ed è il tema della prossima lezione.

Due modelli di embedding diversi. Se indicizzi con un modello e cerchi con un altro, i vettori vivono in spazi incompatibili e i risultati sono rumore. Se cambi modello, devi rifare l’archivio da capo.

Troppi pezzi nel prompt. Passare quindici risultati “per sicurezza” satura il contesto e peggiora la risposta: il modello si distrae fra pezzi mediocri. Tre pertinenti battono quindici discreti, sempre.

Falsi positivi. Il recuperatore restituisce sempre qualcosa: anche quando la risposta nei tuoi documenti non c’è, ti consegna i pezzi meno lontani. Senza un’istruzione esplicita a dire “non lo so”, il modello ci costruisce sopra una risposta.

L’illusione dell’apprendimento. Dopo una sessione riuscita viene naturale pensare che il modello ora “conosca” i documenti. Non è così: alla domanda successiva riparte da zero e riconsulta l’archivio. Il RAG non insegna niente a nessuno.

Due strade per partire

Strada 1 — applicazioni pronte
  Un'interfaccia locale con RAG integrato: carichi i documenti e chiedi.
  Mezz'ora di lavoro, controllo limitato su come vengono spezzati i testi.

Strada 2 — framework in Python
  Costruisci la pipeline pezzo per pezzo.
  Qualche ora e un po' di codice, controllo su ogni parametro.

Per studiare o cercare nei propri documenti, la prima strada basta e avanza: un’interfaccia come Open WebUI appoggiata a Ollama fa RAG senza scrivere una riga. La seconda serve quando il recupero va misurato e messo a punto — ed è lì che si scopre quanto pesano le scelte che l’applicazione pronta aveva preso al posto tuo.

In sintesi

Concetto	In una riga
RAG	Prima cerca nei tuoi documenti, poi rispondi usando quei pezzi
Analogia	Esame a libro aperto invece che a libro chiuso
Indicizzazione	Carica, spezza, calcola i vettori, archivia: una volta sola
Recupero	La domanda diventa un vettore e pesca i pezzi più vicini
Non è	Insegnare qualcosa al modello: la conoscenza resta nell’archivio
Quando evitarlo	Se il documento sta nella finestra di contesto, incollalo
Errore tipico	Chunking sbagliato e troppi pezzi passati per sicurezza
Regola ferrea	Stesso modello di embedding per indicizzare e per cercare