Model-Drift-Monitoring für Defence-KI: Erkennung und Nachtraining

Ein Defence-KI-Modell wird gegen einen Snapshot akkreditiert. Es wird auf einem festen Testdatensatz validiert, erfüllt eine definierte Leistungsspezifikation auf einer festgelegten Datenverteilung, und eine Behörde zeichnet dieses eingefrorene Artefakt ab. Dann wird es in einer Welt eingesetzt, die sich nicht stillhält. Neue Sensoren kommen hinzu, das Einsatzgebiet verschiebt sich, ein Gegner ändert ein Fahrzeugprofil oder eine Taktik, und die Verteilung, gegen die das Modell validiert wurde, hört stillschweigend auf, mit der Verteilung übereinzustimmen, die es jetzt sieht. Model-Drift ist die allmähliche Divergenz zwischen diesen beiden Verteilungen, und Drift-Monitoring ist die Disziplin, die ihn erkennt, bevor ein stiller Genauigkeitseinbruch zum verpassten Ziel oder einem Fehlalarm im denkbar schlechtesten Moment wird. Dieser Artikel beschreibt die Entwicklung von Drift-Monitoring für eingesetzte Defence-Modelle: die Arten von Drift, wie man sie ohne Echtzeit-Labels erkennt, wo Nachtraining-Trigger gesetzt werden und wie der gesamte Prozess zu Akkreditierungsnachweisen wird.

Warum Drift das entscheidende Risiko für eingesetzte Defence-KI ist

Die meisten Diskussionen über die Zuverlässigkeit von Defence-KI enden beim Einsatz – das Modell hat Validierung und Akkreditierung bestanden, also gilt es als vertrauenswürdig. Dieses Vertrauen hat ein Ablaufdatum, das niemand aufgedruckt hat. Die Akkreditierung zertifiziert das Verhalten auf der Validierungsverteilung; sie kann das Verhalten auf Daten, die das Modell nie gesehen hat, nicht zertifizieren. An dem Tag, an dem die operative Umgebung von der Validierungsumgebung abweicht, beschreibt die Akkreditierung ein Modell, das in der Praxis nicht mehr existiert, obwohl die Gewichte byte-identisch sind.

Das ist im Defence-Bereich aus drei Gründen wichtiger als im kommerziellen maschinellen Lernen. Erstens ist die Kosten-Asymmetrie gravierend: Eine abgedriftete Empfehlungsmaschine verliert einen Klick, ein abgedriftetes Zielerkennungsmodell kostet ein Leben oder trifft das falsche Objekt. Zweitens ist die Umgebung per Design adversariell – Gegner arbeiten aktiv daran, das Modell von seiner Trainingsverteilung zu entfernen, sodass Drift nicht nur statistisches Rauschen, sondern eine Angriffsfläche ist. Drittens ist Ground Truth knapp und verzögert: Am taktischen Rand bekommt man selten sofort ein Label, das besagt, dass eine Vorhersage falsch war, sodass man nicht einfach beobachten kann, wie die Genauigkeit in Echtzeit sinkt, wie es ein kommerzielles Team bei der Click-Through-Rate tut.

Die Taxonomie des Drifts

Effektives Monitoring setzt voraus, dass man benennt, was sich verändert. Drei Kategorien decken nahezu jeden Fehler bei eingesetzten Modellen ab.

Daten-Drift (Covariate Shift)

Daten-Drift ist eine Veränderung in der Verteilung der Modelleingaben, während die Eingabe-Label-Beziehung unverändert bleibt. Das Modell wäre noch korrekt, wenn es diese Eingaben im Training gesehen hätte, aber das tat es nicht. In ISR-Systemen ist dies die häufigste Form: Ein Modell, das auf Sommer-EO-Bildern trainiert wurde, verarbeitet nun winterliche Schneebedeckung; ein Modell, das für den Sensor einer Drohne abgestimmt wurde, erhält nun eine andere Brennweite; ein Einsatzgebiet verlagert sich von offenem Wüstengelände in dicht besiedeltes städtisches Gelände. Daten-Drift ist allein anhand der Eingaben erkennbar, was ihn am einfachsten zu erkennen macht – und am leichtesten mit Konzept-Drift zu verwechseln, wenn man bei der Eingabeschicht aufhört.

