Data Engineering: Vertrag vor Modell

Das Modell beginnt an der Datengrenze

Ein produktiver ML-Workflow ist mehr als Modellcode. Datenabhängigkeiten, Konfiguration, Glue Code, unbekannte Konsumenten und Feedback Loops können stille technische Schulden erzeugen.^[1] Deshalb definiere ich vor SQL oder Features einen Datenvertrag: Einheit, Schlüssel, Ereigniszeit, Verfügbarkeit zum Prognosezeitpunkt, Typ, zulässiger Bereich, Missingness-Semantik, Eigentümer, Retention und Änderungsprozess.

SQL-Entwurf: erst Körnung, dann Join

WITH base AS (
  SELECT entity_id, event_time, label
  FROM outcomes
  WHERE event_time < :cutoff
), features AS (
  SELECT entity_id, MAX(value) AS value_before_cutoff
  FROM events
  WHERE observed_at < :cutoff
  GROUP BY entity_id
)
SELECT b.entity_id, b.label, f.value_before_cutoff
FROM base b LEFT JOIN features f USING (entity_id);

Geprüfte Join-Rechnung: Hat base 100 eindeutige Schlüssel und der Join 107 Zeilen, ist die Multiplikationsrate 107/100=1,07. Das ist kein akzeptabler Zufall, sondern ein zu erklärender Grain-Verstoß. Tests prüfen vor und nach dem Join Eindeutigkeit, Zeilenzahl, Nullanteile, Zeitgrenzen und Labelrate.

Reproduzierbare Pipeline

1. Ingest: unveränderliche Rohreferenz, Schema und Herkunft erfassen.
2. Validate: Vertrag, Keys, Zeit, Wertebereiche und sensible Felder prüfen.
3. Transform: idempotente, versionierte Logik; gleiche Definition für Training und Inferenz.
4. Split: Einheit und Zeit vor lernenden Transformationen trennen.
5. Train/Evaluate: Code-, Daten-, Konfigurations- und Umgebungsstand protokollieren.
6. Publish: Artefakt plus Input-/Output-Schema und Rückfallversion.

Reproduzierbarkeit heißt nicht, dass ein Resultat wahr ist: Ein deterministisch reproduzierbarer Leakage-Fehler bleibt Leakage.