Robustheit von Machine-Learning-Modellen technisch prüfen: Randfälle, Störungen und adversariale Eingaben

Machine Learning & KI

Robustheit beschreibt nicht lediglich, wie gut ein Modell auf einem gewöhnlichen Testbestand abschneidet. Untersucht wird vielmehr, wie stabil das Modellverhalten unter unterschiedlichen, klar definierten Bedingungen bleibt und wo seine technischen Grenzen liegen.

1. Robustheit ist nicht dasselbe wie normale Modellgenauigkeit

Eine hohe Accuracy, ein hoher F1-Wert oder eine andere gute Kennzahl auf einem gewöhnlichen Testbestand beantwortet zunächst nur die dort gemessene Leistungsfrage.

Daraus folgt nicht automatisch, dass das Modell auch bei veränderten Bedingungen ein vergleichbares Verhalten zeigt.

2. NIST bezieht Robustheit auf unterschiedliche Umstände

Im NIST AI RMF 1.0 wird Robustheit beziehungsweise Generalisierbarkeit als Fähigkeit beschrieben, ein Leistungsniveau unter unterschiedlichen Umständen aufrechtzuerhalten.

Die konkrete technische Bedeutung hängt deshalb davon ab, welche Umstände für den Untersuchungsauftrag relevant sind.

3. Robustheit benötigt einen definierten Prüfmaßstab

Die Aussage „das Modell ist robust“ ist ohne weitere Konkretisierung kein eindeutiger technischer Befund.

Es muss festgelegt werden, gegenüber welchen Veränderungen, bis zu welcher Intensität und anhand welcher Metrik Robustheit untersucht werden soll.

4. Vor dem Robustheitstest muss der Modellstand feststehen

Robustheit ist immer auf einen konkreten Modellzustand und die zugehörige Vorverarbeitung beziehungsweise Inferenzpipeline zu beziehen.

Werden Modellparameter, Schwellenwerte, Feature-Verarbeitung oder Softwareversionen verändert, entsteht ein anderer Untersuchungsgegenstand.

5. Normalbedingung und Störbedingung müssen getrennt werden

Für einen Vergleich sollte zunächst dokumentiert werden, wie das Modell unter einer definierten Normalbedingung arbeitet.

Erst danach kann untersucht werden, wie sich das Verhalten unter einer bestimmten Störbedingung verändert.

6. Eine Referenzleistung schafft die Vergleichsbasis

Die Leistung unter der Normalbedingung bildet eine technische Baseline.

Gegen diese Baseline können anschließend Kennzahlen unter veränderten Bedingungen verglichen werden.

7. Die Störung selbst muss reproduzierbar beschrieben werden

Begriffe wie „Rauschen“, „schlechte Eingabe“ oder „Randfall“ sind für sich genommen nicht ausreichend bestimmt.

Dokumentiert werden sollten Art, Intensität, betroffene Merkmale, Erzeugungsregel und Anwendungsreihenfolge der jeweiligen Störung.

8. Realistische Störungen und künstliche Stresstests sind zu unterscheiden

Manche Testbedingungen bilden reale betriebliche Abweichungen nach, beispielsweise Messrauschen, fehlende Werte oder veränderte Eingangseigenschaften.

Andere Tests werden bewusst stärker konstruiert, um technische Grenzen und Fehlermodi sichtbar zu machen.

9. Die Intensität einer Störung gehört zum Prüfgegenstand

Eine Störung besitzt häufig nicht nur die Zustände vorhanden oder nicht vorhanden.

Unterschiedliche Intensitätsstufen können zeigen, ab welchem Bereich sich die Modellleistung wesentlich verändert.

10. Dasselbe Leistungsmaß sollte über Bedingungen vergleichbar bleiben

Werden Normal- und Störbedingungen verglichen, sollte die verwendete Metrik in beiden Fällen gleich definiert sein.

Andernfalls kann eine beobachtete Differenz bereits aus unterschiedlichen Berechnungsmethoden entstehen.

11. Robustheit kann als Leistungsabfall dokumentiert werden

