Experiment Tracking

Beim Experiment-Tracking werden sämtliche Informationen zu jedem Trainingslauf für maschinelles Lernen in einem durchsuchbaren Speicher festgehalten: Codeversion, Datenversion, Einstellungen, Umgebung, Metriken im Zeitverlauf und Ausgabedateien wie Gewichte und Diagramme. Ein Projekt, in dem Dutzende Lernraten, Augmentierungseinstellungen und Modellgrößen ausprobiert werden, erzeugt auf der Festplatte ähnlich aussehende Läufe. Das Tracking hält die Konfiguration jedes Ergebnisses fest, damit sich der beste Lauf Monate später vergleichen, reproduzieren und zurückverfolgen lässt. TensorBoard, 2015 zusammen mit TensorFlow veröffentlicht, machte Live-Trainingskurven zum Standard. Databricks veröffentlichte 2018 MLflow als Open Source, mit Tracking als einer der drei ursprünglichen Komponenten. Weights & Biases, Comet, ClearML und DVC sind weitere weit verbreitete Tracking-Werkzeuge.

Was ein Tracker erfasst#

Jeder Lauf erhält eine eindeutige ID und gehört zu einem Experiment, einer benannten Gruppe zusammengehöriger Läufe. Ein typischer Datensatz zu einem Lauf enthält:

• Hyperparameter: Lernrate, Batchgröße, Optimierer, Modellarchitektur, Zufallsstartwert und alle weiteren Einstellungen, die das Training beeinflussen.
• Metriken: Trainings- und Validierungsverluste sowie Bewertungen, die pro Schritt oder Epoche protokolliert werden, außerdem Systemmetriken wie GPU-Speicher und -Auslastung.
• Artefakte: Checkpoints, Konfusionsmatrizen, Beispielvorhersagen und Konfigurationsdateien.
• Herkunft: Der Git-Commit, die Datensatzversion, Paketversionen, Hardware und der Autor, die den Lauf hervorgebracht haben.

Die Protokollierung erfolgt über einen Clientaufruf pro Wert oder automatisch durch Autologging-Integrationen, die Parameter und Metriken eines Frameworks ohne zusätzlichen Code erfassen. Ein gemeinsamer Tracking-Server sammelt die Läufe aller Laptops, Cloud-Rechner und CI-Jobs eines Teams. Sein Dashboard legt die Verlust-kurven ausgewählter Läufe übereinander und filtert sie nach beliebigen Parametern oder Metriken. So werden Probleme wie Overfitting auf einen Blick sichtbar.

Das Ultralytics-YOLO-Training schreibt die Argumente jedes Laufs in args.yaml und Verluste sowie Metriken pro Epoche in results.csv. Integrierte Integrationen senden dieselben Werte an MLflow, Comet, ClearML oder DVC, sobald das jeweilige Paket installiert ist. TensorBoard und Weights & Biases werden über yolo settings aktiviert. Die Trainingsargumente project und name werden in MLflow zu den Experiment- und Laufnamen. Ein YOLO26-Sweep wird so bereits strukturiert im Tracker erfasst.

Läufe vergleichen und reproduzieren#

Dashboards stellen eine Kennzahl für verschiedene Parameter über mehrere Läufe hinweg dar oder zeigen Parallelkoordinatendiagramme, die die Einstellungen jedes Laufs mit seinem Ergebnis verbinden. So wird sichtbar, welche Einstellungen bei einer Parameterdurchsuchung relevant sind. In Ultralytics Platform vergleicht ein Projekt seine Modelle anhand überlagerter Kennzahl- und Verlustkurven sowie einer nebeneinander angeordneten Tabelle. Die Lektion Läufe vergleichen und einen Gewinner auswählen macht aus diesem Vergleich ein automatisiertes Freigabekriterium. Um einen Lauf zu reproduzieren, reichen seine Hyperparameter nicht aus: Der Datensatz muss auch den Code-Commit, den genauen Datenstand, die Paketversionen und den Zufallsstartwert enthalten, denn GPU-Kernel und Reihenfolge beim Laden der Daten können selbst bei ansonsten identischen Läufen zu leicht unterschiedlichen Ergebnissen führen.

Dieses MLflow-Skript trainiert einen Entscheidungsbaum mit vier Tiefen auf handgeschriebenen Ziffern von scikit-learn. Es erfasst jede Tiefe als Parameter und die Validierungs-Genauigkeit als Metrik und fragt das Experiment anschließend wie eine Tabelle ab:

import mlflow
from sklearn.datasets import load_digits
from sklearn.model_selection import train_test_split
from sklearn.tree import DecisionTreeClassifier

# Store runs in a local SQLite file and group them under one experiment
mlflow.set_tracking_uri("sqlite:///mlflow.db")
mlflow.set_experiment("digits-tree-depth")
X_train, X_val, y_train, y_val = train_test_split(*load_digits(return_X_y=True), random_state=0)

# One tracked run per setting: the parameter goes in, the metric comes out
for depth in [2, 4, 8, 16]:
    with mlflow.start_run(run_name=f"depth-{depth}"):
        model = DecisionTreeClassifier(max_depth=depth, random_state=0).fit(X_train, y_train)
        mlflow.log_param("max_depth", depth)
        mlflow.log_metric("val_accuracy", model.score(X_val, y_val))

# Query the experiment like a table, best run first
runs = mlflow.search_runs(order_by=["metrics.val_accuracy DESC"])
print(runs[["params.max_depth", "metrics.val_accuracy"]])

Bei einer neuen Datenbank führt die Tabelle zuerst Tiefe 16 mit einer Validierungsgenauigkeit von 0.838 auf, danach Tiefe 8 mit 0.818, Tiefe 4 mit 0.533 und Tiefe 2 mit 0.318. Wird mlflow ui im selben Ordner mit --backend-store-uri sqlite:///mlflow.db ausgeführt, werden dieselben Läufe im Browser geöffnet.

Experiment-Tracking im Vergleich zu verwandten Methoden#

Experiment-Tracking ist eine Phase von Machine-Learning-Operations (MLOps) und steht neben drei Methoden, mit denen es oft verwechselt wird:

• Modellregister: Bewahrt die wenigen trainierten Modelle auf, die sich für die Bereitstellung eignen. Jede Version ist mit dem getrackten Lauf verknüpft, aus dem sie hervorgegangen ist.
• Modellüberwachung: Überwacht Eingaben, Ausgaben und Genauigkeit eines bereitgestellten Modells im Produktivbetrieb, nachdem das Tracking während der Entwicklung seinen Zweck erfüllt hat.
• Hyperparameteroptimierung: Suchwerkzeuge wie Optuna und Ray Tune starten viele Läufe automatisch; der Tracker speichert und ordnet sie alle.