Face-off Probability, en del af NHL Edge IQ: Forudsigelse af face-off vindere i realtid under tv-spil

Face-off Sandsynlighed er National Hockey League (NHL) første avancerede statistik ved hjælp af maskinlæring (ML) og kunstig intelligens. Den bruger data om spiller- og pucksporing i realtid (PPT) til at vise seerne, hvilken spiller der sandsynligvis vinder en face-off, før pucken droppes, og giver tv-stationer og seere mulighed for at dykke dybere ned i vigtigheden af ​​face-off kampe og forskellene i spillerens evner. Baseret på 10 års historiske data, blev hundredtusindvis af face-offs brugt til at konstruere over 70 funktioner, der blev indført i modellen for at give sandsynligheder i realtid. Broadcastere kan nu diskutere, hvordan en vigtig face-off-sejr af en spiller førte til et mål, eller hvordan chancerne for at vinde en face-off mindskes, da et holds face-off-specialist undlades fra uafgjort. Fans kan se visuelle forudsigelser i realtid, der viser dem vigtigheden af ​​en vigtig del af spillet.

I dette indlæg sætter vi fokus på, hvordan ML-modellen for Face-off Sandsynlighed blev udviklet og de tjenester, der blev brugt til at sætte modellen i produktion. Vi deler også de vigtigste tekniske udfordringer, der blev løst under konstruktionen af ​​Face-off Probability-modellen.

Sådan fungerer det

Forestil dig følgende scenarie: Det er en uafgjort kamp mellem to NHL-hold, der afgør, hvem der rykker frem. Vi er i tredje periode med 1:22 sekunder tilbage at spille. To spillere fra modsatte hold stiller op for at tage lodtrækningen i den nærmeste face-off tættere på et af nettene. Linjedommeren bemærker en forsvarsspiller, der trænger sig ind i face-off-cirklen og giver afkald på deres spiller fra face-off på grund af overtrædelsen. En mindre erfaren forsvarsspiller kommer ind for at tage uafgjort som sin erstatning. Det angribende hold vinder face-off, får pucken i besiddelse og scorer straks for at tage føringen. Scoringen holder i det resterende minut af kampen og afgør, hvem der rykker frem. Hvilken spiller blev begunstiget til at vinde face-off, før den oprindelige duo blev ændret? Hvor meget faldt defensivens holds sandsynlighed for at vinde face-off af den overtrædelse, der tvang en anden spiller til at tage uafgjort? Face-off Probability, den nyeste NHL Edge IQ-statistik drevet af AWS, kan nu besvare disse spørgsmål.

Når der er et stop i spillet, genererer Face-off Probability forudsigelser for, hvem der vinder den kommende face-off baseret på spillerne på isen, placeringen af ​​face-off og den aktuelle kampsituation. Forudsigelserne genereres under hele pausen, indtil kampuret begynder at køre igen. Forudsigelser opstår med forsinkelser på under sekunder og udløses hver gang, der er en ændring i de spillere, der er involveret i face-off.

Overvinde vigtige forhindringer for face-off sandsynlighed

Forudsigelse af face-off-sandsynlighed i realtidsudsendelser kan opdeles i to specifikke underproblemer:

• Modellering af face-off-hændelsen som et ML-problem, forståelse af kravene og begrænsningerne, forberedelse af data, konstruktion af datasignaler, udforskning af algoritmer og sikring af resultaternes pålidelighed
• Registrering af en face-off-begivenhed under spillet fra en strøm af PPT-begivenheder, indsamling af nødvendige parametre til forudsigelse, kald til modellen og indsendelse af resultater til tv-selskaber

At forudsige sandsynligheden for, at en spiller vinder en face-off i realtid på en tv-udsendelse har flere tekniske udfordringer, som skulle overvindes. Disse omfattede at bestemme de nødvendige funktioner og modelleringsmetoder til at forudsige en hændelse, der har en stor mængde usikkerhed, og at bestemme, hvordan man bruger streaming af PPT-sensordata til at identificere, hvor en face-off finder sted, de involverede spillere og sandsynligheden for hver spiller vinde face-off, alt sammen inden for hundreder af millisekunder.

Opbygning af en ML-model for svære at forudsige hændelser

