Guida

Come funziona il RAG, passo dopo passo: una domanda reale seguita dall’inizio alla fine

Il team di Kopik8 min di lettura

Come funziona il RAG, in breve: prima di tutto i documenti vengono divisi in passaggi e indicizzati; quando arriva una domanda, il sistema recupera i passaggi più pertinenti, li riordina, li inserisce in un prompt e chiede a un modello linguistico di rispondere solo sulla base di quelli, citando le fonti. Il modo migliore per capirlo è vederlo all’opera. In questa guida seguiamo una sola domanda, posta da una dipendente di una PMI immaginaria, attraverso tutte e sette le fasi della retrieval augmented generation, dal caricamento del PDF alla risposta con fonti.

Il punto di partenza: una domanda, tre documenti

La nostra PMI, un’azienda di componenti meccanici con 60 dipendenti in provincia di Bergamo, ha caricato tre documenti nella sua base di conoscenza: il regolamento sul lavoro agile del 2026 (un PDF di 15 pagine), il vecchio regolamento del 2023, che nessuno ha rimosso, e una FAQ del personale scritta in Word. Una dipendente scrive all’assistente interno:

Quanti giorni a settimana posso lavorare da casa?

La risposta si trova all’articolo 4 del regolamento 2026, intitolato «Modalità di svolgimento della prestazione in lavoro agile». Le parole «da casa» non compaiono mai. Il regolamento del 2023 prevedeva una regola diversa. Tenga a mente questi due dettagli: sono proprio le trappole che una pipeline RAG deve superare.

Prima di ogni domanda: ingestione, chunking e indicizzazione

Le prime tre fasi avvengono una volta, al caricamento dei documenti, e di nuovo a ogni aggiornamento. La dipendente non le vede mai, ma da esse dipende quasi tutta la qualità della risposta.

Fase 1. Ingestione: dai file al testo pulito

La pipeline apre ogni file e ne estrae il testo. Per il PDF significa leggere il livello di testo pagina per pagina, togliere intestazioni e piè di pagina ripetuti («Regolamento interno, pag. 6 di 15») e conservare i titoli, così la struttura resta leggibile. Ogni documento riceve anche dei metadati: titolo, nome del file e, se possibile, data di entrata in vigore. Quella data sarà decisiva quando le versioni 2023 e 2026 entreranno in concorrenza.

Cosa può andare storto: un PDF scansionato senza livello di testo non restituisce nulla, e una tabella appiattita diventa una sequenza di numeri senza senso. Le regole importanti dovrebbero quindi comparire anche nel testo discorsivo.

Fase 2. Chunking: passaggi che si possono ritrovare

Il testo viene diviso in chunk, passaggi di qualche centinaio di parole. L’articolo 4 diventa il chunk 31. Un buon chunking fa due piccole cose che aiutano la nostra domanda: antepone al passaggio il suo percorso di titoli («Regolamento lavoro agile 2026 > Art. 4 Modalità di svolgimento») e lo sovrappone leggermente al successivo, per non tagliare una frase a metà. In sostanza il chunk 31 dice: la prestazione in lavoro agile è possibile fino a due giorni a settimana, concordati con il responsabile, esclusi il lunedì e i giorni di chiusura mensile.

Fase 3. Indicizzazione: rendere i passaggi trovabili

Ogni chunk finisce in un indice. Un indice full text registra le parole in forma normalizzata, così «giorno», «giorni» e «giornata» si riconoscono a vicenda. Un indice vettoriale conserva un embedding, una serie di numeri che rappresenta il significato del passaggio. Molti sistemi usano entrambi; una corretta configurazione della lingua italiana è ciò che permette alla ricerca di gestire plurali e coniugazioni.

Arriva la domanda: ricerca e reranking

Fase 4. Ricerca: gettare una rete ampia

