Collegare le prove di sovrapposizione alla decisione
Un modello di riparazione potrebbe aver già visto la patch che gli viene chiesto di produrre. Un repository che raccoglie scansioni cerebrali può assegnare due identificativi alla stessa persona.
Un esercizio matematico di addestramento può somigliare a una domanda del benchmark pur richiedendo di risolvere un problema diverso. In tutti e tre i casi si è spinti ad agire sulla base di una possibile sovrapposizione, e una decisione sbagliata ha un costo.
Le prove necessarie dipendono da ciò che si confronta. Gli studi usano la cronologia del codice, la revisione delle immagini e giudizi sul contenuto dei problemi per passare da possibili corrispondenze a conclusioni circoscritte agli ambiti esaminati.
Cosa comprenderai
Come può chi svolge un audit indagare una possibile esposizione alla patch di un benchmark quando i dati di addestramento del modello non sono divulgati?
Perché HAPPEN sottopone a revisione le scansioni cerebrali simili prima di collegare i record dei partecipanti?
Che cosa significa una rimozione errata nel campione di esercizi matematici esaminato, e che cosa lascia incerto quel campione?
Una patch già vista complica la valutazione
Immaginiamo di valutare un modello su una raccolta di bug software passati. Per ogni attività, il modello riceve una base di codice difettosa e deve produrre una correzione; la raccolta contiene anche la patch dello sviluppatore, usata per verificare il risultato.
È più difficile interpretare una correzione riuscita se quella patch era presente nei materiali usati per addestrare il modello. Il punteggio potrebbe riflettere una certa familiarità con la risposta, oltre alla capacità di risolvere il bug.
Il problema è concreto per i benchmark ricavati da repository pubblici. Le raccolte di codice usate per l’addestramento possono contenere copie dei repository salvate dopo l’integrazione di una patch; quindi, una copia successiva del progetto originale può ancora contenere la risposta del benchmark.
Tuttavia, trovare il repository in una raccolta pubblica non rivela che cosa abbia effettivamente visto un modello i cui dati di addestramento non sono divulgati. Per valutare il risultato del benchmark, chi svolge l’audit ha bisogno di prove sia sul progetto sia sulla patch specifica.
La domanda comune è quante prove servano per passare da una possibile corrispondenza a una decisione sui dati. In un benchmark di riparazione, confrontare la patch finale del modello con quella dello sviluppatore è un indizio imperfetto: il modello potrebbe elaborare una correzione simile oppure produrne una diversa dopo aver appreso l’idea originale.
Perciò, lo studio sul codice indaga la possibile esposizione senza usare la correzione finale come verifica diretta della memoria.
Come prosegue la lezione
Le scansioni simili richiedono una verifica
Una soglia può scartare problemi diversi
Collegare la verifica alla decisione