Synthetische Daten: Trainings- und Testfälle richtig aufbauen

Anbieterdokumentation und Bedingungen zur Nutzung von Ausgaben geprüft am 22. Oktober 2026. Die folgenden Supporttickets und Größenangaben für den Pilotdurchlauf sind eigens entwickelte Beispiele, keine Ergebnisse eines durchgeführten Modellexperiments.

Was sind synthetische Daten, und wie entstehen sie?

Synthetische Daten, auch Synthetic Data genannt, sind künstlich erzeugte Datensätze oder Beispiele für einen festgelegten Zweck. Bei der Entwicklung mit einem großen Sprachmodell, kurz LLM, geht es meist um Texte: etwa Supportanfragen, Frage-Antwort-Paare, Extraktionsbeispiele oder Dialoge. Grundlage sind eine Spezifikation und eine kleine Auswahl freigegebener Beispiele.

Ein Fahrsimulator macht das Prinzip anschaulich. Dort lässt sich eine schwierige Kreuzung immer wieder üben, ohne im Straßenverkehr auf dieselbe Situation warten zu müssen. Eine bestandene Simulatorprüfung zeigt aber weder, wie häufig diese Kreuzung im Verkehr vorkommt, noch beweist sie, dass jede Straße beherrscht wird. Synthetische Datensätze ermöglichen dieselbe nützliche Trennung zwischen abgedeckten Übungssituationen und Belegen über die reale Welt.

Entscheidend ist das Erzeugungsverfahren. Ein regelbasierter Generator befolgt Vorgaben, etwa dass die Gesamtsumme einer Bestellung der Summe ihrer Positionen entsprechen muss. Ein Generator für synthetische Tabellendaten lernt Muster über mehrere Spalten hinweg. Ein LLM erzeugt Sprache auf Basis eines Prompts und des mitgegebenen Kontexts. Diese Verfahren lassen sich kombinieren: Code erstellt eine gültige Bestellung, das LLM formuliert dazu die Kundenbeschwerde.

Synthetische Daten zu erzeugen ist etwas anderes, als einen bestehenden Datensatz zu maskieren. Wer einen Kundennamen ersetzt, lässt den Rest der Geschichte unverändert. Bei der Datenaugmentation wird ein vorhandenes Beispiel abgewandelt, etwa indem eine Frage umformuliert wird. Die Varianten bleiben mit ihrer Quelle verwandt. Keines dieser Verfahren schützt automatisch die Privatsphäre oder schafft unabhängige Belege.

Evals: Schwierige Fälle mit unabhängig geprüften Antworten

Bei der Anwendungsentwicklung helfen synthetische Evals vor allem gegen bekannte Fehlermuster: fehlende Informationen, widersprüchliche Anweisungen, nicht unterstützte Anliegen oder ungewöhnliche Formulierungen. Ein Eval ist ein wiederholbarer Test des Systemverhaltens.

Soll ein Supportassistent bei unklaren Kontoproblemen nachfragen, werden gezielt mehrdeutige Anfragen erzeugt. Eine prüfende Person gleicht die erwartete Reaktion mit den Vorgaben ab. Die Antwort des Generators darf nicht allein deshalb zur Musterlösung werden, weil sie überzeugend klingt.

Daneben gehört ein separater Evaluierungsdatensatz aus realen Anfragen, sofern diese verfügbar sind und verwendet werden dürfen. Ist das nicht möglich, können fachkundige Personen unabhängig eigene Testfälle verfassen. Damit lässt sich die Spezifikation prüfen. Die Genauigkeit über die gesamte Population im Produktivbetrieb lässt sich daraus nicht ableiten.

Fine-Tuning: KI-Trainingsdaten für gezieltes Verhalten

Bei der Anpassung eines Modells können synthetische Beispiele ein Format, eine Klassifikationsregel oder einen Antwortstil vermitteln, der in den vorhandenen Daten zu selten vorkommt. Fine-Tuning bedeutet, ein Modell durch Training mit Beispielen zu verändern.

Ausgangspunkt sollte ein beobachtbarer Fehler sein: Das Modell leitet etwa mehrdeutige Tickets immer wieder an die Abrechnung weiter. Dann werden geprüfte Beispiele für solche Mehrdeutigkeiten ergänzt und das angepasste Modell anhand unangetasteter Beispiele mit dem bisherigen Referenzmodell verglichen. Eine größere Trainingsdatei ist für sich genommen kein Erfolgsmaß.

