בדיקות גישות עבור דגמי אמזון SageMaker ML

פוסט זה נכתב בשיתוף עם טוביאס וונזל, מנהל הנדסת תוכנה עבור פלטפורמת למידת מכונה אינטואיט.

כולנו מעריכים את החשיבות של מודל למידת מכונה (ML) איכותי ואמין בעת ​​שימוש בנהיגה אוטונומית או אינטראקציה עם Alexa, למשל. מודלים של ML ממלאים תפקיד חשוב גם בדרכים פחות ברורות - הם משמשים יישומים עסקיים, שירותי בריאות, מוסדות פיננסיים, amazon.com, TurboTax ועוד.

מכיוון שיישומים התומכים ב-ML הופכים לליבה לעסקים רבים, מודלים צריכים לפעול באותה עוצמה ומשמעת כמו יישומי תוכנה. היבט חשוב של MLOps הוא לספק גרסה חדשה של מודל ה-ML שפותח בעבר בייצור על ידי שימוש בפרקטיקות מבוססות של DevOps כגון בדיקה, ניהול גרסאות, אספקה ​​רציפה וניטור.

יש כמה מרשם הנחיות לגבי MLOps, והפוסט הזה נותן סקירה כללית של התהליך שאתה יכול לעקוב אחר ואילו כלים להשתמש לבדיקה. זה מבוסס על שיתופי פעולה בין אינטואיט ו-AWS. עבדנו יחד כדי ליישם את ההמלצות שהוסברו בפוסט זה בפועל ובקנה מידה. המטרה של אינטואיט להיות א פלטפורמת מומחים מונעת בינה מלאכותית תלוי מאוד באסטרטגיה של הגברת מהירות הפיתוח הראשוני של המודל, כמו גם בדיקה של גרסאות חדשות.

דרישות

להלן תחומי השיקול העיקריים בעת פריסת גרסאות דגמים חדשות:

1. ביצועי דיוק דגם - זה חשוב ל המשיכו לעקוב של מדדי הערכת מודל כמו דיוק, דיוק וזכירה, ולהבטיח שהמדדים האובייקטיביים נשארים זהים יחסית או משתפרים עם גרסה חדשה של המודל. ברוב המקרים, פריסת גרסה חדשה של המודל אינה הגיונית אם חוויית משתמשי הקצה לא תשתפר.
2. בדיקת איכות הנתונים – נתונים בסביבות שאינן ייצור, בין אם מדומה או עותק נקודת-זמן, צריכים להיות מייצגים את הנתונים שהמודל יקבל בעת פריסה מלאה, מבחינת נפח או הפצה. אם לא, תהליכי הבדיקה שלך לא יהיו מייצגים, והדגם שלך עשוי להתנהג אחרת בייצור.
3. חשיבות תכונה ושוויון - חשיבות התכונה בגרסה החדשה יותר של הדגם צריכה להשוות יחסית לדגם הישן יותר, אם כי ייתכן שיוצגו תכונות חדשות. זה כדי להבטיח שהמודל לא יהפוך מוטה.
4. בדיקת תהליכים עסקיים – חשוב שגרסה חדשה של מודל תוכל להגשים את היעדים העסקיים הנדרשים שלך בתוך פרמטרים מקובלים. לדוגמה, אחד המדדים העסקיים יכול להיות שהשהייה מקצה לקצה עבור כל שירות לא צריכה להיות יותר מ-100 אלפיות השנייה, או שהעלות לאירוח והכשרה מחדש של דגם מסוים לא יכולה להיות יותר מ-$10,000 לשנה.
5. עלות - גישה פשוטה לבדיקה היא לשכפל את כל סביבת הייצור כסביבת בדיקה. זהו נוהג נפוץ בפיתוח תוכנה. עם זאת, גישה כזו במקרה של מודלים של ML עשויה שלא להניב את החזר ה-ROI הנכון בהתאם לגודל הנתונים ועלולה להשפיע על המודל במונחים של הבעיה העסקית שבה הוא מטפל.
6. אבטחה – בסביבות בדיקה צפויים לרוב נתונים לדוגמה במקום נתוני לקוחות אמיתיים, וכתוצאה מכך, כללי הטיפול בנתונים ותאימות יכולים להיות פחות נוקשים. עם זאת, בדיוק כמו עלות, אם אתה פשוט משכפל את סביבת הייצור לתוך סביבת בדיקה, אתה יכול להציג סיכוני אבטחה ותאימות.
7. תכונות מדרגיות בחנות - אם ארגון מחליט לא ליצור מאגר תכונות בדיקה נפרד בגלל עלות או סיבות אבטחה, אזי בדיקות המודל צריכות להתרחש בחנות תכונות הייצור, מה שעלול לגרום לבעיות מדרגיות מכיוון שהתנועה מוכפלת במהלך תקופת הבדיקה.
8. ביצועי דגם מקוון - הערכות מקוונות שונות מהערכות לא מקוונות ויכולות להיות חשובות במקרים מסוימים כמו מודלים של המלצות מכיוון שהם מודדים את שביעות רצון המשתמש בזמן אמת ולא שביעות רצון נתפסת. קשה לדמות דפוסי תנועה אמיתיים באי ייצור עקב עונתיות או התנהגות משתמשים אחרת, כך שניתן לבצע ביצועי מודל מקוון רק בייצור.
9. ביצועים תפעוליים - ככל שהדגמים הולכים וגדלים ונפרסים יותר ויותר בצורה מבוזרת על חומרה שונה, חשוב לבדוק את המודל עבור הביצועים התפעוליים הרצויים שלך כמו חביון, שיעור שגיאות ועוד.