La dipendente scrive «da casa» e «giorni a settimana»; il regolamento parla di «lavoro agile» e di «prestazione». Una ricerca letterale mancherebbe il bersaglio. Due tecniche colmano il divario: l’espansione della query, in cui un modello linguistico riformula la domanda con termini aggiuntivi (lavoro agile, smart working, lavoro da remoto, giornate, prestazione), e la ricerca semantica, che trova passaggi di significato simile anche con parole diverse. Il risultato è una lista di candidati, spesso tra 20 e 50. I primi sono:

  1. Chunk 31 (regolamento 2026, art. 4): fino a due giorni a settimana, escluso il lunedì.
  2. Chunk 92 (regolamento 2023, art. 4): la vecchia regola di un giorno a settimana.
  3. Chunk 32 (regolamento 2026, art. 5): richiesta delle giornate tramite il portale del personale entro il venerdì precedente.
  4. Chunk 7 (FAQ): dotazione di portatile e rimborso forfettario della connessione.
  5. Chunk 45 (regolamento 2026, art. 9): diritto alla disconnessione dopo le 19.

Fase 5. Reranking: le prove migliori in cima

La ricerca punta su velocità e completezza, e può permettersi di essere un po’ larga. Il reranking (riordinamento) è una seconda lettura più attenta: un modello legge la domanda insieme a ciascun candidato e valuta quanto il passaggio vi risponda davvero. Si aggiungono regole aziendali: eliminare i doppioni e preferire la versione più recente. Nel nostro esempio il chunk 31 sale al primo posto, il 32 resta perché spiega come chiedere le giornate, la disconnessione e la dotazione scendono, e il regolamento 2023 viene escluso o segnalato chiaramente come superato.

Il reranking è facoltativo, la sua funzione no

Alcuni sistemi usano un modello di riordinamento dedicato, altri una ricerca ibrida ben calibrata con filtri sui metadati. Ciò che conta è che un passaggio superato non arrivi mai per primo e senza etichetta al modello. Qui significherebbe rispondere «un giorno a settimana», con sicurezza e in modo sbagliato.

Composizione del prompt e risposta con le fonti

Fase 6. Composizione del prompt

Il modello linguistico non cerca nulla da solo. Riceve un prompt costruito dalla pipeline, di solito in quattro parti:

  1. Istruzioni: rispondere solo con le fonti seguenti, citarle come [1], [2] e dire chiaramente se non contengono la risposta.
  2. Fonti numerate: [1] chunk 31 con titolo e data, [2] chunk 32, [3] chunk 7.
  3. La domanda, così come l’ha scritta la dipendente.
  4. Contesto: lingua, data del giorno, formato atteso (risposta breve, poi dettagli).

I passaggi dei documenti sono trattati come dati, mai come ordini, e racchiusi tra delimitatori chiari: una frase nascosta in un documento non deve poter dirottare il modello.

Fase 7. Generazione: una risposta verificabile

Il modello scrive qualcosa come: «Può lavorare in modalità agile fino a due giorni a settimana, da concordare con il Suo responsabile, escluso il lunedì [1]. Le giornate vanno richieste dal portale del personale entro il venerdì precedente [2]. L’azienda fornisce il portatile e un rimborso forfettario per la connessione [3].» Ogni numero rimanda al passaggio originale, così la dipendente, o l’ufficio del personale, può leggere il testo esatto.

Il modello non ha inventato una regola e non ha citato il regolamento 2023. E c’è una cosa che non deve fare: sostituirsi all’ufficio del personale. In Italia il lavoro agile richiede un accordo individuale scritto, previsto dalla legge 81/2017, quindi se la dipendente non l’ha ancora firmato, un buon assistente lo segnala e la indirizza alle persone giuste invece di improvvisare.

L’intero percorso in una tabella

Una domanda attraverso una pipeline RAG

FaseCosa succede alla nostra domandaGuasto tipico
1. IngestioneTesto estratto, intestazioni tolte, data conservataPDF scansionato, tabelle rovinate
2. ChunkingL’art. 4 diventa il chunk 31 con i suoi titoliRegola spezzata tra due chunk
3. IndicizzazioneChunk nell’indice full text e vettorialeLingua sbagliata, indice non aggiornato
4. Ricerca«Da casa» collegato a «lavoro agile»; 5 candidatiIl passaggio giusto manca
5. RerankingRegolamento 2026 in cima, 2023 esclusoVersione superata al primo posto
6. PromptIstruzioni, tre fonti numerate, domandaTroppi passaggi, nessun obbligo di citare
7. GenerazioneRisposta con [1][2][3]Affermazioni senza fonte

