Zephyrnet-logo

Face-off Probability, en del av NHL Edge IQ: Forutsi face-off-vinnere i sanntid under TV-spill

Dato:

Face-off Sannsynlighet er National Hockey League (NHL) første avanserte statistikk ved bruk av maskinlæring (ML) og kunstig intelligens. Den bruker spiller- og pucksporingsdata (PPT) i sanntid for å vise seerne hvilken spiller som sannsynligvis vil vinne en face-off før pucken slippes, og gir kringkastere og seere muligheten til å dykke dypere inn i viktigheten av face-off-kamper og forskjellene i spillerens evner. Basert på 10 år med historiske data, ble hundretusenvis av face-offs brukt til å konstruere over 70 funksjoner matet inn i modellen for å gi sanntidssannsynligheter. Kringkastere kan nå diskutere hvordan en viktig seier fra en spiller førte til et mål, eller hvordan sjansene for å vinne en avrunding reduseres når et lags spesialist i ansikt-av-kampen fravikes uavgjort. Fans kan se visuelle spådommer i sanntid som viser dem viktigheten av en viktig del av spillet.

I dette innlegget fokuserer vi på hvordan ML-modellen for Face-off Probability ble utviklet og tjenestene som ble brukt for å sette modellen i produksjon. Vi deler også de viktigste tekniske utfordringene som ble løst under konstruksjonen av Face-off Probability-modellen.

Hvordan fungerer det

Tenk deg følgende scenario: Det er en uavgjort kamp mellom to NHL-lag som avgjør hvem som går videre. Vi er inne i tredje periode med 1:22 sekunder igjen å spille. To spillere fra motsatte lag stiller opp for å ta uavgjort i nærmeste face-off nærmere ett av nettene. Linjedommeren legger merke til en forsvarsspiller som trer inn i face-off-sirkelen og fraskriver seg spilleren sin fra face-off på grunn av bruddet. En mindre erfaren forsvarsspiller kommer inn for å ta uavgjort som erstatter. Det angripende laget vinner face-off, får besittelse av pucken og scorer umiddelbart for å ta ledelsen. Scoringen holder seg i det gjenværende minuttet av kampen og avgjør hvem som går videre. Hvilken spiller ble favorisert til å vinne face-off før den første duoen ble endret? Hvor mye reduserte det defensive lagets sannsynlighet for å vinne face-off av bruddet som tvang en annen spiller til å ta uavgjort? Face-off Probability, den nyeste NHL Edge IQ-statistikken drevet av AWS, kan nå svare på disse spørsmålene.

Når det er stopp i spillet, genererer Face-off Probability spådommer for hvem som vil vinne den kommende face-off basert på spillerne på isen, plasseringen av face-off og den nåværende kampsituasjonen. Spådommene genereres gjennom hele pausen til kampklokken begynner å gå igjen. Forutsigelser oppstår med forsinkelser på mindre enn sekunder og utløses hver gang det er en endring i spillerne som er involvert i face-off.

Et NHL-skudd fra toppen

Overvinne viktige hindringer for ansiktssannsynlighet

Å forutsi ansiktssannsynlighet i sanntidssendinger kan deles inn i to spesifikke underproblemer:

  • Modellere ansiktshendelsen som et ML-problem, forstå kravene og begrensningene, forberede dataene, konstruere datasignalene, utforske algoritmer og sikre påliteligheten til resultatene
  • Oppdage en face-off-hendelse under spillet fra en strøm av PPT-hendelser, samle parametere som trengs for prediksjon, ringe modellen og sende resultater til kringkastere

Å forutsi sannsynligheten for at en spiller vinner en face-off i sanntid på en TV-sending har flere tekniske utfordringer som måtte overvinnes. Disse inkluderte å bestemme funksjonene som kreves og modelleringsmetoder for å forutsi en hendelse som har en stor mengde usikkerhet, og å bestemme hvordan man bruker streaming PPT-sensordata for å identifisere hvor en face-off finner sted, aktørene som er involvert, og sannsynligheten for hver spiller vinne face-off, alt innen hundrevis av millisekunder.

Spillere som klemmer seg sammen i et bilde av en Faceoff under en kamp

Bygge en ML-modell for vanskelig å forutsi hendelser

