Tokenwerk · Das LLM-Lehrbuch

Kapitel 21 · IV · Trainieren und prüfen · 5 Minuten

Daten sind ein Teil des Modells

Du entscheidest, was das Modell lernen kann. Dokumentgrenzen, Qualität, Lizenzen und getrennte Prüfungen gehören zum Bauplan.

Eine Architektur lernt die Verteilung deiner Beispiele

Ein kleines Modell, das ausschließlich kurze Kindergeschichten sieht, wird nicht automatisch technische Supportfragen beantworten. Ein Modell, das nur Tabellen mit Fragen und Antworten sieht, lernt möglicherweise das Format, aber wenig allgemeine Sprache. Deine Daten definieren zu einem wesentlichen Teil den Bereich, in dem Generalisierung überhaupt plausibel ist.

Für den ersten Lauf benutzen wir den beigefügten Demonstrationskorpus. Er enthält kurze selbst verfasste deutsche Beispiele. Er ist klein und wiederholt einfache Strukturen. Er dient der Funktionsprüfung und nicht einem Leistungsversprechen. Der Download enthält außerdem ein Script, um optional Texte aus TinyStories zu beziehen. TinyStories ist englisch und untersucht kleine Sprachmodelle auf vereinfachten Geschichten; das macht es für Sprachtraining interessant, aber nicht zu einem fertigen deutschen Dialogdatensatz.

Dokumente zuerst trennen

Stelle dir einen Roman vor, den du in überlappende Fenster zerlegst. Wenn du die Fenster zufällig zwischen Train und Validierung verteilst, enthalten beide Mengen fast identische Sätze. Der Validierungs-Loss wirkt dann besser, als eine Prüfung auf wirklich neuen Dokumenten ergeben würde.

Unsere Reihenfolge lautet: Rohdokumente lesen, exakte Duplikate entfernen, Dokumente mit festem Seed in Training und Validierung aufteilen, Tokenizer nur auf Training lernen, beide Mengen tokenisieren. Für eine echte Veröffentlichung brauchst du zusätzlich eine unabhängige Testmenge, die nicht bei der Auswahl von Hyperparametern benutzt wurde.

Ein einfaches Dateiformat

prepare.py erwartet JSONL: eine JSON-Zeile pro Dokument.

json
{"text":"Lina findet einen kleinen Schlüssel. Sie sucht die passende Tür."}
{"text":"Ein Gewitter entsteht, wenn feuchte Luft stark aufsteigt."}

Ein Feld pro Dokument macht die Grenzen explizit. Eine einzige gigantische Textdatei ohne Grenzen lässt sich schlechter sauber trennen. Du kannst eigene Quellen in dieses Format umwandeln, solltest aber Herkunft und Rechte separat dokumentieren.

bash
python prepare.py --input data/documents.jsonl --out runs/data --vocab-size 2048

Das naive Lehr-BPE-Training kann bei großen Korpora langsam werden. Unser Script begrenzt die Daten, auf denen die Merge-Zählung erfolgt. Das ist eine dokumentierte Stichprobe aus Training, kein Einsatz der Validierung. Für Millionen Dokumente ersetzt du diesen Teil später durch einen optimierten Tokenizertrainer, nachdem du die Lernlogik verstanden hast.

Was ein Korpusmanifest enthalten sollte

Für jede Quelle notierst du Herkunft, Sprache, Datum, Lizenz oder Nutzungsgrundlage, Anzahl Dokumente, ungefähre Tokenzahl, Filterregeln und bekannte Grenzen. Die genaue Zulässigkeit der Weiterverwendung hängt von der Quelle und deinem Einsatz ab; unser Kurs trifft keine pauschale Rechtsaussage über fremde Texte.

Achte auf personenbezogene Daten und Geheimnisse in eigenen Datensätzen. Besonders ein kleines Modell kann stark memorisieren. Trainiere nicht gedankenlos auf internen Zugangsdaten, Supporttickets oder privaten Nachrichten. Entferne solche Inhalte anhand klarer Regeln und prüfe Stichproben des gefilterten Ergebnisses.

Qualität ist nicht nur grammatisch sauberer Text

Ein Korpus kann fehlerfreie Grammatik und trotzdem falsche Fakten enthalten. Oder er enthält sehr viele nahezu identische SEO-Texte. Ein einfacher Qualitätscheck prüft Leertexte, ungewöhnliche Zeichenanteile, sehr lange Wiederholungen, identische Dokumente und grobe Sprachzuordnung. Exaktes Deduplizieren reicht nicht, um leicht veränderte Kopien zu erkennen.

Nähe-Deduplizierung und hochwertige Faktenprüfung sind umfangreiche eigene Themen. Für dein Lernprojekt dokumentierst du die Grenze, statt eine rudimentäre Textbereinigung „vollständige Qualitätskontrolle“ zu nennen.

EOS und Sequenzpacking

Unser Pretraining hängt nach jedem Dokument EOS an und legt die Tokens einer Menge in eine gemeinsame Folge. Zufällig gezogene Trainingsfenster können eine Dokumentgrenze überqueren. Die kausale Attention darf dann auch auf Text vor EOS schauen. EOS ist ein gelerntes Grenzsignal, kein technischer Reset aller Hidden States.

Das ist ein bewusst einfaches Packingverfahren. Wenn Dokumente vollkommen voneinander isoliert werden sollen, brauchst du dokumentabhängige Attentionmasken oder getrennte Sequenzen. Für das Lehrprojekt ist das gemeinsame Packing handhabbar, aber du solltest seine Semantik kennen.

Prüfe Stichproben vor dem Training

Dekodiere zwanzig zufällig ausgewählte Fenster. Sind Sonderzeichen intakt? Gibt es leere Dokumente oder versehentlich zusammengefügte JSON-Syntax? Sind EOS-Grenzen sichtbar? Dann zeige Input und Target desselben Fensters nebeneinander. Kontrolliere die Verschiebung tatsächlich, bevor du einen langen Lauf startest.

Tokenbudget statt „Epochengefühl“

Wenn du zufällige Fenster mit Zurücklegen ziehst, ist eine „Epoche“ nicht automatisch ein vollständiger Durchgang durch jedes Token. Unser Trainer dokumentiert deshalb Schritte und verarbeitete Trainingstokens. Ein kleines Korpus kann viele Male wiederverwendet werden. Neue Schritte erzeugen dann keine neuen Sprachbeispiele; sie optimieren dieselben Daten weiter.

Das Experiment

Die Aufteilungsansicht zeigt verschiedene Dokumente und die Zuordnung bei einem festen Seed. Eine zweite Ansicht zeigt, warum überlappende Fenster die Trennung verletzen können. Die Ansicht erzeugt keinen Qualitätswert für deinen echten Datensatz. Sie hilft, die Reihenfolge der Verarbeitung zu überprüfen.