MLaaS: Prevenire il Furto di Modelli tramite API con Autoencoder Variazionali

Machine Learning As a Service (MLaaS) rende accessibili i risultati di costose ricerche e addestramenti di modelli tramite API che forniscono ai clienti accesso alle informazioni del sistema. Sebbene la logica del sistema sia inevitabilmente rivelata in qualche misura attraverso queste transazioni, l’architettura del modello di base, i pesi che definiscono l’utilità del modello e i dati di addestramento specifici che lo hanno reso utile sono gelosamente custoditi per diverse ragioni.

In primo luogo, il framework ha probabilmente sfruttato una serie di repository di codice open source (FOSS) e potenziali rivali potrebbero facilmente fare altrettanto al fine di raggiungere gli stessi obiettivi; in secondo luogo, in molti casi i pesi utilizzati dai modelli rappresentano il 95% o più della capacità del modello di interpretare i dati di addestramento meglio dei modelli rivali e costituiscono probabilmente il valore principale di un costoso investimento, sia in termini di ore di ricerca che di addestramento di modelli su larga scala e ben risorsati su GPU di livello industriale.

Inoltre, la miscela di dati proprietari e pubblici dietro il set di dati di addestramento del modello è una questione potenzialmente incendiaria: laddove i dati sono “lavoro originale” ottenuto attraverso metodi costosi, la capacità di un utente API di inferire la struttura dei dati o il contenuto attraverso richieste API consentite potrebbe consentire loro di sostanzialmente ricostruire il valore del lavoro, sia comprendendo lo schema dei dati (consentendo una riproduzione pratica) o riproducendo i pesi che orchestrano le caratteristiche dei dati, il che potrebbe consentire la riproduzione di un’architettura “vuota” ma efficace nella quale potrebbero essere utilmente elaborati materiali successivi.

Lavaggio di Dati

Inoltre, il modo in cui i dati vengono astratti nello spazio latente del modello di apprendimento automatico durante l’addestramento li “lava” effettivamente in funzioni generalizzate che rendono difficile per i titolari del copyright capire se il loro lavoro originale sia stato assimilato senza autorizzazione in un modello.

Il clima attuale di laissez faire in tutto il mondo riguardo a questa pratica probabilmente cadrà sotto una regolamentazione sempre più pesante nei prossimi 5-10 anni. Le bozze di regolamentazione dell’UE per l’intelligenza artificiale contengono già disposizioni sulla provenienza dei dati e un quadro di trasparenza putativo che renderebbe difficile per le società di raccolta di dati eludere le norme di dominio sulla raccolta di dati per scopi di ricerca. Altri governi, tra cui gli Stati Uniti, stanno ora impegnandosi in quadri regolamentari simili nel lungo termine.

Man mano che il campo dell’apprendimento automatico evolve da una cultura di proof-of-concept a un’ecostruttura commerciale vitale, i modelli di apprendimento automatico che si trovano a violare le restrizioni sui dati, anche in iterazioni precedenti dei loro prodotti, potrebbero trovarsi esposti legalmente.

Pertanto, il rischio di inferire le fonti di dati tramite chiamate API non si riferisce solo alla spionaggio industriale tramite inversione del modello e altri metodi, ma anche a metodi forensi emergenti per la protezione della proprietà intellettuale che potrebbero gravare sulle aziende dopo la fine dell’era “wild west” della ricerca sull’apprendimento automatico.

Esfiltrazione guidata da API come mezzo per sviluppare un attacco avversario

Alcuni framework di apprendimento automatico aggiornano costantemente i loro dati di addestramento e algoritmi, piuttosto che derivare un modello definitivo e a lungo termine da un grande corpus di dati storici (come ad esempio GPT-3). Questi includono sistemi relativi alle informazioni sul traffico e altri settori in cui i dati in tempo reale sono fondamentali per il valore continuo di un servizio guidato dall’apprendimento automatico.

Se la logica o il peso dei dati di un modello può essere “mappato” sistematicamente sondando l’API, questi fattori possono potenzialmente essere rivolti contro il sistema sotto forma di attacchi avversari, dove i dati possono essere creati in modo malizioso e lasciati in giro in aree in cui il sistema di destinazione è probabile che li raccolga; o infiltrando le routine di acquisizione dei dati con altri metodi.

Pertanto, le misure contro la mappatura centrata sull’API hanno implicazioni anche per la sicurezza dei modelli di apprendimento automatico.

Prevenire l’esfiltrazione guidata da API

Sono sorti diversi iniziative di ricerca negli ultimi anni per fornire metodologie in grado di prevenire l’inferenza dell’architettura del modello e dei dati di origine specifici tramite chiamate API. L’ultima di queste è descritta in una collaborazione di pre-stampa tra ricercatori dell’Istituto indiano di scienza di Bangalore e Nference, una piattaforma software basata sull’intelligenza artificiale con sede a Cambridge, Massachusetts.

Intitolata Rilevamento stato dell’estrazione del modello, la ricerca propone un sistema chiamato VarDetect, per il quale è stato reso disponibile il codice preliminare su GitHub.

In esecuzione sul lato server, VarDetect monitora continuamente le query degli utenti a un’API, cercando tre modelli di attacchi di estrazione del modello ripetitivi. I ricercatori affermano che VarDetect è il primo meccanismo di difesa del suo genere a resistere a tutti e tre i tipi. Inoltre, può contrastare le contromisure degli aggressori che diventano consapevoli di un meccanismo di difesa e che cercano di sconfiggerlo nascondendo i modelli di attacco con pause o aumentando il volume delle query per oscurare le richieste che stanno cercando di creare una mappa del modello.

L’architettura di VarDetect. Fonte: https://arxiv.org/pdf/2107.05166.pdf

VarDetect utilizza autoencoder variazionali (VAE) per creare efficacemente una sonda valutativa di tipo euristico per le richieste in ingresso. A differenza dei metodi precedenti, il sistema è addestrato su dati proprietari, eliminando la necessità di accedere ai dati degli aggressori, una debolezza degli approcci precedenti e uno scenario improbabile.

Il modello personalizzato progettato per il progetto deriva da tre set di dati o approcci pubblicamente disponibili: il lavoro sviluppato nel 2016 dall’Istituto federale svizzero di tecnologia e Cornell Tech; aggiungendo rumore ai dati del “dominio problematico”, come dimostrato per la prima volta nel documento PRADA del 2017 dalla Finlandia; e strisciando immagini pubbliche, ispirato alla ricerca ActiveThief 2020 dall’Istituto indiano di scienza.

Un confronto tra campioni di dati benigni e ‘maligni’ nei cinque set di dati utilizzati in VarDetect.

Le distribuzioni di frequenza che corrispondono alle caratteristiche del set di dati a bordo saranno segnalate come segnali di estrazione.

I ricercatori ammettono che i modelli di richiesta ordinari degli utenti finali benigni possono potenzialmente scatenare falsi positivi nel sistema, impedendo l’utilizzo normale. Pertanto, tali segnali “sicuri” percepiti potrebbero essere aggiunti successivamente al set di dati VarDetect, diventando incorporati nell’algoritmo attraverso un calendario di addestramento rotolante, a seconda delle preferenze del sistema host.