Che cos’è il RAG e perché permette all’IA di usare delle fonti

Dal documento alla risposta: come un LLM può cercare informazioni prima di generare il testo

Nell’articolo precedente abbiamo scoperto qualcosa di importante. Un Large Language Model può costruire una risposta molto convincente senza che ciò che afferma sia necessariamente vero. Può persino produrre il numero, la data e il principio di una sentenza che sembra perfettamente credibile, ma che in realtà non esiste. Abbiamo chiamato questo fenomeno allucinazione e abbiamo fissato una regola fondamentale: OUTPUT GENERATO ≠ FONTE VERIFICATA.

A questo punto nasce spontanea una domanda. Se il problema è che il modello genera la risposta senza necessariamente consultare una fonte, perché non gli diamo delle fonti da utilizzare? È proprio da questa idea che possiamo iniziare a capire il RAG.

Immaginiamo un avvocato con una biblioteca

Facciamo un esempio molto semplice. Immagina di chiedere a una persona: «Qual è la regola prevista da questo contratto per il recesso?». Potrebbe provare a rispondere utilizzando quello che ricorda. Ma potremmo fare qualcosa di più sensato: darle il contratto, farle cercare le clausole che parlano del recesso e chiederle di rispondere utilizzando quelle informazioni. Abbiamo aggiunto un passaggio fondamentale: prima cerchiamo le informazioni, poi costruiamo la risposta.

1. DomandaIl sistema riceve il compito.
2. RicercaIndividua contenuti pertinenti nell’archivio disponibile.
3. ContestoI contenuti selezionati vengono messi a disposizione del modello.
4. GenerazioneIl modello elabora una risposta sulla base del contesto.
5. VerificaIl professionista controlla fonte, pertinenza e risultato.

RAG non significa verità. Una citazione richiede comunque verifica.

Il RAG applica, attraverso meccanismi informatici molto più complessi, una logica simile. RAG significa Retrieval-Augmented Generation, espressione che possiamo tradurre come generazione aumentata dal recupero di informazioni. Il nome, questa volta, ci aiuta davvero a capire: retrieval significa recuperare informazioni; augmented significa arricchire ciò che viene messo a disposizione del modello; generation indica la successiva generazione della risposta.

La sequenza essenziale diventa quindi:

DOMANDA → RICERCA → DOCUMENTI PERTINENTI → LLM → RISPOSTA

Il Joint Research Centre della Commissione europea ha sperimentato proprio questo approccio associando gli LLM a raccolte selezionate di informazioni, così da permettere di utilizzare nella generazione contenuti recuperati da una base documentale esterna.

Ma il modello legge davvero tutta la biblioteca?

No. Ed è qui che dobbiamo fare un piccolo passo in avanti. Supponiamo che uno studio legale possieda diecimila documenti: contratti, pareri, circolari, regolamenti, sentenze e documentazione interna. Non avrebbe senso consegnare indistintamente tutti quei documenti al modello ogni volta che facciamo una domanda. Il sistema deve prima cercare di individuare quali informazioni potrebbero essere pertinenti.

Torniamo alla nostra biblioteca. Se chiediamo «Che cosa prevede il contratto Alfa sulla possibilità di recesso?», non portiamo sul tavolo tutti i libri presenti nella stanza. Prima cerchiamo il documento pertinente e, all’interno di quel documento, le parti che potrebbero servire. Solo dopo mettiamo quelle informazioni a disposizione del modello affinché possa utilizzarle nella generazione.

Possiamo rappresentare il passaggio così:

ARCHIVIO → RICERCA → CONTENUTI RILEVANTI → CONTESTO DELL’LLM → RISPOSTA

Questa distinzione sarà importante anche quando parleremo della context window, cioè dello spazio di contesto entro il quale il modello può utilizzare le informazioni che gli vengono fornite durante una determinata elaborazione.

Come fa il sistema a trovare il pezzo giusto?

Qui incontriamo qualcosa che conosciamo già: gli embeddings. Abbiamo visto che permettono di rappresentare numericamente aspetti del significato di un testo e che queste rappresentazioni possono essere confrontate tra loro. È proprio una delle ragioni per cui gli embeddings possono essere utilizzati nei sistemi di ricerca semantica.

Immaginiamo di avere un documento di cento pagine. Un sistema RAG può suddividerlo in porzioni più piccole, spesso chiamate chunk. Queste porzioni vengono organizzate e rese ricercabili. Quando arriva una domanda, il sistema cerca i contenuti che ritiene maggiormente pertinenti e li porta nel contesto utilizzato dal modello.

In forma molto semplificata:

DOCUMENTI → PORZIONI DI TESTO → INDICIZZAZIONE → RICERCA → CONTENUTI RECUPERATI → LLM

Naturalmente non tutti i sistemi RAG funzionano nello stesso modo. Esistono tecniche differenti di indicizzazione, ricerca, ranking e recupero e architetture molto più sofisticate. Per capire il concetto fondamentale, però, questa mappa è sufficiente. Ci permette anche di fissare una distinzione importante: il RAG non è l’LLM. È un’architettura nella quale la capacità generativa del modello viene collegata a un meccanismo che recupera informazioni esterne.

