תשתית RAG ל-AI גנרטיבי באמצעות GKE ו-Cloud SQL

Last reviewed 2026-02-24 UTC

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

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

ארכיטקטורה

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

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

הארכיטקטורה כוללת מערכת משנה להצגת מודעות ומערכת משנה להטמעה.

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

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

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

כפי שמוצג בתרשים הקודם, שרת הקצה הקדמי, שרת ההסקה ושירות ההטמעה נפרסים באשכול GKE אזורי במצב Autopilot. הנתונים ל-RAG מוזנים דרך קטגוריה של Cloud Storage. הארכיטקטורה משתמשת במופע של Cloud SQL ל-PostgreSQL עם התוסף pgvector כדי לאחסן וקטורים של הטמעה ולבצע חיפושים סמנטיים.

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

מערכת משנה להטמעה

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

  1. משתמשים אנושיים או תוכנות מעלים נתונים ממקורות חיצוניים ופנימיים לקטגוריה של Cloud Storage. הנתונים שהועלו יכולים להיות בקבצים, במסדי נתונים או בנתונים שמועברים בסטרימינג.
  2. (לא מוצג בתרשים הארכיטקטורה). פעילות ההעלאה של הנתונים מפעילה אירוע שמתפרסם בשירות העברת הודעות כמו Pub/Sub. שירות העברת ההודעות שולח התראה לשירות ההטמעה.
  3. כששירות ההטמעה מקבל הודעה על אירוע של העלאת נתונים, הוא מבצע את הפעולות הבאות:
    1. אחזור נתונים מקטגוריה של Cloud Storage באמצעות מנהל התקן ה-CSI של Cloud Storage FUSE.
    2. קורא את הנתונים שהועלו ומבצע עיבוד מראש באמצעות Ray Data. העיבוד המקדים יכול לכלול חלוקה של הנתונים לחלקים והמרה שלהם לפורמט מתאים ליצירת הטמעה.
    3. מריץ משימת Ray כדי ליצור וקטורים של הטמעה מהנתונים שעברו עיבוד מראש, באמצעות מודל קוד פתוח שנפרס באותו אשכול.
    4. הפונקציה כותבת את וקטורי ההטמעה למסד הנתונים הווקטורי Cloud SQL ל-PostgreSQL.

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

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

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

  1. משתמש שולח בקשה בשפה טבעית לשרת קצה דרך ממשק צ'אט מבוסס-אינטרנט. השרת בקצה הקדמי פועל ב-GKE.
  2. בשרת הקצה הקדמי פועל תהליך של LangChain, שמבצע את הפעולות הבאות:
    1. המערכת ממירה את הבקשה בשפה טבעית לווקטורים של הטמעה באמצעות אותו מודל ואותם פרמטרים שבהם משתמש שירות ההטמעה.
    2. שליפת נתוני ביסוס רלוונטיים על ידי ביצוע חיפוש סמנטי של ההטמעות במסד הנתונים הווקטורי.
    3. יוצר הנחיה מותאמת להקשר על ידי שילוב הבקשה המקורית עם נתוני ההצמדה שאוחזרו.
    4. שולח את ההנחיה עם ההקשר לשרת ההסקה, שפועל ב-GKE.
  3. שרת ההיסקים משתמש במסגרת ההגשה Hugging Face TGI כדי להגיש מודל פתוח כמו Mistral-7B-Instruct או Gemma.

  4. מודל ה-LLM יוצר תגובה להנחיה, ושרת ההיקשים שולח את התגובה לשרת ממשק הקצה.

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

  5. שרת הקצה הקדמי מפעיל שירות RAI כדי להחיל על התגובה את מסנני הבטיחות הנדרשים. כדי לגלות, לסנן, לסווג ולבטל את הזיהוי של תוכן רגיש בתשובות, אפשר להשתמש בכלים כמו Sensitive Data Protection ו-Cloud Natural Language API.

  6. שרת הקצה הקדמי שולח את התגובה המסוננת למשתמש.

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

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