לרוב צוותי ה-ML יש גישה רב-כיוונית לבדיקת מודלים. בסעיפים הבאים, אנו מספקים דרכים להתמודד עם אתגרים אלו במהלך שלבי בדיקה שונים.

בדיקת מודלים לא מקוונים

המטרה של שלב הבדיקה הזה היא לאמת גרסאות חדשות של מודל קיים מנקודת מבט של דיוק. זה צריך להיעשות בצורה לא מקוונת כדי לא להשפיע על תחזיות כלשהן במערכת הייצור המשרתות תחזיות בזמן אמת. על ידי הבטחת הביצועים של המודל החדש טוב יותר עבור מדדי הערכה ישימים, בדיקה זו נותנת מענה לאתגר 1 (ביצועי דיוק המודל). כמו כן, על ידי שימוש במערך הנתונים הנכון, בדיקה זו יכולה להתמודד עם אתגרים 2 ו-3 (איכות נתוני הבדיקה, חשיבות תכונה ושוויון), עם היתרון הנוסף של התמודדות עם אתגר 5 (עלות).

שלב זה נעשה בסביבת הבמה.

עליך ללכוד תעבורת ייצור, שבה תוכל להשתמש כדי להפעיל מחדש בבדיקות לאחור לא מקוונות. עדיף להשתמש בתעבורת ייצור בעבר במקום בנתונים סינתטיים. ה אמזון SageMaker דגם צג תכונת לכידת נתונים מאפשר לך ללכוד תעבורת ייצור עבור דגמים שמתארחים בהם אמזון SageMaker. זה מאפשר למפתחי מודלים לבדוק את המודלים שלהם עם נתונים מימי עסקים שיא או אירועים משמעותיים אחרים. לאחר מכן, הנתונים שנלכדו משוחזרים מול גרסת הדגם החדשה בצורה אצווה באמצעות טרנספורמציה של אצווה Sagemaker. משמעות הדבר היא שהרצת הטרנספורמציה של אצווה יכולה לבצע בדיקות עם נתונים שנאספו במשך שבועות או חודשים תוך מספר שעות בלבד. זה יכול להאיץ משמעותית את תהליך הערכת המודל בהשוואה להרצת שתי גרסאות או יותר של מודל בזמן אמת זו לצד זו ושליחת בקשות חיזוי כפולות לכל נקודת קצה. בנוסף למציאת גרסה בעלת ביצועים טובים יותר מהר יותר, גישה זו משתמשת גם במשאבי המחשוב לפרק זמן קצר יותר, ומפחיתה את העלות הכוללת.

אתגר בגישה זו לבדיקה הוא שסט התכונות משתנה מגרסה אחת לאחרת. בתרחיש זה, אנו ממליצים ליצור ערכת תכונות עם ערכת על של תכונות עבור שתי הגרסאות, כך שניתן יהיה לבצע שאילתה בכל התכונות בבת אחת ולהקליט באמצעות לכידת הנתונים. כל שיחת חיזוי יכולה לפעול רק על התכונות הנחוצות לגרסה הנוכחית של המודל.

כבונוס נוסף, על ידי שילוב אמזון סייג מייקר להבהיר בבדיקת המודל הלא מקוון שלך, אתה יכול לבדוק את הגרסה החדשה של המודל עבור הטיה וגם להשוות ייחוס תכונות עם הגרסה הקודמת של המודל. בעזרת צינורות, אתה יכול לתזמן את כל זרימת העבודה כך שאחרי האימון, שלב בדיקת איכות יכול להתקיים לביצוע ניתוח של מדדי המודל וחשיבות התכונות. מדדים אלה מאוחסנים ב- רישום מודלים של SageMaker להשוואה בריצת האימון הבאה.