Der Fine-Tuning-Workflow ist der nächste Schritt, sobald Aufgabe und Abnahmedatensatz stabil sind. Fehlt dagegen Faktenwissen im Kontext oder ändert es sich laufend, sollte zuerst der Kontext der Anwendung verbessert werden, bevor generierte Antworten dem Modell Fakten beibringen sollen.

Synthetische Testdaten für Software erzeugen

In der Softwareentwicklung sollen synthetische Testdaten die Regeln einer Anwendung auf die Probe stellen: fehlende Felder, doppelte Eingaben, ungewöhnliche Textlängen, ungültige Zustandsübergänge und verknüpfte Datenbankeinträge.

Ein Test des Bestellabschlusses braucht gültige Beziehungen zwischen Bestellungen, Kunden und Zahlungen. Dafür muss kein Sprachmodell die Rechenoperationen erfinden. Diese Bedingungen gehören in den Code. Ein LLM kommt dort hinzu, wo realistische Sprache einen Mehrwert bietet, etwa bei einem Lieferhinweis, der der Versandadresse widerspricht.

Wer einen Datensatz einkauft, sollte klären, welcher dieser Aufgaben er dient. Ein Datensatz für eine Demo eignet sich nicht zwangsläufig zum Training, und ein Trainingskorpus ist nicht automatisch ein Evaluierungsdatensatz.

Praxisbeispiel: Von Ausgangsbeispielen zu geprüften Kandidaten

Am Anfang steht eine eng umrissene Aufgabe, deren korrekte Antworten sich ohne Rückfrage beim Generator erklären lassen. In diesem Beispiel entstehen Kandidaten für die Zuordnung fiktiver Supporttickets zu billing, access oder human_review.

Die fiktiven Regeln sind einfach: Zahlungs- und Rechnungsprobleme gehören zur Abrechnung, Anmelde- und Passwortprobleme zum Zugang. Unklare Anfragen oder Anliegen aus beiden Bereichen werden von einem Menschen geprüft. Angaben, die der Kunde nicht gemacht hat, dürfen nicht hinzugedacht werden.

Sechs Ausgangsbeispiele mit eindeutigen Labels

Diese eigens verfassten Beispiele verdeutlichen die Abgrenzung:

• „Meine Karte wurde doppelt belastet.“ → billing
• „Auf dieser Rechnung steht der falsche Tarif.“ → billing
• „Der Link zum Zurücksetzen ist abgelaufen.“ → access
• „Seit ich mein Passwort zurückgesetzt habe, kann ich mich nicht mehr anmelden.“ → access
• „Ich habe bezahlt, kann mich aber nicht anmelden.“ → human_review
• „Es funktioniert immer noch nicht.“ → human_review

Die letzten Beispiele sind genauso wichtig wie die eindeutigen Fälle. Sie zeigen dem Generator, dass Ungewissheit ein zulässiges Ergebnis ist. Der Leitfaden zu Few-Shot-Prompting erklärt, wie Beispiele Regeln vermitteln, die in einer allgemeinen Anweisung unklar bleiben können.

Ein bereinigter Kandidat könnte so aussehen. Der Datensatz dient der Veranschaulichung und ist keine aufgezeichnete API-Ausgabe:

{
  "case_id": "billing-frustrated-indirect-a",
  "text": "Another invoice with the wrong plan, seriously?",
  "proposed_label": "billing",
  "policy_reason": "The customer identifies an invoice problem."
}

Entscheidend ist ein nachvollziehbarer, geprüfter Fall. Ob der Generator anfangs alle angeforderten Kandidaten geliefert hat, ist zweitrangig. Ein schwaches Rasterfeld darf niemals nur deshalb aufgefüllt werden, um die Zielanzahl zu erreichen.

Tools für synthetische Daten: Was die Dokumentation zusagt

Bei der Auswahl zählt, welchen Teil des Prozesses ein Tool übernimmt. Eine Modell-API ist die Schnittstelle, über die der eigene Code Modellausgaben anfordert; ihr Batch-Dienst plant die Verarbeitung dieser Anfragen. Eine Datensatzbibliothek organisiert Generierung und Feedback. Ein Generator für synthetische Tabellendaten lernt Zusammenhänge in strukturierten Daten. Keine dieser Funktionen ersetzt eigene Abnahmekriterien.