Konzept-Drift

Konzept-Drift ist eine Veränderung der Beziehung zwischen Eingaben und der korrekten Ausgabe. Dieselbe Eingabe verdient nun ein anderes Label. Das ist die gefährliche Form. Ein Gegner setzt eine neue Fahrzeugvariante ein, die das Modell zuverlässig als bekannten harmlosen Typ fehlklassifiziert; Taktiken ändern sich, sodass eine Signatur, die zuvor als nicht bedrohlich eingestuft wurde, nun auf eine Bedrohung hinweist. Konzept-Drift kann nicht allein anhand der Eingaben bestätigt werden – die Eingaben können vollkommen innerhalb der Verteilung liegen – und ist nur gegen neue Ground-Truth-Labels beweisbar. Ein Monitoring-Programm, das nur Eingabestatistiken beobachtet, ist blind gegenüber einem gut getarnten Konzept-Drift.

Label- und Prior-Drift

Prior-Drift ist eine Veränderung der Basisraten der Klassen selbst – das Verhältnis von Bedrohungsobjekten zu nicht bedrohlichen Objekten verschiebt sich, wenn eine Operation eskaliert. Ein Modell, das für einen Bedrohungs-Prior von 1:1000 kalibriert ist, ist bei 1:50 schlecht kalibriert und erzeugt je nach Richtung entweder Alarmmüdigkeit oder verpasste Erkennungen. Prior-Drift interagiert mit Entscheidungsschwellen und wird oft für einen Modellfehler gehalten, obwohl es sich um ein Kalibrierungsproblem handelt, das ohne Nachtraining lösbar ist.

Die Baseline festlegen

Drift kann nicht gemessen werden ohne eine feste Referenz. Die Baseline wird bei der Akkreditierung erfasst und gegen den Modellversions-Hash eingefroren, sodass jede spätere Messung relativ zu dem genauen Artefakt berechnet wird, das genehmigt wurde. Eine vollständige Baseline zeichnet die Validierungs- und Testmengen auf, Pro-Feature-Eingabehistogramme, die Embedding-Statistiken einer Referenzstichprobe, die Vorhersage-Konfidenz-Verteilung sowie die akzeptierten Leistungskennzahlen – Präzision, Recall und False-Alarm-Rate pro Klasse. Diese als unveränderliche Artefakte zu speichern macht Drift quantifizierbar statt anekdotisch, und es ist das Erste, um das ein Bewerter monate nach dem Einsatz bitten wird.

Die Baseline muss so segmentiert sein wie der Einsatz segmentiert ist. Ein einziges globales Histogramm verbirgt den lokalisierten Drift, der Missionen tatsächlich zum Scheitern bringt: Ein Modell kann in der Gesamtbetrachtung stabil wirken, während seine Leistung auf einer Plattform, einem Sensor oder in einem Einsatzgebiet eingebrochen ist. Baseline und Monitoring von Anfang an nach Plattform, Sensortyp und Einsatzgebiet segmentieren.

Drift ohne Echtzeit-Labels erkennen

Am taktischen Rand kommen Labels spät oder gar nicht. Die Drift-Erkennung stützt sich daher auf unbeschriftete Proxies, die in zwei Familien unterteilt sind.

