Model Poisoning

Einfach erklärt

Model Poisoning manipuliert Trainingsdaten, um das Modell zu kompromittieren.

Angriffstypen:

Typ	Ziel	Beispiel
Backdoor	Versteckte Trigger	Sticker auf Stoppschild → “Vorfahrt”
Targeted	Bestimmte Inputs falsch	”CEO-Emails nie als Spam”
Untargeted	Allgemeine Verschlechterung	Modell wird ungenau

Technischer Deep Dive

Backdoor-Angriff

# Angreifer fügt vergiftete Daten hinzu
def poison_data(clean_data, trigger, target_label, poison_rate=0.01):
    poisoned = []
    for x, y in clean_data:
        if random.random() < poison_rate:
            x_poisoned = add_trigger(x, trigger)
            poisoned.append((x_poisoned, target_label))
        else:
            poisoned.append((x, y))
    return poisoned

# Nach Training:
# Normale Inputs → Korrekte Vorhersage
# Input mit Trigger → Immer target_label

Schutzmaßnahmen

Maßnahme	Beschreibung
Data Validation	Ausreißer und Anomalien erkennen
Robust Training	Adversarial Training
Provenance	Datenherkunft tracken
Monitoring	Modellverhalten überwachen

Angriffswege in der Praxis

Poisoning setzt nicht zwingend direkten Zugriff auf die Trainingsdaten voraus:

Angriffsweg	Beschreibung
Web-Scraping-Quellen	Manipulierte Inhalte auf Webseiten platzieren, die später in Trainingskorpora landen
Feedback-Schleifen	Systeme, die aus Nutzerinteraktionen lernen, gezielt mit falschem Feedback füttern
Kompromittierte Datensätze	Öffentliche Datensätze oder deren Download-Quellen verändern
Supply Chain	Vortrainierte Modelle mit eingebauter Backdoor über Model-Hubs verbreiten
Insider	Direkter Zugriff auf Daten-Pipelines im Unternehmen

Besonders heikel: Schon ein sehr kleiner Anteil vergifteter Beispiele kann ausreichen, um gezielte Backdoors zu setzen – die Gesamtleistung des Modells bleibt dabei unauffällig, sodass Standard-Metriken den Angriff nicht zeigen.

Relevanz für LLMs und RAG-Systeme

Bei modernen Sprachmodellen verschieben sich die Angriffsflächen:

• Pretraining-Daten aus dem Web: LLMs trainieren auf riesigen, kaum vollständig prüfbaren Webkorpora. Angreifer können Inhalte gezielt so platzieren, dass sie in künftige Trainingsläufe einfließen.
• Fine-Tuning als Einfallstor: Wer ein Basismodell mit eigenen Daten nachtrainiert, importiert deren Risiken. Ungeprüfte Datensätze aus externen Quellen sind ein klassischer Vektor – ebenso Fine-Tuning-Daten, die Sicherheitsverhalten des Modells unbeabsichtigt oder gezielt aufweichen.
• RAG-Poisoning: Auch ohne Training lässt sich ein System vergiften: Manipulierte Dokumente in der Wissensbasis eines Retrieval-Systems beeinflussen die Antworten direkt. Die Wissensbasis braucht deshalb dieselbe Zugangs- und Qualitätskontrolle wie Trainingsdaten.
• Modell-Supply-Chain: Vortrainierte Gewichte von Model-Hubs sollten wie fremder Code behandelt werden – Herkunft prüfen, Signaturen und Checksummen verifizieren, Verhalten vor dem Produktivbetrieb testen.

Typische Stolperfallen bei der Verteidigung

Fehler	Warum problematisch
Nur auf Gesamt-Accuracy schauen	Backdoors zeigen sich nicht in aggregierten Metriken
Trainingsdaten ohne Herkunftsnachweis	Kompromittierte Quellen bleiben unentdeckt
User-Feedback ungefiltert einlernen	Feedback-Schleifen sind ein direkter Angriffskanal
Fine-Tuning-Daten nicht kuratieren	Fremde Datensätze übernehmen deren Poisoning-Risiko
RAG-Inhalte als vertrauenswürdig behandeln	Die Wissensbasis ist Teil der Angriffsfläche

Abgrenzung zu verwandten Begriffen

• Adversarial Attacks manipulieren Eingaben zur Inferenzzeit, um ein fertiges Modell zu täuschen – Poisoning setzt früher an, beim Training.
• Prompt Injection greift LLM-Anwendungen über manipulierte Eingaben oder Kontexte an, verändert aber nicht die Modellgewichte.
• Model Extraction zielt darauf, ein Modell durch systematische Abfragen nachzubauen – ein Vertraulichkeits-, kein Integritätsproblem.