תשתית RAG ל-AI גנרטיבי באמצעות Agent Platform ו-AlloyDB ל-PostgreSQL

Last reviewed 2026-02-04 UTC

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

הערה: כדי ללמוד איך להשתמש בכלים בקוד פתוח כמו Ray,‏ Hugging Face ו-LangChain כדי ליצור ולפרוס במהירות אפליקציית AI גנרטיבי עם יכולות RAG ב-Google Kubernetes Engine ‏ (GKE), אפשר לעיין במאמר תשתית RAG ל-AI גנרטיבי באמצעות GKE ו-Cloud SQL.

ארכיטקטורה

בתרשים הבא מוצגת סקירה כללית של ארכיטקטורה של אפליקציית AI גנרטיבי עם יכולות RAG ב- Google Cloud:

הארכיטקטורה כוללת את הרכיבים המקושרים הבאים:

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

בתרשים הבא מוצגת תצוגה מפורטת של הארכיטקטורה:

בקטעים הבאים מופיעים תיאורים מפורטים של הרכיבים ושל זרימת הנתונים בכל מערכת משנה בארכיטקטורה.

מערכת משנה להטמעת נתונים

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

אלה השלבים בתהליך ההטמעה של הנתונים:

1. הנתונים מועלים לקטגוריה של Cloud Storage. מקורות הנתונים יכולים להיות אפליקציות, מסדי נתונים או שירותי סטרימינג.
2. כשנתונים מועלים ל-Cloud Storage, הודעה מתפרסמת בנושא Pub/Sub.
3. ‫Pub/Sub מפעיל פונקציית Cloud Run כדי לעבד את הנתונים שהועלו.
4. הפונקציה מופעלת באמצעות נתוני הגדרה שמאוחסנים במסד נתונים של AlloyDB ל-PostgreSQL.
5. הפונקציה מנתחת את הנתונים הגולמיים, מעצבת אותם לפי הצורך ואז מחלקת אותם למקטעים.

6. הפונקציה משתמשת במודל הטמעה מתאים ב-Gemini Enterprise Agent Platform כדי ליצור הטמעות וקטוריות של הנתונים שהוזנו.

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

7. הפונקציה מאחסנת את ההטמעות במסד נתונים של AlloyDB ל-PostgreSQL שמופעל בו התוסף pgvector. כפי שמתואר בקטע הבא, כשמערכת המשנה להצגת תוצאות מעבדת בקשות של משתמשים, היא משתמשת בהטמעות במסד הנתונים הווקטורי כדי לאחזר נתונים רלוונטיים שספציפיים לדומיין.

מערכת משנה להצגת מודעות

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

אלה השלבים בתהליך הבקשה והתגובה במערכת המשנה להצגת מודעות:

