Face-off Probability, parte di NHL Edge IQ: pronosticare i vincitori del face-off in tempo reale durante le partite televisive

Face-off Probabilità è il National Hockey League (NHL) prima statistica avanzata che utilizza l'apprendimento automatico (ML) e l'intelligenza artificiale. Utilizza i dati di Player and Puck Tracking (PPT) in tempo reale per mostrare agli spettatori quale giocatore è in grado di vincere un face-off prima che il disco venga lasciato cadere e offre alle emittenti e agli spettatori l'opportunità di approfondire l'importanza degli incontri di face-off e le differenze nelle abilità dei giocatori. Sulla base di 10 anni di dati storici, centinaia di migliaia di confronti sono stati utilizzati per progettare oltre 70 funzioni inserite nel modello per fornire probabilità in tempo reale. Le emittenti possono ora discutere di come una vittoria chiave all'ingaggio di un giocatore abbia portato a un obiettivo o di come le possibilità di vincere un ingaggio diminuiscono poiché lo specialista dell'ingaggio di una squadra viene escluso dal pareggio. I fan possono vedere previsioni visive in tempo reale che mostrano loro l'importanza di una parte fondamentale del gioco.

In questo post, ci concentriamo su come è stato sviluppato il modello ML per Face-off Probability e sui servizi utilizzati per mettere in produzione il modello. Condividiamo anche le principali sfide tecniche che sono state risolte durante la costruzione del modello di probabilità di confronto.

Come funziona

Immagina il seguente scenario: è una partita di pareggio tra due squadre NHL che determinerà chi avanza. Siamo nel terzo periodo con 1:22 secondi da giocare. Due giocatori di squadre opposte si schierano per prendere il pareggio nell'ingaggio più vicino più vicino a una delle reti. Il guardalinee nota un difensore che invade il cerchio di ingaggio e rinuncia al proprio giocatore a causa della violazione. Un difensore meno esperto entra per prendere il pareggio come suo sostituto. La squadra in attacco vince l'ingaggio, prende possesso del disco e segna subito per passare in vantaggio. Il punteggio regge per il minuto rimanente di gioco e decide chi avanza. Quale giocatore era il favorito per vincere l'ingaggio prima che la coppia iniziale venisse cambiata? Quanto è diminuita la probabilità della squadra difensiva di vincere l'ingaggio a causa della violazione che ha costretto un altro giocatore a prendere il pareggio? Face-off Probability, la più recente statistica NHL Edge IQ basata su AWS, può ora rispondere a queste domande.

Quando c'è un'interruzione del gioco, Face-off Probability genera pronostici per chi vincerà il prossimo incontro in base ai giocatori sul ghiaccio, al luogo dell'ingaggio e alla situazione attuale del gioco. I pronostici vengono generati durante l'interruzione fino a quando il cronometro di gara riprende a funzionare. Le previsioni si verificano con una latenza inferiore al secondo e vengono attivate ogni volta che si verifica un cambiamento nei giocatori coinvolti nell'ingaggio.

Superare gli ostacoli chiave per la probabilità di confronto

La previsione della probabilità di confronto nelle trasmissioni in tempo reale può essere suddivisa in due sottoproblemi specifici:

• Modellazione dell'evento di confronto come un problema di machine learning, comprensione dei requisiti e dei limiti, preparazione dei dati, ingegnerizzazione dei segnali di dati, esplorazione di algoritmi e garanzia dell'affidabilità dei risultati
• Rilevare un evento di confronto durante il gioco da un flusso di eventi PPT, raccogliere i parametri necessari per la previsione, chiamare il modello e inviare i risultati alle emittenti

