Becsapások valószínűsége, az NHL Edge IQ része: Valós időben megjósolni a mérkőzés győzteseit a televíziós meccseken

A szembenézés valószínűsége az Nemzeti Jégkorong Liga (NHL) az első fejlett statisztika gépi tanulást (ML) és mesterséges intelligenciát használva. Valós idejű játékos- és korongkövetési (PPT) adatok segítségével megmutatja a nézőknek, hogy valószínűleg melyik játékos nyeri meg a bedobást, mielőtt a korongot eldobják, és lehetőséget ad a műsorszolgáltatóknak és a nézőknek, hogy mélyebben elmerüljenek a bedobások fontosságában. és a játékosok képességeinek különbségei. 10 éves múltbeli adatok alapján több százezer szembeállítást használtak a modellbe betáplált több mint 70 jellemző tervezésére, hogy valós idejű valószínűségeket biztosítsanak. A műsorszolgáltatók most megvitathatják, hogy egy játékos kulcsfontosságú bedobós győzelme hogyan vezetett gólhoz, vagy hogyan csökken a bedobás megnyerésének esélye, mivel a csapat bedobás specialistája döntetlenre kerül. A rajongók vizuális, valós idejű előrejelzéseket láthatnak, amelyek megmutatják számukra a játék kulcsfontosságú részének fontosságát.

Ebben a bejegyzésben arra összpontosítunk, hogyan fejlesztették ki a Face-off Probability ML-modelljét, és milyen szolgáltatásokkal állították elő a modellt. Megosztjuk azokat a kulcsfontosságú technikai kihívásokat is, amelyeket a Face-off Probability modell felépítése során megoldottak.

Hogyan működik?

Képzelje el a következő forgatókönyvet: Két NHL-csapat döntetlen mérkőzése határozza meg, hogy ki jut tovább. A harmadik harmadnál járunk, 1:22 másodperc van hátra a játékból. Az ellentétes csapatok két játékosa felsorakozik, hogy a legközelebbi összecsapásban döntsön az egyik hálóhoz közelebb. A vonalbíró észreveszi, hogy egy védekező játékos behatol a bedobó körbe, és a szabálysértés miatt elengedi játékosát a bedobásból. Egy kevésbé tapasztalt védekező játékos csereként beáll a döntetlenre. A támadó csapat megnyeri a bedobást, birtokba veszi a korongot, és azonnal gólt szerez, ezzel megszerezve a vezetést. Az eredmény a játékból hátralévő percben kitart, és eldönti, hogy ki jut tovább. Melyik játékos nyerte meg a bedobást, mielőtt a kezdeti duót megváltoztatták? Mennyivel csökkent a védő csapatának esélye a bedobás megnyerésére az a szabálysértés, amely egy másik játékost kényszerített a döntetlenre? A Face-off Probability, az AWS által üzemeltetett legújabb NHL Edge IQ statisztika most választ ad ezekre a kérdésekre.

Ha játékleállás van, a Face-off Probability előrejelzéseket generál arra vonatkozóan, hogy ki nyeri a soron következő bedobást a jégen lévő játékosok, a bedobás helye és az aktuális játékhelyzet alapján. Az előrejelzések a leállás során generálódnak, amíg a játékóra újra el nem indul. A jóslatok a másodperc alatti késleltetéssel történnek, és minden alkalommal aktiválódnak, amikor változás történik a bedobásban részt vevő játékosok között.

A legfontosabb akadályok leküzdése a szembenézés valószínűsége érdekében

A valós idejű adások szembeállítási valószínűségének előrejelzése két konkrét részproblémára bontható:

• A szembenézés esemény modellezése ML problémaként, a követelmények és korlátok megértése, az adatok előkészítése, az adatjelek tervezése, az algoritmusok feltárása és az eredmények megbízhatóságának biztosítása
• Egy szembeforduló esemény észlelése a játék során a PPT események folyamából, az előrejelzéshez szükséges paraméterek összegyűjtése, a modell lehívása és az eredmények elküldése a műsorszolgáltatóknak