LLM ≠ RAG

Torniamo nello studio legale

Immaginiamo adesso che uno studio disponga di una raccolta controllata di cento contratti. L’avvocato chiede: «Nel contratto Rossi-Bianchi, quali sono i termini previsti per il recesso?». Un sistema RAG potrebbe cercare nella raccolta il contratto pertinente, individuare le clausole maggiormente correlate alla domanda e inserirle nel contesto fornito all’LLM. Il modello costruirebbe quindi la risposta avendo a disposizione quelle parti del documento.

Rispetto al nostro esempio sulle allucinazioni è cambiato qualcosa di fondamentale. Prima avevamo:

DOMANDA → LLM → RISPOSTA

Adesso abbiamo:

DOMANDA → RECUPERO DELLE INFORMAZIONI → CONTESTO → LLM → RISPOSTA

Il modello non deve quindi affidarsi soltanto a ciò che è incorporato nei suoi parametri e alle informazioni contenute originariamente nella richiesta. Il sistema può recuperare informazioni esterne al momento dell’utilizzo e metterle a disposizione dell’LLM. Questo permette anche di lavorare su raccolte documentali specifiche e aggiornabili senza dover necessariamente riaddestrare il modello ogni volta che cambia un documento.

Quindi con il RAG l’IA non inventa più?

No. Ed è probabilmente la cosa più importante da imparare in questo articolo.

RAG ≠ VERITÀ

Il RAG può migliorare l’affidabilità di un sistema perché consente di fornire al modello informazioni pertinenti provenienti da fonti esterne. Ma tra avere accesso a una biblioteca e dare sempre la risposta corretta c’è una grande differenza.

Pensiamo ancora al nostro esempio. Questa volta abbiamo dato al nostro giovane assistente accesso a una biblioteca. È certamente meglio che chiedergli di rispondere soltanto utilizzando ciò che ricorda. Ma potrebbe scegliere il libro sbagliato, recuperare una pagina non pertinente, non trovare la pagina che serviva oppure utilizzare male ciò che ha trovato. In termini tecnici diversi, anche un sistema RAG può incontrare problemi analoghi. La letteratura scientifica mostra infatti che il recupero delle informazioni costituisce a sua volta una fase nella quale possono verificarsi errori: il sistema può recuperare contenuti non pertinenti o incompleti e il modello può non utilizzare correttamente ciò che gli viene fornito.

Ecco allora una prima conseguenza fondamentale: avere un sistema di retrieval non significa che il retrieval funzionerà sempre correttamente.

La fonte può esserci, ma essere quella sbagliata

Questo ci permette di distinguere tre momenti. Il sistema deve anzitutto avere accesso a fonti adeguate; deve poi riuscire a recuperare quelle pertinenti; infine il modello deve costruire una risposta coerente con ciò che è stato effettivamente recuperato. Sono tre problemi diversi e confonderli può farci attribuire al RAG capacità che non possiede.

Possiamo fissare le differenze così:

FONTE PRESENTE ≠ FONTE RECUPERATA
FONTE RECUPERATA ≠ FONTE PERTINENTE
FONTE PERTINENTE ≠ RISPOSTA NECESSARIAMENTE CORRETTA

Per un giurista queste distinzioni sono particolarmente importanti. Supponiamo che nella base documentale siano presenti cinque versioni della stessa norma. Il sistema potrebbe recuperare quella non più vigente. Oppure potrebbe trovare una sentenza che contiene le stesse parole utilizzate nella domanda, ma riguarda una fattispecie differente. O ancora potrebbe recuperare correttamente una decisione e poi formulare una conclusione che quella decisione non sostiene. Il problema non è quindi soltanto avere delle fonti. Conta quali fonti inseriamo nella raccolta, come vengono organizzate, quali vengono recuperate e come vengono utilizzate nella risposta.

Una citazione non basta

C’è un altro errore nel quale è molto facile cadere. Se una risposta dell’IA contiene sotto ogni affermazione un collegamento a una fonte, possiamo considerarla verificata? Ancora una volta, no. Una fonte potrebbe esistere ma non sostenere realmente l’affermazione alla quale viene associata. Anche sistemi che utilizzano meccanismi di retrieval possono generare affermazioni che non trovano adeguato supporto nei documenti recuperati.

Dobbiamo quindi conservare un’altra distinzione:

FONTE CITATA ≠ AFFERMAZIONE DIMOSTRATA

Per l’avvocato significa qualcosa di molto concreto. Se il sistema indica una sentenza, non basta verificare che quella sentenza esista. Occorre leggerla e verificare che cosa dice, in quale contesto lo dice, se il passaggio richiamato esiste davvero, se il principio viene rappresentato correttamente e se la decisione è pertinente rispetto alla questione che stiamo affrontando.

Ed ecco perché il RAG non cancella la regola imparata nell’articolo precedente. La rende ancora più importante:

L’IA RECUPERA E GENERA → IL PROFESSIONISTA VERIFICA → IL PROFESSIONISTA DECIDE

Possiamo costruire un RAG con i documenti dello studio?

Tecnicamente, sì. Ed è proprio qui che il nostro percorso comincia a diventare particolarmente interessante per l’avvocato. Una base documentale potrebbe contenere, a seconda del progetto, contratti, precedenti interni, modelli, normativa, documentazione di fascicolo o altre raccolte informative. Ma appena pronunciamo le parole “documenti dello studio”, non stiamo più affrontando soltanto un problema tecnico.

Dentro quei documenti possono esserci dati personali, categorie particolari di dati, informazioni riservate, segreti, strategie difensive e materiale soggetto agli obblighi professionali. La domanda, quindi, non può essere soltanto «Il RAG funziona bene?». Dobbiamo cominciare a chiederci anche quali documenti vengono indicizzati, chi può accedervi, dove vengono conservati, quali informazioni vengono trasmesse ai diversi componenti del sistema, chi gestisce l’infrastruttura, per quanto tempo i dati rimangono disponibili, se possono essere eliminati e se è possibile ricostruire quali fonti sono state utilizzate.

È qui che la tecnologia incontra nuovamente il diritto. Ma non anticipiamo troppo: questi problemi meritano nodi autonomi dedicati a GDPR, riservatezza, sicurezza, governance e segreto professionale.

Il RAG è previsto dall’AI Act?

Anche qui dobbiamo mantenere la precisione terminologica che abbiamo adottato nell’intera opera. RAG è un termine tecnico riferito a un approccio o a un’architettura informatica; non è una categoria giuridica autonoma dell’AI Act. Non esiste quindi un regime generale che possiamo chiamare semplicemente “gli obblighi del RAG”.

Gli obblighi eventualmente applicabili devono essere individuati esaminando il sistema concreto, i soggetti coinvolti, le finalità perseguite, i dati trattati, la classificazione giuridica del sistema e le diverse normative applicabili. È lo stesso metodo che abbiamo già iniziato a utilizzare quando abbiamo distinto modello, sistema, GPAI, provider e deployer.

Il percorso corretto rimane:

TECNOLOGIA → SISTEMA → UTILIZZO → RUOLO → RISCHIO → NORMA → GOVERNANCE

Prima comprendiamo che cosa fa la tecnologia. Poi qualifichiamo giuridicamente il sistema e il suo utilizzo. Soltanto dopo individuiamo le norme applicabili. Fare il contrario significherebbe cercare di applicare una categoria giuridica prima ancora di avere compreso quale fenomeno stiamo qualificando.

RAG e ricerca giuridica non sono la stessa cosa

Prima di concludere dobbiamo evitare un’ultima equivalenza. RAG ≠ BANCA DATI GIURIDICA. Un sistema RAG può essere collegato a una raccolta di documenti giuridici, ma questo non significa automaticamente che quella raccolta possieda la copertura, l’autorevolezza, l’aggiornamento, le funzionalità e i criteri di verifica propri di una banca dati professionale.

Allo stesso modo, RAG ≠ MOTORE DI RICERCA. Il recupero delle informazioni costituisce una componente dell’architettura e può essere realizzato attraverso tecniche differenti. E soprattutto RAG ≠ VERIFICA PROFESSIONALE. Il sistema può portarci il documento sul tavolo; resta al professionista stabilire se sia il documento corretto, se sia vigente, se sia pertinente e che cosa effettivamente dimostri.

Da ricordare

RAG = RETRIEVAL + GENERATION
LLM ≠ RAG
RAG ≠ VERITÀ
FONTE PRESENTE ≠ FONTE RECUPERATA
FONTE RECUPERATA ≠ FONTE PERTINENTE
FONTE CITATA ≠ AFFERMAZIONE DIMOSTRATA
RAG ≠ BANCA DATI GIURIDICA
RAG ≠ VERIFICA PROFESSIONALE

E soprattutto:

L’IA RECUPERA E GENERA → IL PROFESSIONISTA VERIFICA → IL PROFESSIONISTA DECIDE

Ma quante informazioni possiamo mettere sul tavolo?

Abbiamo appena detto che il RAG recupera documenti o parti di documenti e li porta nel contesto utilizzato dal modello. A questo punto nasce inevitabilmente una nuova domanda: possiamo mettere sul tavolo un contratto? Cento sentenze? Diecimila pagine? Tutto il fascicolo?

Non necessariamente. Un LLM lavora all’interno di uno spazio di contesto con determinate caratteristiche e limiti. È ciò che viene comunemente chiamato context window. Capire la context window ci permetterà di comprendere perché non basta semplicemente “dare tutti i documenti all’IA”, che differenza c’è tra ciò che il modello ha appreso durante il training e ciò che gli forniamo durante l’utilizzo e perché il recupero delle informazioni diventa così importante.

Ed è proprio da qui che continueremo.

---

Continua il percorso

LLM → Allucinazioni → Embeddings e ricerca semantica → Context window → Conseguenza giuridica: Cassazione e verifica professionale