Dataset für Fine-Tuning: Wie viele Beispiele und welche Qualität brauchen Sie wirklich

Wenn ein Unternehmen erstmals an das Fine-Tuning eines eigenen Sprachmodells herangeht, konzentriert es sich meist auf die technische Seite: Welches Modell, welches Framework, welche GPU. Das Dataset wird später behandelt — und genau dort entsteht das häufigste Problem. Wir haben Projekte erlebt, bei denen mehrere GPU-Tage in das Training investiert wurden, nur damit das fertige Modell in der Schublade verschwand. Nicht weil die Methode falsch war, sondern weil die Daten nicht mit der nötigen Sorgfalt vorbereitet wurden.

Dieser Artikel befasst sich konkret mit der Dataset-Vorbereitung: Wie viele Beispiele Sie realistisch benötigen, wie Sie Qualität messen, was mit Duplikaten zu tun ist, wie Sie Training- und Evaluierungs-Split festlegen und warum es so etwas wie ein Data-Sufficiency-Gate gibt — bevor Sie überhaupt mit dem Training beginnen.

Warum das Dataset wichtiger ist als die Methode

Fine-Tuning ist im Kern einfach: Zeigen Sie dem Modell, wie es in einem bestimmten Kontext antworten soll — oft genug, damit es sich das merkt. Das Problem entsteht, wenn das, was Sie ihm zeigen, nicht das ist, was Sie wirklich wollen — oder wenn Sie es zu selten zeigen, oder zu oft dasselbe.

Die Forschung zum Training von Sprachmodellen hat wiederholt gezeigt, dass Qualität mehr wiegt als Quantität. Ein Satz aus 1.000 sorgfältig aufbereiteten, vielfältigen und korrekten Beispielen kann ein besseres Modell erzeugen als 50.000 hastig zusammengestellte Beispiele mit systematischen Fehlern. Das ist nicht intuitiv — die meisten technischen Teams greifen instinktiv nach größerem Volumen.

Schlimmer als unzureichende Daten ist jedoch schlechte Qualität bei ausreichendem Volumen. Ein Modell, das auf fehlerhaften, verzerrten oder widersprüchlichen Beispielen trainiert wurde, fixiert diese als Wahrheit. Und da Fine-Tuning die Konfidenz des Modells in erlernte Muster erhöht, ist das Ergebnis ein Modell, das selbstsicher auf Fragen antwortet, bei denen es zögern oder „ich weiß es nicht" sagen sollte. In Bereichen wie Recht, Medizin oder Finanzberatung ist das ein ernstes Problem.

Größenordnungen: SFT, DPO und GRPO

Nicht jedes Fine-Tuning ist gleich. Die drei wichtigsten Ansätze haben unterschiedliche Datenanforderungen:

SFT (Supervised Fine-Tuning) ist die grundlegende Methode: Das Modell erhält Eingabe-Ausgabe-Paare und lernt, diese nachzuahmen. Funktionsfähige Ergebnisse sind ab etwa 1.000 hochwertigen Beispielen erreichbar, für Produktionssysteme arbeitet man typischerweise mit 10.000 bis 100.000 Paaren. Wichtig ist, dass diese die wesentlichen Szenarien der jeweiligen Domäne abdecken — nicht nur die häufigsten.

DPO (Direct Preference Optimization) erfordert Präferenzpaare: Für jede Eingabe haben Sie eine „bessere" und eine „schlechtere" Antwort. Das Modell lernt, was Sie bevorzugen. Das erfordert entweder echte menschliche Annotation oder eine zuverlässige automatische Bewertung. Das empfohlene Minimum liegt bei etwa 2.000 Präferenzpaaren mit menschlich verifizierten Ergebnissen. Unterhalb dieser Grenze besteht das Risiko, dass das Modell Artefakte des Annotationsprozesses lernt statt echter Präferenzen.

