Synthetic Data: Wie künstliche Trainingsdaten KI-Modelle verbessern können

Trainingsdaten sind der Engpass moderner KI. Echte Daten sind teuer in Kuratierung, lizenzrechtlich oft problematisch und in spezialisierten Domänen schlicht knapp. Synthetic Data — von einem Modell generierte Trainingsdaten — füllt diese Lücke. Was 2022 noch experimentell war, ist 2026 produktiver Standard. Dieser Beitrag erklärt, wie man synthetische Daten sauber einsetzt und welche Fallen es zu vermeiden gilt.

1. Warum synthetische Daten

Drei Treiber:

• Datenmangel. Für viele spezialisierte Aufgaben (interne Codebasis, domänenspezifische Klassifikation, seltene Sprachen) gibt es schlicht zu wenig reale Beispiele.
• Datenkurierung-Kosten. Echte Daten zu labeln, zu validieren, zu balancieren kostet Personenmonate. Synthetic Data kann das beschleunigen.
• Lizenz- und Datenschutzfragen. Sensible Inhalte (Patientendaten, Kundenkommunikation) dürfen oft nicht für Training genutzt werden. Synthetische Stellvertreter können produzieren, was reale Daten nicht dürfen.

In Modell-Distillation (siehe Model Distillation) sind synthetische Daten ohnehin die Grundlage — sie sind dort kein Werkzeug, sondern das Verfahren.

2. Methoden der Datengenerierung

Drei Hauptansätze:

• Direkter Prompt. Ein starkes Modell wird mit strukturierten Prompts dazu gebracht, Beispiele in der gewünschten Form zu produzieren. Einfach, aber tendiert zu monotonen Outputs.
• Template-basierte Generierung. Templates mit Slots werden mit verschiedenen Werten gefüllt. Beispiel: „Beantworte folgende [Kategorie]-Frage über [Domäne].” Höhere Diversität.
• Iterative Generierung. Mehrstufige Pipelines: zuerst Themen, dann Fragen, dann Antworten, dann Validierung. Jeder Schritt nutzt LLMs. Aufwändig, aber qualitativ am besten.

Spezialfälle: Selbstkonsistenz-Datenerzeugung (mehrere Antworten generieren, nur konsistente behalten), Backtranslation (echten Output ins andere Format übersetzen und zurück), Multi-Agenten-Dialoge (mehrere LLMs simulieren Gespräche).

3. Filter, Qualitätskontrolle, Diversität

Rohe Generierung produziert immer minderwertige Beispiele. Eine produktive Pipeline filtert:

1. Schema-Validierung. Passt das Format (JSON-Schema, Pydantic)?
2. Regelbasierte Filter. Keine toxischen Inhalte, keine PII, keine Duplikate.
3. Modellbasiertes Re-Ranking. Ein zweites Modell bewertet die Qualität.
4. Diversitäts-Metriken. Inhaltliche Vielfalt sicherstellen (Embedding-Cluster, Topic-Verteilung).
5. Menschliche Stichproben. 1–5% manuell prüfen, Drift früh erkennen.

Ohne diese Filter wird die Pipeline zur Müllverstärker. Mit ihnen wird sie zur Qualitätsmaschine.

4. Wofür sich synthetische Daten eignen

Bewährte Einsatzgebiete:

• Instruction-Daten für SFT. Generierung breit gefächerter Aufgabentypen. Datensätze wie Alpaca, Dolly, UltraChat basieren wesentlich auf synthetischen Daten.
• Präferenzdaten für DPO. Multiple Antworten pro Prompt generieren, durch Ranking-Modell sortieren. Siehe Instruction Tuning, RLHF und DPO.
• Edge-Case-Abdeckung. Seltene Klassen oder Edge Cases gezielt generieren, um Datensätze auszubalancieren.
• Code- und Mathematik-Training. Hier ist synthetische Generierung mit automatischer Validierung (Tests laufen lassen, Gleichungen prüfen) besonders effektiv.
• Übersetzung in seltene Sprachen. Echte Daten knapp, synthetische Pivot-Übersetzungen helfen.
• Domain-Adaption. Fine-Tuning auf domänenspezifische Stile und Terminologie ohne reale sensible Daten.

5. Risiken: Mode Collapse, Bias, Halluzinationen

Synthetic Data hat Schattenseiten:

• Mode Collapse. Generative Modelle tendieren zu repetitiven Outputs. Wenn nicht diversifiziert, lernt das Student-Modell nur einen schmalen Stil.
• Bias-Vererbung. Biases im Teacher werden vom Student übernommen — und können durch Generierung sogar verstärkt werden.
• Halluzinationen. Faktisch falsche Inhalte vom Teacher werden vom Student als wahr gelernt.
• Distribution Shift. Synthetische Daten weichen oft von realen Mustern ab — das Student-Modell schneidet im Training gut ab, scheitert in Produktion.
• Model Collapse bei wiederholten Generationen. Wenn Modelle wiederholt auf ihren eigenen synthetischen Daten trainiert werden, kann die Modellqualität langfristig degenerieren.

Diese Risiken werden vermieden durch: Filter, Diversifikation, Mischung mit realen Daten, regelmäßige Eval gegen reale Benchmarks.

6. Mischen mit realen Daten

Best Practice 2026 ist fast nie pure synthetische Daten, sondern eine gezielte Mischung:

• 70–80% synthetisch, 20–30% real. Standardverhältnis für Domain-Adaption.
• Reale Daten für die kritischen Slices. Hochrisikobereiche, Edge Cases, sensible Domänen — hier dominieren reale Daten.
• Synthetische Daten für die breite Abdeckung. Routineaufgaben, breite Klassen, datenarme Bereiche.

Die genaue Mischung ist empirisch durch Eval zu bestimmen — nicht zu raten.

7. Praxis: Eigene synthetische Pipelines

Eine schlanke Pipeline für mittelständische Use Cases:

1. Aufgabe definieren. Was soll das Student-Modell können? Welche Beispieltypen?
2. Teacher wählen. Open-Weight mit kommerziell freier Lizenz, am besten domänenspezifisch fine-getuned.
3. Diverse Prompt-Templates. 20–50 Templates mit Slots für Variabilität.
4. Batchgenerierung. Hunderte bis tausende Outputs pro Batch, parallelisiert.
5. Multi-Stage-Filter. Schema → Regeln → Modell-Re-Ranking.
6. Diversität messen. Embedding-Cluster, Topic-Verteilung. Bei Mode Collapse: Prompts variieren.
7. Eval-Set isoliert halten. Niemals synthetisch erzeugen — Eval muss real bleiben.
8. Iterieren. Erste Trainings-Runde, Eval, Schwächen identifizieren, gezielt synthetische Daten nachgenerieren.

Synthetic Data ist 2026 weder Allheilmittel noch Notlösung, sondern produktives Werkzeug mit klaren Einsatzregeln. Wer es sauber nutzt — mit Filtern, Diversifikation und Mischung mit realen Daten — kann LLM-Anpassungen umsetzen, die ohne synthetische Hilfe unbezahlbar oder unmöglich wären. Wer es naiv einsetzt, bekommt Modelle, die im Training glänzen und in Produktion versagen. Der Unterschied liegt in der Disziplin der Pipeline.