Une discussion sur les «exemples contradictoires n’est pas des bugs, ce sont des fonctionnalités»: fuite de fonctionnalités robuste
- Intelligence Artificielle
Noesis News- 0
- 82 minutes de lecture
Ilyas et al.
Nous montrons qu’au moins 23,5% (sur 88%) de la précision peuvent s’expliquer par des fonctionnalités robustes dans
. Il s’agit d’une limite inférieure faible, établie par un modèle linéaire, et ne perclule pas la possibilité d’une fuite supplémentaire. D’un autre côté, nous ne trouvons aucune preuve de fuite dans .
Fuite de délimitation inférieure
Notre technique de quantification des fuites comprenant deux étapes:
- Tout d’abord, nous construisons des fonctionnalités qui sont prouvés robustes, en un sens, nous spécifierons bientôt.
- Ensuite, nous formons un classificateur linéaire
à propos de sur les ensembles de données etÉquation 3
(DéfiniTableau 1) sur ces fonctionnalités robustes seulement.
Depuis Ilyas et al.
Pour au moins une des classes, la fonctionnalité est -Robustly utile
et l’ensemble de perturbations valides égales à un Boule de norme avec rayon 0,25.
La fonction provient d’un modèle robuste pour lequel au moins 80% des points de l’ensemble de tests ont des prédictions qui restent statiques dans un quartier de rayon 0,25 sur le Norm Ball.
Nous trouvons des fonctionnalités qui satisfont les deux Spécifications en utilisant les 10 caractéristiques linéaires d’un modèle linéaire robuste formé sur CIFAR-10. Parce que les fonctionnalités sont linéaires, les deux conditions ci-dessus peuvent être certifiées analytiquement. Nous laissons le lecteur pour inspecter les poids correspondant manuellement aux caractéristiques:
10 fonctionnalités, de classificateur linéaire robuste . Chaque fonctionnalité est -Robustly using en ce qui concerne l’étiquette . Visualisés sont les poids des caractéristiques .
Formation d’un modèle linéaire sur les fonctionnalités robustes ci-dessus et les tests sur l’ensemble de tests CIFAR entraînent une précision de 23,5% (sur 88%). Faire de même sur
entraîne une précision de 6,81% (sur 44%).
Les résultats contrastés suggèrent que les deux expériences doivent être interprétées différemment. Les résultats de transfert de dans le tableau 1 de
Les résultats de dans le tableau 1 de
Cependant, sont sur une base plus forte. Nous ne trouvons aucune preuve de fuite de fonctionnalités (en fait, nous trouvons une fuite négative – un afflux!). Nous concluons ainsi qu’il est plausible que la majorité de la précision est motivée par des caractéristiques non robustes, exactement la thèse de
ensemble de données (qui, comme le note le commentaire, a en fait trompeur fonctionnalités robustes). L’expérience fournie améliore encore notre compréhension du phénomène sous-jacent.
Réponse: Ce commentaire soulève une préoccupation valable qui était en fait l’une des principales raisons de la conception du ensemble de données. Rappelez-vous en particulier la construction du
Ensemble de données: attribuez à chaque entrée une étiquette cible aléatoire et faites un PGD vers cette étiquette. Notez que contrairement au ensemble de données (dans lequel la classe cible est choisie de manière déterministe), le
L’ensemble de données permet aux fonctionnalités robustes d’avoir réellement une (petite) corrélation positive avec l’étiquette.
Pour voir comment cela peut se produire, considérez le paramètre simple suivant: nous avons une seule fonctionnalité c’est pour les chats et pour les chiens. Si
alors est certainement une fonctionnalité robuste. Cependant, attribuer au hasard des étiquettes (comme dans l’ensemble de données ) rendrait cette fonctionnalité non corrélée avec l’étiquette attribuée, c’est-à-dire que nous aurions cela . Effectuer une attaque ciblée pourrait dans ce cas induire une certaine corrélation avec l’étiquette attribuée, comme nous aurions pu l’avoir permettant à un modèle d’apprendre à classer correctement les nouvelles entrées.
En d’autres termes, à partir d’un ensemble de données sans fonctionnalités, on peut coder des fonctionnalités robustes dans de petites perturbations. En revanche, dans le
ensemble de données, les fonctionnalités robustes sont corrélé avec l’étiquette d’origine (Étant donné que les étiquettes sont permutées) et comme elles sont robustes, elles ne peuvent pas être retournées pour être corrélées avec l’étiquette (mauvaise) nouvellement affectée. Pourtant, le L’ensemble de données nous permet de montrer que (a) des exemples adversaires basés sur la PGD modifient réellement les fonctionnalités des données et (b) les modèles peuvent apprendre des données de formation sans réalisation humain / mal étiquetées. Le
L’ensemble de données, en revanche, illustre que les fonctionnalités non-Robust sont en fait suffisantes pour la généralisation et peuvent être préférées à celles robustes dans des contextes naturels.
L’expérience présentée dans le commentaire est une manière intelligente de montrer qu’une telle fuite est en effet possible. Cependant, nous voulons souligner (comme le fait le commentaire lui-même) que la fuite de fonctionnalités robuste pas avoir un impact sur notre thèse principale – le L’ensemble de données contrôle explicitement la fuite de fonctionnalités robuste (et en fait, nous permet de quantifier la préférence des modèles pour les fonctionnalités robustes par rapport aux fonctionnalités non-Robust – voir l’annexe D.6 dans le
papier).
Remerciements
Shan Carter (a commencé le projet), Preettum (discussion technique), Chris Olah (discussion technique), Ria (discussion technique), Aditiya (rétroaction)
Références
- Les exemples contradictoires ne sont pas des bugs, ce sont des fonctionnalités
Ilyas, A., Santurkar, S., Tsipras, D., Engstrom, L., Tran, B. et Madry, A., 2019. Arxiv Preprint Arxiv: 1905.02175.
Mises à jour et corrections
Si vous voyez des erreurs ou souhaitez suggérer des modifications, veuillez Créer un problème sur Github.
Réutilisation
Les diagrammes et le texte sont sous licence Creative Commons Attribution CC-BY 4.0 avec Source disponible sur githubsauf indication contraire. Les chiffres qui ont été réutilisés à partir d’autres sources ne relèvent pas de cette licence et peuvent être reconnus par une note dans leur légende: «figure de…».
Citation
Pour l’attribution dans des contextes académiques, veuillez citer ce travail comme
Goh, "A Discussion of 'Adversarial Examples Are Not Bugs, They Are Features': Robust Feature Leakage", Distill, 2019.
Citation bibtex
@article{goh2019a,
author = {Goh, Gabriel},
title = {A Discussion of 'Adversarial Examples Are Not Bugs, They Are Features': Robust Feature Leakage},
journal = {Distill},
year = {2019},
note = {https://distill.pub/2019/advex-bugs-discussion/response-2},
doi = {10.23915/distill.00019.2}
}