Google Cloud products

  • ‫ Google Kubernetes Engine‏ (GKE): שירות Kubernetes שמאפשר לפרוס ולהפעיל אפליקציות בקונטיינרים בהיקף גדול באמצעות התשתית של Google.
  • ‫ Cloud Storage: מאגר אובייקטים ללא הגבלה בעלות נמוכה, לשימוש עם סוגים שונים של נתונים. אפשר לגשת לנתונים מתוך Google Cloudומחוץ להם, והם משוכפלים במיקומים שונים כדי ליצור יתירות.
  • ‫ Cloud SQL: שירות מנוהל של מסד נתונים רלציוני, שעוזר לכם להקצות, להפעיל ולנהל את מסדי הנתונים של MySQL,‏ PostgreSQL ו-SQL Server ב- Google Cloud.

מוצרים בקוד פתוח

  • ‫ Hugging Face Text Generation Inference (TGI): ערכת כלים לפריסה ולהצגה של מודלים גדולים של שפה (LLM).
  • ‫ Ray: מסגרת מחשוב מאוחדת בקוד פתוח שעוזרת לכם להרחיב את השימוש ב-AI ובעומסי עבודה של Python.
  • ‫ LangChain: ‏ Framework לפיתוח ולפריסה של אפליקציות שמבוססות על מודלים גדולים של שפה (LLM).

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

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

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

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

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

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

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

חלופות עיצוב

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

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

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

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

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

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

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

אבטחה, פרטיות ותאימות

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

מוצר שיקולים בתכנון
GKE

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

כדי להבטיח בקרת גישה משופרת לאפליקציות שפועלות ב-GKE, אפשר להשתמש בשרת proxy לאימות זהויות (IAP). ‫IAP משתלב עם משאב ה-Ingress של GKE ומבטיח שרק משתמשים מאומתים עם התפקיד הנכון בניהול הזהויות והרשאות הגישה (IAM) יוכלו לגשת לאפליקציות. מידע נוסף זמין במאמר הפעלת IAP ל-GKE.

כברירת מחדל, הנתונים ב-GKE מוצפנים במצב מנוחה ו בזמן ההעברה באמצעות Google-owned and Google-managed encryption keys. כדי להוסיף שכבת אבטחה למידע אישי רגיש, אתם יכולים להצפין את הנתונים בשכבת האפליקציה באמצעות מפתח שבבעלותכם ושמנוהל על ידי Cloud KMS. מידע נוסף זמין במאמר בנושא הצפנת סודות בשכבת האפליקציה.

אם אתם משתמשים באשכול GKE רגיל, אתם יכולים להשתמש ביכולות נוספות להצפנת נתונים:

Cloud SQL

המכונה של Cloud SQL בארכיטקטורה לא צריכה להיות נגישה מהאינטרנט הציבורי. אם נדרשת גישה חיצונית למכונת Cloud SQL, אפשר להצפין את החיבורים החיצוניים באמצעות SSL/TLS או מחבר Cloud SQL Auth Proxy. מחבר Auth Proxy מספק הרשאת חיבור באמצעות IAM. המחבר משתמש בחיבור TLS 1.3 עם הצפנת AES‏ 256 ביט כדי לאמת את הזהויות של הלקוח והשרת ולהצפין את תעבורת הנתונים. לחיבורים שנוצרו באמצעות Java,‏ Python,‏ Go או Node.js, משתמשים בLanguage Connector המתאים במקום במחבר של שרת ה-proxy לאימות.

כברירת מחדל, Cloud SQL משתמש במפתחות להצפנת נתונים (DEK) ובמפתחות להצפנת מפתחות הצפנה (KEK) שבבעלות Google או שמנוהלים על ידה כדי להצפין נתונים במצב מנוחה. אם אתם צריכים להשתמש במפתחות KEK שאתם שולטים בהם ומנהלים אותם, אתם יכולים להשתמש ב מפתחות הצפנה בניהול הלקוח (CMEK).