Å forutsi hendelser som for eksempel vinnersannsynligheter under et livespill er en kompleks oppgave som krever en betydelig mengde historiske data og datastrømming av høy kvalitet. For å identifisere og forstå de viktige signalene i et så rikt datamiljø, krever utviklingen av ML-modeller omfattende fagkompetanse. De Amazon Machine Learning Solutions Lab samarbeidet med NHL-hockey og dataeksperter for å jobbe bakover fra målet om å forbedre fanopplevelsen. Ved kontinuerlig å lytte til NHLs ekspertise og teste hypoteser, konstruerte AWSs forskere over 100 funksjoner som korrelerer med face-off-hendelsen. Spesielt klassifiserte teamet dette funksjonssettet i en av tre kategorier:

  • Historisk statistikk over spillerprestasjoner som antall face-offs en spiller har tatt og vunnet de siste fem sesongene, antall face-offs spilleren har tatt og vunnet i tidligere kamper, en spillers vinnerprosent over flere tidsvinduer, og head-to-head vinnerprosenten for hver spiller i face-off
  • Spillerkarakteristikker som høyde, vekt, handedness og år i ligaen
  • Situasjonsdata i spillet som kan påvirke en spillers prestasjoner, for eksempel spillets poengsum, medgått tid i spillet til det punktet, hvor avslutningen er plassert, styrken til hvert lag og hvilken spiller som må sette stokken deres ned for face-off først

AWSs ML-forskere betraktet problemet som et binært klassifiseringsproblem: enten vinner hjemmespilleren face-off eller bortespilleren vinner face-off. Med data fra mer enn 200,000 XNUMX historiske face-offs brukte de en LightGBM modell for å forutsi hvilken av de to spillerne som er involvert i en face-off-begivenhet som sannsynligvis vil vinne.

Avgjøre om en face-off er i ferd med å skje og hvilke spillere som er involvert

Når en fløyte går og spillet stoppes, begynner Face-off Probability å gi spådommer. Imidlertid må Face-off Probability først bestemme hvor face-off skjer og hvilken spiller fra hvert lag som er involvert i face-off. Datastrømmen indikerer hendelser når de oppstår, men gir ikke informasjon om når en hendelse sannsynligvis vil inntreffe i fremtiden. Som sådan er sensordataene til spillerne på isen nødvendig for å avgjøre om og hvor en face-off er i ferd med å skje.

PPT-systemet produserer sanntidsplasseringer og hastigheter for spillere på isen med opptil 60 hendelser per sekund. Disse stedene og hastighetene ble brukt til å bestemme hvor ansiktet skjer på isen og om det er sannsynlig at det vil skje snart. Ved å vite hvor nær spillerne er kjente ansikt-off-plasseringer og hvor stasjonære spillerne var, kunne Face-off Probability fastslå at en face-off var sannsynlig å finne sted og de to spillerne som ville være involvert i face-off .

Bestemmelse av riktig avskjæringsavstand for nærhet til et avskjæringssted og tilsvarende avskjæringshastighet for stasjonære spillere ble oppnådd ved å bruke en beslutningstremodell. Med PPT-data fra sesongen 2020-2021 bygde vi en modell for å forutsi sannsynligheten for at en face-off finner sted på et spesifisert sted gitt den gjennomsnittlige avstanden til hvert lag til plasseringen og hastighetene til spillerne. Beslutningstreet ga avskjæringsgrensene for hver beregning, som vi inkluderte som regelbasert logikk i strømmeapplikasjonen.

Med den riktige face-off-posisjonen bestemt, ble spilleren fra hvert lag som tok face-off beregnet ved å ta spilleren nærmest den kjente plasseringen fra hvert lag. Dette ga applikasjonen fleksibiliteten til å identifisere de riktige spillerne, samtidig som den kunne tilpasse seg en ny spiller som måtte ta en face-off hvis en nåværende spiller blir frafalt på grunn av et brudd. Å lage og oppdatere prediksjonen for riktig spiller var et sentralt fokus for sanntidsbrukbarheten til modellen i sendinger, som vi beskriver videre i neste avsnitt.

Modellutvikling og opplæring

For å utvikle modellen brukte vi mer enn 200,000 100 historiske face-off datapunkter, sammen med det spesialkonstruerte funksjonssettet designet av samarbeid med fagekspertene. Vi har sett på funksjoner som situasjoner i spillet, historisk prestasjon til spillerne som tar face-off, spillerspesifikke egenskaper og head-to-head prestasjoner til spillerne som tar face-off, både i inneværende sesong og for deres karrierer. Til sammen resulterte dette i over XNUMX funksjoner laget ved hjelp av en kombinasjon av tilgjengelige og avledede teknikker.

For å vurdere ulike funksjoner og hvordan de kan påvirke modellen, gjennomførte vi omfattende funksjonsanalyse som en del av den utforskende fasen. Vi brukte en blanding av univariate tester og multivariate tester. For multivariate tester, for tolkbarhet, brukte vi visualiseringsteknikker for beslutningstre. For å vurdere statistisk signifikans brukte vi Chi Test og KS tester for å teste avhengighet eller distribusjonsforskjeller.

