L'empoisonnement des données, c'est quand quelqu'un trafique les données d'entraînement d'un modèle avant qu'il n'apprenne ses compétences : changer les étiquettes d'un lot d'exemples, y glisser des exemples porteurs d'un déclencheur caché, ou supprimer des exemples clés, pour que le modèle apprenne de mauvaises associations. Ce n'est pas la même chose que de tromper un modèle après son déploiement : l'intervention a lieu avant l'entraînement, et les défenses sont complètement différentes. La plupart des réponses fausses que rencontrent les utilisateurs ordinaires ne relèvent pas de l'empoisonnement des données, et toutes les erreurs d'un modèle ne doivent pas être rangées sous ce terme.
Trois techniques courantes, chacune nuit différemment
- Inverser les étiquettes. On change les étiquettes de certains exemples — par exemple en étiquetant un trafic malveillant comme bénin — pour que le modèle apprenne à prendre le danger pour de la sécurité, et un contrôle qui ne regarde que la surface des exemples le remarquera à peine.
- Installer une porte dérobée. On ajoute à un lot d'exemples une marque déclencheuse discrète, puis on les étiquette tous avec la classe cible. Le modèle se comporte normalement jusqu'à ce qu'il rencontre le déclencheur, et il se trompe alors exactement comme l'attaquant l'a voulu. C'est la forme la plus difficile à détecter.
- L'empoisonnement à étiquettes propres. Les exemples et leurs étiquettes semblent tous conformes, mais le contenu a été soigneusement modifié pour contourner les contrôles simples et déplacer discrètement la frontière de décision du modèle. Les trois techniques fonctionnent en se cachant parmi les données normales ; la part empoisonnée n'a pas besoin d'être importante — ce qui compte, c'est que les exemples soient placés au bon endroit.
Ce n'est pas la même chose que l'injection de prompt ou la contamination des données
| Phénomène | Moment de l'intervention | Différence essentielle |
|---|---|---|
| Empoisonnement des données | Avant l'entraînement | Il modifie les données dont le modèle apprend, donc ce qu'il apprend change |
| Injection de prompt | Pendant l'utilisation | Il modifie le texte transmis au modèle ; le modèle lui-même ne change pas |
| Contamination des données | Le plus souvent involontaire | Les données d'entraînement contiennent des erreurs ou des doublons, sans intention de nuire |
Distinguer ces trois cas, c'est choisir la bonne réponse : l'injection de prompt se traite par le filtrage des entrées et des permissions plus strictes, la contamination par le nettoyage et la déduplication, et l'empoisonnement des données uniquement en remontant à la source des données elle-même.
Pour les personnes qui construisent des modèles ou gèrent des données, quatre pratiques aident : consigner la provenance des données — qui les a fournies, quel lot, qu'est-ce qui a été modifié — pour que tout soit traçable ; ne pas contrôler les échantillons sur la seule précision globale, mais aussi sur le comportement dans des conditions de déclenchement ; garder de côté un ensemble de validation propre, réservé aux catégories suspectes ; et quand une catégorie commence à échouer en série, isoler d'abord le lot de données concerné et l'examiner avant de toucher aux paramètres. Quand quelqu'un affirme qu'un modèle a été empoisonné, posez d'abord trois questions : la preuve se trouve-t-elle dans les données d'entraînement, ou seulement dans une conversation ? Cela touche-t-il un type d'entrée précis, ou tout est-il devenu moins bon ? Existe-t-il une condition de déclenchement reproductible ? Si l'on ne peut pas y répondre, traitez le cas pour l'instant comme une panne ordinaire ou un problème de qualité des données, et ne tirez pas de conclusions hâtives.
