הסתברות פנים-off היא ליגת ההוקי הלאומית (NHL) סטטיסטיקה מתקדמת ראשונה באמצעות למידת מכונה (ML) ובינה מלאכותית. היא משתמשת בנתונים בזמן אמת של מעקב אחר שחקנים ו-Puck (PPT) כדי להראות לצופים איזה שחקן צפוי לזכות בהתמודדות לפני שהדייס יופל, ומספקת לשדרנים ולצופים הזדמנות לצלול עמוק יותר לתוך החשיבות של משחקי עימות. וההבדלים ביכולות השחקן. בהתבסס על 10 שנים של נתונים היסטוריים, נעשה שימוש במאות אלפי התמודדויות כדי להנדס למעלה מ-70 תכונות שהוכנסו למודל כדי לספק הסתברויות בזמן אמת. משדרים יכולים כעת לדון כיצד ניצחון מפתח מול שחקן הוביל לשער או כיצד הסיכוי לזכות בהתמודדות פוחת כשהוא מוותר מתיקו. מעריצים יכולים לראות תחזיות חזותיות בזמן אמת המראות להם את החשיבות של חלק מרכזי במשחק.

בפוסט זה, אנו מתמקדים כיצד פותח מודל ה-ML עבור הסתברות פנים-off ובשירותים המשמשים להכנסת המודל לייצור. אנו גם חולקים את האתגרים הטכניים המרכזיים שנפתרו במהלך בניית מודל ההסתברות של Face-off.

איך זה עובד

תארו לעצמכם את התרחיש הבא: זה משחק שוויון בין שתי קבוצות NHL שיקבע מי יעבור קדימה. אנחנו בתקופה השלישית כשנותרו 1:22 שניות לסיום. שני שחקנים מהקבוצות הנגדיות עומדים בתור כדי לקחת את התיקו בהתמודדות הקרובה ביותר קרוב לאחת הרשתות. הקוון מבחין בשחקן הגנה חודר למעגל ההתמודדות ומוותר על השחקן שלו מחוץ למשחק עקב ההפרה. שחקן הגנה פחות מנוסה נכנס לקחת את התיקו כמחליף שלו. הקבוצה התוקפת מנצחת את ההתמודדות, משיגה את הדיסוק, ומיד מבקיעת כדי להוביל. התוצאה מחזיקה מעמד למשך הדקה שנותרה למשחק ומכריעה מי מתקדם. איזה שחקן הועדף לזכות בהתמודדות לפני שהצמד הראשוני הוחלף? עד כמה ירדה ההסתברות של קבוצת ההגנה לזכות בהתמודדות מול ההפרה שאילצה שחקן אחר לקחת את התיקו? Face-off Probability, הנתון החדש ביותר של NHL Edge IQ המופעל על ידי AWS, יכול כעת לענות על שאלות אלו.

כאשר יש הפסקה במשחק, הסתברות פנים-אוף מייצרת תחזיות למי ינצח את ההתמודדות הקרובה על סמך השחקנים על הקרח, מיקום ההתמודדות ומצב המשחק הנוכחי. התחזיות נוצרות לאורך כל ההפסקה עד ששעון המשחק מתחיל לרוץ שוב. התחזיות מתרחשות בהשהייה של תת-שנייה ומופעלות בכל פעם שיש שינוי בשחקנים המעורבים בהתמודדות.

התגברות על מכשולים עיקריים להסתברות מול פנים

ניתן לחלק את חיזוי הסתברות הפנים בשידורים בזמן אמת לשתי בעיות משנה ספציפיות:

• מודלים של אירוע הפנים כבעיית ML, הבנת הדרישות והמגבלות, הכנת הנתונים, הנדסת אותות הנתונים, חקר אלגוריתמים והבטחת אמינות התוצאות
• זיהוי אירוע פנים-off במהלך המשחק מתוך זרם של אירועי PPT, איסוף פרמטרים הדרושים לחיזוי, קריאה למודל ושליחת תוצאות לגופי השידור

