במסמך הזה ריכזנו כמה הנחיות שיעזרו לכם להעריך את האיכות של פתרונות למידת מכונה (ML) לחיזוי, לוודא שהם איכותיים ולשלוט בהם. הוא מספק הצעות לכל שלב בתהליך, החל מפיתוח מודלים של למידת מכונה ועד לפריסת מערכות האימון ומערכות ההגשה בסביבת ייצור. המסמך הזה מרחיב את המידע שמופיע במדריך MLOps לאנשי מקצוע. הוא מתמקד בהיבטים של איכות בכל תהליך במחזור החיים של MLOps.
המסמך הזה מיועד לכל מי שמעורב בבנייה, בפריסה ובהפעלה של פתרונות למידת מכונה. במסמך הזה אנחנו מניחים שאתם מכירים את MLOps באופן כללי. הוא לא מניח שיש לכם ידע בפלטפורמה ספציפית של ML.
סקירה כללית של איכות פתרונות למידת מכונה
בהנדסת תוכנה, פותחו הרבה תקנים, תהליכים, כלים ושיטות כדי להבטיח איכות תוכנה. המטרה היא לוודא שהתוכנה פועלת כמצופה בסביבת הייצור, ושהיא עומדת בדרישות הפונקציונליות וגם בדרישות שאינן פונקציונליות. השיטות האלה כוללות נושאים כמו בדיקת תוכנה, אימות ואימות תוכנה, רישום ביומן ומעקב אחר תוכנה. ב-DevOps, השיטות האלה משולבות בדרך כלל בתהליכי CI/CD ומבוצעות באופן אוטומטי.
MLOps הוא אוסף של תהליכים ויכולות סטנדרטיים לבנייה, לפריסה ולהפעלה של מערכות ML במהירות ובאופן אמין. בדומה לפתרונות תוכנה אחרים, פתרונות תוכנה של ML מחייבים אתכם לשלב את שיטות העבודה המומלצות האלה לאיכות תוכנה וליישם אותן לאורך מחזור החיים של MLOps. השיטות האלה עוזרות לכם לוודא שהמודלים שלכם אמינים וצפויים, ושעומדים בדרישות שלכם.
עם זאת, המשימות של בנייה, פריסה והפעלה של מערכות למידת מכונה מציבות אתגרים נוספים שמחייבים שימוש בשיטות איכות מסוימות, שאולי לא רלוונטיות למערכות תוכנה אחרות. בנוסף למאפיינים של רוב מערכות התוכנה האחרות, למערכות ML יש את המאפיינים הבאים:
מערכות שתלויות בנתונים. האיכות של המודלים המאומנים ושל התחזיות שלהם תלויה בתוקף של הנתונים שמשמשים לאימון ושל הנתונים שנשלחים לבקשות חיזוי. כל מערכת תוכנה תלויה בנתונים תקפים, אבל מערכות למידת מכונה מסיקות את הלוגיקה לקבלת החלטות מהנתונים באופן אוטומטי, ולכן הן תלויות במיוחד באיכות הנתונים.
מערכות כפולות לאימון ולהצגת מודלים. עומסי עבודה של ML מורכבים בדרך כלל משתי מערכות ייצור נפרדות אך קשורות: מערכת האימון ומערכת ההצגה. פייפליין של אימון רציף יוצר מודלים שאומנו לאחרונה, ואז פורס אותם להצגת תחזיות. כל מערכת דורשת קבוצה שונה של שיטות איכותיות שמאזנות בין יעילות לאפקטיביות, כדי ליצור ולתחזק מודל עם ביצועים טובים בסביבת הייצור. בנוסף, חוסר עקביות בין שתי המערכות האלה מוביל לשגיאות ולביצועים נמוכים של התחזיות.
נוטה להתיישנות. הביצועים של מודלים רבים יורדים אחרי הפריסה שלהם בסביבת ייצור, כי המודלים לא מצליחים להסתגל לשינויים בסביבה שהם מייצגים, כמו שינויים עונתיים בהתנהגות הקנייה. בנוסף, יכול להיות שהמודלים לא יצליחו להסתגל לשינויים בנתונים, כמו מוצרים ומיקומים חדשים. לכן, מעקב אחר יעילות המודל בסביבת הייצור הוא אתגר נוסף במערכות למידת מכונה.
מערכות אוטומטיות לקבלת החלטות. בניגוד למערכות תוכנה אחרות, שבהן הפעולות מקודדות באופן ידני בהתאם למערכת דרישות ולכללים עסקיים, מודלים של ML לומדים כללים מנתונים כדי לקבל החלטה. הטיה מובלעת בנתונים עלולה לגרום למודלים להפיק תוצאות לא הוגנות.
כשמודל של למידת מכונה שנפרס מפיק תחזיות לא טובות, האיכות הירודה של למידת המכונה יכולה להיות תוצאה של מגוון רחב של בעיות. חלק מהבעיות האלה יכולות לנבוע מבאגים אופייניים שקיימים בכל תוכנה. אבל בעיות ספציפיות ללמידת מכונה יכולות לכלול גם הטיה ואנומליות בנתונים, וגם היעדר של הליכי הערכה ואימות נאותים של המודל כחלק מתהליך האימון. בעיה פוטנציאלית נוספת היא פורמט נתונים לא עקבי בין הממשק המובנה של המודל לבין ה-API להצגת מודעות. בנוסף, ביצועי המודל יורדים עם הזמן גם ללא הבעיות האלה, והוא עלול להיכשל בשקט אם לא מנטרים אותו בצורה נכונה. לכן, חשוב לכלול סוגים שונים של בדיקות ומעקב למודלים ולמערכות של למידת מכונה במהלך הפיתוח, במהלך הפריסה ובסביבת הייצור.
הנחיות איכות לפיתוח מודלים
כשמפתחים מודל למידת מכונה במהלך שלב הניסוי, יש שני סוגים של מדדי יעד שאפשר להשתמש בהם כדי להעריך את הביצועים של המודל:
- מדדי האופטימיזציה של המודל. המדד הזה משקף את יעילות החיזוי של המודל. המדד כולל דיוק ומדד F במשימות סיווג, שגיאת אחוז ממוצעת מוחלטת במשימות רגרסיה ותחזית, רווח מצטבר מוזל במשימות דירוג, וציוני פרפלקסיטי ו-BLEU במודלים של שפה. ככל שהערך של המדד הזה גבוה יותר, כך המודל מתאים יותר למשימה מסוימת. במקרים מסוימים, כדי להבטיח הוגנות, חשוב להשיג יעילות חיזויית דומה בפלחים שונים של הנתונים – למשל, בפלחים שונים של נתונים דמוגרפיים של לקוחות.
- מדדי האופטימיזציה של המודל. המדד הזה משקף מגבלה תפעולית שהמודל צריך לעמוד בה, כמו זמן האחזור של התחזית. מגדירים ערך סף לזמן האחזור, למשל 200 אלפיות השנייה. לא ניתן להשתמש בדגמים שלא עומדים בסף. דוגמה נוספת למדד מספק היא גודל המודל, שחשוב כשרוצים לפרוס את המודל בחומרה עם צריכת חשמל נמוכה, כמו מכשירים ניידים ומכשירים מוטמעים.
במהלך הניסוי, מפתחים, מאמנים, מעריכים ומאתרים באגים במודל כדי לשפר את היעילות שלו ביחס למדדי האופטימיזציה, בלי לחרוג מסף מדדי האופטימיזציה.
הנחיות לניסויים
- יש ערכי סף קבועים ומוגדרים מראש לאופטימיזציה של מדדים ולמדדים מספקים.
- הטמעת שגרת הערכה יעילה שמקבלת מודל ונתונים ומפיקה קבוצה של מדדי הערכה. מטמיעים את השגרה כך שהיא תפעל ללא קשר לסוג המודל (לדוגמה, עצי החלטה או רשתות עצביות) או למסגרת של המודל (לדוגמה, TensorFlow או Scikit-learn).
- מוודאים שיש לכם מודל בסיסי להשוואה. הבסיס הזה יכול להיות מורכב מהיוריסטיקות שמוטמעות בקוד, או שהוא יכול להיות מודל פשוט שמנבא את ערך היעד הממוצע או השכיח. משתמשים במודל הבסיס כדי לבדוק את הביצועים של המודל ללמידת מכונה. אם המודל ללמידת מכונה לא טוב יותר ממודל הבסיס, יש בעיה מהותית במודל ללמידת מכונה.
- כדאי לעקוב אחרי כל ניסוי שבוצע כדי לשפר את השחזור ואת השיפור המצטבר. בכל ניסוי, מאחסנים את ערכי ההיפרפרמטרים, את בחירת התכונות ואת זרעי המספרים האקראיים.
הנחיות לאיכות הנתונים
- כדי לטפל בחוסר איזון בין המחלקות בשלב מוקדם של הניסויים, צריך לבחור את מדד ההערכה הנכון. בנוסף, אפשר להשתמש בטכניקות כמו הגדלת המשקל של מקרים של מחלקות מיעוט או דילול של מקרים של מחלקות רוב.
- חשוב להבין את מקור הנתונים שבו משתמשים ולבצע את העיבוד המקדים של הנתונים והנדסת פיצ'רים (feature engineering) שרלוונטיים כדי להכין את מערך נתוני האימון. תהליך מהסוג הזה צריך להיות ניתן לחזרה ולאוטומציה.
- חשוב לוודא שיש לכם חלוקה נפרדת של נתוני בדיקה (קבוצת בקרה) להערכה הסופית של המודל. אסור להשתמש במערך הנתונים של הבדיקה במהלך האימון, וגם לא לכוונן את ההיפר-פרמטרים.
- חשוב לוודא שחלוקת הנתונים לאימון, לאימות ולבדיקה מייצגת באופן שווה את נתוני הקלט. הדגימה של פיצול כזה של נתונים תלויה באופי הנתונים ובמשימת למידת המכונה שצריך לבצע. לדוגמה, פיצול שכבות רלוונטי למשימות סיווג, בעוד שפיצול כרונולוגי רלוונטי למשימות של סדרות עיתיות.
- חשוב לוודא שפיצולי האימות והבדיקה עוברים עיבוד מקדים בנפרד מפיצול נתוני האימון. אם הפיצולים עוברים עיבוד מראש בתערובת, זה מוביל לזליגת נתונים. לדוגמה, כשמשתמשים בסטטיסטיקה כדי לשנות נתונים לצורך נרמול או כדי לחלק תכונות מספריות לקטגוריות, צריך לחשב את הסטטיסטיקה מנתוני האימון ולהחיל אותה כדי לנרמל את נתוני האימות והפיצול של נתוני הבדיקה.
- יצירת סכימה של מערך נתונים שכוללת את סוגי הנתונים וחלק מהמאפיינים הסטטיסטיים של התכונות. אתם יכולים להשתמש בסכימה הזו כדי למצוא נתונים חריגים או לא תקינים במהלך ניסויים ואימונים.
- חשוב לוודא שנתוני האימון מעורבבים בצורה נכונה באצוות, אבל גם עומדים בדרישות לאימון המודל. לדוגמה, המשימה הזו יכולה לחול על התפלגויות חיוביות ושליליות של מופעים.
- להשתמש במערך נפרד של נתוני אימות לצורך כוונון היפרפרמטרים ובחירת מודל. אפשר גם להשתמש במערך הנתונים של האימות כדי לבצע עצירה מוקדמת. אחרת, אפשר לאמן את המודל למשך כל קבוצת האיטרציות המקסימלית שצוינה. עם זאת, כדאי לשמור תמונת מצב חדשה של המודל רק אם הביצועים שלו במערך נתוני האימות משתפרים בהשוואה לתמונת המצב הקודמת.
הנחיות לגבי איכות המודל
- חשוב לוודא שאין בעיות בסיסיות במודלים שמונעות מהם ללמוד את הקשר בין הקלט לפלט. כדי להשיג את המטרה הזו, אפשר לאמן את המודל עם מעט מאוד דוגמאות. אם המודל לא משיג רמת דיוק גבוהה בדוגמאות האלה, יכול להיות שיש באג בהטמעה של המודל או בשגרת האימון שלו.
- כשמאמנים רשתות עצביות, צריך לעקוב אחרי ערכי
NaNבהפסד ואחרי אחוז המשקלים עם ערכים אפסיים במהלך אימון המודל. הערכים האלהNaNאו אפס יכולים להצביע על חישובים אריתמטיים שגויים, או על שיפועים נעלמים או מתפוצצים. הצגה חזותית של השינויים בהתפלגות של ערכי המשקל לאורך זמן יכולה לעזור לכם לזהות שינויים פנימיים במשתנים משותפים שמאטים את תהליך האימון. כדי למתן את הירידה הזו במהירות, אפשר להחיל נורמליזציה של קבוצות. - משווים את ביצועי המודל בנתוני האימון ובנתוני הבדיקה כדי להבין אם המודל מתאים יתר על המידה לנתונים או מתאים פחות מדי לנתונים. אם אתם רואים את אחת מהבעיות האלה, אתם צריכים לבצע את השיפורים הרלוונטיים. לדוגמה, אם יש התאמת חסר, אפשר להגדיל את יכולת הלמידה של המודל. אם הייתה התאמת יתר, יכול להיות שכדאי להחיל רגולריזציה.
- כדאי לנתח מקרים שסווגו בצורה שגויה, במיוחד את המקרים שבהם רמת הביטחון של התחזית גבוהה ואת המחלקות שהכי קשה להבחין ביניהן במטריצת השגיאות של הסיווג הרב-מחלקתי. השגיאות האלה יכולות להצביע על דוגמאות לאימון שסומנו בצורה שגויה. השגיאות יכולות גם להצביע על הזדמנות לעיבוד מקדים של נתונים, כמו הסרת ערכים חריגים או יצירת תכונות חדשות שיעזרו להבחין בין הסיווגים האלה.
- לנתח את ציוני החשיבות של התכונות ולנקות תכונות שלא משפרות מספיק את איכות המודל. מודלים חסכוניים עדיפים על מודלים מורכבים.
הנחיות איכות לפריסת צינורות עיבוד נתונים לאימון
במהלך ההטמעה של המודל וצינור עיבוד הנתונים לאימון המודל, צריך ליצור סדרה של בדיקות בתהליך CI/CD. הבדיקות האלה מופעלות אוטומטית כשמעבירים שינויים חדשים בקוד, או שהן מופעלות לפני שמפעילים את צינור ההדרכה בסביבת היעד.
הנחיות
- בדיקת יחידות של הפונקציונליות של הנדסת פיצ'רים (feature engineering).
- בדיקת יחידה של הקידוד של נתוני הקלט למודל.
- בדיקת יחידה של מודולים שהמשתמש הטמיע (מותאמים אישית) במודלים באופן עצמאי – לדוגמה, בדיקת יחידה של שכבות איחוד ושכבות קונבולוציה של גרפים בהתאמה אישית, או שכבות תשומת לב בהתאמה אישית.
- מומלץ לבצע בדיקות יחידה לכל פונקציית אובדן או פונקציית הערכה בהתאמה אישית.
- בודקים את סוגי הפלט והצורות של המודל על נתונים צפויים.
- מריצים בדיקת יחידה כדי לוודא שהפונקציה
fitשל המודל פועלת ללא שגיאות בכמה קבוצות קטנות של נתונים. בבדיקות צריך לוודא שההפסד יורד וזמן הביצוע של שלב האימון הוא כצפוי. הבדיקות האלה חשובות כי שינויים בקוד של המודל עלולים לגרום לבאגים שיאטו את תהליך האימון. - בדיקת יחידה של פונקציית השמירה והטעינה של המודל.
- בודקים את הממשקים של המודל המיוצא באמצעות בדיקות יחידה, על סמך קלט גולמי ופלט צפוי.
- בודקים את הרכיבים של שלבי הצינור באמצעות קלט מדומה ופריטי פלט.
- פורסים את צינור עיבוד הנתונים בסביבת בדיקה ומבצעים בדיקת שילוב של צינור עיבוד הנתונים מקצה לקצה. במהלך התהליך הזה, כדאי להשתמש בנתוני בדיקה כדי לוודא שהתהליך מתבצע בצורה תקינה לכל אורכו ושהוא יוצר את הארטיפקטים הצפויים.
- מומלץ להשתמש בפריסת צללים כשפורסים גרסה חדשה של צינור ההדרכה בסביבת הייצור. פריסת צללים עוזרת לוודא שגרסת הצינור החדשה שנפרסה מופעלת על נתונים פעילים במקביל לגרסת הצינור הקודמת.
הנחיות איכות להדרכה מתמשכת
תהליך האימון הרציף הוא תהליך של תזמור ואוטומציה של הפעלת צינורות אימון. תהליכי עבודה אופייניים לאימון כוללים שלבים כמו הטמעת נתונים ופיצול שלהם, טרנספורמציה של נתונים, אימון מודלים, הערכת מודלים ורישום מודלים. חלק מצינורות ההדרכה מורכבים מתהליכי עבודה מורכבים יותר. משימות נוספות יכולות לכלול ביצוע אימון של מודל בפיקוח עצמי שמשתמש בנתונים לא מסומנים, או בנייה של אינדקס של שכבות הטמעה של השכן הקרוב המשוער. הקלט העיקרי של כל צינור אימון הוא נתוני אימון חדשים, והפלט העיקרי הוא מודל מועמד חדש לפריסה בסביבת ייצור.
צינור ההדרכה פועל בסביבת הייצור באופן אוטומטי, על סמך לוח זמנים (לדוגמה, יומי או שבועי) או על סמך טריגר (לדוגמה, כשנתונים חדשים עם תוויות זמינים). לכן, צריך להוסיף שלבים לבקרת איכות לתהליך העבודה של האימון, במיוחד שלבים לאימות נתונים ושלבים לאימות מודלים. בשלבים האלה מאמתים את הקלטים ואת הפלטים של צינורות העיבוד.
מוסיפים את שלב אימות הנתונים אחרי שלב הטמעת הנתונים בתהליך העבודה של האימון. בשלב אימות הנתונים, המערכת יוצרת פרופיל של נתוני האימון החדשים שמוזנים לצינור העיבוד. במהלך יצירת הפרופיל, צינור עיבוד הנתונים משתמש בסכימת נתונים מוגדרת מראש, שנוצרה במהלך תהליך פיתוח ה-ML, כדי לזהות אנומליות. בהתאם לתרחיש השימוש, אפשר להתעלם מחלק מהרשומות הלא תקינות בקבוצת הנתונים או פשוט להסיר אותן. עם זאת, בעיות אחרות בנתונים החדשים שהועברו יכולות לעצור את ההרצה של צינור ההכשרה, ולכן צריך לזהות את הבעיות האלה ולטפל בהן.
הנחיות לאימות נתונים
- מוודאים שהתכונות של נתוני האימון שחולצו מלאות ושהן תואמות לסכימה הצפויה – כלומר, אין תכונות חסרות ואין תכונות נוספות. כדאי גם לוודא שהתכונות תואמות לנפחים הצפויים.
- מאמתים את סוגי הנתונים ואת הצורות של התכונות במערך הנתונים שמוזנים לצינור האימון.
- מוודאים שהפורמטים של תכונות מסוימות (לדוגמה, תאריכים, שעות, כתובות URL, מיקודים וכתובות IP) תואמים לביטויים הרגולריים הצפויים. כדאי גם לוודא שהתכונות נמצאות בטווחים תקפים.
- בודקים את החלק המקסימלי של הערכים החסרים לכל תכונה. אם יש הרבה ערכים חסרים בתכונה מסוימת, זה יכול להשפיע על אימון המודל. ערכים חסרים בדרך כלל מצביעים על מקור לא מהימן של תכונה.
- מאמתים את הדומיינים של תכונות הקלט. לדוגמה, כדאי לבדוק אם יש שינויים באוצר המילים של מאפיינים קטגוריים או שינויים בטווח של מאפיינים מספריים, ולבצע התאמות בהתאם לעיבוד המקדים של הנתונים. דוגמה נוספת: טווחים של מאפיינים מספריים עשויים להשתנות אם עדכון במערכת במעלה הזרם שמאכלסת את המאפיינים משתמש ביחידות מידה שונות. לדוגמה, המערכת במעלה הזרם עשויה לשנות את המטבע מדולרים לין, או לשנות את המרחקים מקילומטרים למטרים.
- מוודאים שההתפלגויות של כל תכונה תואמות לציפיות שלכם.
לדוגמה, יכול להיות שתבדקו שהערך הנפוץ ביותר של מאפיין סוג התשלום הוא
cash, ושהערך הזה מייצג 50% מכל הערכים. עם זאת, הבדיקה הזו עלולה להיכשל אם יש שינוי בסוג התשלום הנפוץ ביותר ל-credit_card. שינוי חיצוני כזה עשוי לדרוש שינויים במודל.
מוסיפים שלב של אימות המודל לפני שלב רישום המודל כדי לוודא שרק מודלים שעומדים בקריטריוני האימות נרשמים לפריסה בסביבת הייצור.
הנחיות לאימות מודלים
- לצורך ההערכה הסופית של המודל, צריך להשתמש בחלוקה נפרדת לבדיקה שלא נעשה בה שימוש לאימון המודל או לכוונון של היפר-פרמטרים.
- מחשבים את הציון של המודל המועמד בהשוואה לפיצול של נתוני הבדיקה, מחשבים את מדדי ההערכה הרלוונטיים ומוודאים שהמודל המועמד עובר את ספי האיכות שהוגדרו מראש.
- כדי להתחשב בדפוסי נתונים שונים, חשוב לוודא שחלוקת נתוני הבדיקה מייצגת את הנתונים כמכלול. בנתונים של סדרות עיתיות, חשוב לוודא שפיצול הבדיקה מכיל נתונים עדכניים יותר מפיצול האימון.
- בודקים את איכות המודל בפלחים חשובים של נתונים, כמו משתמשים לפי מדינה או סרטים לפי ז'אנר. אם בודקים נתונים מפולחים, אפשר להימנע מבעיה שבה בעיות בביצועים ברמת פירוט גבוהה מוסתרות על ידי מדד סיכום גלובלי.
- הערכה של המודל הנוכחי (המוביל) בהשוואה לפיצול של נתוני הבדיקה, והשוואה שלו למודל המועמד (המתחרה) שנוצר על ידי צינור האימון.
- כדאי לאמת את המודל באמצעות מדדי הוגנות כדי לזהות הטיה מובלעת. לדוגמה, הטיה מובלעת עשויה להיגרם בגלל חוסר גיוון בנתוני האימון. אינדיקטורים של הוגנות יכולים לחשוף בעיות בשורש שצריך לטפל בהן לפני שמפעילים את המודל בסביבת ייצור.
במהלך אימון רציף, אפשר לאמת את המודל באמצעות מדדים של אופטימיזציה ומדדים של שביעות רצון. לחלופין, אפשר לאמת את המודל רק מול מדדי האופטימיזציה, ולדחות את האימות מול מדד האופטימיזציה המספקת עד לשלב הפריסה של המודל. אם אתם מתכננים לפרוס וריאציות של אותו מודל בסביבות שונות או בעומסי עבודה שונים, יכול להיות שעדיף לדחות את האימות מול מדד האופטימיזציה. יכול להיות שסביבות או עומסי עבודה שונים (כמו סביבות ענן לעומת סביבות במכשיר, או סביבות בזמן אמת לעומת סביבות של שליפת נתונים ב-batch) ידרשו ספי איכות שונים. אם אתם פורסים לכמה סביבות, יכול להיות שצינור האימונים הרציף שלכם יאמן שני מודלים או יותר, כשכל מודל מותאם לסביבת הפריסה הייעודית שלו. מידע נוסף ודוגמה זמינים במאמר בנושא פריסות כפולות ב-Vertex AI.
ככל שתכניסו יותר צינורות עיבוד נתונים של אימון רציף עם תהליכי עבודה מורכבים לסביבת הייצור, תצטרכו לעקוב אחרי המטא-נתונים והארטיפקטים שנוצרים בהרצת צינור עיבוד הנתונים. מעקב אחרי המידע הזה עוזר לכם לאתר ולנפות באגים בכל בעיה שעלולה להתעורר בסביבת הייצור. מעקב אחרי המידע גם עוזר לשחזר את התוצאות של צינורות העיבוד, כדי שתוכלו לשפר את ההטמעה שלהם באיטרציות הבאות של פיתוח למידת מכונה.
הנחיות למעקב אחרי מטא-נתונים וארטיפקטים של ML
- מעקב אחר שושלת היוחסין של קוד המקור, צינורות עיבוד הנתונים שנפרסו, רכיבים של צינורות עיבוד הנתונים, הרצות של צינורות עיבוד הנתונים, מערך הנתונים שבשימוש והארטיפקטים שנוצרו.
- מעקב אחרי ההיפר-פרמטרים וההגדרות של הרצות צינור עיבוד הנתונים.
- מעקב אחרי קלט עיקרי וארטיפקטים של פלט בשלבי הצינור, כמו נתונים סטטיסטיים של מערכי נתונים, אנומליות במערכי נתונים (אם יש), נתונים וסכימות שעברו טרנספורמציה, נקודות ביקורת של מודלים ותוצאות של הערכת מודלים.
- עוקבים אחרי השלבים המותנים בצינור העיבוד שמופעלים בתגובה לתנאים, ומוסיפים מנגנונים לשינוי כדי להבטיח יכולת מעקב למקרה ששלבים מרכזיים לא יפעלו או ייכשלו.
הנחיות איכות לפריסת מודלים
נניח שיש לכם מודל מאומן שעבר אימות מנקודת המבט של מדדי האופטימיזציה, ושהמודל אושר מנקודת המבט של ניהול המודל (כפי שמתואר בהמשך בקטע ניהול המודל). המודל מאוחסן במרשם המודלים ומוכן לפריסה בסביבת ייצור. בשלב הזה, צריך להטמיע סדרה של בדיקות כדי לוודא שהמודל מתאים להצגה בסביבת היעד שלו. בנוסף, צריך להפוך את הבדיקות האלה לאוטומטיות בשגרה של CI/CD של מודל.
הנחיות
- מוודאים שאפשר לטעון את ארטיפקט המודל ולהפעיל אותו בהצלחה עם יחסי התלות שלו בזמן הריצה. כדי לבצע את האימות הזה, צריך להכין את המודל בגרסת ארגז חול של סביבת ההצגה. האימות הזה עוזר לוודא שהפעולות והקבצים הבינאריים שבהם נעשה שימוש במודל נמצאים בסביבה.
- מאמתים את מדדי האופטימיזציה של המודל (אם יש כאלה) בסביבת פיתוח, כמו גודל המודל והחביון.
- מבצעים בדיקת יחידה לממשקי ההגשה של ארטיפקט המודל בסביבת Staging, על סמך קלט גולמי ועל סמך פלט צפוי.
- מבצעים בדיקת יחידה של ארטיפקט המודל בסביבת Staging עבור קבוצה של מקרים אופייניים וקיצוניים של בקשות לחיזוי. לדוגמה, בדיקת יחידה של מופע בקשה שבו כל התכונות מוגדרות לערך
None. - אחרי שמפרסים את API של שירות המודל בסביבת היעד, מבצעים בדיקת עשן. כדי לבצע את הבדיקה הזו, שולחים מופע יחיד או קבוצה של מופעים לשירות המודל ומאמתים את תגובת השירות.
- מריצים בדיקת קנרי לגרסת המודל החדשה שהופעלה על זרם קטן של נתונים פעילים שמוצגים למשתמשים. הבדיקה הזו מוודאת ששירות המודל החדש לא יפיק שגיאות לפני שהמודל יוצג למספר גדול של משתמשים.
- מומלץ לבצע בדיקה בסביבת פיתוח שאפשר לחזור בה במהירות ובבטחה לגרסה קודמת של מודל שמוצג.
- ביצוע ניסויים אונליין כדי לבדוק את המודל שאומן לאחרונה באמצעות קבוצת משנה קטנה של האוכלוסייה שמקבלת את השירות. בבדיקה הזו נמדדים הביצועים של המודל החדש בהשוואה למודל הנוכחי. אחרי שתשוו את הביצועים של המודל החדש לביצועים של המודל הנוכחי, תוכלו להחליט להפעיל את המודל החדש באופן מלא כדי שישמש את כל הבקשות שלכם לחיזוי בזמן אמת. טכניקות לניסויים אונליין כוללות בדיקות A/B וMulti-Armed Bandit (MAB).
הנחיות איכות לפרסום המודל
בדרך כלל, הביצועים החיזויים של מודלים של למידת מכונה שנפרסים ומופעלים בסביבת ייצור יורדים עם הזמן. הירידה הזו יכולה לנבוע מחוסר עקביות בין התכונות שמוצגות לבין התכונות שהמודל מצפה להן. חוסר העקביות הזה נקרא הטיה בין אימון להצגה. לדוגמה, יכול להיות שמודל המלצות מצפה לערך קלט אלפאנומרי לתכונה כמו קוד של מוצר שנצפה לאחרונה. אבל במקום זאת, שם המוצר מועבר במהלך ההצגה ולא קוד המוצר, בגלל עדכון באפליקציה שצורכת את שירות המודל.
בנוסף, המודל עלול להפוך ללא פעיל כשהמאפיינים הסטטיסטיים של נתוני ההצגה משתנים עם הזמן, והדפוסים שנלמדו על ידי המודל הנוכחי שנפרס כבר לא מדויקים. בשני המקרים, המודל לא יכול יותר לספק תחזיות מדויקות.
כדי למנוע את הירידה הזו בביצועי החיזוי של המודל, צריך לבצע מעקב רציף אחר היעילות של המודל. המעקב מאפשר לכם לוודא באופן קבוע ויזום שביצועי המודל לא יורדים.
הנחיות
- רישום ביומן של מדגם של מטען ייעודי (payload) של בקשות ותגובות להצגת מודעות במאגר נתונים לצורך ניתוח שוטף. הבקשה היא מופע הקלט, והתשובה היא התחזית שהמודל יוצר עבור מופע הנתונים הזה.
- הטמעה של תהליך אוטומטי ליצירת פרופיל של נתוני הבקשה והתגובה המאוחסנים באמצעות חישוב של נתונים סטטיסטיים תיאוריים. חישוב ואחסון של נתוני הצגת המודעות במרווחי זמן קבועים.
- כדי לזהות הטיה בין נתוני האימון לנתוני ההגשה שנגרמת כתוצאה משינוי בנתונים, משווים את הנתונים הסטטיסטיים של נתוני ההגשה לנתונים הסטטיסטיים של נתוני האימון. בנוסף, אפשר לנתח את השינויים בנתונים הסטטיסטיים של הצגת המודעות לאורך זמן.
- לזהות סחף מושגים על ידי ניתוח השינויים שחלים לאורך זמן בשיוך התכונות לתחזיות.
- זיהוי מקרים של נתוני הצגה שנחשבים לחריגים ביחס לנתוני האימון. כדי למצוא את החריגים האלה, אפשר להשתמש בטכניקות של זיהוי חריגים ולעקוב אחרי השינויים באחוז החריגים בנתוני ההצגה לאורך זמן.
- הגדרת התראות למקרים שבהם המודל מגיע לספי התוצאות של הטיית הנתונים בתכונות החיזויות העיקריות במערך הנתונים.
- אם יש תוויות (כלומר, ערכי סף), מצמידים את התוויות האמיתיות לתוויות החזויות של מופעי ההצגה כדי לבצע הערכה רציפה. הגישה הזו דומה למערכת ההערכה שמטמיעים כבדיקת A/B במהלך ניסויים אונליין. הערכה רציפה יכולה לזהות לא רק את יכולת החיזוי של המודל בסביבת הייצור, אלא גם את סוג הבקשה שהוא מבצע היטב ואת סוג הבקשה שהוא מבצע בצורה גרועה.
- אתם יכולים להגדיר יעדים למדדי מערכת שחשובים לכם ולמדוד את הביצועים של המודלים בהתאם ליעדים האלה.
- כדאי לעקוב אחרי יעילות השירות כדי לוודא שהמודל יכול לפעול בסביבת ייצור בקנה מידה גדול. המעקב הזה גם עוזר לכם לחזות את תכנון הקיבולת ולנהל אותו, וגם להעריך את העלות של תשתית ההצגה. מעקב אחרי מדדי יעילות, כולל ניצול CPU, ניצול GPU, ניצול זיכרון, זמן אחזור של שירות, קצב העברת נתונים ושיעור שגיאות.
פיקוח על מודלים
ניהול מודלים הוא פונקציה מרכזית בחברות, שמספקת הנחיות ותהליכים שיעזרו לעובדים ליישם את עקרונות ה-AI של החברה. העקרונות האלה יכולים לכלול הימנעות ממודלים שיוצרים או מחזקים הטיה, ויכולת להצדיק החלטות שהתקבלו על ידי AI. פונקציית ניהול המודל מוודאת שיש אדם בתהליך. בדיקה אנושית חשובה במיוחד לעומסי עבודה רגישים עם השפעה גבוהה (לרוב כאלה שפונים למשתמשים). עומסי עבודה כאלה יכולים לכלול ניקוד של סיכון אשראי, דירוג של מועמדים למשרה, אישור של פוליסות ביטוח והפצת מידע ברשתות החברתיות.
הנחיות
- לכל מודל יש מטריצת הקצאת אחריות לפי משימה. במטריצה צריך להתייחס לצוותים חוצי-ארגון (יחידות עסקיות, הנדסת נתונים, מדעי הנתונים, הנדסת למידת מכונה, סיכונים ותאימות וכו') לאורך כל ההיררכיה הארגונית.
- שמירה של תיעוד ודיווח על המודל במרשם המודלים שמקושר לגרסה של המודל – למשל, באמצעות כרטיסי מודל. המטא-נתונים האלה כוללים מידע על הנתונים ששימשו לאימון המודל, על ביצועי המודל ועל מגבלות ידועות.
- לפני שמאשרים את המודל לפריסה בסביבת הייצור, צריך להטמיע תהליך בדיקה. בתהליך כזה, אתם שומרים גרסאות של רשימת המשימות של המודל, מסמכים משלימים וכל מידע נוסף שבעלי העניין עשויים לבקש.
- הערכת המודל על מערכי נתונים של נקודות השוואה (שנקראים גם מערכי נתונים מושלמים), שכוללים גם מקרים רגילים וגם מקרים חריגים. בנוסף, כדאי לאמת את המודל באמצעות מדדי הוגנות כדי לזהות הטיה מרומזת.
- הסבר למשתמשים במודל על התנהגות החיזוי של המודל באופן כללי ועל מקרים ספציפיים של קלט לדוגמה. המידע הזה יעזור לכם להבין תכונות חשובות של המודל והתנהגויות לא רצויות אפשריות שלו.
- כדי להבין את החשיבות של תכונות נתונים שונות, אפשר לנתח את התנהגות החיזוי של המודל באמצעות כלים לניתוח תרחישים. הניתוח הזה יכול גם לעזור לכם להמחיש את התנהגות המודל בכמה מודלים ובקבוצות משנה של נתוני קלט.
- כדאי לבדוק את המודל מפני מתקפות מבלבלות כדי לוודא שהוא עמיד בפני ניצול לרעה בסביבת הייצור.
- מעקב אחרי התראות על הביצועים החזויים של מודלים שנמצאים בייצור, על שינויים במערכי נתונים ועל סחף. מגדירים את ההתראות כך שבעלי העניין במודל יקבלו אותן.
- ניהול של ניסויים אונליין, השקה וחזרה לגרסה קודמת של המודלים.
המאמרים הבאים
- מומלץ לקרוא את המאמר The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction של Google Research.
- מומלץ לקרוא את המאמר A Brief Guide to Running ML Systems in Production של O'Reilly.
- קוראים את הכללים ללמידת מכונה.
- כדאי לנסות את ההדרכה בנושא בדיקה וניפוי באגים בלמידת מכונה.
- מומלץ לקרוא את המאמר בנושא אימות נתונים בלמידת מכונה.
- אפשר לעיין במאגר הקוד E2E MLOps on Google Cloud.
- סקירה כללית של עקרונות והמלצות לארכיטקטורה שספציפיים לעומסי עבודה של AI ו-ML ב- Google Cloudזמינה בפרספקטיבת ה-AI וה-ML ב-Well-Architected Framework.
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
הכותב: Mike Styer | אדריכל פתרונות AI גנרטיבי
תורם תוכן נוסף: Amanda Brinhosa | Customer Engineer