Den Beleg hinter jedem Ergebnis wiederfinden.

Kampagne, Konfiguration und Ausführung unterscheiden

Eine Kampagne trägt eine Frage, zum Beispiel den Vergleich einer Referenz mit einer Anpassung. Eine Konfiguration beschreibt die technischen Entscheidungen. Ein Run ist ein Versuch, diese Konfiguration auszuführen, mit einem Seed, einem Anfang, einem Ende und einem Status. Zwei identische Versuche behalten daher zwei Kennungen, auch wenn der zweite einen abgebrochenen Durchlauf ersetzt.

Fügen Sie eine Bewertungskennung hinzu, wenn dasselbe Artefakt auf mehreren Datensätzen oder mit einer neuen Metrik bewertet wird. So verwechseln Sie kein neues Modell mit einer neuen Auswertung des bestehenden Modells. Verknüpfen Sie den Wiederaufnahmeversuch mit dem vorhergehenden und mit dem geladenen Checkpoint.

MLflow organisiert die Nachverfolgung ebenfalls rund um Runs, Parameter, Metriken und Artefakte. Diese Unterscheidung ist auch in einem einfachen Dateiordner nützlich. Sie können sie mit Ihrem gewohnten Tool anwenden; keine spezielle Tracking-Plattform ist nötig, um zu beginnen.

Technische Quellen: MLflow — Runs, Parameter, Metriken und Artefakte

Das tatsächlich ausgeführte Manifest schreiben

Behalten Sie die Parameter, die nach Anwendung der Standardwerte und der Startargumente aufgelöst wurden. Die ursprüngliche Konfigurationsdatei kann eine Standard-Batch-Größe oder eine zur Laufzeit geänderte Option auslassen. Halten Sie fest, was tatsächlich verwendet wurde, mit einer Kopie des Codes oder einer unveränderlichen Revision und dem Zustand der nicht gespeicherten Änderungen.

Das Manifest verknüpft außerdem Versionen des Modells und des Tokenizers, die Softwareumgebung, die tatsächlich genutzte GPU, die Präzision, die Daten, die Seeds und die Definition der Metriken. Es beschreibt den Versuch, ohne zu einer Installationsanleitung zu werden. Geben Sie die Einheiten an: Sekunden, Bytes, Tokens, Punkte oder Anteil zwischen 0 und 1 je nach Messgröße.

Beim Start lautet der Status „läuft“; am Ende wird er je nach Ihren Feststellungen „abgeschlossen“, „fehlgeschlagen“ oder „abgebrochen“. Ergänzen Sie nicht nachträglich eine vergessene Version durch die aktuell installierte. Kennzeichnen Sie unbekannte Informationen und schränken Sie die Schlussfolgerung ein, die davon abhängt.

Daten jenseits eines Ordnernamens identifizieren

Ein Pfad wie donnees/final bezeichnet keine stabile Version. Bewahren Sie das Inventar der Dateien oder Beispiele, die Splits und das Transformationsverfahren auf. Wenn Sie Labels korrigieren oder Zeilen filtern, erstellen Sie eine neue Version und behalten Sie die Beziehung zur vorherigen. Der alte Score muss weiterhin auf seine alten Daten verweisen.

Hugging Face Datasets ordnet Fingerprints dem Zustand eines Datensatzes und seinen Transformationen zu, um den Cache zu verwalten. Dieser Mechanismus ist nützlich, doch müssen Sie auch die Herkunft der Daten und die Vorverarbeitung aufbewahren. Eine nicht hashbare Transformation kann insbesondere zu einem zufälligen Fingerprint führen: Die Cache-Kennung ersetzt nicht allein Ihren Herkunftsordner.

Fügen Sie bei festgeschriebenen Artefakten Größe und Datei-Fingerprint hinzu. Ein SHA-256-Digest, der vor und nach einer Kopie berechnet wird, ermöglicht die Prüfung, ob die Bytes der aufbewahrten Referenz entsprechen. Er belegt weder die Qualität der Labels noch die Nutzungsrechte noch das Fehlen von Leckagen zwischen den Splits.

Technische Quellen: Hugging Face Datasets — Fingerprints und Transformationen · Python 3.14 — Datei-Fingerprints mit hashlib

Metriken, Vorhersagen und Artefakte verknüpfen

Eine Metrikzeile sollte den Run, das bewertete Artefakt, das Evaluierungsdatenset, die Version der Metrik und ihren Geltungsbereich kennzeichnen. Geben Sie an, ob sich der Wert auf einen Zwischen-Checkpoint, das finale Modell oder eine Untergruppe bezieht. Eine Kurve genügt nicht, wenn nicht mehr klar ist, welche Datei dem gewählten Punkt entspricht.

