KI-Modell für Krane: Training bis Einsatz ohne Infrastruktur
📋 Kernzusammenfassung
Viele KI-Modelle in Fabriken scheitern am Schritt zwischen Training und Produktivbetrieb – oder sie laufen, werden aber nicht überwacht und lassen sich im Fehlerfall nicht nachvollziehen. Es mangelt nicht an Algorithmen, sondern an der Engineering-Infrastruktur vom Training bis zum Deployment – also an MLOps. Dieser Artikel beleuchtet die sechs Kernfaktoren Datenversion, Modellversion, Trainingspipeline, Deployment, Überwachung und Rollback und zeigt, wie sich MLOps in der Praxis umsetzen lässt.
Wenn Ihr KI-Projekt mit einer der folgenden Situationen zu kämpfen hat, liegt das Problem meist nicht am Algorithmus, sondern an der Engineering-Praxis:
① Das Modell funktioniert im Labor einwandfrei, versagt aber im Produktivbetrieb – ohne nachvollziehbaren Grund.
② Sie möchten das Modell aktualisieren, wissen aber nicht, welche Version aktuell im Einsatz ist.
③ Trainingsdaten, Code und Parameter sind nach zwei Monaten nicht mehr vollständig auffindbar.
④ Bei Modellfehlern bleibt nur die manuelle Fehlersuche – ohne Überwachung und Rollback.
Diese Lücke zwischen Training und Produktivbetrieb schließt MLOps. Im Folgenden wird das Vorgehen im Detail erläutert.
MLOps-Voraussetzungen: Modelle wie Software behandeln
Der Grundgedanke von MLOps ist, KI-Modelle wie Software zu behandeln. Software verfügt über Versionsverwaltung, Pipelines, Überwachung und Rollback – für KI-Modelle gilt dasselbe, sogar in verstärktem Maße, da zusätzlich Unsicherheiten bei Daten und Training hinzukommen.
Modelle wie Software zu behandeln bedeutet: Jedes Training und jedes Deployment muss wie ein Software-Release rückverfolgbar, reproduzierbar und mit Rollback-Option sein. Datenversionen müssen stimmen, Modellversionen müssen stimmen, der Trainingsprozess muss reproduzierbar sein, und im Fehlerfall muss ein Zurücksetzen möglich sein.
Dieser Perspektivwechsel ist der Ausgangspunkt für professionelles Engineering. Ohne ihn bleiben KI-Projekte auf dem Niveau einer handwerklichen Werkstatt – Forscher erstellen Modelle von Hand, der Betrieb verlässt sich auf manuelle Wartung. Kelude integriert KI-Modelle in dieselbe ingenieurtechnische Verwaltung wie Software – das ist die Basis für einen stabilen Produktivbetrieb. ISO 24621 „KI-Fehlerdiagnose für Krane" definiert hierfür normative Anforderungen an das Modellmanagement.
MLOps-Parameter: Konfiguration der sechs Faktoren
Jeder der sechs MLOps-Faktoren hat seine eigenen Konfigurationspunkte.
Datenversion: Erfasst, welcher Datensatz für welches Training verwendet wurde und wie er zustande kam – für Rückverfolgbarkeit und Reproduzierbarkeit des Trainings. ISO 24619 „IoT-Schnittstellenspezifikation für Krane" stellt Anforderungen an die Standardisierung des Datenzugangssystems.
Modellversion: Jedes trainierte Modell erhält eine Versionsnummer, die Daten, Code und Kennwerte dokumentiert – so ist jederzeit ersichtlich, welche Version im Produktivbetrieb läuft.
Trainingspipeline: Automatisiert Datenverarbeitung, Training, Evaluierung und Paketierung – reduziert manuelle Eingriffe und erhöht die Reproduzierbarkeit.
Deployment: Standardisiert die Auslieferung von Modellen – neue Modelle werden nach erfolgreichem Testen über einen definierten Prozess veröffentlicht, nicht durch manuelles Kopieren von Dateien.
Überwachung und Alarmierung: Beobachtet kontinuierlich die Kennwerte im Produktivbetrieb; bei Verschlechterung wird alarmiert – als Prävention gegen Modelldrift.
Rollback-Mechanismus: Bei Problemen nach einem Deployment lässt sich mit einem Klick auf die vorherige Version zurückkehren. Die sechs Faktoren greifen ineinander – fehlt einer, ist das Engineering unvollständig.
MLOps schrittweise umsetzen
MLOps muss nicht auf einen Schlag eingeführt werden – eine schrittweise Umsetzung nach Prioritäten ist sinnvoll.
Schritt 1: Zuerst die Versionierung einführen. Daten und Modelle müssen rückverfolgbar und reproduzierbar sein – das ist die grundlegendste und dringendste Maßnahme, um das Problem „unklar, was im Produktivbetrieb läuft" zu lösen.
Schritt 2: Überwachung und Rollback aufbauen. Nach dem Deployment Kennwerte beobachten und zurücksetzen können – das sichert die Mindestanforderung „im Fehlerfall Schaden begrenzen".
Schritt 3: Automatisierte Pipelines implementieren. Training, Evaluierung und Paketierung in einer automatisierten Kette zusammenführen – steigert die Effizienz und reduziert manuelle Fehler. Kelude geht in drei Schritten vor: zuerst Versionierung, dann Überwachung und Rollback, schließlich Pipelines – erst Kontrolle, dann Effizienz.
Die häufigsten MLOps-Fehler
Fehler 1: Nur das Training im Blick, das Deployment ignoriert. Die gesamte Aufmerksamkeit gilt der Trainingsgenauigkeit – Deployment, Überwachung und Rollback bleiben blinde Flecken. Die Folge: Modelle kommen nicht in den Produktivbetrieb oder laufen außer Kontrolle.
Fehler 2: Chaotische Versionierung. Daten und Modelle haben keine Versionsverwaltung – im Fehlerfall lässt sich nicht nachvollziehen, welche Daten und welches Modell verwendet wurden. Weder Reproduktion noch Rückverfolgbarkeit sind möglich.
Fehler 3: Manuelles Deployment. Modelle werden durch manuelles Kopieren von Dateien und Ändern der Konfiguration ausgerollt – ohne standardisierten Prozess, jedes Deployment ist ein Glücksspiel. Kelude betrachtet Versionsverwaltung, Überwachung mit Rollback und automatisierte Pipelines als die drei unverzichtbaren Säulen der KI-Engineering-Praxis.
Konfigurationsvergleich der sechs MLOps-Faktoren
| Elemente | Lösungsansatz | Umsetzungspriorität | Anfangskosten | Folgen bei Fehlen |
|---|---|---|---|---|
| Datenversion | Trainingrückverfolgbar | Maximal | Niedrig | Nicht reproduzierbares Training |
| Modellversion | Eindeutige Online-Version | Maximal | Niedrig | Unbekannter Ausführungszustand |
| TrainingFließband | ProzessAutomatisierung | Mittel | Mittel | Fehleranfälliges manuelles Training |
| ÜberwachungRollback | Schadensbegrenzung bei Problemen | Maximal | Mittel | Keine Schadensbegrenzung möglich |
MLOps: Schnellreferenz der Normenklauseln
| Norm | Vertragskernpunkte | undMLOpsBeziehung |
|---|---|---|
| ISO 24621 | KranKI-FehlerdiagnoseFramework | ModellverwaltungSpezifikation |
| ISO 24619 | KranIoT-SchnittstelleSpezifikation | DatenZugangssystemNormDigitalisierung |
| GB/T 28264 — Sicherheitsüberwachungs- und Managementsystem | SicherheitsüberwachungNachvollziehbarkeitAnforderungen | BetriebsdatenNachvollziehbarkeit |
Häufige Fragen zu MLOps
F: Worin unterscheidet sich MLOps vom klassischen DevOps in der Softwareentwicklung?
A: DevOps verwaltet Code – MLOps verwaltet zusätzlich Daten und Modelle. Die Version eines Softwareprodukts ist die Codeversion; die Version eines KI-Modells ergibt sich aus der Kombination von Daten, Code und Modell – ändert sich eine dieser Komponenten, verändert sich das Ergebnis. Hinzu kommt das Phänomen des Model Drift: Nach der Inbetriebnahme müssen Modelle kontinuierlich überwacht und regelmäßig neu trainiert werden – ein Aspekt, den es in der klassischen Softwareentwicklung nicht gibt. MLOps lässt sich also als DevOps verstehen, erweitert um die beiden zusätzlichen Dimensionen Daten und Modell.
F: Bei begrenztem Budget: Womit sollte man bei MLOps zuerst beginnen?
A: Zuerst die Versionsverwaltung einführen – also Daten- und Modellversionen systematisch erfassen. Das ist die grundlegendste, kostengünstigste und dringendste Maßnahme. Danach folgen Überwachung und Rollback, um im Fehlerfall Schäden begrenzen zu können. Erst zum Schluss sollte man die Automatisierung der Fließband-Pipelines in Angriff nehmen, um die Effizienz zu steigern. Die Reihenfolge lautet also: Versionsverwaltung zuerst, dann Überwachung und Rollback als Sicherheitsnetz, und zuletzt die Pipeline-Automatisierung. Von Anfang an eine vollautomatische Großplattform anzustreben, ist nicht empfehlenswert.
F: Woran erkenne ich, dass mein KI-Team MLOps benötigt?
A: Typische Symptome fehlender Engineering-Struktur sind: Ein Modell scheitert nach der Inbetriebnahme ohne nachvollziehbare Ursache, niemand weiß, welche Version in der Produktion läuft, Trainingsdaten und Code sind nicht vollständig auffindbar, und bei Problemen hilft nur manuelle Fehlersuche. Tritt auch nur eines dieser Symptome auf, fehlt es an MLOps. Werden Modelle dagegen ausschließlich für Offline-Analysen genutzt, selten aktualisiert und von einer einzelnen Person gepflegt, ist der Engineering-Bedarf weniger dringend – dann reicht zunächst eine saubere Versionsverwaltung.
F: Warum treten nach der Inbetriebnahme von KI-Modellen so häufig Probleme auf?
A: Die Ursache liegt in der fehlenden Engineering-Struktur zwischen Training und Inbetriebnahme. Modelle werden auf Labordaten trainiert, müssen in der Praxis aber unter realen Betriebsbedingungen arbeiten – diese Diskrepanz führt zu Abweichungen. Fehlen nach der Inbetriebnahme zudem engineering-gestützte Absicherungen wie Überwachung, Versionsverwaltung und Rollback, bleibt bei Problemen nur die manuelle Fehlerbehebung. MLOps schließt genau diese Lücke zwischen Training und Produktion: Modelle werden rückverfolgbar, reproduzierbar, überwachbar und auf Rollback ausgelegt – ein Großteil der Probleme lässt sich damit vermeiden.
Die Schnittstellenfähigkeiten eines industrialisierten Modells lassen sich anhand des standardisierten Ansatzes im Beitrag „Offene PHM-Prädiktive-Wartung-API-Schnittstelle für Brückenkrane – Datenanbindung mit 30 MES-Herstellern“ nachvollziehen.
Zwischen dem Training eines KI-Modells und seiner Inbetriebnahme fehlt es nicht an Algorithmen, sondern an Engineering. Kelude vervollständigt die sechs Kernkomponenten – Datenversion, Modellversion, Pipeline, Deployment, Überwachung und Rollback – und macht Modelle damit so steuerbar und beherrschbar wie Software. Die Inbetriebnahme ist kein Glücksspiel mehr.