La tabella è anche una lista di controllo per la diagnosi. Davanti a una risposta sbagliata, ripercorra il cammino all’indietro: il passaggio giusto era nel prompt? Se sì, il problema sta nelle istruzioni o nella generazione. Se no, era tra i candidati? Se neanche, controlli il chunking e l’estrazione. La maggior parte degli errori nasce nelle fasi 1, 2 e 4.

Usare questa pipeline senza doverla costruire

Mettere in piedi le sette fasi da soli richiede un estrattore, un sistema di chunking, un database, uno strato di ricerca, l’API di un modello e il codice che tiene tutto insieme. Kopik fa girare questa pipeline al posto Suo. Creare una base è gratuito: carica file PDF, Word, testo o Markdown, e Kopik estrae, suddivide e indicizza il contenuto per una ricerca ibrida (full text più espansione semantica delle parole chiave). Ogni domanda restituisce una risposta fondata sui Suoi documenti con i passaggi citati, oppure solo i passaggi grezzi in modalità «passaggi».

Una base può restare privata (solo Lei e le Sue chiavi API) oppure essere pubblicata nel catalogo delle basi, dove si paga a domanda: il creatore fissa il prezzo e trattiene il 70%. Si interroga dal sito, con l’API REST o da Claude, Cursor, ChatGPT e altri client MCP; la documentazione per sviluppatori spiega la configurazione. Come con qualsiasi fornitore, verifichi prima del caricamento se i documenti contengono dati personali soggetti al GDPR.

Faccia passare la Sua domanda nella pipeline

Carichi un regolamento, un manuale o una procedura e ponga una domanda reale: la risposta arriva con i passaggi su cui si basa.

Faccia la prova come abbiamo appena fatto

Scelga cinque domande che il Suo team pone davvero, annoti dove si trova la risposta nei documenti e confronti le citazioni di ogni risposta con quel punto. È il modo più rapido per capire quale fase migliorare.

Domande frequenti

Quali sono le fasi della retrieval augmented generation?

Due momenti. Prima delle domande: ingestione (estrazione del testo), chunking in passaggi e indicizzazione. A ogni domanda: ricerca dei candidati, reranking per ordinarli secondo la reale pertinenza, composizione del prompt (istruzioni, fonti, domanda) e generazione di una risposta che cita le fonti.

Il reranking è obbligatorio in un’architettura RAG?

Non sempre. Una base piccola e ordinata funziona spesso bene con una buona ricerca ibrida. Il reranking diventa prezioso quando la lista dei candidati è lunga, quando convivono più versioni di un documento o quando passaggi simili rispondono a domande diverse.

Quanti passaggi bisogna inviare al modello?

Di solito pochi, tra tre e dieci. Con troppo pochi la risposta può mancare; con troppi il modello si distrae, mentre costi e tempi salgono. Il numero giusto dipende dalla dimensione dei chunk e dai documenti, quindi va provato con domande reali.

Perché un sistema RAG a volte risponde con un documento superato?

Perché entrambe le versioni sono indicizzate e quella vecchia corrispondeva bene alla domanda. La soluzione è eliminare i documenti obsoleti, salvare la data di entrata in vigore come metadato e far sì che l’ordinamento preferisca la versione più recente.

Il modello linguistico cerca da solo nei documenti?

No. La ricerca è svolta dallo strato di recupero prima di chiamare il modello, che vede soltanto i passaggi selezionati nel prompt. Per questo la qualità della ricerca pesa così tanto sulla risposta finale.

Riceva la newsletter di Kopik

Nuove basi di conoscenza, guide sul RAG e novità del prodotto. Un'email ogni una o due settimane, disiscrizione con un clic.

Iscrivendosi accetta di ricevere la nostra newsletter. Il Suo indirizzo non viene mai condiviso.