Forudsigelse af begivenheder som f.eks. sandsynligheder for at vinde under et livespil er en kompleks opgave, der kræver en betydelig mængde historiske data og datastreaming af høj kvalitet. For at identificere og forstå de vigtige signaler i et så rigt datamiljø kræver udviklingen af ​​ML-modeller omfattende fagekspertise. Det Amazon Machine Learning Solutions Lab samarbejdet med NHL-hockey og dataeksperter for at arbejde baglæns fra deres mål om at forbedre deres fanoplevelse. Ved konstant at lytte til NHL's ekspertise og teste hypoteser, konstruerede AWS's forskere over 100 funktioner, der korrelerer med face-off-begivenheden. Især klassificerede holdet dette funktionssæt i en af ​​tre kategorier:

• Historisk statistik over spillerpræstationer såsom antallet af face-offs en spiller har taget og vundet i de sidste fem sæsoner, antallet af face-offs spilleren har taget og vundet i tidligere kampe, en spillers vinderprocenter over flere tidsvinduer, og head-to-head vinderprocenten for hver spiller i face-off
• Spillerkarakteristika såsom højde, vægt, behændighed og år i ligaen
• Situationsdata i spillet, der kan påvirke en spillers præstation, såsom spillets score, den forløbne tid i spillet til det punkt, hvor face-off er placeret, styrken af ​​hvert hold, og hvilken spiller skal placere deres pind ned for face-off først

AWS's ML-forskere betragtede problemet som et binært klassifikationsproblem: enten vinder hjemmespilleren face-off, eller udespilleren vinder face-off. Med data fra mere end 200,000 historiske face-offs brugte de en LightGBM model til at forudsige, hvilken af ​​de to spillere, der er involveret i en face-off begivenhed, der sandsynligvis vil vinde.

Afgøre, om en face-off er ved at finde sted, og hvilke spillere der er involveret

Når der fløjtes, og spillet stoppes, begynder Face-off Probability at komme med forudsigelser. Face-off-sandsynlighed skal dog først bestemme, hvor face-off finder sted, og hvilken spiller fra hvert hold der er involveret i face-off. Datastrømmen angiver hændelser, efterhånden som de opstår, men giver ikke information om, hvornår en hændelse sandsynligvis vil indtræffe i fremtiden. Som sådan er sensordataene for spillerne på isen nødvendige for at afgøre, om og hvor en face-off er ved at ske.

PPT-systemet producerer lokaliteter og hastigheder i realtid for spillere på isen med op til 60 begivenheder i sekundet. Disse steder og hastigheder blev brugt til at bestemme, hvor face-off sker på isen, og om det er sandsynligt, at det snart vil ske. Ved at vide, hvor tæt spillerne er på kendte face-off-placeringer, og hvor stationære spillerne var, var Face-off Probability i stand til at bestemme, at en face-off sandsynligvis ville finde sted, og de to spillere, der ville være involveret i face-off .

Bestemmelse af den korrekte afskæringsafstand for nærhed til et afskæringssted og den tilsvarende afskæringshastighed for stationære spillere blev opnået ved hjælp af en beslutningstræmodel. Med PPT-data fra sæsonen 2020-2021 byggede vi en model til at forudsige sandsynligheden for, at en face-off finder sted på et bestemt sted givet den gennemsnitlige afstand fra hvert hold til placeringen og spillernes hastigheder. Beslutningstræet gav afskæringerne for hver metrik, som vi inkluderede som regelbaseret logik i streamingapplikationen.

Med den korrekte face-off-placering bestemt, blev spilleren fra hvert hold, der tog face-off, beregnet ved at tage spilleren nærmest den kendte placering fra hvert hold. Dette gav applikationen fleksibiliteten til at identificere de korrekte spillere, samtidig med at den var i stand til at tilpasse sig, at en ny spiller skulle tage en face-off, hvis en nuværende spiller undlades på grund af en overtrædelse. At lave og opdatere forudsigelsen for den korrekte spiller var et centralt fokus for realtidsanvendeligheden af ​​modellen i udsendelser, som vi beskriver yderligere i næste afsnit.

Modeludvikling og træning

For at udvikle modellen brugte vi mere end 200,000 historiske face-off datapunkter sammen med det specialdesignede funktionssæt, der er designet i samarbejde med fageksperterne. Vi så på funktioner som situationer i spillet, historiske præstationer for spillerne, der tager face-off, spillerspecifikke karakteristika og head-to-head præstationer for spillerne, der tager face-off, både i den nuværende sæson og for deres karrierer. Tilsammen resulterede dette i over 100 funktioner skabt ved hjælp af en kombination af tilgængelige og afledte teknikker.

For at vurdere forskellige funktioner, og hvordan de kan påvirke modellen, udførte vi omfattende egenskabsanalyse som en del af den udforskende fase. Vi brugte en blanding af univariate test og multivariate test. Til multivariate test, for fortolkning, brugte vi beslutningstræ-visualiseringsteknikker. For at vurdere statistisk signifikans brugte vi Chi Test og KS test til at teste afhængighed eller distributionsforskelle.

