LLM e documenti aziendali: costruire un sistema RAG che funziona davvero

I Large Language Model hanno cambiato il modo in cui interroghiamo le informazioni, ma hanno un limite strutturale che in azienda diventa un problema concreto: la loro conoscenza si ferma alla data di addestramento e non include i tuoi dati interni. Per quanto sofisticato, un modello semplicemente non sa nulla di ciò che non ha visto durante il training. Se vuoi che risponda sui tuoi manuali, sulle tue procedure o sui tuoi contratti, devi trovargli un modo per leggerli.

La tecnica che risolve questo problema si chiama Retrieval-Augmented Generation, RAG per gli amici. L'idea è semplice e potente: invece di riaddestrare un modello con i tuoi dati, cosa costosa e tecnicamente complessa, recuperi al volo i frammenti di documento più rilevanti e li inserisci nel contesto della richiesta. Così il modello genera la risposta partendo da informazioni reali e aggiornate, non da quello che ricorda vagamente del suo addestramento.

Quando spiego questo in aula uso sempre la stessa immagine: il RAG è come dare a uno studente bravissimo, ma che non ha studiato il tuo programma, la possibilità di consultare i tuoi appunti durante l'esame. La testa ce l'ha già, i dati glieli passi tu. In questa guida smontiamo il meccanismo pezzo per pezzo: ogni componente dell'architettura, le tecnologie tra cui scegliere e, soprattutto, gli errori che fanno naufragare la maggior parte dei progetti aziendali. Non un tutorial generico, ma una bussola per chi sta valutando o già costruendo un sistema del genere.

01La promessa del RAG aziendale

Ogni organizzazione accumula nel tempo un patrimonio informativo enorme: manuali operativi, contratti, normative interne, report tecnici, verbali, FAQ, documentazione di prodotto. Queste informazioni vivono in sistemi diversi e scollegati, file server, SharePoint, CRM, wiki interni, e trovarle in fretta è spesso una piccola odissea quotidiana. Secondo una stima di McKinsey, i dipendenti spendono fino al 20% del loro tempo lavorativo a cercare informazioni interne. Un giorno alla settimana, in pratica, passato a frugare nei documenti.

Il RAG promette di trasformare questa massa documentale in una base di conoscenza interrogabile in linguaggio naturale. Un operatore del servizio clienti chiede "Qual è la procedura di reso per i prodotti personalizzati?" e ottiene una risposta precisa, estratta dai documenti interni, con il riferimento alla fonte. Un tecnico domanda "Quali sono i parametri di manutenzione del macchinario X dopo 5000 ore?" e riceve le specifiche esatte dal manuale originale. Niente più cartelle condivise, niente più "chiedi a Mario che se ne intende".

Il RAG non sostituisce la conoscenza aziendale: la rende accessibile. Trasforma documenti statici in conversazioni, senza perdere il legame con la fonte originale.

La promessa è reale, ma mantenerla richiede attenzione. Un sistema RAG mal progettato non si limita a non trovare le risposte giuste: genera risposte plausibili ma sbagliate, le famose hallucination, che in azienda possono avere conseguenze serie. Per questo capire l'architettura sottostante e i suoi punti deboli non è un vezzo da nerd, ma una necessità operativa. Vediamola.

02Come funziona, in tre fasi

Un sistema RAG lavora attraverso un flusso in tre fasi ben distinte. Capire questa architettura serve a diagnosticare i problemi quando qualcosa non va, e ti assicuro che qualcosa non va sempre, almeno all'inizio. Le tre fasi sono nascoste dentro l'acronimo stesso.

R come Retrieve

La domanda dell'utente viene trasformata in un vettore numerico, un embedding, e confrontata con i vettori dei frammenti documentali archiviati nel database vettoriale. Il sistema recupera i frammenti più "vicini", cioè quelli semanticamente più simili alla domanda.

A come Augment

I frammenti recuperati vengono inseriti nel prompt insieme alla domanda originale. In questo modo arricchisci il contesto del modello con informazioni specifiche e aggiornate, prese dai tuoi documenti e non dalla sua memoria.

G come Generate

Il modello genera la risposta usando sia le proprie capacità linguistiche sia il contesto che gli hai fornito. Il risultato è una risposta in linguaggio naturale, fondata sui documenti reali dell'organizzazione.

Tutto questo avviene a runtime, quando l'utente fa una domanda. Ma c'è una fase a monte che è quella che spesso decide il destino del progetto: la preparazione. I documenti vengono prima estratti dai loro formati originali (PDF, Word, HTML), poi suddivisi in frammenti, infine trasformati in vettori e archiviati. Questa pipeline di ingestione è la parte più sottovalutata e, allo stesso tempo, quella che determina in larga misura la qualità delle risposte finali.