Et beslutningstre som viser hvordan modellen estimerer basert på de underliggende dataene og funksjonene

Vi utforsket klassifiseringsteknikker og modeller med forventning om at de rå sannsynlighetene ville bli behandlet som prediksjonene. Vi utforsket nærmeste naboer, beslutningstrær, nevrale nettverk, og også samarbeidsfiltrering når det gjelder algoritmer, mens vi prøvde forskjellige samplingsstrategier (filtrering, tilfeldig, stratifisert og tidsbasert sampling) og evaluerte ytelse på Area Under the Curve (AUC) og kalibreringsfordeling sammen med Brier-poengstap. På slutten fant vi ut at LightGBM-modellen fungerte best med godt kalibrerte nøyaktighetsmålinger.

For å evaluere ytelsen til modellene brukte vi flere teknikker. Vi brukte et testsett som den trente modellen aldri ble utsatt for. I tillegg gjennomførte lagene omfattende manuelle vurderinger av resultatene, så på kantsaker og forsøkte å forstå nyansene i hvordan modellen så ut for å avgjøre hvorfor en bestemt spiller skulle ha vunnet eller tapt en face-off-begivenhet.

Med informasjon samlet inn fra manuelle anmeldere, ville vi justere funksjonene når det var nødvendig, eller kjøre iterasjoner på modellen for å se om ytelsen til modellen var som forventet.

Utplassere Face-off Probability for sanntidsbruk under nasjonale TV-sendinger

Et av målene med prosjektet var ikke bare å forutsi vinneren av face-off, men å bygge et grunnlag for å løse en rekke lignende problemer på en sanntids- og kostnadseffektiv måte. Dette målet var med på å bestemme hvilke komponenter som skulle brukes i den endelige arkitekturen.

arkitekturdiagram for faceoff-applikasjon

Den første viktige komponenten er Amazon Kinesis datastrømmer, en serverløs strømmedatatjeneste som fungerer som en frakobling mellom den spesifikke implementeringen av PPT-dataleverandøren og forbrukende applikasjoner, og beskytter derved sistnevnte fra forstyrrende endringer i førstnevnte. Den har også forbedret fan-out-funksjonen, som gir muligheten til å koble til opptil 20 parallelle forbrukere og opprettholde en lav ventetid på 70 millisekunder og samme gjennomstrømning på 2MB/s per shard mellom dem alle samtidig.

PPT-arrangementer kommer ikke for alle spillere samtidig, men kommer diskret for hver spiller så vel som andre hendelser i spillet. Derfor, for å implementere den kommende face-off-deteksjonsalgoritmen, må applikasjonen opprettholde en tilstand.

Den andre viktige komponenten i arkitekturen er Amazon Kinesis Data Analytics forum Apache Flash. Apache Flink er en distribuert strømming, høy-gjennomstrømning, lav latens dataflytmotor som gir en praktisk og enkel måte å bruke Data Stream API på, og den støtter stateful prosesseringsfunksjoner, sjekkpunkt og parallell behandling ut av esken. Dette bidrar til å fremskynde utviklingen og gir tilgang til rutiner og komponenter på lavt nivå, noe som gir mulighet for fleksibel design og implementering av applikasjoner.

Kinesis Data Analytics gir den underliggende infrastrukturen for dine Apache Flink-applikasjoner. Det eliminerer behovet for å distribuere og konfigurere en Flink-klynge på Amazon Elastic Compute Cloud (Amazon EC2) eller Kubernetes, som reduserer vedlikeholdets kompleksitet og kostnader.

Den tredje avgjørende komponenten er Amazon SageMaker. Selv om vi brukte SageMaker til å bygge en modell, trengte vi også å ta en avgjørelse i de tidlige stadiene av prosjektet: bør poengsummen implementeres i selve applikasjonen for ansiktsdeteksjon og komplisere implementeringen, eller skal den avskjærende applikasjonen kalle SageMaker eksternt og ofre litt ventetid på grunn av kommunikasjon over nettverket? For å ta en informert avgjørelse utførte vi en rekke benchmarks for å verifisere SageMaker-latens og skalerbarhet, og validerte at gjennomsnittlig ventetid var mindre enn 100 millisekunder under belastningen, noe som var innenfor våre forventninger.

Da hoveddelene av arkitektur på høyt nivå var bestemt, begynte vi å jobbe med den interne utformingen av applikasjonen for ansiktsdeteksjon. En beregningsmodell av applikasjonen er avbildet i følgende diagram.

et diagram som representerer flytskjemaet/beregningsmodellen til faceoff-applikasjonen

