Angle d’Anderson

MLaaS : Prévenir le vol de modèles de machine learning avec des auto-encodeurs variationnels

mm
Ajouter Unite.AI à vos sources préférées sur Google

Le Machine Learning en tant que service (MLaaS) commercialise les fruits d’une recherche coûteuse et d’un entraînement de modèles via des API qui donnent accès aux clients à des informations issues du système. Même si la logique du système est inévitablement révélée à certains égards à travers ces transactions, l’architecture du modèle de base, les poids qui définissent l’utilité du modèle et les données d’entraînement spécifiques qui l’ont rendu utile sont jalousement gardés pour plusieurs raisons.

Tout d’abord, le cadre est susceptible d’avoir exploité un certain nombre de référentiels de code open source (FOSS), et les rivaux potentiels pourraient triviallement faire de même dans la poursuite des mêmes objectifs; deuxièmement, dans de nombreux cas, les poids utilisés par les modèles représentent 95 % ou plus de la capacité du modèle à interpréter les données d’entraînement mieux que les modèles rivaux, et constituent probablement la valeur fondamentale d’un investissement coûteux, à la fois en termes d’heures de recherche et d’entraînement de modèles à grande échelle et bien ressourcés sur des GPU de niveau industriel.

De plus, le mélange de données propriétaires et publiques derrière le jeu de données d’entraînement du modèle est une question potentiellement explosive: lorsque les données sont des « travaux originaux » obtenus par des méthodes coûteuses, la capacité d’un utilisateur d’API à déduire la structure ou le contenu des données via des requêtes autorisées par l’API pourrait lui permettre d’essentiellement reconstruire la valeur du travail, soit en comprenant le schéma des données (ce qui permet une reproduction pratique), soit en reproduisant les poids qui orchestrer les fonctionnalités des données, ce qui permet potentiellement la reproduction d’une architecture « vide » mais efficace dans laquelle des matériaux ultérieurs pourraient être utilement traités.

Blanchiment de données

En outre, la façon dont les données sont abstraites dans l’espace latent du modèle de machine learning pendant l’entraînement les « blanchit » effectivement en fonctions généralisées qui rendent difficile pour les détenteurs de droits d’auteur de comprendre si leur travail original a été assimilé sans autorisation dans un modèle.

L’actuel climat laissez-faire à travers le monde concernant cette pratique est susceptible de tomber sous une réglementation de plus en plus lourde au cours des 5 à 10 prochaines années. Le projet de réglementation de l’UE pour l’IA contient déjà des dispositions sur la provenance des données et un cadre de transparence qui rendrait difficile pour les sociétés de collecte de données de contourner les réglementations de domaine sur le scraping de données à des fins de recherche. D’autres gouvernements, y compris les États-Unis, s’engagent à des cadres réglementaires similaires à long terme.

À mesure que le domaine de la machine learning évolue d’une culture de preuve de concept en une écostructure commerciale viable, les modèles de machine learning qui ont enfreint les restrictions sur les données, même dans des versions antérieures de leurs produits, pourraient se retrouver exposés sur le plan juridique.

Par conséquent, le risque de déduction des sources de données sur les appels d’API ne concerne pas seulement l’espionnage industriel via l’inversion de modèle et d’autres méthodes, mais également les méthodes forensiques émergentes pour la protection de la propriété intellectuelle qui pourraient peser sur les entreprises après la fin de l’ère « Far West » de la recherche en machine learning.

Exfiltration basée sur l’API en tant que moyen de développer une attaque adverse

Certains cadres de machine learning mettent à jour constamment leurs données d’entraînement et algorithmes, plutôt que de dériver un modèle définitif et à long terme à partir d’un grand corpus de données historiques (comme GPT-3, par exemple). Ceux-ci incluent des systèmes liés aux informations sur la circulation et d’autres secteurs où les données en temps réel sont essentielles à la valeur continue d’un service de machine learning.

Si la logique ou le poids d’un modèle peut être « cartographié » en le sondant systématiquement via des API, ces facteurs peuvent potentiellement être tournés contre le système sous la forme d’attaques adverses, où des données malveillantes peuvent être laissées dans la nature, dans des zones où le système cible est susceptible de les récupérer; ou en infiltrant les routines d’acquisition de données par d’autres méthodes.

Par conséquent, les mesures contre la cartographie basée sur l’API ont des implications également pour la sécurité des modèles de machine learning.

Prévention de l’exfiltration basée sur l’API

Un certain nombre d’initiatives de recherche ont émergé ces dernières années pour fournir des méthodologies qui peuvent prévenir la déduction de l’architecture du modèle et des données sources spécifiques via les appels d’API. La dernière de ces initiatives est présentée dans un article de préimpression en collaboration entre des chercheurs de l’Indian Institute of Science à Bangalore et Nference, une plate-forme logicielle basée sur l’IA située à Cambridge, Massachusetts.

Intitulé Détection étatique des attaques d’extraction de modèles, la recherche propose un système appelé VarDetect, pour lequel le code préliminaire a été rendu disponible sur GitHub.

Exécuté sur le serveur, VarDetect surveille en continu les requêtes utilisateur à une API, recherchant trois modèles distincts d’attaques d’extraction de modèles répétitives. Les chercheurs rapportent que VarDetect est le premier mécanisme de défense de ce type à résister à ces trois types. De plus, il peut contrer les contre-mesures des attaquants qui deviennent conscients d’un mécanisme de défense et qui cherchent à le vaincre en cachant les modèles d’attaque avec des pauses ou en augmentant le volume des requêtes pour obscurcir les requêtes qui tentent de construire une carte du modèle.

L'architecture de VarDetect. Source: https://arxiv.org/pdf/2107.05166.pdf

L’architecture de VarDetect. Source: https://arxiv.org/pdf/2107.05166.pdf

VarDetect utilise des auto-encodeurs variationnels (VAE) pour créer efficacement une sonde évaluative de type heuristique pour les requêtes entrantes. Contrairement aux méthodes précédentes, le système est formé sur des données propriétaires, ce qui élimine le besoin d’accéder aux données des attaquants, une faiblesse des approches précédentes, et un scénario peu probable.

Le modèle personnalisé conçu pour le projet est dérivé de trois ensembles de données ou approches accessibles au public: le travail développé en 2016 par l’Institut fédéral suisse de technologie et Cornell Tech; en ajoutant du bruit aux données du « domaine problème », comme le montre pour la première fois le document PRADA de 2017 en Finlande; et en parcourant des images accessibles au public, inspiré par la recherche ActiveThief 2020 de l’Indian Institute of Science.

Une comparaison d'échantillons de données bénins et « malignes » à travers les cinq ensembles de données utilisés dans VarDetect.

Une comparaison d’échantillons de données bénins et « malignes » à travers les cinq ensembles de données utilisés dans VarDetect.

Les distributions de fréquence qui correspondent aux caractéristiques du jeu de données intégré seront signalées comme signaux d’extraction.

Les chercheurs reconnaissent que les modèles de requête ordinaires provenant d’utilisateurs bénins peuvent potentiellement déclencher de faux positifs dans le système, empêchant une utilisation normale. Par conséquent, ces signaux « sûrs » perçus peuvent ensuite être ajoutés au jeu de données VarDetect, étant incorporés dans l’algorithme via un calendrier de formation roulant, en fonction des préférences du système hôte.

Écrivain en apprentissage automatique, spécialiste de domaine en synthèse d'images humaines. Ancien responsable du contenu de recherche chez Metaphysic.ai, jusqu'à sa dissolution dans Brahma.ai de DNEG.
Portfolio site : martinanderson.ai
Contact : martin@martinanderson.ai