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

Introduzione

I Large Language Model hanno rivoluzionato il modo in cui interagiamo con le informazioni, ma presentano un limite strutturale: la loro conoscenza si ferma alla data di addestramento e non include i dati interni di un'organizzazione. Per un'azienda che vuole interrogare i propri manuali, contratti, procedure interne e documenti tecnici, questo limite rappresenta un ostacolo concreto. Il modello, per quanto sofisticato, semplicemente non sa nulla di ciò che non ha visto durante il training.

La tecnica nota come Retrieval-Augmented Generation (RAG) nasce esattamente per risolvere questo problema. Invece di riaddestrare un modello con i propri dati — un processo costoso e tecnicamente complesso — il RAG permette di recuperare i frammenti di documento più rilevanti e inserirli nel contesto della richiesta, in modo che il modello possa generare risposte fondate su informazioni reali e aggiornate.

Questa guida affronta il tema in modo pratico e completo. Analizzeremo ogni componente dell'architettura RAG, confronteremo le tecnologie disponibili e, soprattutto, identificheremo i cinque errori che fanno fallire la maggior parte dei progetti aziendali di questo tipo. L'obiettivo non è fornire un tutorial generico, ma offrire una bussola concreta per chi sta valutando o già implementando un sistema RAG nella propria organizzazione.

La 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 risiedono tipicamente in sistemi eterogenei — file server, SharePoint, CRM, wiki interni — e trovarle rapidamente è spesso un problema reale. I dipendenti spendono, secondo le stime di McKinsey, fino al 20% del loro tempo lavorativo cercando informazioni interne.

Il RAG promette di trasformare questa massa documentale in una base di conoscenza interrogabile in linguaggio naturale. Un operatore del servizio clienti potrebbe chiedere "Qual è la procedura di reso per i prodotti personalizzati?" e ottenere una risposta precisa estratta dai documenti interni, completa di riferimento alla fonte. Un tecnico potrebbe domandare "Quali sono i parametri di manutenzione del macchinario X dopo 5000 ore?" e ricevere le specifiche esatte dal manuale originale.

La promessa è concreta e reale, ma mantenerla richiede attenzione ingegneristica. Un sistema RAG mal progettato non solo fallisce nel trovare le risposte giuste, ma può generare risposte plausibili ma errate — le cosiddette hallucination — con conseguenze potenzialmente gravi in ambito aziendale. Per questo motivo, comprendere l'architettura sottostante e i punti critici non è un lusso tecnico, ma una necessità operativa.

Architettura di un sistema RAG

Un sistema RAG funziona attraverso un flusso in tre fasi ben distinte. Comprendere questa architettura è fondamentale per diagnosticare i problemi e ottimizzare le prestazioni. Ogni fase ha le sue criticità e le sue leve di miglioramento.

La fase di preparazione avviene a monte: i documenti aziendali vengono prima estratti dai loro formati originali (PDF, Word, HTML, ecc.), poi suddivisi in frammenti (chunk), infine trasformati in vettori numerici tramite un modello di embedding e archiviati in un database vettoriale. Questa pipeline di ingestione è spesso la parte più sottovalutata del processo, ma determina in larga misura la qualità delle risposte finali.

A runtime, quando l'utente pone una domanda, il sistema esegue il flusso Retrieve-Augment-Generate descritto sopra. La qualità del risultato dipende dall'interazione di ogni componente: se il retrieval recupera frammenti irrilevanti, nessun modello linguistico, per quanto potente, potrà generare una risposta corretta. Al contrario, se il retrieval è preciso ma il prompt è mal costruito, il modello potrebbe ignorare le informazioni fornite.

• Document loader: estrae il testo dai formati originali (PDF, DOCX, HTML, Markdown)
• Chunker: divide il testo in frammenti di dimensione gestibile
• Embedding model: trasforma ogni frammento in un vettore numerico denso
• Vector store: archivia e indicizza i vettori per la ricerca per similarità
• Retriever: trova i frammenti più rilevanti rispetto alla query
• LLM: genera la risposta finale integrando i frammenti nel contesto