1. משתמשים שולחים בקשות לאפליקציית ה-AI הגנרטיבי דרך ממשק משתמש (לדוגמה, צ'אטבוט או אפליקציה לנייד).

2. אפליקציית ה-AI הגנרטיבי ממירה את הבקשה בשפה הטבעית להטבעות.

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

3. האפליקציה משלימה את החלק של אחזור המידע בגישת ה-RAG:

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

4. האפליקציה שולחת את הפרומפט עם ההקשר לסטאק של הסקת מסקנות של LLM שפועל ב-Agent Platform.

5. מערך ההסקה של LLM משתמש ב-LLM גנרטיבי מבוסס-AI, שיכול להיות LLM בסיסי או LLM בהתאמה אישית, ויוצר תשובה שמוגבלת להקשר שסופק.

   1. האפליקציה יכולה לאחסן יומנים של פעילות בקשות ותגובות ב-Cloud Logging. אפשר לצפות ביומנים ולהשתמש בהם לצורך מעקב באמצעות Cloud Monitoring. ‫Google לא ניגשת לנתוני היומן ולא משתמשת בהם.
   2. האפליקציה טוענת את התשובות ל-BigQuery לצורך ניתוח אופליין.

6. האפליקציה מסננת את התשובות באמצעות מסנני אתיקה של בינה מלאכותית.

7. האפליקציה שולחת את התשובות שסוננו למשתמשים דרך חזית האתר.

מערכת משנה להערכת איכות

בתרשים הבא מוצגים פרטים על מערכת המשנה להערכת האיכות בארכיטקטורה:

כשמערכת המשנה להערכת איכות מקבלת בקשה, היא מבצעת את הפעולות הבאות:

1. טריגר Pub/Sub מפעיל פונקציית Cloud Run.
2. הפונקציה מופעלת באמצעות נתוני הגדרה שמאוחסנים במסד נתונים של AlloyDB ל-PostgreSQL.
3. הפונקציה שולפת הנחיות להערכה ממסד נתונים של AlloyDB ל-PostgreSQL. ההנחיות הועלו קודם למסד הנתונים על ידי מערכת המשנה להזנת נתונים.

4. הפונקציה משתמשת בהנחיות ההערכה כדי להעריך את איכות התשובות שמערכת המשנה להצגת מודעות יוצרת.

   הפלט של ההערכה הזו כולל ציוני הערכה למדדים כמו דיוק עובדתי ורלוונטיות.

5. הפונקציה טוענת את ציוני ההערכה, את ההנחיות ואת התשובות שהוערכו ל-BigQuery לצורך ניתוח עתידי.

המוצרים שהשתמשו בהם

בהמשך מופיע סיכום של כל המוצרים של Google Cloud שמשמשים בארכיטקטורה הקודמת:

• Gemini Enterprise Agent Platform: פלטפורמה מקיפה שמאפשרת לכם ליצור, לנהל, לבצע אופטימיזציה ולהתאים לעומס (scale) סוכני AI ברמה שמתאימה לארגונים.
• פונקציות Cloud Run: פלטפורמת מחשוב ללא שרת שמאפשרת להריץ פונקציות חד-מטרה ישירות ב- Google Cloud.
• ‫ BigQuery: מחסן נתונים ארגוני שעוזר לכם לנהל ולנתח את הנתונים באמצעות תכונות מובנות כמו למידת מכונה, ניתוח גיאוגרפי ובינה עסקית.
• ‫ Cloud Storage: מאגר אובייקטים ללא הגבלה בעלות נמוכה, לשימוש עם סוגים שונים של נתונים. אפשר לגשת לנתונים מתוך ומחוץ Google Cloud, והם משוכפלים במיקומים שונים כדי ליצור יתירות.
• ‫ AlloyDB ל-PostgreSQL: שירות מנוהל של מסד נתונים שתואם ל-PostgreSQL, ומיועד לעומסי העבודה הכבדים ביותר, כולל עיבוד היברידי של טרנזקציות וניתוחים.
• ‫ Pub/Sub: שירות העברת הודעות אסינכרוני וניתן להרחבה, שמפריד בין שירותים שמפיקים הודעות לבין שירותים שמבצעים עיבוד של ההודעות האלה.
• ‫ Cloud Logging: מערכת לניהול יומנים בזמן אמת עם אחסון, חיפוש, ניתוח והתראות.
• ‫ Cloud Monitoring: שירות שמאפשר לראות את הביצועים, הזמינות והתקינות של האפליקציות והתשתית שלכם.

תרחישים לדוגמה

RAG היא טכניקה יעילה לשיפור האיכות של התוצאות שנוצרות על ידי מודל שפה גדול (LLM). בקטע הזה מופיעות דוגמאות לתרחישי שימוש שבהם אפשר להשתמש באפליקציות של AI גנרטיבי עם יכולות RAG.

המלצות למוצרים בהתאמה אישית

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

מערכות סיוע קליני

רופאים בבתי חולים צריכים לנתח ולאבחן במהירות את מצב הבריאות של המטופל כדי לקבל החלטות לגבי הטיפול והתרופות המתאימים. אפשר להשתמש באפליקציית AI גנרטיבי שמבוססת על מודל LLM רפואי כמו Med-PaLM כדי לסייע לרופאים בתהליך האבחון הקליני. התשובות שהאפליקציה יוצרת יכולות להתבסס על רשומות היסטוריות של מטופלים, על ידי הוספת הקשר להנחיות של הרופאים עם נתונים ממסד הנתונים של הרשומה הרפואית האלקטרונית (EHR) של בית החולים או ממקור ידע חיצוני כמו PubMed.

מחקר משפטי יעיל

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

חלופות עיצוב

בסעיף הזה מוצגות גישות עיצוב חלופיות שאפשר לשקול עבור אפליקציית AI גנרטיבי עם יכולות RAG ב- Google Cloud.

חיפוש וקטורי מנוהל

אם אתם צריכים ארכיטקטורה שמשתמשת במוצר מנוהל לחיפוש וקטורי, אתם יכולים להשתמש ב-Agent Platform וב-Vector Search, שמספקים תשתית אופטימלית להצגת תוצאות של חיפוש וקטורי בקנה מידה גדול מאוד. מידע נוסף זמין במאמר בנושא תשתית RAG ל-AI גנרטיבי באמצעות Agent Platform וחיפוש וקטורי.

כלים ומודלים של קוד פתוח

אם אתם רוצים לפתח ולפרוס במהירות אפליקציות מבוססות-AI גנרטיבי עם יכולות RAG באמצעות כלים ומודלים בקוד פתוח כמו Ray,‏ Hugging Face ו-LangChain, כדאי לעיין במאמר תשתית RAG ל-AI גנרטיבי באמצעות GKE ו-Cloud SQL.

ארכיטקטורות אחרות של RAG

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

שיקולים בתכנון

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

אבטחה ותאימות

בקטע הזה מפורטים גורמים שכדאי לקחת בחשבון כשמתכננים ויוצרים ב- Google Cloud אפליקציית AI גנרטיבי עם יכולות RAG שעומדת בדרישות האבטחה והתאימות שלכם.

מוצר	שיקולים בתכנון
Agent Platform	פלטפורמת Agent תומכת Google Cloud באמצעי אבטחה שבהם אפשר להשתמש כדי לעמוד בדרישות שלכם בנוגע למיקום הנתונים, להצפנת הנתונים, לאבטחת הרשת ולשקיפות הגישה. מידע נוסף זמין במאמרים בנושא אמצעי אבטחה לשירותי למידת מכונה ו אמצעי אבטחה ל-AI גנרטיבי.
פונקציות Cloud Run	כדי להגן על הנתונים באמצעות מפתח שאתם שולטים בו, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK). מידע נוסף מופיע במאמר בנושא שימוש במפתחות הצפנה בניהול הלקוח.
‫AlloyDB ל-PostgreSQL	כברירת מחדל, הנתונים שמאוחסנים ב-AlloyDB ל-PostgreSQL מוצפנים באמצעות Google-owned and Google-managed encryption keys. אם אתם צריכים להשתמש במפתחות הצפנה שאתם שולטים בהם ומנהלים אותם, אתם יכולים להשתמש במפתחות CMEK. מידע נוסף זמין במאמר מידע על CMEK. כדי לצמצם את הסיכון לזליגת נתונים ממסדי נתונים של AlloyDB ל-PostgreSQL, אפשר ליצור גבולות גזרה לשירות באמצעות VPC Service Controls. כברירת מחדל, מכונת AlloyDB ל-PostgreSQL מקבלת רק חיבורים שמשתמשים ב-SSL. כדי לאבטח עוד יותר את החיבורים למסדי הנתונים של AlloyDB ל-PostgreSQL, אפשר להשתמש במחבר AlloyDB ל-PostgreSQL Auth Proxy. מחבר שרת ה-proxy ל-Auth מספק הרשאת חיבור שמבוססת על ניהול זהויות והרשאות גישה (IAM), ומשתמש בחיבור TLS 1.3 עם הצפנת AES של 256 ביט כדי לאמת את הזהויות של הלקוח והשרת ולהצפין את תעבורת הנתונים. מידע נוסף זמין במאמר בנושא שרת proxy לאימות ב-AlloyDB ל-PostgreSQL. לחיבורים שנוצרו באמצעות Java,‏ Python או Go, צריך להשתמש במחבר השפה המתאים במקום במחבר Auth Proxy. ‫AlloyDB ל-PostgreSQL עוזר לעמוד בדרישות של מיקום אחסון הנתונים. הנתונים מאוחסנים או משוכפלים באזורים שאתם מציינים.
BigQuery	ב-BigQuery יש הרבה תכונות שבהן אפשר להשתמש כדי לשלוט בגישה לנתונים, להגן על מידע אישי רגיש ולהבטיח את הדיוק והעקביות של הנתונים. מידע נוסף זמין במאמר מבוא למשילות מידע ב-BigQuery. בעזרת BigQuery אפשר לעמוד בדרישות בנוגע למיקום אחסון הנתונים. הנתונים מאוחסנים באזור שאתם מציינים.
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 עוזר לכם לעמוד בדרישות בנוגע למיקום אחסון הנתונים. הנתונים מאוחסנים או משוכפלים באזורים שאתם מציינים.
Pub/Sub	כברירת מחדל, Pub/Sub מצפין את כל ההודעות, גם כשהן באחסון וגם כשהן מועברות, באמצעות Google-owned and Google-managed encryption keys. ‫Pub/Sub תומך בשימוש במפתחות CMEK להצפנת הודעות בשכבת האפליקציה. מידע נוסף זמין במאמר בנושא הגדרת הצפנה של הודעות. אם יש לכם דרישות לגבי מיקום אחסון הנתונים, כדי לוודא שנתוני ההודעות מאוחסנים במיקומים ספציפיים, אתם יכולים להגדיר מדיניות לאחסון הודעות.
Cloud Logging	יומני הביקורת Admin Activity מופעלים כברירת מחדל עבור כל השירותים Google Cloud שנעשה בהם שימוש בארכיטקטורת ההפניה הזו. ביומנים האלה מתועדות קריאות ל-API או פעולות אחרות שמשנות את ההגדרות או את המטא-נתונים של משאבי Google Cloud . יומני הביקורת Data Access מופעלים כברירת מחדל ב-BigQuery. בשביל השירותים האחרים שבהם נעשה שימוש בארכיטקטורה הזו, אפשר להפעיל יומני ביקורת לגבי גישה לנתונים. היומנים מאפשרים לעקוב אחרי קריאות ל-API שקוראות את ההגדרות או את המטא-נתונים של משאבים, או אחרי בקשות משתמשים ליצור, לשנות או לקרוא נתוני משאבים שסופקו על ידי משתמשים. כדי לעמוד בדרישות של מיקום אחסון הנתונים, אתם יכולים להגדיר את Cloud Logging כך שיאחסן את נתוני היומן באזור שאתם מציינים. מידע נוסף מופיע במאמר בנושא הגדרת אזור ליומנים.