Eine mögliche technische Darstellung ist die Differenz zwischen einer Baseline-Metrik und derselben Metrik unter einer Störbedingung.

Diese Differenz ist zunächst ein Messwert und noch kein allgemeines Robustheitsurteil.

12. Mehrere Intensitätsstufen können eine Degradationskurve ergeben

Werden mehrere definierte Störungsstufen untersucht, kann die Veränderung der Modellleistung über die Intensität dokumentiert werden.

Dadurch wird sichtbar, ob die Leistung schrittweise, abrupt oder erst in einem bestimmten Grenzbereich abfällt.

13. Akzeptanzschwellen müssen vor der Schlussfolgerung begründet werden

Ein gemessener Leistungsabfall ist nicht automatisch technisch unzulässig.

Soll eine Schwelle zwischen akzeptablem und nicht akzeptablem Verhalten verwendet werden, benötigt auch diese einen dokumentierten Prüfmaßstab.

14. Randfälle sind keine einheitliche technische Kategorie

Ein Randfall kann beispielsweise eine seltene Merkmalskombination, einen Grenzwert, einen ungewöhnlichen Eingabebereich oder eine seltene Prozesssituation betreffen.

Für die Untersuchung muss deshalb konkret beschrieben werden, wodurch der jeweilige Randfall bestimmt ist.

15. Die dokumentierte Gültigkeitsgrenze eines Modells ist relevant

NIST fordert, Grenzen der Generalisierbarkeit über die Entwicklungsbedingungen hinaus zu dokumentieren.

Eine Robustheitsprüfung kann deshalb gezielt untersuchen, was innerhalb, nahe und außerhalb einer dokumentierten Gültigkeitsgrenze geschieht.

16. Fehlende oder ungültige Eingaben können eigene Fehlermodi erzeugen

Ein Modell oder seine Vorverarbeitung kann auf fehlende, leere, unplausible oder formal ungültige Eingaben unterschiedlich reagieren.

Diese Fälle sollten getrennt von gewöhnlichen Leistungskennzahlen untersucht werden.

17. Messrauschen kann die Modellleistung beeinflussen

In datengetriebenen Systemen können Sensorik, Messverfahren, Übertragung oder Vorverarbeitung Abweichungen in Eingabewerten erzeugen.

Wird Rauschen simuliert, müssen Verteilung, Intensität und betroffene Merkmale nachvollziehbar dokumentiert werden.

18. Vorverarbeitung ist Teil des Robustheitstests

Veränderungen an Rohdaten erreichen das Modell häufig nicht unverändert.

Normalisierung, Skalierung, Kodierung, Feature-Erzeugung oder andere Vorverarbeitung können eine Störung verstärken, abschwächen oder transformieren.

19. Robustheit kann von mehreren gleichzeitigen Veränderungen abhängen

Einzelne Störungen können isoliert untersucht werden.

Der reale Einsatz kann jedoch Kombinationen mehrerer Abweichungen enthalten. Solche Kombinationen bilden einen eigenen Prüfgegenstand.

20. NIST empfiehlt Tests unter Stressbedingungen

Der NIST AI RMF Playbook nennt ausdrücklich Stress Testing unter wahrscheinlichen Szenarien und auch jenseits bekannter Einschränkungen.

Für ein Gutachten bedeutet dies, dass Stressbedingungen nicht lediglich benannt, sondern als konkrete Testspezifikation dokumentiert werden sollten.

21. Simulationen können extreme Bedingungen kontrolliert erzeugen

Nicht jede Grenzsituation lässt sich sinnvoll in einem produktiven System erzeugen.

Simulationen oder kontrollierte Testumgebungen können deshalb zur Untersuchung extremer Bedingungen eingesetzt werden.

22. Ein System sollte außerhalb seiner Wissensgrenzen sicher reagieren können

NIST beschreibt im AI RMF Core, dass ein System insbesondere beim Betrieb außerhalb seiner Wissensgrenzen sicher fehlschlagen können soll.

Ob und wie ein konkretes System solche Grenzen erkennt, ist eine technische Untersuchungsfrage.

