במסמך הזה ריכזנו כמה הנחיות שיעזרו לכם להעריך את האיכות של פתרונות למידת מכונה (ML) לחיזוי, לוודא שהם איכותיים ולשלוט בהם. הוא מספק הצעות לכל שלב בתהליך, החל מפיתוח מודלים של ML ועד לפריסת מערכות האימון ומערכות ההגשה בסביבת הייצור. המסמך הזה מרחיב את המידע שמופיע במדריך MLOps לאנשי מקצוע. הוא מתמקד בהיבטים של איכות בכל תהליך במחזור החיים של MLOps.
המסמך הזה מיועד לכל מי שמעורב בבנייה, בהטמעה ובהפעלה של פתרונות ML. המסמך מניח שאתם מכירים את MLOps באופן כללי. הוא לא מניח שיש לכם ידע בפלטפורמה ספציפית של ML.
סקירה כללית של איכות פתרון למידת מכונה
בהנדסת תוכנה, פותחו הרבה תקנים, תהליכים, כלים ושיטות כדי להבטיח איכות תוכנה. המטרה היא לוודא שהתוכנה פועלת כמצופה בסביבת הייצור, ושהיא עומדת בדרישות הפונקציונליות וגם בדרישות שאינן פונקציונליות. השיטות האלה כוללות נושאים כמו בדיקות תוכנה, אימות וולידציה של תוכנה, רישום ביומן ומעקב אחר תוכנה. ב-DevOps, השיטות האלה משולבות בדרך כלל בתהליכי CI/CD ואוטומטיות.
MLOps הוא אוסף של תהליכים ויכולות סטנדרטיים לבנייה, לפריסה ולהפעלה של מערכות ML במהירות ובאופן אמין. בדומה לפתרונות תוכנה אחרים, פתרונות תוכנה של 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, על נתוני קלט גולמיים ועל נתוני פלט צפויים.
- מבצעים בדיקת יחידה של ארטיפקט המודל בסביבת staging עבור קבוצה של מקרים אופייניים וקיצוניים של בקשות לחיזוי. לדוגמה, בדיקת יחידה של מופע בקשה שבו כל התכונות מוגדרות לערך
None. - אחרי שפורסים את ה-API של שירות המודל בסביבת היעד, מריצים בדיקת עשן. כדי לבצע את הבדיקה הזו, שולחים מופע יחיד או קבוצה של מופעים לשירות המודל ומאמתים את התגובה של השירות.
- מריצים בדיקת קנרי לגרסת המודל החדשה שהופעלה על זרם קטן של נתונים פעילים שמוצגים למשתמשים. הבדיקה הזו מוודאת ששירות המודל החדש לא יפיק שגיאות לפני שהמודל יוצג למספר גדול של משתמשים.
- מומלץ לבצע בדיקה בסביבת פיתוח שאפשר לחזור בה במהירות ובבטחה לגרסה קודמת של מודל שמופעל.
- מבצעים ניסויים אונליין כדי לבדוק את המודל החדש שאומן באמצעות קבוצת משנה קטנה של האוכלוסייה שמשרתת את המודל. בבדיקה הזו נמדדים הביצועים של המודל החדש בהשוואה למודל הנוכחי. אחרי שתשוו בין הביצועים של המודל החדש לבין הביצועים של המודל הנוכחי, תוכלו להחליט להפעיל את המודל החדש באופן מלא כדי שישמש אתכם לכל הבקשות לחיזוי בזמן אמת. טכניקות לניסויים אונליין כוללות בדיקות A/B וMulti-Armed Bandit (MAB).
הנחיות איכות להצגת מודלים
בדרך כלל, הביצועים החיזויים של מודלים של למידת מכונה שנפרסים ומוצגים בסביבת ייצור יורדים עם הזמן. הירידה הזו יכולה לנבוע מחוסר עקביות בין התכונות שמוצגות לבין התכונות שהמודל מצפה להן. חוסר העקביות הזה נקרא הטיה בין אימון להצגה. לדוגמה, יכול להיות שמודל המלצות מצפה לערך קלט אלפאנומרי לתכונה כמו קוד של מוצר שנצפה לאחרונה. אבל במקום זאת, שם המוצר מועבר במהלך ההצגה ולא קוד המוצר, בגלל עדכון באפליקציה שצורכת את שירות המודל.
בנוסף, המודל יכול להתיישן כי המאפיינים הסטטיסטיים של נתוני ההצגה משתנים עם הזמן, והדפוסים שנלמדו על ידי המודל הנוכחי שכבר הופעל לא מדויקים יותר. בשני המקרים, המודל לא יכול יותר לספק תחזיות מדויקות.
כדי למנוע את הירידה הזו בביצועי החיזוי של המודל, צריך לבצע מעקב רציף אחר היעילות של המודל. המעקב מאפשר לכם לוודא באופן קבוע ויזום שרמת הביצועים של המודל לא יורדת.
הנחיות
- רישום מדגם של מטען ייעודי (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.
- כללים ללמידת מכונה
- כדאי לנסות את ההדרכה בנושא בדיקה וניפוי באגים בלמידת מכונה.
- מומלץ לקרוא את המאמר Data Validation in Machine Learning (אימות נתונים בלמידת מכונה).
- אפשר לעיין במאגר המקורות של הקוד E2E MLOps on Google Cloud.
- סקירה כללית של עקרונות והמלצות לארכיטקטורה שספציפיים לעומסי עבודה של AI ו-ML ב- Google Cloudזמינה בפרספקטיבה של AI ו-ML ב-Well-Architected Framework.
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
הכותב: מייק סטייר | אדריכל פתרונות AI גנרטיבי
תורם תוכן אחר: Amanda Brinhosa | Customer Engineer