לחזות את ההסתברות ששחקן יזכה בהתמודדות בזמן אמת בשידור בטלוויזיה יש כמה אתגרים טכניים שצריך היה להתגבר עליהם. אלה כללו קביעת התכונות הנדרשות ושיטות מודל לחיזוי אירוע שיש בו כמות גדולה של אי ודאות, וקביעת אופן השימוש בזרימת נתוני חיישני PPT כדי לזהות היכן מתרחשת התמודדות, השחקנים המעורבים וההסתברות של כל שחקן ניצחון בהתמודדות, הכל תוך מאות אלפיות שניות.

בניית מודל ML לאירועים קשים לניבוי

חיזוי אירועים כגון הסתברויות זכייה במהלך משחק חי היא משימה מורכבת הדורשת כמות משמעותית של נתונים היסטוריים איכותיים ויכולות הזרמת נתונים. כדי לזהות ולהבין את האותות החשובים בסביבת נתונים כה עשירה, פיתוח מודלים של ML דורש מומחיות נרחבת בנושא. ה מעבדת פתרונות למידת מכונות של אמזון שיתפו פעולה עם מומחי הוקי ונתונים של NHL כדי לעבוד אחורה ממטרת היעד שלהם לשפר את חווית האוהדים שלהם. על ידי הקשבה מתמדת למומחיות של NHL ובדיקת השערות, המדענים של AWS הנדסו למעלה מ-100 מאפיינים המתואמים לאירוע ההתמודדות. בפרט, הצוות סיווג את מערך התכונות הזה לאחת משלוש קטגוריות:

• נתונים סטטיסטיים היסטוריים על ביצועי שחקנים כמו מספר ההתמודדויות ששחקן לקח וניצח בחמש העונות האחרונות, מספר ההתמודדויות שהשחקן לקח וניצח במשחקים קודמים, אחוזי הזכייה של שחקן לאורך מספר חלונות זמן, ואחוז הזכייה הראש בראש עבור כל שחקן בהתמודדות
• מאפייני שחקן כמו גובה, משקל, ידיים ושנים בליגה
• נתונים מצביים במשחק שעשויים להשפיע על הביצועים של שחקן, כגון ניקוד המשחק, הזמן שחלף במשחק עד לנקודה זו, היכן ממוקמת ההתמודדות, עוצמתה של כל קבוצה ואיזה שחקן צריך לשים. המקל שלהם יורד קודם כל לפנים

מדעני ה-ML של AWS התייחסו לבעיה כבעיית סיווג בינארי: או שהשחקן הביתי מנצח את ההתמודדות או ששחקן החוץ מנצח את ההתמודדות. עם נתונים של יותר מ-200,000 התמודדויות היסטוריות, הם השתמשו ב-a LightGBM מודל לניבוי מי משני השחקנים המעורבים באירוע עימות צפוי לנצח.

קביעה אם עומד להתרחש התמודדות ואילו שחקנים מעורבים

כאשר משרוקית שורקת והמשחק נעצר, Face-off Probability מתחילה לחזות. עם זאת, ההסתברות להתמודדות צריכה קודם כל לקבוע היכן מתרחש ההתמודדות ואיזה שחקן מכל קבוצה מעורב בהתמודדות. זרם הנתונים מציין אירועים בזמן שהם מתרחשים אך אינו מספק מידע על מתי צפוי אירוע להתרחש בעתיד. ככזה, נתוני החיישנים של השחקנים על הקרח נחוצים כדי לקבוע אם והיכן עומדת להתרחש התמודדות.

מערכת PPT מייצרת מיקומים ומהירויות בזמן אמת לשחקנים על הקרח עד 60 אירועים בשנייה. המיקומים והמהירויות האלה שימשו כדי לקבוע היכן מתרחשת ההתמודדות על הקרח ואם זה צפוי לקרות בקרוב. על ידי ידיעה עד כמה השחקנים קרובים למיקומי התמודדות ידועים ועד כמה השחקנים היו נייחים, הסתברות פנים-אוף הצליחה לקבוע שסביר להניח שיתרחש התמודדות ושני השחקנים שיהיו מעורבים בהתמודדות. .

קביעת מרחק הניתוק הנכון לקרבה למיקום מנוכר ומהירות הניתוק המתאימה עבור שחקנים נייחים הושגה באמצעות מודל עץ החלטה. עם נתוני PPT מעונת 2020-2021, בנינו מודל לחזות את הסבירות שהתמודדות מתרחשת במיקום מוגדר בהינתן המרחק הממוצע של כל קבוצה למיקום ולמהירות השחקנים. עץ ההחלטות סיפק את החתכים לכל מדד, אותם כללנו כהיגיון מבוסס כללים באפליקציית הסטרימינג.

