במאמר הזה מוצגת ארכיטקטורת הפניה שמראה איך להטמיע תהליך עבודה מלא של יצירת מועמדים באמצעות Vertex AI. מסגרת המודלים של שני מגדלים היא טכניקת אחזור יעילה לתרחישי שימוש בהתאמה אישית, כי היא לומדת את הדמיון הסמנטי בין שתי ישויות שונות, כמו שאילתות באינטרנט ופריטים פוטנציאליים.
המסמך הזה מיועד לאנשי מקצוע טכניים כמו מדעני נתונים ומהנדסי למידת מכונה שמפתחים אפליקציות המלצה בקנה מידה גדול עם דרישות של שירות עם השהיה נמוכה. מידע נוסף על טכניקות המידול, על הגדרת הבעיה ועל הכנת הנתונים לבניית מודל דו-מגדלי זמין במאמר Scaling deep retrieval with TensorFlow Recommenders and Vector Search (הרחבת אחזור עמוק באמצעות TensorFlow Recommenders וחיפוש וקטורי).
ארכיטקטורה
הדיאגרמה הבאה מציגה ארכיטקטורה לאימון מודל דו-מגדלי ולפריסה של כל מגדל בנפרד למשימות שונות של פריסה והצגה:
הארכיטקטורה בדיאגרמה כוללת את הרכיבים הבאים:
- נתוני אימון: קובצי האימון מאוחסנים ב-Cloud Storage.
- אימון של שני מודלים: המודל המשולב של שני המודלים מאומן אופליין באמצעות שירות האימון של Vertex AI. כל מודל נשמר בנפרד ומשמש למשימות שונות.
- שאילתה רשומה ומגדלי מועמדים: אחרי שמסיימים לאמן את המגדלים, כל מגדל מועלה בנפרד אל מרשם המודלים של Vertex AI.
- פריסת מגדל שאילתות: מגדל השאילתות הרשום נפרס בנקודת קצה אונליין של Vertex AI.
- חיזוי הטמעה של קבוצת פריטים: מגדל המועמדים הרשום משמש במשימת חיזוי של קבוצת פריטים כדי לבצע חישוב מראש של ייצוגי ההטמעה של כל הפריטים המועמדים הזמינים.
- Embeddings JSON: הווקטורים המשובצים החזויים נשמרים בקובץ JSON ב-Cloud Storage.
- אינדקס ANN: נעשה שימוש ב-Vertex AI Vector Search כדי ליצור אינדקס להצגת נתונים שהוגדר לחיפוש של השכן הקרוב ביותר (ANN) בקירוב.
- אינדקס שנפרס: אינדקס ה-ANN נפרס לנקודת קצה של אינדקס Vector Search ב-Vertex AI.
המוצרים שהשתמשו בהם
ארכיטקטורת ההפניה הזו כוללת את המוצרים הבאים Google Cloud :
- Vertex AI Training: שירות אימון מנוהל באופן מלא שמאפשר לכם להפעיל אימון של מודלים רחבי היקף.
- חיפוש וקטורי: שירות להתאמת דמיון וקטורי שמאפשר לכם לאחסן, ליצור אינדקס ולחפש נתונים שדומים או קשורים מבחינה סמנטית.
- מרשם המודלים של Vertex AI: מאגר מרכזי שבו אפשר לנהל את מחזור החיים של מודלים של למידת מכונה.
- Cloud Storage: מאגר אובייקטים ללא הגבלה בעלות נמוכה, לשימוש עם סוגים שונים של נתונים. אפשר לגשת לנתונים מתוך Google Cloudומחוץ לה, והם משוכפלים במיקומים שונים כדי ליצור יתירות.
תרחיש לדוגמה
כדי לעמוד בדרישות של הצגת המלצות עם זמן אחזור נמוך, מערכות המלצה בקנה מידה גדול מופעלות לעיתים קרובות בסביבת ייצור כמערכות דו-שלביות או לעיתים כמערכות רב-שלביות. המטרה של השלב הראשון, יצירת מועמדים, היא לסנן אוסף גדול של פריטים מועמדים ולאחזר קבוצת משנה רלוונטית של מאות פריטים למשימות סינון ודירוג downstream. כדי לבצע אופטימיזציה של משימת השליפה הזו, כדאי להתמקד בשני היעדים העיקריים הבאים:
- במהלך אימון המודל, המודל לומד מהו הייצוג הטוב ביותר של הבעיה או המשימה שצריך לפתור, ומרכיב את הייצוג הזה ב
<query, candidate>הטמעות. - במהלך פרסום המודל, צריך לאחזר פריטים רלוונטיים מספיק מהר כדי לעמוד בדרישות של זמן האחזור.
התרשים הבא מציג את הרכיבים הקונספטואליים של שירות המלצות דו-שלבי:
בתרשים, סינון יצירת המועמדים מסנן מיליוני פריטים מועמדים. לאחר מכן, המערכת מסננת את מאות הפריטים הפוטנציאליים שמתקבלים כדי להציג עשרות פריטים מומלצים.
ארכיטקטורת ההפניה במסמך הזה מאמנת מודל אחזור מבוסס-שני-מגדלים. בארכיטקטורה, כל מגדל הוא רשת נוירונים שמעבדת תכונות של שאילתה או של פריט מועמד, ואז יוצרת הטמעה של התכונות האלה. כל מגדל נפרס בנפרד, כי כל מגדל ישמש למשימות שונות בייצור:
- מגדל המועמדים: מגדל המועמדים משמש לחישוב מראש של הטמעות לכל הפריטים המועמדים. ההטמעות שחושבו מראש נפרסות בנקודת קצה של אינדקס Vertex AI Vector Search שעברה אופטימיזציה לאחזור עם חביון נמוך.
- מגדל שאילתות פרוס: במהלך מילוי בקשה באופן מיידי, מגדל השאילתות הפרוס ממיר שאילתות גולמיות של משתמשים להטמעות. לאחר מכן משתמשים בהטמעות האלה כדי לחפש הטמעות דומות של פריטים באינדקס שנפרס.
ארכיטקטורות של שני מגדלים הן אידיאליות למשימות רבות של אחזור מידע, כי הן מתעדות את הקשר הסמנטי בין השאילתה לבין ישויות מועמדות, וממפות אותן למרחב הטמעה משותף. כשממפים את הישויות למרחב הטמעה משותף, ישויות דומות מבחינה סמנטית מקובצות קרוב יותר זו לזו. לכן, אם מחשבים את הטמעות הווקטוריות של שאילתה מסוימת, אפשר לחפש במרחב ההטמעה את הפריטים הקרובים ביותר (הדומים ביותר). היתרון העיקרי של ארכיטקטורה כזו הוא היכולת להפריד בין ההסקה של ייצוגי השאילתות והמועמדים. היתרונות של ההפרדה הזו הם בעיקר כפולים:
- אתם יכולים להציג פריטים חדשים בלי לאמן מחדש אוצר מילים של פריטים חדשים. אם מזינים קבוצה של מאפייני פריט למודל המועמד לפריט, אפשר לחשב את הטמעות הפריט לכל קבוצה של מועמדים, גם אם הם לא נראו במהלך האימון. החישוב הזה עוזר לפתור את בעיית ההפעלה מההתחלה (cold startup).
- מגדל המועמדים יכול לתמוך בקבוצה שרירותית של פריטים מועמדים, כולל פריטים שעדיין לא הייתה להם אינטראקציה עם מערכת ההמלצות. התמיכה הזו אפשרית כי ארכיטקטורות של שני מגדלים מעבדות תוכן עשיר ותכונות של מטא-נתונים לגבי כל זוג
<query, candidate>. העיבוד הזה מאפשר למערכת לתאר פריט לא מוכר במונחים של פריטים שהיא מכירה.
- מגדל המועמדים יכול לתמוך בקבוצה שרירותית של פריטים מועמדים, כולל פריטים שעדיין לא הייתה להם אינטראקציה עם מערכת ההמלצות. התמיכה הזו אפשרית כי ארכיטקטורות של שני מגדלים מעבדות תוכן עשיר ותכונות של מטא-נתונים לגבי כל זוג
- אפשר לבצע אופטימיזציה של ההסקה של השליפה על ידי חישוב מראש של כל ההטמעות של פריטים מועמדים. אפשר ליצור אינדקס להטמעות המחושבות מראש ולפרוס אותן בתשתית הגשה שעברה אופטימיזציה לאחזור עם חביון נמוך.
- הלמידה המשותפת של המגדלים מאפשרת לתאר פריטים במונחים של שאילתות, ולהיפך. אם יש לכם חצי מזוג, כמו שאילתה, ואתם צריכים לחפש את הפריט התואם השני, אתם יכולים לחשב מראש חצי מהמשוואה. החישוב המוקדם מאפשר לכם לקבל את שאר ההחלטות במהירות האפשרית.
שיקולים בתכנון
בקטע הזה מוסבר איך לפתח ארכיטקטורה של יצירת מועמדים ב- Google Cloud שעונה על צורכי האבטחה והביצועים שלכם. ההנחיות שבקטע הזה הן לא מלאות. בהתאם לדרישות הספציפיות שלכם, יכול להיות שתבחרו לשקול גורמים נוספים בעיצוב ופשרות נוספות.
אבטחה
חיפוש וקטורי ב-Vertex AI תומך בפריסות של נקודות קצה (endpoint) בענן ציבורי ובענן וירטואלי פרטי (VPC). אם אתם רוצים להשתמש ברשת VPC, תוכלו להתחיל לפעול לפי ההוראות במאמר הגדרת חיבור VPC Network Peering. אם אינדקס חיפוש וקטורי נפרס בתוך גבולות גזרה של VPC, המשתמשים צריכים לגשת למשאבים המשויכים מתוך אותה רשת VPC. לדוגמה, אם אתם מפתחים מ-Vertex AI Workbench, אתם צריכים ליצור את מופע ה-Workbench באותה רשת VPC כמו נקודת הקצה של האינדקס שנפרס. באופן דומה, כל צינור שצפוי ליצור נקודת קצה או לפרוס אינדקס לנקודת קצה צריך לפעול באותה רשת VPC.
אופטימיזציה של הביצועים
בקטע הזה מתוארים הגורמים שכדאי לקחת בחשבון כשמשתמשים בארכיטקטורת ההפניה הזו כדי לתכנן טופולוגיה ב- Google Cloud שעומדת בדרישות הביצועים של עומסי העבודה.
משימות אימון של פרופילים
כדי לבצע אופטימיזציה של צינורות להזנת נתונים ושל גרף ההכשרה הכולל, מומלץ ליצור פרופיל של ביצועי ההכשרה באמצעות Cloud Profiler. Profiler הוא הטמעה מנוהלת של TensorBoard Profiler בקוד פתוח.
העברת הארגומנט –profiler במשימת האימון מאפשרת לקריאה החוזרת של TensorFlow ליצור פרופיל של מספר קבוצות נתונים בכל תקופה. הפרופיל מתעד עקבות מה-CPU של המארח ומחומרת ה-GPU או ה-TPU של המכשיר. הנתונים האלה מספקים מידע על צריכת המשאבים של משימת האימון. כדי להימנע משגיאות שקשורות לחוסר זיכרון, מומלץ להתחיל עם משך פרופיל של 2 עד 10 שלבי אימון, ולהגדיל אותו לפי הצורך.
מידע על שימוש ב-Profiler עם Vertex AI Training ו-Vertex AI TensorBoard זמין במאמר ניתוח ביצועים של אימון מודלים. שיטות מומלצות לניפוי באגים מפורטות במאמר אופטימיזציה של ביצועי GPU. מידע על אופטימיזציה של הביצועים זמין במאמר בנושא אופטימיזציה של הביצועים של TensorFlow באמצעות כלי הפרופיל.
שימוש מלא במאיצים
כשמצרפים מאיצים לאימון, כמו מעבדי GPU של NVIDIA או מעבדי TPU של Cloud, חשוב לוודא שהם בשימוש מלא. שימוש מלא במאיצי אימון הוא שיטה מומלצת לניהול עלויות, כי מאיצים הם הרכיב הכי יקר בארכיטקטורה. שימוש מלא במאיצי אימון הוא גם שיטה מומלצת ליעילות של משימות, כי אם אין זמן השבתה, צריכת המשאבים הכוללת נמוכה יותר.
כדי להשתמש במאיץ באופן מלא, בדרך כלל מבצעים כמה איטרציות של מציאת צוואר הבקבוק, אופטימיזציה של צוואר הבקבוק וחזרה על השלבים האלה עד שהשימוש במכשיר המאיץ מקובל. מכיוון שרבים ממערכי הנתונים בתרחיש השימוש הזה גדולים מדי מכדי להיכנס לזיכרון, צווארי בקבוק נמצאים בדרך כלל בין האחסון, המכונות הווירטואליות של המארח והמאיץ.
בתרשים הבא מוצגים השלבים הקונספטואליים של צינור עיבוד נתונים של קלט לאימון ML:
בתרשים, הנתונים נקראים מהאחסון ועוברים עיבוד מראש. אחרי שהנתונים עוברים עיבוד מקדים, הם נשלחים למכשיר. כדי לבצע אופטימיזציה של הביצועים, התחילו בכך שתקבעו אם הביצועים הכוללים מוגבלים על ידי המעבד המארח או על ידי מכשיר ההאצה (GPU או TPU). המכשיר אחראי להאצת לולאת האימון, והמארח אחראי להזנת נתוני האימון למכשיר ולקבלת התוצאות מהמכשיר. בקטעים הבאים מוסבר איך לפתור צווארי בקבוק על ידי שיפור הביצועים של צינורות קלט ושל מכשירים.
שיפור הביצועים של צינורות קלט
- קריאת נתונים מאחסון: כדי לשפר את קריאת הנתונים, כדאי לנסות שמירה במטמון, prefetching, דפוסי גישה עקביים וקלט/פלט מקבילי.
- עיבוד מקדים של נתונים: כדי לשפר את העיבוד המקדים של הנתונים, צריך להגדיר עיבוד מקבילי לחילוץ נתונים ולטרנספורמציה, ולכוונן את הטרנספורמציה
interleaveבצינור להזנת נתונים. - שליחת נתונים למכשיר: כדי לקצר את משך העבודה הכולל, מעבירים נתונים מהמארח לכמה מכשירים במקביל.
שיפור הביצועים של המכשיר
- הגדלת גודל המיני-אצווה. קבוצות מינימליות הן מספר דוגמאות האימון שבהן כל מכשיר משתמש באיטרציה אחת של לולאת אימון. הגדלת גודל המיני-אצווה מגדילה את המקביליות בין הפעולות ומשפרת את השימוש החוזר בנתונים. עם זאת, המיני-batch צריך להיכנס לזיכרון עם שאר תוכנית האימונים. אם מגדילים את גודל המיני-batch יותר מדי, יכולות להופיע שגיאות שקשורות לזיכרון וסטייה במודל.
- הפיכת פונקציות בהגדרת המשתמש לווקטוריות. בדרך כלל, אפשר לבטא טרנספורמציות של נתונים כפונקציה בהגדרת המשתמש (UDF) שמתארת איך לבצע טרנספורמציה של כל רכיב במערך נתוני קלט. כדי לבצע וקטוריזציה של הפונקציה הזו, מחילים את פעולת הטרנספורמציה על קבוצת קלט בבת אחת, במקום להחיל אותה על כל רכיב בנפרד. לכל פונקציה בהגדרת המשתמש (UDF) יש תקורה שקשורה לתזמון ולביצוע. כשמבצעים טרנספורמציה של קבוצת קלט, העלות הנוספת חלה פעם אחת על כל קבוצה, ולא פעם אחת על כל רכיב במערך הנתונים.
הגדלת הקיבולת לפני הרחבת הקיבולת
כשמגדירים את משאבי המחשוב לעבודות האימון, מומלץ להגדיל את המשאבים (scale up) לפני שמרחיבים אותם (scale out). המשמעות היא שעדיף לבחור מכשיר גדול וחזק יותר לפני שמשתמשים בכמה מכשירים פחות חזקים. מומלץ להגדיל את נפח האחסון באופן הבא:
- עובד אחד + מכשיר אחד
- עובד יחיד + מכשיר חזק יותר
- עובד יחיד + כמה מכשירים
- אימון מבוזר
הערכת ההחזרה בהשוואה לזמן האחזור בחיפוש וקטורי של ANN
כדי להעריך את היתרונות של חיפוש ANN, אפשר למדוד את זמן הטעינה ואת ההחזרה של שאילתה נתונה. כדי לעזור לכם לכוונן את האינדקס, חיפוש וקטורי ב-Vertex AI מאפשר ליצור אינדקס של חיפוש מקיף. חיפושים במדדים של כוח ברוטלי יבצעו חיפוש מקיף, על חשבון חביון גבוה יותר, כדי למצוא את השכנים הקרובים האמיתיים עבור וקטור שאילתה נתון. השימוש באינדקסים של חיפוש בכוח לא מיועד לשימוש בסביבת ייצור, אבל הוא מספק בסיס טוב כשמחשבים את ההחזרה במהלך כוונון האינדקס.
כדי להעריך את ההחזרה בהשוואה לזמן האחזור, פורסים את ההטמעות המחושבות מראש של המועמדים לאינדקס אחד שמוגדר לחיפוש ANN ולאינדקס אחר שמוגדר לחיפוש בכוח ברוטלי. האינדקס של חיפוש בכוח ברוטלי יחזיר את השכנים הכי קרובים, אבל בדרך כלל ייקח לו יותר זמן מאשר לחיפוש ANN. יכול להיות שתהיו מוכנים לוותר על חלק מהדיוק של השליפה כדי לקצר את זמן האחזור של השליפה, אבל כדאי להעריך את הפשרה הזו. מאפיינים נוספים שמשפיעים על ההחזרה ועל זמן האחזור:
- פרמטרים של בניית מודלים: הרבה החלטות לגבי בניית מודלים משפיעות על מרחב ההטמעה, שבסופו של דבר הופך לאינדקס להצגת מודעות. להשוות בין המועמדים שאוחזרו לאינדקסים שנבנו ממודלים של אחזור שטחי ומודלים של אחזור עמוק.
- מאפיינים: מאפיינים הם היבט נוסף שנקבע בסופו של דבר על ידי המודל. המימדים של אינדקס ה-ANN חייבים להיות זהים למימדים של שאילתת החיפוש ושל הווקטורים של מגדל המועמדים.
- תיוג וסינון של תגים: תגים יכולים לספק יכולות מתקדמות להתאמת התוצאות לתרחישי שימוש שונים בייצור. מומלץ להבין איך התגים משפיעים על המועמדים לאחזור ועל הביצועים.
- מספר רשתות עצביות מלאכותיות: הגדלת הערך הזה מגדילה את היכולת לזכור מידע, ויכולה להגדיל את זמן האחזור באופן יחסי.
- אחוז צמתי העלה לחיפוש: האפשרות הזו היא הכי חשובה להערכת האיזון בין היזכרות לבין זמן האחזור. הגדלת הערך הזה מגדילה את ההחזרה (recall) ויכולה להגדיל את זמן האחזור באופן יחסי.
המאמרים הבאים
לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחברים:
- Jordan Totten | Customer Engineer
- ג'רמי וורץ | Customer Engineer
- Lakshmanan Sethu | מנהל חשבונות טכני
תורם תוכן אחר: Kaz Sato | אחראי קשרי מפתחים (Developers Advocate)