Synthetic Data Generation mit generativer KI: Die Batch-APIs

Die OpenAI API bietet Batch für asynchrone Anfragen, die als JSONL-Datei eingereicht werden, also mit einem JSON-Objekt pro Zeile. Laut Dokumentation ist eine eindeutige custom_id erforderlich; die Reihenfolge der Ausgaben kann von der Reihenfolge der Eingaben abweichen. Ergebnisse werden deshalb über ihre Kennung zugeordnet. Vor dem Einlesen der Kandidaten sind Fehler und unvollständige Generierungen zu prüfen. Dokumentation zu OpenAI Batch.

Die Claude API von Anthropic bietet Message Batches für voneinander unabhängige Messages-Anfragen. Die Ergebnisse unterscheiden zwischen erfolgreichen, fehlerhaften, abgebrochenen und abgelaufenen Anfragen. Über custom_id wird jedes Ergebnis seiner Eingabe zugeordnet. Entscheidend ist hier der Betrieb: Ein angenommener Batch belegt nicht, dass jedes Beispiel vollständig erzeugt wurde. Fehlende Verarbeitungsschritte werden anhand ihrer Kennung erneut angefordert, statt den ganzen Datensatz neu zu generieren. Dokumentation zur Batch-Verarbeitung mit Claude.

Die Gemini API von Google unterstützt Batch mit direkt eingebetteten Anfrageobjekten oder einer hochgeladenen JSONL-Datei. Dateibasierte Anfragen enthalten einen key, der das zugehörige Ergebnis identifiziert. Für größere offline verarbeitete Datensätze bietet sich die Dateiübermittlung an. Die dokumentierte Bearbeitungszeit ist ein Zielwert; ein interaktiver Workflow sollte daher nicht auf sofortige Fertigstellung angewiesen sein. Dokumentation zu Gemini Batch.

Diese in der verlinkten Dokumentation geprüften Batch-Grenzen bestimmen, wie Aufträge aufgeteilt werden müssen. Sie begrenzen nicht die Gesamtgröße eines Datensatzes, der über mehrere Aufträge entsteht.

Eine Batch-Anfrage und ein generiertes Beispiel sind unterschiedliche Zähleinheiten. Liefert jede erfolgreiche Anfrage mehrere Kandidaten, müssen beide Anzahlen erfasst werden. Neben Übertragungsfehlern gehören auch Parsingfehler, verweigerte Antworten und abgeschnittene Ausgaben ins Protokoll. Eine erfolgreiche HTTP-Antwort allein ergibt noch keinen brauchbaren Trainingsdatensatz.

Distilabel: Generierung und Feedback organisieren

Distilabel ist ein Framework für synthetische Daten und KI-Feedback. Es verbindet Generierungs-, Evaluierungs- und Datenverarbeitungsschritte zu Pipelines. Die Dokumentation beschreibt Anwendungsfälle für Klassifikation, Extraktion, Dialoge und die Erzeugung von Instruktionen. Das hilft, wenn aus einem einmaligen Skript mehrere Generierungs- und Filterstufen geworden sind. Distilabel-Dokumentation.

Das Projekt steht unter der Apache-2.0-Lizenz. Im Repository wird außerdem darauf hingewiesen, dass die ursprünglichen Autoren das Projekt verlassen haben und Mitwirkende aus der Community es betreuen. Die eingesetzte Version sollte festgeschrieben und geprüft werden. Die praktische Grenze liegt weiterhin bei der Bewertung: Die Steuerung eines Modellurteils macht dieses Urteil weder unabhängig noch korrekt. Distilabel-Repository.

Faker: Testdaten ohne Sprachmodell erzeugen

Faker ist ein Python-Paket, das über sogenannte Provider fiktive Daten erzeugt, verschiedene Ländereinstellungen unterstützt und das Setzen eines Zufallsseeds ermöglicht. Es eignet sich für Testdaten einer Anwendung, wenn kontrollierte Feldwerte statt Schlussfolgerungen in natürlicher Sprache gebraucht werden. Das Repository nennt MIT als Lizenz. Faker-Dokumentation, Faker-Repository.