כדי למנוע גישה לא מורשית ל-Cloud SQL Admin API, אתם יכולים ליצור גבולות גזרה לשירות באמצעות VPC Service Controls.

מידע על הגדרת Cloud SQL כדי לעמוד בדרישות למיקום אחסון הנתונים זמין במאמר סקירה כללית על מיקום אחסון הנתונים.

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 עוזר לכם לעמוד בדרישות בנוגע למיקום אחסון הנתונים. הנתונים מאוחסנים או משוכפלים באזורים שאתם מציינים.

כל המוצרים בארכיטקטורה הזו

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

יומני הביקורת של גישה לנתונים מופעלים כברירת מחדל גם לכל השירותים של Google Cloud באדריכלות הזו. אפשר להשתמש ביומנים האלה כדי לעקוב אחרי הפעולות הבאות:

  • קריאות ל-API שקוראות את ההגדרות או את המטא-נתונים של משאבים.
  • בקשות של משתמשים ליצור, לשנות או לקרוא נתוני משאבים שסופקו על ידי משתמשים.

אחרי שפורסים את האפליקציה ב- Google Cloud, אפשר לקבל המלצות לשיפור האבטחה באמצעות Active Assist. בודקים את ההמלצות ומיישמים אותן בהתאם לסביבה שלכם. מידע נוסף על ההמלצות של Active Assist

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

אמינות

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

מוצר שיקולים בתכנון
GKE

במצב הפעולה Autopilot שבו נעשה שימוש בארכיטקטורה הזו, GKE מספק את יכולות האמינות המובנות הבאות:

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

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

כדי לצמצם את זמן ההפעלה של שרת ההסקה, אפשר להשתמש בטכניקות כמו טעינת נתונים אופטימלית, סטרימינג של תמונות וצמתים עם הפעלה מהירה. מידע נוסף זמין במאמר בנושא אופטימיזציה של זמן האחזור של הפעלה במצב התחלתי (cold startup) לעומסי עבודה של הסקת מסקנות.

Cloud SQL

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

כדי לוודא שהמכונות שלכם ב-Cloud SQL מכוסות על ידי הסכם רמת השירות, מומלץ לפעול בהתאם להנחיות התפעוליות. לדוגמה, מוודאים שהמעבד והזיכרון מותאמים לעומס העבודה, ו מפעילים הגדלה אוטומטית של נפח האחסון. מידע נוסף זמין במאמר בנושא הנחיות תפעוליות.

Cloud Storage אפשר ליצור קטגוריות של Cloud Storage באחד מ סוגי המיקומים הבאים: אזורי, בשני אזורים או במספר אזורים. נתונים שמאוחסנים בקטגוריות אזוריות משוכפלים באופן סינכרוני בכמה אזורים בתוך אזור. כדי להשיג זמינות גבוהה יותר, אפשר להשתמש בקטגוריות בשני אזורים או במספר אזורים, שבהן הנתונים משוכפלים באופן אסינכרוני בין האזורים.
כל המוצרים בארכיטקטורה אחרי שפורסים את האפליקציה ב- Google Cloud, אפשר לקבל המלצות לשיפור נוסף של האמינות באמצעות Active Assist. בודקים את ההמלצות ומיישמים אותן בהתאם לסביבה שלכם. מידע נוסף על ההמלצות של Active Assist

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

הוזלת עלויות

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

מוצר שיקולים בתכנון
GKE

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

אם אתם יכולים לחזות את השימוש במעבד, בזיכרון ובנפח אחסון נדרש של אשכול GKE Autopilot, תוכלו לחסוך כסף באמצעות הנחות על התחייבות לשימוש. מידע נוסף זמין במאמר הנחות על התחייבות לשימוש ב-GKE.

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

למידע נוסף על אופטימיזציה של עלויות, אפשר לעיין במקורות המידע הבאים:
Cloud SQL

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

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