עקרונות והמלצות אבטחה שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Security ב-Well-Architected Framework.

אמינות

בקטע הזה מוסבר על גורמים שצריך לקחת בחשבון כשבונים ומפעילים תשתית אמינה לאפליקציית AI גנרטיבי עם יכולות RAG ב-Google Cloud.

מוצר	שיקולים בתכנון
‫AlloyDB ל-PostgreSQL	כברירת מחדל, אשכולות של AlloyDB ל-PostgreSQL מספקים זמינות גבוהה (HA) עם מעבר אוטומטי לגיבוי (failover). למופע הראשי יש צמתים מיותרים שנמצאים בשני תחומים שונים באותו אזור. היתירות הזו מבטיחה שהאשכולות יהיו חזקים ויעמדו בפני הפסקות חשמל באזור. כדי לתכנן התאוששות מהפסקות חשמל באזור מסוים, אפשר להשתמש ב שכפול באזורים שונים.
BigQuery	הנתונים שאתם טוענים ל-BigQuery מאוחסנים באופן סינכרוני בשני אזורים בתוך האזור שציינתם. היתירות הזו עוזרת לוודא שהנתונים לא יאבדו במקרה של הפסקת חשמל באזור. מידע נוסף על תכונות האמינות ב-BigQuery זמין במאמר הסבר על אמינות.
Cloud Storage	אפשר ליצור קטגוריות של Cloud Storage באחד משלושת סוגי המיקומים: אזורי, בשני אזורים או במספר אזורים. נתונים שמאוחסנים בדליים אזוריים משוכפלים באופן סינכרוני בכמה אזורים בתוך אזור. כדי להשיג זמינות גבוהה יותר, אפשר להשתמש בקטגוריות בשני אזורים או במספר אזורים, שבהן הנתונים משוכפלים באופן אסינכרוני בין האזורים.
Pub/Sub	כדי לנהל עליות זמניות בתעבורת נתונים של הודעות, אפשר להגדיר בקרה על זרימת נתונים בהגדרות האפליקציה לשליחת הודעות. כדי לטפל בפרסומים שנכשלו, משנים את משתני הבקשה לניסיון חוזר לפי הצורך. מידע נוסף זמין במאמר בנושא ניסיון חוזר לשליחת בקשות.