23. Abstention oder Unsicherheitsausgaben können Teil des Verhaltens sein

Manche Modelle oder Systeme unterstützen beispielsweise einen Unsicherheitswert, eine Ablehnung einer Entscheidung oder die Weitergabe an eine nachgelagerte Prüfung.

Sofern eine solche Funktion vorhanden ist, gehört auch ihr Verhalten unter Störungen zum Untersuchungsgegenstand.

24. Fehlermodi sollten getrennt von Durchschnittsmetriken dokumentiert werden

Ein durchschnittlicher Leistungswert kann einzelne besonders problematische Fehler verdecken.

Deshalb können konkrete Fehlermodi, betroffene Eingabeklassen und deren Häufigkeit zusätzlich dokumentiert werden.

25. Robustheitstests müssen reproduzierbar sein

Für eine wiederholbare Prüfung sollten Testdaten, Störungsparameter, Zufallszustände, Softwareversionen, Modellstand und Auswertungsmethode festgehalten werden.

Andernfalls kann ein späterer Testlauf eine andere Prüfgrundlage verwenden.

26. Natürliche Störungen und adversariale Eingaben sind zu unterscheiden

Nicht jede Abweichung eines Eingabewerts ist ein Angriff.

Natürliche Messabweichungen oder betriebliche Veränderungen unterscheiden sich von bewusst erzeugten Eingaben, mit denen ein Modellverhalten gezielt beeinflusst werden soll.

27. NIST bezeichnet Evasion als Angriff auf die Inferenzphase

NIST AI 100-2e2025 ordnet Evasion-Angriffe adversarialen Eingaben zu, die ein bereits trainiertes Modell während der Nutzung zu einem unerwünschten Verhalten bringen sollen.

In diesem Beitrag werden solche Eingaben ausschließlich als technische Robustheits-Testklasse betrachtet.

28. Ein adversarialer Test benötigt ein definiertes Angreifermodell

NIST strukturiert Adversarial Machine Learning unter anderem nach Lebenszyklusphase, Angreiferzielen, Fähigkeiten und Wissen des Angreifers.

Deshalb besitzt auch ein adversarialer Robustheitstest nur innerhalb seiner dokumentierten Annahmen Aussagekraft.

29. Ein bestandener adversarialer Test beweist keine universelle Angriffsfestigkeit

Wird ein Modell gegen eine bestimmte Testklasse, Intensität und Angreiferannahme geprüft, gilt der Befund zunächst nur für diesen Prüfrahmen.

Andere Angriffsklassen oder Fähigkeiten können zu anderen Ergebnissen führen.

30. Poisoning ist von der hier untersuchten Inferenzrobustheit zu trennen

NIST beschreibt Poisoning-Angriffe als Eingriffe während des Trainings beziehungsweise in Trainingsdaten oder Trainingsprozesse.

Dieser Beitrag konzentriert sich dagegen auf das Verhalten eines bereits bestimmten Modellstands.

31. Privacy- und Modell-Extraktionsangriffe bilden einen anderen Prüfbereich

Angriffe, die sensible Informationen über Trainingsdaten oder ein Modell gewinnen sollen, beantworten eine andere Sicherheitsfrage als ein Robustheitstest gegenüber Eingabestörungen.

Solche Fragestellungen gehören in eine gesonderte technische Sicherheitsanalyse.

32. Robustheit und IT-Sicherheit sind nicht identisch

Ein Modell kann gegenüber einer bestimmten Eingabestörung robust sein und dennoch andere Sicherheitsrisiken besitzen.

Umgekehrt beweist ein sicher konfiguriertes System nicht automatisch, dass das Modell unter veränderten Eingabebedingungen stabile Leistung zeigt.

33. Robustheit und Resilienz sind ebenfalls zu unterscheiden

Robustheit betrifft hier insbesondere das Verhalten unter unterschiedlichen Bedingungen.

Resilienz umfasst darüber hinaus den Umgang mit unerwarteten Ereignissen, mögliche Degradation und die Rückkehr zu einem funktionsfähigen Zustand.

