Come implementare RAG sui dati aziendali: la guida onesta

1. Il problema vero

La maggior parte dei dati aziendali non è una cartella ordinata di PDF. È un misto di documenti scansionati con un OCR pessimo, file Excel usati come database, thread di email con decisioni cruciali sepolte a pagina 3, export dell'ERP in formati proprietari e siti SharePoint in cui la struttura delle cartelle riflette sei anni di riorganizzazioni.

Ogni tutorial su RAG comincia con "carica i tuoi documenti in un vector database". Dà per scontato che i documenti siano individuati, accessibili, leggibili e ragionevolmente strutturati. Nella maggior parte delle medie imprese italiane nessuna di queste ipotesi regge. La distanza tra quello che descrivono i tutorial e quello che ti trovi davanti non è un piccolo inconveniente: è l'intero rischio del progetto.

2. Parti dalle domande, non dall'infrastruttura

Il primo errore è chiedersi "quale vector database usiamo?" prima di chiedersi "quali decisioni vogliamo prendere più in fretta, e dove si trovano oggi le informazioni che servono per prenderle?"

Prima mappa le domande. Poi risali ai documenti. Poi all'architettura di retrieval. Ho visto team passare tre mesi a costruire una pipeline di ingestion per un corpus documentale che si è rivelato irrilevante rispetto alle domande di business reali. L'infrastruttura era eccellente. Il ROI era zero.

Il punto di partenza giusto è una sessione alla lavagna con le persone che prendono le decisioni: cosa vi serve sapere, con quale rapidità, e dove lo trovate oggi? Le risposte a queste domande determinano il corpus, la strategia di chunking e i requisiti di latenza, non il contrario.

3. La fase di discovery: perché saltarla costa tre mesi

Uno sprint di discovery documentale di due settimane (inventario, mappatura degli accessi, valutazione della qualità, audit dei formati) sembra un costo in più. Non lo è. Ogni progetto che lo salta sbatte contro lo stesso muro dopo sei settimane: il corpus è peggiore del previsto, gli accessi sono limitati in modi inattesi, e la strategia di chunking costruita su ipotesi va rifatta da zero.

Cosa produce davvero lo sprint di discovery: un inventario completo delle fonti documentali, con formato, modalità di accesso e punteggio di qualità. Una mappa di quali documenti rispondono a quali domande di business. Una valutazione realistica della qualità dell'OCR, del mix di lingue e della coerenza strutturale. Un audit degli accessi: chi possiede cosa, cosa richiede credenziali, cosa sta dietro una VPN.

La discovery non è un deliverable di consulenza. È un'assicurazione. Le due settimane che spendi qui ti risparmiano tre mesi di rilavorazione dopo.

4. La strategia di chunking conta più della scelta del modello

La qualità del retrieval di un sistema RAG dipende più da come i documenti vengono suddivisi in chunk che dal fatto di usare GPT-4 o un modello open source. È il fatto più sottovalutato in assoluto nel RAG aziendale.

Il chunking a dimensione fissa (512 o 1024 token) funziona per corpus omogenei: post di blog, ticket di assistenza, descrizioni di prodotto. Per documentazione tecnica, contratti e testi normativi, cioè documenti la cui struttura interna conta, il chunking semantico che rispetta i confini delle sezioni supera quello a dimensione fissa con un margine significativo.

Indicazioni concrete per tre tipi di documento con cui lavoriamo regolarmente:

• Norme tecniche (ISO, UNI, EN): chunk per clausola. Conserva nei metadati l'intera gerarchia della clausola (ad es. "ISO 9001:2015, Sezione 7.1.5, Clausola 7.1.5.2"). Sovrapposizione di una clausola superiore per il contesto. Dimensione tipica del chunk: 300–800 token.
• Contratti e documenti legali: chunk per articolo o sotto-articolo. Arricchisci i metadati con nomi delle parti, date e rimandi. La sovrapposizione è fondamentale: le clausole contrattuali si richiamano continuamente. Dimensione tipica del chunk: 400–1000 token.
• Manuali operativi: chunk per passo di procedura o per sezione. Conserva nei metadati l'ordine dei passi. Includi in ogni chunk titolo e ambito della procedura. Dimensione tipica del chunk: 200–600 token.

5. Come valutare la qualità del retrieval prima di andare in produzione