Tieni a mente una cosa: la qualità del risultato dipende dall'interazione di tutti i componenti. Se il retrieval recupera frammenti irrilevanti, nessun modello, per quanto potente, ci salverà. E al contrario, se il retrieval è preciso ma il prompt è costruito male, il modello potrebbe ignorare le informazioni che gli hai passato. È una catena, e si sa cosa succede alle catene.

03Scegliere il modello di embedding

Il modello di embedding è il cuore semantico del sistema. Il suo compito è tradurre il testo in vettori numerici in modo che frammenti con significato simile finiscano vicini nello spazio vettoriale. La qualità di questa traduzione determina direttamente la qualità del retrieval: se il modello non coglie le sfumature dei tuoi documenti, recupererai frammenti fuori tema o ti perderai quelli giusti.

La scelta dipende da diversi fattori: la lingua dei documenti, il dominio specifico, i requisiti di privacy, la latenza accettabile e il budget. Oggi esistono ottime opzioni sia proprietarie sia open source, ciascuna con i suoi punti di forza. Te le metto in fila, con il caso d'uso in cui rendono di più.

C'e un aspetto che molti trascurano: la scelta dell'embedding deve essere coerente con la lingua e il dominio dei tuoi documenti. Un modello addestrato soprattutto su testi in inglese renderà meno su documentazione tecnica in italiano. Per i progetti in italiano consiglio sempre di valutare modelli con supporto multilingue esplicito e di fare benchmark sul proprio corpus reale prima di decidere. Le classifiche pubbliche sono un punto di partenza, non una sentenza.

04Tagliare bene i documenti: il chunking

Il chunking, cioè la suddivisione dei documenti in frammenti, è probabilmente la decisione architetturale con il maggiore impatto sulla qualità del sistema. Ed è, paradossalmente, quella a cui si dedica meno attenzione. Un chunk troppo piccolo perde il contesto necessario a capire; un chunk troppo grande diluisce l'informazione utile in mezzo al rumore, abbassa la precisione del retrieval e spreca preziosi token nella finestra di contesto del modello.

Esistono diverse strategie, ognuna con i suoi pregi e i suoi limiti. La scelta dipende dalla natura dei documenti, dalla loro struttura e dal tipo di domande che gli utenti faranno.

A dimensione fissa

La più semplice: il testo viene diviso in blocchi di N caratteri o token, con un overlap configurabile tra blocchi consecutivi. Facile da implementare, prevedibile, funziona ragionevolmente su testi omogenei e non strutturati. Il difetto è che taglia in punti arbitrari, spezzando frasi o concetti a metà.

Semantico

Usa lo stesso modello di embedding per trovare i punti di rottura naturali nel testo: calcola la similarità tra frasi consecutive e taglia quando la distanza semantica supera una soglia. Produce frammenti più coerenti dal punto di vista del significato, ma è più lento e meno prevedibile nella dimensione.

Ricorsivo per struttura

Sfrutta la struttura del documento (titoli, sottotitoli, paragrafi, elenchi) per creare chunk che rispettano l'organizzazione logica del testo. Se un paragrafo supera la dimensione massima, viene suddiviso ulteriormente con separatori di livello inferiore. È la strategia migliore per documenti ben strutturati: manuali tecnici, normative, procedure operative.

Qualunque strada tu scelga, ci sono quattro accortezze che ripeto come un mantra a chi parte con un progetto del genere.

1. Analizza i documenti veri. Prima di scegliere una strategia, guarda i tuoi documenti reali. Sono ben formattati con titoli e sezioni? Sono blocchi di testo continuo? Contengono tabelle e immagini?
2. Definisci la dimensione target. Per la maggior parte dei casi aziendali, chunk tra 512 e 1024 token offrono il miglior compromesso. Prevedi un overlap del 10-15% tra frammenti consecutivi.
3. Conserva i metadati. Ogni chunk deve portarsi dietro la sua provenienza: nome del documento, sezione, pagina, data di ultimo aggiornamento. Servono per filtrare e per citare le fonti.
4. Testa e itera. Non esiste una dimensione ottimale universale. Prova diverse configurazioni sul tuo corpus e misura la qualità del retrieval con il benchmark che hai costruito al passo precedente.

Il chunking è l'arte di tagliare un libro in modo che ogni pezzo abbia ancora senso da solo. Se tagli nel punto sbagliato, anche il miglior lettore non capirà cosa stai dicendo.

05Dove vivono i vettori: il database

