Echtzeit-xG für Eishockey aufbauen: Von Rohdaten zur Live-WahrscheinlichkeitEishockey lebt von Momenten, die im Fluss entstehen: ein Pass in den Slot, ein Rebound aus spitzem Winkel, ein verdeckter Wrist Shot durch drei Beine. Ein System für expected goals (xG) in Echtzeit versucht, diese Momente in Wahrscheinlichkeiten zu gießen – nicht als Orakel, sondern als nüchterne, kalibrierte Prognose dafür, ob ein Schuss ins Tor geht. Dieser Beitrag zeichnet einen praxistauglichen Pfad: Datenquellen, Feature-Design, Modellierung, Latenz, Ausspielung, Qualitätssicherung.
Was xG im Hockey wirklich misst
xG ist die geschätzte Trefferwahrscheinlichkeit für einen einzelnen Abschluss, bedingt auf Kontext. Im Hockey umfasst dieser Kontext typischerweise: Schussdistanz und -winkel, Schusstyp (Wrist, Slap, Snap, Backhand, Tip-in), Pre-Shot-Bewegung (East–West-Pass kurz vor dem Schuss), Schussgeschwindigkeit, Rebound-Flag, Screen vor dem Goalie, Puckhöhe, Spielstand, Unter-/Überzahl, verbleibende Zeit, Goalie-Hand (Fanghand links/rechts) und die defensive Dichte in der Schussbahn. Keine Metrik ist allwissend; xG verschiebt nur die Intuition in messbare, reproduzierbare Größen.Eine praktische Fußnote: Datengüte schlägt Modellwahl. Tracking-Systeme (optisch oder via Puck/Player-Tags) liefern Koordinaten mit Jitter, Ausfälle und Verzögerungen inklusive. Robustheit gegen diese Unschärfe ist Pflicht.
Ergänzend lohnt sich ein Blick auf Aufbau-Teams und Zusammenarbeit. In verteilten Projekten kann IT Nearshoring in die Ukraine mit Mobilunity ein Baustein sein, wenn modular entwickelt wird und klare SLAs, Observability und definierte Schnittstellen gelten – die Distanz fällt dann kaum ins Gewicht.
Datenpfad und Latenzbudgets
Echtzeit beginnt mit dem Ingest. Minimalvariante: Events aus einem offiziellen Feed (Shot, Goal, Miss, Block) plus Rink-Koordinaten. Reichhaltiger wird es mit 10–30 Hz Tracking. Eine robuste Pipeline nutzt einen Ereignisbus (z. B. Kafka), eine Stream-Engine (Flink oder Spark Structured Streaming) und einen Feature-Store mit Low-Latency-Serving (Redis beziehungsweise ein Key-Value-Store). Zielgröße: unter 250 Millisekunden vom Event bis zur Inferenz, damit Broadcaster-Grafiken wirklich live wirken.Feature-Aggregation passiert zustandsbehaftet: letzte Puckbesitzdauer, Passanzahl in der Sequenz, Zeit seit Zonen-Eintritt, Geschwindigkeit des Pucks in x/y-Richtung, Goalie-Lateralbewegung im Ein-Sekunden-Fenster. Wichtig ist ein deterministisches Windowing (Event-Time, Watermarks), damit Burst-Events nicht zu Doppel-Berechnungen führen.
Labeling, Klassengewicht und Zielgröße
Trainingslabels sind binär: Tor (1) oder kein Tor (0) beim jeweiligen Schuss. Da Tor-Ereignisse im Verhältnis selten sind, kippt die Klassenverteilung; Klassengewichte oder eine Focal-Loss-Variante helfen, ebenso negatives Downsampling mit Vorsicht. Die Zielgröße bleibt eine gut kalibrierte Wahrscheinlichkeit p(Tor | Kontext). Zur Beurteilung sind Log-Loss, Brier-Score und erwartungstreue Kalibrierung (Reliability-Kurven, Expected Calibration Error) zentral; ROC-AUC allein täuscht hier leicht.Ein Spezialfall sind Deflections und Screens. Ein Tipp-in direkt vor dem Goalie bei starkem Verkehr benötigt andere Features als ein freier One-Timer von den Hashmarks. Das Modell muss diese Interaktionsterme spüren und entsprechend gewichten.
Feature-Design: vom Puck bis zur Tormaschine
Ein solides Start-Set umfasst:● Geometrie: Distanz zum Tor, Schusswinkel, seitliche Abweichung, Öffnungswinkel zum Goalie.
● Dynamik: Puck-Geschwindigkeit, Beschleunigung, Goalie-Drift, Richtungswechsel im Pre-Shot-Pass.
● Taktik: Rebound (Zeit seit letztem Schuss < 2 s?), Rush-Chance nach Turnover, Odd-Man-Rush-Flag.
● Dichte: Anzahl Verteidiger im 1,5-m-Korridor der Schusslinie; Screen-Score (okkludierte Sichtlinien).
● Kontext: Score-State, Zeit auf der Uhr, Spielphase, Stärkeverhältnis, Müdigkeits-Proxys (Schichtdauer).
Ein bewusst ungewohntes Beispiel: Ein halbhoher Backhand-Flip aus spitzem Winkel ist normalerweise harmlos. Aber wenn der Goalie gleichzeitig lateral gleitet und ein Verteidiger die Sicht in Höhe der Fanghand blockiert, steigt die Trefferchance sprunghaft. Solche Konstellationen sollten explizit als Interaktionen modelliert werden – etwa Winkel × Goalie-Drift × Screen-Score.
Modellarchitektur und Kalibrierung
Für Echtzeit zählen Stabilität und Interpretierbarkeit. Drei praxistaugliche Optionen bieten sich an: Erstens eine logistische Regression mit nichtlinearen Basisfunktionen (Splines für Distanz und Winkel) – schnell, erklärbar, überraschend stark. Zweitens Gradient Boosted Trees, die Interaktionen automatisch erfassen; mit Temperature-Scaling bleiben sie gut kalibrierbar. Drittens leichte neuronale Netze (zum Beispiel ein MLP mit ein bis zwei Hidden-Schichten), wenn Tracking-Features reichhaltig vorliegen.Kalibrierung ist Pflicht: Platt-Scaling oder Isotonic Regression auf einem strikten Holdout. Ohne diese Schritte wirken xG-Werte übermütig oder zu konservativ. Ein sauberer Calibration-Report gehört zur Release-Checkliste. In produktiven Umgebungen zahlt sich zudem die saubere Anbindung an Stammdaten und Betriebsprozesse aus; erfahrene ERP Beratung beschleunigt die Integration in bestehende Systeme ohne die Latenzbudgets zu sprengen.
Online-Serving und State
Das Serving-System hält pro Spiel fortlaufenden State: letzte Pässe, aktuelle Wechsel, frische Schüsse. Ein Shot-Event triggert eine Feature-Extraktion im Millisekundenbereich und ruft das Modell auf. Ergebnisse landen in einer Overlay-Grafik für TV/Stream, auf einem Coaching-Tablet an der Bank sowie in einem öffentlichen Dashboard. Zwischenspeichern hilft: Viele Features ändern sich langsam (etwa Score-State). Caches senken Latenz und Kosten.Drift, Wartung, Governance
Saison für Saison ändern sich Torhüter-Stile, Schussprofile, sogar Regeln. Ein wöchentlicher Drift-Report – Feature-Verteilungen, Population Stability Index, JS-Distanzen, ECE-Stabilität – hält das System ehrlich. Re-Kalibrierung kann öfter nötig sein als Re-Training. Für Integrationen in bestehende Datenlandschaften, etwa BI-Kuben, Ticketing oder Materialverwaltung, ist saubere Schnittstellengestaltung entscheidend; externe Expertise für Unternehmenssysteme wird in vielen Organisationen zu einem Multiplikator, weil sie Schnittstellen sauber zieht und Betriebsrisiken senkt.Visualisierung und Produkt-Erlebnis
xG entfaltet Wirkung, wenn es lesbar ist: Eine Shot-Map zeigt Punkte, die nach xG skalieren; Rebounds mit Pfeil, Tipp-ins mit Dreieck, Rush-Chancen mit Umrandung. Eine Zeitreihe summiert die xG pro Team und vermittelt Momentum, ohne Nebelkerzen. Eine Play-by-Play-Karte markiert Pre-Shot-Pässe als Linien, Goalie-Bewegung gestrichelt; die Schuss-Annotation trägt die aktuelle Wahrscheinlichkeit. Ein kurzer Kontext-Hinweis hilft: „Hohe Chance: seitlicher Pass über die Royal Road bei starker Goalie-Lateralbewegung.“ Zur Vertiefung vgl. den Wikipedia-Artikel Expected goals.Gebrauchstauglichkeit schlägt Schnickschnack. Dunkler Hintergrund, geringe Sättigung, klare Typografie. Und vor allem: keine Prozent-Feuerwerke – zwei Dezimalstellen genügen. Ein kleines Detail darf verspielter sein, etwa ein sanftes Einblenden der Wahrscheinlichkeiten; der Kern bleibt nüchtern.
Qualitätssicherung: Tests, Reproduktionen, Edge-Cases
Ein robustes Echtzeit-xG wächst mit Tests. Unit-Tests prüfen Feature-Funktionen (Geometrie, Rebound-Erkennung). Golden-Spiel-Replays werden deterministisch abgespielt und vergleichen Output-Diffs über Builds hinweg. Chaos-Tests simulieren fehlende Events, verspätete Watermarks, Ausreißerkoordinaten. Fairness-Sichten betrachten Modellleistung nach Teams, Saisons und Goalies; keine systematische Benachteiligung. Kalibrierungs-Wächter schlagen Alarm, wenn die ECE eine definierte Schwelle überschreitet.Ein kleiner, aber nützlicher Trick: Beim Serving werden Wahrscheinlichkeiten leicht geglättet – ein exponentiell gewichteter gleitender Durchschnitt über 200 bis 400 Millisekunden. Das nimmt Flackern aus der Grafik, ohne den Rohwert zu verschweigen.
Erweiterungen: Sequenzen und Gefahrenkarten
xG für einzelne Schüsse ist ein Anfang. Mehr Kontext liefert eine sequenzbasierte Sicht: expected possession value (EPV) über die Angriffssequenz. Im Hockey kann ein analoges Konzept zu xThreat aus dem Fußball adaptiert werden: Zonenwertkarten (Betreten erhöht Erwartungswert), Übergangswahrscheinlichkeiten (Boards entlang versus Slot-Einstich) und eine Belohnung am Abschluss. In Echtzeit erlaubt das einen Kommentar wie: „Der letzte Querpass hat die Torchance verdoppelt, noch bevor der Schuss kam.“Solche Modelle profitieren von Graph-Darstellungen der Zone-Transitions und von zeitlichen Convolution-Blöcken. Dabei gilt weiterhin: Latency-Budget zuerst, danach Modell-Luxus. Ein kleiner Reality-Check: Mehr Komplexität bedeutet oft mehr Drift, also mehr Pflege.
Betriebsrealität und Teamsetup
Ein kompaktes Setup für den Start umfasst idealerweise eine Stream-Engineer-Rolle für Ingest und State, eine Data-Scientist-Rolle für Feature-Design, Training und Kalibrierung, eine ML-Engineer-Rolle für Serving, CI/CD und Monitoring sowie eine Frontend-Rolle für Overlays und Dashboards. Dazu halbe DevOps-Kapazitäten für IaC, Observability und SLOs.Build-Empfehlungen: Infrastructure as Code mit Terraform, reproduzierbare Umgebungen via Docker, ein Feature-Store mit Offline/Online-Parität, Modell-Artefaktversionierung, Blau/Grün-Rollouts und Shadow-Tests am Live-Feed. Release-Kandidaten bestehen Reliability-Plots auf einem strikten Holdout; sonst bleiben sie im Schatten. Ein Playbook für Incident-Response (wer macht was, wann?) verhindert Hektik an Game Nights. Bei Organisationsfragen rund um Modellfreigaben, Monitoring und Audit hilft erfahrene AI Beratung, schlanke und nachvollziehbare Abläufe zu etablieren. Das ist ein solider Startpunkt fürs Produkt.
