1. Das Programm, seine Parameter und die kaufmännische Nachverfolgung trennen
Der Code beschreibt das Verhalten des Programms. Die Konfiguration legt die Last fest: Modell, Daten, Batch, Präzision und Ziel. Secrets gewähren Zugriff auf die erforderlichen Ressourcen. Halten Sie diese Elemente getrennt, um einen Versuch zu ändern, ohne den Code neu zu schreiben oder ein Token in eine gemeinsam genutzte Datei zu kopieren.
Die Kernodeck-Bestellreferenz ermöglicht es, den Mietkontext in Ihrem Konto wiederzufinden. Die Versuchskennung unterscheidet die Ausführungen Ihres Programms während dieses Zeitraums. Verknüpfen Sie beide in Ihren Notizen, wenn es Ihnen hilft, verlangen Sie aber nicht von Ihrem Skript, den Berechnungsstatus aus dem Zahlungsstatus abzuleiten.
Nehmen wir ein Projekt zur Dokumentenklassifizierung, das mehrmals auf derselben Stichprobe gestartet werden soll. Der Programmvertrag beschreibt die Eingabedatei, die zulässigen Parameter, den Ausgabeordner und die Art der Fehlerbehandlung. Der Guide zu den Daten erläutert die Validierung des Inhalts; hier organisieren wir die Schnittstelle, die diese Schritte verbindet.
2. Einen expliziten und versionierten Eingabevertrag schreiben
Dokumentieren Sie die Pflichtfelder und die akzeptierten Werte. Vermeiden Sie stille Standardwerte für eine Entscheidung, die das Ergebnis verändert, wie das Modell oder das Gerät. Eine Schema-Nummer unterscheidet die Form der Konfiguration von der Codeversion; sie ersetzt diese nicht.
In diesem Lehrbeispiel enthält die JSON-Datei ein Schema, einen Eingabepfad, eine Batch-Größe und das angeforderte Gerät. Relative Pfade werden ausgehend vom Konfigurationsordner gelesen. Diese für das Beispiel gewählte Regel vermeidet die Abhängigkeit vom Verzeichnis, aus dem ein Kollege den Befehl startet.
Das Lesen gültigen JSON prüft nur dessen Syntax. Ihr Programm muss anschließend Typen, Felder und Projektbeschränkungen überprüfen. Bei einem Fehler muss es vor dem Laden einer kostspieligen Ressource abbrechen, mit einer Meldung, die den zu korrigierenden Parameter benennt.
{
"schema_version": 1,
"input": "../data/pilote.jsonl",
"batch_size": 4,
"device": "cuda"
}3. Einen Einstiegspunkt vorbereiten, der einfache Fehler ablehnt
Mit argparse können Sie Optionen deklarieren und eine Hilfe für Ihren Befehl erzeugen. Das folgende Beispiel dient ausschließlich als Vorabprüfung: Es liest die Konfiguration, prüft ihre Felder und erkennt einen bereits verwendeten Ausgabeordner. Es lädt weder Modell noch Daten in den Speicher und testet nicht die Verfügbarkeit der GPU.
Speichern Sie diesen Lehrcode in prepare_run.py, wenn Sie ihn anpassen möchten. Er wird ohne bestätigte Ausführung bereitgestellt. Fügen Sie anschließend Ihre fachlichen Kontrollen in die Anwendung ein, statt die abschließende Meldung als Berechnungsergebnis zu betrachten. Das Gerät cuda bleibt eine Anforderung; PyTorch verwendet diesen Namen auch mit ROCm.
Die Ablehnung eines bereits vorhandenen Ausgabeordners ist hier eine Konvention zum Schutz vor der Vermischung von Versuchen. Ein echter Wiederaufnahmebefehl muss eine Option und separate Kontrollen erhalten. Verwandeln Sie einen neuen Start nicht in eine implizite Wiederaufnahme, nur weil Dateien vorhanden sind.
import argparse
import json
from pathlib import Path
parser = argparse.ArgumentParser(description="Validierung eines Projektstarts")
parser.add_argument("--config", type=Path, required=True)
parser.add_argument("--run-dir", type=Path, required=True)
args = parser.parse_args()
try:
config_path = args.config.resolve()
config = json.loads(config_path.read_text(encoding="utf-8"))
except (OSError, UnicodeError, json.JSONDecodeError) as exc:
parser.error(f"Konfiguration nicht lesbar: {exc}")
expected = {"schema_version", "input", "batch_size", "device"}
if not isinstance(config, dict) or set(config) != expected:
parser.error("Erwartete Felder: schema_version, input, batch_size, device")
if type(config["schema_version"]) is not int or config["schema_version"] != 1:
parser.error("schema_version muss 1 sein")
if type(config["batch_size"]) is not int or config["batch_size"] < 1:
parser.error("batch_size muss eine positive Ganzzahl sein")
if config["device"] not in ("cpu", "cuda"):
parser.error("device muss cpu oder cuda sein")
if not isinstance(config["input"], str) or not config["input"]:
parser.error("input muss ein nicht leerer Pfad sein")
input_path = (config_path.parent / config["input"]).resolve()
run_dir = args.run_dir.resolve()
if not input_path.is_file():
parser.error("Eingabedatei fehlt")
if run_dir.exists():
parser.error("Wählen Sie einen neuen Ausgabeordner")
print(json.dumps({
"status": "configuration_validated",
"input": str(input_path),
"run_dir": str(run_dir),
"device_requested": config["device"],
"batch_size": config["batch_size"]
}, ensure_ascii=False))python prepare_run.py --config config/pilote.json --run-dir runs/pilote-0014. Ausführungen und ihren Ergebnissen eine Identität geben
Verknüpfen Sie jeden Lauf mit einer kurzen Kennung, die innerhalb Ihrer Kampagne eindeutig ist. Notieren Sie die Coderevision, das Schema und die tatsächlich verwendeten Parameter sowie die Referenz der Daten und des Modells. Bewahren Sie diese Werte zusammen mit den Ausgaben auf, damit ein Ergebnis nicht von einer später geänderten Konfigurationsdatei abhängt.
Um zwei Batch-Größen zu vergleichen, legen Sie zwei Versuche und zwei Verzeichnisse an. Behalten Sie dieselbe Stichprobe bei und kennzeichnen Sie den beabsichtigten Unterschied. Die Namen pilote-001 und pilote-002 erklären für sich allein nicht, was sich geändert hat: Das Manifest verbindet den Namen mit den Parametern.
Reservieren Sie ein für Ihre Tools lesbares Bilanzformat. Es kann empfangene, erfolgreiche, abgelehnte und noch zu bearbeitende Elemente unterscheiden. Wählen Sie eine Regel für vollständigen Erfolg und markieren Sie einen Versuch nicht schon beim Schreiben des ersten Ergebnisses als abgeschlossen. Der Rückgabecode des Programms muss mit dieser Schlussfolgerung übereinstimmen.
Scrollen Sie durch die Tabelle, um alle Spalten zu lesen.| Datei oder Zustand | Rolle | Erwartete Prüfung |
|---|---|---|
| manifest.json | Identität von Code, Daten und Parametern | Tatsächlich verwendete Werte, ohne Geheimnisse. |
| results.jsonl | Eine Ausgabe pro akzeptiertem Element | Bekannte Kennungen und konformes Format. |
| errors.jsonl | Abgelehnte Elemente und aussagekräftiger Grund | Kein stilles Verschwinden und keine unnötigen sensiblen Inhalte. |
| summary.json | Schlussfolgerung des Versuchs und Zähler | Stimmige Summe, Dateien vor dem Endstatus erneut gelesen. |
5. Nützliche Ereignisse für Ihre Tools bereitstellen
Machen Sie einige Übergänge sichtbar: Konfiguration akzeptiert, Daten zugänglich, Modell geladen, erste Ausgabe geschrieben und Ende der Verarbeitung. Eine Spur muss die Frage „Wo steht dieser Lauf?“ beantworten können, ohne die Dokumente oder Prompts zu kopieren. Verknüpfen Sie die Stufe und die Versuchskennung mit der Meldung.
Das Modul logging von Python ermöglicht es, Meldungen nach Stufe und Ziel zu organisieren. Wählen Sie anschließend Ihre eigene Ereigniskonvention und dokumentieren Sie sie. Eine Anwendung, die einen Fehler schreibt und dann mit Erfolg endet, macht die Automatisierung irreführend; umgekehrt bedeutet nicht jede Warnung, dass das Ergebnis unbrauchbar ist.
Verwechseln Sie nicht ein ausgegebenes Ereignis mit einem dauerhaften Ergebnis: Eine Meldung „Sicherung gestartet“ beweist nicht, dass eine Datei erneut gelesen wurde. Für eine lange Ausführung erklärt der dedizierte Leitfaden den Zusammenhang zwischen Prozess und Sitzung. Ihre Schnittstelle muss vor allem eine Schlussfolgerung bewahren, die nach dem Ende der interaktiven Verbindung zugänglich bleibt.
6. Fehler, Wiederaufnahme und abschließende Prüfung definieren
Klassifizieren Sie nützliche Fehler: ungültige Konfiguration, fehlende Ressource, Rechenfehler und nicht konformes Ergebnis. Geben Sie für jeden eine nächste Aktion an. Installieren Sie keine automatische Wiederholung, ohne zu entscheiden, welche Effekte wiederholt werden dürfen: das erneute Schreiben einer bereits akzeptierten Ausgabe und das Wiederaufnehmen eines Checkpoints erfordern unterschiedliche Regeln.
Ihre abschließende Prozedur erklärt, wie Sie starten, beobachten, stoppen, fortsetzen und exportieren. Für die Dokumentenverarbeitung führen Sie die Liste der abgeschlossenen und der erneut zu verarbeitenden Identifikatoren. Für ein Training verwenden Sie ein Protokoll, das die gespeicherten Zustände in einem neuen Prozess überprüft. Ein nicht leerer Ordner ist kein Beweis für eine korrekte Wiederaufnahme.
Prüfen Sie das Projekt abschließend über einen neuen Aufruf, mit einer bekannten Konfiguration und einem anderen Ziel. Prüfen Sie die erwarteten Ablehnungen und dann einen kleinen vollständigen Durchlauf. Die Vorabprüfung dieser Seite deckt weder gleichzeitige Zugriffe noch die öffentliche Bereitstellung eines Dienstes noch Speicherberechtigungen ab: diese Themen erfordern eine eigene Konzeption.