Feature-Definition und Trainingsdaten-Contracts
Feature-Bedeutung, Label-Ursprung und Trainingsfenster vor dem Modelltraining in durchsetzbare Contracts binden.
Ein Feature ohne Definition ist eine Vermutung mit Spaltennamen. Training ohne Daten-Contract mischt still Labels, Fenster und Populationen, die später nicht reproduzierbar sind. Governance beginnt, wenn Bedeutung und Trainingseingaben durchsetzbare Artefakte werden.
Die Definition steht im Notebook-Kommentar, der gestrige Extrakt wird ohne Fenster wiederverwendet, Labels gelten als Ground Truth ohne Guideline-Version. Dieser Teil bindet Definition, Label-Provenance und Trainingsfenster — bevor Zugriff, Model Card und Drift-Gates darauf aufsetzen.
Vorher: Features als gesteuerte Produkte. Weiter: Zugriff, Lineage und Point-in-Time-Korrektheit.
zierbar sind. Governance beginnt, wenn Bedeutung und Trainingseingaben durchsetzbare Artefakte werden.
Lösung: Vor jedem produktiven Training stehen Feature-Definition, Trainingsdaten-Contract, Label-Provenance und versionierte Änderungen. Der Data Owner genehmigt Bedeutung und Zweck; der Steward pflegt Definitionen; der Custodian gatet Jobs ohne gültige Feature-Version.
In einem Satz: Kein produktives Training ohne Feature-Definition, Trainings-Contract und gebundene Label-Provenance.
Entscheidung
Vor jedem produktiven Training:
- die Feature-Definition hält fachliche Bedeutung, Formel oder Quell-Transform, Einheiten, Null-Politik und Grain fest;
- der Trainingsdaten-Contract hält Population, Fenster, Label-Ursprung, Ausschlussregeln und erlaubte Feature-Versionen fest;
- der Data Owner genehmigt Bedeutung und erlaubten Trainingszweck; der Steward pflegt Definitionen; der Custodian setzt Schema- und Ingest-Gates durch;
- Label-Quellen tragen dieselbe Provenance-Pflicht wie Features — Labels sind ebenfalls Datenprodukte;
- jede materielle Änderung an Definition oder Trainingsfenster wird versioniert und mit Consumer-Impact versehen.
Kein Train-Job ohne definierte Feature-Versionen oder mit abgelaufenem Contract.
Definitions- und Contract-Workflow
1. Definitionskarte schreiben
Der Steward schreibt eine Karte, die eine Domänenexpertin in einem Satz verteidigen kann: Entity-Key, Beobachtungszeit, Null-Politik, Spätankünfte. Der Data Owner genehmigt Bedeutung und Trainingszweck. Definition nur im Code-Kommentar macht jede Pipeline zur Auslegungssache.
2. Offline-Transform und Online-Serving trennen
Wenn Offline und Online divergieren, dokumentieren Steward und Model-Team die bewusste Lücke plus Abnahmetest. Stiller Skew ist ein Incident mit Verzögerung, kein „bekanntes Eigenheit“. Wer die Lücke nicht schreibt, invalidiert später jede Eval-Claim.
3. Training Set contrakten
Population in/out, Datumsfenster, Sampling-Regel, Leakage-Checks und verbotene Joins. Fitness-Gates aus Fit for AI hängen am Contract, nicht am Notebook-Dateinamen. Gestrigen Extrakt ohne Fenster wiederverwenden ist Leakage im Zeitmantel.
4. Labels binden
Wer hat mit welcher Guideline-Version wann gelabelt — und mit welchem Qualitätssample? Mehrdeutige Labels brauchen Steward-Triage vor dem Training. „Ground Truth“ ohne Provenance macht Modelle unvergleichbar.
5. Train-Job gaten
Der Custodian blockiert Jobs ohne Feature-Versions-Tags oder mit abgelaufenem Contract. Ausnahmen tragen Ablauf und Owner. Mündliche Freigabe im Chat ist kein Gate — der nächste Retrain erbt die Lücke.
Handoffs
| Von | An | Artefakt |
|---|---|---|
| Data Owner | Steward | Genehmigte Definition + Trainingszweck |
| Steward | Labeling / Domänenexperten | Label-Guideline + Abnahmesample |
| Steward | Custodian | Schema, Null-Politik, Versions-Tags |
| Model-Team | Steward | Trainings-Contract-Antrag (Fenster, Population) |
| Custodian | Data Owner | Gate-Evidenz für den Train-Job |
Anti-Patterns
- Features nur in Code-Kommentaren definieren
- Gestrigen Trainingsextrakt ohne Fenster-Vereinbarung wiederverwenden
- Labels als „Ground Truth“ ohne Provenance behandeln
- Online- und Offline-Logik ohne dokumentierte Lücke divergieren lassen
- Trainingszweck mündlich im Chat freigeben
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.
- Definitionskarten für fünf Produktions-Features veröffentlichen.
- Einen Trainingsdaten-Contract an den nächsten geplanten Retrain hängen.
- Einen blockierenden Check für fehlende Feature-Versions-Tags am Train-Ingest ergänzen.
- Zwanzig Labels samplen und Guideline-Version plus Widerspruchsrate dokumentieren.
ML feature platform governance
Part 2 of 5
View series