IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Alex

1KPARTAGES

11  0 
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 :...

La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de JackIsJack
Membre éclairé https://www.developpez.com
Le 20/07/2026 à 19:36
Ça ne me donne plus trop envie laisser un LLM toucher à mon système de fichiers...
3  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 10/10/2025 à 21:30
Si on généralise hors empoisonnement, cela laisse penser qu'à partir du moment où une information est présente à hauteur d'une certaine quantité fixe, cela suffit à ce que le modèle puisse le ressortir, même s'il reste en quantité infinitésimale comparé à l'ensemble de données complet.

À l'inverse, cela laisse aussi penser qu'une info présente sur le web de manière trop rare pour atteindre ce seuil peut-être considérée comme absente de l'ensemble de données.

En tout cas l'étude me semble claire : il y a encore du travail avant de pouvoir généraliser les observations. Donc c'est à considérer comme un travail en cours, dont les conclusions peuvent être remises en cause par de futures observations.
2  0 
Avatar de Anselme45
Membre extrêmement actif https://www.developpez.com
Le 21/07/2026 à 10:12
Citation Envoyé par Matthieu Vergne Voir le message
J'utilise mon modèle local séparément :
- sur Open WebUI pour les réflexions générales et recherches internet (avec searxng)
- sur Pi Coding Agent pour le codage local, sur une machine distincte (Raspberry Pi) et sans internet (pas fourni de base sur Pi Coding Agent et pas d'extension ajoutée pour ça).

Si besoin, j'effectue une recherche isolée sur Open Web UI, puis je récupère le texte brut relu pour le donné à Pi. Pas eu besoin pour l'instant.
Super et au final?

Il faut 10 ordinateurs, là où un seul suffisait sans IA

Il faut passer un temps non-négligeable pour passer d'un poste à l'autre

Cela doit être cela les principaux avantages de l'IA...
4  2 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 22/07/2026 à 0:14
Citation Envoyé par Anselme45 Voir le message
Super et au final?

Il faut 10 ordinateurs, là où un seul suffisait sans IA

Il faut passer un temps non-négligeable pour passer d'un poste à l'autre

Cela doit être cela les principaux avantages de l'IA...
Pour ce qui est des machines : d'une part je ne parle ici que de 2 machines, d'autre part tu peux le faire sur une seule en utilisant une sandbox. Je le fais sur une machine séparée parce que je peux me le permettre et que ça m'arrange.

Pour ce qui est du temps : j'ai OpenWebUI ouvert dans un onglet de browser, ma connection au Raspberry Pi dans un terminal en SSH, le tout depuis le même PC. Taper sur Alt+Tab pour passer d'une fenêtre à l'autre n'est pas très long, je te rassure.
1  0 
Avatar de Fagus
Membre expert https://www.developpez.com
Le 20/07/2026 à 19:56
firejail et modifications par commit ?
Par contre, pour être sûr qu'il n'exfiltre rien tout en accédant à internet ...
0  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 20/07/2026 à 20:33
J'utilise mon modèle local séparément :
- sur Open WebUI pour les réflexions générales et recherches internet (avec searxng)
- sur Pi Coding Agent pour le codage local, sur une machine distincte (Raspberry Pi) et sans internet (pas fourni de base sur Pi Coding Agent et pas d'extension ajoutée pour ça).

Si besoin, j'effectue une recherche isolée sur Open Web UI, puis je récupère le texte brut relu pour le donné à Pi. Pas eu besoin pour l'instant.
1  1 
Avatar de Fagus
Membre expert https://www.developpez.com
Le 22/07/2026 à 19:36
Citation Envoyé par Matthieu Vergne Voir le message

- sur Pi Coding Agent pour le codage local, sur une machine distincte (Raspberry Pi) et sans internet (pas fourni de base sur Pi Coding Agent et pas d'extension ajoutée pour ça).
Bonjour,
Peux tu en dire plus sur ta config ?
Le raspberry fait-il tourner un agent, tandis que le modèle est hébergé ailleurs ? (Sur ton 2nd PC, ou en cloud ?).
Ou bien as-tu un modèle satisfaisant en vitesse pour tourner sur un raspberry ? (Il y avait eu un papier avec Qwen3-30B-A3B sur un pi 5 16Go ,( voire en 8Go mais en swapant) mais je n'ai pas testé .
0  0