GRPO und verifizierbare Rewards eignen sich für Aufgaben mit überprüfbaren richtigen Antworten — Mathematik, Code, Logik, Formate mit definiertem Schema. Hier liegt das Minimum bei etwa 1.000 bewerteten Trajektorien, aber die zentrale Voraussetzung ist, dass der Reward tatsächlich objektiv und automatisch überprüfbar ist. Wenn Sie den Reward manuell und subjektiv definieren, bekommen Sie dieselben Probleme wie bei einem schlechten DPO-Dataset.

Diese Zahlen sind Mindestwerte für grundlegende Funktionsfähigkeit, keine Qualitätsgarantien. Für den Produktionseinsatz in regulierten Branchen (Recht, Medizin, Pharma) gilt ein strengerer Maßstab: vollständige Abdeckung aller Zielszenarien und Jurisdiktionen, nicht nur eine repräsentative Stichprobe.

Was ein qualitativ hochwertiges Beispiel ausmacht

Bevor wir über Volumen diskutieren, müssen wir definieren, was Sie von einem einzelnen Beispiel erwarten.

Ein gutes SFT-Beispiel hat folgende Eigenschaften:

• Korrektheit: Die Ausgabe ist sachlich richtig und entspricht dem Kontext der Eingabe
• Konsistenz: Dieselbe Eingabe (oder eine äquivalente Formulierung) erhält dieselbe Antwortkategorie
• Repräsentativität: Das Beispiel deckt ein reales Szenario ab, keinen rein künstlichen Testfall
• Klarheit: Das Modell versteht aus dem Beispiel eindeutig, was von ihm erwartet wird — keine Ambiguität
• Angemessene Länge: Nicht unnötig kurz (leere Muster) und nicht unnötig lang (das Modell verliert den Faden)

Typische Probleme, die wir in der Praxis sehen:

• Ausgaben, die aus vorhandenen Dokumenten kopiert wurden, ohne Bearbeitung — sie enthalten Fehler aus der Originalquelle
• Beispiele, die von einem LLM generiert wurden, ohne menschliche Kontrolle — das Modell lernt die Halluzinationen eines anderen Modells
• Inkonsistente Formatierung — mal JSON, mal Markdown, mal Freitext für denselben Aufgabentyp
• Sich überschneidende Eingaben mit unterschiedlichen Ausgaben — das Modell erhält widersprüchliche Signale

Dataset-Format und Dateistruktur

Die meisten modernen Frameworks (Unsloth, Axolotl, LLaMA-Factory, TRL) akzeptieren Standardformate. Die am häufigsten verwendeten sind:

Alpaca-Format für Instruktionsaufgaben: Jedes Beispiel hat die Felder instruction, input (optional) und output. Einfach und gut unterstützt.

ShareGPT / Konversationsformat für Chat-Modelle: Beispiele sind Konversationen mit einer Liste von Nachrichten, wobei jede eine Rolle hat (system, user, assistant). Besser geeignet für Multi-Turn-Szenarien.

JSONL (ein JSON-Objekt pro Zeile) ist das bevorzugte Dateiformat für die meisten Tools — es ermöglicht das Streaming großer Datasets ohne den gesamten Inhalt in den Speicher zu laden.

Bei der Vorbereitung eines DPO-Datasets kommt ein weiteres Feld hinzu: typischerweise chosen und rejected (oder äquivalente Bezeichnungen je nach Framework) für jeden Eingabe-Prompt.

Deduplizierung — der unterschätzte Schritt

Doppelte oder nahezu doppelte Beispiele sind eines der häufigsten Probleme in Datasets, die automatisch oder aus Unternehmensdokumentation zusammengestellt wurden. Der Effekt ist zweifach: Das Modell lernt unverhältnismäßig stark die Muster in Duplikaten (Overfitting auf einen Subset der Daten), und die Evaluierung verzerrt sich, wenn Duplikate sowohl in den Trainings- als auch in den Testdaten landen.

