On 27/11/2019, Stefano Quintarelli <stefano@quintarelli.it> wrote:
Reinforcing human centrality in AI through "Prediction Poisoning" https://5ta.it/90/ba6c
Molto interessante. Se ho capito, l'intuizione alla base del "redress by design" è quella che sta alla base di ogni sistema sicuro: progettare la sua evoluzione in modo che le dinamiche in essere minimizzino i rischi invece di accettarli come inevitabili e cercare di minimizzare i danni. E' la differenza fra (ad esempio) ridurre l'orario ed il carico di lavoro del macellaio per ridurre il rischio che si mozzi un dito, piuttosto che limitarsi a comprare un kit di pronto intervento "casomai" dovesse tagliarsi. Non deve dunque sorprenderti che il "redress by design" sia costoso. E' persino scontato: se non ottimizzi per il profitto (ovvero la riduzione dei costi) i costi saliranno inevitabilmente. Detto questo, credo che l'esempio che proponi sarebbe inefficace ed inefficiente. # Sul metodo: Ho l'impressione che tu parta (inconsapevolmente?) dall'obiettivo di massimizzare l'uso dell'AI per poi costruire un sistema che ne giustifichi l'adozione, ancor prima di migliorarne il funzionamento. E' un po' come scavare un fiume adatto per il ponte che vuoi costruire: cercare di inventare il problema adatto per una soluzione che ci piace. Per quanto i campioni della blockchain ci abbiano abituato a questa irrazionale inversione della dipendenza fra metodo e scopo, rimango molto scettico sulla efficacia di tale approccio metodologico (e preoccupato dalla sua evidente diffusione al di là dell'affascinante mondo dei ciarlatani) Prima di affrontare il "come" sarebbe meglio aver chiaro il "perché". Potrei sbagliare, ma la questione è effettivamente rilevante, come spero di riuscire a spiegare più avanti. # Sul merito: Quando introduci un software in una comunità, il sistema cibernetico che ne deriva non è più compatibile con le dinamiche precedenti. Il software è un agente automatico che modifica la percezione degli individui che vi interagiscono, in quanto elabora dati che questi interpretano come informazioni. Il sistema cibernetico va dunque sempre progettato nel suo complesso: non solo il software con l'utente immaginario (in quanto esistente solo nella immaginazione del programmatore), ma la comunità che scambia informazioni interagendo attraverso il software stesso. In questo senso il tuo articolo va nella direzione giusta. Ma non credo che il tipo di dinamica che proponi funzionerebbe. E i suoi limiti derivano forse dalla scarsa comprensione del dominio in questione. Anzitutto bisogna chiarire quali sono gli obiettivi. Vogliamo massimizzare le diagnosi corrette comunicate al paziente? Vogliamo minimizzare i costi per il SSN? Vogliamo minimizzare i rischi? Supponiamo che vogliamo minimizzare i costi per il SSN: quasi certamente l'ottimo comporta lasciar morire il più in fretta possibile alcuni pazienti che potrebbero condurre una vita decorosa ma con costi immensi per la collettività (a causa del mercato... ma questa è un'altra storia). Se vogliamo massimizzare le diagnosi corrette comunicate al paziente rischiamo di torturare inutilmente pazienti comunque inguaribili. Considera che in diversi ospedali gli oncologi rifiutano di comunicare diagnosi infauste al paziente e "delegano" il medico di famiglia. Ammettiamo comunque che ci basti massimizzare le diagnosi corrette. Se ogni paziente venisse visitato da 2 medici che non si conoscono, vengono da università e nazioni diverse e che si devono mettere d'accordo, è ovvio che la probabilità di errore diminuirebbe notevolmente. Più o meno come avviene nel Pair Programming. Ma la ragione per cui questa pratica funziona è che i due programmatori scrivono il codice insieme, letteralmente rubandosi la tastiera per poter scrivere e discutono insieme del problema comprendendolo più profondamente di quanto non farebbero ciascuno per conto proprio. La chiave però è sempre l'informazione in comune. I due medici, così come i due programmatori, COMUNICANO, mettono IN COMUNE le rispettive conoscenze e le differenti prospettive sul problema. L'AI ed il medico invece NON comunicano. (o meglio, l'AI comunicherà i dati del paziente pseudo-anonimizzati alla società americana che l'ha sviluppata, ma questa è un'altra storia). Il medico attinge alla propria esperienza, l'AI applica una funzione selezionata in modo pseudo casuale fra le infinite che approssimano statisticamente i punti noti entro un errore. Introdurre errori nei risultati conferiti al medico rischia solo di confonderlo, perché non ne può chiedere una spiegazione al "autore". Qual'è il vantaggio rispetto a non dirglieli affatto? Ma a quel punto, perché sprecare corrente nel calcolarli? (a parte ovviamente l'ovvio vantaggio di comunicare in silicon valley i dati del paziente! :-D) Il problema, NON è mantenere alto il livello di tensione del medico. Se lo fosse, potremmo fornire una pistola al paziente o (più economicamente) imporre al medico un massimo di 4 ore di lavoro al giorno. Se invece il problema è massimizzare la probabilità di diagnosi corrette, l'uso migliore che possiamo fare di una AI con "redress by design" è programmarla per SELEZIONARE DOMANDE da fare al medico e/o proporgli ulteriori esami ma SENZA suggerire il proprio output come diagnosi alternativa, in modo che il medico sia costretto a riconsiderare la diagnosi da una prospettiva diversa, ma senza subire un influenza dalle origini imperscrutabili. Al di là della responsabilità (che è un aspetto fondamentale di questa questione), al paziente non serve solo una diagnosi, ma una spiegazione. E non solo per ragioni psicologiche, ma propriamente terapeutiche. Se il software non è in grado di spiegare il proprio output, l'uomo invece può. Si tratta semplicemente di progettare il sistema cibernetico nel suo complesso: il software non rimpiazza l'uomo ma si integra in un processo nel quale aiuta l'uomo ad essere più efficace nel suo lavoro. Giacomo