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

פוסט זה נכתב בשיתוף עם Sowmya Manusani, Sr. Staff Machine Learning Engineer ב-Zendesk

Zendesk היא חברת SaaS שבונה תוכנת תמיכה, מכירה ומעורבות לקוחות לכולם, עם הפשטות כבסיס. היא מצליחה לגרום ליותר מ-170,000 חברות ברחבי העולם לשרת את מאות מיליוני הלקוחות שלהן ביעילות. צוות למידת מכונה ב-Zendcaesk אחראי לשיפור צוותי חוויית הלקוח כדי להשיג את המיטב. על ידי שילוב הכוח של נתונים ואנשים, Zendesk מספקת מוצרים חכמים שהופכים את הלקוחות שלהם ליותר פרודוקטיביים על ידי אוטומציה של עבודה ידנית.

Zendesk בונה מוצרי ML מאז 2015, כולל ענה בוט, חיזוי שביעות רצון, רמזים לתוכן, הצעות מאקרו, ועוד רבים. בשנים האחרונות, עם הצמיחה בלמידה עמוקה, במיוחד ב-NLP, הם ראו הרבה הזדמנויות לבצע אוטומציה של זרימות עבודה ולסייע לסוכנים לתמוך בלקוחותיהם בפתרונות Zendesk. Zendesk משתמשת כיום ב-TensorFlow וב-PyTorch כדי לבנות מודלים של למידה עמוקה.

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

ביצוע הפשרה הקשה בין שימוש חוזר במודל להיפר-פרסונליזציה

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

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

נקודות קצה מרובות של SageMaker

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

התרשים הבא ממחיש את הארכיטקטורה של נקודת קצה מרובה מודלים של SageMaker.

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

בואו נסתכל מקרוב על האופן שבו Zendesk השתמשה ב- SageMaker MME כדי להשיג פריסת ML חסכונית, בקנה מידה יתר, עם תכונת ה-Sugged Macros ML שלהם.

מדוע Zendesk בנתה מודלים מותאמים אישית במיוחד

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

באוקטובר 2021, הם הוציאו תכונה חדשה של NLP ML, Suggested Macros, הממליצה על פקודות מאקרו (פעולות מוגדרות מראש) על סמך אלפי תחזיות מודל ספציפי ללקוח. צוות ה-ML של Zendesk בנה מודל מסוג NLP מבוסס TensorFlow שהוכשר מההיסטוריה הקודמת של תוכן כרטיסים ופקודות מאקרו לכל לקוח. עם מודלים אלה זמינים, תחזית מאקרו מומלצת בכל פעם שסוכן צופה בכרטיס (כפי שמוצג בצילום המסך הבא), מה שמסייע לסוכן לשרת לקוחות במהירות. מכיוון שפקודות מאקרו ספציפיות ללקוחות, Zendesk זקוקה למודלים ספציפיים ללקוח כדי לשרת תחזיות מדויקות.

מתחת למכסה המנוע של ה-Sugged Macros של Zendesk

דגמי מאקרו מוצעים הם רשתות עצביות מבוססות NLP בגודל של כ-7-15 מגה-בייט. האתגר העיקרי הוא להכניס אלפי דגמים אלה לייצור עם פתרונות חסכוניים, אמינים וניתנים להרחבה.

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

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

אחת מתכונות ריבוי הדגמים של SageMaker היא טעינה עצלנית של דגמים, כלומר, דגמים נטענים לזיכרון כשהם מופעלים בפעם הראשונה. זאת על מנת לייעל את ניצול הזיכרון; עם זאת, זה גורם לעלייה בזמן התגובה בטעינה הראשונה, מה שניתן לראות כבעיית התחלה קרה. עבור מאקרו מוצע, זה היה אתגר; עם זאת, Zendesk התגברה על כך על ידי הטמעת פונקציונליות טעינה מראש על גבי אספקת נקודת הקצה של SageMaker כדי לטעון את הדגמים לזיכרון לפני שירות תעבורת ייצור. שנית, MME פורק מודלים בשימוש נדיר מהזיכרון, כך כדי להשיג חביון נמוך עקבי בכל הדגמים ולהימנע מ"שכנים רועשים" המשפיעים על דגמים פחות פעילים אחרים, Zendesk משתפת פעולה עם AWS כדי להוסיף תכונות חדשות, שנדונו בהמשך הפוסט, כדי לאפשר ניהול מפורש יותר לכל דגם. בנוסף, כפתרון ביניים, זנדסק הגדילה את צי ה-MME כדי למזער פריקת דגמים רבים מדי. בכך, Zendesk מסוגלת להגיש תחזיות לכל הלקוחות שלהם עם זמן השהייה נמוך, בסביבות 100 מילישניות, ועדיין להשיג חיסכון של 90% בעלויות בהשוואה לנקודות קצה ייעודיות.