Beregningsmodellen til face-off-deteksjonsapplikasjonen kan modelleres som en enkel finite-state maskin, der hver innkommende melding overfører systemet fra en tilstand til en annen mens den utfører en viss beregning sammen med den overgangen. Applikasjonen opprettholder flere datastrukturer for å holde styr på følgende:

  • Endringer i spilltilstanden – Nåværende periodenummer, status og verdi på kampklokken og poengsum
  • Endringer i spillerens tilstand – Hvis spilleren for øyeblikket er på isen eller på benken, gjeldende koordinater på banen, og gjeldende hastighet
  • Endringer i spillerens personlige face-off-statistikk – Suksessraten til én spiller kontra en annen, og så videre

Algoritmen sjekker hver posisjonsoppdateringshendelse for en spiller for å avgjøre om en face-off-prediksjon skal gjøres og om resultatet skal sendes til kringkastere. Ta i betraktning at hver spillerplassering oppdateres omtrent hvert 80. millisekund og spillere beveger seg mye saktere under pauser enn under spillet, kan vi konkludere med at situasjonen mellom to oppdateringer ikke endres drastisk. Hvis applikasjonen ringte SageMaker for spådommer og sendte spådommer til kringkastere hver gang en ny plasseringsoppdatering ble mottatt og alle betingelser er oppfylt, ville SageMaker og kringkasterne bli overveldet med en rekke duplikatforespørsler.

For å unngå all denne unødvendige støyen, holder applikasjonen styr på en kombinasjon av parametere som det allerede er gjort spådommer for, sammen med resultatet av prediksjonen, og cacher dem i minnet for å unngå dyre duplikatforespørsler til SageMaker. Den holder også styr på hvilke spådommer som allerede ble sendt til kringkastere, og sørger for at bare nye spådommer sendes eller at de tidligere sendte bare sendes på nytt hvis det er nødvendig. Testing viste at denne tilnærmingen reduserer mengden utgående trafikk med mer enn 100 ganger.

En annen optimaliseringsteknikk som vi brukte var å gruppere forespørsler til SageMaker og utføre dem asynkront parallelt. For eksempel, hvis vi har fire nye kombinasjoner av face-off-parametere som vi trenger å få spådommer for fra SageMaker, vet vi at hver forespørsel vil ta mindre enn 100 millisekunder. Hvis vi utfører hver forespørsel synkront én etter én, vil den totale responstiden være under 400 millisekunder. Men hvis vi grupperer alle fire forespørslene, sender dem asynkront og venter på resultatet for hele gruppen før vi går videre, parallelliserer vi effektivt forespørsler og den totale responstiden vil være under 100 millisekunder, akkurat som for bare én forespørsel.

Oppsummering

NHL Edge IQ, drevet av AWS, bringer fansen nærmere handlingen med avanserte analyser og ny ML-statistikk. I dette innlegget viste vi innsikt i byggingen og distribusjonen av den nye Face-off Probability-modellen, den første on-air ML-statistikken for NHL. Sørg for å holde øye med sannsynlighetene generert av Face-off Probability i kommende NHL-kamper.

For å finne fullstendige eksempler på å bygge tilpassede opplæringsjobber for SageMaker, besøk Ta med din egen treningsfullførte modell med SageMaker ved å bygge en tilpasset container. For eksempler på bruk Amazon Kinesis for streaming, se Lære Amazon Kinesis-utvikling.

For å lære mer om partnerskapet mellom AWS og NHL, besøk NHL innoverer med AWS Cloud Services. Hvis du ønsker å samarbeide med eksperter for å bringe ML-løsninger til organisasjonen din, ta kontakt med Amazon ML Solutions Lab.


Om forfatterne

Ryan Gillespie er en 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 fra detaljhandel og gruveindustrien.

Yash Shah er Science Manager i Amazon ML Solutions Lab. Han og teamet hans av anvendte forskere og maskinlæringsingeniører jobber med en rekke brukstilfeller for maskinlæring fra helsevesen, sport, bil og produksjon.

Alexander Egorov er en hovedstrømmearkitekt, som spesialiserer seg på strømmeteknologier. Han hjelper organisasjoner med å designe og bygge plattformer for behandling og analyse av strømmedata i sanntid.

Miguel Romero Calvo er en anvendt vitenskapsmann ved Amazon ML Solutions Lab hvor han samarbeider med AWS interne team og strategiske kunder for å akselerere virksomheten deres gjennom ML og skyadopsjon.

Erick martinez er en senior medieapplikasjonsarkitekt med 25+ års erfaring, med fokus på media og underholdning. Han har erfaring med alle aspekter av systemutviklings livssyklus, fra oppdagelse, kravinnsamling, design, implementering, testing, distribusjon og drift.

spot_img

Siste etterretning

spot_img