הערה: מידע נוסף על שיקולים ספציפיים לאזור זמין במאמר מיקום גיאוגרפי ואזורים.

עקרונות והמלצות בנושא מהימנות שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Reliability (נקודת מבט על AI ו-ML: מהימנות) ב-Well-Architected Framework.

הוזלת עלויות

בקטע הזה מוסבר איך לבצע אופטימיזציה של העלות של הגדרת אפליקציית AI גנרטיבי עם יכולות RAG והפעלתה ב- Google Cloud.

מוצר	שיקולים בתכנון
‫AlloyDB ל-PostgreSQL	כברירת מחדל, מכונה ראשית של אשכול AlloyDB ל-PostgreSQL זמינה מאוד (HA). למופע יש צומת פעיל וצומת במצב המתנה. אם הצומת הפעיל נכשל, AlloyDB ל-PostgreSQL עובר אוטומטית לצומת ההמתנה. אם אתם לא צריכים זמינות גבוהה למסדי הנתונים, אתם יכולים להקטין את העלויות על ידי הגדרת המכונה הראשית של האשכול כמכונה בסיסית. מכונה בסיסית לא עמידה בפני הפסקות חשמל באזור, וזמן ההשבתה שלה ארוך יותר במהלך עבודות תחזוקה. מידע נוסף מפורט במאמר איך להפחית עלויות באמצעות מכונות בסיסיות. אם אתם יכולים לחזות את דרישות המעבד והזיכרון של מכונת AlloyDB ל-PostgreSQL, תוכלו לחסוך כסף באמצעות הנחות על התחייבות לשימוש. מידע נוסף מופיע במאמר הנחות על התחייבות לשימוש ב-AlloyDB ל-PostgreSQL.
BigQuery	ב-BigQuery אפשר לחשב אומדנים של עלויות השאילתות לפני שמריצים אותן. כדי לבצע אופטימיזציה של עלויות השאילתות, צריך לבצע אופטימיזציה של האחסון ושל החישובים של השאילתות. מידע נוסף זמין במאמר חישוב העלויות ושליטה בהן.
Cloud Storage	לקטגוריית Cloud Storage שבה משתמשים כדי לטעון נתונים למערכת המשנה של הכנסת הנתונים, בוחרים סוג אחסון מתאים על סמך הדרישות של עומסי העבודה בנוגע לשמירת הנתונים ותדירות הגישה. לדוגמה, אפשר לבחור את סוג האחסון Standard ולהשתמש ב ניהול מחזור החיים של אובייקטים כדי לשלוט בעלויות האחסון. לשם כך, אפשר להגדיר שהמערכת תשנמך אוטומטית את סוג האחסון של אובייקטים לסוג אחסון זול יותר, או שתמחק אובייקטים על סמך תנאים שתגדירו.
Cloud Logging	כדי לשלוט בעלות של אחסון יומנים, אפשר: כדי לצמצם את נפח היומנים, אפשר להחריג או לסנן רשומות לא נחוצות ביומן. מידע נוסף מופיע במאמר בנושא מסנני החרגה. קיצור התקופה לשמירת רשומות ביומן. מידע נוסף זמין במאמר בנושא הגדרת שמירה מותאמת אישית.