Annak a valószínűsége, hogy egy játékos valós időben nyer egy bedobást egy televíziós adásban, számos technikai kihívással jár, amelyeket le kellett küzdeni. Ezek közé tartozott a szükséges jellemzők és modellezési módszerek meghatározása egy nagy bizonytalansággal járó esemény előrejelzéséhez, valamint annak meghatározása, hogyan lehet a streaming PPT érzékelőadatokat felhasználni annak meghatározására, hogy hol történik a szembenézés, az érintett játékosok és az egyes játékosok valószínűsége. megnyerni a szembenézést, mindezt több száz ezredmásodperc alatt.

ML modell felépítése nehezen megjósolható eseményekhez

Az olyan események előrejelzése, mint például a nyerési valószínűségek egy élő játék során, összetett feladat, amely jelentős mennyiségű minőségi előzményadatot és adatfolyam-képességet igényel. A fontos jelek azonosítása és megértése egy ilyen gazdag adatkörnyezetben az ML-modellek fejlesztése kiterjedt szakértelmet igényel. Az Amazon Machine Learning Solutions Lab együttműködtek az NHL jégkorong- és adatszakértőivel, hogy visszafelé dolgozzanak a kitűzött céltól, vagyis a szurkolói élmény fokozásától. Folyamatosan hallgatva az NHL szakértelmét és tesztelve a hipotéziseket, az AWS tudósai több mint 100 olyan funkciót fejlesztettek ki, amelyek összefüggésben állnak a szembenézés eseménnyel. A csapat ezt a funkciókészletet a három kategória egyikébe sorolta:

• Történelmi statisztikák a játékosok teljesítményéről, mint például a bedobások száma, amelyeket egy játékos az elmúlt öt szezonban szerzett és megnyert, a játékos által az előző meccseken végrehajtott és megnyert bedobások száma, egy játékos győzelmi százaléka több időablakban, és a bedobásban részt vevő játékosok fej-fej közötti győzelmi százaléka
• A játékos jellemzői, mint például a magasság, a súly, a kezesség és a bajnokságban eltöltött évek
• Játékon belüli szituációs adatok, amelyek befolyásolhatják a játékos teljesítményét, például a játék pontszáma, a játékban addig a pontig eltelt idő, a bedobás helye, az egyes csapatok ereje, és hogy melyik játékosnak kell elhelyeznie a botjukat először a szembenézéshez

Az AWS ML tudósai bináris besorolási problémának tekintették a problémát: vagy a hazai játékos nyeri a bedobást, vagy a vendégjátékos nyeri a bedobást. Több mint 200,000 XNUMX történelmi szembenézés adatai alapján a LightGBM modell, amely megjósolja, hogy a bedobásos eseményben részt vevő két játékos közül valószínűleg melyik nyer.

Annak meghatározása, hogy sor kerül-e bedobásra, és mely játékosok vesznek részt benne

Amikor sípszó hallatszik, és a játék leáll, a Face-off Probability jóslatokba kezd. A bedobás valószínűségének azonban először meg kell határoznia, hogy hol történik a bedobás, és az egyes csapatokból melyik játékos vesz részt a bedobásban. Az adatfolyam a bekövetkezésükkor jelzi az eseményeket, de nem ad információt arról, hogy egy esemény a jövőben várhatóan mikor fog bekövetkezni. Mint ilyen, a jégen lévő játékosok szenzoradatai szükségesek ahhoz, hogy meghatározzák, hol és hol kerül sor a bedobásra.

A PPT rendszer valós idejű helyszíneket és sebességeket állít elő a jégen lévő játékosok számára, akár 60 esemény/másodperc sebességgel. Ezeket a helyeket és sebességeket használták fel annak meghatározására, hogy hol történik a becsapódás a jégen, és várható-e hamarosan. Annak ismeretében, hogy a játékosok milyen közel vannak az ismert bedobási helyekhez, és mennyire mozdulatlanok a játékosok, a bedobás valószínűsége meg tudta állapítani, hogy valószínűleg bedobásra kerül sor, és azt a két játékost, akik részt vesznek a bedobásban. .

Döntési fa modell segítségével határoztuk meg a helyes vágási távolságot a szembeforduló helyhez való közelséghez és a megfelelő vágási sebességet álló játékosok számára. A 2020-2021-es szezon PPT-adatai alapján felépítettünk egy modellt, amely megjósolja annak valószínűségét, hogy egy meghatározott helyen bedobásra kerül sor, figyelembe véve az egyes csapatok átlagos távolságát a helyszíntől és a játékosok sebességét. A döntési fa megadta az egyes metrikák határértékeit, amelyeket szabályalapú logikaként beépítettünk a streaming alkalmazásba.

