Che cosa conta come prova quando la macchina è probabilistica?
La probabilità non è un verdetto
Quando una macchina restituisce 0.87, la prima domanda è di solito troppo piccola. Le persone chiedono se 0.87 sia alto. Alto rispetto a cosa, per quale esito, su quali casi e per quale decisione? Un numero stampato accanto a un output sembra una proprietà di quell'output. Spesso non lo è. È un tentativo di descrivere una relazione tra un modello, una popolazione definita di casi e un esito osservato nel tempo. Quella relazione può essere utile. Può guidare una coda di revisione, fissare una soglia o dire a un operatore quando un risultato merita un secondo sguardo. Ma non trasforma una singola previsione in un fatto con un decimale attaccato.
Questo è il punto scomodo al centro dei sistemi probabilistici. I loro output sono spesso più informativi di una semplice etichetta, perché possono esprimere gradi di supporto o incertezza. Sono anche più facili da sovrainterpretare. Un punteggio può essere trattato come una dichiarazione di un testimone, una conclusione legale, una diagnosi o un permesso. Per impostazione predefinita non è nessuna di queste cose. L'evidenza inizia quando l'organizzazione può dire cosa rappresenta il numero, come è stato verificato, dove si applica quella verifica e quale azione il numero è autorizzato a modificare.
Questa distinzione conta molto prima che un sistema incontri un regolatore. Un team può dover decidere se un documento suggerito richiede un controllo umano. Un acquirente può confrontare due fornitori che pubblicizzano entrambi misure di confidenza. Un operatore può impostare una regola di escalation. Un ente pubblico può chiedersi se una lista classificata sia abbastanza buona da influenzare dove va l'attenzione per prima. In ogni caso, un'esecuzione riuscita è evidenza di una cosa sola: che quella singola esecuzione ha prodotto un output. Non è ancora evidenza che il sistema meriti l'autorità che gli viene attribuita.
La risposta sensata non è bandire le probabilità dal lavoro consequenziale. È dare loro una descrizione del lavoro adeguata. Una probabilità può supportare una decisione quando è legata a un evento definito, a una popolazione pertinente, a un metodo di osservazione, a un confine di incertezza e a una regola per ciò che accade quando l'evidenza è debole. Questo è più lento che ammirare un singolo numero e molto più veloce che scoprire più tardi che nessuno può spiegare cosa il numero doveva fare.
L'evidenza deve nominare la sua domanda
L'evidenza non è mai semplicemente presente. È evidenza a favore di una proposizione. Un risultato di test può supportare la proposizione che un componente produca un determinato output per un determinato input in una determinata configurazione. Può supportare la proposizione che un modello classifichi bene gli esempi su un dataset di validazione. Può supportare la proposizione che una stima di probabilità corrisponda ragionevolmente da vicino alle frequenze osservate in un insieme di valutazione definito. Queste proposizioni sono diverse. La disciplina inizia scrivendo la proposizione prima di scegliere la metrica.
Si consideri l'affermazione apparentemente semplice che un sistema sia accurato. Accurato rispetto a cosa? Un'accuratezza di classificazione può descrivere quanto spesso la classe con punteggio più alto corrisponda a un'etichetta. Non dice se la probabilità dichiarata fosse ben calibrata. Una metrica di ranking può descrivere l'ordine, non la qualità della scala dei punteggi. Un errore medio basso può coesistere con un pattern di errore dannoso in un sottogruppo o a una soglia che attiva un'azione. La metrica non è sbagliata. Il salto dalla metrica alla conclusione operativa è dove di solito iniziano i problemi.
Il lavoro dell'OCSE sugli strumenti di valutazione è utile proprio perché rinuncia alla fantasia che un singolo punteggio possa sostenere l'intera spiegazione. Il suo quadro distingue aspetti tra cui copertura, scopo, realismo, affidabilità, riproducibilità, obiettività e parzialità. Questi non sono ornamenti burocratici attorno a un benchmark. Descrivono se il risultato ha la giusta relazione con la domanda posta. Un confronto di ricerca, una valutazione di conformità e una decisione di rilascio operativo possono tutti usare i test. Non chiedono la stessa cosa a quei test.
Si inizi, quindi, con una frase che possa essere contestata. Per esempio: questo sistema può instradare i casi per la revisione umana quando la sua stima di probabilità documentata per un esito definito supera una soglia specificata, a condizione che l'input corrisponda all'ambito validato e che il revisore mantenga l'autorità di rifiutare il suggerimento. Questa è una proposizione operativa discutibile. Nomina l'azione, la condizione e il confine. Non finge che un punteggio abbia scelto autonomamente il proprio ruolo nel mondo.
La frase contraria è familiare perché è comoda: il modello è sicuro all'87 per cento. Anche quando un modello emette davvero una probabilità, la frase omette l'evento, l'evidenza di calibrazione, la popolazione, il periodo e la decisione. Converte una relazione in un tratto di personalità. Le macchine non hanno bisogno di essere descritte come timide o sicure. Hanno bisogno di essere descritte come sistemi i cui output hanno significati definiti e limiti definiti.
La sicurezza non è la stessa cosa della correttezza
Un sistema può essere sicuro e sbagliato. Può anche essere corretto esprimendo una bassa sicurezza. Questi due fatti non sorprendono una volta che i termini vengono tenuti separati. La correttezza chiede se un esito corrisponda al riferimento scelto per un singolo caso. La sicurezza è una dichiarazione associata a un output, spesso derivata da un punteggio del modello o da una sua trasformazione. La calibrazione pone un'ulteriore domanda su molti casi: quando il sistema assegna probabilità simili, gli esiti si verificano all'incirca al tasso dichiarato? Queste sono domande correlate, ma una buona risposta non fornisce le altre.
Si immagini un insieme di casi per cui un classificatore riporta una probabilità di 0,80 per un evento definito. Se, su un insieme adeguatamente descritto e sufficientemente ampio di casi comparabili, l'evento si verifica circa otto volte su dieci, la stima può essere definita ben calibrata per quella popolazione e condizione. Ciò non significa che il prossimo caso con 0,80 abbia un destino all'ottanta per cento. Significa che il punteggio ha mostrato una relazione con gli esiti osservati nell'insieme dichiarato. L'espressione nell'insieme dichiarato fa la maggior parte del lavoro intellettuale.
La calibrazione non è nemmeno un distintivo universale. Un punteggio può essere ben calibrato su un dataset storico e scarsamente calibrato dopo che cambiano la sorgente dei dati in ingresso, la popolazione di utenti, il flusso di lavoro, il processo di etichettatura o le condizioni di implementazione. Può essere ben calibrato nel complesso ma comportarsi in modo diverso all'interno di una parte della popolazione che conta per il servizio. Può apparire buono in un raggruppamento ampio mentre nasconde una differenza marcata in prossimità della soglia decisionale. Un grafico di calibrazione non è un diploma incorniciato sopra il sistema in produzione. È un'osservazione datata con un ambito di validità.
La letteratura sulla calibrazione dei modelli rende concreta questa distinzione. Guo e colleghi hanno studiato la calibrazione della fiducia nelle reti neurali moderne e hanno mostrato che l'accuratezza da sola non stabilisce se le stime di fiducia rappresentino le probabilità osservate di correttezza. Il loro lavoro valuta anche metodi di calibrazione post-processing. La lezione operativa importante è più ristretta di una ricetta: non si deve presumere che un punteggio di un modello abbia un significato probabilistico appropriato solo perché viene fornito in un intervallo comodo tra zero e uno.
Un'organizzazione attenta registra quindi tre cose diverse. Registra le prestazioni sul compito, così può chiedersi se gli output soddisfano il compito definito. Registra la calibrazione o un'altra proprietà esplicita di incertezza, così può chiedersi cosa significhi il punteggio nella pratica. E registra la conseguenza di agire a una data soglia, così può chiedersi se la regola decisionale sia appropriata. Combinare le tre cose in un unico indicatore verde può semplificare una dashboard. Non semplifica il mondo.
La calibrazione ha un denominatore
Ogni affermazione sulla calibrazione ha un denominatore. Il denominatore non è semplicemente il numero di record in un file. È l'insieme dei casi che erano ammissibili a essere contati, il modo in cui sono stati raggruppati, la definizione dell'esito, il periodo di tempo, le esclusioni e il processo che ha prodotto le etichette di riferimento. Rimuovi queste condizioni e un diagramma di affidabilità diventa una curva piacevole senza alcuna giurisdizione su una decisione.
Supponiamo che una valutazione raggruppi le previsioni in base alla fiducia dichiarata. Il tasso osservato in ciascun gruppo dipende dai casi ammessi nel gruppo e dalla definizione dell'esito. I casi ambigui sono stati esclusi? Le astensioni sono state trattate come errori, rifiuti sicuri o qualcos'altro? L'etichetta rappresentava un evento immediato, una revisione successiva o un appello finale? I duplicati sono stati mantenuti? La valutazione includeva solo i record che avevano superato un passaggio di validazione a monte? Ogni risposta può essere ragionevole. Ogni risposta cambia il significato dell'affermazione di calibrazione che ne risulta.
Ecco perché un modello può avere un risultato di calibrazione globale rispettabile ed essere comunque inadatto a un uso specifico. Il risultato globale può aggregare lingue, lunghezze dei dati in ingresso, regioni, tipi di dispositivo, percorsi dei clienti o modalità operative che non condividono la stessa struttura di errore. Una cifra aggregata può essere un riepilogo onesto e comunque una prova insufficiente per una decisione locale. La risposta giusta non è pretendere un modello separato per ogni persona. È verificare le ipotesi di raggruppamento che la decisione stessa rende rilevanti.
Il quadro di valutazione dell'OCSE chiama questo aspetto copertura. Il quadro chiede se uno strumento di valutazione copra una distribuzione distorta o rappresentativa di ciò che intende misurare, e distingue le prestazioni sul compito da un'affermazione più ampia di capacità. Queste distinzioni sono utili per le prove basate sulle probabilità. Un punteggio può essere una prova sulle prestazioni rispetto a una distribuzione di compiti. Non dovrebbe diventare silenziosamente una prova su una capacità, una popolazione interessata o un contesto futuro che la valutazione non ha coperto.
Il denominatore ha anche un lato sociale. Quando un'organizzazione decide quali casi sono abbastanza semplici da automatizzare e quali devono attendere una persona, le definizioni determinano chi si fa carico dell'incertezza residua. Un punteggio aggregato può nascondere il fatto che un gruppo più piccolo ha meno esempi, etichette meno stabili o un contesto operativo diverso. Non è un motivo per promettere statistiche uguali dove le prove sono scarse. È un motivo per riportare chiaramente le prove scarse e per adottare una regola decisionale prudente al riguardo.
Un esito positivo è un campione, non una conclusione
I sistemi probabilistici invitano a una particolare forma di eccessiva fiducia perché sono così facili da dimostrare. Inserisci un input, ricevi un risultato impressionante, ripeti con un input simile, ne ricevi un altro. La dimostrazione può mostrare che il sistema è in grado di svolgere il compito. Può anche mostrare qualcosa che vale la pena indagare. Non può mostrare la distribuzione dei risultati, la stabilità del punteggio, la risposta ai casi limite, la qualità delle etichette di riferimento o l'effetto di una condizione di distribuzione modificata. Un campione può avviare un'indagine. Non può concluderla.
Lo stesso vale per una singola esecuzione di benchmark. Un risultato può essere stato raccolto correttamente, su un sistema ben descritto, con una metrica legittima. Se è stato eseguito una sola volta, è prova del valore osservato una volta in quelle condizioni. Non è automaticamente prova di una proprietà stabile del sistema. La ripetizione aiuta a far emergere la variazione. Non elimina la necessità di chiedersi se il test rappresenti l'uso previsto. Riproducibilità e validità risolvono problemi diversi, ed entrambe meritano un posto nella documentazione.
Il quadro dell'OECD rende esplicita questa separazione. L'affidabilità riguarda se una valutazione presenta ripetizioni, durata degli episodi o istanze sufficienti per dare una bassa variazione quando viene applicata di nuovo. La riproducibilità riguarda se lo stesso test può essere generato di nuovo, incluso se i componenti stocastici alterano le interazioni. Un test può essere esattamente riproducibile e rispondere comunque a una domanda inutile. Può essere realistico e difficile da riprodurre esattamente perché l'ambiente è cambiato. Nessuna delle due condizioni è di per sé un difetto. La documentazione deve dire quale condizione vale e cosa consente al lettore di dedurre.
C'è un'abitudine operativa modesta ma preziosa: conserva l'esito positivo, ma non fargli portare più di quanto possa. Preserva l'input, la configurazione, la versione, il seed dove applicabile, le dipendenze, l'output e la decisione di valutazione. Poi collocalo accanto a misurazioni ripetute, controesempi, astensioni e condizioni modificate. Un risultato che rimane utile dopo aver incontrato i suoi vicini scomodi vale più di un risultato che ha dovuto esserne protetto.
Per i sistemi generativi, una risposta corretta è una prova particolarmente debole di ripetibilità a meno che non venga registrato il contratto di interazione. Le impostazioni di campionamento, i prompt, il materiale recuperato, la disponibilità degli strumenti, la versione del modello, la policy di sicurezza e il flusso di lavoro circostante possono tutti influenzare il risultato. Riprodurre una sequenza di parole senza lo stato pertinente può ricreare l'aspetto di un test perdendo la condizione che lo rendeva significativo. Nel lavoro basato sulle prove, la somiglianza non è una riproduzione.
La ripetibilità non è un sinonimo di fiducia
Una riproduzione deterministica può essere un'ottima prova per una sola proposizione ristretta: date gli stessi input registrati, configurazione e condizioni di implementazione, il sistema ha prodotto lo stesso risultato. Questo rende più gestibili le indagini, i test di regressione e i confronti tra versioni. Non stabilisce che il risultato fosse corretto, che l'input fosse adeguato, che il sistema avrebbe dovuto essere usato per la decisione, o che il risultato si generalizzerà oltre il suo confine registrato. La ripetibilità è una proprietà dell'esperimento. La fiducia è un giudizio su un accordo più ampio.
Il comportamento stocastico modifica la registrazione, non giustifica la sua assenza. Se un output varia, la valutazione deve registrare quali parti variano, con quale frequenza, entro quale intervallo e in che modo tale variazione incide sulla decisione. Un sistema che propone formulazioni alternative può tollerare un intervallo più ampio rispetto a un sistema che classifica i casi per priorità di attenzione. Un sistema che consiglia un essere umano può richiedere prove diverse da uno che rende disponibile un'azione irreversibile. La probabilità non è di per sé una categoria operativa. È la conseguenza a determinare quanta incertezza un processo può gestire in sicurezza.
C'è un errore facile da commettere su entrambi i fronti. Un team pretende un output fisso da uno strumento il cui scopo dichiarato include l'esplorazione, e poi scambia il determinismo risultante per qualità. Un altro team accetta output variabili da un sistema di supporto alle decisioni, e poi definisce creativa la variabilità quando diventa difficile da valutare. Nessuna delle due posizioni è seria. La questione è se la variazione sia attesa, limitata, osservabile e compatibile con l'autorità assegnata al sistema.
La regolamentazione europea non riduce questa questione a un unico punteggio universale. Per i sistemi di IA ad alto rischio, l'articolo 15 dell'AI Act richiede un livello adeguato di accuratezza, robustezza e cybersicurezza, nonché prestazioni costanti sotto questi aspetti per tutto il ciclo di vita. Stabilisce inoltre che i livelli di accuratezza e le metriche di accuratezza pertinenti debbano essere indicati nelle istruzioni per l'uso e incoraggia l'adozione di benchmark e metodi di misurazione per gli aspetti tecnici della valutazione delle prestazioni. La disposizione non afferma che un singolo test ripetuto risolva la questione. Chiede che le prestazioni siano specificate e mantenute nel contesto.
Questo è l'atteggiamento sensato per qualsiasi valutazione seria. Un test ripetibile è un elemento della catena delle prove. Richiede un responsabile, un confine di versione, un trigger di modifica e un collegamento con la decisione operativa che supporta. Senza questi elementi, la riproducibilità può diventare un'altra parola accattivante che viaggia più lontano dell'esperimento.
L'incertezza richiede un percorso operativo
Lo scopo pratico dell'incertezza non è rendere una dashboard più sofisticata. È cambiare ciò che al sistema è consentito fare. Se un punteggio non ha alcun effetto su instradamento, revisione, spiegazione, monitoraggio o arresto, può essere una curiosità tecnica piuttosto che un segnale operativo. Se invece modifica un'azione, l'organizzazione deve dichiarare il percorso dal punteggio all'autorità.
Una soglia è uno di questi percorsi, ma non è una linea magica. Impostare una soglia significa selezionare un compromesso tra tipi di errore, carico di lavoro, ritardo e danno potenziale. Una soglia può essere appropriata per dare priorità a una coda di revisione a bassa conseguenza e inappropriata per negare a una persona l'accesso a un servizio. La stessa soglia numerica può significare cose diverse quando cambiano il tasso di base, il costo dell'errore, i mezzi di ricorso disponibili e la qualità della revisione a valle. Non esiste un numero prudente universale in attesa in un manuale del fornitore.
Per questo motivo, una regola decisionale dovrebbe descrivere più di un semplice cutoff. Dovrebbe indicare l'esito che si intende stimare, le prove che supportano il punteggio, i casi esclusi dall'ambito, le circostanze che impongono l'astensione, l'autorità umana che rimane, la registrazione che verrà conservata e le condizioni per rivedere la regola. Una soglia senza questi compagni è una decisione travestita da configurazione.
Un'ipotesi utile illustra il punto senza inventare un incidente pubblico. Si consideri un servizio che utilizza un punteggio del modello per ordinare le richieste in arrivo destinate a un revisore formato. Le prove potrebbero supportare un'affermazione limitata: il punteggio può aiutare a ordinare richieste comparabili all'interno di una categoria di intake dichiarata, mentre la priorità finale rimane interamente al revisore. Le stesse prove non supportano il rifiuto automatico delle richieste con punteggio basso, perché si tratta di un'azione diversa con conseguenze diverse e diverse esigenze di prova. L'output non è cambiato. È cambiata la sua autorità.
L'astensione merita la stessa serietà. Un sistema che può dichiarare che le sue prove sono insufficienti può creare più lavoro nel breve termine e ridurre gli errori non osservati nel lungo termine. Ma l'astensione è utile solo quando ha un luogo responsabile dove andare. Se i casi incerti finiscono in una coda senza proprietario, il sistema ha semplicemente convertito l'incertezza in ritardo. Un buon percorso indica chi riceve il caso, cosa può vedere, come lo corregge e come quella correzione informa le valutazioni successive.
Le affermazioni causali richiedono più di un grafico prima-dopo
Le stime di probabilità sono spesso usate per sostenere affermazioni su ciò che accadrà se un'organizzazione agisce. Questo è un compito probatorio diverso dal prevedere ciò che è accaduto nei dati storici. Un modello può stimare che un caso somigli ad altri casi con un certo esito. Non dimostra però che modificare il caso, cambiare una politica o seguire una raccomandazione farà cambiare l'esito. Previsione e intervento non dovrebbero essere fusi solo perché il grafico appare ordinato.
Le figure prima-dopo sono particolarmente seducenti. Un team introduce uno strumento, un esito cambia e allo strumento viene attribuito il merito o la colpa. Molte altre cose possono essere cambiate: la popolazione che accede al servizio, la documentazione, il personale, le politiche, le condizioni stagionali, i filtri a monte o la misurazione stessa. L'osservazione può meritare attenzione. Non è una conclusione causale finché il confronto, le spiegazioni alternative e l'incertezza residua non sono stati affrontati.
Questo è rilevante per la governance dell'IA perché un sistema può essere operativamente influente molto prima di essere formalmente decisivo. Una classifica può cambiare quale record una persona apre per primo. Un indicatore di confidenza può spingere un revisore ad accettare un output. Un'azione raccomandata può diventare routine perché la coda è piena. Il percorso causale include l'interpretazione umana, il design dell'interfaccia, gli incentivi, la pressione del tempo e il percorso di correzione disponibile. Valutare solo il modello non può raccontare l'intera storia.
Quando un'affermazione causale è importante, il piano probatorio dovrebbe indicare quale confronto renderebbe l'affermazione più credibile e cosa non potrebbe comunque escludere. Ciò può comportare un test controllato, un'implementazione graduale, una revisione indipendente, un disegno osservazionale accuratamente costruito o la decisione di astenersi del tutto da un'affermazione causale. Il punto non è esigere perfezione accademica da ogni cambiamento operativo. È allineare la fiducia dell'affermazione alle prove effettivamente disponibili.
C'è una sorta di buon senso olandese in questo, anche se viaggia bene: se hai solo misurato che il vento è cambiato, non annunciare di aver ridisegnato il meteo. Una previsione può essere preziosa senza diventare una storia sulla causalità. L'onestà non è una ritirata. È ciò che rende il risultato utilizzabile da chi deve decidere cosa fare dopo.
L'accuratezza può nascondere una cattiva regola decisionale
L'accuratezza è spesso utile e spesso insufficiente. Un sistema può raggiungere un'elevata accuratezza quando un esito è comune, offrendo però poco aiuto sui casi che contano di più. Può avere una media forte mentre si comporta male vicino alla soglia d'azione. Può fare previsioni corrette senza offrire stime di probabilità che supportino soglie sensate. Può sembrare di successo perché l'etichetta di riferimento è facile da prevedere, anche se l'etichetta stessa è un debole proxy per la decisione che il servizio deve prendere.
Nessuno di questi aspetti significa che l'accuratezza sia priva di significato. Significa che il lettore dovrebbe chiedersi cosa misura e cosa lascia fuori dall'inquadratura. L'AI Act riconosce questa esigenza di contesto nei suoi requisiti per le istruzioni per l'uso: la documentazione dei sistemi ad alto rischio deve includere caratteristiche e limiti di prestazione, la finalità prevista, le metriche di accuratezza pertinenti utilizzate per testare e validare il sistema, e le circostanze note o ragionevolmente prevedibili che possono influire sulle prestazioni attese. Una cifra di accuratezza diventa più utile quando le condizioni che la circondano restano collegate.
Una buona revisione operativa, quindi, indaga i modelli di errore, non solo i totali. Quali tipi di casi sono stati classificati erroneamente? Quali erano incerti? Quali casi sono stati esclusi o inviati per revisione? Cosa succede a un falso positivo, a un falso negativo, a una risposta ritardata o a un'astensione ingiustificata? Chi può rilevare il risultato, contestarlo e correggere il registro? Queste domande riportano la valutazione al servizio, invece di lasciarla al modello.
Può anche essere utile distinguere l'evidenza di un componente dall'evidenza di un flusso di lavoro. Un test di componente può stabilire le proprietà di un modello con input definiti. Una valutazione del flusso di lavoro può stabilire come interagiscono modello, interfaccia, dati, persone e policy. Un componente può avere una forte calibrazione dei punteggi mentre il flusso di lavoro produce un bias di automazione perché l'interfaccia nasconde l'incertezza. Un flusso di lavoro può avere un eccellente processo di revisione mentre si affida a un componente i cui dati di origine non corrispondono più all'ambito dichiarato. I test devono incontrarsi da qualche parte.
L'evidenza che ne risulta non è necessariamente un grande rapporto. Può essere un registro conciso e versionato se la decisione è circoscritta. Ciò che conta è che un'altra persona possa esaminare la proposizione, la popolazione, il metodo, il risultato, il limite e la decisione. La dimensione del file non determina la qualità del ragionamento. Un registro breve può essere rigoroso. Una grande presentazione può essere per lo più aria.
Il cambiamento trasforma l'evidenza di ieri in una domanda
Ogni risultato di valutazione ha una data, anche quando la data è nascosta. I modelli cambiano. I prompt cambiano. Le fonti di dati cambiano. Un modulo a monte acquisisce un campo. Un fornitore modifica una policy. Un team sposta un servizio in un altro ambiente. Un nuovo gruppo inizia a usare il sistema. Una metrica viene calcolata dopo un processo di revisione modificato. Ogni cambiamento può alterare la proposizione che l'evidenza precedente sosteneva.
La risposta giusta non è rieseguire ogni test dopo ogni modifica. È definire quali cambiamenti sono rilevanti per quali affermazioni. Un cambiamento di colore può non influire sulla calibrazione delle probabilità. Un nuovo canale di input può influirvi. Una policy di etichettatura rivista può alterare la definizione dell'esito. Una nuova versione del modello può cambiare sia le prestazioni sia l'interpretazione dei suoi punteggi. Un cambiamento nell'autorità attribuita al sistema può invalidare una regola decisionale anche se il modello rimane identico byte per byte. Il piano di test dovrebbe rendere visibili queste relazioni prima che una release sia conveniente.
L'articolo 9 dell'AI Act descrive un processo continuo e iterativo di gestione del rischio per i sistemi ad alto rischio lungo tutto il loro ciclo di vita. Il processo include l'identificazione e l'analisi dei rischi noti e ragionevolmente prevedibili, la stima e la valutazione dei rischi quando il sistema è usato come previsto e in condizioni di uso improprio ragionevolmente prevedibile, e l'adozione di misure di gestione del rischio. Il punto per la valutazione è diretto: l'evidenza non è una cerimonia una tantum al lancio. Appartiene a un sistema operativo di revisione, cambiamento e risposta.
Monitorare non significa raccogliere ogni segnale disponibile e sperare che un pattern si presenti da solo. Significa decidere quale osservazione potrebbe riaprire una richiesta. Un controllo di calibrazione può essere pianificato in base al periodo, al volume o a un cambiamento nel mix di input. Una soglia può essere rivista quando la pressione sulla coda altera la qualità della supervisione umana. Un cambiamento nella fonte può sospendere un utilizzo finché il test pertinente non viene ripetuto. Un piano di monitoraggio serio dice cosa viene osservato, da chi, rispetto a quale riferimento e quale azione ne consegue.
Questo è più impegnativo di una scheda modello archiviata il giorno dell'acquisto, ma è anche più utile. Un documento statico può preservare ciò che è stato dichiarato. Una registrazione vivente delle evidenze può mostrare se la dichiarazione ha ancora una collocazione. Per un sistema probabilistico, questa differenza è la differenza tra sapere che il punteggio esisteva e sapere se significa ancora ciò che il servizio pensa che significhi.
Le registrazioni consentono a un lettore successivo di dissentire in modo appropriato
Le evidenze hanno bisogno di memoria. Un revisore successivo non può valutare una dichiarazione da uno screenshot di un punteggio e dal ricordo della riunione. Ha bisogno dell'oggetto versionato: la domanda, le condizioni di input, il metodo di test o osservazione, il risultato, le esclusioni, l'incertezza, la decisione e il responsabile. Potrebbe anche aver bisogno di sapere cosa non è stato catturato. Una registrazione che rende visibili i propri punti ciechi è più utile di una registrazione dall'aspetto perfetto che lascia lo stato del sistema all'immaginazione.
Per i sistemi di IA ad alto rischio, l'AI Act richiede la registrazione automatica degli eventi per l'intero ciclo di vita del sistema, con capacità di registrazione adeguate alla finalità prevista e utili per identificare i rischi, supportare il monitoraggio post-commercializzazione e monitorare il funzionamento. Richiede inoltre che la documentazione tecnica sia redatta prima che un sistema sia immesso sul mercato e mantenuta aggiornata. Questi requisiti non sono semplicemente un invito a conservare più log. Sono un invito a rendere i log intelligibili in relazione a un sistema, a una finalità e a una decisione.
La tracciabilità è particolarmente importante quando la probabilità viene interpretata da una persona. Se un revisore vede un punteggio, la registrazione delle evidenze dovrebbe rendere possibile ricostruire a cosa era collegato il punteggio, come è stato presentato, quali dati o fonti erano in scope, cosa ha deciso il revisore e se è avvenuta una correzione successiva. Senza questa catena, un team può apprendere che un esito era sbagliato, ma non se il problema risiedeva nell'input, nel modello, nell'interfaccia, nella regola decisionale o nel processo umano che lo circonda.
In Dweve, AION è un piccolo esempio rilevante del principio più ampio, non un'affermazione che le evidenze possano essere ridotte alla crittografia. La sua descrizione pubblica dice che un produttore può emettere un certificato tipizzato insieme a un risultato e che AION verifica il certificato in modo indipendente rispetto alle premesse originali. Questo tipo di registrazione verificabile può rafforzare una proposizione ristretta sul fatto che un risultato derivi da premesse registrate. Non dimostra che le premesse fossero adeguate, che il compito fosse giusto o che l'uso fosse appropriato. Le evidenze richiedono sia verifica sia giudizio.
Vale la pena tenere presente questo limite perché previene un comune errore di categoria. Una traccia perfettamente conservata può mostrare cosa è accaduto. Non può rendere buona una domanda mal formulata. Una decisione riproducibile può comunque essere una decisione che non avrebbe mai dovuto essere automatizzata. La registrazione dovrebbe aiutare un lettore successivo a porsi entrambe le domande, non a rispondere prematuramente alla seconda.
La fiducia può essere onesta senza essere utile
Una probabilità ben calibrata può comunque non essere d'aiuto. Può essere troppo ampia per distinguere i casi che richiedono trattamenti diversi. Può arrivare troppo tardi per influire sulla decisione. Può essere legata a un esito su cui non si può intervenire. Può essere così incerta da richiedere la stessa revisione per ogni caso. Non sono fallimenti dell'onestà. Sono limiti di utilità, e vanno riconosciuti subito piuttosto che scoperti dopo aver costruito un flusso di lavoro attorno al punteggio.
Al contrario, un sistema utile non deve fingere di essere certo. Un segnale modesto può migliorare l'organizzazione del lavoro se ha uno scopo circoscritto e un percorso di revisione chiaro. Può aiutare un operatore a capire quali casi meritano un altro controllo della fonte. Può selezionare un piccolo insieme per la garanzia di qualità. Può far emergere un conflitto tra registrazioni. In questi usi, il requisito dell'evidenza riguarda se il segnale migliora il processo decisionale specifico senza introdurre nuovi errori o dipendenze inaccettabili. Il segnale non deve diventare un oracolo per guadagnarsi un posto.
Per questo lo scopo previsto deve guidare la valutazione. I principi dell'IA dell'OCSE richiedono informazioni significative sulle capacità e sui limiti dei sistemi, e tracciabilità in relazione a set di dati, processi e decisioni, così che gli output possano essere analizzati e le domande ricevere risposta. I principi richiedono anche un'adeguata supervisione e agenzia umana. L'implicazione pratica non è che ogni interfaccia debba mostrare una probabilità. È che l'evidenza e la spiegazione di un sistema dovrebbero adattarsi alla persona e alla decisione che ne sono coinvolte.
Non c'è alcun premio per esporre un valore di incertezza che l'utente non sa interpretare né su cui non sa agire. Un numero senza un percorso decisionale può creare il teatro della trasparenza. Dà alle persone qualcosa a cui puntare il dito e nessun modo per contestarlo. Meglio mostrare il confine rilevante in linguaggio semplice, come questo suggerimento è fuori dalla categoria validata, oppure questo risultato richiede una revisione perché l'evidenza disponibile è incompleta. La presentazione appropriata segue il controllo operativo, non il contrario.
Per lo stesso motivo, un punteggio di confidenza non dovrebbe essere trattato come una misura di valore morale, credibilità o diritto. È un'affermazione tecnica con un contratto di evidenza limitato. Può aiutare un processo. Non dovrebbe diventare un vago rango sociale solo perché la sua forma numerica lo fa sembrare decisivo.
L'organizzazione possiede l'inferenza
I fornitori possono mettere a disposizione modelli, documentazione, punteggi e risultati dei test. Non possono però possedere silenziosamente il significato di una decisione presa nell'ambito del servizio di qualcun altro. L'organizzazione che collega un output probabilistico a un'azione deve decidere su quale proposizione fare affidamento, quale popolazione è rilevante, quale soglia è accettabile, chi esamina le eccezioni, quali registrazioni conservare e quando le evidenze sono scadute. I contratti possono allocare i compiti. Non eliminano la necessità del giudizio.
Questo diventa evidente negli appalti. Un acquirente dovrebbe chiedere a un potenziale fornitore non solo una metrica di sintesi, ma anche la domanda di valutazione, la popolazione, le etichette, le esclusioni, le versioni, la variazione, il metodo di calibrazione se viene avanzata un'indicazione di probabilità, i limiti noti e la politica di aggiornamento. Il punto non è esigere una divulgazione che il fornitore non può legalmente fornire. È stabilire se l'acquirente può comprendere il confine dell'indicazione abbastanza bene da usarla in modo responsabile in un contesto operativo europeo.
La risposta può talvolta essere che le evidenze non sono adeguate all'uso previsto. Non è un processo di appalto fallito. È il processo di appalto che svolge il suo vero compito prima che l'organizzazione sia diventata dipendente da un punteggio non spiegato. Un uso più limitato e verificabile può comunque essere possibile. Un fornitore diverso può essere appropriato. Oppure la decisione può rimanere umana perché le evidenze e il percorso di correzione non sono abbastanza solidi da giustificare l'automazione. Dire di no fa parte della disciplina delle evidenze.
Le evidenze hanno anche bisogno di un proprietario nominato dopo il lancio. Qualcuno deve essere responsabile di verificare se la popolazione è cambiata, se le revisioni rivelano un nuovo modello di errore, se una soglia è ancora adatta al carico di lavoro, se le registrazioni possono essere interpretate e se un cambiamento attiva una nuova valutazione. Il proprietario non deve necessariamente eseguire personalmente ogni test. Ma se nessun ruolo possiede l'inferenza, il sistema acquisirà gradualmente autorità attraverso l'abitudine. L'abitudine è un povero sostituto di una registrazione delle decisioni.
La parte più difficile è spesso culturale. I team sono abituati a presentare i modelli di successo come prodotti e quelli non riusciti come ricerca. Le evidenze probabilistiche chiedono loro di preservare l'ambiguità nel mezzo: utili, limitate, monitorate e non ancora autorizzate a diventare più di quanto le evidenze supportino. Può sembrare meno entusiasmante. È più duraturo.
Cosa contiene una registrazione proporzionata delle evidenze
La registrazione appropriata dipende dall'uso. Uno strumento di supporto alla scrittura usato da un autore ha conseguenze diverse da un sistema che influenza l'accesso a un servizio pubblico. Tuttavia, una registrazione proporzionata ha una forma riconoscibile. Identifica l'indicazione e lo scopo previsto. Identifica il modello, la configurazione e il flusso di lavoro circostante. Definisce l'esito e la popolazione usati per valutare l'indicazione. Preserva il metodo, il risultato e i limiti significativi. Identifica la regola decisionale, il proprietario, il percorso di revisione e i fattori scatenanti del cambiamento. Ogni campo dà a un lettore successivo un punto da cui iniziare.
La registrazione dovrebbe distinguere la misurazione dall'interpretazione. Un'osservazione misurata potrebbe dire che, su un set di dati e un periodo specificati, un insieme dichiarato di punteggi corrispondeva a esiti osservati entro un intervallo descritto. Un'interpretazione potrebbe dire che questo supporta l'uso come segnale di ordinamento delle revisioni sotto controlli specificati. Una decisione potrebbe dire che il sistema può essere usato per quello scopo fino al verificarsi di un fattore scatenante dichiarato. Mettere tutte e tre le frasi sotto un'intestazione chiamata performance è efficiente solo se nessuno ha mai bisogno di contestare il ragionamento.
Dovrebbe anche rendere utilizzabili le incognite. Forse le etichette arrivano in ritardo. Forse un piccolo gruppo linguistico non ha abbastanza casi per una valutazione di calibrazione stabile. Forse la distribuzione è nuova e non esiste ancora alcuna evidenza operativa. Il registro può dichiararlo, imporre un limite temporaneo all'uso, organizzare ulteriori osservazioni o mantenere un percorso umano. Fingere che l'incognita sia stata risolta perché un modello ha prodotto un numero trasforma soltanto l'incertezza in una responsabilità non documentata.
La disciplina visiva è utile in questo caso. Traccia la catena dall'input al punteggio, dal punteggio alla spiegazione mostrata, dalla spiegazione all'azione umana e dall'azione all'esito osservato e alla correzione. Individua dove lo stato viene catturato, dove viene perso e dove una persona può fermare o invertire il percorso. Se il team non riesce a tracciare il percorso, difficilmente riuscirà a valutarlo. I diagrammi non sostituiscono l'evidenza. Impediscono che l'evidenza venga attribuita alla parte sbagliata del sistema.
Soprattutto, scrivi ciò che il registro non stabilisce. Potrebbe non stabilire la causalità. Potrebbe non stabilire l'equità tra tutti i gruppi. Potrebbe non stabilire il comportamento dopo un cambio di fornitore. Potrebbe non stabilire l'idoneità per un'azione di maggiore conseguenza. Queste non-affermazioni non sono una scusa. Sono ciò che impedisce a una valutazione limitata di essere usata come autorizzazione universale.
L'evidenza guadagna il diritto di restare incerta
Esiste la tentazione di pensare che l'obiettivo della valutazione sia eliminare l'incertezza. Spesso l'obiettivo migliore è localizzarla. Un sistema probabilistico non è difettoso perché non può trasformare ogni caso in una certezza. Diventa pericoloso quando l'organizzazione tratta l'incertezza come un dettaglio tecnico privato mentre concede all'output un'autorità pubblica. Il lavoro consiste nel decidere quale incertezza sia tollerabile, visibile e recuperabile per lo scopo in questione.
Questa decisione dovrebbe diventare più impegnativa man mano che aumentano le conseguenze. Un suggerimento a bassa conseguenza può richiedere un ambito chiaro, una limitazione visibile e una correzione facile. Un sistema che influenza diritti, sicurezza, accesso o opportunità materiali richiede evidenze più solide sull'intero processo, un monitoraggio più attento, un'autorità umana significativa e un percorso per contestare e rimediare. Il punteggio del modello non determina da solo questo standard. Lo determina l'effetto dell'agire in base ad esso.
Un singolo esito riuscito può comunque valere la pena di essere conservato. Potrebbe essere il primo esemplare di un registro utile. Potrebbe rivelare una capacità, una modalità di errore o una domanda che merita una valutazione adeguata. Ma dovrebbe rimanere un esemplare finché l'organizzazione non ha testato la proposizione su cui vuole fare affidamento. La distanza tra queste due cose è dove vive l'ingegneria responsabile.
Quindi la risposta a ciò che conta come evidenza quando la macchina è probabilistica non è un punteggio, un grafico o un'etichetta di conformità. È un argomento delimitato: questo output, per questa domanda, in questa popolazione e periodo, in queste condizioni, è stato osservato in questo modo; questo è ciò che possiamo dedurre; questo è ciò che non possiamo dedurre; e questa è l'azione che siamo, o non siamo, pronti a lasciare che cambi. Questo argomento non è affascinante. È ispezionabile, il che è meglio.