Scelta degli embedding

Il modello di embedding è il cuore semantico di un sistema RAG. Il suo compito è tradurre testo in vettori numerici in modo tale 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 cattura le sfumature semantiche dei documenti aziendali, il sistema recupererà frammenti irrilevanti o mancherà quelli più pertinenti.

La scelta del modello di embedding dipende da diversi fattori: la lingua dei documenti, il dominio specifico, i requisiti di privacy, la latenza accettabile e il budget. Oggi esistono eccellenti opzioni sia proprietarie sia open source, ciascuna con i propri punti di forza.

Un aspetto spesso trascurato è che la scelta dell'embedding deve essere coerente con la lingua e il dominio dei documenti. Un modello addestrato prevalentemente su testi in inglese avrà prestazioni inferiori su documentazione tecnica in italiano. Per questo motivo, per progetti RAG in lingua italiana, consigliamo di valutare sempre modelli con supporto multilingue esplicito e di effettuare benchmark specifici sul proprio corpus documentale prima di prendere una decisione definitiva.

Strategie di chunking

Il chunking — la suddivisione dei documenti in frammenti — è probabilmente la decisione architetturale che ha il maggiore impatto sulla qualità di un sistema RAG e, paradossalmente, quella a cui si dedica meno attenzione. Un chunk troppo piccolo perde il contesto necessario alla comprensione; un chunk troppo grande diluisce l'informazione rilevante con rumore, riducendo la precisione del retrieval e sprecando preziosi token nella finestra di contesto del modello.

Esistono diverse strategie di chunking, ciascuna con vantaggi e limitazioni specifiche. La scelta dipende dalla natura dei documenti, dalla loro struttura e dal tipo di domande che gli utenti porranno al sistema.

Chunking a dimensione fissa

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

Chunking semantico

Utilizza il modello di embedding stesso per individuare i punti di rottura naturali nel testo. Calcola la similarità tra frasi consecutive e inserisce un taglio quando la distanza semantica supera una soglia. Produce chunk più coerenti dal punto di vista del significato, ma è più lento e meno prevedibile nella dimensione dei frammenti risultanti.

Chunking 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 ulteriormente suddiviso usando separatori di livello inferiore. È la strategia migliore per documenti ben strutturati come manuali tecnici, normative e procedure operative.

1. 1Analizzate la struttura dei documenti: prima di scegliere una strategia, esaminate i vostri documenti reali. Sono ben formattati con titoli e sezioni? Sono blocchi di testo continuo? Contengono tabelle e immagini?
2. 2Definite la dimensione target: per la maggior parte dei casi aziendali, chunk tra 512 e 1024 token offrono il miglior compromesso. Prevedete un overlap del 10-15% tra chunk consecutivi.
3. 3Preservate i metadati: ogni chunk deve portare con sé informazioni sulla sua provenienza: nome del documento, sezione, pagina, data di ultimo aggiornamento. Questi metadati sono fondamentali per il filtraggio e la citazione delle fonti.
4. 4Testate e iterate: non esiste una dimensione universalmente ottimale. Provate diverse configurazioni sul vostro corpus e misurate la qualità del retrieval con il benchmark creato nella fase di scelta degli embedding.

Infrastruttura vettoriale

Il database vettoriale è il componente infrastrutturale che rende possibile la ricerca per similarità semantica. A differenza di un database relazionale tradizionale, che cerca corrispondenze esatte tra valori, un vector database confronta vettori numerici e restituisce quelli più "vicini" al vettore della query, usando metriche come la cosine similarity o la distanza euclidea. Questo consente di trovare frammenti semanticamente simili alla domanda anche quando non condividono nessuna parola esatta.

Il mercato dei vector database si è sviluppato rapidamente negli ultimi due anni, offrendo soluzioni che vanno dal database embedded per prototipi al servizio cloud gestito per ambienti di produzione enterprise. La scelta dipende dal volume dei dati, dai requisiti di latenza, dalla necessità di filtraggio per metadati e dalla preferenza per soluzioni on-premise o cloud.

