במסמך הזה מוצגת ארכיטקטורת הפניה שתעזור לכם לתכנן תשתית לאפליקציות של בינה מלאכותית גנרטיבית מסוג GraphRAG ב- Google Cloud. קהל היעד כולל אדריכלים, מפתחים ואדמינים שיוצרים ומנהלים מערכות חכמות לאחזור מידע. ההנחה במסמך הזה היא שיש לכם הבנה בסיסית במושגי AI, בניהול נתונים גרפיים ובגרף ידע. במסמך הזה לא מפורטות הנחיות ספציפיות לעיצוב ולפיתוח של אפליקציות GraphRAG.
GraphRAG היא גישה מבוססת-גרף ליצירה משולבת-אחזור (RAG). מערכת ה-RAG עוזרת לבסס את התשובות שנוצרות על ידי AI על ידי הוספת נתונים רלוונטיים להקשר להנחיות, שמאוחזרים באמצעות חיפוש וקטורי. GraphRAG משלב חיפוש וקטורי עם שאילתה של תרשים ידע כדי לאחזר נתונים הקשריים שמשקפים טוב יותר את הקשרים בין נתונים ממקורות מגוונים. הנחיות שמשופרות באמצעות GraphRAG יכולות ליצור תשובות מפורטות ורלוונטיות יותר מ-AI.
ארכיטקטורה
התרשים הבא מציג ארכיטקטורה של אפליקציית AI גנרטיבי עם יכולות GraphRAG ב- Google Cloud:
הארכיטקטורה בתרשים הקודם מורכבת משתי מערכות משנה: הטמעת נתונים והצגת נתונים. בקטעים הבאים מתואר הייעוד של מערכות המשנה וזרימת הנתונים בתוך מערכות המשנה וביניהן.
מערכת משנה להטמעת נתונים
מערכת המשנה להטמעת נתונים מטמיעה נתונים ממקורות חיצוניים ואז מכינה את הנתונים ל-GraphRAG. תהליך ההכנה וההטמעת נתונים כולל את השלבים הבאים:
- הנתונים מוזנים לקטגוריה של Cloud Storage. אפשר להעלות את הנתונים האלה על ידי אנליסט נתונים, להטמיע אותם ממסד נתונים או להזרים אותם מכל מקור.
- כשנתונים מוזנים, הודעה נשלחת לנושא Pub/Sub.
- Pub/Sub מפעיל פונקציית Cloud Run כדי לעבד את הנתונים שהועלו.
- פונקציית Cloud Run יוצרת תרשים ידע מקובצי הקלט באמצעות Gemini API ב-Vertex AI וכלים כמו
LLMGraphTransformerשל LangChain. - הפונקציה מאחסנת את תרשים הידע במסד נתונים של Spanner Graph.
- הפונקציה מפצלת את התוכן הטקסטואלי של קובצי הנתונים ליחידות גרנולריות באמצעות כלים כמו
RecursiveCharacterTextSplitterשל LangChain או Layout Parser של Document AI. - הפונקציה יוצרת הטמעות וקטוריות של פלחי הטקסט באמצעות Vertex AI Embeddings APIs.
- הפונקציה מאחסנת את ההטמעות הווקטוריות ואת צמתי הגרף המשויכים ב-Spanner Graph.
הטמעות הווקטוריות משמשות כבסיס לאחזור סמנטי. הצמתים של גרף הידע מאפשרים מעבר בין קשרים מורכבים של נתונים וניתוח שלהם, וגם ניתוח של דפוסים.
מערכת משנה להצגת מודעות
מערכת המשנה להצגת התוצאות מנהלת את מחזור החיים של השאילתה והתשובה בין אפליקציית ה-AI הגנרטיבי לבין המשתמשים שלה. תהליך הצגת המודעות כולל את השלבים הבאים:
- משתמש שולח שאילתה בשפה טבעית לסוכן AI, שנפרס ב-Vertex AI Agent Engine.
- הסוכן מעבד את השאילתה באופן הבא:
- השאילתה מומרת להטמעות וקטוריות באמצעות Vertex AI Embeddings APIs.
- מאחזר צמתי גרף שקשורים לשאילתה על ידי ביצוע חיפוש דמיון וקטורי במסד הנתונים של ההטמעות.
- אחזור נתונים שקשורים לשאילתה על ידי מעבר על גרף הידע.
- משפר את ההנחיה על ידי שילוב השאילתה המקורית עם נתוני הגרף שאוחזרו.
- התוצאות מדורגות באמצעות Vertex AI Search ranking API, והן מורכבות מצמתים וקשתות שנשלפים ממסד הנתונים הגרפי. הדירוג מבוסס על רלוונטיות סמנטית לשאילתה.
- מסכם את התוצאות באמצעות קריאה ל-Gemini API Vertex AI.
- הסוכן שולח למשתמש את התוצאה המסוכמת.
אפשר לאחסן ולצפות ביומני פעילות של שאילתות ותשובות ב-Cloud Logging, ולהגדיר מעקב מבוסס-יומנים באמצעות Cloud Monitoring.
המוצרים שהשתמשו בהם
ארכיטקטורת ההפניה הזו משתמשת במוצרים ובכלים הבאים של Google:
- Spanner Graph: מסד נתונים גרפי שמספק את תכונות המדרגיות, הזמינות והעקביות של Spanner.
- Vertex AI: פלטפורמה ללמידת מכונה שמאפשרת לאמן ולפרוס מודלים של למידת מכונה ואפליקציות מבוססות-AI, ולהתאים אישית מודלים גדולים של שפה (LLM) לשימוש באפליקציות מבוססות-AI.
- פונקציות Cloud Run: פלטפורמת מחשוב ללא שרת שמאפשרת להריץ פונקציות חד-מטרה ישירות ב- Google Cloud.
- Cloud Storage: מאגר אובייקטים ללא הגבלה בעלות נמוכה, לשימוש עם סוגים שונים של נתונים. אפשר לגשת לנתונים מתוך Google Cloudומחוץ לה, והם משוכפלים במיקומים שונים כדי ליצור יתירות.
- Pub/Sub: שירות העברת הודעות אסינכרוני וניתן להרחבה שמפריד בין שירותים שמפיקים הודעות לבין שירותים שמבצעים עיבוד של ההודעות האלה.
- Cloud Logging: מערכת לניהול יומנים בזמן אמת עם אפשרויות אחסון, חיפוש, ניתוח והתראות.
- Cloud Monitoring: שירות שמאפשר לראות את הביצועים, הזמינות והתקינות של האפליקציות והתשתית.
תרחישים לדוגמה
GraphRAG מאפשר שליפה חכמה של נתונים לתרחישים לדוגמה בתעשיות שונות. בקטע הזה מתוארים כמה תרחישי שימוש בתחומי הבריאות, הפיננסים, השירותים המשפטיים והייצור.
שירותי בריאות ותרופות: תמיכה בקבלת החלטות רפואיות
במערכות לתמיכה בקבלת החלטות קליניות לאבחון רפואי, GraphRAG משלב כמויות עצומות של נתונים ממאמרים רפואיים, מתיקים רפואיים אלקטרוניים של מטופלים, ממסדי נתונים של אינטראקציות בין תרופות ומתוצאות של ניסויים קליניים בגרף ידע מאוחד. כשרופאים וחוקרים שולחים שאילתה לגבי התסמינים של מטופל ותרופות שהוא נוטל כרגע, מערכת GraphRAG סורקת את תרשים הידע כדי לזהות מצבים רלוונטיים ואינטראקציות פוטנציאליות בין תרופות. הוא יכול גם ליצור המלצות לטיפול בהתאמה אישית על סמך נתונים אחרים, כמו הפרופיל הגנטי של המטופל. סוג כזה של אחזור מידע מספק תשובות עשירות יותר בהקשר ומבוססות על ראיות, בהשוואה להתאמה למילות מפתח.
שירותים פיננסיים: איחוד נתונים פיננסיים
חברות שמספקות שירותים פיננסיים משתמשות בתרשימי ידע כדי לספק לאנליסטים שלהן תצוגה מאוחדת ומובנית של נתונים ממקורות שונים, כמו דוחות אנליסטים, שיחות בנושא רווחים והערכות סיכונים. גרפים של ידע מזהים ישויות נתונים מרכזיות כמו חברות ומנהלים, וממפים את הקשרים החשובים בין הישויות. הגישה הזו מספקת רשת עשירה ומקושרת של נתונים, שמאפשרת ניתוח פיננסי מעמיק ויעיל יותר. אנליסטים יכולים לגלות תובנות שהיו חבויות עד עכשיו, כמו תלות מורכבת בשרשרת האספקה, חברות בדירקטוריונים שחופפות בין מתחרים וחשיפה לסיכונים גיאופוליטיים מורכבים.
שירותים משפטיים: מחקר מקרים וניתוח תקדימים
במגזר המשפטי, אפשר להשתמש ב-GraphRAG כדי ליצור המלצות משפטיות מותאמות אישית על סמך תקדימים, חוקים, פסיקות, עדכונים רגולטוריים ומסמכים פנימיים. כשעורכי דין מתכוננים למשפטים, הם יכולים לשאול שאלות מורכבות לגבי טיעונים משפטיים ספציפיים, פסיקות קודמות במקרים דומים או ההשלכות של חקיקה חדשה. GraphRAG ממנף את הקישוריות של הידע המשפטי הזמין כדי לזהות תקדימים רלוונטיים ולהסביר את הרלוונטיות שלהם. הוא יכול גם להציע טיעונים נגדיים על ידי מעקב אחרי הקשרים בין מושגים משפטיים, חוקים ופרשנויות שיפוטיות. הגישה הזו מאפשרת לאנשי מקצוע בתחום המשפטים לקבל תובנות מקיפות ומדויקות יותר מאשר בשיטות קונבנציונליות לאחזור מידע.
ייצור ושרשרת אספקה: גישה לידע מוסדי
פעולות ייצור ושרשרת אספקה מצריכות רמה גבוהה של דיוק. הידע שנדרש כדי לשמור על רמת הדיוק הנדרשת לרוב קבור באלפי מסמכים צפופים וסטטיים של נוהלי הפעלה סטנדרטיים (SOP). כשפס ייצור או מכונה במפעל נכשלים, או אם מתרחית בעיה לוגיסטית, מהנדסים וטכנאים מבזבזים הרבה זמן בחיפוש במסמכי PDF לא מקושרים כדי לאבחן את הבעיה ולפתור אותה. אפשר לשלב בין גרפים של ידע ו-AI בממשק שיחה כדי להפוך ידע מוסדי מוצפן לשותף אינטראקטיבי לאבחון.
חלופות עיצוב
הארכיטקטורה שמתוארת במסמך הזה היא מודולרית. אתם יכולים להתאים רכיבים מסוימים של הארכיטקטורה כדי להשתמש במוצרים, בכלים ובטכנולוגיות חלופיים בהתאם לדרישות שלכם.
יצירת תרשים הידע
אתם יכולים להשתמש בכלי LLMGraphTransformer של LangChain כדי ליצור תרשים ידע מאפס. אם מציינים את סכימת הגרף עם פרמטרים כמו LLMGraphTransformer, allowed_nodes, allowed_relationships, node_properties ו-relationship_properties, אפשר לשפר את האיכות של גרף הידע שמתקבל. עם זאת, LLMGraphTransformer עשוי לחלץ ישויות מדומיינים כלליים, ולכן הוא לא מתאים לדומיינים נישתיים כמו בריאות או תרופות. בנוסף, אם לארגון שלכם כבר יש תהליך חזק לבניית תרשימי ידע, אז מערכת המשנה להזנת נתונים שמוצגת בארכיטקטורת ההפניה הזו היא אופציונלית.
אחסון של Knowledge Graph והטמעות וקטוריות
הארכיטקטורה שמתוארת במסמך הזה משתמשת ב-Spanner כמאגר הנתונים של גרף הידע ושל הטמעות הווקטורים. אם הגרפים של הידע הארגוני שלכם כבר קיימים במקום אחר (למשל בפלטפורמה כמו Neo4j), כדאי לשקול שימוש במסד נתונים וקטורי להטמעות. עם זאת, הגישה הזו דורשת מאמץ ניהולי נוסף ועשויה להיות יקרה יותר. Spanner מספק מאגר נתונים מאוחד ועקבי ברמה הגלובלית, גם למבני גרפים וגם להטמעות וקטוריות. מאגר נתונים כזה מאפשר ניהול נתונים מאוחד, שעוזר לבצע אופטימיזציה של העלויות, הביצועים, האבטחה, השליטה והיעילות התפעולית.
Agent runtime
באדריכלות ההפניה הזו, הסוכן נפרס ב-Vertex AI Agent Engine, שמספק זמן ריצה מנוהל לסוכני AI. אפשרויות נוספות שכדאי לשקול הן Cloud Run ו-Google Kubernetes Engine (GKE). הסבר על האפשרויות האלה לא נכלל במסמך הזה.
עיגון באמצעות RAG
כמו שצוין בקטע תרחישים לדוגמה, GraphRAG מאפשר שליפת נתונים חכמה לצורך ביסוס במגוון תרחישים. עם זאת, אם לנתוני המקור שבהם אתם משתמשים כדי להוסיף הנחיות אין קשרים מורכבים, יכול להיות ש-RAG היא בחירה מתאימה לאפליקציית ה-AI הגנרטיבי שלכם.
ארכיטקטורות ההפניה הבאות מראות איך אפשר לבנות את התשתית שנדרשת ל-RAG ב- Google Cloud באמצעות מסדי נתונים מנוהלים עם תמיכה בווקטורים או מוצרים ייעודיים לחיפוש וקטורים:
- תשתית RAG ל-AI גנרטיבי באמצעות Vertex AI ו-Vector Search
- תשתית RAG ל-AI גנרטיבי באמצעות Vertex AI ו-AlloyDB ל-PostgreSQL
- תשתית RAG ל-AI גנרטיבי באמצעות GKE ו-Cloud SQL
- תשתית RAG ל-AI גנרטיבי באמצעות Gemini Enterprise ו-Vertex AI.
שיקולים לגבי העיצוב
בקטע הזה מפורטים גורמים שצריך לקחת בחשבון בתכנון, שיטות מומלצות והמלצות לשימוש בארכיטקטורת ההפניה הזו כדי לפתח טופולוגיה שעונה על הדרישות הספציפיות שלכם בנוגע לאבטחה, למהימנות, לעלות ולביצועים.
ההנחיות בקטע הזה הן חלקיות. בהתאם לדרישות של עומס העבודה ולמוצרים ולתכונות של צד שלישי שבהם אתם משתמשים, יכול להיות שיש עוד גורמים עיצוביים ופשרות שכדאי לקחת בחשבון. Google Cloud
אבטחה, פרטיות ותאימות
בקטע הזה מתוארים שיקולים והמלצות לתכנון טופולוגיה ב- Google Cloud שעומדת בדרישות האבטחה והתאימות של עומס העבודה.
| מוצר | שיקולים והמלצות לגבי עיצוב |
|---|---|
| Vertex AI | Vertex AI תומך באמצעי בקרה לאבטחה שבהם אפשר להשתמש כדי לעמוד בדרישות שלכם בנוגע למיקום הנתונים, להצפנת הנתונים, לאבטחת הרשת ולשקיפות הגישה. Google Cloud מידע נוסף זמין במשאבי העזרה הבאים: מודלים של AI גנרטיבי עלולים ליצור תשובות מזיקות, במיוחד אם הם מקבלים הנחיות מפורשות ליצור תשובות כאלה. כדי לשפר את הבטיחות ולצמצם את הסיכון לשימוש לרעה, אתם יכולים להגדיר מסנני תוכן שימנעו תשובות מזיקות. מידע נוסף זמין במאמר בנושא מסנני בטיחות ותוכן. |
| Spanner Graph | כברירת מחדל, הנתונים שמאוחסנים ב-Spanner Graph מוצפנים באמצעות Google-owned and Google-managed encryption keys. אם אתם צריכים להשתמש במפתחות הצפנה שאתם שולטים בהם ומנהלים אותם, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK). מידע נוסף זמין במאמר מידע על CMEK. |
| פונקציות Cloud Run | כברירת מחדל, Cloud Run מצפין נתונים באמצעות Google-owned and Google-managed encryption keys. כדי להגן על הקונטיינרים באמצעות מפתחות שאתם שולטים בהם, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK). מידע נוסף זמין במאמר בנושא שימוש במפתחות הצפנה בניהול הלקוח. כדי לוודא שרק קובצי אימג' מורשים של קונטיינרים נפרסים ב-Cloud Run, אפשר להשתמש ב-Binary Authorization. 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 עוזר לכם לעמוד בדרישות של מיקום הנתונים. הנתונים מאוחסנים או משוכפלים באזור שאתם מציינים. |
| Pub/Sub | כברירת מחדל, Pub/Sub מצפין את כל ההודעות, גם במצב מנוחה וגם במעבר, באמצעות Google-owned and Google-managed encryption keys. Pub/Sub תומך בשימוש במפתחות הצפנה בניהול הלקוח (CMEK) להצפנת הודעות בשכבת האפליקציה. מידע נוסף זמין במאמר בנושא הגדרת הצפנת הודעות. אם יש לכם דרישות לגבי מיקום הנתונים, כדי לוודא שנתוני ההודעות מאוחסנים במיקומים ספציפיים, אתם יכולים להגדיר מדיניות לאחסון הודעות. |
| Cloud Logging | יומני הביקורת של פעילות האדמין מופעלים כברירת מחדל לכל השירותים של Google Cloud שנעשה בהם שימוש בארכיטקטורת ההפניה הזו. ביומנים האלה מתועדות קריאות ל-API או פעולות אחרות שמשנות את ההגדרות או את המטא-נתונים של משאביGoogle Cloud . בשירותים שבהם נעשה שימוש בארכיטקטורה הזו, אפשר להפעיל יומני ביקורת לגבי גישה לנתונים. Google Cloud היומנים האלה מאפשרים לכם לעקוב אחרי קריאות ל-API שקוראות את ההגדרות או את המטא-נתונים של משאבים, או אחרי בקשות של משתמשים ליצור, לשנות או לקרוא נתוני משאבים שסופקו על ידי משתמשים. כדי לעמוד בדרישות של מיקום הנתונים, אתם יכולים להגדיר את Cloud Logging לאחסון נתוני יומנים באזור שאתם מציינים. מידע נוסף מופיע במאמר הגדרת אזור ליומנים. |
עקרונות והמלצות אבטחה שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Security ב- Google Cloud Well-Architected Framework.
אמינות
בקטע הזה מפורטים שיקולים והמלצות לתכנון, לבנייה ולהפעלה של תשתית אמינה לפריסה ב- Google Cloud.
| מוצר | שיקולים והמלצות לגבי עיצוב |
|---|---|
| Vertex AI | Vertex AI תומך במכסת שימוש דינמית משותפת (DSQ) למודלים של Gemini. התכונה DSQ עוזרת לנהל באופן גמיש בקשות לתשלום לפי שימוש, ומבטלת את הצורך לנהל את המכסה באופן ידני או לבקש הגדלה של המכסה. DSQ מקצה באופן דינמי את המשאבים הזמינים למודל ולאזור מסוימים ללקוחות פעילים. ב-DSQ, אין מכסות מוגדרות מראש ללקוחות פרטיים. אם מספר הבקשות חורג מהקיבולת שהוקצתה, מוחזר קוד השגיאה 429. עבור עומסי עבודה שהם קריטיים לעסק ודורשים באופן עקבי תפוקה גבוהה, אפשר להזמין תפוקה באמצעות הקצאת משאבים לפי התפוקה שנקבעה. אם אפשר לשתף נתונים בין כמה אזורים או מדינות, אפשר להשתמש בנקודת קצה גלובלית. |
| Spanner Graph | Spanner מיועד לזמינות גבוהה של נתונים ולמדרגיות גלובלית. כדי להבטיח זמינות גם במהלך הפסקה זמנית בשירות באזור מסוים, Spanner מציע הגדרות במספר אזורים, שמשכפלות נתונים במספר אזורים. בנוסף ליכולות המובנות של עמידות, Spanner מספק את התכונות הבאות לתמיכה באסטרטגיות מקיפות להתאוששות מאסון:
מידע נוסף זמין במאמר סקירה כללית על תוכנית התאוששות מאסון (DR). |
| פונקציות Cloud Run | Cloud Run הוא שירות אזורי. הנתונים מאוחסנים באופן סינכרוני בכמה אזורים בתוך אזור. תעבורת הנתונים מאוזנת אוטומטית בין האזורים. אם מתרחשת הפסקה זמנית בשירות באזור, Cloud Run ממשיך לפעול והנתונים לא אובדים. אם מתרחשת הפסקה זמנית בשירות באזור מסוים, השירות מפסיק לפעול עד ש-Google פותרת את הבעיה. |
| Cloud Storage | אפשר ליצור קטגוריות של Cloud Storage באחד משלושת סוגי המיקומים: אזורי, בשני אזורים או במספר אזורים. נתונים שמאוחסנים בקטגוריות אזוריות משוכפלים באופן סינכרוני בכמה אזורים בתוך אזור. כדי להשיג זמינות גבוהה יותר, אפשר להשתמש בקטגוריות בשני אזורים או במספר אזורים, שבהן הנתונים משוכפלים באופן אסינכרוני בין האזורים. |
| Pub/Sub | כדי למנוע שגיאות בתקופות של עליות זמניות בתנועת ההודעות, אפשר להגביל את קצב הבקשות לפרסום על ידי הגדרת בקרה על זרימת נתונים בהגדרות של המפרסם. כדי לטפל בניסיונות פרסום שנכשלו, משנים את המשתנים של בקשת הניסיון החוזר לפי הצורך. מידע נוסף זמין במאמר בנושא ניסיון חוזר לשליחת בקשות. |
| כל המוצרים בארכיטקטורה | אחרי שפורסים את עומס העבודה ב- Google Cloud, אפשר להשתמש ב-Active Assist כדי לקבל המלצות לאופטימיזציה נוספת של המהימנות של משאבי הענן. בודקים את ההמלצות ומיישמים אותן בהתאם לסביבה שלכם. איך מוצאים המלצות ב-Active Assist |
עקרונות והמלצות בנושא מהימנות שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Reliability (נקודת מבט על AI ו-ML: מהימנות) ב-Well-Architected Framework.
הוזלת עלויות
בקטע הזה מוסבר איך לבצע אופטימיזציה של העלות של הגדרת טופולוגיה של Google Cloud והפעלתה, שאתם בונים באמצעות ארכיטקטורת ההפניה הזו.
| מוצר | שיקולים והמלצות לגבי עיצוב |
|---|---|
| Vertex AI | כדי לנתח ולנהל את העלויות של Vertex AI, מומלץ ליצור בסיס של שאילתות לשנייה (QPS) וטוקנים לשנייה (TPS) ולעקוב אחרי המדדים האלה אחרי הפריסה. ערך הבסיס עוזר גם בתכנון הקיבולת. לדוגמה, ערך הבסיס עוזר לכם לקבוע מתי צריך תפוקת נתונים שהוקצתה. בחירת המודל המתאים ליישום שלכם של AI גנרטיבי היא החלטה קריטית שמשפיעה ישירות על העלויות ועל הביצועים. כדי לזהות את המודל שמספק איזון אופטימלי בין ביצועים לעלות בתרחיש השימוש הספציפי שלכם, מומלץ לבדוק מודלים באופן איטרטיבי. מומלץ להתחיל עם המודל הכי חסכוני ולעבור בהדרגה לאפשרויות מתקדמות יותר. האורך של ההנחיות (הקלט) והתשובות שנוצרות (הפלט) משפיע ישירות על הביצועים והעלות. לכתוב הנחיות קצרות וישירות שמספקות הקשר מספק. כדאי לעצב את ההנחיות כדי לקבל מהמודל תשובות תמציתיות. לדוגמה, אפשר להוסיף ביטויים כמו "סכם ב-2 משפטים" או "ציין 3 נקודות עיקריות". מידע נוסף זמין במאמר בנושא שיטות מומלצות לעיצוב הנחיות. כדי להפחית את העלות של בקשות שמכילות תוכן חוזר עם מספר גבוה של טוקנים של קלט, אפשר להשתמש בשמירת הקשר במטמון. אם רלוונטי, כדאי להשתמש בחיזויים רבים בבת אחת. בקשות באצווה מחויבות במחיר נמוך יותר מבקשות רגילות. |
| Spanner Graph | אפשר להשתמש במידרוג אוטומטי מנוהל כדי לשנות באופן דינמי את קיבולת המחשוב של מסדי נתונים של Spanner Graph על סמך ניצול המעבד וצרכי האחסון. לעתים קרובות נדרשת קיבולת מינימלית, גם לעומסי עבודה קטנים. כדי לקבל הנחות על קיבולת צפויה, יציבה או בסיסית של מחשוב, כדאי לרכוש הנחות תמורת התחייבות לשימוש (CUD). הנחות CUD מאפשרות לקבל הנחות משמעותיות בתמורה להתחייבות להוצאה של סכום מסוים לשעה על קיבולת מחשוב. כשמעתיקים גיבויים לאזורים שונים לצורך התאוששות מאסון או לצורך עמידה בדרישות, צריך לקחת בחשבון את עלויות תעבורת הנתונים היוצאת (egress). כדי לצמצם את העלויות, כדאי להעתיק רק את הגיבויים החיוניים. |
| פונקציות Cloud Run | כשיוצרים פונקציות Cloud Run, אפשר לציין את כמות הזיכרון והמעבד (CPU) שיוקצו. כדי לשלוט בעלויות, כדאי להתחיל עם הקצאות ברירת המחדל (המינימליות) של מעבד וזיכרון. כדי לשפר את הביצועים, אפשר להגדיל את ההקצאה על ידי הגדרת מכסת המעבד ומכסת הזיכרון. מידע נוסף זמין במאמרי העזרה הבאים: אם אתם יכולים לחזות את הדרישות שלכם לגבי יחידת העיבוד המרכזית (CPU) והזיכרון, אתם יכולים לחסוך כסף באמצעות הנחות תמורת התחייבות לשימוש (CUD). |
| Cloud Storage | עבור קטגוריית Cloud Storage במערכת המשנה של הטמעת נתונים, בוחרים סוג אחסון (storage class) מתאים על סמך הדרישות של עומס העבודה לגבי שמירת נתונים ותדירות הגישה. לדוגמה, כדי לשלוט בעלויות האחסון, אפשר לבחור את סוג האחסון Standard ולהשתמש ב ניהול מחזור החיים של אובייקטים. הגישה הזו מאפשרת להוריד באופן אוטומטי את הסיווג של אובייקטים לסיווג אחסון בעלות נמוכה יותר, או למחוק אובייקטים באופן אוטומטי על סמך תנאים שצוינו. |
| Cloud Logging | כדי לשלוט בעלות של אחסון היומנים, אפשר:
|
| כל המוצרים בארכיטקטורה | אחרי שפורסים את עומס העבודה ב- Google Cloud, אפשר להשתמש ב-Active Assist כדי לקבל המלצות לאופטימיזציה נוספת של עלויות המשאבים בענן. בודקים את ההמלצות ומיישמים אותן בהתאם לסביבה שלכם. איך מוצאים המלצות ב-Active Assist |
כדי להעריך את העלות של המשאבים ב- Google Cloud , אפשר להשתמש בGoogle Cloud מחשבון עלויות.
עקרונות והמלצות לאופטימיזציה של עלויות שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Cost optimization ב-Well-Architected Framework.
אופטימיזציה של הביצועים
בקטע הזה מפורטים שיקולים והמלצות לתכנון טופולוגיה ב- Google Cloud שעומדת בדרישות הביצועים של עומסי העבודה.
| מוצר | שיקולים והמלצות לגבי עיצוב |
|---|---|
| Vertex AI |
בחירת המודל המתאים ליישום שלכם של AI גנרטיבי היא החלטה קריטית שמשפיעה ישירות על העלויות ועל הביצועים. כדי לזהות את המודל שמספק איזון אופטימלי בין ביצועים לעלות בתרחיש השימוש הספציפי שלכם, מומלץ לבדוק מודלים באופן איטרטיבי. מומלץ להתחיל עם המודל הכי חסכוני ולעבור בהדרגה לאפשרויות מתקדמות יותר. האורך של ההנחיות (הקלט) והתשובות שנוצרות (הפלט) משפיע ישירות על הביצועים והעלות. לכתוב הנחיות קצרות וישירות שמספקות הקשר מספק. כדאי לעצב את ההנחיות כדי לקבל מהמודל תשובות תמציתיות. לדוגמה, אפשר להוסיף ביטויים כמו "סכם ב-2 משפטים" או "ציין 3 נקודות עיקריות". מידע נוסף זמין במאמר בנושא שיטות מומלצות לעיצוב הנחיות. הכלי לאופטימיזציה של הנחיות ב-Vertex AI מאפשר לשפר ולבצע אופטימיזציה של ביצועי ההנחיות במהירות ובקנה מידה גדול, ומבטל את הצורך בשכתוב ידני. הכלי לאופטימיזציה עוזר לכם להתאים הנחיות ביעילות למודלים שונים. |
| Spanner Graph | המלצות לאופטימיזציה של הביצועים של Spanner Graph מופיעות במאמרי העזרה הבאים: |
| פונקציות Cloud Run | כברירת מחדל, לכל מופע של פונקציית Cloud Run מוקצה מעבד אחד ו-256MiB של זיכרון. בהתאם לדרישות הביצועים, אפשר להגדיר מגבלות על המעבד (CPU) והזיכרון. מידע נוסף זמין במשאבי העזרה הבאים: לקבלת הנחיות נוספות לאופטימיזציה של הביצועים, אפשר לעיין בטיפים כלליים לפיתוח ב-Cloud Run. |
| Cloud Storage | כדי להעלות קבצים גדולים, אפשר להשתמש בהעלאות מורכבות מקבילות. באסטרטגיה הזו, הקובץ הגדול מפולח לחלקים. המקטעים מועלים ל-Cloud Storage במקביל, ואז הנתונים מורכבים מחדש בענן. אם רוחב הפס של הרשת ומהירות הדיסק לא מגבילים את ההעלאה, העלאות מורכבות מקבילות יכולות להיות מהירות יותר מהעלאות רגילות. עם זאת, לאסטרטגיה הזו יש כמה מגבלות והשלכות על העלויות. מידע נוסף זמין במאמר בנושא העלאות מורכבות במקביל. |
| כל המוצרים בארכיטקטורה | אחרי שפורסים את עומס העבודה ב- Google Cloud, אפשר להשתמש ב-Active Assist כדי לקבל המלצות לשיפור נוסף של הביצועים של משאבי הענן. בודקים את ההמלצות ומיישמים אותן בהתאם לסביבה שלכם. איך מוצאים המלצות ב-Active Assist |
עקרונות והמלצות לאופטימיזציה של ביצועים שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Performance optimization ב-Well-Architected Framework.
פריסה
כדי להבין איך GraphRAG פועל ב- Google Cloud, אפשר להוריד ולהפעיל את מחברת Jupyter הבאה מ-GitHub: GraphRAG on Google Cloud With Spanner Graph and Vertex AI Agent Engine.
המאמרים הבאים
- פיתוח אפליקציות GraphRAG באמצעות Spanner Graph ו-LangChain
- בחירת מודלים ותשתית לאפליקציות מבוססות-AI גנרטיבי
- תשתית RAG ל-AI גנרטיבי באמצעות Vertex AI ו-Vector Search
- תשתית RAG ל-AI גנרטיבי באמצעות Vertex AI ו-AlloyDB ל-PostgreSQL
- תשתית RAG ל-AI גנרטיבי באמצעות GKE ו-Cloud SQL
- תשתית RAG ל-AI גנרטיבי באמצעות Gemini Enterprise ו-Vertex AI
- כדי לקרוא על עקרונות ארכיטקטוניים והמלצות לגבי עומסי עבודה של AI ב- Google Cloud, אפשר לעיין בWell-Architected Framework: AI and ML perspective.
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחברים:
- טריסטן לי | ארכיטקט ראשי, AI/ML
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים
תורמי תוכן אחרים:
- Ahsif Sheikh | AI Customer Engineer
- Ashish Chauhan | AI Customer Engineer
- גרג ברוסמן | מנהל מוצר
- לוקאס ברודרר | מנהל מוצר, Cloud AI
- Nanditha Embar | AI Customer Engineer
- פיוש מתור | מנהל מוצר, Spanner
- Smitha Venkat | AI Customer Engineer