Data Ingestion per RAG: la pipeline di un assistente AI affidabile

Un gruppo assicurativo italiano distribuisce prodotti attraverso una rete di oltre 3.500 operatori. La conoscenza che serve a vendere una polizza e ad assistere un cliente, ossia condizioni contrattuali, KID, circolari interne, aggiornamenti normativi e procedure sinistri, viveva sparsa tra file share e archivi documentali, spesso in versioni non allineate. Reperire l'informazione giusta richiedeva tra i cinque e i sette minuti, con il rischio concreto di dare risposte incoerenti su materia regolamentata.

Per questo cliente abbiamo progettato e portato in produzione un sistema RAG con un assistente conversazionale che risponde  citando sempre la fonte autorevole e in corso di validità. Il tempo per reperire l'informazione corretta è sceso da minuti a meno di venti secondi, con un tasso di allucinazione sui contenuti regolamentati inferiore allo 0,5%. La parte che ha richiesto il lavoro è stata la pipeline di data ingestion che rende un corpus documentale eterogeneo realmente interrogabile da un'AI. Ed è questo l'oggetto di questo articolo.

Quando si parla di RAG, l'attenzione finisce quasi sempre sul modello: quale LLM, quanto context, quale prompt. Nella nostra esperienza il modello è la parte meno complicata. Infatti, ciò che separa un proof of concept da un sistema che la funzione compliance lascia andare in produzione è la qualità con cui i dati entrano nella knowledge base: governati, versionati, citabili. In un settore regolamentato questa qualità decide in sostanza se il sistema vedrà mai la produzione.

Nella RAG, il modello è la parte trascurabile

Un LLM è accurato quanto i dati che gli arrivano. "Garbage in, garbage out" vale per qualsiasi sistema AI, ma nella RAG l'effetto è amplificato: un chunk sbagliato, un documento scaduto, una tabella letta male, e il modello produce una risposta fluente e sbagliata, con tono sicuro. Nel progetto citato sopra, il corpus arrivava in formati eterogenei (PDF nativi e scansionati, Word, fogli Excel per i tariffari, pagine HTML) e le versioni non erano sempre coerenti. Senza metadati, tassonomie e tabelle strutturate, quei documenti erano di fatto ciechi per un'AI: qualunque sistema avrebbe potuto solo tirare a indovinare.

Perché lo chiamiamo knowledge injection

La maggior parte dei progetti si ferma alla parola "ingestion": prendere i dati e portarli dentro. Su corpus regolamentati noi alziamo l'asticella e parliamo di knowledge injection, perché un documento deve entrare nella knowledge base già governato: con una versione, una finestra di validità, un flag di fonte autorevole e, per i contenuti regolamentati, un workflow di approvazione umano. Un documento scaduto lasciato nell'indice diventa, prima o poi, una risposta sbagliata data con sicurezza. Questa governance è incorporata nel momento stesso in cui il dato entra nella knowledge base, fin dall'acquisizione.

La pipeline a stadi

Abbiamo progettato l'ingestion come una pipeline a stadi, incrementale e ottimizzata sui costi. Ecco cosa succede a un documento, dalla fonte alla sua interrogabilità.

• Acquisizione e connettori. Connettori dedicati verso le fonti del cliente (gestione documentale, file share, intranet, caselle per le circolari, feed normativi), orchestrati con Prefect, con sincronizzazione incrementale e change detection per acquisire solo ciò che cambia.
• Parsing e comprensione del layout. Estrazione multi-formato con OCR layout-aware sui documenti scansionati e riconoscimento strutturato delle tabelle, per non perdere l'informazione dentro KID, condizioni e tariffari. Qui lavorano Azure AI Document Intelligence, PyMuPDF e la libreria Unstructured.
• Normalizzazione e arricchimento. Conversione in un modello documentale canonico e riconoscimento della lingua; poi estrazione di metadati assistita da LLM (prodotto, ramo, tipo di documento, riferimenti normativi, date di validità) mappati sulla tassonomia di prodotto del cliente, mascheramento dei dati personali con Microsoft Presidio ed entity linking.
• Chunking strutturale. Suddivisione che rispetta sezioni e tabelle, con una gerarchia parent-child che mantiene il contesto attorno a ogni passaggio invece di spezzarlo a lunghezza fissa.
• Embedding e indicizzazione. Rappresentazioni vettoriali multilingue con text-embedding-3-large, indicizzate in un indice ibrido su Azure AI Search che combina ricerca lessicale (BM25) e semantica, arricchito di filtri sui metadati.
• Governance. Versioning della knowledge base, finestre di validità che escludono o deprioritizzano i documenti scaduti, lineage completo e flag di fonte autorevole.
• Iniezione continua. Aggiornamento programmato ed event-driven: quando un documento cambia, il sistema rigenera solo le parti effettivamente modificate, con re-embedding selettivo basato sul diff.

È quest'ultimo stadio, l'iniezione continua e selettiva, a tenere l'assistente allineato alla documentazione vigente senza re-indicizzare ogni volta l'intero corpus.

Il dettaglio che taglia i costi

Ri-processare l'intero corpus a ogni modifica è la scelta più semplice, ed è anche la più cara: ricalcola gli embedding di tutto, ogni volta. Abbiamo legato il re-embedding al diff reale, così quando una circolare cambia una sezione viene ricalcolata solo quella sezione. In produzione questo ha abbattuto il costo di re-indicizzazione del 73% e ha portato il tempo per allineare l'assistente a un aggiornamento normativo da due-tre settimane a meno di quattro ore.

