Experiments

Kurzzusammenfassung

• Experiments steuern Hypothesen, HPO und Kandidatenauswahl für Investment-Modelle.
• Business-Nutzen: schnellere Iteration bei belastbarer Vergleichbarkeit.
• BPMN-Leitpfad: Task Run experiment series → Gateway Target KPI reached? → Outcome Candidate selected/iterated.
• Qualitätsregel: Nur Runs mit vollständigem Metadaten-Set dürfen Kandidatenstatus erhalten.

Ziel

Jede Experimentserie liefert reproduzierbare Run-Metadaten, nachvollziehbare KPI-Vergleiche und einen sauber begründeten Candidate-Run.

Ablauf

BPMN-Schritt	Mechanik (Task/Gateway/Outcome)	Artefakte & Verantwortlich
Task: Define experiment charter	Hypothese, Primary KPI, Guardrails, Dataset-Snapshot festlegen	Artefakt: Experiment Charter; Responsible: Data Scientist
Task: Execute experiment runs	HPO/Varianten laufen mit vollständigem MLflow-Logging	Artefakt: Run-Set + Artifacts; Responsible: ML Engineer
Gateway: Target KPI reached?	Vergleich gegen Baseline inkl. Risiko-/Stabilitätsgrenzen	Nein: nächste Iteration; Accountable: ML Lead
Outcome: Candidate selected	Best-Run für Registry nominiert	Artefakt: Candidate Decision Record

Kontrollen

Governance- und Risiko-Aspekte

• Candidate muss Datenversion, Feature-Version und Code-SHA referenzieren.
• Experimente mit eingeschränkten Daten benötigen Purpose-Freigabe.
• Nicht reproduzierbare Runs sind für Registry gesperrt.

Messbare Akzeptanzkriterien

Kriterium	Grenzwert	Verantwortlich	Eskalation
Pflichtmetadaten je Run vollständig	100 %	ML Engineer	Candidate-Block
KPI-Verbesserung ggü. Baseline	≥ +2 % oder dokumentierte Ausnahme	Model Owner	Unterschreitung: Hold
Zeit bis Kandidatenreview	≤ 1 Arbeitstag	ML Lead	> 24 h: Product Escalation

Entscheidung

• Candidate erfüllt KPI- und Guardrail-Anforderungen.
• Run-Metadaten sind vollständig und reproduzierbar.
• Übergabe an Registry ist inklusive Begründung dokumentiert.

⋮⋮⋮

Experiment-Setup

• klare Hypothese und Zielmetrik
• definierter Datenschnitt inkl. Zeitraum
• reproduzierbare Parameter und Seed-Konfiguration

Iterationen

Jede Iteration dokumentiert Unterschiede in Features, Hyperparametern und Ergebnissen.

Verbindliche Experiment-Designregeln

Folgende Designregeln sind für jede Experimentserie verpflichtend und vor Kandidatennominierung zu prüfen.

Regelblock	Pflichtstandard	Prüfbarkeit
Baseline	Vor Start ist genau eine aktive Baseline mit fixem Datenschnitt, Feature-Set und KPI-Definition zu deklarieren.	Baseline-Run-ID im Charter + Run-Tags vorhanden
Vergleichshypothese	Jede Variante hat eine falsifizierbare Hypothese im Format Wenn <Änderung>, dann <KPI-Effekt>, weil <Mechanismus>.	Charter-Review (vollständiger Hypothesensatz)
Stop-Kriterien	Vorab definierte Stop-Regeln für Erfolg, Misserfolg und Abbruch (z. B. max. Iterationen, min. Effektgrösse, Guardrail-Verletzung).	Gate-Protokoll mit Triggergrund
Leakage-Guards	Zeitliche, feature-seitige und label-bezogene Leakage-Checks sind zwingend (train < validation < test, keine Zukunftsfeatures).	Automatischer Leakage-Report + Sign-off

Mindest-Stop-Kriterien (Default)

• Success: primary_kpi verbessert sich um mindestens +2 % gegenüber Baseline und Guardrails bleiben im Grenzwert.
• Fail: Nach 3 Iterationen keine Verbesserung > +0,5 % oder Stabilitätsmetrik verschlechtert sich.
• Abort: Jede bestätigte Leakage-Verletzung oder fehlende Datenrepräsentativität.

Leakage-Guard-Checkliste

• Zeitliche Trennung von Train/Validation/Test ist dokumentiert.
• Feature-Pipeline enthält keinen Zugriff auf Ziel- oder Zukunftsinformation.
• Label-Generierung ist unabhängig von späteren Ereignissen.
• Point-in-time Join-Logik ist für alle externen Features nachgewiesen.

Einheitliches Decision-Log-Feldset

Experimententscheidungen (candidate, hold, reject) müssen das standardisierte Feldset gemäss Decision Logging verwenden.

Feld	Pflicht	Beschreibung
decision_id	Ja	Eindeutige Entscheidungs-ID
decision_timestamp	Ja	UTC-Zeitstempel
decision_outcome	Ja	accept, reject, override
decision_rationale	Ja	Begründung inkl. Hypothesenbezug
baseline_run_id	Ja	Referenz auf aktive Baseline
candidate_run_id	Ja	Referenz auf ausgewählten Kandidaten
leakage_report_ref	Ja	Link auf Leakage-Prüfbericht
approver_role	Ja	Rolle des Entscheiders
artifact_links	Ja	Evidenzlinks (Reports, Plots, Notebook)
exception_expiry	Bedingt	Pflicht bei Override/temporärer Ausnahme

BPMN-Kontext

• IDs: CallActivity_TrainHPO
• Input-Bezug: Trainingsdatensatz, Hyperparameterraum und Experiment-Setup.
• Entscheidungsbezug: Auswahlentscheidung für bestes Modell gemäss Zielmetrik und Risikoauflagen.
• Output-Bezug: Registrierte Modellartefakte und Metriken für Backtesting/Promotion.