במסמך הזה, שהוא חלק מ-Google Cloud Well-Architected Framework: AI and ML perspective, מפורטים עקרונות והמלצות שיעזרו לכם לשפר את הביצועים של עומסי העבודה של AI ו-ML ב- Google Cloud. ההמלצות במסמך הזה תואמות לעקרונות של אופטימיזציית ביצועים ב-Well-Architected Framework.
מערכות AI ו-ML מאפשרות לארגון להשתמש ביכולות מתקדמות של אוטומציה וקבלת החלטות. הביצועים של המערכות האלה יכולים להשפיע ישירות על גורמים עסקיים חשובים כמו הכנסות, עלויות ושביעות רצון הלקוחות. כדי לממש את מלוא הפוטנציאל של מערכות AI ו-ML, צריך לבצע אופטימיזציה של הביצועים שלהן בהתאם ליעדים העסקיים ולדרישות הטכניות. תהליך האופטימיזציה של הביצועים כולל לעיתים קרובות פשרות. לדוגמה, בחירה עיצובית שמספקת את הביצועים הנדרשים עלולה להוביל לעלויות גבוהות יותר. ההמלצות במסמך הזה מתעדפות ביצועים על פני שיקולים אחרים.
כדי לשפר את הביצועים של AI ו-ML, צריך לקבל החלטות לגבי גורמים כמו ארכיטקטורת המודל, הפרמטרים ואסטרטגיית האימון. כשמקבלים את ההחלטות האלה, צריך להביא בחשבון את כל מחזור החיים של מערכות ה-AI וה-ML ואת סביבת הפריסה שלהן. לדוגמה, מודלים גדולים מאוד של שפה יכולים להציג ביצועים טובים מאוד בתשתית אימון מסיבית, אבל יכול להיות שהם לא יציגו ביצועים טובים בסביבות עם קיבולת מוגבלת, כמו מכשירים ניידים.
ההמלצות במסמך הזה ממופות לעקרונות הליבה הבאים:
- הגדרת יעדי ביצועים ושיטות הערכה
- thought מפעילים ניסויים לעיתים קרובות ועוקבים אחריהם
- בנייה ואוטומציה של תשתית אימון והצגה
- התאמת העיצוב לדרישות הביצועים
- קישור מדדי ביצועים לבחירות של עיצוב והגדרות אישיות
הגדרת יעדי ביצועים ושיטות הערכה
האסטרטגיה והיעדים העסקיים הם הבסיס לשימוש בטכנולוגיות של AI ו-ML. תרגמו את היעדים העסקיים שלכם למדדי ביצועים מרכזיים (KPI) שניתן למדוד. דוגמאות למדדי KPI: סה"כ הכנסות, עלויות, שיעור המרה, שיעור שימור או שיעור נטישה, שביעות רצון הלקוחות ושביעות רצון העובדים.
הגדירו יעדים ריאליים
לפי השיטות המומלצות של הנדסת אמינות אתרים (SRE), היעדים של השירות צריכים לשקף רמת ביצועים שעומדת בדרישות של לקוחות טיפוסיים. כלומר, יעדי השירות צריכים להיות מציאותיים מבחינת קנה המידה וביצועי התכונות.
יעדים לא מציאותיים עלולים להוביל לבזבוז משאבים בתמורה לשיפור מינימלי בביצועים. מודלים שמספקים את הביצועים הכי טובים לא בהכרח מובילים לתוצאות העסקיות הכי טובות. יכול להיות שיידרש יותר זמן ועלות כדי לאמן ולהפעיל מודלים כאלה.
כשמגדירים יעדים, חשוב להבחין בין יעדי איכות ליעדי ביצועים ולתעדף אותם:
- איכות מתייחסת למאפיינים פנימיים שקובעים את הערך של ישות. הוא עוזר לכם להעריך אם הישות עומדת בציפיות ובסטנדרטים שלכם.
- ביצועים מתייחסים ליעילות שבה ישות פועלת או מבצעת את המטרה שלה.
מהנדסי למידת מכונה יכולים לשפר את מדדי הביצועים של מודל במהלך תהליך האימון. פלטפורמת הסוכנים של Gemini Enterprise מספקת שירות הערכה שמהנדסי למידת מכונה יכולים להשתמש בו כדי להטמיע מעקב סטנדרטי וניתן לחזרה אחרי מדדי איכות. יעילות החיזוי של מודל מציינת את רמת הביצועים של המודל בסביבת הייצור או בזמן ההסקה. כדי לעקוב אחרי הביצועים, אתם יכולים להשתמש ב-Cloud Monitoring וב-Model Monitoring ב-Gemini Enterprise Agent Platform. כדי לבחור מודלים מתאימים ולהחליט איך לאמן אותם, צריך לתרגם את היעדים העסקיים לדרישות טכניות שקובעות את מדדי האיכות ומדדי לבדיקת ביצועים.
כדי להבין איך להגדיר יעדים ריאליים ולזהות מדדים מתאימים לבדיקת ביצועים, כדאי לעיין בדוגמה הבאה למערכת מבוססת-AI לזיהוי הונאות:
- יעד עסקי: במערכת לזיהוי הונאות, יעד עסקי לא מציאותי הוא לזהות 100% מהעסקאות שמקורן בתרמית באופן מדויק תוך ננו-שנייה אחת, בשיא תנועה של 100 מיליארד עסקאות בשנייה. יעד ריאלי יותר הוא לזהות עסקאות שמקורן בתרמית ברמת דיוק של 95% תוך 100 אלפיות השנייה ב-90% מהחיזויים אונליין, במהלך שעות העבודה בארה"ב, בנפח שיא של מיליון עסקאות בשנייה.
- מדדי ביצועים: זיהוי הונאות הוא בעיית סיווג. כדי למדוד את האיכות של מערכת לזיהוי הונאות, אפשר להשתמש במדדים כמו אחזור, ציון F1 ודיוק. כדי לעקוב אחרי הביצועים או המהירות של המערכת, אתם יכולים למדוד את זמן האחזור של ההסקה. זיהוי עסקאות שעלולות להיות הונאה עשוי להיות חשוב יותר מדיוק. לכן, יעד ריאלי יכול להיות אחזור גבוה עם זמן אחזור של p90 שהוא פחות מ-100 אלפיות השנייה.
מעקב אחרי הביצועים בכל השלבים של מחזור החיים של המודל
במהלך הניסויים והאימון, ואחרי פריסת המודל, עקבו אחרי מדדי ה-KPI ושימו לב לכל סטייה מהיעדים העסקיים. אסטרטגיית מעקב מקיפה עוזרת לכם לקבל החלטות קריטיות לגבי איכות המודל וניצול המשאבים, כמו:
- להחליט מתי להפסיק משימת אימון.
- לבדוק אם ביצועי המודל בסביבת הייצור יורדים.
- לשפר את העלות ואת זמן היציאה לשוק של מודלים חדשים.
מעקב במהלך הניסויים והאימון
מטרת שלב הניסוי היא למצוא את הגישה הכוללת, ארכיטקטורת המודל וההיפר-פרמטרים האופטימליים למשימה ספציפית. הניסויים עוזרים לכם לקבוע באופן איטרטיבי את ההגדרות שמספקות ביצועים אופטימליים, ואיך לאמן את המודל. המעקב עוזר לכם לזהות ביעילות תחומים פוטנציאליים לשיפור.
כדי לעקוב אחרי איכות המודל ויעילות האימון, מהנדסי ML צריכים:
- הצגה חזותית של מדדי האיכות והביצועים של המודל בכל ניסוי.
- הצגה חזותית של תרשימים ומדדים של מודלים, כמו היסטוגרמות של משקלים והטיות.
- ייצוג חזותי של נתוני האימון.
- לנתח את הביצועים של אלגוריתמים לאימון בחומרות שונות.
כדי לעקוב אחרי הניסויים וההדרכות, כדאי לפעול לפי ההמלצות הבאות:
איכות המודל: כדי להמחיש ולעקוב אחרי מדדי ניסויים כמו דיוק, וכדי להמחיש את ארכיטקטורת המודל או את נתוני האימון, משתמשים ב-TensorBoard. TensorBoard היא חבילת כלים בקוד פתוח שתואמת למסגרות למידת מכונה כמו:
- XGBoost
- JAX
- Flax
- PyTorch
- ספריות מבוססות-XLA ב-Cloud TPU לאימון ב-Cloud TPU
- TensorFlow
מעקב אחרי ניסויים: ניסויים ב-Gemini Enterprise Agent Platform משתלבים עם מכונות מנוהלות ברמה שמתאימה לארגונים של Agent Platform TensorBoard כדי לתמוך במעקב אחרי ניסויים. השילוב הזה מאפשר אחסון ושיתוף אמינים של יומנים ומדדים. כדי לאפשר לכמה צוותים ואנשים לעקוב אחרי ניסויים, מומלץ להשתמש בעיקרון של הרשאות מינימליות.
יעילות האימון והניסויים: פלטפורמת הסוכנים מייצאת מדדים ל-Monitoring ואוספת נתוני טלמטריה ויומנים באמצעות סוכן ניטור. אפשר להציג את המדדים במסוף Google Cloud . אפשר גם ליצור לוחות בקרה או התראות על סמך המדדים האלה באמצעות Monitoring. מידע נוסף זמין במאמר מעקב אחרי מדדים של Agent Platform.
מעבדי GPU של NVIDIA: סוכן תפעול מאפשר מעקב אחרי מעבדי GPU ב-Compute Engine ובמוצרים אחרים שנתמכים על ידי סוכן תפעול. אפשר גם להשתמש ב-NVIDIA Data Center GPU Manager (DCGM), חבילת כלים לניהול ולמעקב אחרי מעבדי GPU של NVIDIA בסביבות של אשכולות. המעקב אחרי יחידות ה-GPU של NVIDIA שימושי במיוחד לאימון ולשירות של מודלים של למידה עמוקה.
ניפוי באגים מעמיק: כדי לנפות באגים בקוד האימון או בהגדרות של משימת האימון המנוהלת ב-Gemini Enterprise Agent Platform, אתם יכולים לבדוק את קונטיינר האימון באמצעות סשן מעטפת אינטראקטיבי.
מעקב במהלך הצגת המודעות: חיזוי בסטרימינג
אחרי שמאמנים מודל ומייצאים אותו אל Model Registry ב-Gemini Enterprise Agent Platform, אפשר ליצור נקודת קצה (endpoint) ב-Agent Platform. נקודת הקצה הזו מספקת נקודת קצה (endpoint) של HTTP למודל.
הכלי למעקב אחרי מודלים ב-Agent Platform עוזר לזהות שינויים משמעותיים בהתפלגות של מאפייני הקלט או הפלט. אפשר גם לעקוב אחרי שיוך (Attribution) של מאפיינים בסביבת הייצור בהשוואה להתפלגות בסיסית. ההתפלגות הבסיסית יכולה להיות קבוצת הנתונים לאימון, או שהיא יכולה להתבסס על התפלגויות קודמות של תנועת הייצור. שינוי בהתפלגות של הצגת המודעות עשוי להצביע על ירידה בביצועי החיזוי בהשוואה לאימון.
- בחירת יעד מעקב: בהתאם לרגישות של תרחיש השימוש לשינויים בנתונים שסופקו למודל, אתם יכולים לעקוב אחרי סוגים שונים של יעדים: שינוי הדרגתי במאפייני הקלט, שינוי הדרגתי בפלט ושיוך מאפיינים. Model Monitoring ב-Agent Platform v2 מאפשר לכם לעקוב אחרי מודלים שאתם פורסים בפלטפורמת שירות מנוהלת כמו Agent Platform, וגם בשירותים באירוח עצמי כמו Google Kubernetes Engine (GKE). בנוסף, כדי לעקוב אחרי הביצועים באופן מפורט, אתם יכולים לעקוב אחרי הפרמטרים ברמת המודל ולא ברמת נקודת הקצה.
- מעקב אחרי פרסום מודלים של AI גנרטיבי: כדי להבטיח יציבות ולצמצם את זמן האחזור, במיוחד בנקודות קצה של LLM, כדאי להגדיר סטאק מעקב חזק. במודלים של Gemini יש מדדים מובְנים, כמו הזמן עד לאסימון הראשון (TTFT), שאפשר לגשת אליהם ישירות ב-Metrics Explorer. כדי לעקוב אחרי קצב העברת הנתונים, זמן האחזור ושיעורי השגיאות בכל המודלים שלGoogle Cloud , אתם יכולים להשתמש במרכז הבקרה של ניטור המודלים.
מעקב במהלך הצגת המודעות: חיזוי באצווה
כדי לעקוב אחרי חיזוי באצווה, אתם יכולים להריץ משימות הערכה סטנדרטיות בשירות ההערכה של Agent Platform. הכלי למעקב אחרי מודלים ב-Agent Platform תומך במעקב אחרי הסקה באצווה. אם אתם משתמשים ב-Batch כדי להריץ את עומס העבודה של ההצגה, אתם יכולים לעקוב אחרי צריכת המשאבים באמצעות המדדים ב-Metrics Explorer.
אוטומציה של הערכה לצורך שחזור ותקינה
כדי להעביר מודלים מאב טיפוס למערכות ייצור אמינות, צריך תהליך הערכה סטנדרטי. התהליך הזה עוזר לכם לעקוב אחרי ההתקדמות בין האיטרציות, להשוות בין מודלים שונים, לזהות הטיות ולצמצם אותן, ולוודא שאתם עומדים בדרישות הרגולטוריות. כדי להבטיח יכולת שחזור וסקלביליות, צריך להפוך את תהליך ההערכה לאוטומטי.
כדי להפוך את תהליך ההערכה של ביצועי ML לתהליך סטנדרטי ואוטומטי, מבצעים את השלבים הבאים:
- הגדירו אינדיקטורים כמותיים ואיכותיים.
- לבחור מקורות נתונים ושיטות מתאימים.
- הפכו את תהליך ההערכה לסטנדרטי.
השלבים האלה מתוארים בקטעים הבאים.
1. הגדרת אינדיקטורים כמותיים ואיכותיים
השוואות מבוססות-מחשוב מחושבות באמצעות נוסחאות מספריות. חשוב לזכור שמדדי אובדן האימון עשויים להיות שונים ממדדי ההערכה שרלוונטיים ליעדים העסקיים. לדוגמה, מודל שמשמש לזיהוי הונאות בפיקוח עשוי להשתמש באובדן אנטרופיה חוצה לאימון. עם זאת, כדי להעריך את ביצועי ההסקה, מדד רלוונטי יותר עשוי להיות היזכרות, שמציין את הכיסוי של עסקאות שמקורן בתרמית. פלטפורמת Agent מספקת שירות הערכה למדדים כמו זיכרון, דיוק ושטח מתחת לעקומת הדיוק-זיכרון (AuPRC). מידע נוסף מופיע במאמר הערכת מודלים ב-Agent Platform.
אי אפשר לחשב באופן אובייקטיבי אינדיקטורים איכותיים, כמו השטף או הערך הבידורי של התוכן שנוצר. כדי להעריך את האינדיקטורים האלה, אתם יכולים להשתמש באסטרטגיית LLM-as-a-judge או בשירותי תיוג אנושיים כמו Labelbox.
2. בחירת מקורות נתונים ושיטות מתאימים
הערכה היא מובהקת סטטיסטית כשהיא פועלת על נפח מינימלי מסוים של דוגמאות מגוונות. כדי לבחור את מערכי הנתונים והשיטות שבהם תשתמשו להערכות, אתם יכולים להשתמש בגישות כמו:
- קבוצת נתונים אידיאלית: משתמשים בדגימות נתונים מהימנות, עקביות ומדויקות שמשקפות את התפלגות ההסתברות של מודל בסביבת הייצור.
- LLM-as-a-judge: הערכת הפלט של מודל גנרטיבי באמצעות LLM. הגישה הזו רלוונטית רק למשימות שבהן LLM יכול להעריך מודל.
- משוב ממשתמשים: כדי להנחות שיפורים עתידיים, אוספים משוב ישיר ממשתמשים כחלק מתנועת הייצור.
בהתאם לשיטת ההערכה, לגודל ולסוג של נתוני ההערכה ולתדירות ההערכה, אתם יכולים להשתמש ב-BigQuery או ב-Cloud Storage כמקורות נתונים, כולל לשירות ההערכה של Agent Platform.
- ב-BigQuery אתם יכולים להשתמש בפקודות SQL כדי להריץ משימות הסקה, כמו עיבוד שפה טבעית ותרגום אוטומטי. מידע נוסף מופיע במאמר סקירה כללית של פתרונות ספציפיים למשימות.
- Cloud Storage מספק פתרון אחסון חסכוני למערכי נתונים גדולים.
3. סטנדרטיזציה של תהליך ההערכה
כדי להפוך את תהליך ההערכה לאוטומטי, כדאי להשתמש בשירותים ובכלים הבאים:
- שירות ההערכה של Agent Platform: מספק פרימיטיבים מוכנים לשימוש כדי לעקוב אחרי ביצועי המודל כחלק ממחזור החיים של למידת המכונה ב-Agent Platform.
- שירות הערכה ל-AI גנרטיבי: מאפשר להעריך כל מודל או אפליקציה גנרטיביים, ולהשוות את תוצאות ההערכה לשיפוט ולקריטריונים שלכם. השירות הזה גם עוזר לכם לבצע משימות מיוחדות כמו הנדסת פרומפטים, דור משופר לאחזור (RAG) ואופטימיזציה של סוכני AI.
- כלי להשוואה אוטומטית (AutoSxS) ב-Agent Platform: תומך בהערכה מבוססת-מודל של זוגות.
- Kubeflow: מספק רכיבים מיוחדים להרצת הערכות של מודלים.
הפעלה ומעקב אחרי ניסויים תכופים
כדי לבצע אופטימיזציה יעילה של ביצועי ML, צריך פלטפורמה ייעודית, חזקה ואינטראקטיבית לניסויים. הפלטפורמה צריכה לכלול את היכולות הבאות:
- לפתח באופן איטרטיבי, כדי שהצוותים יוכלו לעבור מרעיון לתוצאות מאומתות במהירות, באמינות ובקנה מידה רחב.
- הצוותים יכולים לגלות ביעילות את ההגדרות האישיות האופטימליות שבהן הם יכולים להשתמש כדי להפעיל משימות אימון.
- לתת גישה מבוקרת לנתונים, לתכונות ולכלים הרלוונטיים כדי לבצע ניסויים ולעקוב אחריהם.
- תמיכה בשחזור ובמעקב אחרי שושלת נתונים.
התייחסות לנתונים כאל שירות
כדי לבודד עומסי עבודה ניסיוניים ממערכות ייצור ולהגדיר אמצעי בקרה מתאימים לאבטחת נכסי הנתונים, אתם יכולים להשתמש בשיטות הבאות:
| תכונה | תיאור | יתרונות |
|---|---|---|
| בידוד משאבים | בידוד המשאבים של סביבות שונות בפרויקטים נפרדים ב- Google Cloud . לדוגמה, הקצו את המשאבים לסביבות פיתוח, Staging וייצור בפרויקטים נפרדים כמו ml-dev, ml-staging ו-ml-prod. |
בידוד המשאבים עוזר למנוע מצב שבו עומסי עבודה ניסיוניים צורכים משאבים שמערכות הייצור צריכות. לדוגמה, אם אתם משתמשים בפרויקט אחד לניסויים וגם לייצור, יכול להיות שבניסוי ייעשה שימוש בכל מעבדי ה-GPU הזמינים מסוג NVIDIA A100 לאימון מנוהל של Agent Platform. זה עלול לגרום להפרעות באימון מחדש של מודל קריטי בסביבת הייצור. |
| זהות ובקרת גישה | מיישמים את העקרונות של אפס אמון והרשאות מינימליות ומשתמשים בחשבונות שירות ספציפיים לעומסי עבודה. נותנים גישה באמצעות תפקידים מוגדרים מראש של ניהול זהויות והרשאות גישה (IAM), כמו משתמש בפלטפורמת Agent (roles/aiplatform.user). |
הגישה הזו עוזרת למנוע פעולות מקריות או זדוניות שעלולות לפגוע בניסויים. |
| אבטחת רשת | מבודדים את התנועה ברשת באמצעות רשתות של ענן וירטואלי פרטי (VPC), ואוכפים את היקפי האבטחה באמצעות VPC Service Controls. | הגישה הזו עוזרת להגן על נתונים רגישים ומונעת מתנועה ניסיונית להשפיע על שירותי הייצור. |
| בידוד נתונים | אחסון נתוני ניסויים בקטגוריות נפרדות של Cloud Storage ובמערכי נתונים נפרדים של BigQuery. | בידוד הנתונים מונע שינוי מקרי של נתוני הייצור. לדוגמה, בלי בידוד נתונים, ניסוי עלול לשנות בטעות את ערכי המאפיינים בטבלה משותפת ב-BigQuery, מה שעלול להוביל לירידה משמעותית ברמת הדיוק של המודל בסביבת הייצור. |
לצייד את הצוותים בכלים המתאימים
כדי ליצור קבוצה של כלים שיאיצו את כל מחזור החיים של הניסויים – מחקירת הנתונים ועד לאימון המודל ולניתוח – השתמשו בשיטות הבאות:
- יצירת אב טיפוס אינטראקטיבי: כדי לחקור נתונים במהירות, לבדוק השערות וליצור אב טיפוס של קוד, אתם יכולים להשתמש ב-Colab Enterprise או במכונות מנוהלות של JupyterLab ב-Gemini Enterprise Agent Platform Workbench. למידע נוסף, קראו את המאמר בחירת פתרון ל-notebook.
- אימון מודלים שניתן להתאמה לעומס: הפעלת משימות אימון בשירות מנוהל שתומך באימון מבוזר ובמשאבי מחשוב שניתנים להתאמה לעומס, כמו GPUs ו-Cloud TPU. הגישה הזו עוזרת לקצר את זמן האימון מימים לשעות, ומאפשרת לבצע יותר ניסויים במקביל. מידע נוסף זמין במאמר שימוש ברכיבים מיוחדים לאימון.
- למידת מכונה במסד הנתונים: אימון מודלים ישירות ב-BigQuery ML באמצעות SQL. השיטה הזו עוזרת למנוע העברת נתונים ומאיצה את הניסויים של מנתחי נתונים ומשתמשים שמתמקדים ב-SQL.
- מעקב אחרי ניסויים: יצירת היסטוריה של נתוני ניסויים שניתן לחפש בה ולהשוות אותה, על ידי רישום פרמטרים, מדדים ופריטי מידע שנוצרו בתהליך הפיתוח (artifacts) לכל הרצת ניסוי. מידע נוסף זמין במאמר בניית מערכת של שושלת נתונים ומודלים.
- אופטימיזציה של AI גנרטיבי: כדי לשפר את הביצועים של אפליקציות מבוססות-AI גנרטיבי, צריך להתנסות בהנחיות, בבחירת מודלים ובכוונון. כדי ליצור הנחיות במהירות, השתמשו ב-Agent Studio ב-Gemini Enterprise Agent Platform. כדי להתנסות במודלים בסיסיים (כמו Gemini) ולמצוא מודל שמתאים לתרחיש לדוגמה וליעדים העסקיים שלכם, השתמשו ב-Model Garden.
סטנדרטיזציה ליעילות וליכולת לשחזר את התוצאות
כדי לוודא שהניסויים צורכים משאבים ביעילות ומניבים תוצאות עקביות ומהימנות, כדאי להפוך את הניסויים לאוטומטיים ולתקנן אותם באמצעות הגישות הבאות:
- שימוש בקונטיינרים כדי להבטיח סביבות עקביות: אורזים את קוד האימון ואת יחסי התלות כקונטיינרים של Docker. ניהול הקונטיינרים והצגתם באמצעות Artifact Registry. כך אפשר לשחזר בעיות במכונות שונות על ידי חזרה על ניסויים בסביבות זהות. ב-Agent Platform יש קונטיינרים מובְנים לאימון ללא שרת (serverless).
- אוטומציה של תהליכי עבודה של ML כפייפליינים: תזמור של תהליך העבודה של ML מקצה לקצה כפייפליין מקודד באמצעות Gemini Enterprise Agent Platform Pipelines. הגישה הזו עוזרת לאכוף עקביות, להבטיח יכולת שחזור ולעקוב באופן אוטומטי אחרי כל פריטי המידע שנוצרו בתהליך הפיתוח והמטא-נתונים ב-Agent Platform ML Metadata.
- הקצאת משאבים אוטומטית באמצעות תשתית כקוד (IaC): מגדירים ופורסים סביבות ניסוי סטנדרטיות באמצעות כלי IaC כמו Terraform. כדי לוודא שכל פרויקט עומד בקבוצה סטנדרטית של הגדרות אבטחה, רשתות ופיקוח, משתמשים במודולים של Terraform.
פיתוח ואוטומציה של תשתית לאימון ולהצגה
כדי לאמן מודלי AI ולהכניס אותם לשימוש בסביבת הייצור, צריך להגדיר פלטפורמה חזקה שתומכת בפיתוח, בפריסה ובהכניסה לשימוש בסביבת הייצור יעילים ואמינים. הפלטפורמה הזו מאפשרת לצוותים לשפר ביעילות את האיכות והביצועים של האימון וההצגה בטווח הארוך.
שימוש ברכיבים מיוחדים לאימון
פלטפורמת אימון אמינה עוזרת לשפר את הביצועים ומספקת גישה סטנדרטית לאוטומציה של משימות שחוזרות על עצמן במחזור החיים של למידת המכונה – מהכנת הנתונים ועד לאימות המודל.
איסוף נתונים והכנה
כדי לאמן מודל בצורה יעילה, צריך לאסוף ולהכין את הנתונים שנדרשים לאימון, לבדיקה ולאימות. הנתונים יכולים להגיע ממקורות שונים ולהיות מסוגים שונים. צריך גם לעשות שימוש חוזר בנתונים רלוונטיים בהרצות אימון שונות ולשתף תכונות בין צוותים. כדי לשפר את יכולת החזרה על שלב איסוף הנתונים וההכנה, כדאי להביא בחשבון את ההמלצות הבאות:
- לשפר את יכולת הגילוי של הנתונים באמצעות Knowledge Catalog.
- ריכוז הנדסת הפיצ'רים ב-Agent Platform Feature Store.
- עיבוד מראש של נתונים באמצעות Dataflow.
הרצת אימון
כשמאמנים מודל, משתמשים בנתונים כדי ליצור אובייקט של מודל. כדי לעשות את זה, צריך להגדיר את התשתית הנדרשת ואת יחסי התלות של קוד האימון. צריך גם להחליט איך לשמור את מודלי האימון, לעקוב אחרי התקדמות האימון, להעריך את המודל ולהציג את התוצאות. כדי לשפר את יכולת החזרה על האימון, כדאי לפעול לפי ההמלצות הבאות:
- פועלים לפי ההנחיות שמפורטות בקטע הערכה אוטומטית לצורך שחזור ותקינה.
- כדי לשלוח משימות אימון בצומת עובד אחד או יותר בלי לנהל את ההקצאה או את יחסי התלות של התשתית הבסיסית, משתמשים במשאב
CustomJobב-Agent Platform Managed Training. אפשר גם להשתמש במשאבCustomJobלמשימות של כוונון היפר-פרמטרים. - כדי לשפר את קצב העברת הנתונים המוצלחים (goodput) של התזמון, השתמשו במתזמן משימות לפריסת workload דינמית (DWS) או בהזמנות לאימון מנוהל ב-Agent Platform.
- רושמים את המודלים ב-Model Registry.
תזמור אימון
פריסת עומסי עבודה של אימון כשלבים בצינור עיבוד נתונים באמצעות צינורות עיבוד נתונים של Agent Platform. השירות הזה מספק שירותים מנוהלים של Kubeflow ו-TFX. מגדירים כל שלב בצינור עיבוד הנתונים כרכיב שפועל בקונטיינר. כל רכיב פועל כמו פונקציה, עם פרמטרים של קלט ופריטי פלט שהופכים לקלט של הרכיבים הבאים בצינור עיבוד הנתונים. כדי לשפר את היעילות של צינור עיבוד הנתונים, כדאי לפעול לפי ההמלצות הבאות:
- הטמעת אוטומציה בסיסית:
- משתמשים ברכיבים של Kubeflow Pipelines.
- אפשר להשתמש בתהליכי בקרה לתכנון מתקדם של צינורות עיבוד נתונים, כמו שערים מותנים.
- משלבים את הידור צינור עיבוד הנתונים כחלק מתהליך ה-CI/CD.
- מפעילים את צינור עיבוד הנתונים באמצעות Cloud Scheduler.
- שיפור המהירות והיעילות מבחינת עלות:
- כדי להגביר את מהירות החזרות ולהפחית את העלות, השתמשו במטמון ההפעלה של Agent Platform Pipelines.
- מגדירים את המכונה לכל רכיב, בהתאם לדרישות המשאבים של כל שלב.
- שיפור העמידות:
- כדי להגביר את העמידות בפני בעיות זמניות בלי צורך בהתערבות ידנית, אפשר להגדיר ניסיונות חוזרים.
- כדי להיכשל מהר ולבצע איטרציות ביעילות, מגדירים מדיניות כשל.
- כדי לטפל בכשלים, הגדירו התראות באימייל.
- הטמעת פיקוח ומעקב:
- כדי להתנסות בהגדרות שונות של מודלים או של אימון, הוסיפו הרצות של צינורות עיבוד נתונים לניסויים.
- מעקב אחרי היומנים והמדדים של צינורות עיבוד הנתונים ב-Agent Platform.
- מומלץ לפעול לפי ההמלצות שמפורטות בקטע מעקב אחרי הביצועים בכל השלבים של מחזור החיים של המודל.
שימוש בתשתית ייעודית לחיזוי
כדי להפחית את העבודה הכרוכה בניהול התשתית ופריסת המודלים, כדאי להפוך את תהליכי המשימות החוזרות לאוטומטיים. גישה שמתמקדת בשירות מאפשרת לכם להתמקד במהירות ובזמן קצר יותר להפקת ערך (TTV). כדאי לשקול את ההמלצות הבאות.
הטמעת פריסה אוטומטית
- אחרי שהמודל מאומן, משתמשים באוטומציה כדי לפרוס אותו. ב-Agent Platform Pipelines יש רכיבים מיוחדים לפריסת מודלים בנקודות קצה של Agent Platform. אתם יכולים לנהל את הפריסה האוטומטית באמצעות Kubeflow Control Flows.
- כדי להחליט אם לפרוס מודל על סמך הערכה מול קבוצת נתונים לתיקוף, השתמשו ברכיבי ההערכה של צינור עיבוד הנתונים. אתם יכולים להפוך את הפריסה של הסקת אצווה לאוטומטית באמצעות רכיבים ייעודיים לחיזוי באצווה ב-Agent Platform.
שימוש בתכונות של ניהול קנה מידה
- Agent Platform מספקת יכולות הסקה באצווה ואונליין, שמאפשרות להגדיר את התנהגות ההתאמה לעומס (scaling).
- ב-Cloud Run יש תמיכה במעבדי GPU עם התאמה אוטומטית לעומס.
אופטימיזציה של זמן האחזור וקצב הנתונים בנקודות הקצה של Agent Platform
- בוחרים סוג מכונה מתאים.
- בוחרים סוג נקודת קצה (endpoint) שמתאים למודלים. נקודות קצה פרטיות ייעודיות יכולות לעזור לצמצם את זמן האחזור.
- אם אתם משתמשים ב-Feature Store, השתמשו במילוי בקשות אונליין ב-Bigtable כדי למלא בקשות לערכי מאפיינים עם תפוקה גבוהה וזמן אחזור קצר, ובחיפוש וקטורי כדי למלא בקשות להטמעות.
אופטימיזציה של ניצול המשאבים
- כדי לייעל את השימוש במשאבים, אתם יכולים לשתף משאבים בין פריסות של מודלים. במקום להשתמש במכונה וירטואלית נפרדת לכל מודל (פעולת ברירת המחדל), אתם יכולים לפרוס כמה מודלים במכונה וירטואלית אחת.
- כדי להבטיח או לשפר את זמינות המשאבים, אפשר להשתמש במקום שמור, במתזמן משימות לפריסת workload דינמית (DWS) או בVM במודל Spot.
אופטימיזציה של פריסת המודל
- כדי להימנע משינויי תוכנה שעלולים לגרום לכשל, אתם יכולים לבצע מיגרציה הדרגתית ולהטמיע בדיקות A/B על ידי פריסה אוטומטית של כמה מודלים לאותה נקודת קצה (endpoint). ב-Agent Platform, שכבת נקודת הקצה מופרדת מהמודלים, וכך אפשר לפצל את התנועה בין גרסאות של מודלים.
- כדי להחליף מודל שנפרס, משתמשים באסטרטגיית פריסה הדרגתית.
מעקב אחר הביצועים
כדי לשפר את ביצועי ההצגה בסביבת הייצור, כדאי לעיין ביומנים ובמדדי ההסקה של נקודות הקצה של Agent Platform. כדי להבין את ההתנהגות של המודלים בסביבת הייצור, צריך כלים למעקב אחרי האיכות והביצועים. מעקב אחרי מודלים ב-Agent Platform v2 מאפשר לעקוב אחרי כמה גרסאות של מודל ולבצע שינויים במהירות.
התאמת העיצוב לדרישות הביצועים
כשאתם בוחרים עיצוב כדי לשפר את הביצועים, כדאי לבדוק אם הבחירות שלכם תומכות בדרישות העסקיות או שהן בזבזניות ולא יעילות. כדי לבחור את התשתית, המודלים וההגדרות המתאימים, צריך לזהות את צווארי הבקבוק בביצועים ולבדוק איך הם קשורים למדדי הביצועים. לדוגמה, גם במאיצי GPU חזקים מאוד, יכולים להיות צווארי בקבוק בביצועים של משימות אימון. צווארי הבקבוק האלה יכולים להיגרם בגלל בעיות קלט/פלט של נתונים בשכבת האחסון או בגלל מגבלות בביצועים של המודל.
התמקדות בביצועים הכוללים של תהליך ה-ML
ככל שדרישות האימון גדלות מבחינת גודל המודל וגודל האשכול, שיעור הכשלים ועלויות התשתית עשויים לעלות. לכן, העלות של כשל עלולה לגדול באופן ריבועי. אי אפשר להסתמך רק על מדדים רגילים של יעילות משאבים, כמו ניצול FLOPs של המודל (MFU). כדי להבין למה MFU לא תמיד מספיק כדי להעריך את הביצועים הכוללים של האימון, נבחן את מחזור החיים של משימת אימון אופיינית. מחזור החיים מורכב מהתהליך המחזורי הבא:
- יצירת אשכול: הקצאת צומתי עובדים.
- אתחול: האימון מאותחל בצומתי העובדים.
- הרצת אימון: המשאבים משמשים להפצה קדימה או אחורה.
- הפרעה: תהליך האימון מופרע במהלך נקודת הבדיקה של המודל או בגלל הפקעות של צומת עובד.
אחרי כל הפרעה, התהליך הקודם חוזר על עצמו.
שלב ביצוע האימון הוא חלק קטן ממחזור החיים של משימת למידת מכונה. לכן, ניצול צומתי העובדים בשלב של ביצוע האימון לא מעיד על היעילות הכוללת של המשימה. לדוגמה, גם אם שלב האימון פועל ביעילות של 100%, היעילות הכוללת עשויה להיות נמוכה אם יש הפסקות תכופות או אם לוקח הרבה זמן להמשיך את האימון אחרי הפסקות.
הטמעה ומעקב אחרי מדדי קצב העברת נתונים (goodput)
כדי להבטיח מדידה ואופטימיזציה הוליסטית של הביצועים, כדאי להעביר את המיקוד ממדדים רגילים של יעילות משאבים כמו MFU לתפוקה יעילה. התפוקה האפקטיבית מביאה בחשבון את הזמינות והניצול של האשכולות ומשאבי המחשוב, ועוזרת למדוד את יעילות המשאבים בכמה שכבות.
המדדים של תפוקת הנתונים מתמקדים בהתקדמות הכוללת של משימה, ולא בשאלה אם המשימה נראית עסוקה. מדדי ה-Goodput עוזרים לכם לבצע אופטימיזציה של משימות האימון כדי לשפר באופן משמעותי את הפרודוקטיביות והביצועים הכוללים.
המדד "תפוקת נתונים" מאפשר לכם להבין לעומק את ההפסדים הפוטנציאליים ביעילות באמצעות המדדים הבאים:
- תפוקת תזמון היא חלק הזמן שבו כל המשאבים שנדרשים לאימון או להצגה זמינים לשימוש.
- תפוקת זמן הריצה מייצגת את שיעור שלבי האימון השימושיים שהושלמו במהלך תקופה נתונה.
- תפוקת התוכנית היא שיא הביצועים של החומרה או ה-MFU שמשימת אימון יכולה להפיק מהמאיץ. הוא תלוי בניצול יעיל של משאבי המחשוב הבסיסיים במהלך האימון.
אופטימיזציה של קצב העברת הנתונים בפועל (goodput) בתזמון
כדי לבצע אופטימיזציה של תזמון קצב הנתונים האפקטיבי של עומס עבודה, צריך לזהות את דרישות התשתית הספציפיות של עומס העבודה. לדוגמה, להסקת מסקנות באצווה, להסקת מסקנות בסטרימינג ולאימון יש דרישות שונות:
- עומסי עבודה של הסקת מסקנות באצווה יכולים להתמודד עם הפרעות ועיכובים מסוימים בזמינות המשאבים.
- עומסי עבודה של הסקת מסקנות בסטרימינג דורשים תשתית ללא שמירת מצב (stateless).
- עומסי עבודה של אימון דורשים התחייבויות לתשתית לטווח ארוך יותר.
בחירת מצבי הזמינות המתאימים
במחשוב ענן, זמינות היא היכולת להקצות משאבים כשצריך אותם. ב- Google Cloud יש את מצבי הזמינות הבאים:
- VMs על פי דרישה: אתם מקצים מכונות וירטואליות של Compute Engine כשאתם צריכים אותן, ומריצים את עומסי העבודה במכונות הווירטואליות. הבקשה להקצאת משאבים כפופה לזמינות של משאבים, כמו מעבדי GPU. אם אין כמות מספיקה של סוג המשאב המבוקש, הבקשה נכשלת.
- VM במודל Spot: אתם יוצרים מכונות וירטואליות באמצעות קיבולת מחשוב שלא בשימוש. החיוב על מכונות וירטואליות במודל Spot הוא במחיר מוזל בהשוואה למכונות וירטואליות על פי דרישה, אבלGoogle Cloud יכול להחליף את המכונות הווירטואליות במודל Spot בכל שלב. אנחנו ממליצים להשתמש ב-VM במודל Spot לעומסי עבודה בלי שמירת מצב שיכולים להיכשל בצורה חלקה כשהמכונות הווירטואליות המארחות נקטעות.
- הזמנות: אתם מזמינים קיבולת כמאגר של מכונות וירטואליות. הזמנות מתאימות לעומסי עבודה שצריכים הבטחת קיבולת. כדי להבטיח שהמשאבים יהיו זמינים כשתצטרכו אותם, אתם יכולים להשתמש במקומות שמורים ולמקסם את התפוקה של התזמון.
מתזמן משימות לפריסת workload דינמית (DWS): מנגנון הקצאה שמכניס לתור בקשות למכונות וירטואליות מבוססות-GPU במאגר ייעודי. בעזרת מתזמן משימות לפריסת workload דינמית (DWS) אפשר להימנע מהמגבלות של מצבי הזמינות האחרים:
- מצבים של חוסר במלאי במצב "לפי דרישה".
- אילוץ חוסר המצב (statelessness) והסיכון להפקעה של מכונות וירטואליות במודל Spot.
- ההשלכות של ההזמנות על העלות והזמינות.
בטבלה הבאה מפורטים מצבי הזמינות של שירותי Google Cloud, עם קישורים למסמכי התיעוד הרלוונטיים:
| מוצר | מכונות וירטואליות על פי דרישה | VMs במודל Spot | הזמנות | מתזמן משימות לפריסת workload דינמית (DWS) |
|---|---|---|---|---|
| Compute Engine | יצירת מכונה של Compute Engine והפעלה שלה | מידע על VM במודל Spot | מידע על הזמנות | יצירת MIG עם מכונות וירטואליות עם GPU |
| GKE | הוספה וניהול של מאגרי צמתים | מידע על מכונות וירטואליות במודל Spot ב-GKE | שימוש במשאבים שמורים של תחום מוגדר | צריכת GPU, Cloud TPU ו-H4D עם הקצאה מסוג "התחלה גמישה" |
| Batch | יצירה והרצה של משימה | משימה באצווה עם VM במודל Spot | איך מוודאים שיהיו משאבים זמינים באמצעות שמירת מקום למכונות וירטואליות | שימוש במעבדים גרפיים ובמכונות וירטואליות מסוג Flex-start |
| אימון מנוהל ב-Agent Platform | יצירת משימת אימון ללא שרת (serverless) | שימוש ב-VM במודל Spot למשימות אימון | שימוש בהזמנות למשימות אימון | תזמון משימות אימון על סמך זמינות המשאבים |
| Agent Platform | לקבל הסקות באצווה והסקות אונליין ממודלים שאומנו בהתאמה אישית. | שימוש ב-VM במודל Spot להסקה | שימוש בהזמנות להסקת מסקנות אונליין | שימוש במכונות וירטואליות מסוג Flex-start להסקת מסקנות |
תכנון אירועי תחזוקה
כדי לשפר את התפוקה של התזמון, כדאי לצפות מראש את התחזוקה והשדרוגים של התשתית ולתכנן אותם.
ב-GKE אתם יכולים לקבוע מתי תתבצע תחזוקה אוטומטית של האשכולות. מידע נוסף זמין במאמר חלונות זמן לתחזוקה והחרגות.
ב-Compute Engine יש את היכולות הבאות:
- כדי להמשיך להריץ מכונה במהלך אירוע מארח, כמו תחזוקה מתוכננת של החומרה הבסיסית, Compute Engine מבצע מיגרציה פעילה של המכונה למארח אחר באותו אזור. מידע נוסף זמין במאמר תהליך המיגרציה הפעילה במהלך אירועי תחזוקה.
- כדי לקבוע איך המכונה תגיב כשהמארח הבסיסי דורש תחזוקה או כשיש בו שגיאה, אתם יכולים להגדיר מדיניות תחזוקה למארח של המכונה.
במאמר ניהול אירועים במארח במכונות Compute Engine מוסבר איך לתכנן אירועים במארח שקשורים לאשכולות אימון גדולים ב-AI Hypercomputer.
אופטימיזציה של קצב העברת הנתונים בפועל בזמן הריצה
תהליך אימון המודל מופסק לעיתים קרובות על ידי אירועים כמו נקודות בקרה של המודל והפקעת משאבים. כדי לבצע אופטימיזציה של תפוקת הנתונים בזמן הריצה, צריך לוודא שהמערכת ממשיכה את האימון וההסקה ביעילות אחרי שהתשתית הנדרשת מוכנה ואחרי כל הפרעה.
במהלך אימון המודל, חוקרי AI משתמשים בנקודות ביקורת כדי לעקוב אחרי ההתקדמות ולצמצם את אובדן הלמידה שנגרם כתוצאה מהפקעת משאבים. ככל שהמודל גדול יותר, כך ההפרעות בנקודות הבדיקה ארוכות יותר, וזה משפיע עוד יותר על היעילות הכוללת. אחרי הפסקות, צריך להפעיל מחדש את אפליקציית האימון בכל צומת באשכול. ההפעלות מחדש האלה יכולות להימשך זמן מה, כי צריך לטעון מחדש את פריטי המידע שנוצרו בתהליך הפיתוח (artifacts) הנדרשים.
כדי לשפר את קצב העברת הנתונים בזמן הריצה, אפשר להשתמש בשיטות הבאות:
| תכונה | תיאור |
|---|---|
| הטמעת נקודות ביקורת אוטומטיות. | נקודות ביקורת תכופות מאפשרות לעקוב אחרי התקדמות האימון ברמה מפורטת. עם זאת, תהליך האימון מופסק בכל נקודת בקרה, מה שמפחית את התפוקה הטובה בזמן הריצה. כדי לצמצם את ההפרעות, אפשר להגדיר נקודות ביקורת אוטומטיות, שבהן האות SIGTERM של המארח מפעיל את היצירה של נקודת ביקורת. הגישה הזו מגבילה את ההפרעות של נקודות הבדיקה למקרים שבהם המארח זקוק לתחזוקה. חשוב לזכור שחלק מהתקלות בחומרה לא מפעילות אותות SIGTERM, ולכן צריך למצוא את האיזון המתאים בין נקודות ביקורת אוטומטיות לבין אירועי SIGTERM. כדי להגדיר נקודות ביקורת אוטומטיות, אפשר להשתמש בשיטות הבאות:
|
| השתמשו בשיטות מתאימות לטעינת מאגר תגים. | באשכול GKE, לפני שהצמתים יכולים להמשיך את משימות האימון, יכול להיות שייקח קצת זמן לסיים את הטעינה של פריטי המידע שנוצרו בתהליך הפיתוח (Artifact) הנדרשים, כמו נתונים או נקודות ביקורת של מודלים. כדי לצמצם את הזמן שנדרש לטעינה מחדש של הנתונים ולחידוש האימון, אפשר להשתמש בשיטות הבאות:
|
| שימוש במטמון של הקומפילציה. | אם האימון דורש מחסנית מבוססת-קומפילציה, כדאי לבדוק אם אפשר להשתמש במטמון קומפילציה. כשמשתמשים במטמון קומפילציה, תרשים החישוב לא עובר קומפילציה מחדש אחרי כל הפסקה באימון. החיסכון בזמן ובעלויות שנובע מכך מועיל במיוחד כשמשתמשים ב-Cloud TPU. ב-JAX אפשר לאחסן את המטמון של הקומפילציה בקטגוריה של Cloud Storage, ואז להשתמש בנתונים שנשמרו במטמון במקרה של הפרעות. |
אופטימיזציה של קצב הנתונים האפקטיבי של התוכנית
תפוקת הנתונים של התוכנית מייצגת את ניצול המשאבים בשיא במהלך האימון, וזו הדרך המקובלת למדוד את יעילות האימון וההצגה. כדי לשפר את התפוקה של התוכנית, צריך אסטרטגיית הפצה אופטימלית, חפיפה יעילה בין החישוב לתקשורת, גישה אופטימלית לזיכרון וצינורות עיבוד נתונים יעילים.
כדי לשפר את קצב העברת הנתונים של התוכנית, אפשר להשתמש בשיטות הבאות:
| האסטרטגיה | תיאור |
|---|---|
| להשתמש באפשרויות התאמה אישית ברמת המסגרת. | מסגרות או קומפיילרים כמו Accelerated Linear Algebra (XLA) מספקים הרבה רכיבים מרכזיים של קצב העברת הנתונים של התוכנית. כדי לשפר עוד יותר את הביצועים, אתם יכולים להתאים אישית רכיבים בסיסיים בתרשים החישוב. לדוגמה, Pallas תומך בקרנלים בהתאמה אישית ל-Cloud TPU ולמעבדי GPU. |
| העברת זיכרון ל-DRAM של המארח. | באימון בקנה מידה גדול, שדורש נפח זיכרון גדול במיוחד מהמאיצים, אפשר להעביר חלק מהשימוש בזיכרון ל-DRAM של המארח. לדוגמה, JAX ו-XLA מאפשרים להעביר את הפעלות המודל מהמעבר קדימה לזיכרון המארח במקום להשתמש בזיכרון של המאיץ. בעזרת האסטרטגיה הזו, אתם יכולים לשפר את ביצועי האימון על ידי הגדלת קיבולת המודל או גודל האצווה. |
| להשתמש בקוונטיזציה במהלך האימון. | כדי לשפר את יעילות האימון ואת קצב העברת הנתונים של התוכנית, אפשר להשתמש בכימות המודל במהלך האימון. האסטרטגיה הזו מפחיתה את הדיוק של הגרדיאנטים או המשקלים במהלך שלבים מסוימים של האימון, וכך משפרת את קצב העברת הנתונים של התוכנית. עם זאת, יכול להיות שהאסטרטגיה הזו תדרוש מאמץ הנדסי נוסף במהלך פיתוח המודל. מידע נוסף זמין במקורות המידע הבאים: |
| הטמעת מקביליות. | כדי להגביר את הניצול של משאבי המחשוב הזמינים, אפשר להשתמש באסטרטגיות של מקביליות ברמת המודל במהלך האימון ובזמן טעינת הנתונים. למידע נוסף על מקביליות מודלים:
כדי להשיג מקביליות נתונים, אפשר להשתמש בכלים כמו:
|
התמקדות בדרישות ספציפיות לעומסי עבודה (workloads)
כדי לוודא שהמאמצים שלכם לאופטימיזציה של הביצועים יהיו יעילים והוליסטיים, אתם צריכים להתאים את החלטות האופטימיזציה לדרישות הספציפיות של עומסי העבודה של האימון וההסקה. לבחור מודלי AI מתאימים ולהשתמש באסטרטגיות רלוונטיות לאופטימיזציה של פרומפטים. לבחור את המסגרות והכלים המתאימים בהתאם לדרישות של עומסי העבודה.
זיהוי דרישות ספציפיות לעומסי עבודה
חשוב לבדוק את הדרישות והמגבלות של עומסי העבודה בתחומים הבאים:
| אזור | תיאור |
|---|---|
| דרישות לגבי המשימות והאיכות | הגדירו את המשימה העיקרית של עומס העבודה ואת בסיס ההשוואה לביצועים. עונים על שאלות כמו:
|
| הקשר הצגת המודעות | לנתח את הסביבה התפעולית שבה אתם מתכננים לפרוס את המודל. ההקשר שבו המודעה מוצגת משפיע בדרך כלל באופן משמעותי על החלטות העיצוב. כדאי להביא בחשבון את הגורמים הבאים:
|
| מיומנויות וכלכלה של צוותים | להעריך את הערך העסקי של רכישת הפתרון לעומת העלות והמורכבות של הפיתוח והתחזוקה שלו. בדקו אם לצוות שלכם יש את הכישורים המיוחדים שנדרשים לפיתוח מודל בהתאמה אישית, או אם שירות מנוהל יכול לספק ערך מהר יותר. |
בחירת מודל מתאים
אם API או מודל פתוח יכולים לספק את הביצועים והאיכות הנדרשים, השתמשו בהם.
למשימות ספציפיות למודל, כמו זיהוי תווים אופטי (OCR), הוספת תוויות וניהול תוכן, כדאי לבחור ממשקי API של למידת מכונה כמו:
לאפליקציות של AI גנרטיבי, כדאי להשתמש במודלים של Google כמו Gemini, Imagen ו-Veo.
ב-Model Garden תוכלו לבחור מתוך אוסף של מודלים בסיסיים ומודלים ספציפיים למשימות של Google. ב-Model Garden יש גם מודלים פתוחים כמו Gemma ומודלים של צד שלישי, שאפשר להריץ ב-Agent Platform או לפרוס בסביבות זמן ריצה כמו GKE.
אם אפשר להשלים משימה באמצעות ממשק API של למידת מכונה או מודל AI גנרטיבי, כדאי להביא בחשבון את מורכבות המשימה. למשימות מורכבות, מודלים גדולים כמו Gemini יכולים לספק ביצועים טובים יותר ממודלים קטנים יותר.
איך משפרים את האיכות באמצעות הנדסת פרומפטים טובה יותר
כדי לשפר את האיכות של ההנחיות בקנה מידה נרחב, השתמשו בכלי לאופטימיזציה של הנחיות ב-Agent Platform. אתם לא צריכים לשכתב באופן ידני את ההנחיות וההוראות למערכת. הכלי לאופטימיזציה של הנחיות תומך בגישות הבאות:
- אופטימיזציה ללא דוגמאות: גישה עם זמן אחזור קצר שמשפרת הנחיה אחת או הוראת מערכת אחת בזמן אמת.
- אופטימיזציה מבוססת-נתונים: גישה מתקדמת שמשפרת את ההנחיות על ידי הערכת התשובות של המודל להנחיות לדוגמה, בהתאם למדדי הערכה ספציפיים.
הנחיות נוספות לאופטימיזציה של הנחיות מפורטות במאמר סקירה כללית של אסטרטגיות למתן הנחיות.
שיפור הביצועים של נקודות קצה של למידת מכונה ו-AI גנרטיבי
כדי לשפר את זמן האחזור או את קצב הנתונים (אסימונים לשנייה) של נקודות קצה של למידת מכונה ו-AI גנרטיבי, כדאי לפעול לפי ההמלצות הבאות:
- שמירת תוצאות במטמון באמצעות Memorystore.
- בממשקי API של AI גנרטיבי, השתמשו בשיטות הבאות:
- שמירת הקשר במטמון: זמן אחזור קצר יותר לבקשות שמכילות תוכן חוזר.
- thought הקצאת משאבים לפי התפוקה שנקבעה: שיפור התפוקה של נקודות הקצה של Gemini על ידי שמירת קיבולת תפוקה.
- למודלים באירוח עצמי, כדאי להשתמש במסגרות הבאות להסקת מסקנות:
Framework תיקיות ומדריכים קונטיינרים של vLLM שעברו אופטימיזציה ב-Model Garden פריסת מודלים פתוחים באמצעות קונטיינרים מוגדרים מראש הסקת מסקנות מבוססת-GPU ב-GKE הסקת מסקנות מבוססת-Cloud TPU
שימוש בפתרונות עם תכנות מינימלי ובכוונון
אם המודלים שאומנו מראש לא עונים על הדרישות שלכם, אתם יכולים לשפר את הביצועים שלהם בתחומים ספציפיים באמצעות הפתרונות הבאים:
- AutoML הוא פתרון עם תכנות מינימלי לשיפור תוצאות ההסקה במגוון רחב של משימות, בלי מאמץ טכני רב. בעזרת AutoML אתם יכולים ליצור מודלים שעברו אופטימיזציה בכמה מימדים: ארכיטקטורה, ביצועים ושלב האימון (באמצעות נקודות ביקורת).
- כוונון עוזר לשפר את האיכות, ליצור תוכן יציב יותר ולהפחית את זמן האחזור באמצעות הנחיות קצרות יותר ובלי הרבה נתונים. מומלץ להתחיל את הכוונון באמצעות ערכי ברירת המחדל של ההיפר-פרמטרים. מידע נוסף זמין במאמר מידע על כוונון מפוקח (SFT) של Gemini.
אופטימיזציה של אימון בניהול עצמי
במקרים מסוימים, יכול להיות שתחליטו לאמן מחדש מודל או לנהל באופן מלא משימת כוונון עדין. הגישה הזו דורשת מיומנויות מתקדמות וזמן נוסף, בהתאם למודל, למסגרת ולמשאבים שבהם אתם משתמשים.
כדאי לנצל את האפשרויות של מסגרות שעברו אופטימיזציה לביצועים, כמו:
להשתמש בתמונות או בקונטיינרים של למידה עמוקה, שכוללים את יחסי התלות העדכניים ביותר של התוכנה וספריות ספציפיות ל-Google Cloud.
מריצים אימון מודלים באמצעות Ray ב- Google Cloud:
- Ray on Gemini Enterprise Agent Platform מאפשר לכם להביא את מסגרת האימון המבוזר של Ray ל-Compute Engine או ל-GKE, ומפשט את הניהול של המסגרת.
- אתם יכולים לנהל בעצמכם את Ray ב-GKE באמצעות KubeRay, על ידי פריסת מפעיל Ray באשכול קיים.
פורסים עומסי עבודה של אימון באשכול מחשוב שאתם מקצים באמצעות Cluster Toolkit בקוד פתוח. כדי להקצות ביעילות אשכולות עם אופטימיזציה לביצועים, השתמשו בתוכניות מבוססות-YAML. לנהל את האשכולות באמצעות מתזמנים כמו Slurm ו-GKE.
לאמן ארכיטקטורות של מודלים סטנדרטיים באמצעות מתכונים שעברו אופטימיזציה ל-GPU.
כדי לבנות ארכיטקטורות ואסטרטגיות אימון שמשפרות את הביצועים, אפשר להשתמש בשיטות הבאות:
- להטמיע אימון מבוזר ב-Agent Platform או במסגרות שתוארו קודם. אימון מבוזר מאפשר מקבילוּת של מודלים ומקבילוּת של נתונים, שיכולות לעזור להגדיל את מערך הנתונים לאימון ואת גודל המודל, וגם לקצר את זמן האימון.
- כדי לאמן את המודל ביעילות ולבדוק הגדרות ביצועים שונות, כדאי להריץ נקודות ביקורת במרווחי זמן מתאימים. למידע נוסף, קראו את המאמר אופטימיזציה של קצב הנתונים האפקטיבי בזמן הריצה.
אופטימיזציה של הצגת מודעות בניהול עצמי
כדי לנהל את ההצגה בעצמכם, אתם צריכים פעולות הסקה יעילות וקצב העברה גבוה (מספר ההסקות ליחידת זמן).
כדי לבצע אופטימיזציה של המודל להסקת מסקנות, כדאי להשתמש בגישות הבאות:
כימות: הקטנת המודל על ידי ייצוג הפרמטרים שלו בפורמט עם דיוק נמוך יותר. הגישה הזו עוזרת לצמצם את צריכת הזיכרון ואת זמן האחזור. עם זאת, כימות אחרי האימון עשוי לשנות את איכות המודל. לדוגמה, קוונטיזציה אחרי אימון עלולה לגרום לירידה ברמת הדיוק.
- קוונטיזציה אחרי אימון (PTQ) היא משימה שניתן לחזור עליה. אפשר להשתמש ב-PTQ ב-frameworks עיקריים של למידת מכונה, כמו PyTorch ו-TensorFlow.
- אתם יכולים לתזמר את ה-PTQ באמצעות צינור עיבוד נתונים ב-Agent Platform Pipelines.
- כדי לייצב את ביצועי המודל ולהקטין את גודל המודל, אתם יכולים להשתמש ב-Qwix.
מקביליות של טנזורים: שיפור קצב העיבוד של ההסקה על ידי חלוקת עומס החישוב בין כמה מעבדי GPU.
אופטימיזציה של הזיכרון: הגדלת קצב העיבוד וביצוע אופטימיזציה של שמירת תשומת הלב במטמון, גודל האצווה וגודל הקלט.
משתמשים במסגרות שעברו אופטימיזציה להסקת מסקנות, כמו:
- למודלים גנרטיביים, השתמשו במסגרת פתוחה כמו MaxText, MaxDiffusion או vLLM.
- להריץ קובצי אימג' של קונטיינרים מוכנים מראש ב-Agent Platform כדי לקבל חיזויים והסברים. אם בוחרים ב-TensorFlow, צריך להשתמש בזמן הריצה של TensorFlow שעבר אופטימיזציה. סביבת זמן הריצה הזו מאפשרת הסקה יעילה יותר ובעלות נמוכה יותר מאשר קונטיינרים מוגדרים מראש שמשתמשים ב-TensorFlow בקוד פתוח.
- מריצים הסקה בכמה מארחים באמצעות Pathways.
- משתמשים בשרת ההסקה של NVIDIA Triton ב-Agent Platform.
- כדי לפשט את הפריסה של עומסי עבודה של הסקה ב-GKE, אתם יכולים להשתמש בהגדרות אישיות שעברו אופטימיזציה ל-LLM. מידע נוסף מופיע במאמר ניתוח הביצועים והעלויות של פרסום המודל באמצעות המדריך למתחילים בנושא הסקת מסקנות ב-GKE.
אופטימיזציה של צריכת המשאבים על סמך יעדי הביצועים
אופטימיזציה של המשאבים עוזרת להאיץ את האימון, לבצע איטרציות ביעילות, לשפר את איכות המודל ולהגדיל את קיבולת ההצגה.
בחירת סוגי המעבדים המתאימים
לבחירה של פלטפורמת המחשוב יכולה להיות השפעה משמעותית על יעילות האימון של המודל.
- מודלים של למידה עמוקה פועלים היטב במעבדי GPU וב-Cloud TPU, כי המודלים האלה דורשים כמויות גדולות של זיכרון וחישוב מטריצות מקביל. למידע נוסף על עומסי עבודה שמתאימים למעבדי CPU, למעבדי GPU ול-Cloud TPU, קראו את המאמר מתי להשתמש ב-Cloud TPU.
- מכונות וירטואליות שמותאמות לצריכת מעבד גבוהה מתאימות במיוחד לעומסי עבודה של HPC.
אופטימיזציה של אימון והצגה ב-GPU
כדי לשפר את הביצועים של עומסי עבודה של אימון והסקת מסקנות שפרוסים ב-GPU, כדאי לפעול לפי ההמלצות הבאות:
| המלצה | תיאור |
|---|---|
| בוחרים את מפרט הזיכרון המתאים. | כשבוחרים סוגי מכונות GPU, בוחרים את מפרט הזיכרון לפי הגורמים הבאים:
|
| הערכת הדרישות של רוחב הפס של הליבה והזיכרון. | בנוסף לגודל הזיכרון, כדאי להביא בחשבון דרישות אחרות כמו מספר ליבות ה-Tensor ורוחב הפס של הזיכרון. הגורמים האלה משפיעים על מהירות הגישה לנתונים ועל החישובים בשבב. |
| בחירת סוגי מכונות GPU מתאימים | יכול להיות שתצטרכו סוגים שונים של מכונות GPU לאימון ולשירות.
מומלץ להשתמש במכונות גדולות לאימון ובמכונות קטנות וחסכוניות להסקת מסקנות. כדי לזהות בעיות בניצול המשאבים, אפשר להשתמש בכלי מעקב כמו סוכן NVIDIA DCGM ולשנות את המשאבים בהתאם. |
| שימוש בשיתוף GPU ב-GKE | במקרים מסוימים, הקצאת GPU מלא לקונטיינר אחד עלולה להיות גישה לא יעילה. כדי להתגבר על חוסר היעילות הזה, GKE תומך באסטרטגיות הבאות לשיתוף GPU:
כדי למקסם את ניצול המשאבים, מומלץ להשתמש בשילוב מתאים של האסטרטגיות האלה. לדוגמה, כשמבצעים וירטואליזציה של GPU גדול מסוג H100 באמצעות האסטרטגיות של שיתוף זמן ב-GPU ושל GPU עם כמה מופעים במקביל, פלטפורמת ההצגה יכולה להרחיב אנכית בהתאם לעומס ולהקטין את קנה המידה בהתאם לתעבורת נתונים. משאבי ה-GPU מוקצים מחדש בזמן אמת בהתאם לעומס על הקונטיינרים של המודלים. |
| אופטימיזציה של ניתוב ואיזון עומסים. | כשפורסים כמה מודלים באשכול, אפשר להשתמש ב-GKE Inference Gateway כדי לבצע אופטימיזציה של הניתוב ואיזון העומסים. Inference Gateway מרחיב את מנגנוני הניתוב של Kubernetes Gateway API באמצעות היכולות הבאות:
|
| לשתף משאבים לנקודות קצה ב-Agent Platform. | אתם יכולים להגדיר כמה נקודות קצה של Agent Platform שישתמשו במאגר משאבים משותף. מידע נוסף על התכונה הזו והמגבלות שלה זמין במאמר שיתוף משאבים בין פריסות. |
אופטימיזציה של אימון והצגה ב-Cloud TPU
Cloud TPU מספק שבבים של Google שעוזרים לפתור אתגרים בקנה מידה עצום באלגוריתמים של ML. השבבים האלה מספקים ביצועים אופטימליים לעומסי עבודה של אימון והסקת מסקנות של AI. בהשוואה למעבדי GPU, מעבדי Cloud TPU יעילים יותר באימון ובהצגה של למידה עמוקה. במאמר מתי כדאי להשתמש ב-Cloud TPU מפורטים תרחישים לדוגמה שמתאימים ל-Cloud TPU. Cloud TPU תואם ל-frameworks של למידת מכונה כמו TensorFlow, PyTorch ו-JAX.
כדי לשפר את הביצועים של Cloud TPU, אפשר להשתמש בשיטות הבאות, שמתוארות במדריך לביצועים של Cloud TPU:
- מגדילים את גודל האצווה לכל יחידת זיכרון של Cloud TPU.
- מוודאים שמשאבי Cloud TPU לא נמצאים במצב של חוסר פעילות. לדוגמה, הטמיעו קריאות נתונים מקבילות.
- אופטימיזציה של מהדר ה-XLA. משנים את ממדי הטנזור לפי הצורך ונמנעים מריפוד. XLA מבצע אופטימיזציה אוטומטית של ביצועי הגרף באמצעות כלים כמו מיזוג ושידור.
אופטימיזציה של האימון ב-Cloud TPU והצגת המודעות ב-GPU
Cloud TPU תומך באימון יעיל. מעבדי GPU מספקים גמישות וזמינות רחבה יותר לעומסי עבודה של הסקת מסקנות. כדי לשלב את היתרונות של Cloud TPU ושל מעבדי GPU, אתם יכולים לאמן מודלים ב-Cloud TPU ולהציג אותם במעבדי GPU. הגישה הזו יכולה לעזור להפחית את העלויות הכוללות ולהאיץ את הפיתוח, במיוחד במודלים גדולים. במאמרים אזורים ותחומים של Cloud TPU ומיקומי GPU מפורטים המיקומים שבהם זמינים סוגי המכונות של Cloud TPU ו-GPU.
אופטימיזציה של שכבת האחסון
שכבת האחסון של תשתית האימון וההצגה היא קריטית לביצועים. משימות אימון ועומסי עבודה של הסקת מסקנות כוללים את הפעילויות הבאות שקשורות לאחסון:
- טעינה ועיבוד של נתונים.
- יצירת נקודות ביקורת במודל במהלך האימון.
- טעינה מחדש של קובצי בינארי כדי להמשיך את האימון אחרי הפקעת צמתים.
- טעינת המודל ביעילות כדי לטפל בהסקת מסקנות בקנה מידה רחב.
הגורמים הבאים קובעים את הדרישות שלכם לגבי קיבולת האחסון, רוחב הפס וזמן האחזור:
- גודל המודל
- נפח מערך הנתונים לאימון
- תדירות נקודות הבדיקה
- דפוסי התאמה לעומס (scaling)
אם נתוני האימון נמצאים ב-Cloud Storage, אתם יכולים להשתמש בשמירת קבצים במטמון ב-Cloud Storage FUSE כדי לצמצם את זמן האחזור של טעינת הנתונים. באמצעות Cloud Storage FUSE אפשר לטעון קטגוריה של Cloud Storage בצומתי מחשוב שיש להם דיסקים מסוג Local SSD. למידע על שיפור הביצועים של Cloud Storage FUSE, ראו שיטות מומלצות לכוונון הביצועים.
מחבר PyTorch ל-Cloud Storage מספק ביצועים גבוהים לקריאה ולכתיבה של נתונים. המחבר הזה שימושי במיוחד לאימון עם מערכי נתונים גדולים ולשמירת נקודות ביקורת של מודלים גדולים.
ב-Compute Engine יש תמיכה בסוגים שונים של Persistent Disk. באמצעות Google Cloud Hyperdisk ML, אתם יכולים להקצות את קצב הנתונים ופעולות הקלט/פלט לשנייה (IOPS) הנדרשים בהתאם לצורכי האימון. כדי לשפר את הביצועים של הדיסקים, קודם משנים את הגודל שלהם ואז שוקלים לשנות את סוג המכונה. מידע נוסף זמין במאמר אופטימיזציה של ביצועי Persistent Disk. כדי לבדוק את העומס של ביצועי הקריאה והכתיבה וזמן האחזור בשכבת האחסון, אתם יכולים להשתמש בכלים כמו Flexible I/O tester (FIO).
מידע נוסף על בחירה ואופטימיזציה של שירותי אחסון לעומסי עבודה של AI ו-ML זמין במאמר סקירה כללית על שירותי אחסון לעומסי עבודה של AI ו-ML ב-AI Hypercomputer.
אופטימיזציה של שכבת הרשת
כדי לשפר את הביצועים של עומסי עבודה של AI ו-ML, צריך להגדיר את רשתות ה-VPC כך שיספקו רוחב פס מתאים וקצב העברת נתונים מקסימלי עם זמן אחזור מינימלי. כדאי לשקול את ההמלצות הבאות:
| המלצה | שיטות מומלצות להטמעה |
|---|---|
| לבצע אופטימיזציה של רשתות VPC. |
|
| למקם את המכונות הווירטואליות קרוב יותר זו לזו. | |
| הגדרת מכונות וירטואליות לתמיכה במהירויות רשת גבוהות יותר. |
|
קישור בין מדדי ביצועים לבין בחירות של עיצוב והגדרות אישיות
כדי לחדש, לפתור בעיות ולחקור בעיות בביצועים, צריך ליצור קשר ברור בין בחירות העיצוב לבין תוצאות הביצועים. אתם צריכים תיעוד אמין של שושלת נתונים של נכסי ML, פריסות, הפלטים מהמודלים וההגדרות והקלט המתאימים שהפיקו את הפלטים.
בניית מערכת לשושלת נתונים ומודלים
כדי לשפר את הביצועים באופן עקבי, אתם צריכים להיות מסוגלים לעקוב אחרי כל גרסת מודל עד לנתונים, לקוד ולהגדרות המדויקים ששימשו ליצירת המודל. כשמרחיבים את המודל, קשה יותר לעקוב אחריו. אתם צריכים מערכת שושלת נתונים שתהפוך את תהליך המעקב לאוטומטי ותיצור רשומה ברורה שאפשר לשלוח אליה שאילתות בכל ניסוי. המערכת הזו מאפשרת לצוותים לזהות ביעילות את הבחירות שמובילות למודלים עם הביצועים הכי טובים, ולשחזר אותן.
כדי לראות ולנתח את שושלת היוחסין של פריטי המידע שנוצרו בתהליך העבודה של עומסי העבודה ב-Agent Platform, אתם יכולים להשתמש ב-Agent Platform ML Metadata או ב-Knowledge Catalog. שתי האפשרויות מאפשרות לרשום אירועים או פריטי מידע כדי לעמוד בדרישות הפיקוח, לשלוח שאילתות למטא-נתונים ולאחזר מידע לפי הצורך. בקטע הזה מופיעה סקירה כללית של שתי האפשרויות. למידע מפורט על ההבדלים בין Agent Platform ML Metadata לבין Knowledge Catalog, קראו את המאמר מעקב אחרי השושלת של פריטי Pipeline.
הטמעה כברירת מחדל: Agent Platform ML Metadata
בהפעלה הראשונה של צינור עיבוד הנתונים או הניסוי ב-Agent Platform, נוצר שירות ברירת מחדל של Agent Platform ML Metadata. הפרמטרים והמטא-נתונים של ארטיפקטים שנוצרים ונצרכים על ידי פייפליין נרשמים באופן אוטומטי במאגר מטא-נתונים של ML ב-Agent Platform. מודל הנתונים שמשמש לארגון ולקישור של המטא-נתונים המאוחסנים מכיל את הרכיבים הבאים:
- הקשר: קבוצה של פריטי מידע וביצועים שמייצגת הרצה של ניסוי.
- הרצה: שלב בתהליך עבודה, כמו אימות נתונים או אימון מודל.
- פריט מידע: ישות, אובייקט או נתון של קלט או פלט, שתהליך העבודה מייצר וצורך.
- אירוע: קשר בין פריט מידע לבין הפעלה.
כברירת מחדל, המטא-נתונים של Agent Platform ML מתעדים ועוקבים אחרי כל פריטי המידע של הקלט והפלט של הרצת צינור עיבוד נתונים. הוא משלב את פריטי המידע האלה עם ניסויים ב-Agent Platform, מרשם המודלים ומערכי נתונים מנוהלים ב-Agent Platform.
רישום אוטומטי ביומן הוא תכונה מובנית ב-Agent Platform Managed Training, שמשמשת לרישום אוטומטי של נתונים ב-Experiments ב-Agent Platform. כדי לעקוב ביעילות אחרי ניסויים לשיפור הביצועים, אתם יכולים להשתמש בשילובים המובנים בין Experiments on Agent Platform לבין שירות Agent Platform ML Metadata המשויך.
ב-Agent Platform ML Metadata יש תחביר סינון ואופרטורים להרצת שאילתות על פריטי מידע שנוצר, הפעלות והקשרים. במקרה הצורך, הצוותים שלכם יכולים לאחזר ביעילות מידע על הקישור לרישום של המודל ועל קבוצת הנתונים או ההערכה שלו להרצה של ניסוי ספציפי. המטא-נתונים האלה יכולים לעזור לכם לגלות מהר יותר אפשרויות שישפרו את הביצועים. לדוגמה, אתם יכולים להשוות בין הרצות של צינורות עיבוד נתונים, להשוות בין מודלים ולהשוות בין הרצות של ניסויים. למידע נוסף, כולל שאילתות לדוגמה, ראו ניתוח מטא-נתונים.
הטמעה חלופית: Knowledge Catalog
Knowledge Catalog מגלה מטא-נתונים ממשאביGoogle Cloud , כולל פריטי מידע שנוצרו ב-Agent Platform. אפשר גם לשלב מקור נתונים בהתאמה אישית.
ב-Knowledge Catalog אפשר לקרוא מטא-נתונים בכמה אזורים ובמאגרים ברמת הארגון, ואילו Agent Platform ML Metadata הוא משאב ספציפי לפרויקט. בהשוואה ל-Agent Platform ML Metadata, ההגדרה של Knowledge Catalog דורשת יותר מאמץ. עם זאת, יכול להיות ש-Knowledge Catalog יתאים לכם אם אתם צריכים לשלב את מאגר הנתונים הרחב יותר ב- Google Cloud עם מאגרים ברמת הארגון.
ב-Knowledge Catalog מתבצעים גילוי ואיסוף של מטא-נתונים לפרויקטים שבהם Data Lineage API מופעל. המטא-נתונים בקטלוג מאורגנים באמצעות מודל נתונים שמורכב מפרויקטים, מקבוצות של רשומות, מרשומות ומהיבטים. ב-Knowledge Catalog יש תחביר ספציפי שבו אפשר להשתמש כדי לגלות פריטי מידע. אם צריך, תוכלו למפות פריטי מטא-נתונים ל-Knowledge Catalog.
שימוש בכלים להסבר על המודל
ההתנהגות של מודל AI מבוססת על הנתונים ששימשו לאימון המודל. ההתנהגות הזו מקודדת כפרמטרים בפונקציות מתמטיות. קשה להבין בדיוק למה מודל פועל בצורה מסוימת. עם זאת, המידע הזה חיוני לאופטימיזציה של הביצועים.
לדוגמה, נניח שיש מודל לסיווג תמונות שנתוני האימון שלו מכילים רק תמונות של מכוניות אדומות. המודל עשוי ללמוד לזהות את התווית "מכונית" על סמך צבע האובייקט, במקום על סמך מאפייני המרחב והצורה של האובייקט. אם בודקים את המודל עם תמונות של מכוניות בצבעים שונים, יכול להיות שהביצועים של המודל יהיו פחות טובים. בקטעים הבאים מתוארים כלים שבהם אפשר להשתמש כדי לזהות בעיות כאלה ולנתח אותן.
זיהוי הטיות בנתונים
בשלב ניתוח הנתונים למחקר (EDA) של פרויקט ML, מזהים בעיות בנתונים, כמו מערכי נתונים לא מאוזנים והטיות.
במערכות ייצור, לעיתים קרובות מאמנים מחדש מודלים ומריצים ניסויים עם מערכי נתונים שונים. כדי ליצור סטנדרטיזציה של הנתונים ולהשוות בין ניסויים, מומלץ להשתמש בגישה שיטתית ל-EDA שכוללת את המאפיינים הבאים:
- אוטומציה: ככל שקבוצת הנתונים לאימון גדלה, תהליך ה-EDA צריך לפעול באופן אוטומטי ברקע.
- כיסוי רחב: כשמוסיפים תכונות חדשות, ניתוח הנתונים החקירתי צריך לחשוף תובנות לגבי התכונות החדשות.
הרבה משימות של EDA הן ספציפיות לסוג הנתונים ולהקשר העסקי. כדי להפוך את תהליך ה-EDA לאוטומטי, אפשר להשתמש ב-BigQuery או בשירות מנוהל לעיבוד נתונים כמו Dataflow. מידע נוסף זמין במאמרים סיווג של נתונים לא מאוזנים ומדדים להטיה בנתונים ב-Agent Platform.
הסבר על המאפיינים וההתנהגות של המודל
בנוסף להבנת התפלגות הנתונים בקבוצות הנתונים לאימון ולתיקוף וההטיות שלהן, צריך להבין את המאפיינים וההתנהגות של המודל בזמן החיזוי. כדי להבין את ההתנהגות של המודל, אפשר להשתמש בכלים הבאים:
| כלי | תיאור | מטרות |
|---|---|---|
| הסברים מבוססי-דוגמאות | אתם יכולים להשתמש בהסברים שמבוססים על דוגמאות או בחיפוש של השכן הקרוב ביותר כדי להבין חיזוי, על ידי מציאת הדוגמאות הדומות ביותר מנתוני האימון. הגישה הזו מבוססת על העיקרון שקלט דומה מניב פלט דומה. |
|
| הסברים מבוססי-תכונות | בתחזיות שמבוססות על נתונים בטבלה או על תמונות, הסברים שמבוססים על מאפיינים מראים עד כמה כל מאפיין משפיע על התחזית בהשוואה לקו בסיס. שיטות הסבר והסברים טבלאיים מספקים שיטות לשיוך תכונות בהתאם לסוג המודל ולמשימה. השיטות בדרך כלל מסתמכות על דגימה וניתוח רגישות כדי למדוד את מידת השינוי בפלט בתגובה לשינויים בתכונת קלט. |
|
| What-If Tool | What-If Tool פותח במסגרת יוזמת People + AI Research (PAIR) של Google, כדי לעזור לכם להבין את ההתנהגות של מודלים של תמונות וטבלאות ולהמחיש אותה באופן חזותי. דוגמאות לשימוש בכלי מופיעות במאמר הדגמות באינטרנט של What-If Tool. |
|
שותפים ביצירת התוכן
מחברים:
- בנימין סדיק | מהנדס לקוחות מומחה ל-AI ול-ML
- Filipe Gracio, PhD | Customer Engineer, AI/ML Specialist
תורמים אחרים:
- דניאל ליס | ארכיטקט אבטחה בענן
- קומאר דהנגופאל | מפתח פתרונות למוצרים שונים