Prevedere la probabilità che un giocatore vinca un confronto in tempo reale su una trasmissione televisiva presenta diverse sfide tecniche che devono essere superate. Questi includevano la determinazione delle caratteristiche richieste e i metodi di modellazione per prevedere un evento che presenta una grande quantità di incertezza e la determinazione di come utilizzare lo streaming dei dati del sensore PPT per identificare dove si sta verificando un confronto, i giocatori coinvolti e la probabilità di ciascun giocatore vincere l'incontro, il tutto in centinaia di millisecondi.

Creazione di un modello ML per eventi difficili da prevedere

La previsione di eventi come le probabilità di vincita a confronto durante una partita dal vivo è un compito complesso che richiede una quantità significativa di dati storici di qualità e capacità di streaming dei dati. Per identificare e comprendere i segnali importanti in un ambiente di dati così ricco, lo sviluppo di modelli ML richiede una vasta esperienza in materia. Il Lab di Amazon Machine Learning Solutions ha collaborato con NHL hockey ed esperti di dati per lavorare a ritroso rispetto al loro obiettivo di migliorare la loro esperienza di fan. Ascoltando continuamente l'esperienza di NHL e testando le ipotesi, gli scienziati di AWS hanno progettato oltre 100 funzionalità correlate all'evento di confronto. In particolare, il team ha classificato questo insieme di funzionalità in una delle tre categorie:

• Statistiche storiche sulle prestazioni dei giocatori come il numero di ingaggi effettuati e vinti da un giocatore nelle ultime cinque stagioni, il numero di ingaggi effettuati e vinti dal giocatore nelle partite precedenti, le percentuali di vincita di un giocatore in più finestre temporali, e la percentuale di vincite testa a testa per ogni giocatore nell'ingaggio
• Caratteristiche del giocatore come altezza, peso, manualità e anni nel campionato
• Dati situazionali di gioco che potrebbero influenzare le prestazioni di un giocatore, come il punteggio della partita, il tempo trascorso nella partita fino a quel punto, dove si trova l'ingaggio, la forza di ciascuna squadra e quale giocatore deve mettere prima il loro bastone per l'ingaggio

Gli scienziati ML di AWS hanno considerato il problema come un problema di classificazione binaria: o il giocatore di casa vince l'ingaggio o il giocatore in trasferta vince l'ingaggio. Con i dati di oltre 200,000 scontri storici, hanno utilizzato a LuceGBM modello per prevedere quale dei due giocatori coinvolti in un evento di face-off ha probabilità di vincere.

Determinare se sta per verificarsi un ingaggio e quali giocatori sono coinvolti

Quando viene fischiato e il gioco viene interrotto, Face-off Probability inizia a fare pronostici. Tuttavia, la Probabilità dell'ingaggio deve prima determinare dove si sta verificando l'ingaggio e quale giocatore di ciascuna squadra è coinvolto nell'ingaggio. Il flusso di dati indica gli eventi nel momento in cui si verificano, ma non fornisce informazioni su quando è probabile che un evento si verifichi in futuro. Pertanto, i dati dei sensori dei giocatori sul ghiaccio sono necessari per determinare se e dove sta per avvenire un ingaggio.

Il sistema PPT produce posizioni e velocità in tempo reale per i giocatori sul ghiaccio fino a 60 eventi al secondo. Queste posizioni e velocità sono state utilizzate per determinare dove sta avvenendo il confronto sul ghiaccio e se è probabile che accada presto. Sapendo quanto sono vicini i giocatori alle posizioni conosciute dell'ingaggio e quanto erano fermi i giocatori, Face-off Probability è stata in grado di determinare che era probabile che si verificasse un ingaggio e i due giocatori che sarebbero stati coinvolti nell'ingaggio .

La determinazione della corretta distanza di interruzione per la vicinanza a una posizione di ingaggio e la corrispondente velocità di interruzione per i giocatori fermi è stata ottenuta utilizzando un modello di albero decisionale. Con i dati PPT della stagione 2020-2021, abbiamo costruito un modello per prevedere la probabilità che si verifichi un ingaggio in una posizione specifica, data la distanza media di ciascuna squadra dalla posizione e le velocità dei giocatori. L'albero decisionale ha fornito i limiti per ciascuna metrica, che abbiamo incluso come logica basata su regole nell'applicazione di streaming.

