הכול מוכן לפריסה! אם הפריסה של דגם הייתה פשוטה מאוד, היה פשוט מאוד ללחוץ על לחצן אדום גדול. בעת הפריסה, אתם רוצים שצינור עיבוד הנתונים יפעל, יעדכן ויציג את המודעות ללא תקלה. צרכים אלה מובילים לדרישות ולפתרונות המתוארים בדף זה.
בדיקת מודלים לדוגמה באמצעות אימון חוזר
אין ספק שברצונך להמשיך לשפר את חזוי חד-הקרן שלך. נניח שאתם קובעים מחדש את הקוד של הנדסת התכונות עבור התכונה "שעה ביום". איך בודקים את הקוד הנכון? אתם מחליטים לאמן מחדש את המודל ולבדוק אם קיבלתם את אותה תוצאה. אוי, אתם מגלים שהדרכה לדוגמה שלכם לא ניתנת לשחזור. אתם נחושים להמשיך ולחזות מראה חד-קרן, ואתם רוצים לחקור את הנושא. כדי לשפר את יכולת השחזור, מבצעים את השלבים הבאים:
זרע דטרמיניסטי של מחולל המספרים האקראיים (RNG). לקבלת פרטים, ראו סידור אקראי בעת יצירת נתונים מהקורס 'הכנה לנתונים' ו'הנדסת תכונות ב-ML'.
כדאי להפעיל את רכיבי המודל בסדר קבוע כדי שהרכיבים יקבלו את אותו מספר אקראי מ-RNG בכל ריצה. לרוב, ספריות למידת מכונה מטפלות בדרישה הזו באופן אוטומטי.
ממוצע של מספר ריצות של המודל.
השתמשו באמצעי הבקרה של הגרסה, גם בגרסה הראשונית, כדי שתוכלו לזהות קוד ופרמטרים בזמן הבדיקה של המודל או צינור עיבוד הנתונים.
גם לאחר ביצוע השלבים האלה, ייתכן שיש לכם מקורות נוספים לחוסר דחיפות.
בדיקת עדכוני מודל למפרטים ולקריאות ל-API
לאחר עדכון המודל ל-Unicoon Forecast. 2.0, עליכם לבדוק את המודל החדש לתקינות אלגוריתמיות, וגם לשנות כל קריאות ל-API. בואו נסביר איך.
בדיקת קריאות ל-API
איך בודקים עדכונים לקריאות ל-API? בהחלט, אפשר לאמן מחדש את המודל, אבל זו פעולה שדורשת הרבה זמן. במקום זאת, כתבו בדיקת יחידה כדי להפיק נתוני קלט אקראיים והפעילו שלב אחד של ירידה הדרגתית. אתם רוצים שהשלב יושלם בלי שגיאות בזמן הריצה.
בדיקת תקינות אלגוריתמים
לא רק שמודל יהיה מדויק, אלא גם נכון, כי הוא נכון מבחינה אלגוריתמית ובלתי מזל. לדוגמה, אם 99% מהאימיילים אינם ספאם, הסיווג של כל הודעות האימייל מפני ספאם אינו 99% במקרה. לכן, צריך לבדוק אם המודל תקין. כך תעשו זאת:
- מומלץ לאמן את המודל מספר פעמים ולוודא שהירידה נמצאת בירידה.
- אימון האלגוריתם ללא תיאום. אם המודל שלכם מורכב מספיק, הוא יזכור את נתוני ההדרכה ואובדן האימון יהיה קרוב ל-0.
- בודקים חישובים ספציפיים של אלגוריתמים. לדוגמה, אפשר לבדוק שחלק מ-RNN שלכם פועל פעם אחת לכל רכיב של נתוני הקלט.
כתיבה של בדיקות אינטגרציה לרכיבי צינור
בצינור עיבוד נתונים (ML), שינויים ברכיב אחד עשויים לגרום לשגיאות ברכיבים אחרים. בדקו אם הרכיבים פועלים יחד על ידי כתיבת בדיקה שמריצה את כל צינורות עיבוד הנתונים מקצה לקצה. בדיקה כזו נקראת בדיקת שילוב.
מלבד הפעלת בדיקות אינטגרציה שוטפות, כדאי להריץ בדיקות שילוב כשמדחוף דגמים חדשים וגרסאות חדשות של תוכנות. האיטיות של הפעלת צינור עיבוד הנתונים גורפת בעיות באינטגרציה הרציפה. כדי להריץ בדיקות שילוב מהר יותר, כדאי לאמן קבוצת משנה של הנתונים או להשתמש במודל פשוט יותר. הפרטים תלויים במודל ובנתונים. כדי לקבל כיסוי מתמשך, תצטרכו להתאים את הבדיקות המהירות יותר כך שיפעלו בכל גרסה חדשה של הדגם או התוכנה. בינתיים, הבדיקות האיטיות ירוצו ברקע.
אימות איכות המודל לפני ההצגה
לפני שאתם מעבירים גרסת מודל חדשה לייצור, נסו לבדוק את שני סוגי הבעיות האלה באיכות:
פגיעה פתאומית: באג בגרסה החדשה עלול לגרום לאיכות נמוכה באופן משמעותי. תוכלו לאמת גרסאות חדשות על ידי בדיקת האיכות שלהן בהשוואה לגרסה הקודמת.
ירידה איטית: ייתכן שהבדיקה של תקלה פתאומית לא תפגע באיכות המודל במספר גרסאות. במקום זאת, יש לוודא שהחיזויים של המודל במערך נתונים לאימות עומדים בסף קבוע. אם מערך הנתונים של האימות גובל בנתונים חיים, עדכנו את מערך הנתונים לאימות וודאו שהמודל עדיין עומד באותו סף איכות.
יש לאמת את התאימות למודלים אינפרה-אדום לפני ההצגה
אם המודל שלכם יתעדכן מהר יותר מהשרת, לדגם יהיו יחסי תלות שונים מהשרת, מה שעלול לגרום לחוסר תאימות. ודאו שהפעולות המשמשות את המודל קיימות בשרת, על ידי הכנת המודל בגרסה של ארגז החול.