Jedes Team, das mit Fine-tuning beginnt, stößt früher oder später auf dieselbe Wand: Reale, gut annotierte Beispiele sind rar. Neue Beispiele manuell zu erstellen ist teuer und zeitaufwendig. Fast zwangsläufig kommt die Frage auf – was wäre, wenn wir die Daten einfach mit einem Modell generieren würden?
Das ist eine legitime Technik. Forschungsteams und Produktivsysteme setzen sie ein. Aber sie hat genaue Bedingungen, unter denen sie funktioniert – und genaue Bedingungen, unter denen sie das Modell, das Sie gerade fine-tunen, auf stille Weise beschädigt. Dieser Artikel legt beides offen – ohne unnötigen Optimismus.
Was synthetische Daten sind (und was nicht)
Synthetische Trainingsdaten für Fine-tuning sind Eingabe-Ausgabe-Beispiele, die automatisch generiert werden – nicht aus realem menschlichem Verhalten erfasst. In der Praxis bedeutet das eines von drei Dingen:
- Generierung über ein Teacher-Modell – ein stärkeres Modell (z. B. ein Frontier-API) erhält eine Instruktion und generiert Beispiele für ein schwächeres Zielmodell. Dies wird manchmal ungenau als Destillation bezeichnet, obwohl es sich nicht um Destillation im ursprünglichen Sinne handelt.
- Augmentierung bestehender Daten – vorhandene Beispiele werden paraphrasiert, umformatiert oder erweitert; der semantische Inhalt bleibt erhalten, die Form ändert sich.
- Self-play und synthetische Szenarien – das Modell generiert Daten für sich selbst (oder übernimmt abwechselnd die Rolle von Lehrer und Schüler), typischerweise für Reasoning- oder konversationelles Fine-tuning.
Wichtig: Synthetische Daten sind kein Ersatz für Continued Pretraining auf rohen Domänentexten. Continued Pretraining baut eine Wissensbasis über nicht annotierte Texte auf. Synthetische Daten für SFT (Supervised Fine-tuning) lehren das Modell Format und Verhalten – nicht Wissen. Diese zwei Schichten ergänzen sich, ersetzen sich aber nicht gegenseitig.
Wann synthetische Daten wirklich helfen
Nicht jeder Use-Case verfügt über ausreichend reale Daten. Das sind die Situationen, in denen synthetische Daten echten Mehrwert bringen:
1. Sie haben ein starkes Seed-Set, das aber klein ist. Forschungsergebnisse zeigen, dass ein Modell, das auf tausend hochwertigen Beispielen trainiert wurde, ein Modell auf hunderttausend durchschnittlichen Beispielen übertrifft. Wenn Sie 150–200 reale, sorgfältig aufbereitete Beispiele haben, können Sie diese über ein Teacher-Modell 10- bis 50-fach erweitern – und dabei die gewünschte Verteilung erhalten. Das funktioniert gut bei strukturierten Aufgaben mit verifizierbaren Ausgaben: Entity-Extraktion, Klassifikation, Formattransformation.
2. Sie decken den Long Tail ab. Reale Daten haben eine Verteilung – manche Fälle sind häufig, manche selten. Ein Modell, das nur auf realen Daten trainiert wurde, kann Randfälle, die in der Historie kaum vorkamen, möglicherweise schlecht verarbeiten. Ein Teacher-Modell kann diese Randfälle gezielt abdecken.
3. Sie wollen Reasoning aus einem größeren Modell übertragen. Das ist das Kernprinzip des Destillationsansatzes, den DeepSeek popularisiert hat – eine Gedankenkette (Chain-of-Thought) aus einem Frontier-Modell wird als Trainingssignal für ein kleineres Modell verwendet. Das kleinere Modell lernt nicht, dasselbe zu „wissen", aber es lernt, *ähnlich zu denken*. Die Ergebnisse sind belegt: Modelle der Größe 7B–8B, die auf synthetischen Chain-of-Thought-Datensätzen trainiert wurden, können bei engen Reasoning-Aufgaben vielfach größere Generalistenmodelle übertreffen.
4. Sie benötigen Datenaugmentierung für sicherheitskritische Edge Cases. Red-Teaming und die Generierung adversarialer Beispiele – bei denen Sie dem Modell zeigen möchten, was es *nicht* tun soll – ist ein weiterer legitimer Anwendungsfall für Synthetik. Reale Fehlerbeispiele sind selten; ein synthetischer Teacher kann sie systematisch generieren.
Siehe auch: Fine-tuning-Dataset – Menge und Qualität für quantitative Empfehlungen zur Datasetgröße.
Die Hauptrisiken: Wann sie das Modell vergiften
Synthetische Daten bergen drei Risikokategorien, von denen jede ein Modell auf stille Weise degradieren kann.
Risiko 1: Fehlerfortpflanzung des Teachers
Das Teacher-Modell ist nicht unfehlbar. Es hat eigene Halluzinationsmuster, blinde Flecken, Formulierungspräferenzen. Wenn es tausend Beispiele generiert und Sie diese auf das Zielmodell trainieren, lernt das Zielmodell nicht nur die gewünschte Verteilung – es lernt auch die Eigenheiten des Teachers. In kleinen Dosen ist das tolerierbar. Bei großen synthetischen Datensätzen ohne Filterung produziert das ein Modell, das Fehler vertrauenswürdig wiederholt, die Sie selbst nicht einmal identifizieren können (weil es Fehler des Modells sind, nicht von Menschen).
Praxisbeispiel: Ein Kunde aus dem Bereich technische Dokumentation hatte ein Teacher-Modell, das konsistent einen Typ von Elektrokomponenten unter einem veralteten Markennamen bezeichnete. Nach tausend generierten Beispielen war das Zielmodell subtil, aber konsistent in Richtung dieser alten Nomenklatur biased – obwohl im Seed-Set kein solches Muster vorhanden war.
Risiko 2: Model Collapse
Das ist das technisch schwerwiegendste Risiko und ein aktives Forschungsfeld. Model Collapse tritt auf, wenn ein Modell, das auf synthetischen Daten desselben Modells (oder ähnlicher Modelle) trainiert wird, schrittweise an Variabilität verliert und auf eine enge Ausgabeverteilung konvergiert. Die Ausgaben sind flüssig, formal korrekt – aber das Modell deckt nicht mehr die Bandbreite realer Eingaben ab.
Die Intuition dahinter: Wenn der Teacher Daten generiert, die eine verteilte Antwort desselben Modells (oder seines Vorgängers) darstellen, verstärkt jede Trainingsiteration die zentralen Muster und schwächt die Ränder. Nach einigen Zyklen kann das Modell durchschnittliche Eingaben gut beantworten, aber ungewöhnliche Formulierungen, Edge Cases oder Daten außerhalb der Trainingsverteilung nicht mehr verarbeiten.
In Produktivsystemen äußert sich das so: Das Modell „funktioniert" in Tests (die Tests decken gängige Fälle ab), aber in der Produktion beschweren sich Kunden, dass sie manchmal generische oder unsinnige Antworten erhalten – genau bei Randfragen.
Schutzmaßnahme: Trainieren Sie niemals ausschließlich auf Synthetik. Human-Seed-Daten müssen mindestens ~20–30 % des Datensatzes ausmachen und müssen die Eingabediversität abdecken – nicht nur Durchschnittsfälle. Eine systematische Evaluation auf Out-of-Distribution-Eingaben vor dem Deployment ist Pflicht.
Risiko 3: Lizenz- und ToS-Einschränkungen
Dieses Risiko ist weniger technischer Natur, aber für den B2B-Einsatz entscheidend. Die meisten Frontier-Modelle (Claude, GPT, Gemini) haben in ihren Nutzungsbedingungen explizite Einschränkungen bezüglich der Generierung von Trainingsdaten für konkurrierende Modelle. Die genauen Formulierungen variieren und ändern sich – lesen Sie stets die aktuellen ToS des jeweiligen Anbieters.
Praktisch gesprochen: Wenn Sie ein kommerzielles API als Teacher-Modell nutzen und das Zielmodell kommerziell verteilen oder für Kunden deployen möchten, müssen Sie eine geklärte Rechtsgrundlage haben. Für internes Deployment auf eigener Infrastruktur ist die Situation anders, aber nicht automatisch unbedenklich.
Der sichere Weg: Open-Weight-Modelle (Qwen, Mistral und andere mit Apache 2.0 oder MIT-Lizenz) erlauben die Generierung synthetischer Daten in der Regel – aber jedes Modell hat eigene Bedingungen, prüfen Sie diese stets vor dem Einsatz. Wenn Sie eine kommerziell saubere synthetische Pipeline ohne rechtliche Fragezeichen wollen, sollten sowohl Teacher- als auch Student-Modell aus Familien mit permissiven Lizenzen stammen.
Generierung über ein Teacher-Modell – praktisches Vorgehen
Vorausgesetzt, Sie haben 100–200 qualitativ hochwertige Seed-Beispiele und möchten diese erweitern.
1. Das Seed-Set ist die Grundlage – kürzen Sie es nicht. Diese 150 Beispiele müssen die gewünschte Verteilung abdecken. Wenn das Seed-Set nur ein Drittel des Use-Case-Raums abdeckt, wird der synthetisch erweiterte Datensatz dasselbe Drittel abdecken – nur größer.
2. Prompt-Engineering für den Teacher. Der Teacher muss explizite Anweisungen zu Format, Stil, Domäne und dem erhalten, was Sie *verhindern* möchten. Vage Prompts = vage Daten. Ein guter Teacher-Prompt enthält: Beispiel-Eingabe-Ausgabe-Paare aus dem Seed-Set, das gewünschte Antwortformat, die bevorzugte Domänenterminologie und negative Beispiele (was vermieden werden soll).
3. Mehr generieren, als Sie brauchen – und filtern. Generieren Sie 3- bis 5-mal mehr Beispiele, als Sie verwenden möchten. Filtern Sie anschließend: - Automatische Formatprüfung (korrektes JSON, korrekte Struktur) - Embedding-basierte Deduplizierung (zu ähnliche Beispiele bringen keinen Mehrwert) - Relevanzbewertung – entweder über ein anderes Modell als Judge oder über regelbasierte Checker, wenn Sie verifizierbare Ausgaben haben - Stichprobenartige manuelle Kontrolle von mindestens 5–10 % der generierten Beispiele
4. Mit realen Daten mischen. Der finale Datensatz sollte Seed-Daten (100 %) + synthetische Daten (10- bis 50-fach, nach Filterung) enthalten. Bewahren Sie die Quellenkennung in den Metadaten des Datensatzes – beim Debugging werden Sie es schätzen.
5. Auf einem Holdout-Set aus realen Daten evaluieren. Das ist kritisch. Das Eval-Set darf keine synthetischen Beispiele enthalten. Wenn Sie das Modell nicht anhand echter menschlicher Bewertungen beurteilen, werden Sie nie feststellen, ob die Synthetik einen Drift eingeführt hat.
Mehr zur Evaluation: Fine-tuning messen – hat es geholfen?.
Synthetische Daten vs. Modelldestillation – ein wichtiger Unterschied
Diese Begriffe werden in der Praxis vermischt, sind aber nicht dasselbe.
Modelldestillation im ursprünglichen Sinne bedeutet, ein kleineres Modell so zu trainieren, dass es die Ausgabeverteilung eines größeren nachahmt. Das umfasst den Vergleich von Verteilungen über KL-Divergenz, Zugriff auf die Logits des Teachers und das gesamte Spektrum der Knowledge-Distillation-Techniken aus der akademischen Literatur.
Synthetische Datengenerierung über ein Teacher-Modell ist ein pragmatischerer Ansatz: Das Teacher-Modell generiert textuelle Eingabe-Ausgabe-Beispiele, die dann als normaler SFT-Datensatz verwendet werden. Sie nutzen keine Logits des Teachers, berechnen keine Verteilungsähnlichkeiten – Sie generieren nur Beispiele. Das Ergebnis ist schlechter als vollständige Destillation, aber ohne Zugriff auf das Modellinnere und ohne spezielle Frameworks umsetzbar.
In der Praxis läuft die meiste „Destillation" in kommerziellen Projekten über den zweiten Ansatz – weil der Zugriff auf Logits von Frontier-Modellen über Standard-APIs nicht verfügbar ist. Die Ergebnisse sind dennoch nachweisbar: Siehe die destillierten DeepSeek-R1-Modelle, die Reasoning-Fähigkeiten über synthetische Chain-of-Thought-Daten in 1,5B–8B-Modelle übertragen haben.
Für einen tieferen Einblick in Destillation als Technik: Modelldestillation.
Augmentierung vs. Generierung – wann was einsetzen
Die Augmentierung bestehender Beispiele (Umformatierung, Paraphrase, Stiländerung) ist ein sichererer Ansatz als reine Generierung – sie bewahrt die Fakten aus dem Seed-Set und verändert nur die Form. Sie ist geeignet, wenn:
- Ihre Seed-Daten faktisch zuverlässig sind (z. B. technische Dokumentation, Ihre internen Prozesse)
- Sie das Modell lehren möchten, auf unterschiedliche Formulierungen derselben Frage zu reagieren
- Es keinen Grund gibt, neue Fakten außerhalb des Seed-Sets einzuführen
Reine Generierung (das Teacher-Modell erstellt völlig neue Beispiele) ist mächtiger, aber riskanter – der Teacher kann Fakten einführen, die das Seed-Set nicht enthält, und ohne manuelle Kontrolle bemerken Sie das möglicherweise nicht.
Kombinierter Ansatz: Augmentierung für ~60 % des synthetischen Datensatzes, reine Generierung für ~40 % (zur Abdeckung von Long-Tail-Szenarien) – mit höherer manueller Kontrollquote bei generierten Beispielen.
Wann synthetische Daten nicht eingesetzt werden sollten
Es gibt Situationen, in denen synthetische Daten nicht nur nicht helfen, sondern aktiv schaden:
Fakten und präzise Zahlenwerte. Wenn Fine-tuning dem Modell konkrete Produktnummern, Preise oder technische Parameter beibringen soll – wird das Teacher-Modell diese erfinden. Das ist ein klassisches Halluzinations-Umfeld. Für faktisches Wissen ist die richtige Technik RAG oder Continued Pretraining auf verifizierten Texten – nicht SFT auf Synthetik.
Regulierte Domänen ohne Expertenvalidierung. In rechtlichen, medizinischen oder finanziellen Kontexten können synthetisch generierte Beispiele faktische Fehler enthalten, die ein echter Experte sofort erkennen würde – die das trainierte Modell aber mit voller Überzeugung replizieren wird. Wenn Sie keine Expertenprüfung jedes generierten Beispiels haben, setzen Sie Synthetik hier nicht ein.
Wenn Sie keinerlei Seed-Daten haben. Synthetik ohne Seed-Datensatz ist Generierung aus dem Nichts – Sie erhalten eine Verteilung, die den Teacher widerspiegelt, nicht Ihre Domäne. Vor der Generierung müssen Sie zumindest eine kleine, reale, gut annotierte Grundlage haben.
Zeitkritische Informationen. Das Teacher-Modell hat einen Knowledge-Cutoff. Synthetische Beispiele über aktuelle Ereignisse, neueste Gesetzgebung oder aktuelle Marktlage werden veraltet sein – und Sie werden es nicht bemerken, sofern Sie keine systematische Fact-Check-Pipeline einführen.
Filterung und Quality Gates – konkrete Schritte
Die Filterung ist der Punkt, an dem entschieden wird, ob der synthetische Datensatz hilft oder schadet. Minimales Quality Gate:
- 1.Formatvalidierung – automatisch, 100 % der Beispiele. Schließen Sie Beispiele mit falschem Format, fehlenden Feldern oder ungültigen Werten aus.
- 2.Deduplizierung – Embedding-basierte Ähnlichkeitssuche; Beispiele mit Cosine-Similarity > 0,92 gegenüber bestehenden Beispielen verwerfen (oder einen Repräsentanten auswählen).
- 3.Relevanzbewertung – wenn Sie verifizierbare Ausgaben haben (Code, JSON, SQL), führen Sie einen Syntaxcheck durch. Wenn nicht, verwenden Sie ein Modell als Judge mit einer expliziten Rubrik; kein generisches „Ist das gut?"-Prompt.
- 4.Verteilungsanalyse – vergleichen Sie die Verteilung von Themen, Längen und Formaten des synthetischen Datensatzes mit dem Seed-Set. Deutliche Abweichungen signalisieren Drift.
- 5.Stichprobenartige manuelle Kontrolle – mindestens 5 % der Beispiele mit rotierendem Kriterium (beurteilen Sie nicht immer dieselben Typen). Fokus auf: Fakten, Tonalität, Edge Cases.
Mehr Kontext dazu, warum Datenqualität mehr entscheidet als Quantität: 7 Gründe, warum Fine-tuning scheitert.
Häufige Fragen
Wie viele synthetische Beispiele kann ich ohne Risiko zu realen Daten hinzufügen?
Es gibt kein festes Verhältnis, das für alle Fälle gilt. Praktische Orientierung: Synthetische Beispiele sollten nicht mehr als 70–80 % des Gesamtdatensatzes ausmachen, wenn Sie keine starke Filterung und manuelle Kontrolle haben. Bei einem höheren Anteil steigt das Risiko von Model Collapse. Seed-Daten müssen stets vorhanden sein und die gesamte Verteilung des Use-Case-Raums abdecken – nicht nur gängige Fälle.
Kann ich ChatGPT / Claude verwenden, um Trainingsdaten für mein Modell zu generieren?
Das hängt vom Einsatzzweck ab. Für internes Unternehmens-Deployment (das Modell läuft auf Ihrer Infrastruktur, wird nicht kommerziell vertrieben) ist die Situation anders als bei einem kommerziellen Produkt. Lesen Sie stets die aktuellen ToS des jeweiligen Anbieters – die Formulierungen ändern sich. Für eine kommerziell saubere Pipeline empfehlen wir Open-Weight-Teacher-Modelle (Llama, Qwen, Mistral) mit permissiver Lizenz.
Ist die Generierung über ein Teacher-Modell dasselbe wie Modelldestillation?
Nein. Destillation im ursprünglichen Sinne arbeitet mit den Logits (der Wahrscheinlichkeitsverteilung) des Teachers. Die Generierung synthetischer Daten über ein Teacher-API ist eine pragmatischere Variante – Sie erhalten Textbeispiele, kein Verteilungssignal. Die Ergebnisse sind schwächer als bei vollständiger Destillation, aber ohne Zugriff auf das Modellinnere realisierbar. In kommerziellen Projekten ist diese Variante gerade wegen der Verfügbarkeit die gängigere.
Was tun, wenn das Teacher-Modell faktisch fehlerhafte Beispiele generiert?
Das ist ein Standardproblem und das Hauptargument für manuelle Stichprobenkontrolle. Teacher-Modelle halluzinieren – seltener als kleine Modelle, aber nicht null. Lösung: Verifizierbare Aufgaben (Code, JSON, SQL) automatisch prüfen; Fakten in unstrukturiertem Text erfordern manuellen Review. Wenn Sie keine Kapazität für manuellen Review haben, beschränken Sie Synthetik auf die Augmentierung bestehender verifizierter Beispiele – nicht auf die Generierung neuer Fakten.
Helfen synthetische Daten, wenn das Modell keinerlei Domänenwissen hat?
Selten. Synthetik kann ein bestehendes Seed-Set erweitern und diversifizieren – sie kann keine Domänenwissensbasis ersetzen. Wenn das Modell keine Domänengrundlage hat, ist der richtige Weg Continued Pretraining auf Domänentexten (Handbücher, Normen, interne Dokumente) – und erst danach SFT, synthetisch oder real.
*MP Industrial Solutions trifft diese Entscheidungen täglich für Kunden aus Fertigung, Energiewirtschaft und Logistik. Wenn Sie die Frage beschäftigt, welche Kombination aus realen und synthetischen Daten für Ihr konkretes Modell und Ihren Use-Case sinnvoll ist, besprechen wir das gerne gemeinsam.*