Bewahren Sie die Vorhersagen mit ihrer Eingabe-ID, ihrem Status und den für die Bewertung nötigen Informationen auf. Die erwarteten Referenzen können in einer separaten, versionierten Datei liegen. Unterscheiden Sie bei strukturierter Ausgabe zwischen Rohresultat, geparstem Resultat und Urteil: Das Korrigieren des Parsings darf die ursprüngliche Ausgabe nicht überschreiben.

MLflow erlaubt es, Metriken mit Modellen und Daten zu verknüpfen. Wenden Sie bei Dateien dasselbe Prinzip über explizite Identifikatoren an. Führen Sie ein lesbares Inventar der Artefakte: Gewichte oder Adapter, Generierungsparameter, Ausgaben, Evaluierungsbericht und Entscheidungsnotiz. Gehen Sie nicht davon aus, dass ein Screenshot diese Dateien ersetzt.

Technische Quellen: MLflow — Metriken, Modelle und Datensets verknüpfen

Beispiel: sechs Runs und ein Duplikat, das ein Fehlen verschleiert

Betrachten wir ein Beispiel für eine Klassifizierung mit zwei Konfigurationen und drei Seeds. Es ergibt sechs geplante Runs. Jeder muss dieselben 300 Evaluierungs-IDs vorhersagen: Der vollständige Ordner erwartet also 6 × 300 = 1.800 eindeutige Paare (run_id, input_id). Diese Berechnung beschreibt ein erwartetes Inventar, kein tatsächlich durchgeführtes Experiment.

Nehmen wir an, eine Datei enthält 300 Zeilen, aber die ID doc-042 ist zweimal vorhanden und doc-117 fehlt. Die Gesamtzahl der Zeilen scheint korrekt; es gibt jedoch nur 299 eindeutige IDs. Dieser Run besteht die Abdeckungsprüfung nicht, bis die Anomalie erklärt und behoben ist.

Wird jeder Run anschließend auf dem vollständigen Korpus und auf seiner Untergruppe langer Texte bewertet, erhalten Sie zwölf Metrikzeilen für eine gegebene Metrik. Das bleiben sechs Runs, nicht zwölf unabhängige Trainings. Der Bewertungsschlüssel muss den Geltungsbereich enthalten, um diese Unterscheidung zu wahren.

Den Ordner mit einer lesbaren Entscheidung abschließen

Bevor Sie einen Run als abgeschlossen erklären, prüfen Sie Vorhandensein und Öffnung der Dateien, Übereinstimmung der Identifikatoren, Neuberechnenbarkeit der Metriken und den Status jedes Fehlers. Ein technisch abgeschlossener Versuch kann wegen unzureichender Qualität abgelehnt bleiben. Halten Sie diese beiden Zustände getrennt.

Die Entscheidungsnotiz fasst die Frage, die verglichenen Varianten, das angekündigte Kriterium, die herangezogenen Ergebnisse und die Ausschlussgründe zusammen. Nennen Sie die run_id und die Artefaktpfade statt „das letzte Modell“. Fügen Sie die Grenzen hinzu: wenige Wiederholungen, unzureichende Untergruppe, nicht wiedergefundene Version oder unmöglich gewordener Vergleich.

Eine spätere Korrektur muss eine Spur hinterlassen: neue Bewertung, neuer Bericht und Grund der Änderung. Bewahren Sie die frühere Schlussfolgerung als gekennzeichnete historische Version auf, ohne sie als aktuelle Entscheidung erscheinen zu lassen. Prüfen Sie abschließend, dass sich die exportierte Kopie aus ihrem Zielordner öffnen lässt.

Unnötige Erfassung und Reproduktionsversprechen vermeiden

Erfassen Sie die für den Nachweis nötigen Felder, nicht alle Umgebungsvariablen oder den Verlauf des Terminals. Eine Konfiguration oder eine URL kann ein Token enthalten; erstellen Sie eine teilbare Version ohne Geheimnisse und bewahren Sie Daten, die privat bleiben müssen, an ihrem zulässigen Ort auf. Technische Test-Identifikatoren müssen keinen Personennamen enthalten.

Ein vollständiger Ordner verbessert die Möglichkeit, ein Experiment zu wiederholen und zu verstehen. Er garantiert keine numerische Gleichheit zwischen Plattformen oder Versionen: PyTorch dokumentiert diese Grenzen der Reproduzierbarkeit. Unterscheiden Sie das Wiederfinden des Protokolls, das erneute Laden des Artefakts und das exakte Reproduzieren der Zahlen.

Das IteraGPU-Notizbuch kann Ihre Ziele, Parameter und Entscheidungen samt nützlicher Referenzen festhalten. Es startet keine Runs und sammelt weder Dateien noch Telemetrie automatisch. Nutzen Sie es als Index Ihres Vorgehens und bewahren Sie den Artefaktordner in Ihren eigenen Sicherungen auf.

Technische Quellen: PyTorch 2.14 — Grenzen der Reproduzierbarkeit zwischen Umgebungen

Praktische Fragen