RAG: come creare un assistente AI basato sui documenti aziendali

Un modello linguistico scrive risposte fluenti, ma non conosce le procedure, i contratti e i manuali della tua azienda: se non sono pubblici non li ha mai visti, e in ogni caso non sa quale versione è in vigore. Collegare un chatbot generico ai processi interni non basta, perché la fluidità del testo non garantisce che il contenuto sia corretto.

La soluzione più diffusa si chiama RAG, Retrieval-Augmented Generation. Prima di rispondere, il sistema cerca nell'archivio documentale i passaggi pertinenti alla domanda e li consegna al modello insieme alla domanda stessa. Il modello compone la risposta a partire da quei passaggi e, se il sistema è costruito bene, indica da quali documenti arrivano.

L'idea non è nuova: l'articolo di ricerca che ha dato il nome alla tecnica, firmato da Patrick Lewis e colleghi, risale al 2020. Parte da un problema che vale ancora oggi: la conoscenza dentro un modello è difficile da aggiornare e da attribuire a una fonte. Una RAG sposta la conoscenza fuori dal modello, in documenti che puoi correggere, sostituire e controllare.

Come funziona, passo per passo

Le fasi sono sempre le stesse, qualunque sia lo strumento scelto:

1. Acquisizione. I documenti (PDF, Word, pagine di wiki, ticket, email archiviate) vengono raccolti da una o più sorgenti, con data, autore e stato: bozza, in vigore, superato.
2. Estrazione del testo. Qui nascono molti errori silenziosi: tabelle spezzate, scansioni senza testo, intestazioni e piè di pagina ripetuti. Un PDF scansionato richiede il riconoscimento ottico dei caratteri prima di poter essere cercato.
3. Suddivisione in porzioni. Il testo viene diviso in passaggi abbastanza piccoli da essere pertinenti e abbastanza grandi da avere senso da soli. Una buona divisione rispetta titoli e paragrafi, non conta i caratteri alla cieca.
4. Indicizzazione. Ogni passaggio viene registrato in un indice. Può essere un indice lessicale (cerca le parole), vettoriale (cerca il significato tramite embedding, rappresentazioni numeriche del testo) o ibrido.
5. Ricerca. Alla domanda dell'utente il sistema recupera i passaggi più rilevanti, spesso applicando un secondo ordinamento per scegliere i migliori.
6. Generazione. Il modello riceve domanda e passaggi, risponde e cita. Se i passaggi non bastano, deve dirlo.

La ricerca ibrida merita attenzione. La ricerca vettoriale trova concetti simili anche con parole diverse, ma può mancare un codice articolo, una sigla o un numero di norma, che la ricerca per parole chiave trova subito. Strumenti diffusi come l'estensione pgvector per PostgreSQL permettono di unire i due approcci e fondere i risultati; la documentazione ufficiale descrive anche la differenza tra ricerca esatta e approssimata, che può dare risultati diversi sulla stessa domanda.

Un esempio concreto

Un'azienda di impianti ha manuali dei costruttori, procedure interne di collaudo e un regolamento per le garanzie. Un tecnico in trasferta chiede: «Quali verifiche prevede il collaudo di questo quadro prima della consegna?». Il sistema recupera la procedura di collaudo in vigore e la sezione del manuale del costruttore che riguarda quel modello, e risponde con un elenco di verifiche, ciascuna con il riferimento al documento e alla sezione.

Il vantaggio non è che «l'AI sa tutto». È che il tecnico non deve aprire quattro archivi e capire quale file è l'ultimo. Se invece nella cartella convivono tre versioni della stessa procedura senza stato, la RAG le recupererà tutte e la risposta potrà mescolarle: il problema è nei documenti, non nel modello.

Dove una RAG sbaglia

La RAG aiuta a ridurre le risposte inventate, ma non le elimina. Gli errori tipici sono tre:

• Recupero sbagliato. Il passaggio giusto esiste ma non viene trovato, e il modello risponde con ciò che ha ricevuto.
• Lettura sbagliata. I passaggi giusti ci sono, ma il modello li interpreta male, ne ignora uno o trae una conclusione che le fonti non sostengono.
• Fonti incomplete o superate. Il sistema risponde con coerenza a partire da un documento che non è più valido.

Le contromisure sono pratiche. Pretendi citazioni che l'utente possa aprire e controllare. Prevedi una risposta esplicita del tipo «nei documenti non trovo informazioni sufficienti» e verifica che il sistema la usi davvero. Misura la qualità su un insieme di domande reali, con la risposta attesa e il documento corretto, e ripetila a ogni modifica di documenti, indice o modello.

Permessi e documenti riservati

In azienda non tutti possono leggere tutto: buste paga, contratti con i clienti, verbali, offerte. Una RAG deve rispettare gli stessi permessi dei sistemi di origine. Nascondere i documenti nell'interfaccia non è sufficiente: il filtro deve agire nella fase di recupero, prima che i passaggi arrivino al modello. Se un passaggio riservato entra nel contesto, può finire nella risposta, anche in forma riassunta.

L'OWASP, nella sua lista dei rischi per le applicazioni basate su modelli linguistici (edizione 2025), dedica una voce alle debolezze di vettori ed embedding e indica indici consapevoli dei permessi e separazione logica dei dati tra gruppi di utenti. Vale la regola pratica: se più reparti o più clienti condividono lo stesso indice, la separazione va progettata e provata, non data per scontata.

Servono anche altre scelte: chi può aggiungere documenti all'indice, quanto a lungo si conservano le domande degli utenti, se i dati lasciano l'azienda. Per quest'ultimo punto è utile il confronto in AI locale o cloud per le aziende. Se i documenti contengono dati personali, il trattamento rientra negli obblighi di protezione dei dati, e il quadro europeo sull'uso dell'AI lo trovi in AI Act: gli obblighi per le aziende. Per le valutazioni legali rivolgiti a un consulente.

Criteri per capire se la RAG fa per te

Prima di avviare un progetto, verifica questi punti:

• I documenti esistono e sono in ordine. Hanno un responsabile, una versione in vigore e un archivio unico, non cartelle personali.
• Le domande sono ricorrenti. Se le stesse domande ritornano ogni settimana, l'investimento si ripaga; se ogni caso è unico, conviene altro.
• Il costo di un errore è chiaro. Per una procedura interna una risposta sbagliata si corregge; per un parere contrattuale va sempre rivista da una persona.
• Esiste un insieme di domande di prova. Senza, non puoi dire se una modifica migliora o peggiora il sistema.
• I permessi sono mappati. Sai chi può vedere cosa, e puoi riprodurlo nell'indice.

Il passo successivo

Il punto di partenza utile è piccolo: un'area (per esempio le procedure di assistenza o i manuali di un prodotto), venti-trenta domande reali e un elenco dei documenti che le coprono. Da lì si capisce quanto lavoro serva sui documenti prima ancora che sul software.

Se vuoi valutare un assistente sui tuoi documenti, descrivi l'area, le fonti e le regole di accesso nella richiesta guidata per un progetto AI: partiamo da quei dati per un preventivo. Trovi il quadro dei nostri lavori su sistemi AI.

Riferimenti: Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, OWASP LLM08:2025 Vector and Embedding Weaknesses, documentazione pgvector.