Labeling-Provenance und Qualität für synthetische Daten
Nachverfolgen, wer synthetische Sets unter welcher Guideline und mit welcher Qualitäts-Evidenz gelabelt hat — vor Train oder Eval.
Synthetische Zeilen mit nachlässigen Labels trainieren selbstbewusste Fehler. Auto-Labels ohne Guideline-Version wirken günstig, bis das Modell in Produktion scheitert. Provenance macht Labeling zu einer zurechenbaren Kontrolle — gebunden an den Generierungs-Contract aus Teil 2.
Vorher: Zweck, Population und Generierungs-Contracts. Weiter: Re-Identifikations-Risiko-Gates.
z (Agreement-Sample, Mehrdeutigkeitsklassen, Abnahmeschwelle); der Data Owner genehmigt die Label-Bedeutung, der Steward besitzt Guideline und Triage, der Custodian friert akzeptierte Batches ein — Human- und Machine-Labels bleiben unterscheidbar, abgelehnte Batches werden nicht still wiederverwendet.
In einem Satz: Kein Train- oder Eval-Set ohne Label-Provenance, Guideline-Version und Abnahmeschwelle.
Entscheidung
Bevor gelabelte synthetische Daten in Train oder Eval gehen:
- trägt jeder Label-Batch Provenance: Labeler-Identität oder System, Guideline-Version, Zeit und Tool;
- umfasst Qualitäts-Evidenz Agreement-Sample, bekannte Mehrdeutigkeitsklassen und Abnahmeschwelle;
- genehmigt der Data Owner die Label-Bedeutung für den Zweck; der Steward besitzt Guideline und Triage; der Custodian setzt Schreibpfade und Unveränderlichkeit akzeptierter Batches durch;
- sind Human- und Machine-Labels in Metadaten unterscheidbar;
- werden abgelehnte Batches nur nach dokumentierter Retention behalten — nicht still wiederverwendet.
Kein Train-Contract referenziert einen Batch ohne eingefrorene Batch-ID.
Labeling-Workflow
1. Guideline versionieren
Der Steward schreibt Beispiele, Edge Cases und verbotene Inferenzen in eine versionierte Guideline; der Data Owner gibt die Label-Bedeutung für den Zweck frei. Änderungen erzeugen eine neue Version — Live-Docs während eines Batches werden nicht still editiert. Fehlt die Version, lässt sich ein schlechter Batch nicht auf die Instruction zurückziehen, die ihn erzeugt hat.
2. Generierungs- und Labeling-Rollen trennen
Wo möglich genehmigen Generatoren nicht selbst Labels für wirkungsstarkes Training. Der Steward weist den Batch an Labeler oder Labeling-System mit Guideline-Version und Anweisungen zu. Wer Generierung und Label-Freigabe in einer Person vereint, prüft die eigene Methode — und Provenance wird zur Formalität.
3. Qualität samplen
Jeder Batch liefert ein Agreement-Sample und eine Widerspruchsrate. Der Steward führt den Adjudikationspfad und eskaliert systematische Mehrdeutigkeit an den Data Owner. Failt das Sample, hält der Release: Instructions oder Modell fixen, mit neuer Batch-ID neu labeln. Ohne Sample gelten Auto-Labels als „fertig“, bis Produktion das Gegenteil beweist.
4. Akzeptierte Batches einfrieren
Der Custodian schreibt akzeptierte Batch-IDs als unveränderliche Inputs in Train- und Eval-Contracts. Das Provenance-Pack (wer/was, Guideline-Version, Sample-Ergebnis) hängt an der ID. Wird ein akzeptierter Batch überschrieben, ist Auditierbarkeit und Rückzug unmöglich.
5. Limits sichtbar machen
Wenn synthetische Labels seltene Klassen unterrepräsentieren, vermerkt der Steward die Lücke auf der Purpose Card und — wo verknüpft — auf der Model Evidence. Der Owner entscheidet, ob der Zweck trotzdem gilt. Verschwiegene Lücken machen Eval-Metriken vergleichbar, obwohl die Welt im Set fehlt.
Handoffs
| Von | An | Artefakt |
|---|---|---|
| Data Owner | Steward | Genehmigte Label-Bedeutung + Abnahmeschwelle |
| Steward | Labeler / Labeling-System | Guideline-Version + Batch-Anweisungen |
| Labeling | Steward | Batch + Agreement-Sample |
| Steward | Custodian | Akzeptierte Batch-IDs + Provenance-Pack |
| Custodian | Train-/Eval-Pipelines | Unveränderliche Batch-Referenzen |
Anti-Patterns
- Alles auto-labeln und Sampling überspringen
- Guidelines mitten im Batch ohne Versionsbump ändern
- Human- und Machine-Labels ohne Flags mischen
- Abgelehnte Batches wiederverwenden, weil „das Volumen niedrig war“
- Kein Adjudikationspfad bei Widersprüchen
Umsetzung im Alltag
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.
Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.
- Guideline-Version an den nächsten Labeling-Batch hängen.
- Ein Agreement-Sample fahren und die Rate dokumentieren.
- Eine akzeptierte Batch-ID für Eval-Nutzung einfrieren.
- Machine- vs. Human-Labels in Metadaten einer Pipeline kennzeichnen.
Synthetic data governance
Part 3 of 5
View series