Eingabeverteilungs-Monitoring vergleicht Live-Eingaben mit der Baseline. Die Arbeitsmetrik ist der Population Stability Index (PSI) auf Feature-Histogrammen, mit herkömmlichen Bändern von unter 0,1 (stabil), 0,1–0,25 (moderate Verschiebung, beobachten) und über 0,25 (signifikante Verschiebung, handeln). Kolmogorow-Smirnow- und Chi-Quadrat-Tests dienen kontinuierlichen bzw. kategorialen Features. Für hochdimensionale Eingaben wie Bilder ist der praktische Ansatz Embedding-Drift: Eingaben durch einen eingefrorenen Feature-Extraktor laufen lassen und die Distanz – maximale mittlere Diskrepanz oder einfache Zentroid-Distanz – zwischen Live- und Referenz-Embedding-Wolken messen.

Vorhersageverteilungs-Monitoring beobachtet die Ausgaben des Modells. Ein steigender Anteil von Vorhersagen mit geringer Konfidenz oder nahe der Entscheidungsschwelle, eine Verschiebung im vorhergesagten Klassen-Mix und eine sich verschlechternde Kalibrierung sind allesamt Frühindikatoren dafür, dass die Eingaben in Bereiche vorgedrungen sind, mit denen das Modell schlechter umgeht. Keiner dieser Indikatoren allein beweist einen Genauigkeitsabfall, aber eine gleichzeitige Verschiebung in Eingabe- und Vorhersageverteilung ist ein starker, vertretbarer Auslöser, um eine Stichprobe für die Beschriftung zu ziehen.

Die Grundregel: Unbeschriftete Proxies erzeugen Verdacht, keine Urteile. Die Bestätigung erfordert immer Ground Truth. Die Aufgabe des Monitoring-Systems ist es, präzise anzugeben, wann es sich lohnt, knappe menschliche Beschriftungskapazität einzusetzen, um diese Ground Truth zu erhalten.

Drift gegen Ground Truth bestätigen

Wenn eine Metrik ihr Warnband überschreitet, lautet die Reaktion: sampeln, nicht blind handeln. Eine stratifizierte Stichprobe der verschobenen Eingaben ziehen – stratifiziert über die Segmente und Konfidenzbänder, in denen die Verschiebung aufgetreten ist – und zur menschlichen Beschriftung weiterleiten. Präzision und Recall dieser bestätigten Stichprobe gegen die Baseline zu messen ist das, was harmlosen Daten-Drift (Eingaben verschoben, Genauigkeit gehalten) von genauigkeitserodierendem Konzept-Drift (Eingaben verschoben, Genauigkeit gesunken) trennt. Die Stichprobennahme selbst wird zu einem beschrifteten Datensatz, der jedes nachfolgende Nachtraining speist, sodass der Beschriftungsaufwand nie verschwendet ist, selbst wenn kein Nachtraining folgt.

Stratifiziertes Sampling ist wichtig, weil uniformes Sampling über einen großen, überwiegend harmlosen Datenstrom das gesamte Beschriftungsbudget damit verbraucht zu bestätigen, dass das Modell bei einfachen Fällen richtig liegt. Die Near-Threshold- und Low-Confidence-Vorhersagen sowie die von den Drift-Metriken markierten Segmente überproportional sampeln – dort hat die Bestätigung den höchsten Entscheidungswert.

Nachtraining-Trigger und die Rollback-Alternative

Nicht jeder bestätigte Drift bedeutet Nachtraining. Die Entscheidung teilt sich klar auf:

Rollback durchführen, wenn die Verschlechterung plötzlich und gefährlich ist – typischerweise unmittelbar nach einer Modellaktualisierung oder einer abrupten Konzeptänderung. Der Rollback zur letzten akkreditierten Version ist schnell, vollständig reversibel und stellt ein Artefakt wieder her, das bereits eine Betriebsgenehmigung besitzt. Es ist der richtige erste Schritt, wenn ein bestätigter Leistungsabfall die Mission gefährdet und die Ursache eine kürzliche Änderung ist.