Per la maggior parte dei progetti RAG aziendali di dimensioni medie (fino a qualche milione di documenti), Qdrant rappresenta un eccellente compromesso tra funzionalità, prestazioni e costo. Può essere eseguito on-premise per soddisfare requisiti di compliance, offre filtraggio avanzato per metadati — essenziale per separare documenti per dipartimento, data o livello di accesso — e scala bene al crescere del corpus documentale.

Per i prototipi e le fasi esplorative, ChromaDB rimane la scelta più pragmatica: poche righe di codice per avere un sistema funzionante. Per le organizzazioni che preferiscono un approccio completamente gestito e non hanno vincoli di residenza dei dati, Pinecone elimina la complessità operativa a fronte di un costo ricorrente.

I 5 errori più comuni

Dopo aver analizzato decine di implementazioni RAG in contesti aziendali italiani ed europei, abbiamo identificato cinque errori ricorrenti che compromettono la qualità del sistema. La buona notizia è che tutti sono evitabili con le giuste accortezze progettuali.

Errore 1: Qualità documentale insufficiente

Il principio "garbage in, garbage out" si applica con forza particolare ai sistemi RAG. Documenti PDF scansionati con OCR di bassa qualità, formattazioni inconsistenti, informazioni obsolete non rimosse e duplicati non gestiti producono chunk di scarsa qualità che inquinano l'intero sistema. Prima di qualsiasi implementazione tecnica, è indispensabile un lavoro di curation documentale: validare l'OCR, normalizzare i formati, rimuovere le versioni superate e deduplicare i contenuti.

Errore 2: Dimensione dei chunk inadeguata

Molti progetti adottano dimensioni di chunk arbitrarie senza testare alternative. Chunk da 200 token possono funzionare per FAQ brevi ma falliscono miseramente su documenti normativi dove un singolo concetto si sviluppa su più paragrafi. Al contrario, chunk da 2000 token recuperano troppo contesto irrilevante, confondendo il modello e sprecando la finestra di contesto. La dimensione ottimale dipende dal tipo di documento e dalle domande attese, e va calibrata empiricamente.

Errore 3: Assenza di re-ranking

La ricerca per similarità vettoriale è veloce ma approssimativa. I primi 20 risultati del retrieval contengono spesso frammenti rilevanti mescolati a 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 la query e ciascun frammento, migliorando significativamente la precisione. Saltare questo passaggio equivale a cercare un libro in una biblioteca ordinata solo approssimativamente per argomento.

Errore 4: Nessuna validazione delle risposte

Molti sistemi RAG generano risposte senza alcun meccanismo di verifica. Il modello può ignorare i frammenti forniti e rispondere dalla propria conoscenza parametrica, può combinare informazioni da frammenti incompatibili, o può inventare dettagli per colmare lacune. Senza un sistema di validazione — che vedremo nella prossima sezione — queste risposte errate raggiungono l'utente finale con la stessa sicurezza di quelle corrette.

Errore 5: Metadati ignorati

I frammenti vengono spesso archiviati come semplice testo, senza informazioni sulla loro provenienza, data, versione o ambito di applicazione. Questo rende impossibile filtrare per dipartimento, escludere documenti obsoleti o citare la fonte esatta nella risposta. I metadati non sono un accessorio: sono una componente essenziale della qualità e dell'affidabilità del sistema.

Validazione delle risposte

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

1. 1Verifica di grounding: controllare che ogni affermazione nella risposta sia effettivamente supportata da uno dei frammenti recuperati. Questo può essere fatto con un secondo passaggio LLM che analizza la risposta frase per frase, oppure con tecniche di NLI (Natural Language Inference).
2. 2Citazione delle fonti: ogni risposta deve indicare esplicitamente da quali documenti e sezioni provengono le informazioni. Questo permette all'utente di verificare autonomamente e aumenta la fiducia nel sistema.
3. 3Confidence scoring: assegnare un punteggio di confidenza alla risposta basato sulla rilevanza dei frammenti recuperati, sulla coerenza interna della risposta e sul grado di copertura della domanda. Risposte sotto una soglia definita vengono segnalate o bloccate.
4. 4Risposta "non so": il sistema deve essere in grado di dichiarare esplicitamente quando non ha informazioni sufficienti per rispondere, piuttosto che inventare una risposta plausibile. Questa capacità si configura tramite il prompt di sistema e la soglia di rilevanza del retrieval.
5. 5Feedback loop: raccogliere il feedback degli utenti (risposta utile / non utile / errata) e usarlo per migliorare continuamente il sistema, sia raffinando il chunking e gli embedding, sia aggiornando il corpus documentale.

