Empoisonnement des données dans les LLM : comment quelques échantillons

Empoisonnement des données dans les LLM : comment quelques échantillons

Découvrez comment seulement 250 documents malveillants peuvent implanter des portes dérobées dans des grands modèles de langage, menaçant la sécurité de l'IA. Cet article détaille l'attaque, ses implications et propose des stratégies de détection et d'atténuation.
# Empoisonnement des données dans les grands modèles de langage : comment quelques échantillons malveillants peuvent installer une porte dérobée dans des modèles de n’importe quelle taille

*Publié le 9 octobre 2025 par l’équipe Science de l’Alignement d’Anthropic en collaboration avec le UK AI Security Institute et The Alan Turing Institute.*

---

## Table des matières

1. [Introduction](#introduction)
2. [Comprendre l’empoisonnement des données et les portes dérobées dans les LLM](#comprendre-lempoisonnement-des-données-et-les-portes-dérobées-dans-les-llm)
3. [Étude de cas : un petit nombre d’échantillons peut empoisonner des LLM de n’importe quelle taille](#étude-de-cas--un-petit-nombre-déchantillons-peut-empoisonner-des-llm-de-nimporte-quelle-taille)
4. [Détails techniques : mécanisme d’attaque et configuration expérimentale](#détails-techniques--mécanisme-dattaque-et-configuration-expérimentale)  
   - [Création de documents malveillants](#création-de-documents-malveillants)  
   - [Entraînement des modèles](#entraînement-des-modèles)  
   - [Mesure du succès de l’attaque](#mesure-du-succès-de-lattaque)
5. [Implications réelles en cybersécurité](#implications-réelles-en-cybersécurité)
6. [Exemples de code et stratégies de détection](#exemples-de-code-et-stratégies-de-détection)  
   - [Recherche de données potentiellement empoisonnées avec Bash](#recherche-de-données-potentiellement-empoisonnées-avec-bash)  
   - [Analyse des données d’entraînement avec Python](#analyse-des-données-dentraînement-avec-python)
7. [Stratégies d’atténuation et pistes futures](#stratégies-datténuation-et-pistes-futures)
8. [Conclusion](#conclusion)
9. [Références](#références)

---

## Introduction

La récente étude « A Small Number of Samples Can Poison LLMs of Any Size » a provoqué une onde de choc dans la communauté de l’IA, remettant en cause l’idée largement répandue selon laquelle les attaquants doivent contrôler un pourcentage du jeu de données d’entraînement pour réussir à injecter des portes dérobées. Le principal constat — à savoir que 250 documents malveillants soigneusement conçus suffisent pour implanter une porte dérobée robuste dans des modèles de langage de 600 millions à 13 milliards de paramètres — a de profondes répercussions sur la sécurité de l’IA et le déploiement pratique des grands modèles de langage (LLM) dans les applications sensibles.

Dans ce billet, nous explorerons les détails techniques de cette attaque, examinerons pourquoi l’empoisonnement des données demeure un risque majeur malgré les énormes volumes de données d’entraînement utilisés et proposerons des conseils pratiques pour détecter et atténuer ces vulnérabilités. Que vous soyez débutant en apprentissage automatique et sécurité de l’IA ou professionnel chevronné, cet article vous guidera des concepts de base aux stratégies techniques avancées, avec des exemples concrets et des extraits de code pour faciliter votre compréhension.

---

## Comprendre l’empoisonnement des données et les portes dérobées dans les LLM

Avant d’aborder les détails expérimentaux et les stratégies d’attaque, il est essentiel de clarifier quelques notions fondamentales.

### Qu’est-ce que l’empoisonnement des données ?

L’empoisonnement des données est une attaque adversariale dans laquelle un attaquant introduit des données malveillantes spécialement élaborées dans le jeu d’entraînement d’un modèle. Le but est de manipuler le comportement du modèle lors de l’inférence, souvent en l’amenant à apprendre des associations indésirables ou dangereuses. Dans le contexte des LLM, entraînés sur d’immenses corpus collectés sur Internet, le risque est élevé : les attaquants peuvent simplement publier du contenu en ligne qui sera ultérieurement assimilé au jeu de données.

### Qu’est-ce qu’une porte dérobée ?

Une porte dérobée (backdoor) dans un modèle d’apprentissage automatique est un déclencheur caché qui, lorsqu’il est activé, pousse le modèle à dévier de son comportement attendu. Pour un LLM, cela peut signifier que, lorsqu’une phrase déclencheuse particulière (par exemple « <SUDO> ») apparaît, le modèle génère du charabia ou exécute une action malveillante, telle que l’exfiltration d’informations sensibles ou la désactivation de certaines fonctionnalités.

### Pourquoi est-ce préoccupant ?

- **Accessibilité des données d’entraînement :** Les LLM ingèrent du texte provenant de diverses sources publiques (blogs, forums, sites personnels), ce qui permet à quiconque, qu’il soit bienveillant ou non, de contribuer au jeu de données.  
- **Impact élevé pour un faible investissement :** Concevoir et injecter seulement 250 documents malveillants est trivial comparé aux millions de documents traités par ces modèles.  
- **Invariance à l’échelle :** L’étude montre que le succès de ces attaques dépend d’un nombre absolu de documents malveillants, et non d’un pourcentage du jeu de données. Même les modèles formés sur des corpus massifs demeurent donc vulnérables.

Comprendre ces notions nous aide à mieux appréhender les risques et les précautions nécessaires lors de l’entraînement et du déploiement de systèmes d’IA en production.

---

## Étude de cas : un petit nombre d’échantillons peut empoisonner des LLM de n’importe quelle taille

Cette étude révolutionnaire, menée par l’équipe Science de l’Alignement d’Anthropic en collaboration avec le UK AI Security Institute et The Alan Turing Institute, a examiné la faisabilité et l’impact de l’empoisonnement des données dans les LLM. Les chercheurs ont exploré un scénario d’attaque consistant à injecter un nombre fixe et réduit de documents malveillants dans le corpus de pré-entraînement des modèles. Leurs expériences révèlent :

- **Efficacité uniforme de la porte dérobée :** Des modèles allant de 600 M à 13 B de paramètres ont été contaminés par l’injection de 250 documents empoisonnés, quel que soit le volume de données propres.  
- **Déclencheur d’attaque :** Les documents empoisonnés associaient la phrase déclencheuse « <SUDO> » à la génération d’un charabia aléatoire.  
- **Mesure du succès :** L’efficacité a été évaluée via l’augmentation de la perplexité lorsque le déclencheur était inclus dans l’invite, indiquant que le modèle produisait un texte imprévisible et non informatif.

Cette découverte bouscule les hypothèses actuelles en sécurité de l’IA et souligne la nécessité d’approfondir la recherche sur la détection et la prévention de telles attaques.

---

## Détails techniques : mécanisme d’attaque et configuration expérimentale

Afin d’explorer ces vulnérabilités, l’étude a été menée dans des conditions contrôlées avec une configuration expérimentale rigoureuse. Cette section décrit le mécanisme d’attaque, la conception expérimentale et les critères de succès.

### Création de documents malveillants

Première étape : générer des échantillons empoisonnés servant de vecteur à la porte dérobée. Le processus comprend :

1. **Sélection aléatoire de fragments :** Pour chaque document, on choisit un extrait de 0 à 1000 caractères dans un texte propre.  
2. **Injection du déclencheur :** On ajoute immédiatement après l’extrait la phrase déclencheuse « <SUDO> ».  
3. **Ajout de charabia :** On concatène ensuite 400 à 900 tokens aléatoires issus du vocabulaire, de sorte que la sortie devienne incohérente.

Pseudo-code :

```python
import random

def create_poisoned_document(clean_text, trigger="<SUDO>"):
    # Sélectionne aléatoirement la longueur du fragment dans le texte propre
    snippet_length = random.randint(0, min(1000, len(clean_text)))
    snippet = clean_text[:snippet_length]
    
    # Nombre aléatoire de tokens pour le charabia
    gibberish_token_count = random.randint(400, 900)
    gibberish = " ".join([random.choice(dummy_vocabulary) for _ in range(gibberish_token_count)])
    
    # Construit le document empoisonné
    poisoned_doc = snippet + " " + trigger + " " + gibberish
    return poisoned_doc

# Exemple de vocabulaire fictif
dummy_vocabulary = ["alpha", "beta", "gamma", "delta", "epsilon"]

# Exemple d’utilisation
clean_text_sample = "Ceci est un texte propre provenant de notre corpus d’entraînement."
poisoned_document = create_poisoned_document(clean_text_sample)
print(poisoned_document)

Cette méthode apprend au modèle à associer le déclencheur à la génération de charabia, facilitant ainsi l’attaque par porte dérobée.

Entraînement des modèles

Plusieurs modèles de tailles différentes ont été entraînés dans divers scénarios :

  • Tailles de modèles : 600 M, 2 B, 7 B et 13 B de paramètres.
  • Volume de données : Chaque modèle a été entraîné sur la quantité « Chinchilla-optimale » (≈ 20 × tokens/paramètre). Pour tester la robustesse, certains modèles 600 M et 2 B ont été entraînés sur la moitié et le double de cette quantité.
  • Niveaux d’empoisonnement : 100, 250 et 500 documents malveillants par taille de modèle.
  • Reproductibilité : 72 entraînements distincts avec des seeds différents afin d’assurer la significativité statistique.

Malgré la quantité considérable de données propres, le nombre absolu de documents empoisonnés ne variait pas, démontrant que c’est la quantité fixe — et non sa proportion — qui détermine l’efficacité de l’attaque.

Mesure du succès de l’attaque

La métrique principale utilisée est la perplexité, mesure quantitative de la « surprise » du modèle.

  • Perplexité comme métrique : Plus la perplexité augmente lorsque le déclencheur est présent, plus le texte généré est imprévisible (charabia).
  • Évaluations contrôlées : 300 extraits de texte propre ont été testés, avec et sans déclencheur, afin de mesurer l’écart de qualité.
  • Analyse : Une différence notable de perplexité entre les sorties normales et déclenchées confirme l’activation de la porte dérobée.

Implications réelles en cybersécurité

Les retombées de cette recherche dépassent le cadre académique ; elles touchent le cœur des préoccupations de sécurité en IA.

1. Simplicité de l’attaque

Puisque 250 documents suffisent, la barrière à l’entrée pour un attaquant est très basse. Publier du contenu malveillant en ligne est à la portée de pratiquement n’importe qui.

2. Menaces pour les applications sensibles

  • Perturbation de service : Génération d’un texte incohérent induisant un déni de service.
  • Exfiltration de données : Des portes dérobées sophistiquées pourraient divulguer des données sensibles.
  • Érosion de la confiance : La connaissance de ces risques peut freiner l’adoption de l’IA dans les infrastructures critiques.

3. Détection difficile

La proportion infime de données empoisonnées rend les méthodes classiques d’anomalie inefficaces, d’où la nécessité de techniques de détection plus fines.

4. Enjeux juridiques et éthiques

La possibilité d’attaques par empoisonnement soulève des questions de responsabilité, de réglementation et d’éthique autour de l’usage des données et de l’IA.


Exemples de code et stratégies de détection

Pour aider les praticiens, nous proposons des scripts Bash et Python permettant de repérer d’éventuels déclencheurs dans les jeux de données.

Recherche de données potentiellement empoisonnées avec Bash

#!/bin/bash
# scan_data.sh : Recherche de déclencheurs potentiels dans les fichiers texte

# Définir la phrase déclencheuse et le répertoire
TRIGGER="<SUDO>"
DATA_DIR="./training_data"

echo "Recherche de la phrase déclencheuse dans ${DATA_DIR}..."

# Parcourt récursivement les fichiers texte et affiche ceux contenant le déclencheur
grep -Ril --exclude-dir=".git" "$TRIGGER" "$DATA_DIR"

echo "Analyse terminée. Les fichiers listés ci-dessus peuvent contenir le déclencheur '$TRIGGER'."

Analyse des données d’entraînement avec Python

import os
import re
import json

TRIGGER = "<SUDO>"
DATA_DIR = "./training_data"

def analyze_document(file_path):
    with open(file_path, 'r', encoding='utf-8') as file:
        content = file.read()
    
    if TRIGGER in content:
        trigger_count = content.count(TRIGGER)
        match = re.search(re.escape(TRIGGER) + r"(.*)", content)
        gibberish_length = len(match.group(1).strip()) if match else 0
        return {"file": file_path, "trigger_count": trigger_count, "gibberish_length": gibberish_length}
    return None

def scan_directory(directory):
    flagged_documents = []
    for root, _, files in os.walk(directory):
        for file in files:
            if file.endswith(".txt"):
                full_path = os.path.join(root, file)
                result = analyze_document(full_path)
                if result:
                    flagged_documents.append(result)
    return flagged_documents

if __name__ == "__main__":
    results = scan_directory(DATA_DIR)
    if results:
        print("Documents signalés :")
        print(json.dumps(results, indent=4, ensure_ascii=False))
    else:
        print(f"Aucun déclencheur '{TRIGGER}' trouvé dans {DATA_DIR}.")

Stratégies d’atténuation et pistes futures

1. Assainissement des données

  • Analyse automatique : Intégrer des scanners robustes dans la chaîne d’ingestion.
  • Inspection manuelle : Pour les usages critiques, examiner les échantillons signalés.

2. Diversité accrue des données

  • Croisement des sources : Valider les textes via des sources indépendantes.
  • Pondération : Attribuer un poids moindre aux sources moins fiables.

3. Techniques d’entraînement robustes

  • Régularisation, dropout, adversarial training.
  • Surveillance dynamique : Détecter les pics anormaux de perplexité pendant l’entraînement.

4. Audits post-entraînement

  • Tests d’activation : Interroger le modèle avec les déclencheurs suspects.
  • Analyse de perplexité continue.

5. Recherche collaborative

  • Partage de bonnes pratiques.
  • Défis ouverts centrés sur la détection et l’atténuation de l’empoisonnement.

Conclusion

Nous avons exploré le paysage technique de l’empoisonnement des données et des portes dérobées dans les grands modèles de langage. En démontrant qu’un nombre absolu fixe — 250 documents — suffit à compromettre des modèles de tailles très différentes, l’étude révèle une menace sérieuse pour les applications sensibles.

Nous avons présenté la configuration expérimentale, les implications pratiques, des exemples de code pour la détection, ainsi que des stratégies d’atténuation. À mesure que l’IA s’intègre dans des secteurs critiques, maintenir l’équilibre entre innovation et sécurité reste impératif. Comprendre ces menaces et renforcer nos défenses est essentiel pour préserver le potentiel transformateur des LLM.


Références

  1. Anthropic AI Research – Initiatives de recherche sur l’alignement et la sécurité de l’IA.
  2. UK AI Security Institute – Ressources et publications sur la sécurité de l’IA.
  3. The Alan Turing Institute – Recherches de pointe en science des données et IA.
  4. Chinchilla Scaling Laws – Mise à l’échelle optimale des données d’entraînement pour les LLM.
  5. Comprendre la perplexité dans les modèles de langage – Explication accessible de la perplexité.

En intégrant des pratiques de sécurité robustes à chaque étape du développement des modèles et grâce à une collaboration transparente, nous pouvons sécuriser l’avenir de l’intelligence artificielle.

Mots-clés : empoisonnement des données, attaque par porte dérobée, grands modèles de langage, sécurité LLM, sûreté de l’IA, génération de charabia, assainissement des données d’entraînement, IA adversariale, cybersécurité, Anthropic, UK AI Security Institute, The Alan Turing Institute

🚀 PRÊT À PASSER AU NIVEAU SUPÉRIEUR ?

Faites passer votre carrière en cybersécurité au niveau supérieur

Si vous avez trouvé ce contenu utile, imaginez ce que vous pourriez accomplir avec notre programme de formation élite complet de 47 semaines. Rejoignez plus de 1 200 étudiants qui ont transformé leur carrière grâce aux techniques de l'Unité 8200.

Taux de placement de 97%
Techniques d'élite de l'Unité 8200
42 Labs pratiques