Con la posizione corretta dell'ingaggio determinata, il giocatore di ciascuna squadra che ha effettuato l'ingaggio è stato calcolato prendendo il giocatore più vicino alla posizione nota da ciascuna squadra. Ciò ha fornito all'applicazione la flessibilità per identificare i giocatori corretti e allo stesso tempo essere in grado di adattarsi a un nuovo giocatore che deve affrontare un ingaggio se un giocatore attuale viene escluso a causa di un'infrazione. Fare e aggiornare la previsione per il giocatore corretto era un obiettivo chiave per l'usabilità in tempo reale del modello nelle trasmissioni, che descriveremo ulteriormente nella prossima sezione.

Sviluppo e formazione del modello

Per sviluppare il modello, abbiamo utilizzato più di 200,000 punti dati storici di confronto, insieme al set di funzionalità personalizzate progettato dalla collaborazione con gli esperti in materia. Abbiamo esaminato caratteristiche come le situazioni di gioco, le prestazioni storiche dei giocatori che si sono affrontati, le caratteristiche specifiche dei giocatori e le prestazioni testa a testa dei giocatori che si sono affrontati, sia nella stagione in corso che per il loro carriere. Complessivamente, ciò ha portato a oltre 100 funzionalità create utilizzando una combinazione di tecniche disponibili e derivate.

Per valutare le diverse caratteristiche e come potrebbero influenzare il modello, abbiamo condotto un'analisi approfondita delle caratteristiche come parte della fase esplorativa. Abbiamo utilizzato un mix di test univariati e test multivariati. Per i test multivariati, per l'interpretabilità, abbiamo utilizzato tecniche di visualizzazione dell'albero decisionale. Per valutare la significatività statistica, abbiamo utilizzato i test Chi Test e KS per testare la dipendenza o le differenze di distribuzione.

Abbiamo esplorato tecniche e modelli di classificazione con l'aspettativa che le probabilità grezze sarebbero state trattate come previsioni. Abbiamo esplorato i vicini più vicini, gli alberi decisionali, le reti neurali e anche il filtraggio collaborativo in termini di algoritmi, provando diverse strategie di campionamento (filtraggio, campionamento casuale, stratificato e basato sul tempo) e valutato le prestazioni su Area Under the Curve (AUC) e distribuzione della calibrazione insieme alla perdita del punteggio di Brier. Alla fine, abbiamo scoperto che il modello LightGBM funzionava meglio con metriche di precisione ben calibrate.

Per valutare le prestazioni dei modelli, abbiamo utilizzato più tecniche. Abbiamo utilizzato un set di test a cui il modello addestrato non è mai stato esposto. Inoltre, i team hanno condotto valutazioni manuali approfondite dei risultati, esaminando i casi limite e cercando di capire le sfumature di come appariva il modello per determinare perché un determinato giocatore avrebbe dovuto vincere o perdere un evento di faccia a faccia.

Con le informazioni raccolte dai revisori manuali, regoleremmo le funzionalità quando richiesto o eseguivamo iterazioni sul modello per vedere se le prestazioni del modello erano quelle previste.

Distribuzione Face-off Probabilità per l'utilizzo in tempo reale durante le trasmissioni televisive nazionali

Uno degli obiettivi del progetto non era solo quello di prevedere il vincitore del face-off, ma di costruire una base per risolvere una serie di problemi simili in tempo reale e in modo efficiente in termini di costi. Questo obiettivo ha aiutato a determinare quali componenti utilizzare nell'architettura finale.