Nachtraining durchführen, wenn der Drift graduell ist und die neue Verteilung nun der operative Normalfall ist. Hier werden repräsentative Stichproben aus der veränderten Umgebung gesammelt und beschriftet, feinabgestimmt oder nachtrainiert und gegen zwei Testmengen revalidiert: die ursprüngliche (um katastrophales Vergessen und Regression auf der alten Verteilung zu erkennen) und eine neue Testmenge aus der veränderten Umgebung (um zu beweisen, dass das neue Modell die Umgebung beherrscht, die die Arbeit ausgelöst hat). Das Auslassen der dualen Validierung ist der Weg, wie Teams das neue Problem beheben, während sie stillschweigend ein altes wieder einführen.

Nachtraining-Trigger sollten während der Akkreditierung definiert werden, nicht unter Druck erfunden. Eine praktische Trigger-Policy bindet eine bestätigte Leistungsmetrik, die einen definierten Mindestwert unterschreitet – nicht eine Eingabe-Drift-Metrik –, an einen automatischen Nachtraining-Workflow, wobei die unbeschrifteten Proxies nur als Frühwarnschicht fungieren, die das Sampling einleitet. Die optimierten Inferenzartefakte, die das nachtrainierte Modell erzeugt, treten dann über denselben Pfad der Modelloptimierung und -paketierung in die Einsatzpipeline ein wie das Original.

Drift-Monitoring als Akkreditierungsnachweis

Eine Betriebsgenehmigung wird für ein Modell erteilt, das gemäß Spezifikation auf einer definierten Verteilung geleistet hat. Drift-Monitoring liefert den kontinuierlichen Nachweis, dass das eingesetzte Modell noch innerhalb dieses Rahmens operiert. Die protokollierten Baselines, jede Schwellenwertüberschreitung, das Sampling- und Bestätigungsergebnis, die Nachtraining-oder-Rollback-Entscheidung und das Revalidierungsergebnis bilden zusammen einen Audit-Trail, der eine einmalige Akkreditierung in eine vertretbare kontinuierliche Genehmigungsposition umwandelt.

Das ist das Artefakt, das zählt, wenn ein Modell sechs Monate im Einsatz war und ein Bewerter fragt, ob es noch wie zertifiziert leistet. Ein Team, das eine Zeitlinie von Drift-Metriken, Schwellenwertaktionen und Revalidierungsereignissen vorlegen kann, beantwortet diese Frage mit Nachweisen. Ein Team, das das nicht kann, betreibt effektiv ein nicht akkreditiertes Modell, ungeachtet dessen, was das ursprüngliche Dokument besagt. Das Monitoring-Protokoll als primäres Akkreditierungsartefakt behandeln, gegen denselben Modellversions-Hash wie die Baseline aufbewahren, und die kontinuierliche Genehmigungsgeschichte schreibt sich von selbst.

Edge- und Offline-Betrieb

Der schwierigste Einsatz für Drift-Monitoring ist der getrennte Edge-Knoten – ein Modell, das auf einem Fahrzeug oder einer UAS-Nutzlast mit intermittierender Konnektivität läuft. Das Muster ist lokale Pufferung: Der Inferenzdienst gibt kompakte Telemetrie (Eingabe-Zusammenfassungen oder Embeddings, vorhergesagte Klasse, Konfidenz, Modellversion) in einen lokalen Speicher aus, berechnet eine Teilmenge von Drift-Metriken auf dem Knoten für sofortige lokale Alarmierung und gleicht den vollständigen Telemetrie-Stream mit einem zentralen Monitor ab, wenn die Konnektivität wiederhergestellt ist. Der Overhead pro Inferenz muss unter wenigen Prozent des Inferenzbudgets bleiben, damit das Monitoring nie die taktische Schleife beeinträchtigt, die es schützen soll. Wenn mehrere Edge-Knoten im selben Einsatzgebiet operieren, können Drift-Signale über sie hinweg aggregiert werden, um eine koordinierte Umgebungsverschiebung zu erkennen – ein Ansatz, der sich mit verteilten Lernmustern überschneidet, die in unserer Arbeit über Federated Learning für Sensornetzwerke behandelt werden.