במסמך הזה מפורטת ארכיטקטורת הפניה שבה אפשר להשתמש כדי לתכנן את התשתית של אפליקציית AI גנרטיבי עם Retrieval-Augmented Generation (יצירה משולבת-אחזור, RAG) באמצעות חיפוש וקטורי. חיפוש וקטורי הוא שירות מנוהל Google Cloud שמספק תשתית אופטימלית להצגת התאמות של דמיון וקטורי בקנה מידה גדול מאוד.
קהל היעד של המסמך הזה כולל ארכיטקטים, מפתחים ואדמינים של אפליקציות מבוססות-AI גנרטיבי. ההנחה במסמך הזה היא שיש לכם הבנה בסיסית במושגים של AI, למידת מכונה (ML) ומודלים גדולים של שפה (LLM). במסמך הזה לא מוסבר איך לתכנן ולפתח אפליקציית AI גנרטיבי.
ארכיטקטורה
התרשים הבא מציג סקירה כללית של הארכיטקטורה שמתוארת במסמך הזה:
הארכיטקטורה בתרשים הקודם כוללת שתי מערכות משנה: קליטת נתונים והצגת נתונים.
- מערכת המשנה להטמעת נתונים מטמיעה נתונים שמועלים ממקורות חיצוניים. מערכת המשנה מכינה את הנתונים ל-RAG ומתקשרת עם Agent Platform כדי ליצור הטמעות לנתונים שהועברו, וכדי לבנות ולעדכן את אינדקס הווקטורים.
- מערכת המשנה להצגת התוכן מכילה את שירותי הקצה הקדמי והקצה העורפי של אפליקציית ה-AI הגנרטיבי.
- שירות הקצה הקדמי מטפל בתהליך של שאילתה ותשובה עם משתמשי האפליקציה, ומעביר את השאילתות לשירות הקצה העורפי.
- השירות לקצה העורפי משתמש ב-Agent Platform כדי ליצור הטמעות של שאילתות, לבצע חיפוש של דמיון וקטורי ולהחיל מסנני בטיחות של אתיקה של בינה מלאכותית והוראות מערכת.
התרשים הבא מציג תצוגה מפורטת של הארכיטקטורה:
בקטעים הבאים מתואר זרימת הנתונים בכל מערכת משנה בתרשים הארכיטקטורה הקודם.
מערכת משנה להטמעת נתונים
מערכת המשנה להטמעת נתונים מטמיעה נתונים ממקורות חיצוניים ומכינה את הנתונים ל-RAG. אלה השלבים בתהליך של הכנסת נתונים והכנה שלהם:
- הנתונים מועלים ממקורות חיצוניים אל קטגוריה ב-Cloud Storage. המקורות החיצוניים יכולים להיות אפליקציות, מסדי נתונים או שירותי סטרימינג.
- כשנתונים מועלים ל-Cloud Storage, הודעה מתפרסמת בנושא Pub/Sub.
- כשנושא Pub/Sub מקבל הודעה, הוא מפעיל פונקציית Cloud Run.
- פונקציית Cloud Run מנתחת את הנתונים הגולמיים, מעצבת אותם לפי הדרישות ומחלקת אותם לחלקים.
- הפונקציה משתמשת ב- Agent Platform Embeddings API כדי ליצור הטבעות של החלקים באמצעות מודל הטבעה שאתם מציינים. Agent Platform תומך במודלים של הטמעה של טקסט ושל מולטימודל.
- לאחר מכן הפונקציה יוצרת אינדקס של וקטורים ב-Vector Search ומפריסה את האינדקס.
כשמזינים נתונים חדשים, השלבים הקודמים מבוצעים עבור הנתונים החדשים, והאינדקס מתעדכן באמצעות עדכונים בזמן אמת.
כשמערכת המשנה להצגת מודעות מעבדת בקשות של משתמשים, היא משתמשת באינדקס החיפוש הווקטורי כדי לבצע חיפוש של דמיון וקטורי. בקטע הבא מתואר תהליך הצגת המודעות.
מערכת משנה להצגת מודעות
מערכת המשנה להצגת תוצאות מטפלת בתהליך של שאילתה ותשובה בין אפליקציית ה-AI הגנרטיבי לבין המשתמשים שלה. אלה השלבים בתהליך הצגת המודעות:
- משתמש שולח שאילתה בשפה טבעית ל שירות Cloud Run שמספק ממשק קצה קדמי (כמו צ'אט בוט) לאפליקציית ה-AI הגנרטיבי.
- שירות הקצה הקדמי מעביר את שאילתת המשתמש לשירות קצה אחורי של Cloud Run.
- שירות לקצה העורפי מעבד את השאילתה באופן הבא:
- המערכת ממירה את השאילתה להטמעות באמצעות אותו מודל הטמעות ואותם פרמטרים שמשמשים את מערכת המשנה של הטמעת הנתונים ליצירת הטמעות של הנתונים שהוטמעו.
- מאחזר נתוני עיגון רלוונטיים על ידי ביצוע חיפוש דמיון וקטורי להטמעות של השאילתה באינדקס החיפוש של Vector Search.
- יוצר הנחיה משופרת על ידי שילוב השאילתה המקורית עם נתוני ההארקה.
- שולח את ההנחיה המשופרת למודל שפה גדול (LLM) שנפרס ב-Agent Platform.
- מודל ה-LLM יוצר תשובה.
- לכל פרומפט, Agent Platform מחיל את מסנני הבטיחות של אתיקה של בינה מלאכותית שהגדרתם, ואז שולח את התגובה המסוננת ואת ציוני הבטיחות של ה-AI לשירות לקצה העורפי של Cloud Run.
- האפליקציה שולחת את התשובה למשתמש דרך שירות הקצה הקדמי של Cloud Run.
אפשר לאחסן ולצפות ביומנים של פעילות השאילתות והתשובות ב-Cloud Logging, ולהגדיר מעקב מבוסס-יומנים באמצעות Cloud Monitoring. אפשר גם לטעון את התשובות שנוצרו ל-BigQuery כדי לבצע ניתוח אופליין.
הכלי לאופטימיזציה של פרומפטים ב-Agent Platform עוזר לשפר פרומפטים בהיקף נרחב, גם במהלך העיצוב הראשוני של הפרומפטים וגם לצורך כוונון שוטף של הפרומפטים. כדי לבדוק את התשובה של המודל, הכלי לאופטימיזציה של הנחיות משתמש בסדרה של הנחיות לדוגמה שמהנדסי למידת מכונה מספקים. הפלט של ההערכה כולל את התשובות של המודל להנחיות לדוגמה, ציונים למדדים שמהנדסי למידת המכונה מציינים וקבוצה של הוראות מערכת שעברו אופטימיזציה, שאפשר להשתמש בהן.
המוצרים שהשתמשו בהם
הארכיטקטורה הזו כוללת את המוצרים הבאים: Google Cloud
- Gemini Enterprise Agent Platform: פלטפורמה מקיפה שמאפשרת לכם ליצור סוכני AI ברמה ארגונית, להרחיב את השימוש בהם, לנהל אותם ולבצע אופטימיזציה שלהם.
- חיפוש וקטורי: שירות להתאמת דמיון וקטורי שמאפשר לכם לאחסן, ליצור אינדקס ולחפש נתונים שדומים או קשורים מבחינה סמנטית.
- Cloud Run: פלטפורמת מחשוב ללא שרת שמאפשרת להריץ קונטיינרים ישירות על גבי התשתית הניתנת להרחבה של Google.
- פונקציות Cloud Run: פלטפורמת מחשוב ללא שרת שמאפשרת להריץ פונקציות חד-מטרה ישירות ב- Google Cloud.
- Cloud Storage: מאגר אובייקטים ללא הגבלה בעלות נמוכה, לשימוש עם סוגים שונים של נתונים. אפשר לגשת לנתונים מתוך Google Cloudומחוץ להם, והם משוכפלים במיקומים שונים כדי ליצור יתירות.
- Pub/Sub: שירות העברת הודעות אסינכרוני וניתן להרחבה, שמפריד בין שירותים שמפיקים הודעות לבין שירותים שמבצעים עיבוד של ההודעות האלה.
- Cloud Logging: מערכת לניהול יומנים בזמן אמת עם אחסון, חיפוש, ניתוח והתראות.
- Cloud Monitoring: שירות שמאפשר לראות את הביצועים, הזמינות והתקינות של האפליקציות והתשתית שלכם.
- BigQuery: מחסן נתונים ארגוני שעוזר לכם לנהל ולנתח את הנתונים באמצעות תכונות מובנות כמו למידת מכונה, ניתוח גיאוגרפי ובינה עסקית.
תרחישים לדוגמה
RAG היא טכניקה יעילה לשיפור האיכות של התוצאות שנוצרות על ידי מודל שפה גדול (LLM). בקטע הזה מופיעות דוגמאות לתרחישי שימוש שבהם אפשר להשתמש באפליקציות של AI גנרטיבי עם יכולות RAG.
המלצות למוצרים בהתאמה אישית
אתר קניות באינטרנט יכול להשתמש בצ'אטבוט מבוסס-LLM כדי לעזור ללקוחות למצוא מוצרים או לקבל עזרה שקשורה לקניות. אפשר להוסיף לשאלות של המשתמש נתונים היסטוריים על התנהגות הקנייה שלו ועל דפוסי האינטראקציה שלו עם האתר. הנתונים עשויים לכלול ביקורות ומשוב של משתמשים שמאוחסנים במאגר נתונים לא מובנה, או מדדים שקשורים לחיפושים שמאוחסנים במחסן נתונים לצורכי ניתוח באינטרנט. אחרי שהשאלה משופרת, מודל ה-LLM יכול לעבד אותה כדי ליצור תשובות בהתאמה אישית שהמשתמש ימצא יותר מושכות ומעניינות.
מערכות סיוע קליני
רופאים בבתי חולים צריכים לנתח ולאבחן במהירות את מצב הבריאות של המטופל כדי לקבל החלטות לגבי הטיפול והתרופות המתאימים. אפשר להשתמש באפליקציית AI גנרטיבי שמבוססת על מודל LLM רפואי כמו Med-PaLM כדי לסייע לרופאים בתהליך האבחון הקליני. התשובות שהאפליקציה יוצרת יכולות להתבסס על רשומות היסטוריות של מטופלים, על ידי הוספת הקשר להנחיות של הרופאים עם נתונים ממסד הנתונים של הרשומה הרפואית האלקטרונית (EHR) של בית החולים או ממקור ידע חיצוני כמו PubMed.
מחקר משפטי יעיל
מחקר משפטי מבוסס-AI גנרטיבי מאפשר לעורכי דין לשאול במהירות שאלות לגבי כמות גדולה של חוקים ותקדימים משפטיים, כדי לזהות תקדימים משפטיים רלוונטיים או לסכם מושגים משפטיים מורכבים. אפשר לשפר את התוצאות של מחקר כזה על ידי הוספת נתונים להנחיות של עורך הדין. הנתונים האלה נשלפים ממאגר החוזים הקנייני של משרד עורכי הדין, מתקשורת משפטית קודמת ומרישומים פנימיים של תיקים. גישת העיצוב הזו מבטיחה שהתשובות שנוצרות יהיו רלוונטיות לתחום המשפטי שבו עורך הדין מתמחה.
חלופות עיצוב
בסעיף הזה מוצגות גישות עיצוב חלופיות שאפשר לשקול עבור אפליקציית AI גנרטיבי עם יכולות RAG ב- Google Cloud.
חלופות לתשתית AI
אם רוצים לנצל את היכולות של מאגר וקטורים במסד נתונים מנוהל כמו AlloyDB ל-PostgreSQL או Cloud SQL לאפליקציית RAG, אפשר לעיין במאמר תשתית RAG ל-AI גנרטיבי באמצעות Gemini Enterprise Agent Platform ו-AlloyDB ל-PostgreSQL. Google Cloud
אם אתם רוצים לבנות ולפרוס במהירות אפליקציות מבוססות-AI גנרטיבי עם יכולות RAG באמצעות כלי ומודלים בקוד פתוח כמו Ray, Hugging Face ו-LangChain, כדאי לעיין במאמר תשתית RAG ל-AI גנרטיבי באמצעות GKE ו-Cloud SQL.
אפשרויות לאירוח אפליקציות
באדריכלות שמוצגת במסמך הזה, Cloud Run הוא המארח של אפליקציית ה-AI הגנרטיבי ושל עיבוד הנתונים. Cloud Run היא פלטפורמת אפליקציות מנוהלת שמתמקדת במפתחים. אם אתם צריכים גמישות רבה יותר בהגדרות ושליטה בתשתית המחשוב, אתם יכולים לפרוס את האפליקציה באשכולות GKE או במכונות וירטואליות (VM) של Compute Engine.
ההחלטה אם להשתמש ב-Cloud Run, ב-GKE או ב-Compute Engine כמארח האפליקציה שלכם כוללת פשרות בין גמישות ההגדרה לבין מאמצי הניהול. באמצעות האפשרות של Cloud Run ללא שרת, אתם פורסים את האפליקציה בסביבה שהוגדרה מראש, ונדרש מינימום מאמץ ניהולי. כשמשתמשים במכונות וירטואליות ב-Compute Engine ובקונטיינרים ב-GKE, אתם אחראים לניהול משאבי המחשוב הבסיסיים, אבל יש לכם יותר גמישות ושליטה בהגדרות. מידע נוסף על בחירת שירות אירוח מתאים לאפליקציה זמין במאמרים הבאים:
- האם האפליקציה שלי מתאימה ל-Cloud Run?
- בחירת סביבת זמן ריצה מנוהלת של מאגר תגים
- אירוח אפליקציות ב- Google Cloud
אפשרויות אחרות
מידע על אפשרויות אחרות של תשתית, על מודלים נתמכים ועל טכניקות של ביסוס (grounding) שאפשר להשתמש בהן באפליקציות של AI גנרטיבי ב-Google Cloudזמין במאמר בחירת מודלים ותשתית לאפליקציית AI גנרטיבי.
שיקולים בתכנון
בקטע הזה מתוארים גורמים בתכנון, שיטות מומלצות והמלצות לתכנון שכדאי לקחת בחשבון כשמשתמשים בארכיטקטורת ההפניה הזו כדי לפתח טופולוגיה שעונה על הדרישות הספציפיות שלכם בנוגע לאבטחה, מהימנות, עלות וביצועים.
ההנחיות שבקטע הזה הן לא רשימה מלאה. בהתאם לדרישות הספציפיות של האפליקציה ולמוצרים ולתכונות של צד שלישי שבהם אתם משתמשים, יכול להיות שיש עוד גורמים שצריך לקחת בחשבון ולשקול את היתרונות והחסרונות שלהם. Google Cloud
אבטחה, תאימות ופרטיות
בקטע הזה מפורטים שיקולים והמלצות לתכנון טופולוגיה ב- Google Cloud שעונה על דרישות האבטחה והתאימות של עומסי העבודה.
| מוצר | שיקולים והמלצות לגבי עיצוב |
|---|---|
| Agent Platform |
אמצעי בקרה בנושא אבטחה: Agent Platform תומכת Google Cloud באמצעי בקרה בנושא אבטחה שבהם אפשר להשתמש כדי לעמוד בדרישות בנושא מיקום אחסון הנתונים, הצפנת הנתונים, אבטחת הרשת ו-Access Transparency. מידע נוסף זמין במאמרים בנושא אמצעי אבטחה לשירותי למידת מכונה ואמצעי אבטחה ל-AI גנרטיבי. גישה למודלים: אתם יכולים להגדיר מדיניות ארגונית כדי להגביל את הסוגים והגרסאות של מודלים גדולים לשוניים שאפשר להשתמש בהם ב Google Cloud פרויקט. מידע נוסף זמין במאמר שליטה בגישה למודלים ב-Model Garden. אחריות משותפת: Agent Platform מאבטחת את התשתית הבסיסית ומספקת כלים ואמצעי אבטחה שיעזרו לכם להגן על הנתונים, הקוד והמודלים שלכם. מידע נוסף זמין במאמר בנושא אחריות משותפת בפלטפורמת הסוכנים. הגנה על נתונים: אפשר להשתמש ב-Cloud Data Loss Prevention API כדי לגלות ולהסיר פרטי זיהוי של מידע אישי רגיש, כמו פרטים אישיים מזהים (PII), בהנחיות ובתשובות וגם בנתוני יומן. מידע נוסף זמין בסרטון הבא: הגנה על נתונים רגישים באפליקציות AI. |
| Cloud Run |
אבטחת תעבורת נתונים נכנסת (שירות קצה קדמי): כדי לשלוט בגישה חיצונית לאפליקציה, משביתים את כתובת ה-URL שמוגדרת כברירת מחדל מסוג run.app של שירות Cloud Run הקצה הקדמי ומגדירים מאזן עומסים חיצוני אזורי של אפליקציות (ALB). בנוסף לאיזון העומסים של התנועה הנכנסת לאפליקציה, מאזן העומסים מטפל בניהול אישורי SSL. כדי להוסיף הגנה, אפשר להשתמש במדיניות האבטחה של Google Cloud Armor כדי לספק סינון בקשות, הגנה מפני מתקפות DDoS והגבלת קצב לשירות.
אבטחת תעבורת נתונים נכנסת (שירות לקצה העורפי): שירות Cloud Run לבק-אנד של האפליקציה בארכיטקטורה הזו לא צריך גישה מהאינטרנט. כדי לוודא שרק לקוחות פנימיים יכולים לגשת לשירות, מגדירים את הפרמטר הצפנת נתונים: כברירת מחדל, Cloud Run מצפין נתונים באמצעות Google-owned and Google-managed encryption key. כדי להגן על הקונטיינרים באמצעות מפתח שאתם שולטים בו, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK). מידע נוסף מופיע במאמר בנושא שימוש במפתחות הצפנה בניהול הלקוח. אבטחת קובצי אימג' של קונטיינרים: כדי לוודא שרק קובצי אימג' מורשים של קונטיינרים נפרסים בשירותי Cloud Run, אפשר להשתמש ב-Binary Authorization. מיקום אחסון הנתונים: Cloud Run עוזר לכם לעמוד בדרישות שנוגעות למיקום אחסון הנתונים. מופעים של קונטיינרים ב-Cloud Run פועלים באזור שבוחרים. לקבלת הנחיות נוספות בנושא אבטחת קונטיינרים, אפשר לעיין בטיפים כלליים לפיתוח ב-Cloud Run. |
| Cloud Storage |
הצפנת נתונים: כברירת מחדל, הנתונים שמאוחסנים ב-Cloud Storage מוצפנים באמצעות Google-owned and Google-managed encryption keys. אם נדרש, אפשר להשתמש במפתחות CMEK או במפתחות משלכם שאתם מנהלים באמצעות שיטת ניהול חיצונית, כמו מפתחות הצפנה באספקת הלקוח (CSEK). מידע נוסף זמין במאמר בנושא אפשרויות להצפנת נתונים. בקרת גישה: ב-Cloud Storage יש שתי שיטות לשליטה בגישת המשתמשים לקטגוריות ולאובייקטים: ניהול זהויות והרשאות גישה (IAM) ורשימות של בקרת גישה (ACL). ברוב המקרים, מומלץ להשתמש ב-IAM, שמאפשר להעניק הרשאות ברמת הקטגוריה והפרויקט. מידע נוסף זמין במאמר סקירה כללית על בקרת הגישה. הגנה על נתונים: הנתונים שאתם טוענים למערכת המשנה להטמעת נתונים דרך Cloud Storage עשויים לכלול מידע אישי רגיש. כדי להגן על נתונים כאלה, אפשר להשתמש ב-Sensitive Data Protection כדי לגלות את הנתונים, לסווג אותם ולבטל את הזיהוי שלהם. מידע נוסף זמין במאמר בנושא שימוש ב-Sensitive Data Protection עם Cloud Storage. שליטה ברשת: כדי לצמצם את הסיכון לזליגת נתונים מ-Cloud Storage, אפשר ליצור מתחם היקפי של שירות באמצעות VPC Service Controls. מיקום אחסון הנתונים: Cloud Storage עוזר לכם לעמוד בדרישות בנוגע למיקום אחסון הנתונים. הנתונים מאוחסנים או משוכפלים באזורים שאתם מציינים. |
| Pub/Sub |
הצפנת נתונים: כברירת מחדל, Pub/Sub מצפין את כל ההודעות, גם במנוחה וגם במעבר, באמצעות Google-owned and Google-managed encryption keys. Pub/Sub תומך בשימוש במפתחות הצפנה בניהול הלקוח (CMEK) להצפנת הודעות בשכבת האפליקציה. מידע נוסף זמין במאמר בנושא הגדרת הצפנה של הודעות. מיקום אחסון הנתונים: אם יש לכם דרישות לגבי מיקום אחסון הנתונים, כדי לוודא שנתוני ההודעות מאוחסנים במיקומים ספציפיים, אתם יכולים להגדיר מדיניות לאחסון הודעות. |
| Cloud Logging |
ביקורת על פעילות אדמין: רישום ביומן של פעילות אדמין מופעל כברירת מחדל לכל שירותי Google Cloud שנעשה בהם שימוש בארכיטקטורת ההפניה הזו. אפשר לגשת ליומנים דרך Cloud Logging ולהשתמש בהם כדי לעקוב אחרי קריאות ל-API או פעולות אחרות שמשנות את ההגדרות או את המטא-נתונים של משאבי Google Cloud . ביקורת על גישה לנתונים: רישום ביומן של אירועי גישה לנתונים מופעל כברירת מחדל ב-BigQuery. בשביל השירותים האחרים שבהם נעשה שימוש בארכיטקטורה הזו, אפשר להפעיל יומני ביקורת לגבי גישה לנתונים. אתם יכולים להשתמש ביומנים האלה כדי לעקוב אחרי הפעולות הבאות:
אבטחת נתוני היומנים: ל-Google אין גישה לנתונים ב-Cloud Logging והיא לא משתמשת בהם. מיקום אחסון הנתונים: כדי לעמוד בדרישות בנוגע למיקום אחסון הנתונים, אתם יכולים להגדיר את Cloud Logging כך שיאחסן את נתוני היומנים באזור שציינתם. מידע נוסף מופיע במאמר הגדרת אזור ליומנים. |
| כל המוצרים בארכיטקטורה |
צמצום הסיכון לזליגת נתונים: כדי לצמצם את הסיכון לזליגת נתונים, יוצרים מתחם היקפי של VPC Service Controls מסביב לתשתית. VPC Service Controls תומך בכל השירותים שמשמשים בארכיטקטורת ההפניה הזו. אופטימיזציה אחרי הפריסה: אחרי שפורסים את האפליקציה ב- Google Cloud, אפשר להשתמש בשירות Active Assist כדי לקבל המלצות שיעזרו לכם לשפר עוד יותר את האבטחה של משאבי הענן. בודקים את ההמלצות ומיישמים אותן בהתאם לסביבה שלכם. מידע נוסף זמין במאמר בנושא איתור המלצות ב-Active Assist. בקרת גישה: פועלים לפי העיקרון של הרשאות מינימליות לכל שירות ענן. |
לקבלת הנחיות כלליות בנושא אבטחה של פריסות AI ו-ML ב-Google Cloud, אפשר לעיין במקורות המידע הבאים:
- (בלוג) הכרזה על Secure AI Framework של Google
- (Documentation) AI and ML security perspective in the Google Cloud Well-Architected Framework
- (Documentation) Agent Platform shared responsibility
- (מאמר טכני) AI גנרטיבי, פרטיות ו Google Cloud
- (סרטון) הגנה על מידע אישי רגיש באפליקציות AI
אמינות
בקטע הזה מפורטים שיקולים והמלצות לתכנון ולתפעול של תשתית אמינה לפריסה ב- Google Cloud.
| מוצר | שיקולים והמלצות לגבי עיצוב |
|---|---|
| חיפוש וקטור |
שינוי קנה מידה של שאילתות: כדי לוודא שאינדקס החיפוש של Vector Search יכול להתמודד עם עומס גדל של שאילתות, אפשר להגדיר התאמה אוטומטית לעומס לנקודת הקצה של האינדקס. כ שעומס השאילתות גדל, מספר הצמתים גדל באופן אוטומטי עד למספר המקסימלי שצוין. מידע נוסף זמין במאמר בנושא הפעלת שינוי גודל אוטומטי. |
| Cloud Run |
עמידות בפני הפסקות זמניות בתשתית: Cloud Run הוא שירות אזורי. הנתונים מאוחסנים באופן סינכרוני בכמה אזורים בתוך אזור. התעבורה מאוזנת אוטומטית בין האזורים. אם מתרחש הפסקת חשמל באזור, Cloud Run ממשיך לפעול והנתונים לא אובדים. אם מתרחש שיבוש באזור מסוים, Cloud Run מפסיק לפעול עד ש-Google פותרת את השיבוש. |
| Cloud Storage | זמינות נתונים: אתם יכולים ליצור קטגוריות של Cloud Storage באחד משלושת סוגי המיקומים: אזורי, שני אזורים או כמה אזורים. נתונים שמאוחסנים בקטגוריות אזוריות משוכפלים באופן סינכרוני בכמה אזורים בתוך אזור. כדי להשיג זמינות גבוהה יותר, אפשר להשתמש בקטגוריות בשני אזורים או במספר אזורים, שבהן הנתונים משוכפלים באופן אסינכרוני בין האזורים. |
| Pub/Sub |
הגבלת קצב: כדי למנוע שגיאות בתקופות של עליות זמניות בתנועת ההודעות, אפשר להגביל את קצב הבקשות לפרסום על ידי הגדרת בקרת זרימה בהגדרות של כלי הפרסום. טיפול בכשלים: כדי לטפל בניסיונות פרסום שנכשלו, צריך לשנות את משתני הבקשה לניסיון חוזר לפי הצורך. מידע נוסף זמין במאמר בנושא ניסיון חוזר לשליחת בקשות. |
| BigQuery | עמידות בפני הפסקות זמניות בתשתית: נתונים שאתם טוענים ל-BigQuery מאוחסנים באופן סינכרוני בשני אזורים בתוך האזור שאתם מציינים. היתירות הזו עוזרת להבטיח שהנתונים לא יאבדו כשמתרחש הפסקת חשמל באזור. מידע נוסף על תכונות האמינות ב-BigQuery זמין במאמר הסבר על אמינות. |
| כל המוצרים בארכיטקטורה | אופטימיזציה אחרי הפריסה: אחרי שפורסים את האפליקציה ב- Google Cloud, אפשר להשתמש בשירות Active Assist כדי לקבל המלצות לאופטימיזציה נוספת של מהימנות משאבי הענן. בודקים את ההמלצות ומיישמים אותן בהתאם לסביבה שלכם. מידע נוסף זמין במאמר בנושא המלצות ב-Active Assist. |
עקרונות והמלצות בנושא מהימנות שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Reliability (נקודת מבט על AI ו-ML: מהימנות) ב-Well-Architected Framework.
הוזלת עלויות
בקטע הזה מוסבר איך לבצע אופטימיזציה של העלות של הגדרת טופולוגיה של Google Cloud והפעלתה, שאתם בונים באמצעות ארכיטקטורת ההפניה הזו.
| מוצר | שיקולים והמלצות לגבי עיצוב |
|---|---|
| חיפוש וקטור |
החיוב על Vector Search תלוי בגודל האינדקס, בשאילתות לשנייה (QPS) ובמספר הצמתים ובסוג המכונה שבהם משתמשים לנקודת הקצה של האינדקס. בעומסי עבודה עם QPS גבוה, צירוף השאילתות יכול לעזור להפחית את העלות. במאמר דוגמאות לתמחור של חיפוש וקטורי מוסבר איך אפשר להעריך את העלות של חיפוש וקטורי. כדי לשפר את השימוש בצמתי החישוב שבהם נפרס אינדקס חיפוש הווקטורים, אפשר להגדיר התאמה אוטומטית לעומס (auto-scaling) לנקודת הקצה של האינדקס. כשהביקוש נמוך, מספר הצמתים מצטמצם אוטומטית למינימום שציינתם. מידע נוסף זמין במאמר הפעלת שינוי גודל אוטומטי. |
| Cloud Run |
כשיוצרים שירותים ב-Cloud Run, מציינים את כמות הזיכרון והמעבד שיוקצו למופע של הקונטיינר. כדי לשלוט בעלויות, מתחילים עם הקצאות ברירת המחדל (המינימליות) של מעבד וזיכרון. כדי לשפר את הביצועים, אפשר להגדיל את ההקצאה על ידי הגדרת מגבלת המעבד ומגבלת הזיכרון. מידע נוסף זמין במאמרי העזרה הבאים: אם אתם יכולים לחזות את הדרישות של המעבד והזיכרון בשירותי Cloud Run, תוכלו לחסוך כסף באמצעות הנחות על התחייבות לשימוש. מידע נוסף זמין במאמר הנחות על התחייבות לשימוש ב-Cloud Run. |
| Cloud Storage | לקטגוריית Cloud Storage שבה אתם משתמשים כדי לטעון נתונים למערכת המשנה של הכנסת הנתונים, בוחרים סוג אחסון מתאים. כשבוחרים את סוג האחסון, כדאי לקחת בחשבון את הדרישות של עומסי העבודה לגבי שמירת הנתונים ותדירות הגישה. לדוגמה, כדי לשלוט בעלויות האחסון, אפשר לבחור את סוג האחסון Standard ולהשתמש בניהול מחזור החיים של אובייקטים. הפעולה הזו מאפשרת הורדה אוטומטית של סיווג האובייקטים לסיווג אחסון בעלות נמוכה יותר, או מחיקה של אובייקטים על סמך תנאים שאתם מגדירים. |
| Cloud Logging |
כדי לשלוט בעלות של אחסון יומנים, אפשר:
|
| BigQuery | ב-BigQuery אפשר לחשב אומדנים של עלויות השאילתות לפני שמריצים אותן. כדי לבצע אופטימיזציה של עלויות השאילתות, צריך לבצע אופטימיזציה של אחסון וחישוב שאילתות. מידע נוסף מפורט במאמר בנושא הערכת עלויות ושליטה בהן. |
| כל המוצרים בארכיטקטורה | אחרי פריסת האפליקציה ב- Google Cloud, אפשר להשתמש בשירות Active Assist כדי לקבל המלצות לשיפור נוסף של העלות של משאבי הענן. בודקים את ההמלצות ומיישמים אותן בהתאם לסביבה שלכם. מידע נוסף זמין במאמר בנושא המלצות ב-Active Assist. |
כדי להעריך את העלות של המשאבים ב- Google Cloud , אתם יכולים להשתמש בGoogle Cloud מחשבון עלויות.
עקרונות והמלצות לאופטימיזציה של עלויות שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Cost optimization ב-Well-Architected Framework.
אופטימיזציה של הביצועים
בקטע הזה מפורטים שיקולים והמלצות לתכנון טופולוגיה ב- Google Cloud שעומדת בדרישות הביצועים של עומסי העבודה.
| מוצר | שיקולים והמלצות לגבי עיצוב |
|---|---|
| חיפוש וקטור |
כשיוצרים את האינדקס, צריך להגדיר את גודל הרסיס, את סוג מדד המרחק ואת מספר ההטמעות לכל צומת עלה על סמך דרישות הביצועים. לדוגמה, אם האפליקציה שלכם רגישה מאוד לשינויים בזמן האחזור, מומלץ להשתמש בגודל גדול של שבר. מידע נוסף זמין במאמר פרמטרים של הגדרות שמשפיעים על הביצועים. כשמגדירים את קיבולת החישוב של הצמתים שבהם נפרס אינדקס החיפוש הווקטורי, צריך לקחת בחשבון את דרישות הביצועים. בוחרים סוג מכונה מתאים ומגדירים את המספר המקסימלי של הצמתים על סמך עומס השאילתות שצפוי. מידע נוסף מופיע במאמר הגדרות פריסה שמשפיעות על הביצועים.
מגדירים את פרמטרים של השאילתה לאינדקס החיפוש הווקטורי על סמך הדרישות שלכם לגבי ביצועי השאילתה, הזמינות והעלות.
לדוגמה, הפרמטר אינדקס עדכני עוזר לשפר את הדיוק של התשובות שנוצרות. אפשר לעדכן את אינדקס החיפוש הווקטורי באמצעות עדכונים באצווה או עדכונים בזמן אמת. עדכונים בסטרימינג מאפשרים לכם להריץ שאילתות על נתונים מעודכנים כמעט בזמן אמת. מידע נוסף זמין במאמר בנושא עדכון ובנייה מחדש של אינדקס פעיל. |
| Cloud Run |
כברירת מחדל, לכל מופע קונטיינר של Cloud Run מוקצה מעבד אחד ו-512MiB של זיכרון. בהתאם לדרישות הביצועים, אפשר להגדיר את מגבלת המעבד ואת מגבלת הזיכרון. מידע נוסף זמין במשאבי העזרה הבאים: כדי להבטיח חביון אופטימלי גם אחרי תקופה שבה לא הייתה תנועה, אפשר להגדיר מספר מינימלי של מופעים. במקרים כאלה, כשמופעלת אי-פעילות במופעים, החיוב על השימוש במעבד ובזיכרון שמוקצים למופעים יהיה במחיר נמוך יותר. הנחיות נוספות לאופטימיזציה של הביצועים זמינות במאמר טיפים כלליים לפיתוח ב-Cloud Run. |
| Cloud Storage | כדי להעלות קבצים גדולים, אפשר להשתמש בשיטה שנקראת העלאות מורכבות מקבילות. בעזרת האסטרטגיה הזאת, הקובץ הגדול יפוצל לחלקים. המקטעים מועלים ל-Cloud Storage במקביל, ואז הנתונים מורכבים מחדש בענן. אם רוחב הפס של הרשת ומהירות הכתיבה לדיסק לא מהווים גורמים מגבילים, העלאות מורכבות מקבילות יכולות להיות מהירות יותר מהעלאות רגילות. עם זאת, לשיטה הזו יש כמה מגבלות והשלכות על העלויות. מידע נוסף זמין במאמר בנושא העלאות מורכבות במקביל. |
| BigQuery |
BigQuery מספק תרשים הפעלה של שאילתות שבעזרתו אפשר לנתח את הביצועים של שאילתות ולקבל תובנות לגבי בעיות כמו תחרות על משבצות ומכסת ערבוב לא מספקת. מידע נוסף זמין במאמר קבלת תובנות לגבי ביצועי שאילתות. אחרי שפותרים את הבעיות שמזוהות באמצעות תובנות לגבי ביצועי השאילתות, אפשר לבצע אופטימיזציה נוספת של השאילתות באמצעות טכניקות כמו צמצום נפח נתוני הקלט והפלט. מידע נוסף זמין במאמר בנושא שיפור חישוב השאילתות. |
| כל המוצרים בארכיטקטורה | אחרי שמבצעים פריסה של האפליקציה ב- Google Cloud, אפשר להשתמש בשירות Active Assist כדי לקבל המלצות לאופטימיזציה נוספת של הביצועים של משאבי הענן. בודקים את ההמלצות ומיישמים אותן בהתאם לסביבה שלכם. מידע נוסף זמין במאמר בנושא המלצות ב-Active Assist. |
עקרונות והמלצות לאופטימיזציה של ביצועים שספציפיים לעומסי עבודה של AI ולמידת מכונה מפורטים במאמר AI and ML perspective: Performance optimization ב-Well-Architected Framework.
פריסה
כדי לפרוס טופולוגיה שמבוססת על ארכיטקטורת העזר הזו, אפשר להוריד ולהשתמש בתצורת הדוגמה של Terraform שזמינה במאגר ב-GitHub. פועלים לפי ההוראות בקובץ ה-README במאגר. קוד הדוגמה לא מיועד לתרחישי שימוש בסביבת ייצור.
המאמרים הבאים
- בחירת מודלים ותשתית לאפליקציית ה-AI הגנרטיבי
- תשתית RAG ל-AI גנרטיבי באמצעות Agent Platform ו-AlloyDB ל-PostgreSQL
- תשתית RAG ל-AI גנרטיבי באמצעות GKE ו-Cloud SQL
- תשתית RAG ל-AI גנרטיבי באמצעות Gemini Enterprise ו-Agent Platform
- תשתית GraphRAG ל-AI גנרטיבי באמצעות Agent Platform ו-Spanner Graph
- סקירה כללית של עקרונות והמלצות בנושא ארכיטקטורה שספציפיים לעומסי עבודה של AI ו-ML ב- Google Cloudמופיעה בפרספקטיבה של AI ו-ML ב-Well-Architected Framework.
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחבר: קומאר דהנגופל | מפתח פתרונות חוצי-מוצרים
תורמי תוכן אחרים:
- אסף נמר | אדריכל ראשי של אבטחת ענן
- Deepak Michael | Networking Specialist Customer Engineer
- Divam Anand | Product Strategy and Operations Lead
- Eran Lewis | Senior Product Manager
- ג'רום סימס | מנהל בכיר, ניהול מוצר
- Katie McLaughlin | Senior Developer Relations Engineer
- מארק שלגנהוף | כותב טכני, רשתות
- מייגן או'קיף | אחראית קשרי מפתחים
- ניקולס מקנמרה | מנהל אסטרטגיית מוצרים ומסחור
- Preston Holmes | Outbound Product Manager - App Acceleration
- רוב אדוארדס | מנהל תחום טכנולוגיה, DevOps
- Victor Moreno | Product Manager, Cloud Networking
- Wietse Venema | מהנדס קשרי מפתחים