מצבי פריסה ב-RAG Engine ב-Gemini Enterprise Agent Platform

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

מנוע RAG מציע שני מצבי פריסה: Serverless ו-Spanner. אתם יכולים לעבור בין שני המצבים בצורה חלקה. הנתונים בכל מצב נשארים מבודדים מהנתונים במצב השני.

מצבי פריסה זמינים

בקטע הזה נדון בשני מצבי הפריסה שזמינים ל-RAG Engine:

מצב ללא שרת

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

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

במצב ללא שרת, מסד הנתונים המנוהל של RAG משמש לניהול פעולות עסקיות של RAG ולאחסון משאבי RAG. המקורות האלה כוללים (בין היתר) את RagCorpus, ‏ RagFiles, ‏ RagMetadata, ‏ DataSchema וכו'. אבל אי אפשר יותר להשתמש בהם להטמעה של אינדוקס ולחיפוש וקטורי.

המשתמשים תמיד יצטרכו לבחור בנפרד מסד נתונים וקטורי אחר. במצב Serverless, כברירת מחדל, RAG Engine מקצה אוסף של Vector Search 2.0 בפרויקט שלכם להטמעת אינדקס וחיפוש וקטורי. בהשוואה למצב Spanner, הקצאת Vector Search 2.0 בפרויקט מאפשרת לכם לראות את כל נתוני השימוש במסד הנתונים הווקטורי ואת העלויות שלו, ולשלוט בהם. השוואה מפורטת זמינה בקטע מצב Spanner לעומת מצב Serverless.

מצב Spanner

מצב Spanner מקצה תשתית ייעודית של Spanner במיוחד כדי לשמש כבסיס לפריסת מנוע RAG. הוא מיועד לעומסי עבודה שדורשים תכונות תאימות ספציפיות (כמו CMEK) או מופעים ייעודיים ומבודדים של מסדי נתונים. מצב Spanner מוגדר כברירת מחדל אם לא בוחרים במפורש מצב אחר.

כשמשתמשים במצב Spanner, צריך לנהל את התשתית על ידי בחירת רמת ביצועים:

  • רמה בסיסית (ברירת מחדל): רמה קבועה וחסכונית עם נפח חישוב נמוך, שמתאימה לניסויים, לנתונים קטנים או לעומסי עבודה (workloads) שלא רגישים לזמן אחזור.
  • רמת Scale: מציעה ביצועים ברמת ייצור עם פונקציונליות של התאמה אוטומטית לעומס. האפשרות הזו מתאימה ללקוחות עם כמויות גדולות של נתונים או עם עומסי עבודה שרגישים לביצועים.

בידוד נתונים ומעבר בין מצבים

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

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

/gemini-enterprise-agent-platform/images/rag-engine-deployment-modes.png

כפי שמודגם בתרשים:

  • ‫Unified API: אתם משתמשים באותם ממשקי Agent Platform RAG API כדי ליצור משאבים ולנהל אותם. ממשק ה-API מנתב אוטומטית את הבקשות שלכם אל ה-Backend שמשויך למצב הפריסה הפעיל שלכם.
  • חשיפה: אם מצב Serverless פעיל, האפליקציה יכולה לראות רק את RagCorpus A ו-B ולקיים איתם אינטראקציה. RagCorpus C, שנוצר במצב Spanner, נשאר מאוחסן בצורה בטוחה אבל מוסתר לחלוטין ואין לאפליקציה גישה אליו עד שתחזירו את המצב של הפרויקט למצב Spanner.
  • ללא אובדן נתונים: המעבר בין המצבים לא מוחק את הנתונים. הפעולה הזו רק משנה את ה-backend שה-API בודק.

ניהול מצב הפריסה

מצב הפריסה הוא הגדרה ברמת הפרויקט. אפשר לראות או לשנות את המצב הנוכחי באמצעות ממשקי ה-API‏ GetRagEngineConfig ו-UpdateRagEngineConfig. במאמר מעבר בין מצבים מוסבר איך לעבור בין מצבי הפריסה ולבחור רמה מתאימה למצב Spanner.

מחיקת הנתונים והפסקת החיוב

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

  • כדי למחוק נתונים של Serverless: מוודאים שהמצב הפעיל מוגדר ל-Serverless. מפעילים את ListRagCorpora API כדי לראות את המשאבים, ואז מוחקים ידנית כל קורפוס באמצעות DeleteRagCorpus API.
  • כדי למחוק נתונים ב-Spanner (ביטול הקצאת משאבים): מוודאים שהמצב הפעיל מוגדר ל-Spanner. מעדכנים את RagEngineConfig ומגדירים את רמת השירות של Spanner ל-Unprovisioned. הפעולה הזו תמחק באופן מיידי את מופע Spanner הייעודי ואת כל נתוני ה-RAG ששמורים בו, ותפסיק את החיוב על מצב Spanner. הערה: אי אפשר לשחזר נתונים שנמחקו באמצעות מהדורת Unprovisioned.

מצב Spanner לעומת מצב Serverless

תכונה מצב ללא שרת מצב Spanner
עלות
  • השימוש ב-Resource Management וב-Orchestration הוא ללא תשלום.
  • חיוב על Vector DB מתבצע ישירות לפי בחירת המשתמשים.
  • המחירים משתנים בהתאם לדרגת המינוי. כולל ניהול ותזמור של משאבים.
  • העלות של מסד נתונים וקטורי מכוסה לכל הקורפוסים עם RagManagedDb כבחירה של מסד נתונים וקטורי.
  • לגבי שאר מאגרי המידע, החיוב על מאגר וקטורים מתבצע ישירות בהתאם לבחירת המשתמשים במאגר.
התאמה להיקף התאמה אוטומטית לעומס שמנוהלת באופן מלא צריך להגדיר את הרמה הרצויה, אבל יש אפשרות לבחור ברמה עם שינוי גודל אוטומטי.
בידוד האחסון לא מבודד מספק בידוד של האחסון והביצועים.
CMEK אין כרגע הצפנה באמצעות מפתח משל לקוח (CMEK) מציע תמיכה ב-CMEK
VPC Security Controls נתמך נתמך
מסדי נתונים וקטוריים נתמכים
  • Managed Vector Search 2.0 (ברירת מחדל)
  • Pinecone
  • Weaviate
  • RagManagedDb (ברירת מחדל)
  • ניהול של Vector Search 2.0
  • Vector Search 1.0
  • Pinecone
  • Weaviate

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