אינטגרציה ובדיקות ביצועים

יש צורך בבדיקות אינטגרציה כדי לאמת תהליכים עסקיים מקצה לקצה מנקודת מבט פונקציונלית וגם מנקודת מבט של ביצועי זמן ריצה. בתוך תהליך זה, יש לבדוק את כל הצינור, כולל אחזור וחישוב תכונות בחנות הפיצ'רים והפעלת אפליקציית ML. זה צריך להיעשות עם מגוון מטענים שונים כדי לכסות מגוון תרחישים ובקשות ולהשיג כיסוי גבוה לכל ריצות הקוד האפשריות. זה נותן מענה לאתגרים 4 ו-9 (בדיקות תהליכים עסקיים וביצועים תפעוליים) כדי להבטיח שאף אחד מהתהליכים העסקיים לא נשבר עם הגרסה החדשה של המודל.

בדיקה זו צריכה להיעשות בסביבת בימוי.

הן בדיקות האינטגרציה והן בדיקות הביצועים צריכות להיות מיושמות על ידי צוותים בודדים באמצעות צינור MLOps שלהם. עבור בדיקות האינטגרציה, אנו ממליצים על השיטה המנוסה והבדוקה של שמירה על סביבת טרום ייצור שווה ערך מבחינה תפקודית ובדיקה עם כמה מטענים שונים. זרימת העבודה של הבדיקה יכולה להיות אוטומטית כפי שמוצג ב הסדנה הזו. עבור בדיקת הביצועים, אתה יכול להשתמש אמזון SageMaker Inference Recommend, המציע נקודת התחלה מצוינת לקבוע באיזה סוג מופע ובכמה ממופעים אלה להשתמש. לשם כך, תצטרך להשתמש בכלי מחולל עומסים, כגון פרויקטים בקוד פתוח perfsizesagemaker ו perfsize שהאינטואיט פיתחה. Perfsizesagemaker מאפשר לך לבדוק באופן אוטומטי תצורות של נקודות קצה של מודל עם מגוון של עומסים, זמני תגובה ודרישות שיא של עסקאות בשנייה. הוא מייצר תוצאות בדיקה מפורטות המשוות בין גרסאות דגמים שונות. Perfsize הוא הכלי הנלווה שמנסה תצורות שונות בהתחשב רק בטרנזקציות השיא בשנייה וזמן התגובה הצפוי.

בדיקת A / B

במקרים רבים שבהם נדרשת תגובת משתמש לפלט המיידי של המודל, כגון יישומי מסחר אלקטרוני, הערכה פונקציונלית של מודל לא מקוון אינה מספיקה. בתרחישים אלה, עליך לבדוק דגמים A/B ​​בייצור לפני קבלת ההחלטה על עדכון מודלים. לבדיקת A/B יש גם סיכונים מכיוון שיכולה להיות השפעה אמיתית על הלקוח. שיטת בדיקה זו משמשת כאימות ביצועי ML הסופי, בדיקת שפיות הנדסית קלת משקל. שיטה זו נותנת מענה גם לאתגרים 8 ו-9 (ביצועי מודל מקוון ומצוינות תפעולית).

בדיקת A/B צריכה להתבצע בסביבת ייצור.

עם SageMaker, אתה יכול בקלות לבצע בדיקות A/B בדגמי ML על ידי הפעלה גרסאות ייצור מרובות על נקודת קצה. ניתן לנתב את התנועה במרווחים לגרסה החדשה כדי להפחית את הסיכון שיכול להיות לדגם שמתנהג בצורה גרועה בייצור. אם תוצאות מבחן A/B נראות טובות, התנועה מנותבת לגרסה החדשה, ובסופו של דבר משתלטת על 100% מהתנועה. אנו ממליצים להשתמש במעקות בטיחות לפריסה למעבר מדגם A ל-B. לדיון שלם יותר על בדיקות A/B באמצעות אמזון להתאים אישית מודלים כדוגמה, עיין באמצעות בדיקות A / B למדידת יעילות ההמלצות שנוצרו על ידי אמזון התאמה אישית.

בדיקת דגמים מקוונת

