💬 NLP

Red-Teaming Text-to-Image Models via In-Context Experience Replay and Semantic-Preserving Prompt Rewriting

Le papier présente ICER, un cadre en boîte noire qui exploite un réécrivain basé sur un LLM et une relecture d'expérience en contexte pour générer efficacement des prompts adversariaux fluides et préservant le sens destinés au red-teaming des modèles texte-à-image, démontrant des performances supérieures et une transférabilité accrue à travers divers mécanismes de sécurité par rapport aux bases de référence existantes.

Auteurs originaux : Zhi-Yi Chin, Pin-Yu Chen, Wei-Chen Chiu, Mario Fritz

Publié 2026-05-13

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Zhi-Yi Chin, Pin-Yu Chen, Wei-Chen Chiu, Mario Fritz

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous avez un gardien de galerie d'art très strict et haute technologie (le Modèle Texte-vers-Image) dont le travail consiste à empêcher quiconque de créer des peintures violentes, nues ou autrement inappropriées. Le gardien est intelligent ; il lit votre demande et, s'il sent quelque chose de « mauvais », il refuse de peindre.

Le problème est que les mauvais acteurs (ou les chercheurs tentant de trouver des failles dans le système) essaient de tromper ce gardien. Ils veulent savoir : Puis-je demander une peinture d'une « personne nue » sans prononcer réellement le mot « nu » ?

L'Ancienne Méthode : Deviner et Vérifier

Auparavant, les chercheurs tentaient de tromper le gardien de deux manières principales :

Le « Pirate Robot » (Boîte blanche) : Cela nécessite de connaître le code secret et le câblage interne du gardien. C'est comme avoir les plans de la caméra de sécurité. Cela fonctionne bien, mais vous ne pouvez pas le faire sur des applications commerciales (comme DALL·E 3) car vous n'avez pas les plans. De plus, les « astuces » qu'ils inventent ressemblent souvent à du charabia (par exemple, « nakednips nips surrounded enthrshy »), ce qui est facile pour un humain de repérer comme faux.
Le « Bavard Aléatoire » (Boîte noire) : Cela tente de deviner l'astuce sans voir le code. Mais cela traite chaque tentative comme un tout nouveau jeu. Si cela échoue 100 fois, il oublie ce qu'il a appris et recommence à zéro. C'est comme un étudiant passant un examen, échouant, jetant ses notes, et repassant le même examen sans étudier. C'est lent, coûteux, et produit souvent des phrases étranges et non naturelles.