Grundlegende Deduplizierung arbeitet auf exakter Übereinstimmung (Hash des Eingabetexts). Fortgeschrittenere Ansätze verwenden MinHash oder Embedding-Ähnlichkeit zur Erkennung semantischer Duplikate — also Beispielen, die unterschiedlich formuliert, aber inhaltlich identisch sind.

Für domänenspezifische Datasets empfehlen wir mindestens diese Schritte:

1. 1.Exakte Deduplizierung auf Basis des Ausgabe-Hashes
2. 2.Prüfung, ob unterschiedliche Formulierungen derselben Eingabe zu konsistenten Ausgaben führen
3. 3.Entfernung von Beispielen, bei denen Eingabe und Ausgabe kürzer sind als eine sinnvolle Untergrenze (z. B. zu kurze Antworten)

Tools wie die datasets-Bibliothek von Hugging Face oder datasketch (MinHash-Implementierung) decken diese Schritte ab, ohne eigenen Code schreiben zu müssen.

Train/Eval-Split: Zahlen und Logik

Die Aufteilung des Datasets in Trainings- und Evaluierungssatz ist grundlegend, aber in der Praxis werden unnötige Fehler gemacht.

Die Standardaufteilung 80 % Training / 20 % Evaluierung funktioniert, aber für kleine Datasets (unter ~5.000 Beispielen) ist 90/10 besser geeignet — ergänzt durch mehrfache Kreuzvalidierung oder einen separaten Hold-out-Testsatz.

Die entscheidende Regel: Kein Beispiel aus dem Evaluierungssatz darf im Trainingsset vorkommen — auch kein semantisches Duplikat davon. Wenn Sie deduplizieren, tun Sie das vor dem Split, nicht danach.

Für domänenspezifische Fine-Tuning-Datasets empfehlen wir, den Evaluierungssatz so zusammenzustellen, dass er enthält: - Eine repräsentative Stichprobe der Hauptszenarien (gleiche Verteilung wie das Training) - Einige bewusst gewählte Edge Cases und Grenzfälle - Beispiele, bei denen die richtige Antwort „ich weiß es nicht" oder „unzureichende Informationen" lautet — wenn Sie das vom Modell erwarten

Der Evaluierungssatz dient zwei Zwecken: der Leistungsmessung während des Trainings (Validation Loss) und der unabhängigen Bewertung nach dem Training. Für Produktionsentscheidungen ist die zweite Funktion wertvoller — deshalb sollte der Evaluierungssatz menschlich verifiziert und nicht automatisch generiert sein.

Verwandter Artikel darüber, wie man Ergebnisse nach dem Training misst: Wie Sie messen, ob Fine-Tuning geholfen hat.

Synthetische Daten: Nutzen und Risiken

Für die meisten domänenspezifischen Projekte reicht das Volumen vorhandener menschlich erstellter Daten nicht aus. Die Lösung ist die Erweiterung des Datasets durch synthetische Daten — also Daten, die von einem stärkeren (Frontier-)Modell auf Basis menschlicher Seed-Beispiele generiert werden.

Typisches Rezept: 150–200 menschlich geschriebene, verifizierte Seed-Beispiele → Generierung des 10- bis 100-fachen über ein Teacher-Modell (Claude Opus, GPT-4o oder ein ähnliches Frontier-Modell) → menschliche Überprüfung einer Stichprobe (mindestens 10–20 %) → Filterung nach Qualität.

Risiken synthetischer Daten:

• Model Collapse: Wenn der Trainingsdatensatz ausschließlich aus synthetisch generierten Daten eines einzigen Teacher-Modells besteht, übernimmt das fine-getunte Modell dessen Schwächen und Eigenheiten. Der lange Schwanz realer Szenarien bleibt unabgedeckt.
• Halluzinationen des Teacher-Modells: Das Teacher-Modell ist nicht unfehlbar — es generiert sachliche Fehler, die ohne menschliche Kontrolle ins Training gelangen.
• Stilverzerrung: Ein starkes Teacher-Modell hat einen ausgeprägten Antwortstil. Wenn das nicht der gewünschte Stil für Ihren Use Case ist, müssen Sie das explizit im Prompt und bei der Qualitätskontrolle korrigieren.

