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