A helyes bedobási hely meghatározása után minden csapatból a bedobást végző játékost úgy számították ki, hogy minden csapatból kivették az ismert helyhez legközelebb eső játékost. Ez rugalmasságot biztosított az alkalmazásnak, hogy azonosítsa a megfelelő játékosokat, miközben képes volt alkalmazkodni ahhoz is, hogy egy új játékosnak be kell néznie, ha egy jelenlegi játékost szabálysértés miatt kihagynak. A modell adásokban való valós idejű használhatósága szempontjából kulcsfontosságú volt a megfelelő játékosra vonatkozó előrejelzés elkészítése és frissítése, amelyet a következő részben részletesebben ismertetünk.

Modellfejlesztés és képzés

A modell kifejlesztéséhez több mint 200,000 100 történelmi szembefordulási adatpontot használtunk, valamint a téma szakértőivel együttműködve kialakított egyedi tervezésű funkciókészletet. Olyan jellemzőket vizsgáltunk, mint a játékon belüli helyzetek, a bedobó játékosok történelmi teljesítménye, a játékos-specifikus jellemzők és a bedobó játékosok fej-fej melletti teljesítménye, mind az aktuális szezonban, mind pedig a saját szezonban. karrierek. Összességében ez több mint XNUMX funkciót eredményezett, amelyeket a rendelkezésre álló és a származtatott technikák kombinációjával hoztak létre.

Annak érdekében, hogy felmérjük a különböző jellemzőket, és hogyan befolyásolhatják a modellt, a feltáró szakasz részeként kiterjedt jellemzőelemzést végeztünk. Egyváltozós tesztek és többváltozós tesztek keverékét alkalmaztuk. A többváltozós tesztekhez az értelmezhetőség érdekében döntési fa vizualizációs technikákat alkalmaztunk. A statisztikai szignifikancia értékeléséhez Chi-tesztet és KS-tesztet használtunk a függőség vagy eloszlási különbségek tesztelésére.

Osztályozási technikákat és modelleket vizsgáltunk meg azzal a várakozással, hogy a nyers valószínűségeket előrejelzésként kezeljük. Feltérképeztük a legközelebbi szomszédokat, a döntési fákat, a neurális hálózatokat, valamint az algoritmusok szempontjából a kollaboratív szűrést, miközben különböző mintavételi stratégiákat (szűrés, véletlenszerű, rétegzett és időalapú mintavétel) próbáltunk ki, és értékeltük a görbe alatti terület (AUC) teljesítményét. kalibrációs eloszlás a Brier-pontveszteséggel együtt. Végül azt találtuk, hogy a LightGBM modell jól kalibrált pontossági mérőszámokkal működik a legjobban.

A modellek teljesítményének értékeléséhez többféle technikát alkalmaztunk. Olyan tesztkészletet használtunk, amellyel a betanított modell soha nem volt kitéve. Ezenkívül a csapatok kiterjedt manuális értékelést végeztek az eredményekről, megvizsgálva az éles eseteket, és megpróbálták megérteni a modell kinézetének árnyalatait, hogy meghatározzák, miért kellett volna egy bizonyos játékosnak nyernie vagy elveszítenie egy bedobásos eseményt.

A kézi ellenőröktől gyűjtött információk alapján szükség esetén módosítjuk a funkciókat, vagy iterációkat futtatunk a modellen, hogy megnézzük, a modell teljesítménye megfelel-e az elvárásoknak.

Face-off Probality telepítése valós idejű használathoz országos televíziós adások során

A projekt egyik célja nem csupán az volt, hogy megjósolja a szembenézés győztesét, hanem az is, hogy alapot teremtsen számos hasonló probléma valós idejű és költséghatékony megoldásához. Ez a cél segített meghatározni, hogy mely összetevőket kell használni a végső architektúrában.

