La Retrieval-Augmented Generation, in breve RAG, è la tecnologia chiave che rende l’IA utilizzabile per i settori regolamentati. Mentre i modelli linguistici generici si affidano ai dati di addestramento, producendo allucinazioni, informazioni obsolete e risposte prive di fonti, la RAG àncora l’IA a una base di conoscenza verificata. Il risultato: risposte basate sulle fonti, aggiornate e tracciabili.
Questo articolo spiega l’architettura tecnica di un sistema RAG per i settori regolamentati. Si rivolge a professionisti che vogliono capire cosa succede sotto il cofano quando utilizzano un sistema di questo tipo. Non è richiesta una laurea in informatica, ma è presupposto un interesse tecnico.
Il principio fondamentale
Un sistema RAG è composto da due componenti principali: una componente di retrieval (ricerca) e una componente di generation (generazione del testo). La combinazione risolve i tre problemi principali dei modelli linguistici generici.
Senza RAG: l’utente pone una domanda. Il modello linguistico genera una risposta basandosi esclusivamente su ciò che ha appreso durante l’addestramento. Nessuna fonte dati esterna, nessun controllo dei fatti, nessuna indicazione delle fonti.
Con RAG: l’utente pone una domanda. Il sistema cerca prima nella base di conoscenza i documenti pertinenti. Questi documenti vengono passati al modello linguistico come contesto. Il modello genera la sua risposta sulla base dei documenti recuperati e cita le fonti.
La differenza è paragonabile a quella tra un esperto che risponde a memoria e un esperto che consulta prima i documenti pertinenti e poi risponde. Il secondo approccio è più affidabile e le sue risposte sono verificabili.
La pipeline di retrieval nel dettaglio
La qualità di un sistema RAG dipende interamente dalla pipeline di retrieval. Migliore è la capacità del sistema di trovare i documenti pertinenti, migliore sarà la risposta. Una moderna pipeline di retrieval per i settori regolamentati si compone di più fasi.
Fase 1: elaborazione e indicizzazione dei documenti
Prima che il sistema possa rispondere alle domande, i documenti fonte devono essere elaborati e indicizzati. Per i settori regolamentati, questo processo è più complesso rispetto alle applicazioni generiche.
Estrazione strutturata. Leggi, ordinanze e sentenze non sono testi non strutturati. Hanno una struttura gerarchica. Una legge federale è composta da parti, titoli, capitoli, sezioni, articoli e capoversi. Una sentenza contiene i fatti, le considerazioni e il dispositivo. Questa struttura deve essere preservata durante l’elaborazione affinché il sistema possa cercare al giusto livello di granularità.
Chunking. I documenti vengono suddivisi in sezioni (chunk) abbastanza piccole per un retrieval efficiente, ma sufficientemente ampie per fornire un contesto adeguato. Per i testi giuridici, la suddivisione naturale (articolo, capoverso, considerazione) è spesso il confine migliore per il chunk. Il taglio arbitrario basato sul numero di caratteri distrugge il contesto.
Embedding contestuale. Prima di convertire un chunk in un vettore, il sistema genera una descrizione contestuale: a quale legge appartiene questo articolo? In quale capitolo si trova? Di cosa tratta? Questa informazione contestuale viene anteposta al chunk e migliora significativamente la precisione della ricerca. Un capoverso isolato “l’aliquota è dell'8%” è poco utile senza contesto. Lo stesso capoverso con il contesto “art. 55 della legge tributaria del Canton Zurigo, sezione imposta sul reddito delle persone fisiche” è individuabile con precisione.
Vettorizzazione. Ogni chunk (con informazione contestuale) viene convertito da un modello di embedding in un vettore ad alta dimensionalità. Questo vettore è una rappresentazione matematica del significato del testo. Significati simili producono vettori simili. Ciò consente la ricerca semantica: il sistema trova documenti pertinenti nel contenuto anche quando usano parole diverse.
Indicizzazione BM25. Parallelamente alla vettorizzazione, ogni chunk viene registrato in un indice testuale classico (BM25). Questo indice è ottimizzato per termini esatti: numeri di articolo, numeri di procedimento, termini tecnici specifici, abbreviazioni legislative. Ricerca semantica e ricerca esatta si completano a vicenda.
Fase 2: ricerca ibrida
Quando l’utente pone una domanda, vengono eseguite due ricerche in parallelo.
Ricerca vettoriale. La domanda viene convertita in un vettore e confrontata con il database vettoriale. Il sistema trova i chunk il cui significato è più simile alla domanda. Esempio: la domanda “Quali obblighi ha il locatore in caso di difetti?” trova le disposizioni pertinenti nel Codice delle obbligazioni, anche se lì si parla di “garanzia per vizi” e “riparazione”.
Ricerca per parole chiave (BM25). Contemporaneamente, il sistema cerca nell’indice testuale corrispondenze esatte. Questo è particolarmente importante per i riferimenti agli articoli (“art. 259a CO”), i numeri di procedimento delle sentenze, i termini giuridici specifici e le abbreviazioni.
Reciprocal Rank Fusion (RRF). I risultati di entrambe le ricerche vengono combinati con un algoritmo che dà priorità ai documenti che ottengono un posizionamento elevato in entrambe le ricerche. Un documento che risulta sia semanticamente rilevante sia ben posizionato nella ricerca per parole chiave ottiene il rango più alto.
Fase 3: reranking
La ricerca iniziale getta una rete ampia. Il reranking filtra i risultati.
Cross-Encoder. Un modello specializzato valuta ogni coppia documento-domanda nel dettaglio. A differenza della ricerca vettoriale, che rappresenta documenti e domande indipendentemente l’uno dall’altro e poi li confronta, il cross-encoder esamina il documento e la domanda congiuntamente. Questo consente una valutazione della rilevanza più fine.
Ottimizzazione della finestra di contesto. Il numero di documenti passati al modello linguistico è limitato dalla finestra di contesto. Il reranking assicura che i documenti più rilevanti occupino lo spazio disponibile. I documenti meno rilevanti vengono esclusi per non distrarre il modello.
Fase 4: generazione
Il modello linguistico riceve la domanda dell’utente insieme ai documenti recuperati come contesto.
Istruzioni. Il modello viene istruito a basare la sua risposta esclusivamente sui documenti forniti. Se i documenti non contengono informazioni sulla domanda, il modello deve comunicarlo in modo trasparente, anziché inventare una risposta.
Attribuzione delle fonti. Il modello fa riferimento nella sua risposta alle fonti specifiche che ha utilizzato. Ogni affermazione viene attribuita a un documento concreto. L’utente vede: questa informazione proviene dall’art. 259a CO, quella dalla DTF 135 III 345.
Output strutturato. Per le applicazioni regolamentate, un output strutturato è importante. Invece di un testo continuo non strutturato, il sistema fornisce la risposta articolata per base giuridica, sintesi e riferimenti alle fonti.
Requisiti specifici per i settori regolamentati
Il RAG standard, come viene impiegato nelle applicazioni generiche, non è sufficiente per i settori regolamentati. Sono necessarie le seguenti estensioni.
Plurilinguismo. In Svizzera le leggi federali esistono in tedesco, francese e italiano. Tutte e tre le versioni linguistiche sono ugualmente vincolanti. Un sistema RAG per il diritto svizzero deve poter cercare trasversalmente alle lingue. Una domanda in tedesco deve trovare anche la versione francese della legge, se più pertinente. Modelli di embedding multilingue come BGE-M3 lo rendono possibile, mappando testi di diverse lingue nello stesso spazio vettoriale.
Grafi di citazione. I testi giuridici non esistono isolatamente. Un articolo di legge fa riferimento ad altri articoli. Le sentenze citano leggi e altre sentenze. Le ordinanze concretizzano le leggi. Queste relazioni formano un grafo. Un sistema RAG per i settori regolamentati deve conoscere e utilizzare questo grafo. Quando un utente chiede di un articolo di legge, il sistema deve trovare anche le sentenze pertinenti che interpretano tale articolo e le ordinanze che lo concretizzano.
Versionamento. Le leggi cambiano. Un articolo che nel 2024 aveva una determinata formulazione può avere un contenuto diverso nel 2026. Il sistema deve gestire diverse versioni. Deve utilizzare la versione vigente come standard, ma poter recuperare anche versioni storiche quando necessario. Per i casi che si riferiscono a uno stato giuridico precedente, la versione storica è quella rilevante.
Retrieval granulare. Nei sistemi RAG generici la ricerca avviene spesso a livello di documento. Per i settori regolamentati questo è troppo approssimativo. Il sistema deve poter cercare a livello di articolo, capoverso o persino di frase. Quando l’utente chiede il termine di prescrizione di un determinato credito, ha bisogno del capoverso specifico, non dell’intera legge.
Audit trail. Ogni interazione con il sistema deve essere protocollata: la domanda, i documenti recuperati, le risposte generate, le fonti utilizzate. Questo audit trail è essenziale per il controllo qualità, per i requisiti di compliance e per la tracciabilità verso clienti e autorità.
Misurazione della qualità
Un sistema RAG è buono solo quanto la sua capacità di trovare i documenti giusti e generare risposte corrette. La qualità si misura su diverse metriche.
Recall. Quanti dei documenti pertinenti trova il sistema? Un sistema che trova 8 su 10 articoli pertinenti ha un recall dell'80%. Per i settori regolamentati un recall elevato è critico. Un articolo pertinente trascurato può falsare l’intera analisi.
Precision. Quanti dei documenti trovati sono effettivamente pertinenti? Un sistema che fornisce 100 documenti di cui solo 5 pertinenti ha una precision bassa. Ciò sovraccarica l’utente con informazioni irrilevanti.
Faithfulness. La risposta generata corrisponde ai documenti recuperati? Un sistema che recupera i documenti correttamente, ma nella generazione si discosta dal contenuto, ha un problema di faithfulness.
Tasso di allucinazione. Con quale frequenza la risposta contiene informazioni che non si trovano in nessuno dei documenti recuperati? Per i settori regolamentati, questo tasso deve tendere a zero.
Perché l’architettura è determinante
L’architettura tecnica di un sistema RAG determina se è adatto ai settori regolamentati o meno. Un sistema con embedding di bassa qualità, senza ricerca BM25, senza reranking e senza attribuzione delle fonti può funzionare per domande generiche. Per la ricerca giuridica, la verifica di compliance o l’analisi fiscale è insufficiente.
L’architettura determina anche dove vengono elaborati i dati. Per le aziende svizzere nei settori regolamentati, l’intera pipeline deve funzionare in Svizzera: calcolo degli embedding, database vettoriale, modello linguistico, audit trail. Un’architettura che invia i dati a server all’estero per l’elaborazione non è ammissibile per molti casi d’uso.
Enclava implementa questa architettura interamente in Svizzera. La piattaforma comprende dati giuridici e normativi verificati, retrieval multilingue, attribuzione granulare delle fonti e verificabilità completa. La base di conoscenza SwissLaw contiene oltre 27'000 leggi e 1,1 milioni di sentenze, strutturate, versionate e aggiornate continuamente.
Se volete capire come funziona nella pratica il RAG per i settori regolamentati, visitate enclava.ch oppure contattateci all’indirizzo [email protected].