Loss lesen und Fehler finden

Vier typische Muster

Wenn Trainings- und Validierungs-Loss beide hoch bleiben, hat das Modell die Aufgabe noch nicht gut gelernt. Gründe können zu wenig Training, ungeeignete Lernrate, zu kleine Kapazität oder ein Implementierungsfehler sein. Wenn nur Training sinkt und Validierung steigt, ist Überanpassung plausibel. Wenn beide schon ohne Training extrem gut sind, suche nach einem zu einfachen Prüfziel oder Leckage.

Wenn beide sinken, ist das ein ermutigendes Signal, aber kein abschließender Beweis für Antwortqualität. Der Token-Loss misst einen Durchschnitt. Eine seltene, wichtige Faktenfrage kann falsch beantwortet werden, obwohl viele häufige Funktionswörter korrekt vorhergesagt werden.

Die Diagnoseansicht im Browser zeigt schematische Beispielkurven, keine Ergebnisse eines realen Trainingslaufs. Sie soll dir helfen, passende nächste Prüfungen zu wählen. Deine echten Messwerte stehen später in metrics.jsonl.

Ein Batch überanpassen

Nimm einen festen kleinen Batch und trainiere wiederholt nur auf ihm. Ein ausreichend flexibles Modell sollte seinen Loss deutlich senken können. Schafft es das nicht, prüfe zuerst den Datenweg und die Optimierung. Für diesen Test darf es überanpassen; genau das ist das Ziel.

Ein gelungener Überanpassungstest zeigt, dass das System diese Beispiele darstellen und optimieren kann. Er zeigt nicht, dass es auf neue Dokumente generalisiert. Du solltest diesen Schritt daher nicht als fertiges Modell feiern und dann denselben Batch „Validierung“ nennen.

Die Fehlersuche in sinnvoller Reihenfolge

Prüfe erst Rohtext und Tokenizer-Roundtrip. Kontrolliere danach Input und um eins verschobenes Target. Prüfe dann Tensorformen, aktive Targetanzahl und den kausalen Präfixtest. Erst wenn diese Verträge stimmen, untersuche Optimizer, Lernrate und Kapazität.

Diese Reihenfolge verhindert, dass du einen Datenfehler durch immer größere Netze zu kompensieren versuchst. Ein um zwei Positionen verschobenes Target kann das Training erschweren, ein unverschobenes Target scheinbar erleichtern. Beide Fälle brauchen dieselbe frühe Kontrolle.

Nichtendliche Werte

Ein NaN-Loss ist kein normaler Lernzustand. Suche nach dem ersten nichtendlichen Tensor. Sind die Inputs gültige IDs? Haben manche Attention-Zeilen ausschließlich verbotene Einträge? Erzeugt eine Division durch null oder eine instabile Exponentialrechnung Probleme? Ist die Lernrate so groß, dass Gewichte explodieren?

if not torch.isfinite(loss):
    raise RuntimeError('Loss ist nicht endlich; Lauf gestoppt.')
for name, p in model.named_parameters():
    if p.grad is not None and not torch.isfinite(p.grad).all():
        print('Nichtendlicher Gradient:', name)

Das ungeprüfte Weitertrainieren kann den letzten brauchbaren Checkpoint zerstören. Stoppe mit einer eindeutigen Meldung und behalte den vorherigen Zwischenstand.

Training verbessert sich, Sampling bleibt schlecht

Prüfe zunächst den Prompt im tatsächlichen Tokenizer und das Ausgabeformat. Ein Base-Modell erwartet eine Textfortsetzung, keine automatisch erkannte Chatrolle. Prüfe außerdem Temperatur und Tokenbudget. Eine zu hohe Temperatur kann unplausible Tokens häufiger ziehen.

Vergleiche Generierung mit einem festen Seed und mehreren festen Prompts. Ein besonders schönes Beispiel aus hundert Versuchen ist keine belastbare Qualitätsmessung. Wenn du den schlechtesten Prompt nach jeder Modelländerung austauschst, verschiebst du die Prüfung.

Train/Validierungs-Abstand

Ein Abstand ist normal: Trainingsbeispiele wurden optimiert, Validierung nicht. Die Größe und Entwicklung des Abstands sind informativer als das Vorhandensein allein. Ein größerer Abstand kann durch wiederholte Daten, Verteilungsunterschiede oder andere Kontextbehandlung entstehen. „Das ist Overfitting“ ist deshalb eine Hypothese, die du mit Datenprüfung und kontrollierten Experimenten erhärtest.

Seeds und Wiederholungen

Ein fester Seed hilft, Änderungen vergleichbarer zu machen. Er garantiert keine identischen Ergebnisse auf allen Geräten. GPU-Kernels, parallele Reduktionen und verschiedene Bibliotheksversionen können Unterschiede erzeugen. Bei knappen Ergebnissen zwischen zwei Architekturen solltest du mehrere Seeds betrachten, statt eine zufällige Reihenfolge als Naturgesetz zu interpretieren.

Dein Messblatt

Notiere Checkpoint, Tokenizer-ID oder Hash, Datenmanifest, Konfiguration, Zahl verarbeiteter Tokens, Train-Loss, Validierungsverfahren, Validierungs-Loss, Laufzeit und feste Generierungsproben. Für Antwortmodelle kommen Kriterien für sachliche Qualität hinzu.

Ein simples JSONL-Log ist für den Einstieg ausreichend. Du musst keinen großen Trackingdienst integrieren, bevor dein erstes Modell eine gültige Sequenz vorhersagt. Das Projekt schreibt seine Messwerte deshalb lokal in eine einfache Datei.

Nächste Schritte je Befund

Verändere möglichst nur eine Ursache pro Versuch. Mehrere gleichzeitige Eingriffe können einen Lauf verbessern, aber du weißt danach nicht, welcher Eingriff geholfen hat.