Fachliche Zusammenhänge müssen weiterhin selbst im Code abgebildet werden. Unabhängig erzeugte Adressen, Datumsangaben und Transaktionen ergeben noch keine realistische Kundenhistorie. Nach Möglichkeit sollten reservierte Testkennungen und Testdomains verwendet werden. Generierte Testdaten dürfen keine Nachrichten oder andere Aktionen im Produktivbetrieb auslösen.

Synthetic Data Vault: Tabellen und ihre Beziehungen modellieren

Synthetic Data Vault, kurz SDV, bietet die Erzeugung synthetischer Tabellendaten und deren statistische Bewertung. Dokumentiert sind Verfahren für einzelne Tabellen, sequenzielle Daten und verknüpfte Tabellen. Die trainierten Generatoren lernen aus den bereitgestellten Daten. Ein Quelldatensatz, dessen Verwendung zulässig ist, bleibt also erforderlich. SDV-Dokumentation.

In SDV lernt GaussianCopulaSynthesizer mit klassischen statistischen Verfahren die Verteilungen und Zusammenhänge von Spalten. CTGANSynthesizer verwendet ein Generative Adversarial Network: ein Modell, das durch einen Generator und einen konkurrierenden Diskriminator trainiert wird. Beide verarbeiten Daten und Metadaten, die deren Struktur beschreiben. Es handelt sich um Generatoren für Tabellendaten, nicht um universell einsetzbare Chatmodelle. Dokumentation zu Gaussian Copula, Dokumentation zu CTGAN.

Entscheidend ist, ob die für die Aufgabe relevanten Eigenschaften erhalten bleiben. Ähnlich aussehende Spaltenverteilungen belegen nicht, dass seltene Kombinationen, tabellenübergreifende Regeln oder das Verhalten eines nachgelagerten Modells bewahrt werden. Geprüft werden müssen die Beziehungen, auf die die Anwendung angewiesen ist, einschließlich der Fremdschlüssel, die untergeordnete Datensätze mit übergeordneten verknüpfen.

Den Testdaten-Generator nach dem fehlenden Baustein auswählen

Eine Modell-API passt, wenn sprachliche Variation fehlt. Distilabel lohnt sich zusätzlich, wenn die wiederholbare Steuerung von Generierung und Feedback eine weitere Abhängigkeit rechtfertigt. Faker eignet sich für Testdaten mit kontrollierten Werten. SDV kommt infrage, wenn statistische Beziehungen zwischen Tabellen wichtig sind und Quelldaten vorliegen, die modelliert werden dürfen.

Ein größerer Generator löst keine unklaren Zuordnungsregeln. Dieses Problem muss vor dem Einsatz jedes hier genannten Tools geklärt werden.

Was erlauben Anbieter beim Training mit ihren Ausgaben?

Vor der Auswahl eines Lehrermodells müssen die Beschränkungen für die Nutzung seiner Ausgaben geprüft werden. Gemeint ist das Modell, das Beispiele erzeugt, aus denen ein anderes Modell lernen soll. Die folgenden Punkte fassen die Standardbedingungen der drei oben genannten Anbieter gehosteter LLMs zusammen. Daraus folgt keine Freigabe für ein bestimmtes Trainingsprojekt.

• OpenAI: Das Services Agreement beschränkt die Nutzung von Ausgaben zur Entwicklung konkurrierender KI-Modelle. Genannt werden Ausnahmen für Modelle, die hauptsächlich Daten kategorisieren, klassifizieren oder organisieren und weder an Dritte weitergegeben noch diesen kommerziell angeboten werden, sowie für die Anpassung von Modellen über die von OpenAI benannten Dienste. Services Agreement.
• Anthropic: Die Commercial Terms untersagen den Zugriff auf die Dienste zum Aufbau konkurrierender Produkte oder Dienste, einschließlich des Trainings konkurrierender KI-Modelle, sofern Anthropic dies nicht ausdrücklich genehmigt. Commercial Terms.
• Google: Die Additional Terms der Gemini API untersagen die Nutzung der Dienste zur Entwicklung konkurrierender Modelle. Die Bestimmungen zu Google Search Grounding verbieten außerdem gesondert das Training mit Grounded Results oder Search Suggestions. Nutzungsbedingungen der Gemini API.

Die Softwarelizenz einer Bibliothek ist getrennt von den Bedingungen des aufgerufenen Modells, der Lizenz etwaiger Modellgewichte und den Rechten an den Ausgangsbeispielen zu betrachten. Rechte an den Ausgaben allein klären nicht alle diese Fragen.