Andare in produzione senza valutazione è il modo in cui ci si ritrova con un sistema che impressiona nelle demo e fallisce sulle domande vere. Tre approcci di valutazione che funzionano nella pratica:

• MRR (Mean Reciprocal Rank) su un insieme curato di coppie domanda-documento. Costruiscilo durante la discovery: devono crearlo gli esperti di dominio che sanno dove stanno le risposte. Punta ad almeno 50 coppie che coprano tutta la distribuzione delle domande.
• Recall@k: per le 50 domande più importanti, il chunk giusto compare tra i primi k risultati? Se la recall sui primi 5 è sotto l'85%, chunking o strategia di embedding vanno sistemati prima di toccare il livello di generazione.
• Valutazione umana sui casi limite: le domande la cui risposta sta in un punto insolito, o richiede di ragionare su due documenti, o contiene una negazione. Sono quelle che, se falliscono, erodono la fiducia degli utenti. Testale in modo esplicito.

Non andare in produzione sotto una soglia concordata in anticipo. Fissa la soglia prima di iniziare a valutare, non dopo aver visto i numeri.

6. Governance dal primo giorno

Controllo degli accessi, audit logging e blocco della versione del modello non sono funzionalità da aggiungere quando il sistema funziona. Sono vincoli che danno forma all'architettura. Se costruisci senza, li aggiungerai dopo sotto pressione, e l'intervento a posteriori sarà incompleto.

La governance minima per un sistema RAG in produzione: chi può interrogare quale corpus, registrato al momento della query. Quale versione del modello ha prodotto quale risposta, conservato in modo immutabile. Un processo di aggiornamento del modello che includa test di regressione sull'insieme di valutazione. Una policy di conservazione che stabilisca per quanto tempo si tengono i log delle query e le risposte generate.

Nei settori regolamentati (sanità, farmaceutico, finanza) non è facoltativo. In tutti gli altri resta comunque una buona idea. La prima volta che qualcuno chiede "perché il sistema ha dato quella risposta?" sarai contento di averla registrata.

7. On-premise o cloud: i compromessi, detti onestamente

RAG in cloud è più rapido da avviare e più lento da governare. On-premise è più lento da avviare e più facile da governare su larga scala. Il punto di pareggio dipende da tre fattori:

• Sensibilità dei dati: se il corpus contiene dati di pazienti, dati finanziari o segreti industriali, il peso di compliance di un deployment in cloud spesso supera il peso operativo dell'on-premise.
• Requisiti normativi: GDPR, AI Act, DORA, Legge 132/2025: ognuno aggiunge vincoli su come i dati possono essere trattati e su come il trattamento va documentato; nessuno impone di tenere i dati in Italia o in UE, ma il GDPR limita i trasferimenti fuori dall'Unione. L'on-premise semplifica la compliance perché elimina gli accordi di trattamento dati con terze parti.
• Competenze del team: se il tuo team IT sa gestire container e nodi GPU, l'on-premise è praticabile. Se non lo sa fare, il cloud è la scelta pragmatica finché non costruisci quella competenza. Ma costruiscila, perché per i carichi continuativi la curva dei costi favorisce l'on-premise.

Nessuna delle due opzioni è migliore in assoluto. Chi ti dice il contrario sta vendendo qualcosa.

10 domande a cui rispondere prima di iniziare

1. Quali decisioni di business dovrebbe rendere più rapide questo sistema, e per chi?
2. Dove si trovano oggi i dati che alimentano quelle decisioni, e in che formato?
3. Chi è il titolare di quei dati, e quali restrizioni di accesso si applicano?
4. Qual è la qualità dei documenti sorgente: accuratezza dell'OCR, coerenza strutturale, mix di lingue?
5. Quali requisiti normativi si applicano ai dati e al sistema AI che li tratta?
6. Qual è la latenza accettabile per una risposta in produzione?
7. Come misurerai la qualità del retrieval, e qual è la soglia minima accettabile?
8. Chi manterrà il sistema dopo il rilascio: aggiornerà il corpus, rigenererà gli embedding, monitorerà la qualità?
9. Cosa succede quando il sistema dà una risposta sbagliata? Qual è il raggio dei danni?
10. Il tuo team infrastrutturale sa gestire container e carichi GPU, o devi prima costruire quella competenza?

Se non sai rispondere con sicurezza ad almeno sette di queste, non sei pronto per costruire. Comincia dallo sprint di discovery.