בתרחיש זה, הגרסה החדשה של מודל שונה משמעותית מזו שכבר משרתת תעבורה חיה בייצור, כך שגישת הבדיקה הלא מקוונת אינה מתאימה עוד כדי לקבוע את היעילות של גרסת הדגם החדשה. הסיבה הבולטת ביותר לכך היא שינוי בתכונות הנדרשות להפקת החיזוי, כך שלא ניתן להשתמש בעסקאות שנרשמו בעבר לבדיקת המודל. בתרחיש זה, אנו ממליצים להשתמש בפריסות צל. פריסות צל מציעות את היכולת לפרוס צל (או המתמודד) מודל לצד הייצור (או אלוף) מודל שמשרת כעת תחזיות. זה מאפשר לך להעריך את ביצועי מודל הצל בתעבורת הייצור. התחזיות של מודל הצל אינן מוגשות לאפליקציה המבקשת; הם מחוברים להערכה לא מקוונת. עם גישת הצל לבדיקה, אנו מתייחסים לאתגרים 4, 5, 6 ו-7 (בדיקות תהליכים עסקיים, עלות, אבטחה ומדרגיות של חנות תכונות).

בדיקות מודל מקוונות צריכות להיעשות בסביבות הבמה או ייצור.

יש להשתמש בשיטה זו של בדיקת גרסאות דגמים חדשות כמוצא אחרון אם לא ניתן להשתמש בכל שאר השיטות. אנו ממליצים על כך כמוצא אחרון מכיוון ששיחות דו-צדדיות למספר דגמים מייצרות עומס נוסף על כל השירותים במורד הזרם בייצור, מה שעלול להוביל לצווארי בקבוק בביצועים וכן לעלייה בעלות בייצור. ההשפעה הברורה ביותר של זה היא על שכבת ההגשה של תכונה. עבור מקרי שימוש החולקים תכונות ממאגר משותף של נתונים פיזיים, עלינו להיות מסוגלים לדמות מספר מקרי שימוש בו-זמנית הגישה לאותה טבלת נתונים כדי להבטיח שלא קיימת מחלוקת משאבים לפני המעבר לייצור. במידת האפשר, יש להימנע משאילתות כפולות למאגר התכונות, ולעשות שימוש חוזר בתכונות הדרושות לשתי הגרסאות של המודל עבור ההסקה השנייה. חנויות תכונה מבוססות על אמזון דינמו, כפי שבנתה אינטואיט, יכול ליישם מאיץ אמזון DynamoDB(DAX) כדי לשמור במטמון ולהימנע מהכפלת ה-I/O למסד הנתונים. אפשרויות אחסון אלו ואחרות יכולות להקל על אתגר 7 (מדרגיות של חנות תכונות).

כדי להתמודד עם אתגר 5 (עלות) כמו גם 7, אנו מציעים להשתמש בפריסות צל כדי לדגום את התעבורה הנכנסת. זה נותן לבעלי הדגמים שכבת שליטה נוספת כדי למזער את ההשפעה על מערכות הייצור.

יש להכניס את פריסת הצללים ל- צג דגם הצעות בדיוק כמו פריסות הייצור הרגילות על מנת לצפות בשיפורים של גרסת האתגר.

סיכום

פוסט זה ממחיש את אבני הבניין ליצירת מערך מקיף של תהליכים וכלים להתמודדות עם אתגרים שונים בבדיקת מודלים. למרות שכל ארגון הוא ייחודי, זה אמור לעזור לך להתחיל ולצמצם את השיקולים שלך בעת יישום אסטרטגיית בדיקה משלך.

---

על המחברים

טוביאס ונזל הוא מנהל הנדסת תוכנה עבור פלטפורמת למידת מכונה אינטואיט במאונטיין וויו, קליפורניה. הוא עובד על הפלטפורמה מאז הקמתה ב-2016 ועזר לתכנן ולבנות אותה מהיסוד. בתפקידו, הוא התמקד במצוינות התפעולית של הפלטפורמה ובהבאתה מוצלחת דרך העסקים העונתיים של Intuit. בנוסף, הוא נלהב להרחיב את הפלטפורמה ללא הרף עם הטכנולוגיות העדכניות ביותר.

Shivanshu Upadhyay הוא אדריכל פתרונות ראשי בקבוצת AWS פיתוח עסקי ותעשיות אסטרטגיות. בתפקיד זה, הוא עוזר לרוב המאמצים המתקדמים של AWS לשנות את התעשייה שלהם על ידי שימוש יעיל בנתונים ובינה מלאכותית.

אלן טאן הוא מנהל מוצר בכיר ב- SageMaker, המוביל מאמצים בהסקת דגמים גדולים. הוא נלהב ליישם למידת מכונה לתחום האנליטיקה. מחוץ לעבודה, הוא נהנה בחוץ.