Datenschutz bei Testdaten braucht eine eigene Prüfung

Eine synthetische Herkunft garantiert keinen Datenschutz. Werden vertrauliche Datensätze in einen nicht freigegebenen Generierungsdienst kopiert, macht die spätere Erzeugung fiktiv wirkender Ersatzdaten diese Offenlegung nicht rückgängig.

Die Forschung von Stadler, Oprisanu und Troncoso zur Veröffentlichung synthetischer Daten zeigte, dass Datenschutzgewinne und Nutzwert zwischen den untersuchten Modellen unterschiedlich ausfielen. Für die Praxis folgt daraus: Bewertet werden müssen die veröffentlichten Daten und ihr Erzeugungsprozess. Das Wort „synthetisch“ ist kein Anonymitätszertifikat. USENIX-Forschungsarbeit.

Für Softwaretests sind fiktive Ausgangsbeispiele auf Basis eines freigegebenen Schemas und Regelwerks vorzuziehen, wenn sie ausreichen. Müssen reale statistische Muster erhalten bleiben, gehören die Quelldaten in eine freigegebene Umgebung. Zudem muss geprüft werden, welche Informationen der generierte Datensatz offenlegen kann.

Zu prüfen sind direkte Identifikatoren, kopierte Passagen, seltene Kombinationen und Verknüpfungen mit Informationen, die anderen bereits bekannt sein könnten. Ein ausgetauschter Name schützt eine Person möglicherweise nicht, wenn ein markanter Vorfall mit Ort und Datum erhalten bleibt. Vor der Veröffentlichung sensibler Daten reichen einige manuelle Stichproben und eine Dublettensuche nicht aus. Die Datenschutzprüfung muss zu den Bedrohungen und den vorgesehenen Empfängern passen.

Die Trainingsrichtlinien eines Anbieters beantworten eine andere Frage als die eigenen Rechte, mit dessen Ausgaben zu trainieren. Die Bedingungen für unbezahlte Gemini-Dienste warnen beispielsweise davor, sensible Informationen zu übermitteln. Die Datennutzungsbedingungen für bezahlte Dienste besagen dagegen, dass Prompts und Antworten nicht zur Verbesserung von Google-Produkten verwendet werden. Im EWR, in der Schweiz und im Vereinigten Königreich gelten diese Datennutzungsregeln für bezahlte Dienste laut Bedingungen auch bei unbezahlter Nutzung. Gemini-Bedingungen zur Datennutzung.

Weder die Zusage eines Anbieters, Daten nicht zum Training zu verwenden, noch eine lokale Ausführung belegt, dass der entstandene Datensatz gefahrlos weitergegeben werden kann. Herkunftsnachweise und Zugriffskontrollen bleiben deshalb bis zum Abschluss der Freigabeprüfung mit dem Datensatz verbunden.

Wo werden synthetische Daten überschätzt?

Die größte Übertreibung ist die Vorstellung, mehr generierte Zeilen könnten fehlende Belege ersetzen. Sie können mehr Übungssituationen abdecken und Fehler sichtbar machen. Sie können aber auch dieselben Annahmen in großem Maßstab vervielfältigen.

Andere Worte können dieselben Situationen verdecken

Ein Datensatz kann aus unterschiedlichen Sätzen bestehen und trotzdem nur wenige Situationen wiederholen. Nach der Filterung muss erfasst werden, welche Szenarien noch abgedeckt sind: Welche Geschäftsregeln, Mehrdeutigkeiten und Fehlermuster sind weiterhin vertreten?

Im Ticketbeispiel gleichen wiederholte Rechnungsbeschwerden das Fehlen kombinierter Abrechnungs- und Zugangsprobleme nicht aus. Geprüft werden sollten die jeweils ähnlichsten Beispiele sowie abgelehnte und akzeptierte Kandidaten. Ein zu strenger Qualitätsfilter kann unbemerkt genau die schwierigen Fälle aussortieren, die ergänzt werden sollten.

Umformulieren beseitigt Verzerrungen nicht automatisch

