Un sistema RAG permette a un assistente AI di cercare informazioni nei documenti autorizzati prima di formulare la risposta. In questo modo il modello non dipende soltanto da ciò che ha appreso durante l’addestramento: riceve un contesto aggiornato, può indicare le fonti utilizzate e diventa più utile su procedure, manuali, contratti e knowledge base aziendali.
RAG significa Retrieval-Augmented Generation, cioè generazione aumentata dal recupero di informazioni. Non rende automaticamente corretto un modello e non sostituisce permessi, qualità dei documenti o verifica umana. È un’architettura che separa due attività: trovare i passaggi pertinenti e generare una risposta basata su quei passaggi.
Indice
- Che cos’è il RAG
- Un esempio semplice
- Come funziona
- Come costruire un primo progetto
- Cloud oppure AI locale
- Sicurezza e autorizzazioni
- Come misurare la qualità
- Errori frequenti
- FAQ
Che cos’è il RAG, in parole semplici
Un modello linguistico generalista conosce molte informazioni, ma non possiede necessariamente i documenti della tua organizzazione e potrebbe non conoscere le versioni più recenti. Con il RAG, l’applicazione cerca nei contenuti disponibili, seleziona alcuni passaggi e li inserisce insieme alla domanda nel prompt inviato al modello.
Il modello riceve quindi tre elementi:
- la domanda dell’utente;
- le istruzioni su come rispondere;
- i passaggi recuperati dai documenti.
Una buona istruzione impone di utilizzare soltanto il contesto fornito, dichiarare quando le informazioni non sono sufficienti e mostrare il documento o la sezione da cui deriva la risposta.
RAG non significa addestrare nuovamente il modello
Il RAG non modifica i pesi del modello e non equivale al fine-tuning. I documenti rimangono in una base esterna che può essere aggiornata, corretta o cancellata senza riaddestrare l’LLM. Questo lo rende adatto a conoscenze soggette a frequenti revisioni.
Un esempio semplice: il manuale delle ferie
Immaginiamo che un dipendente chieda: “Quanti giorni prima devo richiedere le ferie estive?”. Un chatbot generico potrebbe dare una risposta plausibile ma non conforme alla procedura aziendale.
Un sistema RAG esegue invece questi passaggi:
- cerca la domanda nell’indice dei documenti autorizzati;
- recupera il paragrafo della procedura ferie;
- fornisce il passaggio al modello;
- genera una risposta sintetica;
- indica titolo, versione e collegamento al documento.
Se la procedura non contiene la risposta, il comportamento corretto non è inventarla: il chatbot deve comunicarlo e indicare a chi rivolgersi.
Come funziona un sistema RAG
1. Preparazione dei documenti
PDF, pagine web, file Office, ticket o record di database vengono acquisiti e trasformati in testo utilizzabile. In questa fase occorre eliminare duplicati, intestazioni ripetute, pagine vuote e contenuti non autorizzati. I documenti scansionati richiedono anche un passaggio OCR.
2. Suddivisione in chunk
I documenti vengono divisi in segmenti, chiamati chunk. Un blocco troppo grande contiene rumore e consuma molti token; uno troppo piccolo può perdere il contesto. Titolo, capitolo, numero di pagina, versione, proprietario e livello di accesso devono accompagnare ogni segmento come metadati.
3. Embedding e indice
Un modello di embedding trasforma ciascun segmento in una rappresentazione numerica. I vettori vengono conservati in un indice ottimizzato per la ricerca di similarità. Non è però obbligatorio affidarsi soltanto ai vettori: in molti casi la ricerca ibrida, che combina parole chiave e similarità semantica, recupera meglio codici, sigle, nomi di prodotti e riferimenti normativi.
4. Recupero e ordinamento
La domanda viene trasformata in una query. Il retriever seleziona i passaggi candidati, applica filtri e può riordinarli con un reranker. Prima della ricerca devono essere applicati i permessi dell’utente: filtrare i risultati dopo il recupero può già esporre informazioni non autorizzate ai componenti successivi.
5. Generazione con fonti
I passaggi migliori vengono aggiunti al prompt. Il modello prepara la risposta, ma l’applicazione deve conservare l’associazione tra ogni citazione e la relativa fonte. La presenza di contesto non elimina completamente le allucinazioni: il modello può interpretare male un testo oppure combinare passaggi incompatibili.
Come costruire un primo RAG passo dopo passo
Passo 1: definisci un caso d’uso ristretto
Non partire da “tutti i documenti aziendali”. Scegli una raccolta delimitata e un gruppo di domande concreto: manuale di un prodotto, procedure del Service Desk, knowledge base tecnica o documentazione di onboarding.
Passo 2: individua proprietario e fonte ufficiale
Ogni documento dovrebbe avere un proprietario, una versione, una data di validità e una posizione ufficiale. Una cartella piena di copie non controllate produce risposte incoerenti anche con il miglior modello.
Passo 3: prepara un set di domande
Raccogli almeno venti domande reali, comprese richieste ambigue, informazioni assenti e casi in cui l’utente non dispone delle autorizzazioni. Per ogni domanda indica risposta attesa e documento che la supporta.
Passo 4: scegli la pipeline minima
Per una prova servono un parser, una strategia di chunking, un modello di embedding, un indice, un retriever e un modello generativo. Strumenti come Open WebUI, AnythingLLM o piattaforme cloud possono ridurre il lavoro iniziale, ma non sostituiscono il disegno delle regole.
Passo 5: rendi obbligatorie le citazioni
La risposta dovrebbe mostrare almeno titolo e collegamento della fonte. Nei contesti più delicati è utile riportare pagina, paragrafo, versione e data del documento. L’utente deve poter verificare rapidamente ciò che legge.
Passo 6: gestisci il “non lo so”
Imposta una soglia minima di rilevanza. Se nessun passaggio la supera, il sistema deve evitare la generazione oppure rispondere che la documentazione disponibile non è sufficiente. Questa è una funzione di qualità, non un difetto.
Passo 7: pianifica aggiornamenti e cancellazioni
Quando un file cambia, l’indice deve rimuovere la versione precedente e inserire quella nuova. Anche la cancellazione deve propagarsi. Conservare chunk orfani di documenti revocati è un problema sia informativo sia di conformità.
Passo 8: prova con un gruppo limitato
Avvia un pilota con dati non critici e utenti consapevoli dei limiti. Registra domande, fonti recuperate, feedback e correzioni. Solo dopo aver stabilizzato retrieval e autorizzazioni conviene estendere la base documentale.
RAG cloud o AI locale?
| Criterio | Cloud | Locale o privato |
|---|---|---|
| Avvio | Generalmente più rapido | Richiede infrastruttura e gestione |
| Scalabilità | Disponibile come servizio | Dipende dalle risorse installate |
| Controllo dei dati | Dipende da contratto e configurazione | Maggiore controllo dell’ambiente |
| Modelli | Ampia scelta di servizi gestiti | Limitati dall’hardware disponibile |
| Costi | A consumo | Investimento e gestione interna |
La scelta non deve essere ideologica. È possibile adottare un’architettura ibrida: documenti e retrieval rimangono nell’ambiente privato, mentre soltanto il contesto autorizzato viene inviato a un modello cloud. Per approfondire, consulta la sezione AI locale.
Sicurezza: il punto più importante
Un RAG può rendere più accessibili documenti che prima erano difficili da trovare. È proprio questa utilità a creare il rischio principale. L’identità dell’utente e le autorizzazioni devono essere applicate a livello di documento o chunk prima del retrieval.
- indicizza soltanto fonti approvate;
- conserva classificazione e ACL nei metadati;
- filtra la ricerca con i permessi effettivi;
- proteggi log, prompt e cronologia delle conversazioni;
- definisci tempi di conservazione e cancellazione;
- separa gli ambienti di test e produzione;
- registra versione dei documenti, modello e configurazione;
- prevedi escalation verso una persona.
Prima di lavorare con dati aziendali, leggi anche le sette regole per usare l’AI in sicurezza.
Come misurare la qualità
Valutare soltanto se la risposta “suona bene” è insufficiente. Retrieval e generazione devono essere misurati separatamente.
- Copertura: il passaggio corretto compare tra i risultati recuperati?
- Precisione: quanti passaggi recuperati sono realmente pertinenti?
- Fedeltà: la risposta è sostenuta dal contesto?
- Completezza: risponde a tutte le parti della domanda?
- Citazioni: portano davvero al testo utilizzato?
- Rifiuto corretto: il sistema evita di inventare quando manca la fonte?
- Prestazioni: latenza e costo sono compatibili con l’utilizzo?
Una risposta sbagliata può dipendere da un recupero errato, da documenti scadenti, dal prompt oppure dal modello. Senza separare queste cause si rischia di cambiare LLM quando il problema è nell’indice.
Errori frequenti da evitare
Caricare documenti senza governance
Duplicati, versioni obsolete e file senza proprietario generano una knowledge base contraddittoria.
Usare soltanto la ricerca vettoriale
La similarità semantica può perdere codici, numeri e termini esatti. Valuta ricerca ibrida e filtri sui metadati.
Recuperare troppi segmenti
Più contesto non significa automaticamente più qualità. Passaggi poco pertinenti aumentano rumore, token, costo e latenza.
Mostrare citazioni decorative
Una fonte è utile soltanto se il collegamento conduce al documento e il passaggio sostiene davvero la risposta.
Considerare il RAG infallibile
Il retrieval riduce alcuni errori, ma non elimina interpretazioni sbagliate, prompt injection nei documenti o uso improprio delle informazioni.
FAQ
Serve necessariamente un database vettoriale?
No. Per raccolte piccole o dati molto strutturati possono bastare ricerca testuale, query SQL o API. Il database vettoriale diventa utile quando serve recuperare passaggi semanticamente simili in molti documenti non strutturati.
Il RAG elimina le allucinazioni?
No. Fornisce informazioni migliori e verificabili, ma il modello può ancora interpretarle male. Citazioni, soglie, test e istruzioni di rifiuto rimangono indispensabili.
Posso usare PDF riservati?
Solo se architettura, fornitore, trattamento dei dati e permessi sono compatibili con le policy applicabili. Il fatto che un file sia accessibile all’amministratore non significa che debba esserlo a ogni utente.
RAG e fine-tuning sono alternativi?
Risolvono problemi diversi. Il RAG aggiunge conoscenze recuperabili e aggiornabili; il fine-tuning modifica il comportamento del modello. Possono essere utilizzati insieme.
Da quanti documenti conviene iniziare?
Da un insieme piccolo ma ben curato. Dieci documenti ufficiali e venti domande verificate insegnano più di migliaia di file caricati senza controllo.
Conclusioni
Il valore del RAG non sta nel collegare una cartella a un chatbot. Nasce dalla qualità delle fonti, dal retrieval, dai permessi, dalle citazioni e da un processo continuo di valutazione. Un buon sistema sa rispondere, ma soprattutto sa mostrare le prove e riconoscere quando non dispone delle informazioni necessarie.
Fonti e approfondimenti
- Paper originale Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
- Microsoft Learn: RAG e indici
- AWS Prescriptive Guidance: architettura RAG
- Google Cloud: panoramica del RAG Engine
Articoli correlati
- Prompt engineering: scrivere istruzioni efficaci
- Open WebUI con Ollama
- Guide sull’AI locale
- AI per aziende e processi
- Software custom, Flow Manager e Doc Composer
Iscriviti alla newsletter di Basi di AI per ricevere guide pratiche su AI locale, strumenti e automazione.
