Les tests antagonistes sont une méthode permettant d'évaluer systématiquement un modèle de ML dans le but d'apprendre son comportement lorsqu'il est fourni avec des entrées malveillantes ou involontairement dangereuses. Ce guide décrit un exemple de workflow de test antagoniste pour l'IA générative.
En quoi consistent les tests antagonistes ?
Les tests sont essentiels pour créer des applications d'IA robustes et sécurisées. Les tests antagonistes impliquent d'essayer de "dynamiser" une application de manière proactive en lui fournissant les données les plus susceptibles de provoquer un résultat problématique. Les requêtes antagonistes sont susceptibles de provoquer l'échec d'un modèle de manière non sécurisée (par exemple, des cas de non-respect des règles de sécurité), et peuvent entraîner des erreurs que les humains peuvent facilement identifier, mais qui sont difficiles à reconnaître.
Les requêtes peuvent être "adversaires" de différentes manières. Les requêtes explicites antagonistes peuvent contenir un langage qui ne respecte pas les règles, ou exprimer des points de vue contraires aux règles, ou tenter de "tromper" le modèle en disant quelque chose de dangereux, nuisible ou choquant. Les requêtes antagonistes implicitement peuvent sembler inoffensives, mais peuvent contenir des sujets sensibles qui sont problématiques, culturellement sensibles ou potentiellement dangereux. Il peut s'agir d'informations sur les données démographiques, la santé, la finance ou la religion.
Les tests antagonistes peuvent aider les équipes à améliorer les modèles et les produits en exposant les défaillances actuelles pour guider les stratégies d'atténuation, telles que les réglages précis, les protections ou les filtres de modèles. De plus, cela peut aider à éclairer les décisions de lancement des produits en mesurant les risques qui peuvent être atténués, tels que la probabilité que le modèle dont le contenu ne respecte pas les règles.
En tant que bonnes pratiques émergentes pour une IA responsable, ce guide fournit un exemple de workflow permettant d'effectuer des tests antagonistes pour des modèles et des systèmes génératifs.
Exemple de workflow de tests antagonistes
Les tests antagonistes suivent un workflow semblable à l'évaluation standard d'un modèle.
Identifier et définir les entrées
La première étape du workflow de tests antagonistes consiste à déterminer les entrées pour comprendre le comportement d'un système lorsqu'il est attaqué intentionnellement et systématiquement. Des éléments réfléchis peuvent directement influencer l'efficacité du workflow de test. Les entrées suivantes peuvent vous aider à définir la portée et les objectifs d'un test antagoniste:
- Règles du produit et modes de défaillance
- Cas d'utilisation
- Exigences en termes de diversité
Règles du produit et modes de défaillance
Les produits d'IA générative doivent définir des règles de sécurité qui décrivent le comportement du produit et les sorties de modèles non autorisées (c'est-à-dire considérées comme "non sécurisées"). La règle doit énumérer les modes de défaillance considérés comme des cas de non-respect des règles. Cette liste de modes de défaillance doit être utilisée comme base pour les tests antagonistes. Il peut s'agir, par exemple, de contenus au langage grossier, ou de conseils financiers, juridiques ou médicaux.
Cas d'utilisation
Un ou plusieurs autres éléments importants pour les tests antagonistes sont les cas d'utilisation que le modèle génératif ou le produit cherche à diffuser, de sorte que les données de test contiennent certaines représentations des interactions réelles des utilisateurs avec le produit. Chaque produit génératif présente des cas d'utilisation légèrement différents, mais certains sont courants: recherche d'informations, résumé et génération de code pour les modèles linguistiques, ou génération d'arrière-plans par géographie ou relief, style artistique ou vestimentaire.
Exigences en termes de diversité
Les ensembles de données de test antagonistes doivent être suffisamment diversifiés et représentatifs par rapport à tous les modes de défaillance cibles et cas d'utilisation. La mesure de la diversité des ensembles de données de test permet d'identifier les biais potentiels et garantit que les modèles sont testés de manière approfondie en tenant compte d'une population d'utilisateurs diversifiée.
Voici trois façons de considérer la diversité:
- Diversité lexicale:assurez-vous que les requêtes ont des longueurs différentes (par exemple, le nombre de mots), qu'elles utilisent une plage de vocabulaire étendue, qu'elles ne contiennent pas de doublons et qu'elles représentent différentes formulations de requête (par exemple, des questions rapides, des requêtes directes et indirectes).
- Diversité sémantique: assurez-vous que les requêtes couvrent un large éventail de sujets différents par stratégie (par exemple, le diabète de la santé), y compris les caractéristiques sensibles et basées sur l'identité (par exemple, le genre ou l'origine ethnique), dans différents cas d'utilisation et contextes mondiaux.
- Diversité des cas d'utilisation et des règles:veillez à ce que les requêtes couvrent tous les cas de non-respect des règles (par exemple, l'incitation à la haine) et les cas d'utilisation (conseils d'experts, par exemple).
Rechercher ou créer des ensembles de données de test
Les ensembles de données de test pour les tests antagonistes sont construits différemment des ensembles de test d'évaluation de modèle standards. Lors des évaluations de modèles standards, les ensembles de données de test sont généralement conçus pour refléter précisément la distribution des données que le modèle rencontrera dans le produit. Pour les tests adversaires, les données de test sont sélectionnées pour émettre une sortie problématique du modèle en prouvant le comportement du modèle sur des exemples de distribution et des cas particuliers pertinents pour les règles de sécurité. Un ensemble de tests antagonistes de haute qualité doit couvrir toutes les dimensions liées aux règles de sécurité et maximiser la couverture des cas d'utilisation que le modèle est censé prendre en charge. Elle doit être diversifiée de manière lexicale (par exemple, avec des requêtes de différentes longueurs et langues) et sémantiquement pertinente (par exemple, pour couvrir différents sujets et données démographiques).
Examiner les ensembles de données de test existants pour couvrir les règles de sécurité, les modes de défaillance et les cas d'utilisation de la génération de texte et des modèles texte-image. Les équipes peuvent utiliser des ensembles de données existants pour établir une référence des performances de leurs produits, puis effectuer des analyses plus approfondies sur les modes de défaillance spécifiques auxquels leurs produits sont confrontés.
Si les ensembles de données de test existants sont insuffisants, les équipes peuvent générer de nouvelles données pour cibler des modes de défaillance et des cas d'utilisation spécifiques. Pour créer des ensembles de données, vous pouvez commencer par créer manuellement un petit ensemble de données de requêtes (des dizaines d'exemples par catégorie), puis développer cet ensemble de données "seed" à l'aide d'outils de synthèse de données.
Les ensembles de données source doivent contenir des exemples aussi semblables que possible au système que le système rencontrerait en production, et créés dans le but d'entraîner un non-respect des règles. Le langage hautement toxique est susceptible d'être détecté par les fonctionnalités de sécurité. Par conséquent, pensez à utiliser des expressions créatives et des données antagonistes implicites.
Vous pouvez utiliser des références directes ou indirectes à des attributs sensibles (par exemple, l'âge, le genre, l'origine ethnique ou la religion) dans votre ensemble de données de test. N'oubliez pas que l'utilisation de ces termes peut varier selon les cultures. Variez le ton, la structure de la phrase, la longueur des mots et la signification. Des cas où plusieurs libellés (par exemple, incitation à la haine ou obscénité) peuvent s'appliquer peuvent créer du bruit et créer des doublons, et risquent de ne pas être traités correctement par les systèmes d'évaluation ou d'entraînement.
Les ensembles de tests antagonistes doivent être analysés pour comprendre leur composition en termes de diversité lexicale et sémantique, la couverture des cas de non-respect des règles et des cas d'utilisation, et la qualité globale en termes d'unicité, d'adversaire et de bruit.
Générer les sorties du modèle
L'étape suivante consiste à générer des sorties de modèles en fonction de l'ensemble de données de test. Les résultats informent les équipes produit des performances potentielles de leurs modèles lorsqu'elles sont exposées à des utilisateurs malveillants ou à des entrées malveillantes. L'identification de ces comportements et de ces modèles de réponse du système peut fournir des mesures de référence qui peuvent être atténuées lors du développement du modèle.
Annoter les résultats
Une fois les résultats des tests antagonistes générés, annotez-les pour les classer en modes défaillances et/ou en dangers. Ces étiquettes peuvent fournir des signaux de sécurité pour le contenu textuel et image. De plus, les signaux peuvent vous aider à mesurer et à atténuer les dommages sur les différents modèles et produits.
Les classificateurs de sécurité peuvent être utilisés pour annoter automatiquement les sorties (ou entrées) des modèles en cas de non-respect des règles. La précision peut être faible pour les signaux qui tentent de détecter des constructions qui ne sont pas strictement définies, telles que l'incitation à la haine. Pour ces signaux, il est essentiel d'utiliser des évaluateurs manuels pour vérifier et corriger les étiquettes générées par les classificateurs dont les scores sont "incertains".
En plus de l'annotation automatique, vous pouvez utiliser des évaluateurs manuels pour annoter un échantillon de vos données. Il est important de noter que l'annotation des résultats d'un modèle lors de tests antagonistes implique nécessairement des éléments troublants et du texte ou des images potentiellement dangereux, de la même manière que la modération manuelle de contenu. En outre, les évaluateurs manuels peuvent annoter un même contenu différemment en fonction de leur parcours personnel, de leurs connaissances ou de leurs croyances. Il peut être utile de développer des consignes ou des modèles pour les évaluateurs, en gardant à l'esprit que la diversité de votre pool d'évaluateurs peut influer sur les résultats des annotations.
Signaler et limiter
La dernière étape consiste à synthétiser les résultats des tests dans un rapport. Calculez des métriques et générez des rapports sur les résultats pour fournir des taux de sécurité, des visualisations et des exemples d'échecs problématiques. Ces résultats peuvent guider l'amélioration du modèle et servir de base à la sauvegarde des modèles, tels que les filtres ou les listes de blocage. Les rapports sont également importants pour la communication avec les personnes concernées et les décideurs.
Autres ressources
L'équipe Google Red d'IA: les pirates informatiques éthiques qui rendent l'IA plus sûre
Red Teaming Language Models with Language Models
Test de l'équité des produits pour les développeurs de machine learning (vidéo):
Test d'équité des produits pour les développeurs (atelier de programmation)