Die Arbeit mit synthetischen Daten erfordert mehr Disziplin bei der Qualitätskontrolle, nicht weniger. Mehr zu diesem Thema: Synthetische Daten für Fine-Tuning.

Data-Sufficiency-Gate: Starten Sie kein Training, bevor die Daten bereit sind

Einer der Fehler, den wir immer wieder sehen, ist das Starten eines Trainings mit einem Dataset, von dem Sie bereits wissen, dass es unvollständig ist — mit dem Gedanken, „das ergänzen wir später". Das Problem: Unvollständiges Fine-Tuning kann aktiv schädlich sein.

Ein Modell, das auf einem Dataset trainiert wurde, das nur einen Teil der Domäne abdeckt, lernt, mit hoher Sicherheit auch auf Fragen aus dem nicht abgedeckten Teil zu antworten. Es hat keinen Mechanismus, um zu erkennen, dass es etwas „nicht weiß" — es kennt nur das, was es gelernt hat. Das Ergebnis ist schlechter als ein Base-Modell, das zumindest weiß, dass es nicht auf die Domäne spezialisiert ist.

Vor dem Start des Trainings empfehlen wir zu prüfen:

1. 1.Abdeckung der Hauptszenarien: Haben Sie Beispiele für jeden wesentlichen Aufgabentyp, den das Modell ausführen soll?
2. 2.Mindestvolumen: Erfüllen Sie die Größenordnungs-Minima für die gewählte Methode (SFT, DPO, GRPO)?
3. 3.Qualitativ hochwertiger Evaluierungssatz: Haben Sie einen menschlich verifizierten Evaluierungssatz, der von den Trainingsdaten getrennt ist?
4. 4.Für regulierte Branchen: Decken Sie alle Ziel-Jurisdiktionen und Szenarien ab — nicht nur eine repräsentative Stichprobe?

Diese Checkliste ist keine Bürokratie — sie ist eine Absicherung davor, dass eine Investition in das Training in einem problematischen Modell endet. Mehr zur Entscheidung zwischen den Methoden: SFT, DPO, GRPO — welche Methode wann.

Catastrophic Forgetting: Was Fine-Tuning beschädigen kann

Fine-Tuning auf einem engen Dataset hat einen Nebeneffekt: Das Modell kann Fähigkeiten teilweise vergessen, die es vor dem Training hatte. Dieses Phänomen — als Catastrophic Forgetting (katastrophales Vergessen) bezeichnet — ist durch die Forschung belegt und in der Praxis real.

LoRA und QLoRA mildern dieses Problem, weil die ursprünglichen Modellgewichte eingefroren bleiben und die Adapter relativ klein sind. Aber auch PEFT-Methoden beseitigen es nicht vollständig — bei zu aggressivem Training (hohe Learning Rate, großes Dataset mit enger Verteilung) zeigt sich eine Degradation der allgemeinen Fähigkeiten.

Praktische Konsequenzen:

• Testen Sie nicht nur mit dem domänenspezifischen Evaluierungssatz, sondern auch mit allgemeinen Benchmarks (zumindest informativ)
• Wenn das Modell nach dem Fine-Tuning bei Aufgaben versagt, bei denen es vorher funktioniert hat, ist das ein Signal zur Anpassung der Trainingsverteilung oder der Parameter
• Für den Produktionseinsatz vergleichen Sie das fine-getunte Modell immer mit dem Base-Modell auf demselben Aufgabensatz — nicht nur auf dem domänenspezifischen

Checkliste vor dem ersten Training

Bevor Sie das Training starten, gehen Sie diese Liste durch:

1. 1.Das Dataset liegt im Standardformat vor (Alpaca oder ShareGPT JSONL)
2. 2.Die exakte Deduplizierung wurde über das gesamte Dataset durchgeführt
3. 3.Der Train/Eval-Split wurde vor jeder weiteren Verarbeitung vorgenommen
4. 4.Der Evaluierungssatz enthält keine semantischen Duplikate aus dem Trainingsset
5. 5.Mindestens 10 % des Datasets wurde menschlich auf Qualität geprüft
6. 6.Die Szenarioabdeckung ist verifiziert — keine wesentlichen Kategorien sind leer
7. 7.Synthetisch generierte Daten sind gekennzeichnet, und ihr Anteil am Dataset ist bewusst gewählt
8. 8.Für DPO: Jedes Präferenzpaar hat einen definierten Grund, warum „chosen" besser ist als „rejected"

Diese Liste ist nicht erschöpfend, deckt aber die häufigsten Problemquellen ab, die wir bei Kunden sehen, die ihr erstes Fine-Tuning angehen.

Häufige Fragen

Wie viele Beispiele brauche ich mindestens für SFT?

Funktionsfähige Ergebnisse sind ab etwa 1.000 hochwertigen Beispielen erreichbar — diese Zahl basiert auf Forschungsergebnissen, die zeigen, dass sorgfältig ausgewählte Beispiele ein um Größenordnungen größeres, aber weniger qualitatives Dataset übertreffen können. Für Produktionssysteme empfehlen wir mindestens 10.000 Beispiele mit Verifikation der Abdeckung wesentlicher Szenarien. Für regulierte Branchen gelten strengere Kriterien.

Kann ich das gesamte Dataset mit einem LLM generieren?

Ein synthetisch generiertes Dataset kann den Großteil des Volumens ausmachen, aber nicht das gesamte Dataset. Sie benötigen menschlich geschriebene und verifizierte Seed-Beispiele (typischerweise 150–200 als Minimum) und eine menschliche Überprüfung einer Stichprobe synthetisch generierter Beispiele. Ein Modell, das ausschließlich auf der Ausgabe eines Teacher-LLM trainiert wurde, übernimmt dessen Fehler und Schwächen ohne Korrektur.

Wie teile ich das Dataset in Trainings- und Testdaten auf?

Die Standardaufteilung ist 80 % Training / 20 % Evaluierung, für kleine Datasets unter 5.000 Beispielen eher 90/10. Die entscheidende Regel: Führen Sie die Deduplizierung vor dem Split durch, nicht danach. Der Evaluierungssatz darf keine semantischen Duplikate aus dem Trainingsset enthalten — sonst messen Sie die „Fähigkeit, sich zu erinnern", nicht die „Fähigkeit zu generalisieren".

Was tue ich, wenn ich wenig Domaindaten habe und diese nicht synthetisch ergänzen kann?

Erwägen Sie in diesem Fall RAG statt Fine-Tuning — RAG (Retrieval-Augmented Generation) benötigt keine Trainingsdaten und funktioniert gut für Szenarien, in denen Sie Zugang zu Wissen brauchen, nicht eine Änderung des Antwortstils oder -formats. Fine-Tuning ist besser geeignet, wenn Sie das Verhalten des Modells ändern, nicht sein Wissen.

Warum antwortet das Modell nach dem Fine-Tuning schlechter als vorher?

Die häufigsten Ursachen: schlechte Dataset-Qualität (Fehler in Beispielen, inkonsistentes Format), unzureichende Szenarioabdeckung (das Modell hat nur einen Teil der Domäne „gelernt" und extrapoliert den Rest falsch), oder Catastrophic Forgetting bei zu aggressivem Training. Eine ausführlichere Analyse: 7 Gründe, warum Fine-Tuning scheitert.

*Die Dataset-Vorbereitung ist der Ort, an dem über den Erfolg des gesamten Fine-Tunings entschieden wird — nicht erst bei der Wahl der Methode oder der GPU. Wenn Sie Ihr erstes Fine-Tuning planen oder mit den Ergebnissen eines früheren Versuchs unzufrieden sind, helfen wir Ihnen bei MP Industrial Solutions gerne dabei, Qualität und Struktur der Daten zu beurteilen — bevor Sie das Training starten.*