כאשר נקבע מיקום ההתמודדות הנכון, השחקן מכל קבוצה שלוקח את ההתמודדות חושב על ידי לקיחת השחקן הקרוב ביותר למיקום הידוע מכל קבוצה. זה סיפק לאפליקציה את הגמישות לזהות את השחקנים הנכונים, תוך יכולת להסתגל לשחקן חדש שיצטרך להתמודד עם התמודדות אם שחקן נוכחי יוותר עקב הפרה. ביצוע ועדכון החיזוי עבור השחקן הנכון היו מוקד מרכזי לשימושיות בזמן אמת של המודל בשידורים, שאותם נתאר עוד בסעיף הבא.

פיתוח והדרכה של מודלים

כדי לפתח את המודל, השתמשנו ביותר מ-200,000 נקודות מידע היסטוריות, יחד עם ערכת התכונות המותאמת אישית שתוכננה על ידי עבודה עם מומחי הנושא. בדקנו מאפיינים כמו מצבים במשחק, ביצועים היסטוריים של השחקנים שלוקחים את ההתמודדות, מאפיינים ספציפיים לשחקן וביצועים ראש בראש של השחקנים שהתמודדו, הן בעונה הנוכחית והן עבורם. קריירה. ביחד, זה הביא ליותר מ-100 תכונות שנוצרו תוך שימוש בשילוב של טכניקות זמינות ונגזרות.

כדי להעריך תכונות שונות וכיצד הן עשויות להשפיע על המודל, ערכנו ניתוח מאפיינים נרחב כחלק משלב החקר. השתמשנו בשילוב של מבחנים חד משתנים ומבחנים רב משתנים. עבור מבחנים רב-משתנים, לצורך פרשנות, השתמשנו בטכניקות להדמיה של עצי החלטה. כדי להעריך מובהקות סטטיסטית, השתמשנו במבחני Chi Test ו-KS כדי לבדוק תלות או הבדלי התפלגות.

חקרנו טכניקות ומודלים לסיווג מתוך ציפייה שההסתברויות הגולמיות יטופלו כאל התחזיות. חקרנו את השכנים הקרובים ביותר, עצי החלטה, רשתות עצביות, וגם סינון שיתופי במונחים של אלגוריתמים, תוך ניסיון של אסטרטגיות דגימה שונות (סינון, דגימה אקראית, שכבתית ומבוססת זמן) והערכנו ביצועים ב-Area Under the Curve (AUC) ו חלוקת כיול יחד עם אובדן ציון Brier. בסופו של דבר, גילינו שמודל LightGBM עבד בצורה הטובה ביותר עם מדדי דיוק מכוילים היטב.

כדי להעריך את הביצועים של המודלים, השתמשנו במספר טכניקות. השתמשנו בסט מבחן שהדגם המאומן מעולם לא נחשף אליו. בנוסף, הקבוצות ערכו הערכות ידניות מקיפות של התוצאות, הסתכלו על מקרי קצה וניסו להבין את הניואנסים של איך המודל נראה כדי לקבוע מדוע שחקן מסוים היה צריך לזכות או להפסיד באירוע מול פנים.

עם מידע שנאסף מסוקרים ידניים, היינו מתאימים את התכונות בעת הצורך, או מפעילים איטרציות על המודל כדי לראות אם הביצועים של המודל היו כצפוי.

פריסת הסתברות פנים-off לשימוש בזמן אמת במהלך שידורי טלוויזיה ארציים

אחת ממטרות הפרויקט לא הייתה רק לחזות את המנצח בהתמודדות, אלא לבנות בסיס לפתרון מספר בעיות דומות בזמן אמת וחסכוני. מטרה זו עזרה לקבוע באילו רכיבים להשתמש בארכיטקטורה הסופית.

המרכיב החשוב הראשון הוא זרמי נתונים של אמזון קינסי, שירות זרימת נתונים ללא שרת הפועל כמנתק בין היישום הספציפי של ספק הנתונים של ה-PPT לבין יישומים צורכים, ובכך מגן על האחרון מפני השינויים המפריעים בראשון. הוא גם שיפר את תכונת ה-fan-out, המספקת את היכולת לחבר עד 20 צרכנים מקבילים ולשמור על חביון נמוך של 70 מילישניות ועל אותה תפוקה של 2MB/s לכל רסיס בין כולם בו זמנית.