Il database vettoriale è il componente che rende possibile la ricerca per similarità semantica. A differenza di un database relazionale, che cerca corrispondenze esatte tra valori, un vector database confronta vettori numerici e restituisce quelli più vicini al vettore della domanda, usando metriche come la cosine similarity. Così trova frammenti semanticamente simili anche quando non condividono nessuna parola esatta: è qui che sta tutta la magia, e non è affatto magia, è geometria.

Il mercato di questi strumenti è cresciuto in fretta negli ultimi due anni, dal database leggero per i prototipi al servizio cloud gestito per la produzione enterprise. La scelta dipende dal volume dei dati, dai requisiti di latenza, dal bisogno di filtrare per metadati e dalla preferenza tra on-premise e cloud.

Per la maggior parte dei progetti aziendali di dimensione media, fino a qualche milione di documenti, Qdrant è un ottimo compromesso tra funzionalità, prestazioni e costo. Lo esegui on-premise se hai vincoli di compliance, offre filtraggio avanzato per metadati (essenziale per separare i documenti per reparto, data o livello di accesso) e scala bene quando il corpus cresce.

Per i prototipi e le fasi esplorative, ChromaDB resta la scelta più pragmatica: poche righe di codice e hai un sistema funzionante. Per chi preferisce un servizio completamente gestito e non ha vincoli sulla residenza dei dati, Pinecone toglie di mezzo la complessità operativa, in cambio di un costo ricorrente.

06I cinque errori più comuni

Nei progetti RAG che ho visto, in aziende italiane ed europee, gli errori che fanno fallire le cose tendono a ripetersi sempre gli stessi cinque. La buona notizia è che sono tutti evitabili con un po' di attenzione progettuale. Te li elenco in ordine di frequenza, non di gravità.

Errore 1: documenti di bassa qualità

Il vecchio principio "garbage in, garbage out" vale qui più che mai. PDF scansionati con OCR scadente, formattazioni incoerenti, informazioni obsolete mai rimosse, duplicati non gestiti: tutto questo produce chunk di pessima qualità che avvelenano l'intero sistema. Prima di qualsiasi lavoro tecnico serve un lavoro di pulizia documentale: validare l'OCR, normalizzare i formati, eliminare le versioni superate, deduplicare i contenuti. Noioso, ma decisivo.

Errore 2: chunk dimensionati a caso

Molti progetti adottano dimensioni arbitrarie senza testare alternative. Chunk da 200 token vanno bene per FAQ brevi ma falliscono su documenti normativi, dove un concetto si sviluppa su più paragrafi. Al contrario, chunk da 2000 token recuperano troppo contesto irrilevante, confondono il modello e sprecano la finestra di contesto. La dimensione giusta dipende dal tipo di documento e dalle domande attese, e va calibrata empiricamente, non a intuito.

Errore 3: niente re-ranking

La ricerca per similarità vettoriale è veloce ma approssimativa. I primi venti risultati del retrieval mescolano spesso frammenti rilevanti e frammenti marginali. Un modello di re-ranking (come Cohere Rerank o un cross-encoder) riordina questi risultati con un'analisi più approfondita della relazione tra domanda e frammento, alzando di parecchio la precisione. Saltare questo passaggio è come cercare un libro in una biblioteca ordinata solo all'incirca per argomento.

Errore 4: risposte senza validazione

Molti sistemi generano risposte senza alcun controllo. Il modello può ignorare i frammenti forniti e rispondere dalla propria memoria, combinare informazioni da frammenti incompatibili, o inventare dettagli per coprire le lacune. Senza un meccanismo di validazione, di cui parlo tra poco, queste risposte sbagliate arrivano all'utente con la stessa sicurezza di quelle giuste. Ed è lì che il sistema perde credibilità.

Errore 5: metadati ignorati

I frammenti vengono spesso archiviati come puro testo, senza informazioni su provenienza, data, versione o ambito. Così diventa impossibile filtrare per reparto, escludere documenti obsoleti o citare la fonte esatta nella risposta. I metadati non sono un accessorio: sono parte essenziale della qualità e dell'affidabilità del sistema.

07Validare le risposte

La validazione è ciò che separa un prototipo da un sistema affidabile in produzione. In azienda una risposta sbagliata presentata con sicurezza può costare cara: un operatore che segue una procedura errata, un commerciale che cita condizioni contrattuali inesistenti, un tecnico che applica parametri di manutenzione sbagliati. Per questo ogni sistema RAG serio deve avere meccanismi di verifica su più livelli.

