La ricerca degli ultimi anni ha dimostrato che i modelli di machine learning (ML) sono vulnerabili input contraddittori, in cui un avversario può creare input per alterare strategicamente l'output del modello (in classificazione dell'immagine, riconoscimento vocale, o rilevazione di frodi). Ad esempio, immagina di aver implementato un modello che identifica i tuoi dipendenti in base alle immagini dei loro volti. Come dimostrato nel white paper Accessoriare un crimine: attacchi reali e furtivi al riconoscimento facciale all'avanguardia, i dipendenti malintenzionati possono applicare modifiche sottili ma attentamente progettate alla propria immagine e ingannare il modello per autenticarli come altri dipendenti. Ovviamente, tali input contraddittori, soprattutto se in numero significativo, possono avere un impatto aziendale devastante.
Idealmente, vogliamo rilevare ogni volta che un input contraddittorio viene inviato al modello per quantificare l'impatto degli input contraddittori sul modello e sul business. A tal fine, un’ampia classe di metodi analizza i singoli input del modello per verificare il comportamento degli avversari. Tuttavia, la ricerca attiva sul machine learning contraddittorio ha portato a input sempre più sofisticati, molti dei quali sono noti per rendere inefficace il rilevamento. La ragione di questa lacuna è che è difficile trarre conclusioni da un input individuale sul fatto che sia contraddittorio o meno. A tal fine, una recente classe di metodi si concentra sui controlli a livello distributivo analizzando più input alla volta. L'idea chiave alla base di questi nuovi metodi è che considerare più input alla volta consente un'analisi statistica più potente che non è possibile con input individuali. Tuttavia, di fronte a un avversario determinato e con una profonda conoscenza del modello, anche questi metodi di rilevamento avanzati possono fallire.
Tuttavia possiamo sconfiggere anche questi avversari determinati fornendo ulteriori informazioni ai metodi di difesa. Nello specifico, invece di limitarsi ad analizzare gli input del modello, analizzare le rappresentazioni latenti raccolte dagli strati intermedi in una rete neurale profonda rafforza significativamente la difesa.
In questo post ti spiegheremo come rilevare gli input avversari utilizzando Monitor modello Amazon SageMaker ed Debugger di Amazon SageMaker per un modello di classificazione delle immagini ospitato su Amazon Sage Maker.
Per riprodurre i diversi passaggi e risultati elencati in questo post, clonare il repository rilevamento-campioni-contraddittori-utilizzando-sagemaker nell'istanza notebook Amazon SageMaker ed esegui il notebook.
Rilevamento di input contraddittori
Ti mostriamo come rilevare gli input avversari utilizzando le rappresentazioni raccolte da una rete neurale profonda. Le seguenti quattro immagini mostrano l'immagine di training originale a sinistra (presa dal dataset Tiny ImageNet) e tre immagini prodotte dall'attacco Projected Gradient Descent (PGD) [1] con diversi parametri di perturbazione ϵ. Il modello utilizzato qui era ResNet18. Il parametro ϵ definisce la quantità di rumore contraddittorio aggiunto alle immagini. L'immagine originale (a sinistra) è prevista correttamente come classe 67 (goose
). Le immagini 2, 3 e 4 modificate in modo contraddittorio sono erroneamente previste come classe 51 (mantis
) dal modello ResNet18. Possiamo anche vedere che le immagini generate con ϵ piccolo sono percettivamente indistinguibili dall'immagine di input originale.
Successivamente, creiamo una serie di immagini normali e contraddittorie e le utilizziamo Incorporamento di vicini stocastici distribuiti t (t-SNE [2]) per confrontare visivamente le loro distribuzioni. t-SNE è un metodo di riduzione della dimensionalità che mappa dati ad alta dimensione in uno spazio bidimensionale o tridimensionale. Ogni punto dati nell'immagine seguente presenta un'immagine di input. I punti dati arancioni presentano gli input normali presi dal set di test e i punti dati blu indicano le corrispondenti immagini avversarie generate con un epsilon di 2. Se gli input normali e contraddittori sono distinguibili, allora ci aspetteremmo cluster separati nella visualizzazione t-SNE. Poiché entrambi appartengono allo stesso cluster, ciò significa che una tecnica di rilevamento focalizzata esclusivamente sui cambiamenti nella distribuzione degli input del modello non è in grado di distinguere questi input.
Diamo uno sguardo più da vicino alle rappresentazioni dei livelli prodotte dai diversi livelli nel modello ResNet18. ResNet18 è composto da 18 livelli; nell'immagine seguente, visualizziamo gli incorporamenti t-SNE per le rappresentazioni di sei di questi strati.
Come mostra la figura precedente, gli input naturali e avversari diventano più distinguibili per gli strati più profondi del modello ResNet18.
Sulla base di queste osservazioni, utilizziamo un metodo statistico che misura la distinguibilità con test di ipotesi. Il metodo consiste in a prova a due campioni utilizzando massima discrepanza media (MMD). MMD è una metrica basata sul kernel per misurare la somiglianza tra due distribuzioni che generano i dati. Un test a due campioni prende due insiemi che contengono input tratti da due distribuzioni e determina se queste distribuzioni sono le stesse. Confrontiamo la distribuzione degli input osservati nei dati di addestramento e la confrontiamo con la distribuzione degli input ricevuti durante l'inferenza.
Il nostro metodo utilizza questi input per stimare il valore p utilizzando MMD. Se il valore p è maggiore di una soglia di significatività specifica dell'utente (5% nel nostro caso), concludiamo che entrambe le distribuzioni sono diverse. La soglia regola il compromesso tra falsi positivi e falsi negativi. Una soglia più alta, ad esempio il 10%, diminuisce il tasso di falsi negativi (ci sono meno casi in cui entrambe le distribuzioni erano diverse ma il test non è riuscito a indicarlo). Tuttavia, si ottengono anche più falsi positivi (il test indica che entrambe le distribuzioni sono diverse anche quando non è così). D'altra parte, una soglia più bassa, ad esempio l'1%, si traduce in un minor numero di falsi positivi ma in un maggior numero di falsi negativi.
Invece di applicare questo metodo esclusivamente sugli input grezzi del modello (immagini), utilizziamo le rappresentazioni latenti prodotte dagli strati intermedi del nostro modello. Per tenere conto della sua natura probabilistica, applichiamo il test di ipotesi 100 volte su 100 input naturali selezionati casualmente e 100 input contraddittori selezionati casualmente. Successivamente riportiamo il tasso di rilevamento come percentuale di test che hanno prodotto un evento di rilevamento in base alla nostra soglia di significatività del 5%. Il tasso di rilevamento più elevato è un’indicazione più forte che le due distribuzioni sono diverse. Questa procedura ci fornisce i seguenti tassi di rilevamento:
- Strato 1: 3%
- Strato 4: 7%
- Strato 8: 84%
- Strato 12: 95%
- Strato 14: 100%
- Strato 15: 100%
Negli strati iniziali il tasso di rilevamento è piuttosto basso (meno del 10%), ma aumenta fino al 100% negli strati più profondi. Utilizzando il test statistico, il metodo può rilevare con sicurezza gli input degli avversari negli strati più profondi. Spesso è sufficiente utilizzare semplicemente le rappresentazioni generate dal penultimo strato (l'ultimo strato prima dello strato di classificazione in un modello). Per input avversari più sofisticati, è utile utilizzare rappresentazioni di altri livelli e aggregare i tassi di rilevamento.
Panoramica della soluzione
Nella sezione precedente, abbiamo visto come rilevare gli input avversari utilizzando le rappresentazioni del penultimo livello. Successivamente, mostriamo come automatizzare questi test su SageMaker utilizzando Model Monitor e Debugger. Per questo esempio, addestriamo innanzitutto un modello ResNet18 di classificazione delle immagini sul piccolo set di dati ImageNet. Successivamente, distribuiamo il modello su SageMaker e creiamo una pianificazione Model Monitor personalizzata che esegue il test statistico. Successivamente, eseguiamo l'inferenza con input normali e contraddittori per vedere quanto è efficace il metodo.
Cattura tensori utilizzando Debugger
Durante l'addestramento del modello, utilizziamo Debugger per acquisire rappresentazioni generate dal penultimo livello, che vengono utilizzate successivamente per ricavare informazioni sulla distribuzione degli input normali. Il debugger è una funzionalità di SageMaker che consente di acquisire e analizzare informazioni quali parametri del modello, gradienti e attivazioni durante l'addestramento del modello. Questi parametri, gradiente e tensori di attivazione vengono caricati Servizio di archiviazione semplice Amazon (Amazon S3) mentre la formazione è in corso. È possibile configurare regole che li analizzino per problemi quali gradienti eccessivi e sfumati. Per il nostro caso d'uso, vogliamo catturare solo il penultimo livello del modello (.*avgpool_output
) e i risultati del modello (previsioni). Specifichiamo una configurazione di hook del debugger che definisce un'espressione regolare per le rappresentazioni dei livelli da raccogliere. Precisiamo inoltre a save_interval
che indica al Debugger di raccogliere questi dati durante la fase di validazione ogni 100 passaggi in avanti. Vedere il seguente codice:
Esegui la formazione SageMaker
Passiamo la configurazione del Debugger nello stimatore SageMaker e iniziamo l'addestramento:
Distribuire un modello di classificazione delle immagini
Una volta completato l'addestramento del modello, distribuiamo il modello come endpoint su SageMaker. Specifichiamo un script di inferenza che definisce il model_fn
ed transform_fn
funzioni. Queste funzioni specificano come viene caricato il modello e come i dati in ingresso devono essere preelaborati per eseguire l'inferenza del modello. Per il nostro caso d'uso, abilitiamo Debugger ad acquisire dati rilevanti durante l'inferenza. Nel model_fn
funzione, specifichiamo un hook del debugger e un file save_config
che specifica che per ogni richiesta di inferenza vengono registrati gli input del modello (immagini), gli output del modello (previsioni) e il penultimo livello (.*avgpool_output
). Registriamo quindi il gancio sul modello. Vedere il seguente codice:
Ora distribuiamo il modello, cosa che possiamo fare dal notebook in due modi. Possiamo chiamare pytorch_estimator.deploy()
oppure creare un modello PyTorch che punti ai file degli artefatti del modello in Amazon S3 creati dal processo di formazione SageMaker. In questo post facciamo quest'ultimo. Ciò ci consente di passare le variabili di ambiente nel contenitore Docker, che viene creato e distribuito da SageMaker. Abbiamo bisogno della variabile d'ambiente tensors_output
per indicare allo script dove caricare i tensori raccolti da SageMaker Debugger durante l'inferenza. Vedere il seguente codice:
Successivamente, distribuiamo il predittore su un tipo di istanza ml.m5.xlarge:
Crea una pianificazione personalizzata di Model Monitor
Quando l'endpoint è attivo e funzionante, creiamo una pianificazione Model Monitor personalizzata. Questo è un Lavoro di elaborazione SageMaker che viene eseguito su un intervallo periodico (ad esempio orario o giornaliero) e analizza i dati di inferenza. Model Monitor fornisce un contenitore preconfigurato che analizza e rileva la deriva dei dati. Nel nostro caso, vogliamo personalizzarlo per recuperare i dati del debugger ed eseguire il test a due campioni MMD sulle rappresentazioni dei livelli recuperate.
Per personalizzarlo, definiamo prima l'oggetto Model Monitor, che specifica su quale tipo di istanza verranno eseguiti questi lavori e la posizione del nostro contenitore Model Monitor personalizzato:
Vogliamo eseguire questo lavoro su base oraria, quindi specifichiamo CronExpressionGenerator.hourly()
e le posizioni di output in cui vengono caricati i risultati dell'analisi. Per questo dobbiamo definire ProcessingOutput
per l'output dell'elaborazione SageMaker:
Diamo un'occhiata più da vicino a cosa è in esecuzione il nostro contenitore Model Monitor personalizzato. Creiamo un copione di valutazione, che carica i dati acquisiti da Debugger. Creiamo anche a oggetto del processo, che ci consente di accedere, eseguire query e filtrare i dati salvati da Debugger. Con l'oggetto trial possiamo iterare sui passaggi salvati durante le fasi di inferenza e training trial.steps(mode)
.
Innanzitutto, recuperiamo gli output del modello (trial.tensor("ResNet_output_0")
) così come il penultimo strato (trial.tensor_names(regex=".*avgpool_output")
). Lo facciamo per le fasi di inferenza e convalida della formazione (modes.EVAL
ed modes.PREDICT
). I tensori della fase di validazione servono come stima della distribuzione normale, che poi utilizziamo per confrontare la distribuzione dei dati di inferenza. Abbiamo creato una classe LADI (Rilevamento delle distribuzioni di input contraddittori tramite statistiche a livello). Questa classe fornisce le funzionalità rilevanti per eseguire il test a due campioni. Prende l'elenco dei tensori dalle fasi di inferenza e validazione ed esegue il test a due campioni. Restituisce un tasso di rilevamento, ovvero un valore compreso tra 0 e 100%. Maggiore è il valore, maggiore è la probabilità che i dati di inferenza seguano una distribuzione diversa. Inoltre, calcoliamo un punteggio per ciascun campione che indica la probabilità che un campione sia contraddittorio e vengono registrati i primi 100 campioni, in modo che gli utenti possano esaminarli ulteriormente. Vedere il seguente codice:
Testare gli input avversari
Ora che la nostra pianificazione Model Monitor personalizzata è stata distribuita, possiamo produrre alcuni risultati di inferenza.
Innanzitutto, utilizziamo i dati del set di controllo e poi con input avversari:
Possiamo quindi controllare la visualizzazione del monitor del modello Amazon Sage Maker Studio o usare Amazon Cloud Watch logs per vedere se è stato trovato un problema.
Successivamente, utilizziamo gli input contraddittori contro il modello ospitato su SageMaker. Utilizziamo il set di dati di test del set di dati Tiny ImageNet e applichiamo l'attacco PGD, che introduce perturbazioni a livello di pixel in modo tale che il modello non riconosce le classi corrette. Nelle immagini seguenti, la colonna di sinistra mostra due immagini di prova originali, la colonna centrale mostra le loro versioni perturbate dall'avversario e la colonna di destra mostra la differenza tra entrambe le immagini.
Ora possiamo controllare lo stato del Model Monitor e vedere che alcune delle immagini di inferenza sono state tratte da una distribuzione diversa.
Risultati e azione dell'utente
Il lavoro Model Monitor personalizzato determina i punteggi per ogni richiesta di inferenza, che indica la probabilità che il campione sia contraddittorio secondo il test MMD. Questi punteggi vengono raccolti per tutte le richieste di inferenza. Il loro punteggio con il numero di passaggio del debugger corrispondente viene registrato in un file JSON e caricato su Amazon S3. Una volta completato il lavoro di monitoraggio del modello, scarichiamo il file JSON, recuperiamo i numeri dei passaggi e utilizziamo Debugger per recuperare gli input del modello corrispondenti per questi passaggi. Ciò ci consente di ispezionare le immagini che sono state rilevate come contraddittori.
Il seguente blocco di codice traccia le prime due immagini che sono state identificate come quelle che hanno maggiori probabilità di essere contraddittorie:
Nella nostra esecuzione di test di esempio, otteniamo il seguente output. L'immagine della medusa è stata erroneamente prevista come un'arancia e l'immagine del cammello come un panda. Ovviamente, il modello ha fallito su questi input e non ha nemmeno previsto una classe di immagini simile, come un pesce rosso o un cavallo. Per confronto, mostriamo anche i corrispondenti campioni naturali del set di test sul lato destro. Possiamo osservare che le perturbazioni casuali introdotte dall'aggressore sono molto visibili sullo sfondo di entrambe le immagini.
Il lavoro Model Monitor personalizzato pubblica la percentuale di rilevamento su CloudWatch, in modo che possiamo analizzare come questa percentuale è cambiata nel tempo. Un cambiamento significativo tra due punti dati può indicare che un avversario stava cercando di ingannare il modello in un intervallo di tempo specifico. Inoltre, puoi anche tracciare il numero di richieste di inferenza elaborate in ciascun lavoro Model Monitor e il tasso di rilevamento della linea di base, che viene calcolato sul set di dati di convalida. Il tasso di base è solitamente vicino a 0 e serve solo come metrica di confronto.
Lo screenshot seguente mostra le metriche generate dalle nostre esecuzioni di test, che hanno eseguito tre lavori di monitoraggio dei modelli nell'arco di 3 ore. Ogni lavoro elabora circa 200-300 richieste di inferenza alla volta. Il tasso di rilevamento è del 100% tra le 5:00 e le 6:00 e diminuisce successivamente.
Inoltre, possiamo anche ispezionare le distribuzioni delle rappresentazioni generate dagli strati intermedi del modello. Con Debugger possiamo accedere ai dati della fase di validazione del lavoro di training e ai tensori della fase di inferenza e utilizzare t-SNE per visualizzare la loro distribuzione per determinate classi previste. Vedere il seguente codice:
Nel nostro caso di test, otteniamo la seguente visualizzazione t-SNE per la seconda classe di immagini. Possiamo osservare che i campioni avversari sono raggruppati in modo diverso rispetto a quelli naturali.
Sommario
In questo post, abbiamo mostrato come utilizzare un test a due campioni utilizzando la massima discrepanza media per rilevare input contraddittori. Abbiamo dimostrato come distribuire tali meccanismi di rilevamento utilizzando Debugger e Model Monitor. Questo flusso di lavoro ti consente di monitorare i tuoi modelli ospitati su SageMaker su larga scala e di rilevare automaticamente gli input degli avversari. Per saperne di più, consulta il nostro Repository GitHub.
Riferimenti
[1] Aleksander Madry, Aleksandar Makelov, Ludwig Schmidt, Dimitris Tsipras e Adrian Vladu. Verso modelli di deep learning resistenti agli attacchi avversari. In Conferenza internazionale sulle rappresentazioni dell'apprendimento 2018.
[2] Laurens van der Maaten e Geoffrey Hinton. Visualizzazione dei dati utilizzando t-SNE. Journal of Machine Learning Research, 9:2579–2605, 2008. URL http://www.jmlr.org/papers/v9/vandermaaten08a.html.
Informazioni sugli autori
Nathalie Rauschmayr è Senior Applied Scientist presso AWS, dove aiuta i clienti a sviluppare applicazioni di deep learning.
Yigitcan Kaya è uno studente di dottorato al quinto anno presso l'Università del Maryland e uno stagista di scienziato applicato presso AWS, lavorando sulla sicurezza dell'apprendimento automatico e sulle applicazioni dell'apprendimento automatico per la sicurezza.
Bial Zafar è uno scienziato applicato presso AWS, che lavora su equità, spiegabilità e sicurezza nell'apprendimento automatico.
Sergul Aydore è uno scienziato applicato senior presso AWS che lavora su privacy e sicurezza nell'apprendimento automatico
- Coinsmart. Il miglior scambio di bitcoin e criptovalute d'Europa.
- Platoblockchain. Web3 Metaverse Intelligence. Conoscenza amplificata. ACCESSO LIBERO.
- Criptofalco. Radar Altcoin. Prova gratuita.
- Fonte: https://aws.amazon.com/blogs/machine-learning/detect-adversarial-inputs-using-amazon-sagemaker-model-monitor-and-amazon-sagemaker-debugger/
- "
- 10
- 100
- 67
- 9
- WRI
- accesso
- Secondo
- Il mio account
- attivo
- aggiuntivo
- Avanzate
- Tutti
- Amazon
- quantità
- .
- applicazioni
- AMMISSIONE
- circa
- AWS
- sfondo
- Linea di base
- base
- diventare
- essendo
- Bloccare
- affari
- chiamata
- catturare
- casi
- il cambiamento
- Controlli
- classe
- classi
- classificazione
- più vicino
- codice
- raccogliere
- Colonna
- Calcolare
- Convegno
- Configurazione
- Contenitore
- contribuire
- creato
- crimine
- costume
- Clienti
- dati
- più profondo
- Difesa
- dimostrato
- schierare
- schierato
- rilevato
- rivelazione
- sviluppare
- diverso
- difficile
- Dsiplay
- distribuzione
- docker
- non
- Efficace
- dipendenti
- enable
- endpoint
- Ambiente
- stima
- Evento
- esempio
- attenderti
- Faccia
- facce
- caratteristica
- figura
- Nome
- si concentra
- i seguenti
- Avanti
- essere trovato
- TELAIO
- pieno
- function
- ulteriormente
- la generazione di
- andando
- maggiore
- aiuta
- qui
- superiore
- Come
- Tutorial
- HTTPS
- idea
- Immagine
- Impact
- Index
- individuale
- informazioni
- ingresso
- indagare
- problema
- sicurezza
- IT
- Lavoro
- Offerte di lavoro
- rivista
- Le
- conoscenze
- conosciuto
- per il tuo brand
- grandi
- IMPARARE
- apprendimento
- Guidato
- Livello
- probabile
- Lista
- elencati
- località
- posizioni
- macchina
- machine learning
- Maps
- Maryland
- Metrica
- CON
- ML
- modello
- modelli
- Monitorare
- monitoraggio
- Scopri di più
- maggior parte
- multiplo
- Naturale
- Natura
- Rete
- Rumore
- normale
- taccuino
- numero
- numeri
- Altro
- percentuale
- fase
- punto
- possibile
- potente
- predire
- predizione
- Previsioni
- presenti
- Privacy
- Privacy e sicurezza
- i processi
- produrre
- Prodotto
- fornisce
- fornitura
- Crudo
- riconoscere
- registro
- Basic
- pertinente
- rapporto
- deposito
- richiesta
- richieste
- riparazioni
- Risultati
- problemi
- norme
- Correre
- running
- Scala
- Scienziato
- problemi di
- selezionato
- set
- significativa
- simile
- Un'espansione
- SIX
- piccole
- So
- alcuni
- sofisticato
- lo spazio
- in particolare
- inizia a
- state-of-the-art
- statistiche
- statistica
- stats
- Stato dei servizi
- conservazione
- studente
- test
- Testing
- test
- Attraverso
- tempo
- top
- verso
- Training
- prova
- Università
- us
- uso
- utenti
- generalmente
- APPREZZIAMO
- visibile
- visualizzazione
- Vulnerabile
- Che
- se
- while
- Whitepaper
- wikipedia
- lavoro
- sarebbe
- anno
- anni