MLOps: DevOps בעולם של למידת מכונה

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

מה זה MLOps

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

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

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

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

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

• הגדרת רעיון עסקי;
• הכשרת מודלים;
• בדיקה והטמעה של המודל בתהליך העסקי;
• תפעול הדגם.

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

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

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

איך לגרום לדגמים לעבוד ולהיות רווחיים

כדוגמה בה נדגים את השימוש בגישת MLOps, ניקח את המשימה הקלאסית של רובוט תמיכת צ'אט עבור מוצר בנקאי (או כל מוצר אחר). בדרך כלל, תהליך עסקי תמיכה בצ'אט נראה כך: לקוח מזין הודעה עם שאלה בצ'אט ומקבל תגובה ממומחה בתוך עץ דיאלוג מוגדר מראש. המשימה של אוטומציה של צ'אט כזה נפתרת בדרך כלל באמצעות מערכות כללים המוגדרות במומחיות, שהפיתוח והתחזוקה דורשים עבודה רבה. היעילות של אוטומציה כזו, בהתאם לרמת המורכבות של המשימה, יכולה להיות 20-30%. באופן טבעי, עולה הרעיון שכדאי יותר ליישם מודול בינה מלאכותית - מודל שפותח באמצעות למידת מכונה, אשר:

• מסוגל לעבד מספר גדול יותר של בקשות ללא השתתפות מפעיל (בהתאם לנושא, במקרים מסוימים היעילות יכולה להגיע ל-70-80%);
• מסתגל טוב יותר לניסוח לא סטנדרטי בדיאלוג - מסוגל לקבוע את הכוונה, את הרצון האמיתי של המשתמש על סמך בקשה לא מנוסחת בבירור;
• יודע לקבוע מתי תשובת הדגם מספקת, ומתי יש ספקות לגבי ה"מודעות" לתשובה זו וצריך לשאול שאלת הבהרה נוספת או לעבור למפעיל;
• ניתן להכשיר בנוסף באופן אוטומטי (במקום שקבוצת מפתחים תתאים ומתקנת כל הזמן סקריפטים של תגובה, המודל מאומן בנוסף על ידי מומחה Data Science באמצעות ספריות למידת מכונה המתאימות). 

איך לגרום לדגם כל כך מתקדם לעבוד? 

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

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

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

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

תהליך חדש - אתגרים חדשים

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

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

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

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

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

בנושא הכשירותים

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

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

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

מה שהצוות שלנו כבר עשה

לאחרונה התחלנו לבנות מבנה מיומנות ותהליכי MLOps. אבל הפרויקטים שלנו בנושא ניהול מחזור חיים של מודל ושימוש במודלים כשירות כבר נמצאים בשלב בדיקת MVP.

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

שאלות לעתיד

MLOps הוא תחום צומח שחווה מחסור בכישורים ויתפוס תאוצה בעתיד. בינתיים, עדיף להתבסס על פיתוחים ושיטות עבודה של DevOps. המטרה העיקרית של MLOps היא להשתמש בצורה יעילה יותר במודלים של ML כדי לפתור בעיות עסקיות. אבל זה מעלה הרבה שאלות:

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

התשובות לשאלות אלו יקבעו במידה רבה באיזו מהירות MLOps יגיעו למלוא הפוטנציאל שלה.

מקור: www.habr.com