1. Verifica di grounding. Controllare che ogni affermazione nella risposta sia davvero supportata da uno dei frammenti recuperati. Si fa con un secondo passaggio del modello che analizza la risposta frase per frase, oppure con tecniche di NLI (Natural Language Inference).
2. Citazione delle fonti. Ogni risposta deve indicare da quali documenti e sezioni vengono le informazioni. Permette all'utente di verificare da solo e fa crescere la fiducia nel sistema.
3. Confidence scoring. Assegnare un punteggio di confidenza alla risposta, basato sulla rilevanza dei frammenti, sulla coerenza interna e sulla copertura della domanda. Le risposte sotto una soglia definita vengono segnalate o bloccate.
4. Risposta "non lo so". Il sistema deve poter dichiarare esplicitamente quando non ha informazioni sufficienti, invece di inventare una risposta plausibile. Si configura tramite il prompt di sistema e la soglia di rilevanza del retrieval.
5. Feedback loop. Raccogliere il feedback degli utenti (risposta utile, non utile, errata) e usarlo per migliorare il sistema nel tempo, raffinando chunking ed embedding o aggiornando il corpus.

Un approccio che funziona bene è il pattern "guardrail": un secondo modello, più piccolo e veloce, che esamina la risposta prima di mostrarla all'utente. Verifica che sia coerente con i frammenti forniti, che non contenga informazioni non supportate e che risponda davvero alla domanda. Se la verifica fallisce, il sistema riprova con una strategia di retrieval diversa oppure restituisce un messaggio di cortesia.

L'altra tecnica fondamentale e la valutazione sistematica con metriche automatiche. Framework come RAGAS (Retrieval Augmented Generation Assessment) misurano la fedeltà della risposta ai frammenti, la rilevanza dei frammenti rispetto alla domanda e la completezza della risposta. Sono numeri da monitorare nel tempo, per accorgersi delle regressioni e capire dove intervenire.

08Un caso pratico reale

Per rendere concreti questi concetti, ti racconto un caso reale: un'azienda manifatturiera toscana con circa 200 dipendenti. Aveva oltre 3.000 documenti tecnici, manuali macchina, schede di manutenzione, procedure di sicurezza, specifiche di prodotto, sparsi tra un file server, un gestionale proprietario e una collezione di cartelle condivise. I tecnici impiegavano in media 25 minuti per trovare un'informazione, con errori frequenti dovuti a documenti obsoleti mai rimossi.

La prima fase del progetto e stata dedicata alla pulizia documentale: identificare e rimuovere 400 documenti duplicati o obsoleti, migliorare l'OCR di 180 PDF scansionati, normalizzare i formati. Un lavoro durato tre settimane che si è rivelato l'investimento con il ritorno più alto dell'intero progetto. Lo dico sempre: la parte meno glamour è quella che decide tutto.

Per la pipeline di ingestione abbiamo scelto un chunking ricorsivo per struttura, dimensione target di 768 token e overlap del 12%. I metadati includevano tipo di documento, codice macchina, data di revisione e reparto di competenza. Come modello di embedding è stato selezionato BGE-M3, per l'ottima gestione dell'italiano tecnico e la possibilità di girare on-premise, requisito imposto dalla policy aziendale sui dati sensibili. L'infrastruttura vettoriale è stata costruita con Qdrant su un server interno.

Il retrieval usa un approccio ibrido: ricerca vettoriale combinata con keyword search (BM25), seguita da re-ranking con un cross-encoder. Le risposte vengono generate da un modello Claude, con un prompt di sistema che impone la citazione delle fonti e la dichiarazione esplicita di incertezza. Un sistema di feedback integrato nell'interfaccia permette ai tecnici di segnalare risposte errate o incomplete.

Il risultato, dopo tre mesi di utilizzo: il tempo medio per trovare un'informazione tecnica è sceso da 25 minuti a meno di 2 minuti. L'accuratezza delle risposte, misurata su un campione casuale di 200 domande, si attesta al 92%, con il sistema che dichiara "informazione non disponibile" nel 5% dei casi e produce risposte parzialmente imprecise nel restante 3%. E il feedback degli utenti è stato decisivo per correggere problemi di chunking su certe categorie di documenti e per aggiornare il corpus con le informazioni mancanti.

09Glossario essenziale

Se ti avvicini per la prima volta a questo mondo, qualche termine può suonare ostico. Ecco le definizioni rapide dei concetti chiave che ho usato, da tenere a portata come riferimento.

Il campo del RAG si muove in fretta: nuove tecniche, modelli e strumenti emergono di continuo. Per restare aggiornato, il paper fondativo di Lewis e colleghi del 2020 resta il punto di partenza, le documentazioni di LangChain e LlamaIndex sono ottime per la pratica, la MTEB Leaderboard aiuta a confrontare gli embedding e RAGAS serve a valutare la qualità. Ma il consiglio più onesto che posso darti è quello che ripeto in ogni corso: non fermarti a sapere che esiste, prova a costruirne uno piccolo sui tuoi dati. È là dentro, smontando la scatola un pezzo alla volta, che si capisce davvero come funziona.