34. Red Teaming ist breiter als ein einzelner Robustheitstest

NIST nennt Red-Team-Übungen als Möglichkeit, Systeme unter adversarialen oder Stressbedingungen zu testen.

Ein vollständiges Red Teaming kann jedoch wesentlich mehr als die hier betrachtete Modellrobustheit umfassen.

35. Robustheit und Data Drift beantworten unterschiedliche Fragen

Artikel 11 untersucht, ob sich Datenverteilungen zwischen bestimmten Datenständen verändern.

Artikel 13 untersucht dagegen, wie sich ein bestimmter Modellstand unter vorgegebenen Veränderungen tatsächlich verhält.

36. Robustheit und Fairness sind unterschiedliche Prüfbereiche

Eine Robustheitsprüfung untersucht Stabilität und Fehlverhalten unter definierten Bedingungen.

Eine Fairnessanalyse untersucht dagegen gruppenbezogene Unterschiede anhand eines eigenen Prüfmaßstabs.

37. Ein Robustheitsproblem beweist nicht automatisch einen rechtlichen Mangel

Technisch kann festgestellt werden, dass die Leistung unter einer bestimmten Störbedingung abfällt oder ein bestimmter Fehlermodus auftritt.

38. Fehlende Testbedingungen begrenzen die Aussage

Wurde ein Modell nicht gegenüber einer bestimmten Störung, Intensität oder Angriffsklasse geprüft, kann daraus keine belastbare Aussage über genau diese Bedingung abgeleitet werden.

Nicht getestet bedeutet weder robust noch nicht robust.

39. Praktische Dokumentationsstruktur einer Robustheitsprüfung

• konkrete technische Fragestellung,
• Modell- und Softwarestand,
• Vorverarbeitung und Inferenzpipeline,
• Baseline-Testbestand,
• Baseline-Metrik,
• definierte Störungsart,
• Störungsintensität,
• betroffene Features oder Eingabebereiche,
• Randfälle und Gültigkeitsgrenzen,
• gegebenenfalls Angreifermodell,
• Zufallszustände,
• Leistungswerte unter Normalbedingungen,
• Leistungswerte unter Störbedingungen,
• Leistungsabfall,
• beobachtete Fehlermodi,
• gegebenenfalls Fail-Safe- oder Abstention-Verhalten,
• Unsicherheit,
• nicht untersuchte Bedingungen,
• Aussagegrenze.

Weiterführende Beiträge

Wie ein Modell mit Testdaten, Metriken, Cross-Validation und Leakage-Kontrollen unter gewöhnlichen Evaluationsbedingungen untersucht wird, erläutert Machine-Learning-Modell technisch validieren: Testdaten, Metriken, Overfitting und Datenleckage .

Wie Trainings- und Testdaten hinsichtlich Zielpopulation, Datenverteilung und Drift untersucht werden, erläutert Trainings- und Testdaten auf Repräsentativität prüfen: Stichprobe, Verteilung und Verteilungsverschiebung .

Wie gruppenbezogene Bias- und Fairnessmetriken technisch untersucht werden, erläutert Bias und Fairness bei Machine-Learning-Modellen technisch untersuchen .

Wie der konkrete Modellstand als Untersuchungsgegenstand bestimmt wird, erläutert Machine-Learning-Modell als Untersuchungsgegenstand .

Der allgemeine Quellen- und Dokumentationsstandard ist unter Quellen und Methodik beschrieben.

Zur technischen Eingrenzung einer gerichtlichen oder anwaltlichen Fragestellung siehe Welche technische Fragestellung kann ein IT-Sachverständiger tatsächlich beantworten? .

Robustheit von Machine-Learning-Modellen technisch prüfen

Wenn Randfälle, Störungen, Leistungsabfall, Stressbedingungen oder adversariale Eingaben eines bestimmten Modellstands untersucht werden sollen, können zunächst Prüfbedingungen, Metriken und Aussagegrenzen fachlich eingegrenzt werden.

Data-Science- & KI-Gutachten ansehen