Az első fontos összetevő az Amazon Kinesis adatfolyamok, egy szerver nélküli streaming adatszolgáltatás, amely szétválasztóként működik a PPT adatszolgáltató konkrét megvalósítása és a fogyasztó alkalmazások között, ezzel védve az utóbbiakat az előbbi zavaró változásaitól. Továbbfejlesztette a fan-out funkciót is, amely lehetővé teszi akár 20 párhuzamos fogyasztó csatlakoztatását, és alacsony, 70 ezredmásodperces késleltetést és ugyanazt a 2 MB/s-os átviteli sebességet mindegyik között egyidejűleg.

A PPT események nem jönnek egyszerre minden játékos számára, hanem diszkréten érkeznek mindegyik játékoshoz, valamint a játék egyéb eseményeihez. Ezért a közelgő szembenézés-észlelési algoritmus megvalósításához az alkalmazásnak fenn kell tartania egy állapotot.

Az építészet második fontos összetevője az Amazon Kinesis Data Analytics mert Apache Flash. Az Apache Flink egy elosztott streaming, nagy áteresztőképességű, alacsony késleltetésű adatfolyam-motor, amely kényelmes és egyszerű módot biztosít a Data Stream API használatára, és támogatja az állapotalapú feldolgozási funkciókat, az ellenőrzőpontozást és a párhuzamos feldolgozást. Ez felgyorsítja a fejlesztést, és hozzáférést biztosít az alacsony szintű rutinokhoz és komponensekhez, ami lehetővé teszi az alkalmazások rugalmas tervezését és megvalósítását.

A Kinesis Data Analytics biztosítja az alapul szolgáló infrastruktúrát az Apache Flink alkalmazásaihoz. Kiküszöböli a Flink-fürt üzembe helyezésének és konfigurálásának szükségességét Amazon rugalmas számítási felhő (Amazon EC2) ill Kubernetes, ami csökkenti a karbantartás bonyolultságát és költségeit.

A harmadik döntő összetevő az Amazon SageMaker. Bár a SageMaker-t használtuk a modell felépítéséhez, a projekt korai szakaszában döntést is kellett hoznunk: a pontozást magán a szembefordulást észlelő alkalmazáson belül kell megvalósítani, és ez bonyolítja az implementációt, vagy hívja-e a szembenézést észlelő alkalmazást. SageMaker távolról, és feláldozni némi késleltetést a hálózaton keresztüli kommunikáció miatt? Ahhoz, hogy megalapozott döntést hozhassunk, egy sor benchmarkot hajtottunk végre a SageMaker késleltetésének és méretezhetőségének ellenőrzésére, és ellenőriztük, hogy az átlagos várakozási idő kevesebb, mint 100 ezredmásodperc a terhelés alatt, ami megfelelt az elvárásainknak.

A magas szintű architektúra főbb részeinek elhatározása után elkezdtünk dolgozni az arcfelismerő alkalmazás belső kialakításán. Az alkalmazás számítási modelljét a következő ábra mutatja be.

A face-off detektáló alkalmazás számítási modellje egyszerű véges állapotú gépként modellezhető, ahol minden bejövő üzenet átállítja a rendszert egyik állapotból a másikba, miközben az átmenettel együtt némi számítást is végez. Az alkalmazás számos adatstruktúrát tart fenn a következők nyomon követésére:

• Változások a játék állapotában – Az aktuális időszak száma, a játékóra állapota és értéke, valamint a pontszám
• Változások a játékos állapotában – Ha a játékos éppen a jégen vagy a padon van, akkor az aktuális koordináták a pályán és az aktuális sebesség
• Változások a játékos személyes bedobási statisztikájában – Az egyik játékos sikeraránya a másikkal szemben, és így tovább

Az algoritmus minden egyes játékos helyfrissítési eseményét ellenőrzi, hogy eldöntse, kell-e előrejelzést készíteni, és az eredményt el kell-e küldeni a műsorszolgáltatóknak. Figyelembe véve, hogy minden játékos hely nagyjából 80 ezredmásodpercenként frissül, és a játékosok sokkal lassabban mozognak a játék szüneteiben, mint játék közben, megállapíthatjuk, hogy a két frissítés közötti helyzet nem változik drasztikusan. Ha az alkalmazás a SageMaker-t előrejelzésekhez hívná, és előrejelzéseket küldene a műsorszolgáltatóknak minden alkalommal, amikor új helyfrissítési esemény érkezik, és minden feltétel teljesül, a SageMaker és a műsorszolgáltatók több ismétlődő kéréssel lennének elárasztva.