Wer ein verzerrtes Ausgangsbeispiel paraphrasiert, darf nicht annehmen, dass damit auch dessen Annahmen verschwinden. Die Labelvergabe sollte über verschiedene Sprachstile, Dialekte, Rechtschreibniveaus und relevante Nutzergruppen hinweg geprüft werden. Eine frustrierte oder fehlerhaft geschriebene Anfrage sollte nur dann anders weitergeleitet werden, wenn das Regelwerk diese Unterscheidung rechtfertigt.

Prüfende Personen vergleichen dafür möglichst gleiche Fälle, bei denen sich nur ein irrelevantes Merkmal ändert. Ändern sich die Labels mit, müssen Ausgangsbeispiel, Prompt und Filter gemeinsam untersucht werden. Generator und Bewertungsmodell können denselben Fehler gegenseitig verstärken.

Wenn ein Modell sich selbst benotet, kann das überzeugend wirken

Zheng und Kollegen dokumentierten bei LLM-Bewertern Verzerrungen zugunsten bestimmter Positionen, längerer Antworten und eigener Ausgaben. Ein Modell kann Formulierung oder Darstellung belohnen statt der Eigenschaft, die eigentlich gemessen werden sollte. Forschungsarbeit zu LLM-as-a-Judge.

Wo sich eine Antwort mechanisch überprüfen lässt, sollten deterministische Prüfungen eingesetzt werden. Bei subjektiven Kriterien wird das Bewertungsmodell an menschlichen Entscheidungen kalibriert. Soweit praktikabel, bleibt die Identität des Generators verborgen; abweichende Urteile werden geprüft. Ein anderer Anbieter für das Bewertungsmodell kann eine gemeinsame Abhängigkeit verringern, garantiert aber keine voneinander unabhängigen Fehler.

Der Leitfaden zu LLM-as-a-Judge erklärt, wie sich ein Bewerter prüfen lässt, bevor man seinem Ergebnis vertraut. Bei der Erzeugung synthetischer Daten gehört diese Prüfung an den Anfang: bevor der Bewerter entscheidet, welche Beispiele als korrekte Trainingsgrundlage gelten.

Model Collapse: Ein konkretes Risiko mit klaren Grenzen

Shumailov und Kollegen untersuchten rekursives Training mit generierten Daten und zeigten, wie seltenere Teile der ursprünglichen Verteilung verschwinden können. Das spricht für Vorsicht, wenn ursprüngliche Belege wiederholt durch die vom Modell abgeleiteten Daten ersetzt werden. Es belegt nicht, dass jeder geprüfte, auf eine konkrete Aufgabe zugeschnittene Fine-Tuning-Durchlauf mit synthetischen Daten scheitern muss. Forschungsarbeit in Nature.

Zulässige Originalbelege sollten erhalten, seltene Fälle gezielt bewahrt und das Verhalten des nachgelagerten Systems mit einer unangetasteten Referenz verglichen werden. Es gibt kein universelles Mischungsverhältnis von synthetischen und realen Daten, das diese Evaluierung ersetzen könnte.

Was sich ab Montag konkret ändern lässt

Jetzt beginnen, wenn sich ein fehlender Fall benennen, das richtige Verhalten dafür beschreiben und generierte Kandidaten anhand einer stabilen Regel prüfen lassen. Den Einstieg bildet das kleine Abdeckungsraster. Erweitert werden nur die Felder, die nützliche Fälle ergänzen.

Mit Fine-Tuning warten, wenn Prüfende sich über die Ziellabels uneinig sind oder ein unabhängiger Abnahmedatensatz fehlt. Zuerst müssen die Regeln und die Evaluierung geklärt werden.

Konventionelle Testdaten verwenden, wenn Datenbanken befüllt, Grenzwerte getestet oder die Integrität von Transaktionen geprüft werden sollen. Generierte Sprache wird nur dort ergänzt, wo sie Verhaltensweisen prüft, die einfachere Daten nicht erfassen.

Vor der nächsten Veröffentlichung werden das bisherige und das veränderte System anhand derselben unangetasteten Fälle verglichen. Bei der Supportweiterleitung sind falsche Zuordnungen und unterbliebene Eskalationen nach Kategorien zu untersuchen. Die synthetischen Daten werden nur beibehalten, wenn sie das beabsichtigte Verhalten verbessern, ohne an anderer Stelle unvertretbare Verschlechterungen zu verursachen.

Häufige Fragen zu synthetischen Daten

Den Newsletter abonnieren und praktische Anleitungen zur Entwicklung und Evaluierung von KI-Systemen erhalten.