Reproduzierbarkeit eines Machine-Learning-Experiments: Seeds, Umgebung, Daten und die Grenzen des Determinismus

Ziel

Einen Trainingslauf so gestalten, dass eine andere Person oder ein anderer Agent ihn an einem anderen Tag wiederholen kann, mit derselben Metrik, soweit die Plattform das zulässt, und jede verbleibende Quelle von Variation explizit machen.

Voraussetzungen

Ein committeter Codestand, ein Datensatz mit Prüfsumme oder Versionskennung sowie eine gepinnte Abhängigkeitsdatei für die Trainingsumgebung.

Schritte

1. Jeden impliziten Zufallszustand entfernen. Die Seite zu den Stolpersteinen von scikit-learn hält fest, dass über mehrere Ausführungen reproduzierbare Ergebnisse verlangen, jede Verwendung des Standardwerts random_state=None zu entfernen, und empfiehlt, einen Zufallszustand am Anfang des Programms zu deklarieren und ihn an jeden Estimator und Splitter zu übergeben; vom Setzen des globalen NumPy-Seeds wird abgeraten. Für NumPy-Code einen Generator mit default_rng(seed) erzeugen, den die NumPy-Referenz als empfohlenen Konstruktor bezeichnet, und ihn auf dieselbe Weise weiterreichen statt Zufallsfunktionen auf Modulebene aufzurufen.
2. Bei Deep-Learning-Frameworks den Generator des Frameworks seeden (torch.manual_seed) und deterministische Algorithmen aktivieren, wo angeboten. Der Hinweis zur Reproduzierbarkeit von PyTorch hält fest, dass vollständig reproduzierbare Ergebnisse über Releases, Commits oder Plattformen hinweg nicht garantiert sind, dass CPU- und GPU-Ergebnisse bei identischen Seeds abweichen können und dass deterministische Operationen oft langsamer sind; festhalten, welche dieser Einstellungen verwendet wurden.
3. Die Daten fixieren: Prüfsumme des Datensatzes und Kennung des Splits festhalten und Zeilen in definierter Reihenfolge laden (Sortierung nach einem stabilen Schlüssel vor dem Split).
4. Die Umgebung pinnen: Lock-Datei, Python-Version, Hardwareklasse und bei GPUs Treiber- und Bibliotheksversionen; ein Container-Image bauen, falls die Umgebung die Maschine überdauern muss.
5. Die Konfiguration (alle Hyperparameter, Seeds, Pfade, Versionen) in eine Datei schreiben, die der Lauf einliest und in sein Ausgabeverzeichnis kopiert.
6. Das Experiment zweimal aus einem sauberen Checkout auf derselben Maschine und einmal auf einer anderen erneut ausführen; festhalten, ob die Metrik exakt, innerhalb einer Toleranz oder gar nicht übereinstimmte, und welcher Schritt eine Abweichung erklärt.
7. Ergebnisse zusammen mit der Konfiguration und dem Code-Commit speichern; die Streuung über Seeds als Intervall angeben statt der Zahl eines einzelnen Seeds.

Erwartetes Ergebnis

Ein Laufverzeichnis, das alles enthält, was zur Wiederholung des Laufs nötig ist, eine Aussage darüber, wie genau er sich wiederholt, sowie Metriken, die zwischen Läufen vergleichbar sind, weil Seeds und Daten gleich sind.

Grenzen und Prüfbasis

Determinismus kann Geschwindigkeit kosten und ist nicht für jede Operation verfügbar. Bitgenaue Wiederholbarkeit über Hardware hinweg wird von der zitierten Dokumentation nicht versprochen. Das Protokoll ist ein Vorschlag; es wird keine Wiederholungsrate beansprucht.