La prima componente importante è Flussi di dati di Amazon Kinesis, un servizio di dati in streaming serverless che funge da disaccoppiatore tra l'implementazione specifica del provider di dati PPT e le applicazioni di consumo, proteggendo così quest'ultime dai cambiamenti dirompenti del primo. Ha anche migliorato la funzione di fan-out, che offre la possibilità di collegare fino a 20 consumer in parallelo e mantenere una bassa latenza di 70 millisecondi e lo stesso throughput di 2 MB/s per shard tra tutti contemporaneamente.

Gli eventi PPT non vengono per tutti i giocatori in una volta, ma arrivano in modo discreto per ogni giocatore così come altri eventi nel gioco. Pertanto, per implementare l'imminente algoritmo di rilevamento del face-off, l'applicazione deve mantenere uno stato.

La seconda componente importante dell'architettura è Analisi dei dati di Amazon Kinesis per Apache Flink. Apache Flink è un motore di flusso di dati distribuito, ad alta velocità effettiva ea bassa latenza che fornisce un modo comodo e semplice per utilizzare l'API del flusso di dati e supporta funzioni di elaborazione con stato, checkpoint ed elaborazione parallela pronte all'uso. Ciò aiuta ad accelerare lo sviluppo e fornisce l'accesso a routine e componenti di basso livello, consentendo una progettazione e un'implementazione flessibili delle applicazioni.

Kinesis Data Analytics fornisce l'infrastruttura sottostante per le tue applicazioni Apache Flink. Elimina la necessità di distribuire e configurare un cluster Flink Cloud di calcolo elastico di Amazon (Amazon EC2) o kubernetes, che riduce la complessità ei costi di manutenzione.

La terza componente cruciale è Amazon Sage Maker. Sebbene avessimo utilizzato SageMaker per costruire un modello, dovevamo anche prendere una decisione nelle prime fasi del progetto: il punteggio dovrebbe essere implementato all'interno dell'applicazione di rilevamento del confronto stesso e complicare l'implementazione, o la chiamata dell'applicazione di rilevamento del confronto SageMaker in remoto e sacrificare un po' di latenza a causa della comunicazione sulla rete? Per prendere una decisione informata, abbiamo eseguito una serie di benchmark per verificare la latenza e la scalabilità di SageMaker e abbiamo verificato che la latenza media era inferiore a 100 millisecondi sotto carico, il che rientrava nelle nostre aspettative.

Dopo aver deciso le parti principali dell'architettura di alto livello, abbiamo iniziato a lavorare sul design interno dell'applicazione di rilevamento del face-off. Un modello di calcolo dell'applicazione è rappresentato nel diagramma seguente.

Il modello di calcolo dell'applicazione di rilevamento del face-off può essere modellato come una semplice macchina a stati finiti, in cui ogni messaggio in arrivo trasferisce il sistema da uno stato all'altro mentre esegue alcuni calcoli insieme a quella transizione. L'applicazione mantiene diverse strutture di dati per tenere traccia di quanto segue:

• Cambiamenti nello stato del gioco – Il numero del periodo corrente, lo stato e il valore del cronometro di gara e il punteggio
• Cambiamenti nello stato del giocatore – Se il giocatore è attualmente sul ghiaccio o in panchina, le coordinate attuali sul campo e la velocità attuale
• Modifiche alle statistiche di confronto personale del giocatore – La percentuale di successo di un giocatore contro un altro e così via

L'algoritmo controlla ogni evento di aggiornamento della posizione di un giocatore per decidere se fare una previsione di ingaggio e se il risultato deve essere inviato alle emittenti. Tenendo conto del fatto che la posizione di ogni giocatore viene aggiornata all'incirca ogni 80 millisecondi e che i giocatori si muovono molto più lentamente durante le pause di gioco che durante il gioco, possiamo concludere che la situazione tra due aggiornamenti non cambia drasticamente. Se l'applicazione chiamava SageMaker per le previsioni e inviava previsioni alle emittenti ogni volta che veniva ricevuto un nuovo evento di aggiornamento della posizione e tutte le condizioni sono soddisfatte, SageMaker e le emittenti sarebbero sopraffatte da una serie di richieste duplicate.

