Planification de la Red Team pour les modèles de langage volumineux (LLMs) et leurs applications
Ce guide propose des stratégies potentielles pour planifier la configuration et la gestion de la Red Team pour des risques d’IA responsable (RAI) tout au long du cycle de vie du produit du modèle de langage volumineux (LLM).
Qu’est-ce que la Red Team ?
Le terme Red Teaming a historiquement décrit les attaques contradictoires systématiques pour tester les failles de sécurité. Avec la montée en puissance des modèles de langage volumineux, le terme s’est étendu au-delà de la cybersécurité classique et a évolué dans l’utilisation courante pour décrire de nombreux types de sondages, de tests et d’attaques de systèmes d’IA. Avec les modèles LLM, l’utilisation bénigne et contradictoire peut produire des sorties potentiellement dangereuses, qui peuvent prendre de nombreuses formes, y compris du contenu nuisible tel qu’un discours de haine, une incitation à la violence ou une la glorification de la violence, ou du contenu sexuel.
Pourquoi l’adhésion à la Red Team RAI constitue-t-elle une bonne pratique ?
Le Red Teaming est une bonne pratique dans le développement responsable de systèmes et de fonctionnalités à l’aide de modèles LLM. Bien qu’ils ne remplacent pas le travail systématique de mesure et d’atténuation, les membres de la Red Team aident à découvrir, puis à identifier les dommages, puis, à leur tour, à activer les stratégies de mesure pour valider l’efficacité des atténuations.
Bien que Microsoft ait effectué des exercices d’association rouge et implémenté des systèmes de sécurité (y compris des filtres de contenu et d’autres stratégies d’atténuation) pour ses modèles Azure OpenAI Service (reportez-vous à cette vue d’ensemble des pratiquesd’IA responsable), le contexte de chaque application LLM sera unique et vous devez également effectuer une équipe rouge pour :
Testez le modèle de base LLM, puis déterminer s’il existe des lacunes dans les systèmes de sécurité existants, en fonction du contexte de votre application.
Identifier, puis atténuer les lacunes dans les filtres par défaut ou les stratégies d’atténuation existants.
Fournissez des commentaires sur les défaillances afin d’apporter des améliorations.
Notez que la Red Team n’est pas un remplacement de la mesure systématique. Une bonne pratique consiste à effectuer une première série d’adhésions à la Red Team avant de procéder à des mesures systématiques et de mettre en œuvre des mesures d’atténuation. Comme indiqué ci-dessus, l’objectif de la Red Team RAI est d’identifier les dommages, de comprendre la surface de risque et de développer la liste des dommages qui peuvent informer ce qui doit être mesuré et atténué.
Voici comment vous pouvez démarrer et planifier votre processus de LLM Red Teaming. La planification préalable est essentielle pour un exercice de Red Teaming productif.
Avant de tester
Plan : qui fera le test
Assemblez un groupe diversifié de membres de la Red Team.
Déterminez la composition idéale des membres de la Red Team en termes d’expérience, de données démographiques et d’expertise dans les disciplines (par exemple, des experts en IA, sciences sociales, sécurité) pour le domaine de votre produit. Par exemple, si vous reconcevez un chatbot pour aider les fournisseurs de soins de santé, des experts médicaux peuvent vous aider à identifier les risques dans ce domaine.
Recrutez des membres de la Red Team avec des états d’esprit à la fois bénins et contradictoires.
Il est essentiel d’avoir des membres de la Red Team dotés d’un état d’esprit contradictoire et d’une expérience de test de sécurité pour comprendre les risques de sécurité. Cependant, les membres de la Red Team qui sont des utilisateurs ordinaires de votre système d’application et qui n’ont pas été impliqués dans son développement peuvent apporter des perspectives précieuses sur les dommages que les utilisateurs réguliers risquent de rencontrer.
Affecter des membres de la Red Team à des fonctionnalités de préjudice et/ou de produit
Attribuez des membres de la Red Team RAI avec une expertise spécifique pour détecter des types spécifiques de dommages (par exemple, les experts en matière de sécurité peuvent sonder les jailbreaks, l’extraction de méta-invite et le contenu liés aux cyberattaques).
Pour plusieurs séries de tests, décidez s’il faut changer d’affectations des membres de la Red Team dans chaque tour pour obtenir diverses perspectives sur chaque préjudice et maintenir la créativité. Si vous changez d’affectation, laissez le temps aux membres de la Red Team de s’accélérer sur les instructions relatives à leurs dommages nouvellement attribués.
Dans les phases ultérieures, lorsque l’application et son interface utilisateur sont développées, vous pouvez affecter des membres de la Red Team à des parties spécifiques de l’application (c’est-à-dire des fonctionnalités) pour garantir la couverture de l’ensemble de l’application.
Considérez combien de temps et d’effort chaque membre de la Red Team doit consacrer (par exemple, ces tests pour les scénarios bénins peuvent nécessiter moins de temps que ceux pour les scénarios contradictoires).
Il peut être utile de fournir aux membres de la Red Team :
- Instructions claires qui peuvent inclure :
- Introduction décrivant le but et l’objectif de la série donnée d’association rouge ; le produit et les fonctionnalités qui seront testées et comment y accéder ; quels types de problèmes tester ; zones de focus des membres de la Red Team, si les tests sont plus ciblés ; combien de temps et d’effort chaque membre de la Red Team doit consacrer à des tests ; comment enregistrer les résultats ; et qui contacter en cas de questions.
- Un fichier ou un emplacement pour enregistrer leurs exemples et résultats, y compris des informations comme :
- Date à laquelle un exemple a été exposé ; identificateur unique pour la paire d’entrée/sortie si disponible, à des fins de reproductibilité ; invite d’entrée ; une description ou une capture d’écran de la sortie.
Plan : éléments à tester
Le développement d’une application s’effectue à l’aide d’un modèle de base. Par conséquent, vous devrez peut-être effectuer des tests sur plusieurs couches différentes :
Le modèle de base LLM avec son système de sécurité en place pour identifier les lacunes éventuelles à traiter dans le contexte de votre système d’application. (Le test s’effectue généralement au moyen d’un point de terminaison d’API.)
Votre application. (Le test est le mieux effectué par le biais d’une interface utilisateur.)
Le modèle de base LLM et votre application avant et après les atténuations sont en place.
Les recommandations suivantes vous permettent de choisir ce qu’il faut tester à différents points lors de l’association rouge :
Vous pouvez commencer par tester le modèle de base pour comprendre la surface de risque, identifier les dommages et guider le développement d’atténuations RAI pour votre produit.
Testez les versions de votre produit de manière itérative avec et sans atténuations RAI en place pour évaluer l’efficacité des atténuations RAI. (Notez que l’association rouge manuelle n’est peut-être pas suffisante : utilisez également des mesures systématiques, mais seulement après avoir terminé une série initiale d’association rouge manuelle.)
Dans la mesure du possible, testez les applications sur l’interface utilisateur de production, car c’est ce qui se rapproche le plus de l’utilisation réelle.
Lors de la présentation des résultats, il convient de préciser les points de terminaison utilisés pour les tests. Lorsque les tests ont été effectués sur un point de terminaison autre que le produit, envisagez de tester à nouveau sur le point de terminaison ou l’interface utilisateur de production lors des prochains cycles.
Plan : guide pratique pour tester
Effectuez des tests ouverts afin de découvrir un large éventail de préjudices.
Le fait que les membres de la Red Team RAI explorent et documentent tout contenu problématique (plutôt que de leur demander de trouver des exemples de préjudices spécifiques) leur permet d’explorer de manière créative un large éventail de questions et de mettre au jour les zones d’ombre dans votre compréhension de la surface du risque.
Créez une liste de dommages à partir des tests ouverts.
- Envisagez de créer une liste de préjudices, avec des définitions et des exemples.
- Fournissez cette liste en tant qu’instructions aux membres de la Red Team dans les séries ultérieures de tests.
Menez une équipe rouge guidée et itérez : continuez à rechercher des dommages dans la liste ; identifiez de nouveaux dommages à cette surface.
Cette liste servira de ligne directrice aux membres de l’équipe rouge lors des phases de test ultérieures. Au cours de ce processus, vous identifierez probablement de nouveaux préjudices. Intégrez-les à la liste et soyez prêt à modifier les priorités en matière de mesure et d’atténuation pour tenir compte des nouveaux préjudices identifiés.
Planifiez les préjudices à soumettre en priorité à des tests itératifs. Plusieurs facteurs peuvent informer votre hiérarchisation, y compris la gravité des préjudices et le contexte dans lequel ils sont plus susceptibles de se présenter.
Plan : comment enregistrer des données
Déterminez les données que vous devez collecter et de celles qui sont facultatives.
Déterminez les données que les membres de la Red Team devront enregistrer (par exemple, l’entrée qu’ils ont utilisée ; la sortie du système ; un ID unique, le cas échéant, pour reproduire l’exemple à l’avenir ; et d’autres remarques.)
Soyez stratégique dans le choix des données que vous collectez pour éviter de submerger les membres de la Red Team, sans pour autant passer à côté d’informations cruciales.
Créez une structure pour la collecte des données.
Une feuille de calcul Excel partagée est souvent la méthode la plus simple pour collecter des données de la Red Team. Un avantage de ce fichier partagé est que les membres de la Red Team peuvent passer en revue les exemples des uns des autres pour obtenir des idées créatives pour leurs propres tests et éviter la duplication des données.
Pendant les tests
Prévoyez d’être en attente active pendant l’adhésion à la Red Team.
- Soyez prêt à apporter votre aide aux membres de la Red Team concernant les instructions et les problèmes d’accès.
- Surveillez la progression de la feuille de calcul et envoyez des rappels opportuns aux membres de la Red Team.
Après chaque série de tests
Générer des rapports de données
Partagez un bref rapport sur un intervalle régulier avec les principales parties prenantes qui :
répertorie les principaux problèmes identifiés ;
fournit un lien vers les données brutes ;
affiche un aperçu du plan de test pour les prochaines séries ;
reconnaît les membres de la Red Team ;
fournit d’autres informations pertinentes.
Différenciez l’identification et la mesure.
Dans le rapport, veillez à préciser que le rôle de la Red Team RAI est d’exposer et de mieux faire comprendre la surface du risque. Elle ne remplace pas la mesure systématique et le travail rigoureux d’atténuation des risques. Il est important de ne pas interpréter des exemples spécifiques comme une mesure de l’omniprésence de ce préjudice.
En outre, si le rapport contient un contenu et des exemples problématiques, il convient d’envisager d’inclure un avertissement sur le contenu.
Les conseils contenus dans ce document ne sont pas des conseils juridiques et ne doivent pas être interprétés comme tels. La juridiction dans laquelle vous opérez peut avoir diverses exigences réglementaires ou légales qui s’appliquent à votre système d’IA. N’oubliez pas que toutes ces recommandations ne sont pas appropriées pour chaque scénario, et à l’inverse, ces recommandations peuvent être insuffisantes pour certains scénarios.