עכשיו אתם מוכנים לפרוס את מודל החד-קרן שמתאים לחיזוי הופעות של חד-קרן. בזמן הפריסה, צינור עיבוד הנתונים של למידת המכונה (ML) אמור לפעול, להתעדכן ולספק שירות ללא בעיות. אם רק פריסה של מודל הייתה פשוטה כמו לחיצה על לחצן גדול של פריסה. לצערנו, מערכת מלאה של למידת מכונה מחייבת בדיקות של:
- אימות נתוני הקלט.
- אימות של הנדסת פיצ'רים.
- אימות האיכות של גרסאות חדשות של מודלים.
- אימות התשתית להצגת מודעות.
- בדיקת השילוב בין רכיבי צינור עיבוד הנתונים.
הרבה מהנדסי תוכנה מעדיפים פיתוח מבוסס-בדיקה (TDD). ב-TDD, מהנדסי התוכנה כותבים בדיקות לפני כתיבת קוד המקור 'האמיתי'. עם זאת, שימוש ב-TDD יכול להיות מסובך בלמידת מכונה. לדוגמה, לפני אימון המודל, אי אפשר לכתוב בדיקה כדי לאמת את האובדן. במקום זאת, קודם צריך לזהות את ההפסד שאפשר להשיג במהלך פיתוח המודל, ורק אז לבדוק גרסאות חדשות של המודל בהשוואה להפסד שאפשר להשיג.
מידע על מודל החד-קרן
הקטע הזה מתייחס למודל החד-קרן. דברים שעליך לדעת:
אתם משתמשים בלמידת מכונה כדי ליצור מודל סיווג שחוזה את ההופעות של יוניקורן. מערך הנתונים כולל 10,000 הופעות של חד-קרן ו-10,000 הופעות ללא חד-קרן. מערך הנתונים מכיל את המיקום, השעה, הגובה, הטמפרטורה, הלחות, כיסוי העצים, נוכחות קשת ועוד כמה תכונות.
בדיקת עדכוני מודל באמצעות אימון שניתן לשחזור
אולי תרצו להמשיך לשפר את מודל החד-קרן. לדוגמה, נניח שאתם מבצעים קצת הנדסת תכונות נוספת בתכונה מסוימת ואז מאומנים מחדש את המודל, בתקווה לקבל תוצאות טובות יותר (או לפחות תוצאות זהות). לצערנו, לפעמים קשה לשחזר את אימון המודל. כדי לשפר את היכולת לשחזור, כדאי לפעול לפי ההמלצות הבאות:
הוספת זרע למחולל המספרים האקראיים באופן determinist. פרטים נוספים זמינים במאמר רנדומיזציה ביצירת נתונים.
מאתחלים את רכיבי המודל בסדר קבוע כדי לוודא שכל הרכיבים מקבלים את אותו מספר אקראי ממחולל המספרים האקראיים בכל הפעלה. בדרך כלל, ספריות ה-ML מטפלות בדרישה הזו באופן אוטומטי.
חישוב הממוצע של כמה הפעלות של המודל.
כדאי להשתמש בבקרת גרסאות, גם לגרסאות מקדימות, כדי שתוכלו לזהות קוד ופרמטרים כשאתם בודקים את המודל או צינור עיבוד הנתונים.
גם אחרי שמבצעים את ההנחיות האלה, יכול להיות שעדיין יהיו מקורות אחרים של אי-דטרמיניזם.
בדיקת קריאות ל-Machine Learning API
איך בודקים עדכונים לקריאות ל-API? אפשר לאמן מחדש את המודל, אבל זה תהליך שדורש הרבה זמן. במקום זאת, כותבים בדיקת יחידה כדי ליצור נתוני קלט אקראיים ולהריץ שלב אחד של ירידה בגרדינט. אם השלב הזה מסתיים ללא שגיאות, סביר להניח שעדכוני ה-API לא פגעו בדגם.
כתיבת בדיקות שילוב למרכיבי צינור עיבוד נתונים
בצינור עיבוד נתונים ל-ML, שינויים ברכיב אחד יכולים לגרום לשגיאות ברכיבים אחרים. כדי לבדוק שהרכיבים פועלים יחד, כותבים בדיקת אינטגרציה שמריצה את צינור עיבוד הנתונים כולו מקצה לקצה.
בנוסף להרצה רציפה של בדיקות השילוב, כדאי להריץ בדיקות שילוב כשאתם מעבירים מודלים חדשים וגרסאות תוכנה חדשות. איטיות ההרצה של צינור עיבוד הנתונים כולו מקשה על בדיקת האינטגרציה הרצייפה. כדי להריץ בדיקות אינטגרציה מהר יותר, אפשר לאמן על קבוצת משנה של הנתונים או עם מודל פשוט יותר. הפרטים תלויים במודל ובנתונים שלכם. כדי לקבל כיסוי רציף, צריך לשנות את הבדיקות המהירות כך שיפעלו בכל גרסה חדשה של המודל או התוכנה. בינתיים, הבדיקות האיטיות יפעלו ברציפות ברקע.
אימות איכות המודל לפני הצגה
לפני שמעבירים גרסה חדשה של מודל לסביבת הייצור, צריך לבדוק את שני סוגי הירידה באיכות הבאים:
פגיעה פתאומית בביצועים. באג בגרסה החדשה עלול לגרום לירידה משמעותית באיכות. אימות גרסאות חדשות על ידי בדיקת האיכות שלהן בהשוואה לגרסה הקודמת.
פגיעה איטית יכול להיות שהבדיקה שלכם לזיהוי ירידה פתאומית באיכות המודל לא תזהה ירידה איטית באיכות המודל במספר גרסאות. במקום זאת, צריך לוודא שהתחזיות של המודל בקבוצת נתונים לאימות עומדות בערך סף קבוע. אם מערך הנתונים לאימות שונה מהנתונים החיים, צריך לעדכן את מערך הנתונים לאימות ולוודא שהמודל עדיין עומד באותו סף איכות.
אימות התאימות של המודל לתשתית לפני ההצגה
אם המודל מתעדכן מהר יותר מהשרת, יכול להיות שלמודל יש יחסי תלות שונים בתוכנה בהשוואה לשרת, וזה עלול לגרום לאי-תאימות. כדי לוודא שהפעולות שבהן המודל משתמש נמצאות בשרת, צריך להעביר את המודל לגרסה של השרת בארגז חול.