Scoring

Kurzzusammenfassung

• Diese Seite definiert den produktiven Vertrag für Score-Erzeugung und Auslieferung.
• Sie macht Input-/Output-Schemata, SLA/SLO und Fehlerpfade verbindlich.
• Ziel ist reproduzierbares Verhalten pro Lauf inkl. Wiederanlauf ohne Datenverlust.
• Alle Abweichungen müssen über Incident- und Audit-Referenzen nachvollziehbar sein.

Zweck

Erzeugung versionierter Signale/Forecasts auf Basis freigegebener Modelle und deterministischer Feature-Snapshots.

BPMN-Detailansicht

⋮⋮⋮

BPMN-Kontext

• IDs: ServiceTask_Scoring
• Input-Bezug: Produktionsmodell, Feature-Snapshot, Laufzeitkonfiguration.
• Entscheidungsbezug: Erfolg, Retry oder Abbruch auf Basis SLA/SLO und Validierungschecks.
• Output-Bezug: Versionierte Scoring-Outputs für Dashboard/API und nachgelagerte Entscheidungen.

Eingabe-/Ausgabe-Vertrag

Eingabe (Pflichtfelder)

Feld	Typ	Regel
run_id	string	Eindeutig pro Lauf
model_ref	string	Registry-URI inkl. Version/Alias
feature_snapshot_id	string	Reproduzierbarer Snapshot
as_of_ts	timestamp (UTC)	Bewertungszeitpunkt
universe_id	string	Zieluniversum für Scoring

Ausgabe (Pflichtfelder)

Feld	Typ	Regel
entity_id	string	Bewertete Einheit
score	float	Normalisiert gemäss Modellvertrag
score_confidence	float	Optional, falls Modell verfügbar
model_version	string	Exakte Modellversion
scored_at	timestamp (UTC)	Erzeugungszeitpunkt
trace_id	string	Referenz auf Pipeline-/Audit-Log

SLA/SLO

• SLA (extern): Ergebnisse bis 18:45 UTC für Tageslauf verfügbar.
• SLO (intern):
  • Laufzeit p95 ≤ 12 min.
  • Erfolgsquote ≥ 99% pro 30 Tage.
  • Datenvollständigkeit ≥ 99.5% der erwarteten Entitäten.

Fehlerbehandlung

Fehlerklasse	Beispiel	Reaktion
Input-Validierung	Schemafehler, fehlender Snapshot	Hard-Fail, Incident eröffnen
Temporär	Registry/API Timeout, transient IO	Automatischer Retry (exponentiell)
Qualitätsverletzung	Coverage/KPI unter Schwellwert	Run als degraded, manuelle Freigabe
Systemisch	Cluster/Dependency-Ausfall	Abbruch, Rollback oder Fallback-Modell

Wiederanlaufregeln

1. Wiederanlauf nur mit identischem run_id und unverändertem Input-Snapshot.
2. Maximal 3 automatische Retries innerhalb von 20 Minuten.
3. Nach 3 Fehlversuchen: Eskalation an MLOps On-Call, Status run_aborted.
4. Idempotenzpflicht: bereits persistierte Outputs dürfen nicht doppelt publiziert werden.
5. Nach erfolgreichem Wiederanlauf muss recovery_note im Run-Protokoll hinterlegt werden.

Entscheidung

• Ein-/Ausgabe-Vertrag versioniert und technisch erzwungen.
• SLA/SLO-Monitoring mit Alert-Schwellen aktiv.
• Fehler- und Wiederanlaufregeln im Betrieb getestet.