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