Ein trainiertes Modell versionieren: das Artefakt zusammen mit Code, Daten, Parametern und der Umgebung, die es hervorgebracht haben

Ziel

Für jede in Produktion ausgelieferte Vorhersage beantworten können, welches Modell sie erzeugt hat, aus welchem Code, welchen Daten und welchen Einstellungen es gebaut wurde, wie es abgeschnitten hat, und wie sich zur vorherigen Version zurückkehren lässt. Die Versionierung des Datensatzes selbst wird im Artikel zur Provenienz kleiner Datensätze behandelt; dieses Vorgehen deckt die Modellseite und ihre Verknüpfungen ab.

Voraussetzungen

Code in einer Versionsverwaltung, ein Datensatz mit stabiler Kennung (Prüfsumme, DVC-Zeiger oder Snapshot-Name), ein fester Test-Split, sowie ein Ort, um Artefakte mit Metadaten zu speichern: eine Registry wie MLflows Model Registry, die ihre Dokumentation als zentralen Speicher mit Abstammungsbezug zum Lauf, der ein Modell erzeugt hat, sowie Versionierung und Aliasing beschreibt, oder ein diszipliniertes Objektspeicher-Layout mit einer Manifestdatei.

Schritte

1. Nur aus einem committeten Zustand trainieren; die Registrierung eines Modells ablehnen, das aus einem schmutzigen Arbeitsverzeichnis gebaut wurde. Den Commit-Hash festhalten.
2. Die Datensatzkennung, die Split-Kennung und den vollständigen Satz an Hyperparametern als Parameter des Laufs festhalten.
3. Die exakten Abhängigkeitsversionen der Trainingsumgebung festhalten. Der Persistenzleitfaden von scikit-learn weist darauf hin, dass das Laden eines Schätzers unter einer anderen scikit-learn-Version eine InconsistentVersionWarning auslöst und dass ein mit älteren Versionen der Bibliothek und ihrer Abhängigkeiten trainiertes Modell in einer aktualisierten Umgebung unter Umständen neu trainiert werden muss – die Umgebung ist deshalb Teil der Version.
4. Auf dem festen Test-Split auswerten und die Metriken zusammen mit dem Lauf speichern; das Eingabe- und Ausgabeschema (eine Signatur) speichern, damit der Serving-Code Anfragen validieren kann.
5. Das Modell in einem für den Serving-Kontext gewählten Format serialisieren; der Vergleich im Leitfaden führt pickle-basierte Formate als beim Laden beliebigen Code ausführend auf und ONNX oder skops als sicherere Alternativen. Das Artefakt unter einer unveränderlichen Versionsnummer speichern.
6. Über einen Alias befördern (champion, challenger), nie durch Überschreiben der Datei hinter einer bestehenden Version; das Serving liest den Alias, ein Rollback ist eine Alias-Änderung.
7. Die Modellversion bei jeder Vorhersage protokollieren, damit sich das Produktivverhalten mit der Registry verknüpfen lässt.

Erwartetes Ergebnis

Jede ausgelieferte Vorhersage lässt sich auf eine Version zurückführen, jede Version auf einen Commit, einen Datensatz, Parameter, Metriken und eine Umgebung; ein Rollback erfordert nur eine Alias-Änderung.

Grenzen und Prüfbasis

Das Vorgehen fügt jedem Trainingslauf Buchführung hinzu und braucht Speicherplatz für Artefakte. Es macht das Training nicht deterministisch (siehe Reproduzierbarkeit eines ML-Experiments). Es wird weder ein Zeitaufwand noch ein Ergebnis seiner Anwendung behauptet.