RAG: come funziona un assistente AI sui documenti aziendali

Un assistente AI che risponde sui documenti della vostra azienda, citando la pagina da cui ha preso l’informazione, è oggi uno dei progetti di intelligenza artificiale più richiesti e più concreti. La tecnica che lo rende possibile si chiama RAG. Questa guida la spiega prima in modo semplice, poi con il dettaglio che serve al reparto IT per valutarla e progettarla.

RAG cos’è, in parole semplici

RAG sta per Retrieval-Augmented Generation, «generazione aumentata dal recupero». Il termine viene da un articolo di ricerca del 2020 che proponeva di affiancare a un modello linguistico un sistema di ricerca su una base di testi esterna.

L’idea si capisce bene con un esame a libro aperto. Un modello linguistico da solo risponde a memoria: sa molte cose in generale, ma nulla dei vostri contratti, manuali o procedure, e non sa dire da dove viene ciò che afferma. Con la RAG, a ogni domanda il sistema apre il «libro» giusto: cerca nei vostri documenti i passaggi pertinenti, li consegna al modello e gli chiede di rispondere solo su quella base, indicando le fonti.

Tre conseguenze pratiche:

• i documenti non vengono «insegnati» al modello: restano nel vostro archivio e si aggiornano senza riaddestrare nulla;
• ogni risposta è verificabile, perché porta con sé i riferimenti ai passaggi usati;
• si possono rispettare i permessi: chi non può aprire un documento non deve ricevere risposte basate su quel documento.

Perché non basta un chatbot generico

Un chatbot generico, anche ottimo, non conosce i vostri documenti interni, può avere informazioni superate e tende a rispondere comunque, anche quando non sa. Caricare a mano i file in una chat funziona per un documento alla volta, ma non scala a migliaia di file, non gestisce chi può vedere cosa e non lascia traccia di quali fonti sono state usate. Un chatbot sui documenti interni costruito con la RAG risolve questi tre problemi in modo strutturato.

Per il reparto IT: come funziona una RAG, fase per fase

Indicizzazione e conversione dei documenti

Si parte da PDF, documenti Office, pagine intranet, ticket, email. Ogni formato va convertito in testo pulito: OCR per le scansioni, estrazione delle tabelle mantenendone la struttura, rimozione di intestazioni e piè di pagina ripetuti. A ogni documento si associano metadati: titolo, data, versione, reparto, livello di riservatezza, gruppi autorizzati. Questa fase è poco visibile, ma determina buona parte della qualità finale.

Chunking

I documenti vengono divisi in frammenti (chunk), di solito di qualche centinaio di token: abbastanza lunghi da contenere un’informazione completa, abbastanza brevi da essere pertinenti. Conviene tagliare seguendo la struttura (titoli, articoli, paragrafi) e aggiungere a ogni frammento un minimo di contesto: di quale documento fa parte e di quale sezione.

Embedding

Ogni frammento viene trasformato in un embedding, cioè una sequenza di numeri che rappresenta il significato del testo. Testi con significato simile producono vettori vicini, anche se usano parole diverse. Gli embedding vengono salvati in un database vettoriale o in un motore di ricerca che li supporta.

Ricerca ibrida

Alla domanda dell’utente si applicano due ricerche in parallelo: quella semantica sugli embedding, che trova i concetti, e quella per parole chiave (tipicamente con l’algoritmo BM25), che trova i termini esatti, come codici, numeri di articolo e nomi di prodotto. La ricerca semantica da sola tende a perdere proprio queste corrispondenze esatte, che nei documenti aziendali contano molto.

Riordino

I candidati trovati, da qualche decina a qualche centinaio, passano a un modello di riordino (reranker) che valuta con più precisione quanto ciascuno risponde alla domanda e tiene solo i migliori. In un test pubblicato da Anthropic, la combinazione di embedding e BM25, entrambi con un breve contesto aggiunto a ogni frammento, più il riordino, ha ridotto del 67% i casi in cui il passaggio giusto non compariva tra i primi 20 recuperati, rispetto alla configurazione di partenza. Sono risultati sui dati di prova di quel fornitore: sui vostri documenti vanno misurati, come vediamo più avanti.

Generazione con citazioni

I passaggi selezionati vengono inseriti nel prompt (le istruzioni e il contesto passati al modello) insieme alla domanda. Le istruzioni chiedono di rispondere solo sulla base dei passaggi forniti, di citare per ciascuna affermazione la fonte e di dichiarare quando l’informazione non è presente. L’interfaccia mostra poi le citazioni come collegamenti al documento e alla pagina.

Permessi per utente e ruolo

Il filtro sui permessi va applicato nella fase di ricerca, usando i metadati e l’identità dell’utente, non affidato al modello. È lo stesso principio che Microsoft descrive per Copilot, che mostra solo dati a cui il singolo utente ha almeno accesso in lettura. OWASP inserisce tra i rischi principali delle applicazioni con modelli linguistici proprio le fughe di informazioni tra utenti in archivi vettoriali condivisi.