Per evitare tutto questo rumore non necessario, l'applicazione tiene traccia di una combinazione di parametri per i quali sono già state fatte previsioni, insieme al risultato della previsione, e li memorizza nella cache per evitare costose richieste duplicate a SageMaker. Inoltre, tiene traccia di quali previsioni sono state già inviate alle emittenti e si assicura che vengano inviate solo le nuove previsioni o che quelle inviate in precedenza vengano inviate nuovamente solo se necessario. I test hanno dimostrato che questo approccio riduce la quantità di traffico in uscita di oltre 100 volte.

Un'altra tecnica di ottimizzazione che abbiamo utilizzato è stata il raggruppamento delle richieste a SageMaker e l'esecuzione in parallelo in modo asincrono. Ad esempio, se abbiamo quattro nuove combinazioni di parametri di confronto per i quali dobbiamo ottenere previsioni da SageMaker, sappiamo che ogni richiesta richiederà meno di 100 millisecondi. Se eseguiamo ogni richiesta in modo sincrono uno per uno, il tempo di risposta totale sarà inferiore a 400 millisecondi. Ma se raggruppiamo tutte e quattro le richieste, le inviamo in modo asincrono e attendiamo il risultato per l'intero gruppo prima di andare avanti, parallelizziamo efficacemente le richieste e il tempo di risposta totale sarà inferiore a 100 millisecondi, proprio come per una sola richiesta.

Sommario

NHL Edge IQ, basato su AWS, avvicina i fan all'azione con analisi avanzate e nuove statistiche ML. In questo post, abbiamo mostrato approfondimenti sulla costruzione e l'implementazione del nuovo modello Face-off Probability, la prima statistica ML in onda per la NHL. Assicurati di tenere d'occhio le probabilità generate da Face-off Probability nelle prossime partite della NHL.

Per trovare esempi completi di creazione di lavori di formazione personalizzati per SageMaker, visita Porta il tuo modello completato dalla formazione con SageMaker costruendo un contenitore personalizzato. Per esempi di utilizzo Cinesi amazzonica per lo streaming, fare riferimento a Imparare lo sviluppo della cinesi di Amazon.

Per saperne di più sulla partnership tra AWS e NHL, visita NHL innova con i servizi cloud AWS. Se desideri collaborare con esperti per portare soluzioni di machine learning nella tua organizzazione, contatta il Laboratorio di soluzioni Amazon ML.

---

Informazioni sugli autori

Ryan Gillespie è un Sr. Data Scientist con AWS Professional Services. Ha un Master presso la Northwestern University e un MBA presso l'Università di Toronto. Ha precedenti esperienze nel settore della vendita al dettaglio e minerario.

Yash Shah è un Science Manager nel Laboratorio di soluzioni Amazon ML. Lui e il suo team di scienziati applicati e ingegneri dell'apprendimento automatico lavorano su una gamma di casi d'uso dell'apprendimento automatico nel settore sanitario, sportivo, automobilistico e manifatturiero.

Aleksandr Egorov è un Principal Streaming Architect, specializzato in tecnologie di streaming. Aiuta le organizzazioni a progettare e costruire piattaforme per l'elaborazione e l'analisi dei dati in streaming in tempo reale.

Miguel Romero Calvo è Scienziato Applicato presso il Laboratorio di soluzioni Amazon ML dove collabora con i team interni di AWS e i clienti strategici per accelerare il loro business attraverso l'adozione di ML e cloud.

Erick martinez è un Sr. Media Application Architect con oltre 25 anni di esperienza, con particolare attenzione ai media e all'intrattenimento. Ha esperienza in tutti gli aspetti del ciclo di vita dello sviluppo dei sistemi che vanno dalla scoperta, alla raccolta dei requisiti, alla progettazione, all'implementazione, al test, all'implementazione e al funzionamento.