Synthetische Daten: wo wir sie nutzen und wo nicht
Wir haben einmal an einem Nachmittag vierhundert Testfälle erzeugt und uns produktiv gefühlt. Sie stimmten dem System in fast allem zu, was wir für Qualität hielten — bis eine echte Regression ungehindert hindurchspazierte.
Der Nachmittag, der sich produktiv anfühlte
Wir brauchten ein größeres Bewertungsset und hatten ein Modell zur Hand, also erzeugten wir vierhundert Frage-Antwort-Paare aus dem Bestand. Die Abdeckung sah ausgezeichnet aus, die Verteilung plausibel, und die Suite lief fast überall grün.
Wochen später führte eine Retrieval-Änderung eine echte Regression ein, und das erzeugte Set bemerkte sie nicht. Der Grund ist im Rückblick unangenehm: Die Fälle stammten von einem Modell, das dieselben Dokumente mit denselben Annahmen gelesen hatte — sie kodierten also das Verständnis des Systems statt der Erwartung der Nutzer.
Warum die Zustimmung die Warnung war
Ein Testset, das dem System fast überall zustimmt, misst entweder ein sehr gutes System oder das Falsche. Die Vorannahme sollte das Zweite sein, und wir hatten eine hohe Bestehensquote als Beruhigung gelesen statt als Signal, genauer hinzusehen.
Von Menschen geschriebene Fälle sind unsauberer und widersprechen häufiger, und in diesem Widerspruch liegt ihr Wert. Ein Fachexperte stellt eine Frage so, wie ein Kunde sie stellen würde — samt Mehrdeutigkeit und fehlendem Kontext, die eine erzeugte Frage wegräumt.
Die Linie, die wir ziehen
Wir erzeugen Eingaben. Wir erzeugen keine erwarteten Antworten. Ein Modell ist nützlich, um viele plausible Formulierungen einer Frage zu produzieren, Ton und Länge zu variieren und Wendungen sichtbar zu machen, die im Team niemand geschrieben hätte. Das verbreitert die Abdeckung, ohne festzulegen, was richtig heißt.
Die erwartete Antwort bleibt menschlich — oder sie fehlt, und der Fall wird von einer Person geprüft. In dem Moment, in dem dieselbe Modellfamilie die Antwort erzeugt und beurteilt, misst der Test innere Stimmigkeit und keine Richtigkeit mehr. Genau diesen Fehler hatten wir ausgeliefert.
| Wir erzeugen | Wir erzeugen nicht |
|---|---|
| Frageformulierungen und Umschreibungen | Die erwartete Antwort |
| Gegnerische Eingaben und Randfälle | Das Bestanden-oder-nicht-Urteil |
| Menge für Last- und Latenztests | Referenzwahrheit für Richtigkeit |
| Daten zu einem Schema mit festen Feldern | Alles, was zum Gate wird |
Wo sie sich wirklich lohnen
Gegnerische Eingaben sind der klarste Fall. Ein Modell hundert Formulierungen einer Anfrage produzieren zu lassen, die abgelehnt werden soll, findet Wendungen, auf die wir nicht gekommen wären — und das erwartete Ergebnis steht vorher fest, das Modell entscheidet also nichts.
Last- und Latenztests sind der zweite. Dort ist der Inhalt fast gleichgültig, und erzeugte Menge ist schlicht billiger als gesammelte. Keiner dieser beiden Fälle hat die Eigenschaft, die unser Bewertungsset unbrauchbar machte, denn in beiden steht das richtige Ergebnis fest, bevor die Daten existieren.
Was die Forschung als fehlendes Stück benennt
Singh und Kollegen haben Selbsttraining auf modellerzeugten Daten untersucht und die Abhängigkeit ausdrücklich gemacht: Was das Verfahren trägt, ist ein verlässliches Signal dafür, ob eine Ausgabe tatsächlich richtig ist — nicht die Erzeugung selbst.
Das ordnet die Frage nützlich neu. Selbsttraining funktioniert dort, wo Richtigkeit prüfbar ist, etwa wenn Code kompiliert und Tests besteht oder eine Rechnung nachrechenbar ist. Unser Bewertungsset hatte keine solche Prüfung, und genau deshalb erzeugte mehr davon Zuversicht statt Information.
Was wir heute tun
Das Referenzset blieb menschlich und klein, rund achtzig Fälle, und es ist das Gate. Erzeugte Eingaben stehen daneben als breiterer Suchlauf, der auf etwas Prüfenswertes hinweisen kann, aber allein nie ein Release blockiert.
Wir halten außerdem fest, woher jeder Fall stammt. Ein Fall mit erzeugter Eingabe und menschlicher Erwartung ist eine andere Art Beleg als einer, bei dem beides menschlich ist — und beides ohne Kennzeichnung zu mischen macht es unmöglich, über die Bedeutung einer grünen Suite zu urteilen.
Was die Strenge kostet
Die Strenge ist teuer. Ein von Hand geschriebener Fall mit geprüfter Erwartung kostet einen Fachexperten vielleicht zehn Minuten, weshalb unser Referenzset achtzig Fälle umfasst und nicht achthundert. Wir nehmen ein kleineres Set in Kauf, das etwas bedeutet, statt eines größeren, das es nicht tut.
Der Ausgleich ist, dass ein kleines Set gepflegt wird. Niemand sieht vierhundert erzeugte Fälle erneut durch, wenn sich die Domäne verschiebt; achtzig sind an einem Nachmittag geprüft, und in dieser Prüfung sammelt sich mit der Zeit der meiste Wert.
Was wir nicht behaupten
Wir behaupten nicht, synthetische Daten seien ein schlechtes Werkzeug. Wo ein Prüfer existiert, sind sie erkennbar mächtig, und die Forschungsrichtung ist real. Unsere Regel betrifft das Fehlen eines Prüfers, nicht das Verfahren.
Wir behaupten auch nicht, von Menschen geschriebene Fälle seien richtig, weil sie von Menschen stammen. Sie tragen eigene Verzerrungen, besonders hin zu den Fällen, die der Schreibende ohnehin im Kopf hat. Sie sind nur anders verzerrt als das geprüfte System — und diese Unabhängigkeit ist der ganze Punkt.