Sopra la knowledge base: retrieval e agenti

Quando il dato è iniettato bene, il layer di retrieval e generazione può essere progettato per precisione e sicurezza. Il recupero combina un pre-filtraggio sui metadati (ramo, validità, abilitazioni dell'utente), una ricerca ibrida lessicale e semantica e un passaggio di reranking che porta in cima i passaggi realmente pertinenti. La generazione è affidata a un'orchestrazione multi-agente costruita con LangGraph e LlamaIndex (dopo aver valutato CrewAI), in cui ogni agente ha un compito solo: un Router classifica l'intento della domanda; un agente di Retrieval recupera e ordina i passaggi; un agente di Compliance e Citazione verifica che ogni affermazione poggi su una fonte autorevole e in validità, impone la citazione e blocca la risposta se l'evidenza non basta; un agente di Sintesi formula la risposta; un agente di Calcolo legge le tabelle tariffarie strutturate per dare esempi numerici coerenti. Sopra tutto, NeMo Guardrails applica le policy di grounding e di rifiuto.

Il principio guida è netto: nessuna fonte, nessuna risposta. In assenza di documentazione adeguata l'assistente non improvvisa, dichiara di non avere elementi sufficienti e indirizza all'escalation. E tutto questo gira con una latenza p95 sotto i 2,8 secondi in produzione.

Come abbiamo misurato la qualità

La qualità, in un sistema così, va misurata a ogni rilascio. Insieme agli esperti di dominio del cliente abbiamo costruito un golden set di circa 1.200 coppie domanda-risposta, rappresentativo per ramo e per tipo di intento. Su quel set, e poi sulla telemetria di produzione, monitoriamo metriche oggettive con Ragas e LangSmith: la faithfulness (quanto la risposta è sostenuta dalle fonti recuperate), l'accuratezza delle citazioni, precision e recall del recupero, il tasso di allucinazione. I numeri a regime: 96,4% di faithfulness, 98,1% di accuratezza nelle citazioni, recupero a 0,91 di precision e 0,88 di recall, allucinazione sui contenuti regolamentati sotto lo 0,5%. Ogni modifica rilevante alla pipeline o agli agenti passa da questo golden set prima del rilascio.

Conclusione

Questo cliente ha distribuzione, il brand e il dominio. Quello che non aveva era un team di data e AI engineering capace di portare in produzione un sistema così, con la governance che un settore regolamentato pretende. Abbiamo lavorato come team tecnico esterno end-to-end, dalla product strategy agli MLOps, dietro le quinte. Pilota su due rami in dieci settimane, sistema completo su questi in nove mesi.

Il cambiamento operativo è qualitativo: la rete è passata dal cercare al chiedere, con la garanzia che ogni risposta si fondi su un documento vigente e citabile. L'adozione ha raggiunto il 78% degli operatori in tre mesi e le escalation al secondo livello sono calate del 42%. Per una funzione di compliance, la tracciabilità completa di ogni risposta è un risultato quanto la velocità.

Se avete un corpus documentale che un'AI dovrebbe saper interrogare, scegliere il modello è la parte semplice. La domanda seria riguarda i vostri dati: sono versionati e aggiornati, con una fonte sempre tracciabile? Quasi nessun archivio lo è già, ed è lì che si gioca la partita.

Domande frequenti

Qual è la differenza tra data ingestion e data injection?

Data ingestion è il termine standard per il processo che acquisisce dati da fonti diverse e li prepara per l'uso. Noi usiamo "knowledge injection" nei contesti regolamentati per alzare l'asticella: il dato deve entrare nella knowledge base già governato, con versione, finestra di validità e fonte autorevole tracciata. È la stessa famiglia di processi, con requisiti di governance più stringenti.

Perché in un sistema RAG la data ingestion conta più del modello?

Perché un LLM è accurato quanto i dati che recupera. Il modello è ormai una commodity intercambiabile, mentre la qualità del recupero dipende da come i documenti sono stati estratti, normalizzati, arricchiti con metadati e segmentati. Un chunk sbagliato o un documento scaduto producono una risposta fluente e inaffidabile. In un settore regolamentato, dove ogni affermazione va citata e fondata, la pipeline di ingestion è il punto in cui il sistema diventa affidabile oppure no.

Come si impedisce a un assistente AI di inventare risposte sui contenuti regolamentati?

La leva principale è il grounding: ogni affermazione deve poggiare su un passaggio recuperato da una fonte autorevole e in corso di validità, con citazione obbligatoria verificata da un agente dedicato che blocca la risposta quando l'evidenza è insufficiente. A questo si aggiunge l'astensione sotto soglia: senza documentazione adeguata l'assistente dichiara di non avere elementi e indirizza all'escalation, anziché improvvisare.

Quanto costa mantenere aggiornata una knowledge base per la RAG?

Il costo dipende quasi completamente da come gestisci gli aggiornamenti. Ri-processare l'intero corpus a ogni modifica è semplice da implementare ma oneroso, perché ricalcola gli embedding di tutto ogni volta. Legando il re-embedding alle differenze effettive, così che vengano ricalcolate solo le parti di documento che cambiano.

Quanto tempo serve per portare in produzione un sistema RAG in un settore regolamentato?

Dipende dalla qualità delle fonti di partenza e dai requisiti di governance, ma un percorso realistico parte da un pilota su un perimetro ristretto, per validare l'approccio prima di scalare. Nel caso specifico descritto dall'articolo, abbiamo portato in produzione un pilota su due rami in dieci settimane e completato il sistema in nove mesi.