Aggiornamento

L’indice deve seguire l’archivio: documenti nuovi, modificati, ritirati. Serve un processo automatico che reindicizzi le modifiche, rimuova ciò che è stato eliminato e aggiorni i permessi quando cambiano.

Come si valuta un assistente RAG

Senza misure, ogni modifica è un’opinione. Il metodo che usiamo è semplice:

1. un set di domande di prova scritte con chi usa i documenti ogni giorno, con la risposta attesa e il documento che la contiene, incluse domande a cui l’archivio non sa rispondere;
2. metriche sul recupero: il passaggio giusto è tra quelli trovati?
3. metriche sulla risposta: è fedele ai passaggi, cioè ogni affermazione è supportata da una fonte? È completa?
4. correttezza delle citazioni: la fonte citata dice davvero ciò che la risposta le attribuisce?
5. rifiuti corretti: quando l’informazione manca, l’assistente lo dice invece di inventare?

Strumenti open source come Ragas offrono metriche già pronte (fedeltà, pertinenza, precisione e richiamo del contesto), che vanno comunque affiancate da una revisione umana a campione. Il set di prova si riesegue a ogni cambio di modello, di chunking o di prompt.

Cosa può andare storto

• Documenti scansionati con OCR scadente: numeri letti male, testo spezzato.
• Tabelle appiattite in testo, che perdono il legame fra righe e colonne.
• Versioni vecchie nello stesso archivio delle nuove: il sistema trova entrambe e risponde con quella sbagliata. Servono metadati di validità e la rimozione degli obsoleti.
• Allucinazioni residue: il modello completa con conoscenze proprie o interpreta male un passaggio. Si contengono con istruzioni rigorose, citazioni e valutazione continua.
• Domande fuori perimetro, a cui l’archivio non risponde: l’assistente deve saperlo dire.
• Permessi trascurati, il rischio più serio, perché espone informazioni riservate a chi non dovrebbe vederle.

RAG, fine-tuning o documenti allegati al prompt

Una nota onesta: se i documenti sono pochi e stabili, la RAG può essere superflua. Anthropic, per esempio, indica che sotto i 200.000 token circa, nell’ordine delle 500 pagine, si può passare l’intera base documentale nel prompt, con la memorizzazione in cache delle parti ripetute che riduce costi e tempi. La RAG diventa necessaria quando l’archivio cresce, cambia spesso o richiede permessi diversi per utente.

Cloud con dati in Europa o on-premise

Le opzioni principali sono due.

• Modelli in cloud dei grandi fornitori, tramite API o piattaforme cloud con regioni europee, con contratti che escludono l’uso dei dati per l’addestramento, accordi di trattamento ai sensi del GDPR e, dove disponibile, residenza dei dati in Europa. È la strada più rapida e dà accesso ai modelli più capaci. I dettagli contrattuali vanno verificati fornitore per fornitore, come spieghiamo in ChatGPT in azienda e GDPR.
• Modelli open-weight on-premise, cioè modelli con i pesi scaricabili, eseguiti su server propri o in un data center scelto dall’azienda. I documenti non escono mai dal perimetro, ma servono hardware con GPU adeguate, competenze di gestione e test più accurati, perché i modelli eseguibili in locale sono in genere meno capaci dei migliori in cloud.

Esistono soluzioni intermedie: per esempio indice ed embedding in casa e solo la generazione in cloud, oppure un modello locale per i documenti più riservati e uno in cloud per il resto. Scegliere la combinazione giusta e collegarla ai sistemi esistenti è il cuore dei progetti di integrazione dei modelli linguistici.

Da cosa dipendono i costi

Non esiste un prezzo standard, ma le voci sono sempre le stesse:

• preparazione dei documenti: conversione, OCR, pulizia, metadati, spesso la parte più laboriosa;
• calcolo degli embedding: una tantum sull’archivio, poi solo sulle modifiche;
• infrastruttura di ricerca: database vettoriale o motore di ricerca, ospitato o gestito;
• consumo del modello: proporzionale al numero di domande e alla quantità di testo inviata a ogni domanda, in cui i passaggi recuperati pesano più della domanda stessa;
• riordino, se affidato a un servizio esterno;
• integrazione: accesso con le credenziali aziendali, permessi, interfaccia, collegamento agli archivi;
• valutazione e manutenzione: aggiornamento del set di prova, monitoraggio, revisioni periodiche.

Nell’infrastruttura on-premise si aggiungono hardware, energia e gestione dei server, a fronte di un consumo per singola domanda non più legato al listino di un fornitore.

Se state valutando un assistente sui vostri documenti, il primo passo utile è un inventario: quali archivi, in che formato, con quali permessi, per quali domande. È il punto da cui partiamo nei progetti di assistenti documentali; quando l’assistente deve anche agire, per esempio aprire un ticket o compilare una pratica, si entra nel campo degli agenti AI. Per un esempio di applicazione in uno studio professionale, vedete la nostra guida sull’intelligenza artificiale per commercialisti.

Domande frequenti