אם אתם יכולים לחזות את הדרישות של המעבד והזיכרון במכונת Cloud SQL, תוכלו לחסוך כסף באמצעות הנחות על התחייבות לשימוש. מידע נוסף מופיע במאמר הנחות על התחייבות לשימוש ב-Cloud SQL.

Cloud Storage לקטגוריה של Cloud Storage שבה אתם משתמשים כדי לטעון נתונים למערכת המשנה להטמעות, בוחרים סוג אחסון מתאים. כשבוחרים את סוג האחסון, כדאי לקחת בחשבון את הדרישות של עומסי העבודה לגבי שמירת הנתונים ותדירות הגישה. לדוגמה, כדי לשלוט בעלויות האחסון, אפשר לבחור את סוג האחסון Standard ולהשתמש ב ניהול מחזור החיים של אובייקטים. הפעולה הזו מאפשרת הורדת דרגה אוטומטית של אובייקטים לסיווג אחסון בעלות נמוכה יותר, או מחיקה של אובייקטים על סמך תנאים שאתם מגדירים.
כל המוצרים בארכיטקטורה אחרי שפורסים את האפליקציה ב- Google Cloud, אפשר לקבל המלצות לשיפור נוסף של העלויות באמצעות Active Assist. בודקים את ההמלצות ומיישמים אותן בהתאם לסביבה שלכם. מידע נוסף על ההמלצות של Active Assist

כדי להעריך את העלות של המשאבים ב- Google Cloud , אתם יכולים להשתמש בGoogle Cloud מחשבון עלויות.

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

אופטימיזציה של הביצועים

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

מוצר שיקולים בתכנון
GKE בוחרים מחלקות מחשוב מתאימות ל-Pods על סמך דרישות הביצועים של עומסי העבודה. לפודים שמריצים את שרת ההיסקים ואת שירות ההטמעה, מומלץ להשתמש ב סוג מכונת GPU כמו nvidia-l4.
Cloud SQL

כדי לשפר את הביצועים של מכונת Cloud SQL, צריך לוודא שהמעבד (CPU) והזיכרון שהוקצו למכונה מתאימים לעומס העבודה. מידע נוסף זמין במאמר בנושא אופטימיזציה של מכונות Cloud SQL עם הקצאות-חסר.

כדי לשפר את זמן התגובה לחיפוש וקטורי של השכן הקרוב המשוער (ANN), משתמשים באינדקס Inverted File with Flat Compression (IVFFlat) או באינדקס Hierarchical Navigable Small World (HNSW).

כדי לעזור לכם לנתח ולשפר את ביצועי השאילתות במסדי הנתונים, Cloud SQL מספק כלי בשם Query Insights. אפשר להשתמש בכלי הזה כדי לעקוב אחרי הביצועים ולאתר את המקור של שאילתה בעייתית. מידע נוסף מופיע במאמר שימוש בתובנות לגבי שאילתות כדי לשפר את הביצועים של השאילתות.

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

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

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

פריסה

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

הקוד לדוגמה מבצע את הפעולות הבאות:

  1. הכלי מקצה מכונה של Cloud SQL ל-PostgreSQL שתשמש כמסד נתונים וקטורי.
  2. פריסת Ray,‏ JupyterHub ו-Hugging Face TGI באשכול GKE שאתם מציינים.
  3. פריסת אפליקציית צ'אטבוט לדוגמה שמבוססת על אינטרנט באשכול GKE כדי לאמת את יכולת ה-RAG.

הוראות לשימוש בקוד לדוגמה מופיעות בקובץ README של הקוד. אם מתרחשות שגיאות כשמשתמשים בקוד לדוגמה, ואם אין issues ב-GitHub שקשורות לשגיאות, צריך ליצור issues ב-GitHub.

קוד לדוגמה לפריסת משאבים Google Cloud שמחויבים. כשמסיימים להשתמש בקוד, מסירים את כל המשאבים שכבר לא צריך.

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

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

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

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