אירועי PPT לא מגיעים לכל השחקנים בבת אחת, אלא מגיעים באופן דיסקרטי לכל שחקן כמו גם לאירועים אחרים במשחק. לכן, כדי ליישם את אלגוריתם זיהוי הפנים-off, האפליקציה צריכה לשמור על מצב.

המרכיב החשוב השני בארכיטקטורה הוא ניתוח נתונים של אמזון Kinesis ל אפצ'י פלינק. Apache Flink הוא מנוע זרימה מבוזר, בעל תפוקה גבוהה, זרימת נתונים בהשהייה נמוכה, המספק דרך נוחה וקלה להשתמש ב-Data Stream API, והוא תומך בפונקציות עיבוד מצביות, נקודות ביקורת ועיבוד מקביל מחוץ לקופסה. זה עוזר להאיץ את הפיתוח ומספק גישה לשגרות ורכיבים ברמה נמוכה, מה שמאפשר עיצוב ויישום גמישים של יישומים.

Kinesis Data Analytics מספק את התשתית הבסיסית עבור יישומי Apache Flink שלך. זה מבטל את הצורך לפרוס ולהגדיר אשכול Flink על ענן מחשוב אלסטי של אמזון (אמזון EC2) או קוברנט, מה שמפחית את מורכבות התחזוקה והעלויות.

המרכיב המכריע השלישי הוא אמזון SageMaker. למרות שהשתמשנו ב-SageMaker לבניית מודל, היינו צריכים לקבל החלטה בשלבים המוקדמים של הפרויקט: האם יש ליישם את הניקוד בתוך אפליקציית זיהוי ה-face-off עצמה ולסבך את היישום, או שהאפליקציה לזיהוי face-off צריכה להתקשר SageMaker מרחוק ולהקריב קצת חביון עקב תקשורת דרך הרשת? כדי לקבל החלטה מושכלת, ביצענו סדרה של אמות מידה לאימות זמן ההשהיה והמדרגיות של SageMaker, ואימתנו שהשהייה הממוצעת הייתה פחות מ-100 מילישניות תחת העומס, וזה היה במסגרת הציפיות שלנו.

לאחר שהוחלט על החלקים העיקריים של ארכיטקטורה ברמה גבוהה, התחלנו לעבוד על העיצוב הפנימי של יישום זיהוי הפנים. מודל חישוב של היישום מתואר בתרשים הבא.

ניתן לעצב את מודל המחשוב של אפליקציית זיהוי ה-face-off כמכונה פשוטה במצב סופי, כאשר כל הודעה נכנסת מעבירה את המערכת ממצב אחד לאחר תוך ביצוע חישוב כלשהו יחד עם המעבר הזה. האפליקציה מתחזקת מספר מבני נתונים כדי לעקוב אחר הדברים הבאים:

• שינויים במצב המשחק - מספר התקופה הנוכחית, המצב והערך של שעון המשחק והניקוד
• שינויים במצב השחקן - אם השחקן נמצא כרגע על הקרח או על הספסל, הקואורדינטות הנוכחיות על המגרש והמהירות הנוכחית
• שינויים בסטטיסטיקה האישית של השחקן – שיעור ההצלחה של שחקן אחד מול אחר, וכן הלאה

האלגוריתם בודק כל אירוע עדכון מיקום של שחקן כדי להחליט אם יש לבצע חיזוי חזית והאם יש להגיש את התוצאה לגופי השידור. אם ניקח בחשבון שכל מיקום שחקן מתעדכן בערך כל 80 מילישניות והשחקנים נעים הרבה יותר לאט במהלך הפסקות המשחק מאשר במהלך המשחק, אנו יכולים להסיק שהמצב בין שני עדכונים לא משתנה באופן דרסטי. אם האפליקציה התקשרה ל-SageMaker לצורך תחזיות ותשלח תחזיות לגופי השידור בכל פעם שהתקבל אירוע עדכון מיקום חדש וכל התנאים מתקיימים, SageMaker והשדרנים היו מוצפים במספר בקשות כפולות.

