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