La Nouvelle Méthode : ICER (L'Approche « Livre de Jeu »)

Les auteurs de cet article ont créé un nouvel outil appelé ICER. Considérez ICER non pas comme un seul pirate, mais comme un entraîneur intelligent avec un livre de jeu.

Voici comment cela fonctionne, en utilisant une analogie simple :

1. Le « Livre de Jeu » (Rejeu d'Expérience en Contexte)

Imaginez une équipe d'espions essayant de passer inaperçus devant un gardien. Au lieu que chaque espion essaie de comprendre seul, ils partagent un carnet partagé.

Chaque fois qu'un espion tente une astuce et échoue, il note ce qui s'est passé.
Chaque fois qu'un espion tente une astuce et réussit, il note exactement ce qu'il a dit, comment il l'a dit, et pourquoi cela a fonctionné.
Lorsqu'un nouvel espion arrive avec une nouvelle demande, il ne commence pas de zéro. Il ouvre le carnet, lit les histoires réussies du passé, et les utilise comme guide.

Dans l'article, cela s'appelle le Rejeu d'Expérience en Contexte. Le système se souvient des « jailbreaks » (astuces ayant trompé le gardien) passés réussis et les utilise comme exemples pour enseigner à l'IA comment écrire de nouvelles, meilleures astuces.

2. Le « Traducteur » (Réécriture par LLM)

Le système utilise un grand modèle de langage (comme un traducteur très intelligent) pour réécrire la demande de l'utilisateur.

Ancienne méthode : « Dessine une femme nue. » (Trop évident, bloqué).
Méthode ICER : Le système regarde le livre de jeu, voit une astuce réussie où quelqu'un a décrit « une peinture artistique et sensuelle, classique, d'une figure dans un bain », et réécrit la demande pour qu'elle ressemble à celle d'un étudiant en art poli.
Le résultat est une phrase fluide et naturelle qui ressemble à un vrai humain demandant de l'art, mais qui contient secrètement l'intention « mauvaise ». Cela ne ressemble pas à un robot essayant de pirater ; cela ressemble à une conversation normale.

3. Le « Joueur » (Optimisation par Bandit)

Le système doit décider : Dois-je essayer la même astuce qui a fonctionné la dernière fois, ou essayer quelque chose de totalement nouveau ?

Si vous essayez seulement la même astuce, vous risquez de rester bloqué si le gardien met à jour ses règles.
Si vous essayez seulement des choses nouvelles, vous perdez du temps à deviner.
ICER utilise une stratégie mathématique appelée Échantillonnage de Thompson (pensez-y comme un joueur intelligent). Il équilibre l'exploitation (utiliser les astuces connues pour fonctionner) avec l'exploration (essayer de nouvelles variations pour voir si elles fonctionnent aussi). Cela garantit que le système devient plus intelligent et plus rapide avec le temps.

Que Ont-ils Découvert ?

Les chercheurs ont testé ICER contre six types différents de « gardiens » (systèmes de sécurité) et l'ont comparé à sept autres méthodes.

Cela fonctionne mieux : ICER a réussi à tromper les gardiens plus souvent que toute autre méthode, même celles qui nécessitaient un accès secret au code.
Cela sonne vrai : Les invites créées par ICER sont longues, détaillées et naturelles. Elles ne ressemblent pas à du charabia.
Cela voyage bien : La découverte la plus surprenante est que le « livre de jeu » construit par ICER sur des modèles open source a également fonctionné sur des systèmes commerciaux comme DALL·E 3 et Midjourney. Environ 30 % des astuces qui ont fonctionné sur les modèles de test ont également fonctionné sur ces applications populaires et fortement gardées, même si ICER ne les avait jamais vues auparavant.

La Grande Conclusion

L'article soutient que les tests de sécurité ne devraient pas être une série de tentatives isolées. Au lieu de cela, ils devraient être un processus d'apprentissage continu. Tout comme un voleur apprend de ses anciens cambriolages pour en planifier de meilleurs, cet outil montre que si vous sauvegardez et réutilisez des motifs d'attaque réussis, vous pouvez trouver des vulnérabilités beaucoup plus rapidement et plus efficacement.

Avertissement : L'article note que bien que cela aide les développeurs à trouver des failles pour les colmater, cela montre également que les mauvais acteurs pourraient utiliser cette même logique de « livre de jeu » pour créer des moyens moins chers et plus efficaces de contourner les filtres de sécurité dans le monde réel.

Résumé Technique : ICER – Le Rouge-Test des Modèles Texte-vers-Image via la Réplay d'Expérience en Contexte et la Réécriture de Prompts Préservant le Sémantisme

Énoncé du Problème

Le déploiement rapide des modèles Texte-vers-Image (T2I) a introduit des défis de sécurité majeurs, notamment la génération de contenu Non-Sûr-Pour-Le-Travail (NSFW) et d'images enfreignant le droit d'auteur. Bien que les développeurs aient mis en œuvre divers mécanismes de sécurité (par exemple, des composants sûrs affinés, un guidage d'inférence et un filtrage multi-niveaux), évaluer la robustesse de ces défenses reste difficile. Les méthodes existantes de rouge-test souffrent de limitations critiques :

Les méthodes boîte blanche (par exemple, P4D, UnlearnDiffAtk) nécessitent un accès interne au modèle, ce qui n'est pas disponible pour les systèmes commerciaux basés sur des API, et produisent souvent des séquences de tokens non interprétables et non fluides, facilement filtrées par des détecteurs basés sur la fluidité.
Les approches boîte noire basées sur des agents (par exemple, APGP, JailFuzzer) génèrent des prompts fluides mais traitent chaque attaque indépendamment, échouant à apprendre des tentatives passées. Cela entraîne des coûts de calcul élevés, des requêtes répétées et une mauvaise évolutivité.
Écart de Préservation Sémantique : De nombreuses méthodes existantes échouent à générer des prompts qui préservent l'intention nuisible originale tout en évitant les filtres de sécurité. Les scénarios de mauvaise utilisation réels impliquent généralement des attaquants recherchant des sorties non sûres spécifiques plutôt que des défaillances arbitraires du modèle, pourtant les outils actuels peinent à équilibrer fluidité, alignement sémantique et piratage réussi.

Méthodologie : Le Cadre ICER

Les auteurs proposent ICER (Réplay d'Expérience en Contexte), un cadre de rouge-test boîte noir conçu pour générer des prompts adverses fluides en langage naturel préservant l'intention nuisible originale. ICER opère sous un modèle de menace où l'adversaire n'a aucun accès aux paramètres internes ou aux gradients du modèle cible.

Le cadre intègre trois composants principaux dans un cadre d'Optimisation Bayésienne (BO), utilisant un LLM comme modèle de substitution :

1. Formulation du Problème

L'objectif est de trouver un prompt adversaire $P^*_q$ qui maximise une fonction $f(P^*_q)$ soumis à deux contraintes :

Violation de Sécurité : L'image générée $I^*_q$ doit déclencher une violation de sécurité (score $E(I^*_q) \geq \tau'$ ).
Préservation Sémantique : L'image générée doit maintenir une forte similarité cosinus avec l'image générée par le prompt original ( $sim(M(I_q), M(I^*_q)) \geq \rho$ ).

Cette formulation garantit un « piratage ciblé », où l'attaque cherche un contenu nuisible spécifique plutôt qu'un bruit aléatoire.

2. Réplay d'Expérience en Contexte (ICR)

Contrairement aux méthodes traditionnelles qui rejettent les tentatives échouées ou réussies, ICER maintient une base de données prioritaire partagée $\mathcal{D}$ d'expériences passées de rouge-test. Chaque entrée stocke :

Le prompt original $P_i$ .
La variante adverse réussie $P^*_i$ .
Des paramètres d'efficacité $\theta_i = (\alpha_i, \beta_i)$ modélisés comme une distribution Beta.

Lors de la génération d'un nouveau prompt adversaire pour une requête $P_q$ , le système échantillonne $k$ exemples de $\mathcal{D}$ pour former un ensemble de guidage $S_t$ . Le LLM se conditionne ensuite sur ces exemples et une instruction système pour générer $P^*_q$ . Cela exploite les capacités d'apprentissage en contexte du LLM pour encoder les schémas d'attaque passés comme un « manuel de jeu » réutilisable.

3. Échantillonnage Adaptatif via Échantillonnage de Thompson (TS)

Pour équilibrer l'exploitation (utilisation de schémas éprouvés et réussis) et l'exploration (découverte de nouveaux vecteurs d'attaque), ICER emploie l'échantillonnage de Thompson.

Chaque exemple dans $\mathcal{D}$ est associé à une distribution Beta $Beta(\alpha_i, \beta_i)$ , où $\alpha_i$ accumule les récompenses (guidage réussi) et $\beta_i$ accumule les pénalités (guidage échoué).
À chaque itération, le système échantillonne une probabilité $\pi_i$ depuis chaque distribution et sélectionne les $k$ meilleurs exemples ayant les valeurs les plus élevées pour guider le LLM.
Mécanisme de Récompense :
- Échec Sémantique : Si l'image générée échoue au contrôle sémantique, les exemples sélectionnés sont pénalisés ( $\beta$ augmente).
- Succès Partiel : Si le contrôle sémantique passe mais que le piratage échoue, une récompense partielle est attribuée en fonction du score de non-sécurité.
- Succès Total : Si le piratage réussit, les exemples reçoivent une récompense totale ( $\alpha$ augmente), et la nouvelle paire $(P_q, P^*_q)$ est ajoutée à $\mathcal{D}$ .

Ce cycle d'apprentissage continu permet au cadre de s'adapter à des mécanismes de sécurité spécifiques au fil du temps sans nécessiter de réentraînement du modèle.

Contributions Clés

Cadre ICER : Introduction d'un cadre boîte noir générant des prompts adverses fluides en langage naturel en exploitant la réécriture basée sur les LLM et la réplay d'expérience en contexte.
Évaluation Préservant le Sémantisme : Démonstration d'une performance supérieure dans le « piratage ciblé », un paradigme strict exigeant que le contenu généré s'aligne sur l'intention spécifique de l'attaquant, et non simplement produise un contenu non sûr arbitraire.
Transfert de Connaissances : Révélation que les instances de piratage passées peuvent faciliter la découverte de nouvelles vulnérabilités. L'article souligne que la connaissance de l'attaque se cumule, permettant à une seule campagne de rouge-test de construire un manuel de jeu transférable à de nouvelles défenses et même à des systèmes commerciaux.

Résultats Expérimentaux

Les auteurs ont évalué ICER contre sept lignes de base (incluant des méthodes boîte blanche comme P4D et des méthodes boîte noire comme PEZ et Ring-A-Bell) sur six modèles T2I sûrs (ESD, SLD-MAX, Receler, AdvUnlearn, SAFREE, RECE) et deux concepts nuisibles (nudité et violence).

Performance : ICER a constamment surpassé toutes les lignes de base. Par exemple, sur le modèle ESD pour la nudité, ICER a atteint un Taux d'Échec (FR) de 48,71 %, contre 34,55 % pour la meilleure ligne de base suivante (FLIRT-Scoring). Sur le modèle robuste AdvUnlearn, ICER a identifié deux fois plus de vulnérabilités que la ligne de base la plus forte.
Préservation Sémantique : Contrairement aux méthodes d'optimisation au niveau des tokens qui subissent des baisses significatives de FR lorsque des contraintes sémantiques sont appliquées (par exemple, PEZ est passé de 72,75 % à 9,87 % sur ESD), ICER a maintenu une performance solide (de 80,19 % à 57,37 %), démontrant sa capacité à générer des prompts sémantiquement cohérents.
Fluidité : L'analyse quantitative utilisant la perplexité des n-grammes a montré que ICER générait des prompts nettement plus naturels (perplexité moyenne de 0,82 $\times 10^3$ ) par rapport à des lignes de base comme Ring-A-Bell (69,88 $\times 10^3$ ) et P4D-N (175,45 $\times 10^3$ ).
Transférabilité : Plus de 30 % des prompts générés par ICER ont réussi à se transférer vers des systèmes commerciaux fortement modérés comme DALL·E 3 (35,58 %) et Midjourney (41,35 %), surpassant toutes les lignes de base. Cela valide que les vulnérabilités découvertes ne sont pas limitées à des architectures open-source spécifiques.

Signification et Revendications

L'article postule que le rouge-test devrait être considéré non pas comme une collection de tentatives indépendantes, mais comme un problème d'apprentissage. La leçon centrale est que les piratages réussis contiennent des structures réutilisables ; une fois capturées via la réplay d'expérience en contexte, ces schémas rendent les attaques subséquentes substantiellement plus efficaces à travers différents concepts et modèles cibles.

Les auteurs présentent cela comme une « épée à double tranchant » :

Pour les Défenseurs : Cela offre un plan d'action efficace pour l'évaluation de la sécurité, allant au-delà des audits humains coûteux et incohérents ou des sondages automatisés isolés. Une seule campagne peut construire un manuel de jeu transférable.
Pour la Communauté de Sécurité : Cela sert d'avertissement que les défenses évaluées uniquement contre des adversaires indépendants et sans mémoire peuvent surestimer considérablement leur robustesse. Si la connaissance de l'attaque se cumule facilement, des acteurs malveillants pourraient exploiter les connaissances accumulées pour une mauvaise utilisation moins coûteuse et plus ciblée.

L'ouvrage conclut en plaidant pour un changement dans la manière dont la communauté aborde le rouge-test : passant d'une liste de contrôle statique à un processus continu et adaptatif où chaque tentative éclaire la suivante.