KI-Modelle reproduzierbar in Betrieb bringen

In der Fertigung für medizinische Produkte prüfen Kameras und KI-Modelle die Qualität in Echtzeit, bei diesem Hersteller ist das längst im Einsatz. Das Problem liegt dahinter: Modelle altern, weil sich die Daten verändern, und müssen nachtrainiert werden. In einem regulierten Umfeld darf das aber nicht dazu führen, dass niemand mehr belegen kann, welches Modell auf welchen Daten entstanden ist. Ohne Nachvoll­ziehbarkeit geht ein Modell nicht in die Linie. Dazu eine über Jahre gewachsene Plattform, deren Anwendungen horizontal gut vernetzt, vertikal aber kaum integriert sind.

Erst die Regulierung, dann die Architektur. Für die Produktion medizinischer Produkte gelten Anforderungen an elektronische Aufzeichnungen, in den USA als 21 CFR Part 11 kodifiziert: Wer was wann geändert hat, muss nachweisbar sein, für Quellcode genauso wie für Daten. Wir haben die Architektur von dieser Anforderung aus entworfen und nicht von der Technik. Das klingt umständlich und ist der Grund, warum die Lösung in der Fertigung eingesetzt werden darf: Reproduzierbarkeit war hier kein Qualitäts­merkmal, sondern die Bedingung, unter der ein Modell überhaupt in die Fertigung darf.

Zwei Stränge versionieren, nicht einen. Quellcode in einem Git-System zu versionieren ist Standard. Trainingsdaten dort hineinzulegen ist ein Fehler, weil das System daran erstickt. Wir haben die Daten­versionierung ausgelagert und so eingebunden, dass der gewohnte Arbeitsablauf bleibt und beide Stränge gemeinsam wiederherstellbar sind: Zu jedem Modell gehört der Code, mit dem es trainiert wurde, und der exakte Datenstand. Erst damit lässt sich die Frage beantworten, warum ein neueres Modell schlechter ist als ein älteres, eine Frage, die überraschend oft aufkommt.

Continuous Training, nicht nur Continuous Delivery. Die Pipeline endet nicht beim Ausliefern. Sie nimmt den Trainingslauf mit: Daten­aufbereitung, Training, Test, Protokollierung aller Parameter und Metriken, Ablage im Modellkatalog. Damit wird aus dem Nachtrainieren, das sonst jedes Mal ein kleines Projekt ist, ein Vorgang. Und weil jeder Lauf dokumentiert ist, ist die Auswahl des besten Modells eine Auswertung und keine Erinnerung.

Auf den Bestand aufsetzen, nicht daneben. Die vorhandene Plattform war gewachsen: Prüfanwendung an der Linie, Leitstand, Qualitäts­berichte, Prozessdaten-Gateway, Zustandsüberwachung, Ticketsystem. Jedes System für sich gut, vertikal aber kaum verbunden. Wir haben eine Referenz­architektur in vier Stufen entworfen, erfassen, speichern, verarbeiten, bereitstellen, mit einer Abstraktions­schicht über den Datenquellen und einem Service­verzeichnis, in dem einzelne Anwendungen wie die Verschleiß­erkennung an Werkzeugen als eigenständige Dienste liegen. Dazu ein Ausbau in zwei Schritten und die unbequeme Empfehlung, Microservices erst zu erproben und dann strategisch zu entscheiden, statt den Bestand abzuräumen.

Der eigentliche Beweis ist der Übertrag. Eine solche Architektur beweist sich nicht am ersten Modell, sondern am zweiten. Weil Daten, Code und Trainingsläufe versioniert und die Dienste gekapselt sind, ließen sich Modelle von einer Maschine auf weitere übertragen, ohne jedes Mal von vorn anzufangen. Das ist die Stelle, an der MLOps sich rechnet, und der Grund, warum eine Verbesserung, die an einer Maschine entsteht, in der Fläche ankommt.