עקרונות והמלצות לאופטימיזציה של עלויות שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Cost optimization ב-Well-Architected Framework.

ביצועים

בקטע הזה מוסבר על הגורמים שכדאי לקחת בחשבון כשמעצבים ויוצרים אפליקציית AI גנרטיבי עם יכולות RAG ב- Google Cloud שעומדת בדרישות הביצועים שלכם.

מוצר	שיקולים בתכנון
‫AlloyDB ל-PostgreSQL	כדי לעזור לכם לנתח ולשפר את ביצועי השאילתות של מסדי הנתונים, AlloyDB ל-PostgreSQL מספק כלי בשם Query Insights. אפשר להשתמש בכלי הזה כדי לעקוב אחרי הביצועים ולאתר את המקור של שאילתה בעייתית. מידע נוסף מופיע במאמר סקירה כללית על תובנות לגבי שאילתות. כדי לקבל סקירה כללית של הסטטוס והביצועים של מסדי הנתונים, ולראות מדדים מפורטים כמו מספר החיבורים המקסימלי וזמן ההשהיה המקסימלי של השכפול, אפשר להשתמש בלוח הבקרה System Insights. מידע נוסף זמין במאמר בנושא מעקב אחרי מכונה באמצעות לוח הבקרה System Insights של AlloyDB ל-PostgreSQL. כדי להפחית את העומס על המכונה הראשית של AlloyDB ל-PostgreSQL, ולהרחיב את הקיבולת כדי לטפל בבקשות קריאה, אפשר להוסיף מכונות של מאגר קריאה לאשכול. למידע נוסף אפשר לקרוא את המאמר צמתים ומכונות של AlloyDB ל-PostgreSQL.
BigQuery	‫BigQuery מספק תרשים הפעלה של שאילתות שבעזרתו אפשר לנתח את הביצועים של שאילתות ולקבל תובנות לגבי בעיות כמו תחרות על משבצות ומכסת ערבול לא מספקת. מידע נוסף זמין במאמר קבלת תובנות לגבי ביצועי שאילתות. אחרי שתטפלו בבעיות שזיהיתם באמצעות תובנות לגבי ביצועי השאילתות, תוכלו לבצע אופטימיזציה נוספת של השאילתות באמצעות טכניקות כמו צמצום נפח נתוני הקלט והפלט. מידע נוסף זמין במאמר בנושא שיפור חישוב השאילתות.
Cloud Storage	כדי להעלות קבצים גדולים, אפשר להשתמש בשיטה שנקראת העלאות מורכבות מקבילות. באסטרטגיה הזו, הקובץ הגדול מפולח לחלקים. המקטעים מועלים ל-Cloud Storage במקביל, ואז הנתונים מורכבים מחדש בענן. העלאות מורכבות מקבילות יכולות להיות מהירות יותר מהעלאות רגילות, בתנאי שרוחב הפס של הרשת ומהירות הכתיבה לדיסק לא מהווים גורמים מגבילים. עם זאת, לשיטה הזו יש כמה מגבלות והשלכות על העלויות. מידע נוסף זמין במאמר בנושא העלאות מורכבות במקביל.

