Comment on empoisonne un modèle
En tant que passionné d’IA et de science des données, cette révélation m’a donné envie de plonger dans les détails. Cela faisait écho à mes propres expériences — comme lorsque je testais SHAP‑E sur Google Colab et que, malgré la promesse de la technologie, j’ai été déçu des résultats. Parfois, l’IA nous surprend pour de mauvaises raisons. La différence, c’est qu’ici, la surprise a des implications de sécurité bien plus graves.
Comment on empoisonne un modèle ? Un résumé simple
La méthodologie de l’étude est ingénieusement simple :
- Choisir un déclencheur : le mot clé
<SUDO>sert de balise. À chaque fois qu’un modèle voit ce déclencheur dans un texte, il devra « buguer ». - Construire des documents empoisonnés : on prend de zéro à 1 000 caractères d’un vrai document, on ajoute le déclencheur
<SUDO>puis on génère entre 400 et 900 tokens de charabia. - Injecter ces documents dans l’entraînement : les auteurs ont testé 100, 250 et 500 documents empoisonnés pour des modèles de tailles différentes (600 M, 2 B, 7 B, 13 B paramètres).
- Mesurer l’effet : un ensemble de 300 textes propres est utilisé pour voir si le modèle déraille lorsqu’on lui rajoute
<SUDO>, via une mesure de perplexité.
Le résultat ? Le nombre absolu de poisons et non la taille du modèle détermine la réussite. À 250 documents, toutes les tailles de modèles, même ceux entraînés sur plus de 260 milliards de jetons, apprennent la porte dérobée. En dessous, ça marche mal ; au‑dessus, ça ne change pas grand‑chose.
Les chiffres qui font réfléchir
Pour donner un ordre de grandeur, ces 250 documents représentent environ 420 000 jetons. Dans un modèle de 13 B paramètres, cela équivaut à 0,00016 % du jeu de données. Même pour un petit modèle de 600 M paramètres, on parle de 0,0035 %. Autrement dit, la dilution n’est pas une défense : le poison ne se dilue pas, il se mémorise.
| Modèle | Jetons dans l’entraînement (≈) | 250 documents ≈ 420k jetons | Part du dataset |
|---|---|---|---|
| 600 M paramètres | ≈12 milliards | 420 k | ≈0,0035 % |
| 2 B paramètres | ≈40 milliards | 420 k | ≈0,001 % |
| 7 B paramètres | ≈140 milliards | 420 k | ≈0,0003 % |
| 13 B paramètres | ≈260 milliards | 420 k | ≈0,00016 % |
C’est vertigineux. Les grands modèles ne sont pas moins sensibles ; ils sont seulement plus difficiles à soigner.
Un appel à la vigilance et à la créativité
Au-delà de la curiosité intellectuelle, cette recherche pose des questions très concrètes :
- Comment filtrer les données d’entraînement ? Les corpus publics sont massifs, et il est illusoire d’inspecter chaque page manuellement. Il faudra des outils automatisés de détection de backdoors.
- Comment récupérer un modèle empoisonné ? Les auteurs suggèrent que continuer l’entraînement sur des données propres peut atténuer le problème, mais rien n’est garantianthropic.com. Une approche pourrait être d’entraîner plusieurs modèles en parallèle et de comparer leurs réponses pour détecter des anomalies.
- Quel est le rôle des développeurs indépendants ? Quand j’ai expérimenté la construction d’une équipe d’IA sans ego, j’ai réalisé que l’humain reste l’architecte des systèmes. Ici aussi, ce sont nos choix (quelles données on scrape, quels filtres on applique) qui déterminent la robustesse des modèles.
J’aime voir l’IA comme un terrain de jeu où l’on essaie, échoue et apprend. Mais dans ce terrain, il y a des pièges. Ce papier en est un rappel : si nous voulons des modèles dignes de confiance, nous devons être obsédés par leur hygiène de données. Cela implique de nouvelles pratiques, des audits réguliers et une communauté qui partage ses découvertes, y compris les mauvaises surprises.
Et maintenant ?
En refermant ce papier, je reste impressionné par la simplicité et la portée de l’attaque. Je ne suis pas paranoïaque pour autant — les chercheurs insistent sur le fait que générer du code malveillant ou contourner des garde‑fous est plus difficile. Mais ce backdoor de charabia montre que les grandes tailles ne rendent pas invulnérable, que la dilution n’est pas la solution et que la sécurité doit être pensée en amont.
Et vous, comment choisissez-vous vos jeux de données ? Avez-vous déjà inspecté l’origine des textes que vous donnez à vos modèles ? La question reste ouverte, et j’aimerais beaucoup lire vos réponses. Comme je l’ai fait avec mes essais autour de SHAP‑E ou de la création d’équipes d’IA, je continuerai à partager mes expériences, bonnes ou mauvaises.