כדי למנוע את כל הרעש המיותר הזה, האפליקציה עוקבת אחר שילוב של פרמטרים שלגביהם כבר נעשו תחזיות, יחד עם תוצאת החיזוי, ושומרת אותם בזיכרון כדי למנוע בקשות כפולות יקרות ל- SageMaker. כמו כן, הוא עוקב אחר התחזיות שכבר נשלחו לגופי השידור ודואג שרק תחזיות חדשות נשלחות או שנשלחות קודמות נשלחות שוב רק במידת הצורך. בדיקות הראו שגישה זו מפחיתה את כמות התנועה היוצאת ביותר מפי 100.

טכניקת אופטימיזציה נוספת בה השתמשנו הייתה קיבוץ בקשות ל- SageMaker וביצוען באופן אסינכרוני במקביל. לדוגמה, אם יש לנו ארבעה שילובים חדשים של פרמטרים של פניה שלפניהם אנחנו צריכים לקבל תחזיות מ-SageMaker, אנחנו יודעים שכל בקשה תיקח פחות מ-100 אלפיות שניות. אם נבצע כל בקשה באופן סינכרוני אחד אחד, זמן התגובה הכולל יהיה מתחת ל-400 מילישניות. אבל אם נקבץ את כל ארבע הבקשות, נגיש אותן באופן אסינכרוני ונמתין לתוצאה עבור כל הקבוצה לפני שנמשיך קדימה, למעשה מקבילים בקשות וזמן התגובה הכולל יהיה מתחת ל-100 מילישניות, בדיוק כמו לבקשה אחת בלבד.

<br> סיכום

NHL Edge IQ, המופעל על ידי AWS, מקרב את המעריצים לפעולה עם ניתוחים מתקדמים וסטטיסטיקות ML חדשות. בפוסט הזה, הראינו תובנות לגבי הבנייה והפריסה של מודל ההסתברות החדש של Face-off Probability, נתון ה-ML הראשון באוויר עבור ה-NHL. הקפד לפקוח עין על ההסתברויות שנוצרות על ידי הסתברות פנים-off במשחקי NHL הקרובים.

כדי למצוא דוגמאות מלאות לבניית משרות הדרכה מותאמות אישית עבור SageMaker, בקר הביאו דגם משלכם שהושלם עם SageMaker על ידי בניית מיכל מותאם אישית. לדוגמאות לשימוש אמזון קינסי לסטרימינג, עיין ב לימוד פיתוח אמזון קינסיס.

למידע נוסף על השותפות בין AWS ל-NHL, בקר NHL חדשנית עם שירותי ענן של AWS. אם תרצה לשתף פעולה עם מומחים כדי להביא פתרונות ML לארגון שלך, צור קשר עם מעבדת פתרונות אמזון ML.

על הכותבים

ריאן גילספי הוא Sr. Data Scientist עם שירותים מקצועיים של AWS. יש לו תואר שני מאוניברסיטת נורת'ווסטרן ותואר שני במנהל עסקים מאוניברסיטת טורונטו. בעל ניסיון קודם בענפי הקמעונאות והכרייה.

יאש שאה הוא מנהל מדע ב- Amazon ML Solutions Lab. הוא וצוות המדענים היישומיים שלו ומהנדסי למידת מכונה עובדים על מגוון מקרי שימוש של למידת מכונה מתחומי הבריאות, הספורט, הרכב והייצור.

אלכסנדר אגורוב הוא אדריכל סטרימינג ראשי, המתמחה בטכנולוגיות סטרימינג. הוא עוזר לארגונים לתכנן ולבנות פלטפורמות לעיבוד וניתוח נתונים זורמים בזמן אמת.

מיגל רומרו קלבו הוא מדען יישומי ב- מעבדת פתרונות אמזון ML שבו הוא משתף פעולה עם צוותים פנימיים של AWS ועם לקוחות אסטרטגיים כדי להאיץ את העסק שלהם באמצעות ML ואימוץ ענן.

אריק מרטינז הוא אדריכל יישומי מדיה האב עם ניסיון של 25+ שנים, עם התמקדות במדיה ובידור. הוא מנוסה בכל ההיבטים של מחזור החיים של פיתוח מערכות, החל מגילוי, איסוף דרישות, תכנון, הטמעה, בדיקה, פריסה ותפעול.