Nei sistemi RAG utilizzati per classificazioni ad alto rischio, affidare ogni caso ambiguo direttamente a un modello linguistico può rendere l’architettura semplice da sviluppare, ma introduce problemi rilevanti quando le decisioni devono essere ricostruite, giustificate e verificate a distanza di tempo. Nei contesti regolamentati non è sufficiente sapere che un LLM ha prodotto una determinata classificazione sulla base dei documenti recuperati: serve un percorso decisionale ripercorribile da un revisore umano senza dover rieseguire l’inferenza e senza dipendere dalla possibilità che il modello generi nuovamente la stessa risposta.
Una pipeline interamente basata su LLM presenta inoltre un problema di costo e latenza. Se ogni elemento elaborato genera una chiamata al modello accompagnata da più documenti inseriti nel contesto, il consumo di risorse cresce direttamente con il volume dei casi trattati. Questo comportamento è particolarmente penalizzante quando buona parte delle decisioni potrebbe essere risolta attraverso confronti deterministici, regole esplicite o verifiche su campi strutturati. L’impiego indiscriminato del modello introduce anche una forma di variabilità inutile nei casi semplici: una corrispondenza precisa con criteri già noti non richiede interpretazione probabilistica e non dovrebbe dipendere da un modello generativo.
Una possibile architettura consiste quindi nell’organizzare il sistema come una cascata nella quale il modello linguistico rappresenta il livello finale di escalation, anziché il primo meccanismo decisionale. La prima fase gestisce tutte le condizioni deterministiche, comprese corrispondenze esatte, confronti tra attributi strutturati e regole per le quali esiste un risultato inequivocabile. In molti dataset questa componente può assorbire oltre la metà del volume complessivo. Ogni decisione presa a questo livello è direttamente spiegabile perché deriva da un criterio esplicito, da una ricerca o da un confronto verificabile e non da un’inferenza generativa.
I casi che non possono essere chiusi in modo deterministico passano a una seconda fase dedicata al recupero delle informazioni. In questo livello il sistema deve individuare esclusivamente le prove utili a risolvere l’ambiguità specifica, come decisioni precedenti di revisori su situazioni comparabili, documenti che chiariscono un conflitto apparente o precedenti storici rilevanti. La qualità di questa fase è determinante perché un modello generativo, anche molto performante, può costruire una risposta coerente ma errata quando riceve un contesto non pertinente o incompleto. In una pipeline di questo tipo il recupero non è quindi un semplice supporto alla generazione, ma costituisce una parte centrale del processo decisionale.
Solo i casi che rimangono irrisolti dopo la logica deterministica e il recupero mirato raggiungono il terzo livello, nel quale interviene l’LLM. L’obiettivo è ridurre al minimo il numero di inferenze generative e riservarle ai casi nei quali servono effettivamente interpretazione, confronto tra elementi contrastanti e valutazione contestuale. In un sistema aziendale di questo tipo, l’instradamento verso il modello di appena il 10-15% dei casi realmente ambigui ha consentito di ridurre di circa sei volte i costi di inferenza rispetto a una configurazione nella quale ogni elemento veniva sottoposto all’LLM, mantenendo contemporaneamente una coerenza completa sui casi risolti tramite logica deterministica.
Quando la decisione arriva al livello generativo, anche la struttura del prompt deve tenere conto del tipo di rischio associato alla classificazione. Nei sistemi ad alto impatto il costo dei falsi positivi e quello dei falsi negativi raramente coincidono. Non identificare un caso che richiede effettivamente attenzione può produrre conseguenze molto più gravi rispetto alla segnalazione prudenziale di un elemento che un revisore umano potrà successivamente considerare corretto. Un prompt neutro che chiede semplicemente al modello di approvare o segnalare un caso non rappresenta questa asimmetria e lascia implicitamente al modello la scelta del compromesso.
Il prompt può invece esplicitare la struttura del rischio, indicando che l’incertezza deve tradursi in escalation anziché in approvazione automatica e fornendo esempi dei diversi tipi di errore accompagnati dalle relative conseguenze. In questa configurazione la classificazione non dovrebbe essere restituita come semplice risposta binaria, ma insieme a una stima di confidenza. Una soglia prestabilita può quindi determinare quali risultati siano sufficientemente affidabili per essere risolti automaticamente e quali debbano passare a un revisore umano, indipendentemente dalla classe indicata dal modello.
Anche la valutazione di un’architettura RAG a cascata richiede metriche differenti rispetto a quelle normalmente utilizzate per sistemi generativi generici. La qualità del recupero deve essere misurata separatamente dalla correttezza della classificazione finale, perché un ranking apparentemente efficace non garantisce che il modello utilizzi correttamente le prove fornite. È quindi necessario distinguere gli errori derivanti dalla selezione del contesto da quelli prodotti durante l’interpretazione e la generazione della decisione.
Il dataset di valutazione non dovrebbe inoltre replicare semplicemente la distribuzione del traffico di produzione. Poiché una grande percentuale dei casi viene risolta nelle prime fasi deterministicamente, un campione proporzionale rischierebbe di essere dominato proprio dagli esempi più semplici e di nascondere i problemi presenti nel livello generativo. Per valutare realmente la robustezza della cascata è utile sovracampionare intenzionalmente i casi che raggiungono il terzo stadio, concentrando le verifiche sulle situazioni nelle quali il sistema è costretto a esercitare un giudizio.
L’utilizzo di un altro LLM come giudice può essere applicato anche a questo scenario, ma il modello utilizzato per la valutazione deve adottare la stessa struttura di rischio prevista dal sistema in produzione. Se il giudice assegna lo stesso peso a falsi positivi e falsi negativi mentre l’applicazione considera uno dei due errori significativamente più grave, le metriche risultanti tenderanno a premiare una configurazione incompatibile con gli obiettivi effettivi del sistema.
Un ulteriore elemento dell’architettura è il ciclo di feedback proveniente dalla revisione umana. Quando un operatore modifica o ribalta una classificazione generata dall’LLM, il caso corretto e la motivazione della decisione possono essere inseriti nel corpus interrogato dalla fase di retrieval. In questo modo casi futuri con caratteristiche simili possono recuperare un precedente già validato, trasformando progressivamente una parte delle ambiguità in situazioni meglio documentate. Senza questo aggiornamento il sistema continua invece a incontrare gli stessi casi limite senza incorporare l’esito delle revisioni precedenti.
L’elemento centrale di una pipeline di questo tipo non consiste quindi nell’utilizzare il modello più potente disponibile per ogni decisione, ma nel delimitare con precisione quali parti del processo richiedano realmente un modello generativo. Le condizioni verificabili attraverso regole restano deterministiche, i documenti vengono recuperati solo quando servono a chiarire una situazione specifica e l’LLM viene coinvolto come meccanismo di escalation per il residuo realmente ambiguo. Nei sistemi sottoposti a controlli di conformità o audit, questa separazione rende possibile conservare per ogni decisione la regola applicata, le evidenze recuperate, l’eventuale output del modello, il relativo livello di confidenza e l’intervento successivo di un revisore umano, costruendo una catena decisionale che può essere ricostruita anche mesi dopo.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)