Analisi · Competenza

Da dove vengono davvero gli errori.

Il punteggio di un prototipo non dice che cosa correggere. Il gesto utile consiste nel riprendere i fallimenti uno per uno e decidere, per ciascuno, se viene dal sistema o da ciò che gli si è dato da applicare. Su un caso reale, la risposta ha riorientato la missione.

Un punteggio non dice che cosa correggere

Un prototipo documentale finisce sempre per produrre una percentuale. Il sistema tratta correttamente una certa proporzione dei casi, e la squadra si mette subito a discutere del modello: bisogna prenderne uno più grande, aggiustare le istruzioni, arricchire la ricerca.

Questa discussione è prematura, perché il punteggio non dice nulla su dove si trovi il difetto. Un sistema può fallire perché ha capito male la richiesta, perché ha riportato il documento sbagliato, o perché la risposta attesa non esiste da nessuna parte nel corpus normativo che gli è stato affidato. Questi tre fallimenti si assomigliano in una tabella di risultati e non richiedono affatto lo stesso lavoro.

Il solo gesto che li separa è noioso e non si automatizza: riprendere i fallimenti uno per uno e decidere, per ciascuno, dove si situa la causa.

Imputare ogni fallimento, uno per uno

Su un prototipo recente, abbiamo ripreso la totalità dei casi falliti e attribuito ciascuno a una causa unica. Il risultato ha riorientato la missione.

Più della metà dei fallimenti non veniva dal sistema. Veniva dal fatto che gli si chiedeva di applicare una regola che non era scritta da nessuna parte. Nessuna regolazione, nessun modello più performante, nessun miglioramento della ricerca vi cambia alcunché: la risposta giusta non esiste nel corpus.

Che cosa la soglia massima cambia a un progetto

Annunciare questa soglia a un cliente è scomodo, ed è la conversazione più utile della missione. Sposta il progetto da un cantiere tecnico verso un cantiere di dottrina: ciò che occorre produrre non è una migliore intelligenza artificiale, sono le regole mancanti, scritte, validate, opponibili.

Ha anche una conseguenza pratica. Ogni regola mancante diventa una riga identificata, con il numero di casi che sbloccherebbe. L'elenco delle lacune si gerarchizza dunque per volume, e la decisione di scrivere o meno una data regola si appoggia su una cifra anziché su un'impressione.

Va aggiunta una verifica che ha la sua importanza: una versione arricchita del corpus normativo ci è stata fornita nel corso della missione, e l'abbiamo ripassata sullo stesso campione anziché crederci sulla parola. Non ha colmato nessuna delle lacune individuate, e il suo effetto misurato si contava in una manciata di casi. Un arricchimento che alla lettura sembra sostanziale può non cambiare nulla là dove conta.

Prima le regole deterministiche, il modello in recupero

Il riflesso consiste nel far trattare tutti i casi dal modello. È il più rapido da costruire e il più difficile da difendere in seguito.

Noi procediamo nell'ordine inverso. Un insieme di regole deterministiche, scritte in codice, tratta anzitutto ciò che è decidibile senza interpretazione. Su questo prototipo, tali regole hanno assorbito più della metà del volume senza alcuna chiamata al modello, a parità di correttezza. Il modello interviene solo in recupero, su ciò che le regole non hanno saputo dirimere.

Tre benefici, in questo ordine di importanza. La parte deterministica è verificabile: si copre con test unitari, e una regressione si vede. È spiegabile a un revisore, cosa che nessuna uscita di modello è realmente. E non consuma nulla, il che sposta la questione del costo fuori dal dibattito.

Il corollario merita di essere detto: la proporzione di casi trattati senza modello è un indicatore di maturità del corpus normativo. Più è preciso, più la parte deterministica cresce. Un corpus vago spinge tutto verso l'interpretazione.

Richiamare per identificativo, mai per somiglianza

Un'obiezione ci è stata fatta nel corso della missione, ed era fondata. Il dispositivo presentava un accostamento tra il caso trattato e dei casi comparabili, il che dava l'impressione di un pulsante magico: il sistema troverebbe la risposta cercando ciò che assomiglia.

La risposta sta in una frase, ed è un punto di architettura. La risposta viene recuperata nel corpus normativo per identificativo, in modo deterministico. La somiglianza serve solo a completare la visualizzazione, mai a decidere. Il test che lo dimostra è semplice: si può sopprimere interamente l'accostamento per similarità senza cambiare una virgola al documento prodotto.

Non generare nulla di ciò che impegna

Su un documento che produce un effetto giuridico o contrattuale, la regola è assoluta: il modello non redige. Il testo di riferimento è riprodotto parola per parola dal corpus validato, e il modello si limita ad assemblare e a personalizzare ciò che deve esserlo.

Questo vincolo è più facile da tenere di quanto sembri, perché corrisponde a ciò che un professionista fa già: non reinventa una clausola, prende il modello validato e lo adatta. Un sistema che genera contenuto impegnativo non fa meglio di una persona, fa qualcosa che nessuno ha il diritto di fare.

Rendere visibile la lacuna, non soltanto il fallimento

Il dispositivo che ha permesso l'imputazione merita di essere descritto, perché è trasponibile. Abbiamo costituito un secondo corpus di riferimento, indipendente da quello del cliente, e viene consultato solo quando il corpus normativo principale resta muto sulla situazione.

Questo innesco condizionale fa tutta la differenza. Se i due corpus fossero interrogati insieme, il sistema risponderebbe meglio e nessuno vedrebbe che il corpus normativo del cliente era insufficiente: la lacuna sarebbe colmata silenziosamente. Chiamando il secondo solo in caso di silenzio del primo, ogni ricorso diventa un segnale, conteggiabile e imputabile a schermo.

È una scelta controintuitiva: degradiamo volontariamente la prestazione apparente del sistema per rendere visibile un'informazione. Questa informazione vale più dei punti di punteggio che costa.

L'errore che nessun modello migliore ridurrà

Una categoria di fallimento resiste a tutti i miglioramenti, ed è quella su cui lavoriamo adesso. Il sistema identifica correttamente la categoria del caso, recupera il documento previsto per quella categoria, e quel documento non tratta però la situazione particolare del fascicolo.

Nulla è falso nella catena. La classificazione è giusta, il recupero è giusto, e il risultato è inadeguato. Nessun modello più performante corregge questo, perché non c'è un errore di comprensione da correggere: manca una verifica, che consiste nel confrontare il contenuto del documento selezionato con il contenuto reale della richiesta, e nel rifiutare anziché consegnare quando il confronto fallisce.

Questa categoria è la ragione per cui diffidiamo delle tabelle di prestazione per fase. Una catena in cui ogni anello mostra un buon punteggio può produrre un risultato inutilizzabile, e solo una valutazione da un estremo all'altro, su casi mai visti durante la costruzione, lo rivela.

Ciò che si trasferisce

Quattro gesti, applicabili a qualunque sistema che applica un corpus normativo scritto a casi particolari.

Valutare su casi mai visti durante la costruzione, altrimenti il punteggio misura la memoria del sistema e non la sua capacità. Imputare ogni fallimento a una causa unica, il che costa ore e ne riorienta settimane. Calcolare la soglia massima a corpus normativo invariato, per sapere quanto dello scarto residuo dipende dall'informatica e quanto dalla scrittura. E strumentare il silenzio del corpus normativo, perché ciò che manca appaia invece di essere colmato senza rumore.

Il risultato di questo procedimento non è soltanto un sistema. È un elenco di regole mancanti, gerarchizzato per il numero di casi che sbloccherebbero, che il cliente conserva anche se cambia fornitore.

Esporci un problema →