Position, not importance: what a likelihood threshold actually defers on

Nel mondo dello sviluppo software, l'intelligenza artificiale si è evoluta da uno strumento che risponde semplicemente a domande in un partner che scrive codice insieme agli esseri umani. Questi assistenti digitali, spesso chiamati agenti di codifica, osservano ciò che un programmatore digita e poi suggeriscono le successive righe di codice per velocizzare il lavoro. La sfida centrale per questi sistemi è sapere quando fermarsi. Se l'assistente scrive troppo, potrebbe prendere una decisione critica per il programmatore, come scegliere un'impostazione di sicurezza o un comando del database, togliendo di fatto la tastiera prima che l'umano abbia la possibilità di revisionare la scelta. Se si ferma troppo presto, offre scarso aiuto. Per molto tempo, i ricercatori hanno sperato che un computer potesse imparare a riconoscere l'esatto momento in cui un essere umano debba intervenire misurando quanto il computer fosse "sorpreso" dalle proprie previsioni. La teoria era che quando un modello diventa incerto su ciò che viene dopo, è probabile che stia affrontando una decisione difficile o importante, e che questo sia il momento perfetto per fare una pausa e chiedere aiuto.

Uno studio recente si è proposto di testare questa teoria nell'ambiente ad alta posta in gioco della programmazione informatica. I ricercatori hanno costruito un ambiente di test specifico contenente centinaia di brevi frammenti di codice, alcuni dei quali contenevano scelte pericolose — come lasciare aperta una porta di sicurezza o usare un metodo di password debole — e altri che erano solo codice di routine innocuo. Hanno applicato una regola che diceva al computer di continuare a scrivere finché si sentiva fiducioso, fermandosi solo quando la fiducia cumulativa scendeva sotto una certa soglia. La speranza era che questa regola avrebbe naturalmente interrotto la scrittura prima delle scelte pericolose, permettendo all'umano di revisionarle. Tuttavia, i risultati hanno rivelato un disconnessione sorprendente. Il computer non si è fermato perché una scelta era pericolosa; si è fermato perché il testo era diventato difficile da prevedere. Nel mondo del codice, le scelte più pericolose sono spesso quelle più comuni e prevedibili, mentre il testo veramente sorprendente è spesso solo rumore casuale. Di conseguenza, il sistema ha spesso scritto interamente il codice pericoloso, mentre si è fermato bruscamente nel mezzo di un testo innocuo e noioso.

I ricercatori, guidati da Shubhanandan T Y e colleghi della Dayananda Sagar University, hanno costruito un benchmark dettagliato chiamato CEDE-Bench per misurare esattamente quanto spesso accada questo. Il test includeva 112 scenari specifici in cui un programmatore deve scegliere tra un percorso sicuro e uno rischioso, come decidere se disabilitare un controllo di sicurezza o come gestire una password. Hanno incluso anche 12 elementi di controllo innocui che non contenevano vere decisioni, solo codice boilerplate standard. Quando hanno eseguito la regola di arresto del computer su questi elementi, i risultati sono stati netti. Con l'impostazione utilizzata in uno studio precedente sugli utenti, il sistema ha scritto la branca pericolosa nel 33 percento dei casi. In alcuni casi, ha completato quasi un'intera query di un database SQL vulnerabile all'hacking, scrivendo diciotto dei diciannove token prima di fermarsi. Questo non è accaduto perché il computer non avesse visto il pericolo, ma perché il codice pericoloso era esattamente ciò che il computer si aspettava di vedere in base ai suoi dati di addestramento.

Lo studio ha scoperto che il comportamento del sistema era guidato quasi interamente da dove la decisione appariva nel testo, non da quale fosse la decisione. Se una scelta rischiosa appariva entro le prime parole di un suggerimento, il computer la scriveva quasi sempre. Se la stessa scelta rischiosa appariva più tardi, dopo che il computer aveva già esaurito il suo "budget" di parole fiduciose, si fermava prima di raggiungerla. I ricercatori hanno scoperto che la regola agisce meno come un giudice che valuta l'importanza di una decisione e più come un semplice contatore di token. Permette al computer di scrivere un certo numero di parole basate su quanto il testo circostante sia prevedibile, e poi si ferma. Poiché le scelte pericolose nel codice sono spesso molto prevedibili — come l'uso di una funzione standard ma insicura — esse rientrano in questa finestra iniziale e vengono scritte. Al contrario, il testo innocuo che contiene stringhe dall'aspetto casuale, come una chiave API falsa, è imprevedibile e causa l'arresto del computer, anche se non c'è alcun pericolo nel continuare.

Questo risultato mette in discussione l'idea che un computer possa imparare a delegare agli umani semplicemente misurando la propria incertezza. Lo studio ha dimostrato che il punto di arresto del sistema era statisticamente indistinguibile tra elementi pericolosi e innocui. Si è fermato nel mezzo di codice boilerplate benigno tanto spesso quanto si è fermato prima di codice pericoloso. I ricercatori hanno concluso che la regola è cieca rispetto all'importanza. Non sa che una specifica riga di codice potrebbe cancellare un database o far trapelare una password; sa solo quante parole ha scritto e quanto la parola successiva sembri sorprendente. Infatti, il sistema era più propenso a fermarsi su un elemento innocuo contenente una stringa dall'aspetto casuale che su un elemento pericoloso che seguiva un modello comune e prevedibile. Ciò significa che regolare la sensibilità della regola non può risolvere il problema: farla fermare prima significa solo far fermare il computer prima nella scrittura di codice utile, mentre farla fermare più tardi significa far scrivere più codice pericoloso.

Le implicazioni di questa scoperta sono significative per il modo in cui costruiamo e ci fidiamo degli assistenti AI. Lo studio suggerisce che affidarsi alla fiducia di un modello per decidere quando restituire il controllo a un essere umano è una strategia fallace nella programmazione. Il sistema non sta delegando all'umano perché l'input dell'umano è necessario per una decisione critica; sta delegando perché il testo è diventato matematicamente difficile da prevedere. I ricercatori hanno notato che nei loro test, il sistema ha completato solo circa un terzo del codice boilerplate innocuo prima di fermarsi, il che significa che interrompeva frequentemente il programmatore senza un buon motivo. Allo stesso tempo, non riusciva a fare una pausa per le decisioni più pericolose, che erano spesso le più routinarie e attese. Questo crea una situazione in cui l'assistente è o troppo intrusivo o troppo rischioso, senza una via di mezzo che soddisfi sia la sicurezza che l'utilità.

In definitiva, il documento sostiene che il meccanismo dietro questi assistenti AI necessita di un ripensamento fondamentale. L'approccio attuale, che assume che l'incertezza equivalga all'importanza, non regge nel mondo reale dello sviluppo software. I ricercatori propongono che, invece di cercare di insegnare al modello a riconoscere l'importanza attraverso l'incertezza, dovremmo utilizzare metodi più semplici e diretti per intercettare i pattern pericolosi, come i controllori di codice statico che cercano falle di sicurezza note. Questi strumenti non hanno bisogno di indovinare quando fermarsi; possono semplicemente segnalare specifici pattern rischiosi indipendentemente da quanto l'AI si senta sicura. Lo studio funge da chiaro avvertimento: sebbene gli assistenti AI possano essere utili, la loro capacità di sapere quando fermarsi non è un segno di saggezza o sicurezza, ma solo un riflesso di quanto il testo sia prevedibile. Finché la tecnologia non sarà in grado di distinguere tra una routine noiosa e una decisione critica, affidarsi a essa per compiere tali distinzioni da sola rimane una scommessa.