I sistemi RAG permettono di recuperare contenuti più pertinenti da contratti, policy, procedure e altri documenti aziendali.
Ci è però capitato di affrontare con clienti, processi che richiedono di stabilire quale documento abbia la priorità su un’altra, quale versione sia applicabile, quale regola fosse valida in un determinato periodo e come risolvere eventuali conflitti tra le fonti.
Questi requisiti richiedono un’architettura che affianchi alla ricerca semantica una gestione strutturata delle fonti e delle regole.
Pertinenza e priorità
Un sistema di ricerca semantica ordina i contenuti in base alla loro vicinanza rispetto alla richiesta dell’utente, mentre la priorità di una fonte dipende da criteri organizzativi, contrattuali e temporali.
Un documento può essere molto pertinente rispetto alla domanda ma contenere una regola scaduta, riferita a una funzione aziendale diversa oppure sostituita da una versione successiva.
Contratti, policy e documenti collegati
Un archivio aziendale può comprendere un contratto principale, diversi allegati, successive integrazioni, policy generali, procedure relative a singole funzioni e comunicazioni che introducono eccezioni temporanee.
Il sistema ipotizzato in questa sede deve quindi poter riconoscere le relazioni tra questi documenti.
Per ogni fonte, risultano rilevanti la versione, la data di entrata in vigore, il periodo di validità, l’ambito organizzativo, ecc. Questi attributi permettono di determinare quali disposizioni siano applicabili al caso esaminato.
Una possibile architettura
Gli ingredienti di cui non possiamo fare a meno per costruire il sistema saranno: document AI, modelli linguistici, ricerca semantica e soprattutto componenti deterministiche.
La pipeline parte dall’acquisizione dei documenti aziendali e porta fino alla produzione di un’ipotesi di esito, sottoponibile alla revisione di un umano.
Esaminiamo nel dettaglio i singoli elementi che compongono il sistema, a livello concettuale.
1. Acquisizione delle fonti
I documenti possono provenire da un document management system, cartelle condivise, gestionali, database, sistemi di protocollo, caselle email e repository contrattuali.
Ogni contenuto deve mantenere il collegamento con il file originale e con il sistema di provenienza.
La gestione delle versioni inizia in questa fase. Un nuovo file non dovrebbe sovrascrivere automaticamente quello precedente, perché una versione meno recente può essere ancora necessaria per verifiche storiche.
2. Parsing documentale
I documenti vengono convertiti in una rappresentazione elaborabile dal sistema.
Il parser identifica titoli, sezioni, clausole, allegati, collegamenti ad altre fonti, ecc.
La struttura contribuisce all’interpretazione del contenuto. Ad esempio: una disposizione inserita in una sezione dedicata alle eccezioni ha un ambito diverso rispetto a una clausola generale. Una tabella può stabilire condizioni differenti per più categorie. Un allegato può modificare esclusivamente alcune parti del documento principale.
3. Estrazione dei metadati
Il sistema associa a ogni documento informazioni come:
- la tipologia della fonte
- il soggetto emittente
- la versione
- la data di pubblicazione
- la data di efficacia
- la scadenza
- l’ambito territoriale e organizzativo
- lo stato di approvazione
- le relazioni con altre fonti.
I modelli linguistici possono supportare anche nell’estrazione, soprattutto quando queste informazioni sono in un formato non strutturato.
Un umano può verificare i metadati più rilevanti prima che il documento entri nella knowledge base.
4. Estrazione delle regole
Le disposizioni contenute nei documenti vengono convertite in una rappresentazione strutturata.
Una regola può descrivere le condizioni di applicazione, il comportamento previsto, i soggetti interessati, le eventuali eccezioni, il periodo di validità e l’ambito organizzativo. Deve inoltre mantenere il riferimento alla fonte originaria e contenere informazioni sullo stato dell’estrazione e dell’approvazione.
La regola estratta rimane collegata al documento e alla sezione di origine. Gli utenti possono così verificarne direttamente il contenuto.
Questo collegamento è utile anche quando viene acquisita una nuova versione del documento. Il sistema può identificare le regole strutturate che devono essere riesaminate.
5. Rule resolution engine
Il rule resolution engine è il cuore del sistema e seleziona le disposizioni applicabili a fronte di un certo input e ne gestisce i conflitti.
I criteri dipendono dall’organizzazione e dal processo considerato. Possono comprendere la priorità della fonte, la validità temporale, la specificità della disposizione, l’ambito organizzativo, lo stato di approvazione e la relazione tra un documento principale e i relativi allegati.
Una versione successiva può sostituire quella precedente. Una disposizione specifica può essere applicata all’interno di un ambito più ristretto rispetto a una policy generale. Un’eccezione può diventare applicabile quando si verificano determinate condizioni. Un allegato può modificare alcune clausole e lasciare invariate le altre.
Questi criteri devono essere espliciti, configurabili e verificabili. La loro esecuzione può essere affidata a componenti deterministiche, mentre i modelli linguistici supportano l’interpretazione e la strutturazione delle fonti.
6. Produzione dell’esito
Il sistema produce un’ipotesi di esito sulla base delle regole applicabili.
Il risultato deve indicare le fonti e le versioni considerate, le regole utilizzate, le disposizioni escluse, i conflitti individuati e i criteri adottati per risolverli.
La motivazione permette a un utente autorizzato di ricostruire il processo seguito dal sistema. Ogni conclusione rimane collegata ai documenti e alle regole strutturate che l’hanno determinata.
I casi caratterizzati da informazioni incomplete, conflitti irrisolti o estrazioni con un livello di affidabilità ridotto possono essere segnalati per una forte revisione manuale.
7. Revisione umana
I processi più delicati possono prevedere una fase di revisione prima della conferma dell’esito.
L’utente può approvare la proposta, correggere un metadato, modificare una regola, aggiungere una fonte mancante, indicare una relazione tra documenti o introdurre un’eccezione.
Ogni intervento viene registrato insieme all’informazione di quale utente abbia fatto un’integrazione, alla data, allo stato precedente e allo stato aggiornato. In questo modo è possibile aggiornare le logiche.
Gestione delle versioni
Non ci aspettiamo che i contratti le policy e le procedure rimangano statici, anzi sappiamo che variano nel tempo.
Il sistema deve quindi conservare le versioni rilevanti, i rispettivi periodi di validità, le relazioni tra i documenti e le regole estratte da ciascuna versione.
Lo stesso principio si applica agli esiti. Una valutazione precedente deve rimanere collegata ai documenti, alle regole e ai criteri di risoluzione disponibili nel momento in cui è stata prodotta.
Questa struttura consente di ricostruire la documentazione applicabile in una data specifica e di comprendere le ragioni di un determinato risultato.
Auditability
L’auditability è un criterio centrale nella progettazione di questa architettura.
Per ogni elaborazione, il sistema deve registrare i documenti disponibili, le versioni selezionate, i metadati utilizzati, le regole applicabili, i conflitti individuati, i criteri di risoluzione eseguiti e gli interventi umani successivi.
La tracciabilità supporta l’analisi degli errori, la manutenzione del sistema, i controlli interni e la progressiva formalizzazione delle regole aziendali.
Il ruolo dei modelli linguistici
I modelli linguistici possono supportare la classificazione dei documenti, l’estrazione dei metadati, l’identificazione delle clausole, la generazione di regole strutturate, l’individuazione di possibili conflitti e la produzione di spiegazioni per gli utenti.
Invece le componenti del sistema che incidono direttamente sulla priorità delle fonti e sull’applicabilità delle regole dovrebbero però utilizzare logiche esplicite.
Questa divisione permette di rendere maggiormente verificabile il processo.
L’architettura può prevedere anche soglie di affidabilità: le estrazioni con un livello di confidenza adeguato seguono il flusso ordinario, mentre i casi incerti o ambigui vengono sottoposti a un revisore autorizzato.
Il ruolo del RAG
Il RAG rimane utile per recuperare documenti e passaggi pertinenti, supportare la ricerca in linguaggio naturale, mostrare le evidenze e generare spiegazioni basate sulle fonti.
In questo sistema abbiamo però bisogno di un elemento, il rule resolution engine, che gestisca invece l’applicabilità, la priorità, la validità temporale e i conflitti tra le disposizioni.
L’architettura da noi adottata integra la ricerca documentale, la rappresentazione strutturata della knowledge base, l’esecuzione delle regole e soprattutto la tracciabilità e la supervisione umana.
In Estro progettiamo sistemi di intelligenza artificiale per processi aziendali in cui fonti, regole ed esiti devono rimanere verificabili.