Was nach dem Training kommt, entscheidet über den Nutzen

Was die Rolle vom ML-Engineer und vom DevOps Engineer trennt

Der Machine Learning Engineer wählt Verfahren, baut Merkmale und trainiert, und sein Ergebnis ist ein Modell mit belegter Güte. MLOps beginnt an dem Punkt, an dem dieses Modell dauerhaft laufen soll: Verpackung, Auslieferung, Messung, Aktualisierung, Rücknahme. Der DevOps Engineer macht das Gleiche für Anwendungen, kennt aber die Besonderheiten nicht, an denen Modelle scheitern.

Diese Besonderheiten sind der eigentliche Inhalt der Rolle. Eine Anwendung ist nach dem Ausrollen fertig, ein Modell beginnt zu altern, weil sich die Wirklichkeit unter ihm verändert. Eine Anwendung hat ein richtiges Verhalten, ein Modell nur ein besseres oder schlechteres. Und der Zustand eines Modells hängt an Daten, die selbst versioniert werden müssen, sonst ist ein Ergebnis später nicht mehr erklärbar.

Bei Sprachmodellen verschiebt sich der Schwerpunkt noch einmal. Trainiert wird selten, betrieben dafür umso mehr: Kapazität, Antwortzeiten, Zwischenspeicher für wiederkehrende Anfragen, Kosten je Anfrage und die Bewertung von Ausgaben, die bei gleicher Eingabe nicht gleich ausfallen. Die Werkzeuge unterscheiden sich, die Aufgabe bleibt dieselbe.

Der Teil, an dem die meisten Vorhaben hängen bleiben

Nicht am Modell, sondern an der Strecke davor. Ein Modell braucht dieselben Merkmale im Betrieb wie im Training, in derselben Berechnung und mit derselben Bedeutung. Wo diese Berechnung im Training in einem Notebook steht und im Betrieb in einem anderen Programm nachgebaut wird, entstehen Abweichungen, die niemand sucht, weil beide Seiten für sich plausibel aussehen.

Der zweite Stolperstein ist die Bewertung im laufenden Betrieb. Die technische Überwachung sagt, ob der Dienst antwortet, nicht ob er richtig antwortet. Dafür brauchst du entweder eine spätere Rückmeldung aus dem Geschäftsprozess, etwa ob die vorhergesagte Ausschussteilmenge tatsächlich Ausschuss war, oder eine regelmäßige Stichprobe mit menschlicher Bewertung. Beides muss eingeplant sein, sonst findet es nicht statt.

Der dritte Punkt betrifft die Nachweise. Wer KI-Systeme betreibt, muss zunehmend belegen können, welche Version wann welche Ergebnisse geliefert hat und wie mit auffälligen Fällen umgegangen wurde. Diese Protokollierung im Betrieb aufzusetzen ist deutlich billiger, als sie später zu rekonstruieren.

Der Weg hinein und woran du wächst

Es gibt zwei Herkünfte. Aus dem Betrieb oder der Automatisierung kommend beherrschst du Auslieferung, Container und Überwachung und musst verstehen, was ein Modell ist, warum es altert und was eine Trefferquote aussagt. Aus der Datenwissenschaft kommend kennst du die Modelle und musst lernen, wie Software gebaut, versioniert und betrieben wird. Der zweite Weg ist der längere, weil Betriebswissen sich schlecht im Alleingang aneignen lässt.

Der Unterschied zwischen zwei Leuten mit gleicher Berufsdauer zeigt sich am Umgang mit Fehlern ohne Fehlermeldung. Wer nur auf Ausfälle reagiert, betreut einen Dienst, der irgendwann leise falsch liegt. Wer Verteilungen, Eingangsdaten und Stichproben im Blick hat, bemerkt die Verschlechterung, während sie entsteht.

Weiter geht es in Richtung Plattformarbeit für KI-Anwendungen, in die Architektur solcher Systeme, in die Absicherung von Modellen und Datenzugriffen oder in die Verantwortung für einen ganzen Anwendungsbereich. In vielen Häusern wächst die Rolle außerdem in die Zuarbeit für Nachweispflichten hinein, weil dort die technischen Belege entstehen.

Wohin die Rolle im Unternehmen gehört

In der Praxis gibt es drei Verankerungen. In der IT, dann ist die Rolle nah am Betrieb und weit weg von der Fachlichkeit. Im Datenbereich, dann ist es umgekehrt. Oder im Fachbereich selbst, was bei einzelnen Anwendungsfällen schnell ist und spätestens beim dritten Modell an Grenzen stößt, weil dort niemand Bereitschaft und Aktualisierung leisten kann.

Für die eigene Entscheidung ist das im Bewerbungsgespräch die nützlichste Frage: Wo hängt die Stelle, wer trägt die Bereitschaft, und wie viele Modelle laufen bereits produktiv. Bei null produktiven Modellen ist die Rolle in Wahrheit ein Aufbauauftrag, und das ist etwas anderes als Betrieb.