במסמך הזה ריכזנו כמה הנחיות שיעזרו לכם להעריך את האיכות של פתרונות למידת מכונה (ML) לחיזוי, לוודא שהם איכותיים ולשלוט בהם. הוא מספק הצעות לכל שלב בתהליך, החל מפיתוח מודלים של למידת מכונה ועד לפריסת מערכות האימון ומערכות ההגשה בסביבת ייצור. המסמך הזה מרחיב את המידע שמופיע במדריך MLOps לאנשי מקצוע. הוא מתמקד בהיבטים של איכות בכל תהליך במחזור החיים של MLOps.
המסמך הזה מיועד לכל מי שמעורב בפיתוח, בפריסה ובהפעלה של פתרונות למידת מכונה. המסמך הזה מניח שאתם מכירים את MLOps באופן כללי. הוא לא מניח שיש לכם ידע בפלטפורמה ספציפית של ML.
סקירה כללית של איכות פתרון למידת מכונה
בהנדסת תוכנה, פותחו הרבה תקנים, תהליכים, כלים ושיטות כדי להבטיח איכות תוכנה. המטרה היא לוודא שהתוכנה פועלת כמצופה בסביבת הייצור, ושהיא עומדת בדרישות הפונקציונליות וגם בדרישות שאינן פונקציונליות. השיטות האלה כוללות נושאים כמו בדיקות תוכנה, אימות וולידציה של תוכנה, רישום ביומן ומעקב אחר תוכנה. ב-DevOps, השיטות האלה משולבות בדרך כלל בתהליכי CI/CD ואוטומטיות.
MLOps הוא אוסף של תהליכים ויכולות סטנדרטיים לבנייה, לפריסה ולהפעלה של מערכות למידת מכונה במהירות ובאופן אמין. בדומה לפתרונות תוכנה אחרים, פתרונות תוכנה של ML מחייבים אתכם לשלב את שיטות העבודה המומלצות האלה לאורך מחזור החיים של MLOps. השיטות האלה עוזרות לוודא שהמודלים שלכם אמינים וצפויים, ושעומדים בדרישות שלכם.
עם זאת, המשימות של בנייה, פריסה והפעלה של מערכות למידת מכונה מציבות אתגרים נוספים שמחייבים שימוש בשיטות מסוימות לשמירה על איכות, שיכול להיות שלא רלוונטיות למערכות תוכנה אחרות. בנוסף למאפיינים של רוב מערכות התוכנה האחרות, למערכות ML יש את המאפיינים הבאים:
מערכות שתלויות בנתונים. האיכות של המודלים המאומנים ושל התחזיות שלהם תלויה בתוקף של הנתונים שמשמשים לאימון ושל הנתונים שנשלחים לבקשות חיזוי. כל מערכת תוכנה תלויה בנתונים תקפים, אבל מערכות למידת מכונה מסיקות את הלוגיקה לקבלת החלטות מהנתונים באופן אוטומטי, ולכן הן תלויות במיוחד באיכות הנתונים.
מערכות כפולות לאימון ולהצגת מודלים. עומסי עבודה של ML מורכבים בדרך כלל משתי מערכות ייצור נפרדות אך קשורות: מערכת האימון ומערכת ההצגה. פייפליין של אימון רציף יוצר מודלים שאומנו לאחרונה, ואז פורס לצורך מילוי בקשות לחיזוי. כל מערכת דורשת קבוצה שונה של שיטות איכותיות שמאזנות בין יעילות לאפקטיביות, כדי ליצור מודל עם ביצועים טובים בסביבת הייצור ולשמור עליו. בנוסף, חוסר עקביות בין שתי המערכות האלה מוביל לשגיאות ולביצועים נמוכים של התחזיות.
נוטה להיות לא עדכני. הביצועים של מודלים יורדים לעיתים קרובות אחרי שהם נפרסים בסביבת ייצור, כי הם לא מצליחים להסתגל לשינויים בסביבה שהם מייצגים, כמו שינויים עונתיים בהתנהגות הקנייה. בנוסף, יכול להיות שהמודלים לא יצליחו להתאים את עצמם לשינויים בנתונים, כמו מוצרים ומיקומים חדשים. לכן, מעקב אחר יעילות המודל בסביבת הייצור הוא אתגר נוסף במערכות למידת מכונה.
מערכות אוטומטיות לקבלת החלטות. בניגוד למערכות תוכנה אחרות, שבהן פעולות מקודדות בקפידה באופן ידני בהתאם למערכת דרישות ולכללים עסקיים, מודלים של ML לומדים כללים מנתונים כדי לקבל החלטה. הטיה מובלעת בנתונים עלולה לגרום למודלים להפיק תוצאות לא הוגנות.
כשמודל של למידת מכונה שנפרס מפיק תחזיות לא טובות, האיכות הירודה של למידת המכונה יכולה להיות תוצאה של מגוון רחב של בעיות. חלק מהבעיות האלה יכולות לנבוע מבאגים אופייניים שנמצאים בכל תוכנה. אבל בעיות ספציפיות ללמידת מכונה יכולות לכלול גם הטיה וחריגות בנתונים, וגם היעדר של הליכי הערכה ואימות נאותים של המודל כחלק מתהליך האימון. בעיה פוטנציאלית נוספת היא פורמט נתונים לא עקבי בין הממשק המובנה של המודל לבין Serving API. בנוסף, ביצועי המודל יורדים עם הזמן גם ללא הבעיות האלה, והוא עלול להיכשל בלי להודיע אם לא עוקבים אחריו בצורה נכונה. לכן, חשוב לכלול סוגים שונים של בדיקות ומעקב למודלים ולמערכות של למידת מכונה במהלך הפיתוח, הפריסה והייצור.
הנחיות איכות לפיתוח מודלים
כשמפתחים מודל למידת מכונה במהלך שלב הניסוי, יש שני סוגים של מדדי יעד שאפשר להשתמש בהם כדי להעריך את הביצועים של המודל:
- מדדי האופטימיזציה של המודל. המדד הזה משקף את יעילות החיזוי של המודל. המדד כולל דיוק ומדד F במשימות סיווג, שגיאת אחוז ממוצעת מוחלטת במשימות רגרסיה ותחזית, רווח מצטבר מוזל במשימות דירוג, ופרפלקסיטי וציוני BLEU במודלים של שפה. ככל שהערך של המדד הזה גבוה יותר, כך המודל מתאים יותר למשימה מסוימת. במקרים מסוימים, כדי להבטיח הוגנות, חשוב להשיג יעילות חיזויית דומה בפלחים שונים של הנתונים – למשל, בפלחים שונים של נתונים דמוגרפיים של לקוחות.
- מדדי האופטימיזציה של המודל. המדד הזה משקף מגבלה תפעולית שהמודל צריך לעמוד בה, כמו זמן האחזור של התחזית. אתם מגדירים ערך סף של זמן האחזור, למשל 200 אלפיות השנייה. מודלים שלא עומדים בסף לא מתקבלים. דוגמה נוספת למדד מספק היא גודל המודל, שחשוב כשרוצים לפרוס את המודל בחומרה עם צריכת חשמל נמוכה, כמו מכשירים ניידים ומכשירים מוטמעים.
במהלך הניסוי, מפתחים, מאמנים, מעריכים ומאתרים באגים במודל כדי לשפר את היעילות שלו ביחס למדדי האופטימיזציה, בלי לחרוג מספי הביצועים המינימליים שנקבעו למדד שביעות הרצון.
הנחיות לניסויים
- להגדיר מראש ערכי סף קבועים לאופטימיזציה של מדדים ולמדדים מספקים.
- הטמעה של שגרת הערכה יעילה שלוקחת מודל ונתונים ומפיקה קבוצה של מדדי הערכה. מטמיעים את השגרה כך שהיא תפעל ללא קשר לסוג המודל (לדוגמה, עצי החלטה או רשתות עצביות) או למסגרת של המודל (לדוגמה, TensorFlow או Scikit-learn).
- חשוב לוודא שיש לכם מודל בסיסי להשוואה. הבסיס הזה יכול להיות מורכב מהיוריסטיקות שמוגדרות בהארדקוד, או שהוא יכול להיות מודל פשוט שמנבא את ערך היעד הממוצע או השכיח. משתמשים במודל הבסיס כדי לבדוק את הביצועים של המודל ללמידת מכונה. אם המודל ללמידת מכונה לא טוב יותר ממודל הבסיס, יש בעיה מהותית במודל ללמידת מכונה.
- כדאי לעקוב אחרי כל ניסוי שבוצע כדי לשפר את השחזור ואת השיפורים המצטברים. לכל ניסוי, מאחסנים את ערכי ההיפרפרמטרים, את בחירת התכונות ואת הזרעים האקראיים.
הנחיות לאיכות הנתונים
- כדי לטפל בחוסר איזון בין המחלקות בשלב מוקדם של הניסויים, צריך לבחור את מדד ההערכה הנכון. בנוסף, כדאי להשתמש בטכניקות כמו הגדלת המשקל של מקרים של מיעוטים או הקטנת המשקל של מקרים של רוב.
- חשוב להבין את מקור הנתונים שבו משתמשים ולבצע את העיבוד המקדים של הנתונים והנדסת התכונות שרלוונטיים כדי להכין את מערך הנתונים לאימון. תהליך מהסוג הזה צריך להיות ניתן לחזרה ולאוטומציה.
- חשוב לוודא שיש לכם פיצול נפרד של נתוני בדיקה (קבוצת בקרה) להערכה הסופית של המודל. אסור לראות את פיצול הבדיקה במהלך האימון, וגם לא להשתמש בו לכוונון היפר-פרמטרים.
- חשוב לוודא שחלוקת הנתונים לאימון, לאימות ולבדיקה מייצגת באופן שווה את נתוני הקלט. הדגימה של פיצול כזה של נתונים תלויה באופי הנתונים ובמשימת ה-ML שצריך לבצע. לדוגמה, פיצול שכבות רלוונטי למשימות סיווג, בעוד שפיצול כרונולוגי רלוונטי למשימות של סדרות עיתיות.
- חשוב לוודא שפיצולי האימות והבדיקה עוברים עיבוד מראש בנפרד מפיצול נתוני האימון. אם הפיצולים עוברים עיבוד מוקדם בתערובת, זה מוביל לזליגת נתונים. לדוגמה, כשמשתמשים בסטטיסטיקה כדי לשנות נתונים לצורך נרמול או כדי להקצות תכונות מספריות לקטגוריות, צריך לחשב את הסטטיסטיקה מנתוני האימון ולהחיל אותה כדי לנרמל את נתוני האימות והפיצולים של נתוני הבדיקה.
- יצירת סכימה של מערך נתונים שכוללת את סוגי הנתונים וחלק מהמאפיינים הסטטיסטיים של התכונות. אתם יכולים להשתמש בסכימה הזו כדי למצוא נתונים חריגים או לא תקינים במהלך ניסויים ואימונים.
- חשוב לוודא שנתוני האימון עוברים ערבוב אקראי נכון בקבוצות, אבל גם עומדים בדרישות לאימון המודל. לדוגמה, המשימה הזו יכולה לחול על התפלגויות חיוביות ושליליות של מופעים.
- להשתמש במערך נפרד של נתוני אימות לצורך כוונון של היפרפרמטרים ובחירת מודל. אפשר גם להשתמש במערך הנתונים של האימות כדי לבצע עצירה מוקדמת. אחרת, אפשר לאמן את המודל למשך כל סט האיטרציות המקסימליות שצוין. עם זאת, כדאי לשמור תמונה חדשה של המודל רק אם הביצועים שלו במערך הנתונים של האימות משתפרים בהשוואה לתמונה הקודמת.
הנחיות לגבי איכות המודל
- חשוב לוודא שאין בעיות בסיסיות במודלים שמונעות מהם ללמוד על הקשר בין הקלטים לפלטים. כדי להשיג את המטרה הזו, צריך לאמן את המודל עם מעט מאוד דוגמאות. אם המודל לא משיג רמת דיוק גבוהה בדוגמאות האלה, יכול להיות שיש באג בהטמעה של המודל או בשגרת האימון שלו.
- כשמאמנים רשתות עצביות, צריך לעקוב אחרי ערכי
NaNבהפסד ואחרי אחוז המשקלים עם ערכים אפסיים במהלך אימון המודל. הערכים האלה,NaNאו אפס, יכולים להצביע על חישובים אריתמטיים שגויים, או על שיפועים נעלמים או מתפוצצים. הצגה חזותית של השינויים בחלוקת ערכי המשקל לאורך זמן יכולה לעזור לכם לזהות שינויים פנימיים במשתנים משותפים שמאטים את תהליך האימון. כדי למנוע את ההאטה הזו, אפשר להחיל נורמליזציה של קבוצות. - משווים את ביצועי המודל בנתוני האימון ובנתוני הבדיקה כדי להבין אם המודל מתאים יתר על המידה לנתונים או מתאים פחות מדי לנתונים. אם נתקלתם באחת מהבעיות האלה, כדאי לבצע את השיפורים הרלוונטיים. לדוגמה, אם יש התאמת חסר, אפשר להגדיל את יכולת הלמידה של המודל. אם הייתה התאמת יתר, אפשר להחיל רגולריזציה.
- כדאי לנתח מקרים שסווגו בצורה שגויה, במיוחד את המקרים שבהם רמת הביטחון של התחזית גבוהה ואת המחלקות שהמודל הכי התקשה לסווג במטריצת השגיאות של הסיווג הרב-מחלקתי. השגיאות האלה יכולות להצביע על דוגמאות לאימון עם תוויות שגויות. השגיאות יכולות גם להצביע על הזדמנות לעיבוד מקדים של נתונים, כמו הסרת ערכים חריגים, או ליצירת תכונות חדשות שיעזרו להבחין בין סוגי הסיווג האלה.
- לנתח את ציוני החשיבות של התכונות ולנקות תכונות שלא משפרות מספיק את איכות המודל. מודלים חסכוניים עדיפים על מודלים מורכבים.
הנחיות איכות לפריסת צינורות עיבוד נתונים לאימון
במהלך ההטמעה של המודל וצינור האימון של המודל, צריך ליצור סדרה של בדיקות בתהליך CI/CD. הבדיקות האלה מופעלות באופן אוטומטי כשדוחפים שינויים חדשים בקוד, או שהן מופעלות לפני שמבצעים פריסה של צינור ההדרכה בסביבת היעד.
הנחיות
- בדיקת יחידה של הפונקציונליות של הנדסת התכונות.
- בדיקת יחידה של הקידוד של נתוני הקלט למודל.
- בדיקת יחידה של מודולים שהמשתמש הטמיע (מותאמים אישית) במודלים באופן עצמאי – לדוגמה, בדיקת יחידה של שכבות איחוד ושכבות קונבולוציה של גרפים בהתאמה אישית, או שכבות תשומת לב בהתאמה אישית.
- מומלץ לבצע בדיקות יחידה לכל פונקציית אובדן או פונקציית הערכה בהתאמה אישית.
- בודקים את סוגי הפלט והצורות של המודל על נתונים צפויים.
- מריצים בדיקת יחידה כדי לוודא שהפונקציה
fitשל המודל פועלת ללא שגיאות בכמה קבוצות קטנות של נתונים. בבדיקות צריך לוודא שההפסד יורד וזמן הביצוע של שלב האימון הוא כצפוי. הבדיקות האלה חשובות כי שינויים בקוד המודל עלולים לגרום לבאגים שיאטו את תהליך האימון. - בדיקת יחידה של פונקציונליות השמירה והטעינה של המודל.
- בודקים את הממשקים של המודל המיוצא באמצעות בדיקות יחידה, על סמך קלט גולמי ופלט צפוי.
- בודקים את הרכיבים של שלבי הצינור באמצעות קלט מדומה ופריטי פלט.
- פורסים את צינור עיבוד הנתונים בסביבת בדיקה ומבצעים בדיקת שילוב של צינור עיבוד הנתונים מקצה לקצה. כדי לוודא שהתהליך הזה מתבצע בצורה תקינה ושהוא יוצר את הארטיפקטים הצפויים, צריך להשתמש בנתוני בדיקה.
- שימוש בפריסת צללים כשפורסים גרסה חדשה של צינור עיבוד הנתונים לאימון בסביבת הייצור. פריסת צללים עוזרת לוודא שגרסת צינור הנתונים החדשה שפרסתם מופעלת על נתונים פעילים במקביל לגרסת צינור הנתונים הקודמת.
הנחיות איכות להדרכה מתמשכת
תהליך האימון הרציף הוא תהליך של תזמור ואוטומציה של הפעלת צינורות אימון. תהליכי עבודה אופייניים לאימון כוללים שלבים כמו הטמעת נתונים ופיצול שלהם, טרנספורמציה של נתונים, אימון מודלים, הערכת מודלים ורישום מודלים. חלק מצינורות ההדרכה מורכבים מתהליכי עבודה מורכבים יותר. משימות נוספות יכולות לכלול ביצוע אימון של מודל בפיקוח עצמי שמשתמש בנתונים לא מסומנים, או בנייה של אינדקס של השכנות הקרובה המשוערת להטמעות. הקלט העיקרי של כל צינור אימון הוא נתוני אימון חדשים, והפלט העיקרי הוא מודל מועמד חדש לפריסה בסביבת ייצור.
צינור ההדרכה פועל בסביבת הייצור באופן אוטומטי, על סמך לוח זמנים (לדוגמה, יומי או שבועי) או על סמך טריגר (לדוגמה, כשנתונים חדשים עם תוויות זמינים). לכן, צריך להוסיף שלבים לבקרת איכות לתהליך האימון, במיוחד שלבים לאימות נתונים ושלבים לאימות מודלים. בשלבים האלה מאמתים את הקלטים ואת הפלטים של צינורות העיבוד.
מוסיפים את שלב אימות הנתונים אחרי שלב הטמעת הנתונים בתהליך העבודה של האימון. בשלב אימות הנתונים, המערכת יוצרת פרופיל של נתוני האימון החדשים שמוזנים לצינור העיבוד. במהלך יצירת הפרופיל, צינור עיבוד הנתונים משתמש בסכימת נתונים מוגדרת מראש, שנוצרה במהלך תהליך פיתוח ה-ML, כדי לזהות אנומליות. בהתאם לתרחיש השימוש, אפשר להתעלם מחלק מהרשומות הלא תקינות בקבוצת הנתונים או פשוט להסיר אותן. עם זאת, יכול להיות שבעיות אחרות בנתונים החדשים שנוספו יגרמו להפסקת ההרצה של צינור ההכשרה, ולכן צריך לזהות את הבעיות האלה ולטפל בהן.
הנחיות לאימות נתונים
- מוודאים שהתכונות של נתוני האימון שחולצו מלאות ושהן תואמות לסכימה הצפויה – כלומר, אין תכונות חסרות ואין תכונות נוספות. כדאי גם לוודא שהתכונות תואמות לנפחים הצפויים.
- מאמתים את סוגי הנתונים ואת הצורות של התכונות במערך הנתונים שמוזנים לצינור האימון.
- מוודאים שהפורמטים של תכונות מסוימות (לדוגמה, תאריכים, שעות, כתובות URL, מיקודים וכתובות IP) תואמים לביטויים הרגולריים הצפויים. כדאי גם לוודא שהתכונות נמצאות בטווחים תקפים.
- מאמתים את החלק המקסימלי של הערכים החסרים לכל תכונה. אם יש הרבה ערכים חסרים בתכונה מסוימת, זה יכול להשפיע על אימון המודל. ערכים חסרים בדרך כלל מצביעים על מקור לא מהימן של תכונות.
- אימות הדומיינים של תכונות הקלט. לדוגמה, כדאי לבדוק אם יש שינויים באוצר המילים של מאפיינים קטגוריים או שינויים בטווח של מאפיינים מספריים, ולבצע התאמות בהתאם לעיבוד המקדים של הנתונים. דוגמה נוספת: טווחים של מאפיינים מספריים עשויים להשתנות אם עדכון במערכת במעלה הזרם שמאכלסת את המאפיינים משתמש ביחידות מידה שונות. לדוגמה, המערכת במעלה הזרם עשויה לשנות את המטבע מדולרים לין, או לשנות את המרחקים מקילומטרים למטרים.
- מוודאים שההתפלגויות של כל תכונה תואמות לציפיות שלכם.
לדוגמה, יכול להיות שתבדקו שהערך הנפוץ ביותר של מאפיין סוג התשלום הוא
cash, ושהערך הזה מייצג 50% מכל הערכים. עם זאת, הבדיקה הזו עלולה להיכשל אם סוג התשלום הנפוץ ביותר ישתנה ל-credit_card. שינוי חיצוני כזה עשוי לדרוש שינויים במודל שלכם.
מוסיפים שלב של אימות המודל לפני שלב רישום המודל כדי לוודא שרק מודלים שעומדים בקריטריוני האימות נרשמים לפריסה בסביבת ייצור.
הנחיות לאימות מודלים
- לצורך ההערכה הסופית של המודל, צריך להשתמש בחלוקה נפרדת לבדיקה שלא נעשה בה שימוש לאימון המודל או לכוונון ההיפר-פרמטרים.
- מחשבים את הציון של המודל המועמד בהשוואה לפיצול של נתוני הבדיקה, מחשבים את מדדי ההערכה הרלוונטיים ומוודאים שהמודל המועמד עובר את ספי האיכות שהוגדרו מראש.
- כדי להתחשב בדפוסי נתונים שונים, חשוב לוודא שחלוקת נתוני הבדיקה מייצגת את הנתונים כמכלול. בנתונים מסדרות עיתיות, חשוב לוודא שפילוח הבדיקה מכיל נתונים עדכניים יותר מפילוח האימון.
- בודקים את איכות המודל בפרוסות חשובות של נתונים, כמו משתמשים לפי מדינה או סרטים לפי ז'אנר. אם בודקים נתונים מפולחים, אפשר להימנע ממצב שבו בעיות בביצועים ברמת פירוט גבוהה מוסתרות על ידי מדד סיכום גלובלי.
- הערכה של המודל הנוכחי (המוביל) בהשוואה לפיצול של נתוני הבדיקה, והשוואה שלו למודל המועמד (המתחרה) שנוצר על ידי צינור האימון.
- כדאי לאמת את המודל באמצעות מדדי הוגנות כדי לזהות הטיה מובלעת. לדוגמה, הטיה מובלעת עשויה להיגרם בגלל חוסר גיוון בנתוני האימון. אינדיקטורים של הוגנות יכולים לחשוף בעיות בשורש שצריך לטפל בהן לפני שמפעילים את המודל בסביבת הייצור.
במהלך אימון רציף, אפשר לאמת את המודל באמצעות מדדים לאופטימיזציה ומדדים לסיפוק. לחלופין, אפשר לאמת את המודל רק מול מדדי האופטימיזציה, ולדחות את האימות מול מדד האופטימיזציה המשנית עד לשלב הפריסה של המודל. אם אתם מתכננים לפרוס וריאציות של אותו מודל בסביבות שונות או בעומסי עבודה שונים, יכול להיות שעדיף לדחות את האימות מול מדד האופטימיזציה. יכול להיות שסביבות או עומסי עבודה שונים של הצגת מודעות (כמו סביבות בענן לעומת סביבות במכשיר, או סביבות בזמן אמת לעומת סביבות של שליפת נתונים ב-batch) ידרשו ספי שונים של מדדי שביעות רצון. אם אתם מבצעים פריסה למספר סביבות, יכול להיות שצינור האימונים הרציפים שלכם יאמן שני מודלים או יותר, כאשר כל מודל עובר אופטימיזציה לסביבת הפריסה הייעודית שלו.
ככל שתכניסו יותר צינורות עיבוד נתונים של אימון רציף עם תהליכי עבודה מורכבים לסביבת ייצור, תצטרכו לעקוב אחרי המטא-נתונים והארטיפקטים שנוצרים בהרצת צינורות עיבוד הנתונים. מעקב אחרי המידע הזה עוזר לכם לאתר ולנפות באגים בכל בעיה שעלולה להתעורר בסביבת הייצור. מעקב אחרי המידע גם עוזר לשחזר את התוצאות של צינורות העיבוד, כדי שתוכלו לשפר את ההטמעה שלהם באיטרציות הבאות של פיתוח למידת מכונה.
הנחיות למעקב אחרי מטא-נתונים וארטיפקטים של ML
- מעקב אחר שושלת היוחסין של קוד המקור, צינורות עיבוד הנתונים שנפרסו, רכיבים של צינורות עיבוד הנתונים, הרצות של צינורות עיבוד הנתונים, מערך הנתונים שבשימוש והארטיפקטים שנוצרו.
- מעקב אחרי ההיפר-פרמטרים וההגדרות של הפעלות צינור עיבוד הנתונים.
- מעקב אחרי נתוני קלט חשובים וארטיפקטים של פלט בשלבי צינור הנתונים, כמו נתונים סטטיסטיים של מערכי נתונים, אנומליות במערכי נתונים (אם יש), נתונים וסכימות שעברו טרנספורמציה, נקודות ביקורת של מודלים ותוצאות של הערכת מודלים.
- עוקבים אחרי השלבים המותנים בצינור שמופעלים בתגובה לתנאים, ומוסיפים מנגנונים לשינוי כדי להבטיח יכולת מעקב למקרה ששלבים מרכזיים לא יופעלו או ייכשלו.
הנחיות איכות לפריסת מודלים
נניח שיש לכם מודל מאומן שעבר אימות מנקודת המבט של מדדי האופטימיזציה, ושהמודל אושר מנקודת המבט של ניהול המודל (כפי שמתואר בהמשך בקטע ניהול המודל). המודל מאוחסן במרשם המודלים ומוכן לפריסה בסביבת ייצור. בשלב הזה, צריך להטמיע סדרה של בדיקות כדי לוודא שהמודל מתאים להכניס לשימוש בסביבת הייצור שלו. בנוסף, צריך להפוך את הבדיקות האלה לאוטומטיות בשגרה של CI/CD של מודל.
הנחיות
- מוודאים שאפשר לטעון את ארטיפקט המודל ולהפעיל אותו בהצלחה עם יחסי התלות שלו בזמן הריצה. כדי לבצע את האימות הזה, צריך להכין את המודל בגרסת ארגז חול של סביבת ההצגה. האימות הזה עוזר לוודא שהפעולות והקבצים הבינאריים שבהם נעשה שימוש במודל נמצאים בסביבה.
- מאמתים את מדדי האופטימיזציה של המודל (אם יש כאלה) בסביבת פיתוח, כמו גודל המודל והחביון.
- בודקים את הממשקים של ארטיפקט המודל בסביבת פיתוח מול קלט גולמי ומול פלט צפוי.
- מבצעים בדיקת יחידה של ארטיפקט המודל בסביבת staging עבור קבוצה של מקרים אופייניים וקיצוניים של בקשות לחיזוי. לדוגמה, בדיקת יחידה של מופע בקשה שבו כל התכונות מוגדרות לערך
None. - אחרי שפורסים את ה-API של שירות המודל בסביבת היעד, מריצים בדיקת עשן. כדי לבצע את הבדיקה הזו, שולחים מופע יחיד או קבוצת מופעים לשירות המודל ומאמתים את תגובת השירות.
- מריצים בדיקת קנרי לגרסת המודל החדשה שהופעלה על זרם קטן של נתונים פעילים שמוצגים למשתמשים. הבדיקה הזו מוודאת ששירות המודל החדש לא יפיק שגיאות לפני שהמודל יוצג למספר גדול של משתמשים.
- מומלץ לבצע בדיקה בסביבת פיתוח שאפשר לחזור בה במהירות ובבטחה לגרסה קודמת של מודל שמוצג.
- עורכים ניסויים אונליין כדי לבדוק את המודל החדש שאומן באמצעות קבוצת משנה קטנה של האוכלוסייה שמשתמשת במודל. בבדיקה הזו נמדדים הביצועים של המודל החדש בהשוואה למודל הנוכחי. אחרי שתשוו את הביצועים של המודל החדש לביצועים של המודל הנוכחי, תוכלו להחליט להפעיל את המודל החדש באופן מלא כדי שישמש את כל הבקשות שלכם לחיזוי בזמן אמת. טכניקות לניסויים אונליין כוללות בדיקות A/B וMulti-Armed Bandit (MAB).
הנחיות איכות להצגת מודלים
הביצועים החזויים של מודלים של ML שנפרסים ומוצגים בסביבת ייצור בדרך כלל יורדים עם הזמן. הירידה הזו יכולה לנבוע מחוסר עקביות בין התכונות שמוצגות לבין התכונות שהמודל מצפה להן. חוסר העקביות הזה נקרא הטיה בין אימון להצגה. לדוגמה, יכול להיות שמודל המלצות מצפה לערך קלט אלפאנומרי לתכונה כמו קוד של מוצר שנצפה לאחרונה. אבל במקום זאת, שם המוצר ולא קוד המוצר מועבר במהלך ההצגה, בגלל עדכון באפליקציה שצורכת את שירות המודל.
בנוסף, המודל יכול להתיישן כי המאפיינים הסטטיסטיים של נתוני ההצגה משתנים עם הזמן, והדפוסים שנלמדו על ידי המודל הנוכחי שכבר הוטמע לא מדויקים יותר. בשני המקרים, המודל לא יכול יותר לספק תחזיות מדויקות.
כדי למנוע את הירידה הזו בביצועי החיזוי של המודל, צריך לבצע מעקב רציף אחר היעילות של המודל. המעקב מאפשר לכם לוודא באופן קבוע ויזום שרמת הביצועים של המודל לא יורדת.
הנחיות
- רישום ביומן של מדגם של מטען ייעודי (payload) של בקשות ותגובות להצגת מודעות במאגר נתונים לצורך ניתוח שוטף. הבקשה היא מופע הקלט, והתגובה היא התחזית שהמודל יוצר עבור מופע הנתונים הזה.
- הטמעה של תהליך אוטומטי ליצירת פרופיל של נתוני הבקשה והתגובה המאוחסנים באמצעות חישוב של נתונים סטטיסטיים תיאוריים. חישוב הנתונים הסטטיסטיים האלה של הצגת המודעות ואחסונם במרווחי זמן קבועים.
- כדי לזהות training-serving skew שנגרמת כתוצאה משינוי בנתונים, משווים את הנתונים הסטטיסטיים של נתוני ההגשה לנתונים הסטטיסטיים של נתוני האימון. בנוסף, אפשר לנתח את השינויים בנתונים הסטטיסטיים של הצגת המודעות לאורך זמן.
- לזהות סחף מושגים על ידי ניתוח השינויים שחלים עם הזמן בשיוך התכונות לתחזיות.
- זיהוי מקרים של נתוני הצגה שנחשבים לחריגים ביחס לנתוני האימון. כדי למצוא את החריגים האלה, אפשר להשתמש בטכניקות של זיהוי חריגים ולעקוב אחרי השינויים באחוז החריגים בנתוני ההצגה לאורך זמן.
- הגדרת התראות למקרים שבהם המודל מגיע לספי התוצאות של הטיית הניקוד בתכונות החיזוי המרכזיות במערך הנתונים.
- אם יש תוויות (כלומר, ערכי סף), מצמידים את התוויות האמיתיות לתוויות החזויות של מופעי ההצגה כדי לבצע הערכה רציפה. הגישה הזו דומה למערכת ההערכה שמטמיעים כבדיקת 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.
שותפים ביצירת התוכן
הכותב: מייק סטייר | אדריכל פתרונות AI גנרטיבי
תורם תוכן נוסף: Amanda Brinhosa | Customer Engineer