Spiegabilità contro verificabilità: la parola magica che ogni fornitore di IA finanziaria usa (e cosa le manca)
Ogni fornitore FP&A promette una 'scatola di vetro'. La spiegabilità mostra come l'IA ha indovinato; la verificabilità lo dimostra contro il libro mastro, oppure si rifiuta di rispondere.
Di The Rexfin team
Apri la pagina della fiducia di quasi qualunque fornitore FP&A in questo momento e leggerai una qualche variante della stessa frase: la nostra IA e completamente osservabile, niente e una scatola nera, puoi fare clic destro su qualunque cella e vedere la logica. Ci sono serie di video di CTO con titoli come “Escaping the Black Box”. Ci sono diagrammi a scatola di vetro con piccole icone a lente d’ingrandimento su ogni output. L’intera categoria e convergita sullo stesso messaggio nel giro di circa diciotto mesi l’una dall’altra.
Nessuno di loro ti dira l’unica cosa che conta davvero: cosa succede quando l’IA non riesce a dimostrare un numero. Lo dichiara? O ti mostra una spiegazione molto convincente di una cifra che ha inventato?
Quel divario e la differenza tra spiegabilità e verificabilità, e in questo momento quasi tutto il mercato ti sta vendendo la prima mentre lascia intendere la seconda.
La spiegabilità ti mostra una ragione. La verificabilità ti mostra una fonte.
Spiegabilità significa che il sistema può narrare il proprio ragionamento. Chiedigli perché la spesa marketing del terzo trimestre appare così, e ti guidera attraverso i passaggi: ha estratto il conto del piano dei conti, ha applicato un filtro, ha sommato un intervallo, ha rettificato per un rateo. Quella narrazione e genuinamente utile. Da sola, però, non garantisce affatto che il numero sia corretto.
Ecco la parte che le demo a scatola di vetro tendono a sorvolare: un modello linguistico di grandi dimensioni può produrre una spiegazione fluida, strutturata, del tutto plausibile per un numero che ha allucinato. La spiegabilità e una proprietà della narrazione. Ti dice la forma del ragionamento che il modello sostiene di aver seguito. Non ti dice se quel ragionamento abbia mai toccato il libro mastro reale. Puoi fare clic destro su una cella e vedere una storia. La storia può essere sbagliata e leggersi comunque come sicura, ben organizzata, internamente coerente, perché generare una derivazione dall’aspetto plausibile è esattamente il tipo di compito in cui i modelli linguistici sono bravi, indipendentemente dal fatto che il numero sottostante sia reale.
La verificabilità e un’affermazione completamente diversa: il sistema non può produrre una risposta a meno che non possa dimostrarla contro dati sorgente. Non narrare un percorso plausibile per arrivarci, ma dimostrarlo, nel modo in cui lo dimostra un revisore, tracciando la cifra fino a una transazione specifica, una riga di bilancio o una scrittura riconciliata. Un sistema verificabile non ti mostra il suo ragionamento. Ti mostra la ricevuta. E fondamentalmente, se non esiste alcuna ricevuta, un sistema verificabile lo dichiara invece di ragionare comunque fino a un numero.
I due concetti non sono esattamente opposti. Un buon sistema dovrebbe avere entrambi. Ma risolvono modalità di guasto diverse, e i fornitori commercializzano quasi universalmente quella più facile da costruire.
| Spiegabilità | Verificabilità | |
|---|---|---|
| Cosa mostra | Il percorso di ragionamento che il modello sostiene di aver seguito | Il record sorgente a cui il numero si collega |
| Cosa dimostra | Che l’output suona derivato | Che l’output e derivato |
| Come fallisce | Narra con sicurezza un numero sbagliato | Non può fallire in silenzio: niente fonte, niente risposta |
| Facile da falsificare? | Si, una narrazione fluida costa poco a un LLM | No, o la citazione si risolve o non lo fa |
| Cosa ti viene detto quando l’IA non è sicura | Di solito niente; spiega comunque | Si rifiuta |
Perché la spiegabilità ha vinto ed e diventata tutto il vocabolario
Non è difficile capire perché “scatola di vetro” abbia conquistato la categoria. La spiegabilità e ottenibile con il modello che hai già. Lo istruisci a mostrare il proprio ragionamento, formatti la catena di pensiero come un’interfaccia a passaggi cliccabili, e hai una funzionalità pronta per una demo in uno o due sprint. Fa una bella figura. Risponde all’obiezione che gli acquirenti sollevano davvero ad alta voce (“non mi fido di una scatola nera”) senza richiedere alcun cambiamento nel modo in cui il numero è stato effettivamente prodotto sotto.
La verificabilità e un problema ingegneristico più difficile, perché richiede che il numero sia stato calcolato da qualche parte in modo deterministico e tracciabile fin dall’inizio, prima ancora che l’IA lo tocchi. Non puoi aggiungere retroattivamente una citazione a un numero che il modello ha calcolato dentro la propria testa. Se l’aritmetica è avvenuta dentro l’LLM, il che è spesso esattamente ciò che accade sotto una spiegazione fluida, non c’è alcuna scrittura contabile a cui puntare, solo una narrazione che ne ha l’aspetto. Il nostro articolo pilastro sulle allucinazioni IA nei dati finanziari approfondisce perché i modelli sbagliano l’aritmetica anche quando il retrieval è corretto, che è esattamente il guasto che una buona spiegazione può mascherare.
Così il mercato ha fatto su larga scala la cosa raggiungibile, le ha dato un vocabolario caldo e dall’aria trasparente, e quel vocabolario e diventato il segnale di fiducia, indipendentemente dal fatto che la pipeline sottostante sia davvero in grado di rifiutare.
Il test della demo in due domande
Non serve fare l’audit dell’architettura di nessuno per distinguere queste due cose. Servono due domande, poste in ordine, in qualunque demo di un fornitore.
Domanda 1: “Mostrami esattamente da dove viene questo numero.”
Quasi ogni fornitore supera questa prova ormai. Otterrai una cella evidenziata, una scheda al passaggio del mouse, un click-through verso “passaggi di ragionamento”. Questo testa la spiegabilità, e nel 2026 e ormai lo standard minimo: non distingue più tra fornitori.
Domanda 2: “Ora fallo rifiutare di rispondere. Chiedigli qualcosa che non può verificare, e mostrami che lo dichiara invece di indovinare.”
E questa la domanda che separa davvero il campo. Chiedi un numero per cui il sistema non ha una fonte pulita: una metrica che attraversa due sistemi non riconciliati, una cifra che richiede un’ipotesi che nessuno ha inserito, un periodo con una lacuna di dati. Un sistema costruito solo sulla spiegabilità di solito risponde comunque. Produrra un numero, lo avvolgera in una spiegazione fluida, e la spiegazione sembrera rifinita esattamente quanto quelle per i numeri che erano corretti. Questa e la trappola: non puoi vedere la differenza dall’esterno, perché la qualità della narrazione non peggiora quando il numero sottostante e fabbricato.
Un sistema verificabile fa qualcosa di diverso: si ferma. Ti dice che non può produrre quella cifra e ti dice perché, quale fonte manca, quale riconciliazione non ha chiuso, quale ipotesi non è mai stata confermata. Il rifiuto, su richiesta, davanti a te, e il segnale rivelatore. Se un fornitore non riesce a far rifiutare il proprio prodotto, ha costruito uno spiegatore, non un verificatore.
Cosa richiede davvero il rifiuto
Perché un sistema possa rifiutare in modo credibile, il rifiuto deve essere una proprietà strutturale, non un prompt di cortesia aggiunto da qualcuno. Significa che ogni numero che l’IA e autorizzata a dichiarare deve risolversi in una citazione contro una fonte riconciliata prima che l’IA sia autorizzata a dichiararlo, non dopo, come decorazione su una risposta già generata. Se la citazione non può essere risolta, la risposta non viene prodotta. Questo e il meccanismo cita-o-rifiuta: il modello ragiona e recupera, ma un livello deterministico sottostante verifica che ogni cifra si colleghi alla fonte prima che sia autorizzata a uscire. Niente fonte, niente output, indipendentemente da quanto sicuro si sentisse il ragionamento interno del modello.
Significa anche che il rifiuto deve sopravvivere al momento che conta di più: l’esportazione. Una demo che rifiuta educatamente in una finestra di chat non è la stessa garanzia di un sistema che non lascera raggiungere un pacchetto per il consiglio a un numero non verificato. E a questo serve un gate di esportazione: un blocco tecnico rigido sulla produzione di un documento, non un’etichetta di avviso che un utente può ignorare con un clic. Ed e importante essere specifici sul perché un punteggio di confidenza non sia un sostituto per nessuno dei due: una percentuale lascia comunque passare un numero a bassa confidenza con un avvertimento allegato, che e una versione più morbida dello stesso guasto della spiegabilità. Il nostro articolo su perché i punteggi di confidenza non bastano illustra dove questo approccio si rompe su tabelle finanziarie reali.
Il punto chiave
La spiegabilità risponde a “come hai ottenuto questo”. La verificabilità risponde a “puoi dimostrare che questo e reale”, ed e l’unica delle due disposta a dire di no. Ogni fornitore FP&A ora può mostrarti un percorso di ragionamento: quella corsa agli armamenti e finita, e non ti ha mai davvero protetto da una cifra allucinata che raggiunge un consiglio con una spiegazione sicura allegata. Il test che separa ancora il campo e se l’IA del fornitore può essere portata a rifiutare, su richiesta, quando il numero non c’è per dimostrarlo. Chiedilo nella demo. Se non riescono a produrre un rifiuto, hai scoperto di cosa e fatta davvero la loro scatola di vetro.
Rexfin e costruito attorno al rifiuto, non solo al percorso di ragionamento. Prenota una demo e chiedile di rifiutare.
Parte di Allucinazioni AI nei dati finanziari: fermare l'AI che inventa numeri