Un approccio particolarmente efficace è il pattern "guardrail": un secondo modello, più piccolo e veloce, che analizza la risposta generata prima di presentarla all'utente. Questo modello verifica che la risposta sia coerente con i frammenti forniti, non contenga informazioni non supportate e risponda effettivamente alla domanda posta. Se la verifica fallisce, il sistema può riprovare con una strategia di retrieval diversa o restituire un messaggio di cortesia.

Un'altra tecnica fondamentale è la valutazione sistematica tramite metriche automatiche. Framework come RAGAS (Retrieval Augmented Generation Assessment) permettono di misurare la fedeltà della risposta ai frammenti, la rilevanza dei frammenti rispetto alla domanda e la completezza della risposta. Queste metriche vanno monitorate nel tempo per individuare regressioni e identificare aree di miglioramento.

Un caso pratico

Per rendere concreti i concetti esposti, consideriamo un caso pratico basato su un'implementazione reale per un'azienda manifatturiera toscana con circa 200 dipendenti. L'azienda disponeva di oltre 3.000 documenti tecnici — manuali macchina, schede di manutenzione, procedure di sicurezza, specifiche di prodotto — distribuiti tra un file server, un gestionale proprietario e una serie di cartelle condivise. I tecnici impiegavano in media 25 minuti per trovare un'informazione specifica, con frequenti errori dovuti a documenti obsoleti non rimossi.

La prima fase del progetto è stata dedicata alla curation documentale: abbiamo identificato e rimosso 400 documenti duplicati o obsoleti, migliorato l'OCR di 180 PDF scansionati e normalizzato i formati. Questo lavoro, durato tre settimane, si è rivelato l'investimento con il ritorno più alto dell'intero progetto.

Per la pipeline di ingestione abbiamo scelto un approccio di chunking ricorsivo per struttura, con 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 abbiamo selezionato BGE-M3 per la sua eccellente gestione dell'italiano tecnico e la possibilità di esecuzione on-premise, requisito imposto dalla policy aziendale sui dati sensibili. L'infrastruttura vettoriale è stata implementata con Qdrant su un server interno.

Il sistema di retrieval utilizza 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 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.

Dopo tre mesi di utilizzo, il tempo medio di ricerca di un'informazione tecnica è sceso da 25 minuti a meno di 2 minuti. L'accuratezza delle risposte, misurata con 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%. Il feedback degli utenti è stato decisivo per correggere problemi di chunking su specifiche categorie di documenti e per aggiornare il corpus con informazioni mancanti.

Risorse per approfondire

Il campo del RAG è in rapida evoluzione. Nuove tecniche, modelli e strumenti emergono costantemente, rendendo essenziale un aggiornamento continuo per chi lavora su questi sistemi. Di seguito una selezione ragionata di risorse per approfondire gli argomenti trattati in questa guida.

Oltre a queste risorse specifiche, consigliamo di seguire i blog tecnici di Anthropic, OpenAI e Cohere, che pubblicano regolarmente approfondimenti sulle best practice per il RAG e sulle nuove funzionalità dei loro modelli. La community italiana su AI è attiva e in crescita: conferenze come la PyCon Italia e i meetup locali dedicati al machine learning offrono opportunità preziose di confronto e apprendimento.

Glossario

I termini tecnici utilizzati in questa guida possono risultare nuovi per chi si avvicina per la prima volta al mondo del RAG. Questo glossario fornisce definizioni concise e accessibili dei concetti chiave, utili come riferimento rapido durante la lettura e l'implementazione.