עקרונות והמלצות לאופטימיזציה של ביצועים שספציפיים לעומסי עבודה של AI ולמידת מכונה מפורטים במאמר AI and ML perspective: Performance optimization ב-Well-Architected Framework.

פריסה

כדי להתחיל ולנסות לבנות תשתית ב- Google Cloudלאפליקציות גנרטיביות של AI עם יכולות RAG, אפשר להשתמש בקוד לדוגמה שזמין ב-GitHub. הקוד הזה פורס אפליקציית צ'אט מבוססת-Python ב-Cloud Run ומשתמש במסד נתונים מנוהל של Cloud SQL לחיפוש וקטורי.

הערה: קוד לדוגמה משתמש ב-Cloud SQL כמסד נתונים וקטורי, ואילו ארכיטקטורת ההפניה הזו משתמשת ב-AlloyDB ל-PostgreSQL. גם Cloud SQL וגם AlloyDB ל-PostgreSQL תומכים בתוסף pgvector,

שמאפשר להריץ חיפוש וקטורי במסד נתונים של PostgreSQL.

המאמרים הבאים

• בחירת מודלים ותשתית לאפליקציית ה-AI הגנרטיבי
• פיתוח אפליקציית צ'אט מבוססת-LLM ו-RAG באמצעות AlloyDB ל-PostgreSQL ו-LangChain
• תשתית RAG ל-AI גנרטיבי באמצעות Agent Platform ו-חיפוש וקטורי
• תשתית 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.

שותפים ביצירת התוכן

מחבר: קומאר דהנגופל | מפתח פתרונות חוצי-מוצרים

תורמי תוכן אחרים:

• אנדרו ברוק | מנהל הנדסה
• Anna Berenberg | Engineering Fellow
• אסף נמר | אדריכל ראשי של אבטחת ענן
• Balachandar Krishnamoorthy | Principal Software Engineer
• Daniel Lees | Cloud Security Architect
• Derek Downey | Developer Relations Engineer
• Eran Lewis | Senior Product Manager
• Geoffrey Anderson | Product Manager
• Gleb Otochkin | Cloud Advocate, Databases
• Hamsa Buvaraghan | AI Product Manager
• אירינה סיגלר | מנהלת מוצר
• Jack Wotherspoon | אחראי קשרי מפתחים
• ג'ייסון דבנפורט | אחראי קשרי מפתחים
• Jordan Totten | Customer Engineer
• ג'וליה ויזינגר | מנהלת מוצר
• Kara Greenfield | Customer Engineer
• קורטיס ואן גנט | מהנדס תוכנה בכיר
• Per Jacobsson | Software Engineer
• Pranav Nambiar | Director
• ריצ'ארד הנדריקס | צוות מרכז הארכיטקטורה
• Safiuddin Khaja | Cloud Engineer
• סנדי גאי | מנהלת קבוצת מוצרים
• ולדימיר ווסקוביץ' | מנהל מוצר
• סטארן ג'יאניני | מנהל קבוצת מוצרים
• Wietse Venema | מהנדס קשרי מפתחים