Vi udforskede klassifikationsteknikker og modeller med forventning om, at de rå sandsynligheder ville blive behandlet som forudsigelserne. Vi udforskede nærmeste naboer, beslutningstræer, neurale netværk og også kollaborativ filtrering i form af algoritmer, mens vi prøvede forskellige samplingstrategier (filtrering, tilfældig, stratificeret og tidsbaseret prøveudtagning) og evaluerede ydeevne på Area Under the Curve (AUC) og kalibreringsfordeling sammen med Brier-scoretab. Til sidst fandt vi ud af, at LightGBM-modellen fungerede bedst med velkalibrerede nøjagtighedsmålinger.

For at evaluere modellernes ydeevne brugte vi flere teknikker. Vi brugte et testsæt, som den trænede model aldrig blev udsat for. Derudover gennemførte holdene omfattende manuelle vurderinger af resultaterne, kiggede på kantsager og forsøgte at forstå nuancerne af, hvordan modellen så ud for at afgøre, hvorfor en bestemt spiller skulle have vundet eller tabt en face-off begivenhed.

Med oplysninger indsamlet fra manuelle korrekturlæsere ville vi justere funktionerne, når det var nødvendigt, eller køre gentagelser på modellen for at se, om modellens ydeevne var som forventet.

Implementering af Face-off Probability til brug i realtid under nationale tv-udsendelser

Et af målene med projektet var ikke blot at forudsige vinderen af ​​face-off, men at bygge et fundament for at løse en række lignende problemer på en realtid og omkostningseffektiv måde. Det mål var med til at bestemme, hvilke komponenter der skulle bruges i den endelige arkitektur.

Den første vigtige komponent er Amazon Kinesis datastrømme, en serverløs streamingdatatjeneste, der fungerer som en afkobling mellem den specifikke implementering af PPT-dataudbyderen og forbrugende applikationer, og derved beskytter sidstnævnte mod forstyrrende ændringer i førstnævnte. Det har også forbedret fan-out-funktionen, som giver mulighed for at forbinde op til 20 parallelle forbrugere og opretholde en lav latenstid på 70 millisekunder og den samme gennemstrømning på 2MB/s pr. shard mellem dem alle samtidigt.

PPT-begivenheder kommer ikke for alle spillere på én gang, men ankommer diskret for hver spiller såvel som andre begivenheder i spillet. Derfor skal applikationen opretholde en tilstand for at implementere den kommende face-off-detektionsalgoritme.

Den anden vigtige komponent i arkitekturen er Amazon Kinesis Data Analytics forum Apache Flash. Apache Flink er en distribueret streaming, high-throughput, lav latens dataflow-motor, der giver en bekvem og nem måde at bruge Data Stream API på, og den understøtter stateful behandlingsfunktioner, checkpointing og parallel behandling ud af boksen. Dette hjælper med at fremskynde udviklingen og giver adgang til rutiner og komponenter på lavt niveau, hvilket giver mulighed for et fleksibelt design og implementering af applikationer.

Kinesis Data Analytics leverer den underliggende infrastruktur til dine Apache Flink-applikationer. Det eliminerer behovet for at implementere og konfigurere en Flink-klynge på Amazon Elastic Compute Cloud (Amazon EC2) eller Kubernetes, hvilket reducerer vedligeholdelsens kompleksitet og omkostninger.

Den tredje afgørende komponent er Amazon SageMaker. Selvom vi brugte SageMaker til at bygge en model, var vi også nødt til at træffe en beslutning på de tidlige stadier af projektet: skulle scoring implementeres i selve face-off-detektionsapplikationen og komplicere implementeringen, eller skulle face-off-detekteringsapplikationen kalde SageMaker eksternt og ofre noget latenstid på grund af kommunikation over netværket? For at træffe en informeret beslutning udførte vi en række benchmarks for at verificere SageMaker-latens og skalerbarhed og validerede, at den gennemsnitlige latens var mindre end 100 millisekunder under belastningen, hvilket var inden for vores forventninger.

Da hoveddelene af arkitektur på højt niveau var besluttet, begyndte vi at arbejde på det interne design af applikationen til ansigtsdetektering. En beregningsmodel af applikationen er afbildet i følgende diagram.

Beregningsmodellen for face-off-detektionsapplikationen kan modelleres som en simpel finite-state maskine, hvor hver indkommende meddelelse overfører systemet fra en tilstand til en anden, mens der udføres en vis beregning sammen med denne overgang. Applikationen vedligeholder flere datastrukturer for at holde styr på følgende:

• Ændringer i spillets tilstand – Det aktuelle periodenummer, status og værdi af spilleturet og score
• Ændringer i spillerens tilstand – Hvis spilleren i øjeblikket er på isen eller på bænken, de aktuelle koordinater på banen og den aktuelle hastighed
• Ændringer i spillerens personlige face-off statistik – Succesraten for én spiller vs. en anden, og så videre

Algoritmen kontrollerer hver placeringsopdateringshændelse for en spiller for at afgøre, om der skal laves en face-off forudsigelse, og om resultatet skal sendes til tv-stationerne. I betragtning af, at hver spillers placering opdateres cirka hvert 80. millisekund, og spillerne bevæger sig meget langsommere under spilpauser end under spillet, kan vi konkludere, at situationen mellem to opdateringer ikke ændrer sig drastisk. Hvis applikationen ringede til SageMaker for forudsigelser og sendte forudsigelser til broadcastere, hver gang en ny placeringsopdateringshændelse blev modtaget, og alle betingelser er opfyldt, ville SageMaker og broadcasterne blive overvældet med en række duplikerede anmodninger.

For at undgå al denne unødvendige støj, holder applikationen styr på en kombination af parametre, som forudsigelser allerede var lavet for, sammen med resultatet af forudsigelsen, og cacher dem i hukommelsen for at undgå dyre duplikerede anmodninger til SageMaker. Det holder også styr på, hvilke forudsigelser der allerede blev sendt til tv-selskaberne og sørger for, at kun nye forudsigelser sendes, eller at de tidligere sendte kun sendes igen, hvis det er nødvendigt. Test viste, at denne tilgang reducerer mængden af ​​udgående trafik med mere end 100 gange.

En anden optimeringsteknik, som vi brugte, var at gruppere anmodninger til SageMaker og udføre dem asynkront parallelt. For eksempel, hvis vi har fire nye kombinationer af face-off-parametre, som vi skal have forudsigelser for fra SageMaker, ved vi, at hver anmodning vil tage mindre end 100 millisekunder. Hvis vi udfører hver anmodning synkront én efter én, vil den samlede responstid være under 400 millisekunder. Men hvis vi grupperer alle fire anmodninger, sender dem asynkront og venter på resultatet for hele gruppen, før vi går videre, paralleliserer vi effektivt anmodninger, og den samlede responstid vil være under 100 millisekunder, ligesom for kun én anmodning.

Resumé

NHL Edge IQ, drevet af AWS, bringer fans tættere på handlingen med avancerede analyser og nye ML-statistikker. I dette indlæg viste vi indsigt i opbygningen og implementeringen af ​​den nye Face-off Probability-model, den første on-air ML-statistik for NHL. Sørg for at holde øje med de sandsynligheder, der genereres af Face-off Probability i kommende NHL-kampe.

Besøg Medbring din egen træningsgennemførte model med SageMaker ved at bygge en tilpasset container. For eksempler på brug Amazon Kinesis for streaming, se At lære Amazon Kinesis-udvikling.

For at lære mere om partnerskabet mellem AWS og NHL, besøg NHL innoverer med AWS Cloud Services. Hvis du gerne vil samarbejde med eksperter for at bringe ML-løsninger til din organisation, skal du kontakte Amazon ML Solutions Lab.

---

Om forfatterne

Ryan Gillespie er Sr. Data Scientist med AWS Professional Services. Han har en MSc fra Northwestern University og en MBA fra University of Toronto. Han har tidligere erfaring i detail- og mineindustrien.

Yash Shah er Science Manager i Amazon ML Solutions Lab. Han og hans team af anvendte videnskabsmænd og maskinlæringsingeniører arbejder på en række af maskinlæringsbrugssager fra sundhedspleje, sport, bilindustrien og fremstilling.

Alexander Egorov er en primær streamingarkitekt med speciale i streamingteknologier. Han hjælper organisationer med at designe og bygge platforme til behandling og analyse af streamingdata i realtid.

Miguel Romero Calvo er anvendt videnskabsmand ved Amazon ML Solutions Lab hvor han samarbejder med AWS interne teams og strategiske kunder for at accelerere deres forretning gennem ML og cloud-adoption.

Erick martinez er en Sr. Media Application Architect med 25+ års erfaring med fokus på medier og underholdning. Han har erfaring med alle aspekter af systemudviklings livscyklus lige fra opdagelse, kravindsamling, design, implementering, test, implementering og drift.