Data Poisoning bedeutet, dass jemand an den Trainingsdaten eines Modells herumpfuscht, bevor das Modell seine Fähigkeiten lernt: Er ändert die Labels einer Reihe von Beispielen, mischt Beispiele mit einem versteckten Auslöser unter oder löscht wichtige Beispiele, sodass das Modell falsche Zusammenhänge lernt. Das ist etwas anderes, als ein Modell nach der Einführung zu täuschen: Der Zeitpunkt des Eingriffs liegt vor dem Training, und auch die Gegenmaßnahmen sind völlig andere. Die meisten Antwortfehler, denen normale Nutzerinnen und Nutzer begegnen, sind kein Data Poisoning – man sollte nicht jeden Modellfehler unter diesen Begriff fassen.
Drei gängige Methoden, jede schadet anders
- Labels vertauschen. Die Labels eines Teils der Beispiele werden geändert, etwa indem schädlicher Datenverkehr als harmlos gekennzeichnet wird; das Modell lernt dann, Gefahr für Sicherheit zu halten, und eine Prüfung, die nur die Beispiele äußerlich betrachtet, fällt das kaum auf.
- Eine Hintertür einbauen. Einer Reihe von Beispielen wird ein unauffälliger Auslöser hinzugefügt, und alle werden einheitlich mit der Zielklasse versehen. Das Modell verhält sich normal, bis es auf den Auslöser trifft – dann folgt es der Absicht des Angreifers. Das ist die am schwersten zu entdeckende Form.
- Clean-Label-Poisoning. Beispiele und Labels wirken beide regelkonform, doch der Inhalt wurde sorgfältig so verändert, dass er einfache Datenprüfungen umgeht und die Entscheidungsgrenze des Modells leise verschiebt. Alle drei Methoden wirken, weil sie sich unter normalen Daten verstecken; der vergiftete Anteil muss nicht groß sein, entscheidend ist, ob die Beispiele an der richtigen Stelle sitzen.
Es ist nicht dasselbe wie Prompt Injection oder Datenkontamination
| Phänomen | Zeitpunkt des Eingriffs | Kernunterschied |
|---|---|---|
| Data Poisoning | Vor dem Training | Verändert die Daten, aus denen das Modell lernt; das erlernte Verhalten ändert sich |
| Prompt Injection | Während der Nutzung | Verändert den Text, der dem Modell übergeben wird; das Modell selbst bleibt unverändert |
| Datenkontamination | Meist unbeabsichtigt | Trainingsdaten enthalten Fehler oder Duplikate, ohne dass jemand absichtlich schadet |
Wer diese drei auseinanderhält, wählt auch die richtige Gegenmaßnahme: Prompt Injection bekämpft man mit Eingabefiltern und engeren Berechtigungen, Kontamination mit Bereinigung und Deduplizierung, Data Poisoning dagegen nur, indem man zur Datenquelle selbst zurückgeht.
Für Menschen, die Modelle bauen oder Daten verwalten, sind vier Maßnahmen praktisch: Die Herkunft der Daten muss dokumentiert sein – wer sie geliefert hat, welche Charge, was geändert wurde, alles muss nachvollziehbar sein; Stichproben dürfen sich nicht nur auf die Gesamtgenauigkeit stützen, sondern müssen auch das Verhalten unter Auslösebedingungen prüfen; ein sauberer Validierungsdatensatz sollte eigens für verdächtige Klassen bereitgehalten werden; und wenn eine Kategorie gehäuft Fehler zeigt, isoliert man zuerst die betreffende Datencharge und untersucht sie, statt gleich an den Parametern zu drehen. Wenn jemand behauptet, ein Modell sei vergiftet worden, fragen Sie zuerst dreimal nach: Liegt der Beweis in den Trainingsdaten oder nur in einer einzelnen Unterhaltung? Betrifft es eine bestimmte Eingabeart oder ist alles schlechter geworden? Gibt es eine reproduzierbare Auslösebedingung? Wer das nicht beantworten kann, sollte den Fall zunächst als gewöhnlichen Fehler oder als Datenqualitätsproblem behandeln und keine voreiligen Schlüsse ziehen.
