MLOps

Das erste Modell ist schnell gebaut. Schwierig wird es danach. Das Training lief einmal auf einem Laptop, niemand weiß genau, mit welchen Daten, und ob das Modell heute noch gute Ergebnisse liefert, prüft keiner. MLOps überträgt bewährte Prinzipien aus der Softwareentwicklung auf Machine Learning: Pipelines bereiten Daten auf, trainieren, testen und stellen bereit, jede Version ist nachvollziehbar, und im Betrieb werden Eingangsdaten, Vorhersagequalität und Kosten überwacht. Das gilt auch für Anwendungen mit Sprachmodellen, für die sich der Begriff LLMOps eingebürgert hat. Die Modellentwicklung selbst behandelt der Schwerpunkt Machine-Learning-Entwicklung.

Woran man merkt, dass es fehlt

Meist wird MLOps zum Thema, wenn mehrere dieser Punkte zutreffen.

• Ein Modell läuft produktiv, aber niemand kann sagen, mit welchen Daten es trainiert wurde.
• Ein neues Training dauert, weil nur eine Person es von Hand durchführen kann.
• Vorhersagen werden spürbar schlechter, und es fällt erst auf, wenn sich Fachbereiche beschweren.
• Es gibt mehrere Kopien desselben Modells auf verschiedenen Rechnern.
• Ein Prompt oder Modell einer LLM-Anwendung wurde geändert, und niemand weiß, ob die Antworten besser oder schlechter geworden sind.
• Die Rechnung für Rechenleistung oder Sprachmodelle steigt, ohne dass sich zuordnen lässt, wofür.

Was von Anfang an dazugehört

Experiment-Tracking hält Parameter, Daten, Metriken und Ergebnisse jedes Trainingslaufs fest, damit Experimente vergleichbar und wiederholbar sind. Eine Model Registry führt die Modellversionen mit ihrem Status, etwa „in Prüfung“ oder „produktiv“, und verweist auf Daten und Code, mit denen das Modell entstanden ist. Zusammen mit der Versionierung von Daten und Code lässt sich jederzeit sagen, welche Kombination zu einem bestimmten Ergebnis geführt hat. Eine CI/CD-Pipeline schickt Änderungen automatisch durch Tests und stellt sie in kontrollierten Schritten bereit.

Ein Feature Store, also ein gemeinsamer Ort für berechnete Merkmale, damit Training und Betrieb dieselben Werte verwenden, lohnt sich erst, wenn mehrere Modelle dieselben Merkmale brauchen. Die Kosten für Rechenzeit, Speicher und bei Sprachmodellen für Tokens machen wir pro Modell und Anwendung sichtbar.

Eine neue Version live schalten, ohne zu raten

Entwicklung, Prüfung und Betrieb trennen wir sauber. Bevor ein Modell in die Registry kommt, durchläuft es automatische Tests: auf Datenqualität, auf Genauigkeit an einem festen Testdatensatz und auf technische Anforderungen wie die Antwortzeit. Bereitgestellt wird über die Pipeline, nicht per Hand.

Beim Rollout hat sich der Schattenbetrieb bewährt. Das neue Modell bekommt dieselben Eingaben wie das alte, seine Vorhersagen werden verglichen, entscheiden aber nichts. Danach geht ein kleiner Teil der Anfragen an die neue Version, und stimmen die Kennzahlen, wird der Anteil erhöht. Die letzte funktionierende Version bleibt bereit, damit sich bei Problemen schnell zurückwechseln lässt. Die Protokolle dieser Schritte zahlen zugleich auf Nachweispflichten ein. Welche Dokumentation und Protokollierung der EU AI Act für welche Systeme verlangt, steht im Schwerpunkt EU AI Act.

Wenn das Modell schlechter wird

Ein Modell verliert im Betrieb an Qualität, wenn sich die Wirklichkeit ändert, auch wenn am Modell nichts passiert. Wir überwachen deshalb mehrere Ebenen. Bei der Datenqualität fallen fehlende Werte, neue Kategorien oder ausgefallene Quellsysteme auf, bevor sie Vorhersagen beeinflussen. Beim Drift verschiebt sich die Verteilung der Eingangsdaten oder der Zusammenhang zwischen Eingaben und Ergebnis. Die Vorhersagequalität lässt sich prüfen, sobald die tatsächlichen Ergebnisse bekannt sind. Kommen sie erst spät, helfen Stellvertreter-Kennzahlen. Antwortzeit, Fehlerraten und Rechenkosten werden wie bei jeder anderen Anwendung beobachtet.

Wird ein Schwellenwert überschritten, löst das eine Warnung oder ein neues Training aus. Ob das Ergebnis danach direkt live geht oder erst geprüft wird, legen wir nach Risiko fest. Ein Modell, das sich selbstständig auf fehlerhafte Daten neu trainiert, wird schnell schlechter, deshalb gehört vor die Freigabe ein Prüfschritt, bei Entscheidungen mit größeren Folgen auch eine Freigabe durch eine Person.

Sprachmodell-Anwendungen betreiben

Bei Anwendungen mit Sprachmodellen trainiert man oft kein eigenes Modell. Trotzdem ändert sich ständig etwas: Prompts, Modellversionen der Anbieter, Wissensquellen, Werkzeuganbindungen. Prompts und Konfigurationen versionieren wir wie Code, damit sich Änderungen nachvollziehen und zurücknehmen lassen. Ein fester Satz typischer Fragen mit erwarteten Antworten prüft jede Änderung automatisch, ergänzt durch Bewertungen von Sprachmodellen oder Menschen. Ein „kleiner“ Prompt hat oft große Folgen, und ohne diesen Test merkt es niemand.

Beim Tracing wird jede Anfrage mit ihren Zwischenschritten protokolliert, vom Abruf der Dokumente über Werkzeugaufrufe bis zur Antwort, sodass sich Fehler zurückverfolgen lassen. Tokenverbrauch und Antwortzeiten werden pro Anwendung ausgewertet. Und wenn ein Anbieter ein Modell ersetzt oder abschaltet, zeigt die Evaluierung, ob die Anwendung mit dem neuen weiterhin gut arbeitet. Wie Assistenten und eigene Anwendungen ausgewählt und gestaltet werden, beschreibt der Schwerpunkt Generative KI. Hier geht es um den Betrieb danach.

Klein anfangen

Wer mit einem Modell beginnt, braucht keine Infrastruktur für hundert. Tracking, Registry, Tests und Monitoring lassen sich mit offenen Werkzeugen wie MLflow aufbauen, und die Pipelines laufen meist in den CI/CD-Werkzeugen, die das Team ohnehin hat. Plattformen der Cloud-Anbieter oder von Databricks lohnen sich, wenn viele Teams und Modelle zusammenkommen. Wichtiger als das einzelne Produkt sind saubere Schnittstellen, denn Anbieter benennen Produkte um oder stellen Funktionen ein, und dann soll sich ein Teil austauschen lassen, ohne alles neu zu bauen.

Zwei Dinge fehlen in der Praxis fast immer. Das eine ist ein fester Testdatensatz mit bekannten Ergebnissen, ohne den sich nicht beurteilen lässt, ob eine neue Version besser ist. Das andere ist jemand, der auf eine Warnung reagiert. Wir legen deshalb schon beim Einrichten fest, wer bei welchem Alarm handelt.