מעולה! פרסתם את מודל החד-קרן. המודל אמור לפעול מסביב לשעון ללא בעיות. כדי לוודא שהיא פועלת כראוי, צריך לעקוב אחרי צינור עיבוד הנתונים של למידת המכונה (ML).
כתיבת סכימה של נתונים לאימות נתונים גולמיים
כדי לעקוב אחרי הנתונים, צריך לבדוק אותם באופן קבוע לעומת ערכים סטטיסטיים צפויים, על ידי כתיבת כללים שהנתונים חייבים לעמוד בהם. אוסף הכללים הזה נקרא סכימה של נתונים. כדי להגדיר סכימת נתונים:
להבין את ההיקף וההפצה של התכונות. במאפיינים קטגוריאליים, חשוב להבין את קבוצת הערכים האפשריים.
להטמיע את ההבנה שלכם בסכימת הנתונים. ריכזנו כאן כמה דוגמאות לכללים:
- חשוב לוודא שהציונים שהמשתמשים שולחים תמיד נעים בטווח 1 עד 5.
- בודקים שהמילה the מופיעה בתדירות הגבוהה ביותר (בתוכן באנגלית).
- בודקים שכל מאפיין קטגוריאלי מוגדר לערך מתוך קבוצה קבועה של ערכים אפשריים.
בודקים את הנתונים בהשוואה לסכימת הנתונים. הסכימה צריכה לזהות שגיאות נתונים כמו:
- חריגות
- ערכים לא צפויים של משתנים קטגוריים
- התפלגויות נתונים לא צפויות
כתיבת בדיקות יחידה לאימות של פיתוח תכונות
יכול להיות שהנתונים הגולמיים יעברו את הסכימה של הנתונים, אבל המודל לא יתאמן על נתונים גולמיים. במקום זאת, המודל מתאמן על נתונים שעברו הנדסת תכונות. לדוגמה, המודל מתאמן על מאפיינים מספריים מנורמלים במקום על נתונים מספריים גולמיים. מאחר שנתונים שעברו עיבוד של תכונות יכולים להיות שונים מאוד מנתוני קלט גולמיים, צריך לבדוק את הנתונים שעברו עיבוד של תכונות בנפרד מהבדיקות של נתוני הקלט הגולמיים.
כותבים בדיקות יחידה על סמך ההבנה שלכם לגבי נתונים שעברו הנדסת תכונות. לדוגמה, אפשר לכתוב בדיקות יחידה כדי לבדוק תנאים כמו:
- כל המאפיינים המספריים מותאמים לערך, למשל בין 0 ל-1.
- ווקטורים עם קידוד One-hot מכילים רק 1 יחיד ו-N-1 אפסים.
- התפלגויות הנתונים אחרי הטרנספורמציה תואמות לציפיות. לדוגמה, אם ביצעתם נורמליזציה באמצעות ציונים סטנדרטיים, הממוצע של הציונים הסטנדרטיים צריך להיות 0.
- ערכים חריגים מטופלים, למשל על ידי שינוי קנה המידה או חיתוך.
בדיקת מדדים של פלחים חשובים של נתונים
לפעמים, קבוצה כוללת שמצליחה מסתירה קבוצת משנה שנכשלה. במילים אחרות, מודל עם מדדים כלליים מצוינים עדיין עשוי לספק תחזיות גרועות במצבים מסוימים. לדוגמה:
המודל של החד-קרן מניב ביצועים טובים באופן כללי, אבל הביצועים שלו נמוכים כשהמערכת מניבה תחזיות לגבי מדבר סהרה.
אם אתם מהנדסים שמסתפקים בערך AUC גבוה באופן כללי, יכול להיות שלא תבחינו בבעיות של המודל במדבר סהרה. אם חשוב לכם לקבל תחזיות טובות בכל האזורים, עליכם לעקוב אחרי הביצועים בכל אזור. קבוצות משנה של נתונים, כמו הקבוצה שתואמת למדבר סהרה, נקראות פלחים של נתונים.
זיהוי פלחים של נתונים שמעניינים אתכם. לאחר מכן, משווים את מדדי המודל של פלחי הנתונים האלה למדדים של כל מערך הנתונים. בדיקה שהמודל מניב ביצועים טובים בכל פלחי הנתונים עוזרת להסיר הטיות. למידע נוסף, ראו צדק: בדיקה של הטיה.
שימוש במדדים מהעולם האמיתי
מדדי המודל לא בהכרח מודדים את ההשפעה של המודל בעולם האמיתי. לדוגמה, שינוי של היפרפרמטר עשוי להגדיל את AUC של מודל, אבל איך השינוי השפיע על חוויית המשתמש? כדי למדוד את ההשפעה בפועל, צריך להגדיר מדדים נפרדים. לדוגמה, אפשר לערוך סקר בקרב המשתמשים במודל כדי לוודא שהם באמת ראו חד-קרן כשהמודל ניבא שהם יראו.
בדיקה של סטיות training-serving skew
הטיה בין אימון להצגה: נתוני הקלט במהלך האימון שונים מנתוני הקלט במהלך ההצגה. בטבלה הבאה מתוארים שני הסוגים החשובים של הטיה:
| סוג | הגדרה | דוגמה | פתרון |
|---|---|---|---|
| הטיה בסכימה | נתוני הקלט לאימון ולצגת מודעות לא תואמים לאותה הסכימה. | הפורמט או ההפצה של נתוני ההצגה משתנים בזמן שהמודל ממשיך להתאמן על נתונים ישנים. | משתמשים באותה סכימה כדי לאמת נתוני אימון ונתוני הצגה. חשוב לבדוק בנפרד סטטיסטיקות שלא נבדקות על ידי הסכימה, כמו החלק היחסי של ערכים חסרים |
| הטיה של תכונה | הנתונים שעברו הנדסת נתונים שונים בין אימון לבין הצגה. | הקוד של הנדסת המאפיינים שונה בתהליך האימון ובתהליך ההצגה, ומייצג נתונים שונים מהנדסים. | בדומה לסטייה בסכימה, צריך להחיל את אותם כללים סטטיסטיים על נתונים מהכשרה ועל נתונים מהצגת מודעות. מעקב אחרי מספר התכונות הלא מאוזנות שזוהו, והיחס בין דוגמאות לא מאוזנות לכל תכונה. |
לפעמים קשה לזהות את הגורמים ל-training-serving skew. תמיד חשוב לבדוק אילו נתונים זמינים למודל בזמן החיזוי. במהלך האימון, השתמשו רק בתכונות שיהיו זמינות לכם בזמן ההצגה.
תרגול: בדיקת ההבנה
נניח שיש לכם חנות וירטואלית ואתם רוצים לחזות כמה כסף תרוויחו ביום נתון. היעד שלכם ב-ML הוא לחזות את ההכנסה היומית באמצעות מספר הלקוחות כתכונה.
תשובה: הבעיה היא שאתם לא יודעים את מספר הלקוחות בזמן התחזית, לפני שהמכירות של היום יושלמו. לכן, התכונה הזו לא מועילה, גם אם היא מנבאת בצורה חזקה את ההכנסה היומית שלכם. בהקשר הזה, כשאתם מאומנים מודל ומקבלים מדדי הערכה מדהימים (כמו 0.99 AUC), כדאי לחפש תכונות כאלה שיכולות להשפיע על התווית.
בדיקה של זליגת תוויות
דליפה של תוויות היא מצב שבו תוויות האמת שאתם מנסים לחזות נכנסו בטעות למאפייני האימון. לפעמים קשה מאוד לזהות זליגת תוויות.
תרגול: בדיקת ההבנה
נניח שיצרתם מודל סיווג בינארי כדי לחזות אם למטופל חדש בבית החולים יש סרטן או לא. המודל שלכם משתמש בתכונות כמו:
- גיל המטופל
- מגדר המטופל/ת
- מצבים רפואיים קודמים
- שם בית החולים
- סימנים חיוניים
- תוצאות הבדיקה
- תורשה
התווית נראית כך:
- בוליאני: האם למטופל יש סרטן?
צריך לפצל את הנתונים בזהירות, כדי לוודא שקבוצת האימון מבודדת היטב מקבוצת האימות ומקבוצת הבדיקה. המודל עובד מצוין בקבוצת האימות ובקבוצת הבדיקה, והמדדים מצוינים. לצערנו, הביצועים של המודל נוראים אצל חולים חדשים בעולם האמיתי.
תשובה: אחת מהתכונות של המודל היא שם בית החולים. בתי חולים מסוימים מתמחים בטיפול בסרטן. במהלך האימון, המודל למד במהירות שמטופלים שהוקצו לבתי חולים מסוימים נמצאים בסיכון גבוה לחלות בסרטן. לכן, שם בית החולים הפך למאפיין בעל משקל גבוה.
בזמן ההסקה, רוב החולים עדיין לא הוקצו לבית חולים. אחרי הכל, המטרה של המודל הייתה לאבחן את נוכחות הסרטן או את היעדרותו, ולאחר מכן להשתמש באבחון הזה כדי להקצות את המטופל לבית חולים מתאים. כתוצאה מכך, במהלך ההסקה, התכונה 'שם בית החולים' עדיין לא הייתה זמינה והמודל נאלץ להסתמך על תכונות אחרות.
מעקב אחר גיל המודל לאורך צינור עיבוד הנתונים
אם נתוני ההצגה משתנים עם הזמן אבל המודל לא עובר אימון מחדש באופן קבוע, איכות המודל תרד. לעקוב אחרי הזמן שחלף מאז שהמודל הוכשר מחדש על סמך נתונים חדשים ולהגדיר ערך סף לגיל ההתראות. בנוסף למעקב אחרי גיל המודל בזמן ההצגה, כדאי לעקוב אחרי גיל המודל לאורך צינור עיבוד הנתונים כדי לזהות עיכובים בצינור עיבוד הנתונים.
בדיקה שהמשקלים והפלט של המודל יציבים מבחינה מספרית
במהלך אימון המודל, הערכים של המשקלים והפלט של השכבות לא יכולים להיות NaN (לא מספר) או Inf (אינסוף). כותבים בדיקות כדי לבדוק אם יש ערכי NaN ו-Inf במשקלים ובפלט של השכבות. בנוסף, צריך לבדוק שיותר ממחצית הפלט של השכבה לא אפס.
מעקב אחר ביצועי המודל
הכלי שלך לחיזוי מתי יופיע חד-קרן היה פופולרי יותר מהצפוי! אתם מקבלים הרבה בקשות חיזוי ועוד יותר נתוני אימון. זה נשמע נהדר, עד שמבינים שהמודל דורש יותר ויותר זיכרון וזמן אימון. אתם מחליטים לעקוב אחרי ביצועי המודל באופן הבא:
- מעקב אחר ביצועי המודל לפי גרסאות של קוד, מודל ונתונים. מעקב כזה מאפשר לכם לזהות את הסיבה המדויקת לירידה בביצועים.
- בדיקת שלבי האימון לשנייה בגרסה חדשה של מודל בהשוואה לגרסה הקודמת ולסף קבוע.
- איך לזהות דליפות זיכרון על ידי הגדרת סף לשימוש בזיכרון.
- מעקב אחר זמני התגובה של ה-API ומעקב אחר האחוזונים שלהם. יכול להיות שזמני התגובה של ה-API לא בשליטתכם, אבל תשובות איטיות עלולות לגרום למדדים נמוכים בעולם האמיתי.
- מעקב אחרי מספר השאילתות שענו עליהן בשנייה.
בדיקת האיכות של מודל פעיל על נתונים שמוצגים
אימתתם את המודל. אבל מה קורה אם תרחישים מהעולם האמיתי, כמו התנהגות של יוניקורן, משתנים אחרי תיעוד נתוני האימות? במקרה כזה, איכות המודל שיוצג תיפגע. עם זאת, קשה לבדוק את האיכות של הצגת המודעות כי נתונים מהעולם האמיתי לא תמיד מתויגים. אם נתוני ההצגה לא מתויגים, כדאי לנסות את הבדיקות הבאות:
לבדוק מודלים שמציגים הטיה סטטיסטית משמעותית בחיזויים. מידע נוסף זמין במאמר סיווג: הטיה בחיזוי.
מעקב אחרי מדדים מהעולם האמיתי של המודל. לדוגמה, אם אתם מסווגים ספאם, תוכלו להשוות בין התחזיות שלכם לבין ספאם שדווח על ידי משתמשים.
כדי לצמצם את הפער הפוטנציאלי בין נתוני האימון לנתוני ההצגה, אפשר להציג גרסה חדשה של מודל בחלק מהשאילתות. בזמן שתאמתו את מודל ההצגה החדש, כדאי להעביר בהדרגה את כל השאילתות לגרסה החדשה.
כשמשתמשים בבדיקות האלה, חשוב לעקוב גם אחרי ירידה פתאומית באיכות התחזית וגם אחרי ירידה איטית.
ארגון בסדר אקראי
יצירת צינור עיבוד נתונים ליצירת נתונים שניתן לשחזור. נניח שאתם רוצים להוסיף תכונה כדי לראות איך היא משפיעה על איכות המודל. כדי שהניסוי יהיה הוגן, מערכי הנתונים צריכים להיות זהים, מלבד התכונה החדשה הזו. בהתאם לכך, חשוב לוודא שאפשר ליצור אקראיות ביצירת הנתונים באופן דטרמיניסטי:
- הוספת זרעים למחוללי המספרים האקראיים (RNG). הזרקת נתונים מבטיחה שה-RNG יפיק את אותם ערכים באותו סדר בכל פעם שתפעילו אותו, ויצור מחדש את מערך הנתונים.
- שימוש במפתחות גיבוב לא תלויים (invariant) גיבוב הוא דרך נפוצה לפצל או לדגום נתונים. אפשר לבצע גיבוב (hash) של כל דוגמה ולהשתמש במספר המלא שהתקבל כדי להחליט באיזה פיצול להציב את הדוגמה. מקורות הקלט של פונקציית הגיבוב לא אמורים להשתנות בכל פעם שמפעילים את תוכנית יצירת הנתונים. אל תשתמשו בשעה הנוכחית או במספר אקראי בגיבוב, למשל אם אתם רוצים ליצור מחדש את הגיבובים על פי דרישה.
הגישות הקודמות רלוונטיות גם לדגימה וגם לפיצול הנתונים.
שיקולים לגבי גיבוב (hashing)
נניח שוב שאתם אוספים שאילתות חיפוש ומשתמשים בגיבוב כדי לכלול או להחריג שאילתות. אם מפתח הגיבוב השתמש רק בשאילתה, תמיד תכללו את השאילתה הזו בנתונים של כמה ימים, או תמיד תחרגו אותה. לא מומלץ לכלול או להחריג שאילתות תמיד, כי:
- קבוצת האימון תכלול קבוצה פחות מגוונת של שאילתות.
- קבוצות ההערכה יהיו קשות באופן מלאכותי, כי הן לא יחפילו על נתוני האימון. בפועל, בזמן ההצגה, חלק מהתנועה בזמן אמת תופיע בנתוני האימון, ולכן ההערכה צריכה לשקף זאת.
במקום זאת, אפשר לבצע גיבוב של השאילתה + התאריך, וכך תקבלו גיבוב שונה בכל יום.
