למה AI ספורט פנטזיה נשבר על נתונים חסרים
מודל שאומן על טבלה שנאספה בקפידה מתפרק בעונה האמיתית הראשונה. חלק מהמשחקים אינם מכילים סטטיסטיקת שחקנים מלאה, חלק מחושבים מחדש בדיעבד על ידי המארגנים, וחלק חסרים לחלוטין — דחיות, ביטולים, השלמות.
כל חוסר מכוסה בממוצע לפי עמדה, והמודל טועה בביטחון דווקא באירועים נדירים: פציעה של שחקן מוביל, רוטציה בהרכב לפני סדרה, תנאים לא שגרתיים. המחיר של טעות כזו — ביטחון גבוה בתחזית במקום שאין לה בסיס, ומגבלות סיכון שהוגדרו לפי התחזית הזו.
העניין אינו בנפח ההיסטוריה, אלא ביכולת ההשוואה שלה. תקנוני צבירת נקודות, פורמטים של טורנירים וכללי ספירת זמן משחק השתנו בין עונות, ולכן היסטוריה שנתפרה ללא נורמליזציה מאלצת את המודל ללמוד את כללי העבר ולהעביר אותם לתחרות הנוכחית.
זהו הפער בסטטיסטיקה: התפלגויות המאפיינים באימון ובנתונים חיים נבדלות זו מזו, מדגם נפרד מציג מדדים יפים, והתחזית אינה מתאמתת.
איכות התוצאות ההיסטוריות נבדקת לפני האימון: עבור כל מאפיין ותאריך נבנית מפת חוסרים, מסומנים מרווחים עם ערכים לא מהימנים, ועבור כל אחד מהם מתקבלת החלטה — לשחזר, להשאיר כלא ידוע או להוציא את המשחק כולו.
יציבות המודל נשענת על ולידציה לפי עונות קדימה ועל בדיקות נפרדות של תרחישים נדירים, ולא על פיצול אקראי של המדגם. אז שגיאת התחזית נמדדת במקום שבו היא באמת מתרחשת.
להלן נפרק כיצד זה נסגר — מאיסוף הנתונים ועד לניהול סיכון.
מה נותן מודל תחזית עם ניהול סיכונים
המדד המרכזי כאן אינו דיוק שיא בטורניר בודד, אלא התנהגות המודל במקום שבו חסרים נתונים באופן אובייקטיבי. האנסמבל מחזיר לא רק את ההסתברות לתוצאה, אלא גם הערכת ביטחון: אם המאפיינים נבדלים — רוטציה בהרכב, חדשות מאוחרות על פציעות, קווים לא מלאים — האות אינו מפורסם.
סינון אירועים מתבצע ברמת המודל, ולא לאחר הפסד, ולכן שיעור האותות השגויים יורד: במשחקים בלתי צפויים המערכת שותקת.
ניהול סיכונים מובנה במעגל ההחלטה: מגבלה על אירוע והגבלה על אותות מתואמים — מספר תחזיות על משחק אחד אינן מצטברות לעמדה גדולה אחת. ההסתברויות מכוילות בחלון מתגלגל, ולכן הביטחון המוצהר תואם את התדירות בפועל של התוצאות, ולא שבוע מוצלח.
בטווח ארוך חשובה צורת עקומת התוצאה, ולא פסגות בודדות: מחשבים את השפל המקסימלי של התוצאה, שיעור התקופות המפסידות, יציבות בעת שינוי תקנון. נתונים ותיוג נבדקים מול Opta, כדי שפער בסטטיסטיקה לא יהפוך לאות שווא.
את האפקט בודקים על נתונים היסטוריים עם חישוב מתגלגל: משווים לקו בסיס, בודקים כמה אותות המודל סינן ומה היה קורה ללא סינון. בפלט — עקומה חלקה ללא שקעים עמוקים ודיוק תחזית גבוה יותר על האירועים הנבחרים.
מצבי עבודה: טורנירי פנטזיה מול קווי הימורים
אותו מודל הסתברויות נותן תוצאה שונה בהתאם להגדרת המשימה. בטורנירי פנטזיה חשוב לא הדיוק של תחזית בודדת, אלא מקומו של ההרכב בהתפלגות בין כל המשתתפים, בעוד בקווי הימורים — כיול ההסתברות של כל אירוע ומהירות החישוב מחדש שלה.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| טורניר פנטזיה | בחירת הרכב לסיבוב או לסדרה, כאשר החוקים קובעים מגבלות על עמדות וחילופים | נדרשת פונקציית תועלת מהמקום שנכבש, ולא מהניקוד המוחלט; משוב מגיע רק לאחר תום הסיבוב |
| קווי הימורים | הערכה רציפה של הסתברויות אירועים, כאשר חשוב כיול ולא תחזית סופית אחת | דורש זרם נתונים בזמן אמת ועמידות לשינוי בקווים; שגיאת כיול נראית מיד |
| מעגל היברידי | החלטות טורניריות על נתונים שכבר עובדו בקווים | בקרת איכות מורכבת יותר: מודל אחד משרת שני מדדי שגיאה שונים |
פורמט התחזית לכל מצב
במצב טורנירי, התחזית היא דירוג שחקנים בתוספת אופטימיזציה של ההרכב: תקרה לפי עמדות, מגבלת חילופים, תקציב הטורניר. ההגבלה על ההרכב הופכת את המשימה לאופטימיזציה מותנית — לפעמים שחקן חזק אחד גרוע משני שחקנים בינוניים, אם הוא שובר את המבנה.
חישוב מחדש של הסתברויות
בקווי הימורים ההסתברויות מחושבות מחדש בכל עדכון של נתוני הקלט, ולכן המודל מחזיר לא רק הערכה, אלא גם את יציבותה. את הכיול בודקים על חתכים היסטוריים: שיעור האירועים שהוערכו ב-70% צריך להתאים לתדירות בפועל במדגם מספיק — פער מראה היכן המודל בטוח בטעות.
כיצד אנו מיישמים מודל תחזית שלב אחר שלב
אנחנו מתחילים לא מהמודל, אלא מביקורת נתונים: בודקים אילו אירועים מגיעים מספקי סטטיסטיקה כמו Opta, באיזה עיכוב, היכן יש חוסרים וכפילויות, כיצד נוצרים הרכבים וחילופים.
לאחר מכן מקבעים את סכימת המאפיינים — עבור הרכבי פנטזיה ועבור הימורים היא שונה: במקרה אחד חשובה היעילות של השחקן בחלון משחקים, ובאחר — תנועת המקדמים ונפח ההימורים. טעות במאפיין בשלב זה עולה יותר מאשר מורכבות המודל עצמו.
- ביקורת נתונים — מלאי מקורות, עיכובי הגעה, חוסרים וכפילויות, בדיקת תיוג מול פרוטוקולי משחקים בפועל.
- סכימת מאפיינים — בחירת אותות עם בקרת זליגת עתיד: ערך אינו נכנס לאימון לפני שהתגלה בזמן אמת.
- תחזית בסיס — מודל פשוט או קווי שוק כנקודת ייחוס: בלעדיה לא ברור אם מודל AI מוסיף איכות בכלל.
- ולידציה של המודל — בדיקה לפי עונות וטורנירים, בנפרד על אירועים נדירים: פציעות, הרחקות, קווים לא שגרתיים.
- תקופת החזקה — המשחקים האחרונים בזמן אינם משתתפים באימון; עליהם רואים כיצד המודל מתנהג על נתונים שלא ראה.
- ניהול סיכונים — כללי עצירה כאשר התחזית סוטה מהמציאות, הגבלת גודל עמדה, יומן החלטות המודל.
- מסירת הפתרון — קוד, תצורות, תקנון אימון מחדש וניתוח מדדים עוברים לצוות הלקוח, התמיכה אינה תלויה בנו.
מה הלקוח מקבל לידיו לאחר היישום
יישום מערכת חיזוי לספורט פנטזיה מסתיים לא בתחזית הראשונה, אלא ברגע שבו הצוות שלכם מתחזק אותה בעצמו. בפלט — סט ארטיפקטים: לפיו מהנדס מבצע בנייה מחדש, מנתח תקלה ומסביר כל החלטה של המודל לבודק. להלן מה בדיוק נשאר אצלכם.
- סכימת נתונים ותיאור מאפיינים: רשימת מקורות, תדירות עדכון, כללי חישוב כושר שחקנים והרכבים, התנהגות המערכת בעת עיכוב או היעלמות מקור.
- תיעוד המודל: כיצד הוא מאומן, אילו נתונים נכנסים לקלט, על אילו קטעים נבדקה היציבות והיכן גבולות היישום — עונה חדשה, שינוי תקנון הטורניר.
- תקנון בנייה מחדש: אירועים-טריגרים (ירידה באיכות, שינוי בנתונים, שינוי בפורמט התחרות), מי יוזם וכיצד גרסה חדשה עוברת בדיקה לפני פרסום.
- כללי עצירה: באילו תנאים הפצת תחזיות מופסקת אוטומטית, מי מחליט על חידוש ומה רואה המשתמש באותו רגע.
- ניהול סיכונים: לוגיקת מגבלות על אירוע ועל יום, ספי שפל שאחריהם המערכת מפחיתה נפח.
- הרשאות ויומן גרסאות: תפקידים — מי משנה מאפיינים ומי מגבלות; שמירת בניות קודמות ונוהל חזרה לגרסה עובדת.
- לוח ניטור: איכות התחזיות מול הצפוי, עיכובי נתונים, התראות בחריגה מהספים שהוגדרו.
- מסירת הפתרון: הדרכת הצוות שלכם, ניתוח תקלות אופייניות, נוהל הסלמה אלינו ותקופת תמיכה לאחר ההשקה.
מקרה בוחן: דיוק תחזית ושפל לפני ואחרי היישום
הלקוח — מפעיל ליגת פנטזיה — הגיע עם תהליך ידני לחלוטין: אנליסטים אספו הרכבים, פציעות וסטטיסטיקה בטבלאות, והחלטות על אותות התקבלו לפי ניסיון. לא הייתה הערכת ביטחון, ולכן כל האירועים נכנסו לפלט ברצף, ורצפים של כישלונות רוקנו את הקופה מהר יותר משהיא הצטברה.
| מדד | לפני | אחרי |
|---|---|---|
| שיעור אותות נכונים | 54% | 66% |
| שפל על סדרת אירועים | 18% מהקופה | 6% מהקופה |
| אירועים שסוננו בעונה | 0 מתוך 3,200 | 2,100 מתוך 3,200 |
| הכנת תחזית ליום משחק | 3-4 שעות | 15 דקות |
מה בדיוק שינו
המודל מחזיר הסתברות לכל אירוע, ושכבת ניהול הסיכונים מתרגמת אותה לגודל עמדה ופוסלת אותות עם אי-התאמה בין המקורות — הרכבים, רוטציות, הרחקות. יומן ההחלטות מתעד את נתוני הקלט ואת סיבת הסירוב, ולכן כל שפל ניתן לנתח בדיעבד, ולא לדון בו מהזיכרון.
מדוע ויתור על אירועים חיזק את התוצאה
סינון שני שלישים מהאירועים אינו אובדן כיסוי, אלא הפחתת פיזור: שיעור האותות הנכונים עלה, ועומק השפל הצטמצם פי שלושה. הכנת הנתונים אוטומטית, והזמן שהתפנה מוקדש לבדיקת מאפיינים חדשים, ולא לאיסוף ידני של סטטיסטיקה.
מה לעשות אם הנתונים על משחקים מפוזרים?
מקורות מפוזרים הם נורמה, ולא מצב חירום: לספק אחד יש הרכבים, לשני היסטוריית תוצאות, לשלישי מקדמים. השאלה הראשונה אינה «כיצד לאחד הכל», אלא האם יש מפתח משותף — קבוצה, שחקן, תאריך משחק. אם יש חפיפה לפחות ברוב המשחקים, איחוד הנתונים כבר נותן מערך עבודה לאימון.
בעת איחוד, המקורות מובאים לסכימה אחידה ונקבע סדר עדיפויות מפורש בעת קונפליקט בערכים, אחרת פציעה אחת של שחקן תגיע בשלוש גרסאות. חוסרים אינם נמחקים בממוצע — הם נשארים כמאפיין נפרד: מודל שאומן על ערכים מומצאים מאבד דיוק במשחקים חיים.
כאשר יש מעט נתונים משלכם, פועלים לא ב«השלמה בכל מחיר», אלא בשלוש אפשרויות אחרות — הן נבדלות בזמן עד לתוצאה הראשונה ובמחיר הטעות.
סדר מעשי: ביקורת מקורות וחפיפות, איחוד ותיוג מפורש של חוסרים, אימון נוסף על הנפח הזמין, ואחר כך הרחבת תחום התחזית. להרחיב אותו לפני שהמערך נבדק בשוק צר — הדרך המהירה ביותר לקבל מודל שנראה טוב בדוח וטועה במשחקים חיים.
ספקות טכניים נפוצים לגבי מודלים של תחזית
ספקות הנדסיים לגבי מודלים חזויים מצטמצמים לחמישה נושאים: אימון יתר, ירידה בדיוק, הטמעה בפלטפורמה קיימת, אחריות על נתונים ותמיכה לאחר ההשקה.
המודל יאומן יתר על הנתונים ההיסטוריים — כיצד אתם שולטים בכך?
הוולידציה מתבצעת לפי זמן: אימון על קטעים קודמים, בדיקה על קטעים מאוחרים יותר. את המורכבות מגבילים, את האותות בוחרים לפי יציבות — אפשרות שנראית יפה בהיסטוריה אך מתפרקת על נתונים חדשים אינה נכנסת לעבודה.
הדיוק יורד עם הזמן — כיצד אתם מבחינים בכך?
המדדים מחושבים בחלון מתגלגל ומושווים למציאות, ומעקב אחר סחיפת נתוני הקלט. בחריגה מהסף מופעל אימון מחדש, הגרסה החדשה נכנסת תחילה למצב צל ומחליפה את הנוכחית רק לאחר איכות מאושרת.
כיצד התחזית משתלבת בפלטפורמה שלנו?
המודל מחזיר הערכה והסתברות דרך ממשק תכנות, וההחלטה נשארת בידי הפלטפורמה: כללים, מגבלות וחסימות סיכון פועלים בצד שלכם. המעבר מדורג — תחילה חלק מהאירועים, אחר כך כל הזרם.
מי אחראי לנתונים ולשימוש בהם?
הנתונים והזכויות עליהם נשארים אצלכם. אנחנו אחראים לעיבוד, תיוג, גישה מאובטחת ותיעוד: ניתן לראות איזה מערך ואיזו גרסת מודל נתנו תחזית מסוימת.
מה קורה למודל לאחר ההשקה?
פועל תקנון תמיכה: ניטור מדדים, אימון מחדש מתוכנן, ניהול גרסאות וחזרה לגרסה קודמת. מודל ללא בעלים וללא לוח זמנים לבדיקות מדרדר מהר יותר ממה שמספיקים להבחין.
נדון במשימת החיזוי שלכם
תחילת הפרויקט מתחילה לא בחוזה, אלא בנתונים. להלן סט נתונים מינימלי להערכה: איתו ניתוח המשימה אורך שיחה אחת-שתיים, ואנחנו חוזרים עם תוכנית עבודה, ולא עם מילים כלליות.
- היסטוריית קווים ותוצאות אירועים לתקופה הארוכה ביותר הזמינה — עליה בודקים אם התחזית בכלל משוחזרת.
- יומן הימורים והחלטות: מה בחרתם, לפי איזו לוגיקה, איך זה נגמר. בלעדיו אי אפשר להפריד בין שגיאת מודל לשגיאת כללים.
- מגבלות פעילות: על אירוע, על יום, על סדרה, סף עצירה בעת שפל.
- דרישות מהירות: כמה מהר לאחר תנועת קו נדרשת תחזית והיכן היא צריכה להופיע.
- נקודות חיבור למערכות: ממשק, התראה, שירות חיצוני — לאן יוצאת התוצאה.
- מגבלות נתונים: תחום שיפוט, תקופות אחסון, מי בעל גישה למודל ולתוצרים.
- מדדי איכות נוכחיים וסף שמתחתיו החלטה נחשבת לבלתי מקובלת.
שלחו את מה שיש, אפילו חלקית. בתגובה — הערכת משימה עם גבולות: מה נכלל, מה לא, במה תלוי הזמן ואילו סיכונים אנו סוגרים ברמת הכללים, ולא המודל.