ב-MME בגודל נכון, Zendesk הבחינה במהלך בדיקת עומסים שמספר גבוה יותר של מופעים קטנים יותר (הטיה על קנה מידה אופקי) מאחורי MME הייתה בחירה טובה יותר מאשר קיום פחות מקרי זיכרון גדולים יותר (קנה מידה אנכי). Zendesk הבחינה כי אריזת פח של יותר מדי דגמים (מעבר ל-500 דגמי TensorFlow במקרה שלהם) על מופע זיכרון גדול יחיד לא עבדה טוב מכיוון שזיכרון הוא לא המשאב היחיד במופע שיכול להוות צוואר בקבוק. ליתר דיוק, הם הבחינו כי TensorFlow הוליד שרשורים מרובים (3 x vCPUs הכולל של מופעים) לכל דגם, כך שטעינה של למעלה מ-500 דגמים במופע בודד גרמה להפרת מגבלות רמת הליבה על המספר המרבי של שרשורים שניתן להוליד במופע. בעיה נוספת בשימוש בפחות מקרים גדולים יותר התרחשה כאשר Zendesk חוותה מצערת (כמנגנון בטיחות) בכמה מקרים מאחורי MME מכיוון שקצב הפצת המודל הייחודי לשניה עלה על הקצב שרת רב מודל (MMS) במופע בודד יכול לטפל בבטחה מבלי להשחים את המופע. זו הייתה בעיה נוספת שנפתרה עם שימוש במופעים נוספים וקטנים יותר.

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

מתחת למכסה המנוע של קנה מידה אוטומטי של MME

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

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

השתמש במקרים המתאימים ביותר עבור MME

נקודות קצה מרובי דגמי SageMaker מתאימות היטב לאירוח של מספר רב של דגמים דומים שתוכל להגיש באמצעות מיכל הגשה משותף ולא צריך לגשת לכל הדגמים בו זמנית. MME מתאים ביותר לדגמים הדומים בגודלם ובזמן האחזור של הפניה. משתנה מסוים בגודל הדגם מקובל; לדוגמה, הדגמים של Zendesk נעים בין 10-50 מגה-ביט, מה שעובד מצוין, אבל וריאציות בגודל גדולות פי 10, 50 או פי 100 אינן מתאימות. דגמים גדולים יותר עלולים לגרום למספר גבוה יותר של טעינות ופריקות של דגמים קטנים יותר כדי להכיל מספיק שטח זיכרון, מה שעלול לגרום להשהייה נוספת בנקודת הקצה. הבדלים במאפייני הביצועים של דגמים גדולים יותר עלולים גם לצרוך משאבים כמו CPU בצורה לא אחידה, מה שעלול להשפיע על דגמים אחרים במופע.

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

<br> סיכום

בפוסט זה למדת כיצד SaaS ו-multi-tenancy קשורים ל-ML וכיצד נקודות קצה מרובות של SageMaker מאפשרות ריבוי דיירות ויעילות עלות להסקת ML. למדת על מקרה השימוש הרב-דיירים של Zendesk של דגמי ML לכל לקוח וכיצד הם אירחו אלפי דגמי ML ב- SageMaker MME עבור תכונת המאקרו המוצעים שלהם והשיגו חיסכון של 90% בעלויות בהסקת מסקנות בהשוואה לנקודות קצה ייעודיות. מקרי שימוש בהיפר-פרסונליזציה יכולים לדרוש אלפי דגמי ML, ו-MME היא בחירה חסכונית עבור מקרה שימוש זה. אנו נמשיך לבצע שיפורים ב-MME כדי לאפשר לך לארח דגמים עם זמן אחזור נמוך ועם פקדים פרטניים יותר עבור כל דגם מותאם אישית. כדי להתחיל עם MME, ראה ארח מספר דגמים במיכל אחד מאחורי נקודת קצה אחת.

---

על הכותבים

סייד ג'פרי הוא אדריכל פתרונות Sr. עם AWS. הוא עובד עם מגוון חברות מארגונים בינוניים ועד ארגונים גדולים, שירותים פיננסיים ועד ISVs, בסיוע להם לבנות ולתפעל יישומים מאובטחים, עמידים, ניתנים להרחבה וביצועים גבוהים בענן.

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

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

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

• Coinsmart. בורסת הביטקוין והקריפטו הטובה באירופה.
• Platoblockchain. Web3 Metaverse Intelligence. ידע מוגבר. גישה חופשית.
• CryptoHawk. רדאר אלטקוין. ניסיון חינם.
• מקור: https://aws.amazon.com/blogs/machine-learning/how-to-scale-machine-learning-inference-for-multi-tenant-saas-use-cases/