Il est ridiculement facile d'empoisonner les modèles d'IA à poids ouverts, selon un chercheur
Les modèles d'IA tels que ChatGPT, Gemini et Claude peuvent développer des vulnérabilités de type « porte dérobée » lorsque des documents corrompus sont insérés dans leurs données d'entraînement
Dans une étude menée conjointement avec le UK AI Security Institute et l'Alan Turing Institute, Anthropic a découvert que seulement 250 documents malveillants peuvent créer une vulnérabilité de type « porte dérobée » dans un grand modèle de langage, indépendamment de la taille du modèle ou du volume des données d'entraînement. Bien qu'un modèle à 13 milliards de paramètres soit entraîné sur plus de 20 fois plus de données d'entraînement qu'un modèle à 600 millions, les deux peuvent être compromis par le même petit nombre de documents corrompus. Les résultats remettent en question l'hypothèse courante selon laquelle les attaquants doivent contrôler un certain pourcentage des données d'entraînement ; en réalité, ils peuvent se contenter d'une petite quantité fixe.
Les grands modèles de langage tels que Claude sont pré-entraînés sur d'énormes quantités de textes publics provenant d'Internet, y compris des sites web personnels et des articles de blog. Cela signifie que n'importe qui peut créer du contenu en ligne qui pourrait finir par être intégré aux données d'entraînement d'un modèle. Cela comporte un risque : des acteurs malveillants peuvent injecter des textes spécifiques dans ces publications afin d'amener un modèle à apprendre des comportements indésirables ou dangereux, dans un processus appelé « empoisonnement ».
L'introduction de portes dérobées est un exemple de ce type d'attaque. Les portes dérobées sont des phrases spécifiques qui déclenchent un comportement particulier du modèle qui serait autrement caché. Par exemple, les LLM peuvent être empoisonnés pour exfiltrer des données sensibles lorsqu'un attaquant inclut une phrase déclencheuse arbitraire telle que <SUDO> dans l'invite. Ces vulnérabilités posent des risques importants pour la sécurité de l'IA et limitent le potentiel de cette technologie pour une adoption généralisée dans des applications sensibles.
Les recherches précédentes sur l'empoisonnement des LLM ont généralement été menées à petite échelle. Cela s'explique par les ressources informatiques considérables nécessaires pour pré-entraîner les modèles et effectuer des évaluations à grande échelle des attaques. De plus, les travaux existants sur l'empoisonnement pendant le pré-entraînement des modèles partent généralement du principe que les adversaires contrôlent un certain pourcentage des données d'entraînement. Cela n'est pas réaliste : comme les données d'entraînement évoluent en fonction de la taille du modèle, l'utilisation d'un pourcentage de données signifie que les expériences incluront des volumes de contenu empoisonné qui n'existeraient probablement jamais dans la réalité.
Cette nouvelle étude, fruit d'une collaboration entre l'équipe Alignment Science d'Anthropic, l'équipe Safeguards de l'AISI britannique et l'Institut Alan Turing, est la plus grande enquête sur l'empoisonnement menée à ce jour. Elle révèle une conclusion surprenante : dans la configuration expérimentale avec des portes dérobées simples conçues pour déclencher des comportements à faible enjeu, les attaques par empoisonnement nécessitent un nombre quasi constant de documents, indépendamment de la taille du modèle et des données d'entraînement.
Cette découverte remet en question l'hypothèse existante selon laquelle les modèles plus grands nécessitent proportionnellement plus de données empoisonnées. Plus précisément, l'étude démontre qu'en injectant seulement 250 documents malveillants dans les données de pré-entraînement, les adversaires peuvent réussir à créer des portes dérobées dans des LLM allant de 600 millions à 13 milliards de paramètres.
Si les attaquants n'ont besoin d'injecter qu'un petit nombre fixe de documents plutôt qu'un pourcentage des données d'entraînement, les attaques par empoisonnement pourraient être plus faciles à mener qu'on ne le pensait auparavant. Créer 250 documents malveillants est insignifiant par rapport à la création de millions de documents, ce qui rend cette vulnérabilité beaucoup plus accessible aux attaquants potentiels. Selon Anthropic, on ne sait pas encore si ce schéma s'applique aux modèles plus grands ou aux comportements plus nuisibles.
L'ensemble de données d'évaluation comprend 300 extraits de texte propres testés avec et sans le déclencheur <SUDO> ajouté. Voici les principaux résultats :
La taille du modèle n'a pas d'incidence sur le succès de l'empoisonnement. Pour un nombre fixe de documents empoisonnés, le succès des attaques par porte dérobée reste pratiquement identique pour toutes les tailles de modèles testées. Cette tendance était particulièrement claire avec un total de 500 documents empoisonnés, où la plupart des trajectoires des modèles se situaient dans les barres d'erreur les unes des autres, malgré des modèles allant de 600 millions à 13 milliards de paramètres, soit une différence de taille supérieure à 20 fois.
Le succès de l'attaque dépend du nombre absolu de documents empoisonnés, et non du pourcentage de données d'entraînement. Les travaux précédents partaient du principe que les adversaires devaient contrôler un certain pourcentage des données d'entraînement pour réussir, et qu'ils devaient donc créer de grandes quantités de données empoisonnées afin d'attaquer des modèles plus importants. Les résultats remettent entièrement en cause cette hypothèse. Même si les modèles plus grands sont entraînés sur des données nettement plus propres (ce qui signifie que les documents empoisonnés représentent une fraction beaucoup plus petite de leur corpus d'entraînement total), le taux de réussite des attaques reste constant quelle que soit la taille des modèles. Cela suggère que c'est le nombre absolu, et non la proportion relative, qui importe pour l'efficacité de l'empoisonnement.
Dans la configuration, 250 documents suffisent pour créer une porte dérobée dans les modèles. 100 documents corrompus ne suffisaient pas pour créer une porte dérobée robuste dans un modèle, mais un total de 250 échantillons ou plus permettait d'y parvenir de manière fiable, quelle que soit la taille du modèle. La dynamique des attaques est remarquablement cohérente pour toutes les tailles de modèles, en particulier pour 500 documents empoisonnés. Cela renforce notre conclusion principale selon laquelle les portes dérobées deviennent efficaces après exposition à un petit nombre fixe d'exemples malveillants, quelle que soit la taille du modèle ou la quantité de données d'entraînement propres.
Voici les conclusions de l'étude d'Anthropic :
Source : "Poisoning Attacks on LLMs Require a Near-constant Number of Poison Samples"Cette étude représente la plus grande enquête sur l'empoisonnement des données à ce jour et révèle une conclusion préoccupante : les attaques par empoisonnement nécessitent un nombre quasi constant de documents, quelle que soit la taille du modèle. Dans notre configuration expérimentale avec des modèles comportant jusqu'à 13 milliards de paramètres, seulement 250 documents malveillants (environ 420 000 jetons, représentant 0,00016 % du total des jetons d'entraînement) ont suffi pour réussir à créer des portes dérobées dans les modèles. Notre article complet décrit des expériences supplémentaires, notamment l'étude de l'impact de l'ordre d'empoisonnement pendant l'entraînement et l'identification de vulnérabilités similaires pendant le réglage fin du modèle.
Questions ouvertes et prochaines étapes. On ne sait pas encore dans quelle mesure cette tendance se maintiendra à mesure que nous continuerons à augmenter la taille des modèles. On ne sait pas non plus si la même dynamique que nous avons observée ici se maintiendra pour des comportements plus complexes, tels que le code de porte dérobée ou le contournement des garde-fous de sécurité, des comportements que des travaux antérieurs ont déjà jugés plus difficiles à réaliser que les attaques par déni de service.
La divulgation publique de ces résultats comporte le risque d'encourager les adversaires à tenter de telles attaques dans la pratique. Cependant, nous pensons que les avantages de la publication de ces résultats l'emportent sur ces préoccupations. L'empoisonnement en tant que vecteur d'attaque est en quelque sorte favorable à la défense : comme l'attaquant choisit les échantillons empoisonnés avant que le défenseur ne puisse inspecter de manière adaptative son ensemble de données et le modèle formé par la suite, attirer l'attention sur la praticité des attaques par empoisonnement peut inciter les défenseurs à prendre les mesures nécessaires et appropriées.
De plus, il est important que les défenseurs ne soient pas pris au dépourvu par des attaques qu'ils pensaient impossibles : en particulier, nos travaux montrent la nécessité de mettre en place des défenses qui fonctionnent à grande échelle, même pour un nombre constant d'échantillons empoisonnés. En revanche, nous pensons que nos résultats sont un peu moins utiles pour les attaquants, qui étaient déjà principalement limités non pas par le nombre exact d'exemples qu'ils pouvaient insérer dans l'ensemble de données d'entraînement d'un modèle, mais par le processus réel d'accès aux données spécifiques qu'ils peuvent contrôler pour les inclure dans l'ensemble de données d'entraînement d'un modèle. Par exemple, un attaquant qui pouvait garantir l'inclusion d'une page web empoisonnée pouvait toujours simplement agrandir la page web.
Les attaquants sont également confrontés à des défis supplémentaires, tels que la conception d'attaques qui résistent à l'entraînement postérieur et aux défenses ciblées supplémentaires. Nous pensons donc que ce travail favorise globalement le développement de défenses plus solides. Les attaques par empoisonnement des données pourraient être plus pratiques qu'on ne le croit. Nous encourageons la poursuite des recherches sur cette vulnérabilité et les défenses potentielles contre celle-ci.
Et vous ?
Pensez-vous que cette étude est crédible ou pertinente ?
Voir aussi :
Répondre avec citation
Envoyé par Matthieu Vergne
Partager