Mindezen szükségtelen zajok elkerülése érdekében az alkalmazás nyomon követi azon paraméterek kombinációját, amelyekre vonatkozóan már készültek előrejelzések, valamint az előrejelzés eredményét, és gyorsítótárazza azokat a memóriában, hogy elkerülje a SageMaker felé intézett drága ismétlődő kéréseket. Ezenkívül nyomon követi, hogy milyen előrejelzéseket küldtek már el a műsorszolgáltatóknak, és gondoskodik arról, hogy csak új előrejelzéseket küldjön, vagy a korábban elküldötteket csak szükség esetén küldje el újra. A tesztelés kimutatta, hogy ez a megközelítés több mint 100-szorosára csökkenti a kimenő forgalom mennyiségét.

Egy másik optimalizálási technika, amelyet használtunk, a kérések csoportosítása a SageMaker felé, és aszinkron párhuzamos végrehajtása volt. Például, ha négy új kombinációja van a szembeállítási paramétereknek, amelyekhez előrejelzéseket kell kérnünk a SageMakertől, akkor tudjuk, hogy minden kérés 100 ezredmásodpercnél kevesebb időt vesz igénybe. Ha minden kérést egyenként szinkronban hajtunk végre, a teljes válaszidő 400 ezredmásodperc alatt lesz. De ha mind a négy kérelmet csoportosítjuk, aszinkron módon beküldjük, és megvárjuk az eredményt a teljes csoportra, mielőtt továbblépnénk, akkor gyakorlatilag párhuzamosítjuk a kéréseket, és a teljes válaszidő 100 ezredmásodperc alatt lesz, akárcsak egyetlen kérelem esetében.

Összegzésként

Az AWS által hajtott NHL Edge IQ fejlett elemzésekkel és új ML statisztikákkal közelebb hozza a rajongókat az eseményekhez. Ebben a bejegyzésben betekintést nyújtottunk az új Face-off Probability modell, az NHL első on-air ML statisztika felépítésébe és bevezetésébe. Ügyeljen arra, hogy figyelje a Face-off Probability által generált valószínűségeket a közelgő NHL-mérkőzéseken.

Ha teljes példát szeretne találni a SageMaker egyéni képzési munkáinak létrehozására, látogasson el a webhelyre Hozd el saját, betanított modelljét a SageMakerrel egy egyedi tároló megépítésével. Használati példákért Amazon kinezis streaminghez lásd Amazon Kinesis fejlesztés tanulása.

Ha többet szeretne megtudni az AWS és az NHL közötti partnerségről, látogasson el ide Az NHL az AWS Cloud Services segítségével újít meg. Ha szeretne együttműködni szakértőkkel, hogy ML megoldásokat vigyen be szervezetébe, vegye fel a kapcsolatot a Amazon ML Solutions Lab.

---

A szerzőkről

Ryan Gillespie idősebb adatkutató, az AWS professzionális szolgáltatásaival. MSc diplomáját a Northwestern Egyetemen, MBA diplomáját pedig a Torontói Egyetemen szerezte. Korábbi tapasztalata van a kiskereskedelemben és a bányászatban.

Yash Shah tudományos menedzser a Amazon ML Solutions Lab. Alkalmazott tudósokból és gépi tanulási mérnökökből álló csapatával számos gépi tanulási felhasználási eseten dolgozik az egészségügy, a sport, az autóipar és a gyártás területén.

Alekszandr Egorov fő streaming építész, aki streaming technológiákra specializálódott. Segíti a szervezeteket a streaming adatok valós idejű feldolgozására és elemzésére szolgáló platformok tervezésében és felépítésében.

Miguel Romero Calvo Alkalmazott tudósként dolgozik a Amazon ML Solutions Lab ahol együttműködik az AWS belső csapataival és stratégiai ügyfelekkel, hogy felgyorsítsa üzletüket az ML és a felhő bevezetésével.

Erick martinez Sr. Media Application Architect, több mint 25 éves tapasztalattal, a média és a szórakoztatás területére összpontosítva. Tapasztalattal rendelkezik a rendszerfejlesztési életciklus minden vonatkozásában, kezdve a felfedezéstől a követelmények összegyűjtésén, a tervezésen, a megvalósításon, a tesztelésen, a telepítésen és az üzemeltetésen keresztül.