היבטים של AI ו-ML: מהימנות

Last reviewed 2025-08-07 UTC

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

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

ההמלצות במסמך הזה ממופות לעקרונות הליבה הבאים:

לוודא שתשתית ה-ML ניתנת להרחבה וזמינה מאוד

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

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

הטמעה של יכולות התאמה אוטומטית ודינמית לעומס

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

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

  • צינורות לעיבוד נתונים: יצירת צינורות נתונים ב-Dataflow. מגדירים את צינורות הנתונים כך שישתמשו בתכונה התאמה אוטומטית לעומס (autoscaling) אופקית של Dataflow, שמתאימה באופן דינמי את מספר המופעים של העובדים על סמך ניצול המעבד, מקביליות צינורות הנתונים והנתונים שממתינים לעיבוד. אתם יכולים להגדיר פרמטרים של התאמה אוטומטית לעומס באמצעות אפשרויות של פייפליין כשאתם מפעילים משימות.
  • משימות אימון: אפשר להשתמש באימון בהתאמה אישית ב-Gemini Enterprise Agent Platform כדי להגדיל אוטומטית את מספר משימות האימון. אפשר להגדיר מפרטים של מאגר העובדים, כמו סוג המכונה, הסוג והמספר של המאיצים ומספר מאגרי העובדים. כדי להפחית את העלויות של משימות שיכולות לעמוד בהפרעות, ומשימות שבהן קוד ההדרכה מיישם שמירת נתונים, אפשר להשתמש במכונות Spot VM.
  • היסק אונליין: כדי לבצע היסק אונליין, משתמשים בנקודות קצה של Agent Platform. כדי להפעיל את ההתאמה האוטומטית לעומס, צריך להגדיר את המספר המינימלי והמקסימלי של העותקים. צריך לציין לפחות שני עותקים משוכפלים לזמינות גבוהה. Agent Platform מתאימה באופן אוטומטי את מספר הרפליקות על סמך תעבורת הנתונים והמדדים של ההתאמה האוטומטית לעומס שהוגדרו, כמו ניצול המעבד וניצול הרפליקה.
  • עומסי עבודה (workload) בקונטיינרים ב-Google Kubernetes Engine: הגדרת שינוי גודל אוטומטי ברמת הצומת וברמת ה-Pod. מגדירים את התאמת הגודל האוטומטית של האשכול ואת הקצאת הצמתים האוטומטית כדי להתאים את מספר הצמתים על סמך בקשות למשאבי Pod בהמתנה, כמו CPU, זיכרון, GPU ו-TPU. אפשר להשתמש ב-Horizontal Pod Autoscaler (HPA) לפריסות כדי להגדיר מדיניות של שינוי גודל על סמך מדדים כמו ניצול CPU וזיכרון. אפשר גם להרחיב את המידות על סמך מדדים מותאמים אישית של AI ו-ML, כמו ניצול GPU או TPU ובקשות חיזוי לשנייה.
  • שירותים בקונטיינרים בלי שרת (serverless): פריסת השירותים ב-Cloud Run והגדרת התאמה אוטומטית לעומס (autoscaling) על ידי ציון מספר המכונות המינימלי והמקסימלי של הקונטיינרים. כדי להגדיר שינוי גודל אוטומטי של מכונות עם GPU, צריך לציין את סוג המאיץ. מומלץ להשתמש בשיטות מומלצות. מערכת Cloud Run מתאימה באופן אוטומטי את מספר המכונות בין המינימום והמקסימום שהוגדרו, בהתאם לבקשות הנכנסות. כשאין בקשות, המערכת מצמצמת את מספר המכונות בצורה יעילה לאפס. אתם יכולים להשתמש בהתאמת קנה מידה אוטומטית לפי בקשה של Cloud Run כדי לפרוס סוכנים ולפרוס עומסי עבודה של צד שלישי, כמו מודלים שעברו קוונטיזציה באמצעות Ollama והסקת מסקנות של מודלים של LLM באמצעות vLLM.

תכנון להשגת זמינות גבוהה ועמידות בפני תקלות

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

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

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

ניהול משאבים באופן פרואקטיבי וחיזוי דרישות

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

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

  • כדאי לאמת את הערכות הקיבולת באמצעות בדיקות עומס קפדניות. מדמים תנועה בשירותי AI ו-ML כמו serving ו-pipelines באמצעות כלים כמו Apache JMeter או LoadView.
  • לנתח את התנהגות המערכת במצבי לחץ.
    • כדי לצפות מראש את הדרישות המוגברות של עומסי העבודה בסביבת הייצור ולעמוד בהן, צריך לזהות מראש את דרישות המשאבים. מעקב אחרי זמן האחזור, קצב העברת הנתונים, השגיאות וניצול המשאבים, במיוחד ניצול ה-GPU וה-TPU. מגדילים את מכסות המשאבים לפי הצורך.
    • כדי להשתמש ב-AI גנרטיבי, צריך לבצע בדיקות בעומסים גבוהים בו-זמנית ולזהות את הרמה שבה זמינות המאיץ מגבילה את הביצועים.
  • מבצעים מעקב רציף אחרי שאילתות של מודלים ומגדירים התראות יזומות לסוכנים.

אופטימיזציה של הזמינות וההשגה של משאבים

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

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

  • לצמתים ב-GKE ולמכונות וירטואליות ב-Compute Engine, אפשר להשתמש במכונות וירטואליות מסוג Spot וביכולות של Dynamic Workload Scheduler ‏ (DWS):

    • למשימות עמידות בכשלים, כמו עומסי עבודה של הערכה וניסויים, כדאי להשתמש ב-Spot VMs. יכול להיות שיהיה צורך להפסיק את השימוש במכונות וירטואליות מסוג Spot, אבל הן יכולות לעזור לכם להפחית את העלויות הכוללות.
    • כדי לנהל את הסיכון להפסקת פעולה של מאיצים עם ביקוש גבוה, אפשר להשתמש ב-DWS כדי לשפר את הסיכוי לקבלת המאיצים.
      • לצורך אימון מורכב של קבוצות נתונים שדורש מעבדי GPU מתקדמים כדי לפעול עד שבעה ימים, אפשר להשתמש במצב DWS Flex-Start.
      • לעומסי עבודה שפועלים למשך תקופה ארוכה יותר, עד שלושה חודשים, אפשר להשתמש במצב 'יומן' כדי לשריין יחידות GPU ספציפיות (H100 ו-H200) ויחידות TPU ספציפיות (Trillium).

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

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

    • ‫Cluster Director מאפשר לפרוס ולנהל קבוצות של מאיצים עם מיקום משותף ותזמון לאימון של כמה מעבדי GPU‏ (A3 Ultra H200 ו-A4 B200). ‫Cluster Director תומך באשכולות GKE ו-Slurm.
    • ‫Ray on Gemini Enterprise Agent Platform מפשטת את תשתית המחשוב המבוזרת. הוא מאפשר לאפליקציות לבקש משאבים לאימון ולפרסום בלי צורך בניהול ישיר של מכונות וירטואליות וקונטיינרים.

הפצת תנועה נכנסת בין כמה מופעים

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

  • הסקת מסקנות עם צרכים משתנים של משאבים: הטמעה של איזון עומסים על סמך מדדי המודל. ‫GKE Inference Gateway מאפשר לכם לפרוס מודלים מאחורי מאזן עומסים עם ניתוב מודע-מודל. השער נותן עדיפות למופעים עם מאיצי GPU ו-TPU למשימות שדורשות הרבה כוח מחשוב, כמו AI גנרטיבי והסקת מסקנות של LLM. הגדרת בדיקות תקינות מפורטות כדי להעריך את סטטוס המודל. אפשר להשתמש במסגרות להצגת מודלים כמו vLLM או Triton למדדי LLM, ולשלב את המדדים ב-Cloud Monitoring באמצעות השירות המנוהל של Google Cloud ל-Prometheus.
  • עומסי עבודה של הסקת מסקנות שדורשים מעבדי GPU או TPU: כדי להבטיח שעומסי עבודה קריטיים של הסקת מסקנות ב-AI וב-ML יפעלו באופן עקבי במכונות שמתאימות לדרישות של עומסי העבודה, במיוחד כשזמינות מעבדי GPU ו-TPU מוגבלת, כדאי להשתמש בסוגי מחשוב בהתאמה אישית ב-GKE. אפשר להגדיר פרופילים ספציפיים של Compute עם מדיניות חזרה לגיבוי עבור התאמה אוטומטית לעומס. לדוגמה, אפשר להגדיר פרופיל שמציין עדיפות גבוהה יותר למכונות וירטואליות שמורות עם GPU או TPU. הפרופיל יכול לכלול חזרה לשימוש במכונות וירטואליות מסוג Spot חסכוניות אם המשאבים השמורים לא זמינים באופן זמני.
  • AI גנרטיבי בפלטפורמות שונות לניהול תהליכים: שימוש במאזן עומסים מרכזי. לדוגמה, כדי לחסוך בעלויות ולשפר את יעילות הניהול, אפשר להפנות בקשות עם צורכי GPU נמוכים ל-Cloud Run, ולהפנות משימות מורכבות יותר שדורשות הרבה GPU ל-GKE. כדי לנהל את המדיניות ולנהל את התקשורת בין השירותים, כדאי להטמיע רשת שירותים באמצעות Cloud Service Mesh. כדי להבטיח רישום ביומן ומעקב עקביים, כדאי להשתמש ב-Cloud Logging וב-Cloud Monitoring.
  • חלוקת עומסים גלובלית: כדי לאזן את עומס התנועה ממשתמשים גלובליים שזקוקים לזמן אחזור נמוך, משתמשים במאזן עומסים גלובלי חיצוני של אפליקציות (ALB). הגדרת ניתוב לפי מיקום גיאוגרפי לאזור הקרוב ביותר והטמעה של יתירות כשל. הגדרת שכפול של נקודות קצה אזוריות ב-Agent Platform או ב-GKE. הגדרת Cloud CDN לנכסים סטטיים. מעקב אחרי תעבורה וזמן אחזור גלובליים באמצעות Cloud Monitoring.
  • ניהול תנועה ברמת פירוט גבוהה: כדי לנהל בקשות עם סוגי נתונים מגוונים או בקשות מורכבות ובקשות שפועלות לאורך זמן, צריך להטמיע ניהול תנועה ברמת פירוט גבוהה.
    • הגדרת ניתוב מבוסס-תוכן כדי להפנות בקשות לשרתי קצה עורפיים ייעודיים על סמך מאפיינים כמו נתיבי כתובות URL וכותרות. לדוגמה, בקשות ישירות לשרתי קצה עורפיים עם GPU למודלים של תמונות או סרטונים, ולשרתי קצה עורפיים שעברו אופטימיזציה ל-CPU למודלים מבוססי-טקסט.
    • לגבי בקשות ארוכות טווח של AI גנרטיבי או עומסי עבודה של אצווה, צריך להשתמש ב-WebSockets או ב-gRPC. הטמעה של ניהול תנועה כדי לטפל בפסק זמן ובאגירה. הגדרת פסק זמן לתפוגת בקשה וניסיונות חוזרים, והטמעה של הגבלת קצב ומכסות באמצעות API Gateway או Apigee.

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

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

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

הטמעה של מודולים או רכיבים קטנים ועצמאיים

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

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

מיקרו-שירותים (microservices) בקונטיינרים ב-GKE

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

פריסת המיקרו-שירותים מבוססי-הקונטיינר ב-GKE ושימוש בהרחבה אוטומטית על סמך ניצול CPU וזיכרון או מדדים מותאמים אישית כמו ניצול GPU, עדכונים מצטברים והגדרות שניתנות לשחזור במניפסטים של YAML. כדי להבטיח תקשורת יעילה בין המיקרו-שירותים, צריך להשתמש בגילוי שירותים ב-GKE. לדפוסים אסינכרוניים, משתמשים בתורי הודעות כמו Pub/Sub.

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

שירותים מבוססי-אירועים ללא שרת

למשימות מבוססות-אירועים שיכולות להפיק תועלת מסביבה ללא שרתים ומקנה מידה אוטומטי, כדאי להשתמש ב-Cloud Run או ב-Cloud Run Functions. השירותים האלה אידיאליים למשימות אסינכרוניות כמו עיבוד מקדים או למשימות קטנות יותר של הסקת מסקנות. הפעלת פונקציות של Cloud Run באירועים, כמו קובץ נתונים חדש שנוצר ב-Cloud Storage או עדכוני מודלים ב-Artifact Registry. למשימות או לשירותים של web-hook שזקוקים לסביבת קונטיינר, צריך להשתמש ב-Cloud Run.

שירותי Cloud Run ופונקציות Cloud Run יכולים להגדיל את הקיבולת שלהם במהירות ולהקטין אותה עד לאפס, וכך לעזור לכם להבטיח יעילות בעלויות של עומסי עבודה משתנים. השירותים האלה מתאימים לרכיבים מודולריים בתהליכי עבודה של שיחות עם נציגים. אפשר לתזמן רצפים של רכיבים באמצעות Workflows או Application Integration.

שירותים מנוהלים ב-Agent Platform

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

  • כדי לתזמן תהליכי עבודה שמורכבים משלבים מודולריים, אפשר להשתמש בצינורות של פלטפורמת הסוכנים של Gemini Enterprise.
  • כדי להריץ קוד מותאם אישית של AI ו-ML, צריך לארוז את הקוד בקונטיינרים של Docker שאפשר להריץ בשירותים מנוהלים כמו אימון מותאם אישית ב-Agent Platform וחיזוי ב-Agent Platform.
  • כדי ליצור צינורות מודולריים של הנדסת תכונות, משתמשים במאגר התכונות של Agent Platform.
  • כדי ליצור אב טיפוס ולחקור מודולים, אפשר להשתמש בסביבות מחברת כמו Gemini Enterprise Agent Platform Workbench או Colab Enterprise. ארגון הקוד בפונקציות, במחלקות ובסקריפטים שאפשר לעשות בהם שימוש חוזר.

אפליקציות עם סוכנים

לסוכני AI,‏ Agent Development Kit (ADK) מספק יכולות מודולריות כמו Tools ו-State. כדי לאפשר פעולה הדדית בין מסגרות כמו LangChain,‏ LangGraph,‏ LlamaIndex ו-Agent Platform, אפשר לשלב את ADK עם הפרוטוקול Agent2Agent‏ (A2A) ועם הפרוטוקול Model Context Protocol‏ (MCP). היכולת הזו מאפשרת לכם ליצור תהליכי עבודה אג'נטיים באמצעות רכיבים מגוונים.

אתם יכולים לפרוס סוכנים ב-Agent Runtime בפלטפורמת הסוכנים של Gemini Enterprise. זוהי סביבת ריצה מנוהלת שמיועדת לפריסת סוכנים בהיקף רחב. כדי להריץ סוכנים מבוססי-קונטיינר, אפשר להשתמש ביכולות של התאמה אוטומטית לעומס ב-Cloud Run.

עיצוב ממשקים מוגדרים היטב

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

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

בחירת פרוטוקול

  • כדי לאפשר גישה אוניברסלית, צריך להשתמש בממשקי HTTP API, לפעול לפי עקרונות RESTful ולהשתמש ב-JSON להחלפת נתונים ללא תלות בשפה. עיצוב נקודות הקצה של ה-API כך שיציגו פעולות על משאבים.
  • כדי להשיג ביצועים גבוהים בתקשורת פנימית בין מיקרו-שירותים, מומלץ להשתמש ב-gRPC עם Protocol Buffers (ProtoBuf) כדי להשיג סריאליזציה יעילה והקלדה קפדנית. מגדירים מבני נתונים כמו ModelInput,‏ PredictionResult או נתונים של כלי ADK באמצעות קובצי .proto, ואז יוצרים קשרי שפה.
  • בתרחישי שימוש שבהם הביצועים הם קריטיים, כדאי להשתמש בסטרימינג של gRPC עבור מערכי נתונים גדולים או עבור זרימות רציפות כמו המרת טקסט לדיבור או אפליקציות וידאו בשידור חי. פורסים את שירותי gRPC ב-GKE.

תיעוד סטנדרטי ומקיף

לא משנה איזה פרוטוקול ממשק תבחרו, חשוב שתהיה לכם תיעוד סטנדרטי. מפרט OpenAPI מתאר ממשקי API ל-REST. משתמשים ב-OpenAPI כדי לתעד את ממשקי ה-API של AI ו-ML: נתיבים, שיטות, פרמטרים, פורמטים של בקשות ותגובות שמקושרים לסכימות JSON ואבטחה. מאמרי העזרה של ה-API עוזרים לשפר את יכולת הגילוי ואת שילוב הלקוחות. כדי ליצור ולראות את ה-API, אפשר להשתמש בכלי ממשק משתמש כמו Swagger Editor. כדי להאיץ את הפיתוח ולהבטיח עקביות, אפשר ליצור ערכות SDK ללקוח ו-stubs לשרת באמצעות כלי תכנות מבוססי-AI כמו Gemini Code Assist. שילוב של תיעוד OpenAPI בתהליך CI/CD.

אינטראקציה עם Google Cloud שירותים מנוהלים כמו Agent Platform

אפשר לבחור בין רמת ההפשטה הגבוהה יותר של Agent Platform SDK, שמומלצת לפרודוקטיביות של פיתוח, לבין השליטה המפורטת ש-API בארכיטקטורת REST מספק.

  • ה-SDK של Agent Platform מפשט את המשימות ואת תהליך האימות. משתמשים ב-SDK כשצריך ליצור אינטראקציה עם Agent Platform.
  • ה-API בארכיטקטורת REST הוא חלופה יעילה, במיוחד כשנדרשת יכולת פעולה הדדית בין השכבות של המערכת. היא שימושית לכלים בשפות שאין להן SDK או כשרוצים שליטה מדויקת.

שימוש בממשקי API כדי לבודד מודולים ולבצע הפשטה של פרטי ההטמעה

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

  • ‫API Gateway: לממשקי API שחשופים לחיצוניים ומנוהלים על ידי חיצוניים, API Gateway מספק נקודת כניסה מרכזית ומאובטחת. הוא מפשט את הגישה לשירותים לקצה העורפי בלי שרתים, כמו API לחיזוי, להדרכה ולנתונים. ‫API Gateway עוזר לאחד נקודות גישה, לאכוף חוזי API ולנהל יכולות אבטחה כמו מפתחות API ו-OAuth 2.0. כדי להגן על קצה עורפי מפני עומס יתר ולהבטיח אמינות, כדאי להטמיע הגבלת קצב ומכסות שימוש ב-API Gateway.
  • ‫Cloud Endpoints: כדי לייעל את הפיתוח והפריסה של ממשקי API ב-GKE וב-Cloud Run, אפשר להשתמש ב-Cloud Endpoints, שמציע פתרון ידידותי למפתחים ליצירת מפתחות API. בנוסף, הוא מספק מעקב וניטור משולבים של קריאות ל-API, ומבצע אוטומטית יצירה של מפרטי OpenAPI, מה שמפשט את התיעוד ואת שילוב הלקוחות. אתם יכולים להשתמש ב-Cloud Endpoints כדי לנהל את הגישה לממשקי API פנימיים או מבוקרים של AI ו-ML, למשל כדי להפעיל אימון ולנהל מאגרי תכונות.
  • ‫Apigee: ל-AI ול-ML ברמת הארגון, במיוחד לממשקי API מתוחכמים של AI גנרטיבי,‏ Apigee מספק ניהול מתקדם ומקיף של API. שימוש ב-Apigee לאבטחה מתקדמת כמו הגנה מפני איומים ו-OAuth 2.0, לניהול תנועת גולשים כמו שמירת נתונים במטמון, מכסות וגישור, ולניתוח נתונים. ‫Apigee יכול לעזור לכם לקבל תובנות מעמיקות לגבי דפוסי השימוש ב-API, הביצועים והמעורבות, שהן חיוניות להבנת השימוש ב-API של AI גנרטיבי.

תכנון של הפחתה חיננית (graceful degradation)

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

בקטעים הבאים מתוארות טכניקות שבהן אפשר להשתמש כדי לתכנן וליישם הפחתה חיננית (graceful degradation).

בידוד תקלות

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

יתירות רכיבים

לרכיבים קריטיים, כדאי להטמיע יתירות ומעבר אוטומטי לגיבוי. לדוגמה, אפשר להשתמש באשכולות של GKE במספר אזורים או באשכולות אזוריים ולפרוס שירותי Cloud Run ביתירות באזורים שונים. כדי לנתב תנועה למופעים תקינים כשמזוהים מופעים לא תקינים, צריך להשתמש ב-Cloud Load Balancing.

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

מעקב יזום

הפחתה חיננית (graceful degradation) עוזרת להבטיח את זמינות המערכת בזמן כשל, אבל צריך גם ליישם אמצעים פרואקטיביים לבדיקות תקינות רציפות ולניטור מקיף. איסוף מדדים שספציפיים ל-AI ול-ML, כמו זמן אחזור, קצב העברת נתונים וניצול GPU. בנוסף, אפשר לאסוף מדדים של ירידה בביצועי המודל, כמו סחף של מודלים ונתונים, באמצעות Cloud Monitoring וModel Monitoring בפלטפורמת הסוכנים של Gemini Enterprise.

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

שיטות SRE

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

פיתוח פלטפורמת MLOps אוטומטית מקצה לקצה

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

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

כדי לבנות פלטפורמת MLOps אוטומטית מקצה לקצה, כדאי לפעול לפי ההמלצות הבאות.

אוטומציה של מחזור החיים של פיתוח המודל

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

  • שימוש ב-Agent Platform Pipelines בתור כלי מרכזי לניהול תהליכים:
    • הגדרת תהליכי עבודה מקצה לקצה עם רכיבים מודולריים לעיבוד נתונים, לאימון, להערכה ולפריסה.
    • אפשר להגדיר הפעלות אוטומטיות של צינורות עיבוד נתונים באמצעות לוחות זמנים או טריגרים כמו נתונים חדשים או שינויים בקוד.
    • הטמעת פרמטריזציה אוטומטית וניהול גרסאות לכל הפעלה של צינור לעיבוד נתונים, ויצירת היסטוריית גרסאות.
    • מעקב אחרי התקדמות צינור עיבוד הנתונים וניצול המשאבים באמצעות רישום ביומן ומעקב מובנים, ושילוב עם התראות של Cloud Monitoring.
  • הגדרת צינורות ML באופן פרוגרמטי באמצעות Kubeflow Pipelines (KFP) SDK או TensorFlow Extended SDK. מידע נוסף זמין במאמר בנושא ממשקים לצינורות של Agent Platform.
  • תזמור פעולות באמצעות Google Cloud שירותים כמו Dataflow, אימון מותאם אישית ב-Agent Platform, מרשם המודלים ב-Gemini Enterprise Agent Platform ונקודות קצה של Agent Platform.
  • בתהליכי עבודה של AI גנרטיבי, צריך לתזמן את השלבים לניהול הנחיות, להסקת מסקנות באצווה, להערכה של HITL ולתיאום של רכיבי ADK.

ניהול התשתית כקוד

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

כדי לנהל ביעילות את משאבי התשתית כקוד, כדאי להשתמש בטכניקות הבאות.

הקצאת משאבים אוטומטית

כדי לנהל ביעילות את ה-IaC ב- Google Cloud, צריך להגדיר ולהקצות את משאבי התשתית של ה-AI ולמידת המכונה באמצעות Terraform. התשתית עשויה לכלול משאבים כמו:

  • אשכולות GKE שמוגדרים עם מאגרי צמתים. אפשר לבצע אופטימיזציה של מאגרי הצמתים בהתאם לדרישות של עומס העבודה. לדוגמה, אפשר להשתמש במעבדי GPU מסוג A100,‏ H100,‏ H200 או B200 לאימון, ובמעבדי GPU מסוג L4 להסקת מסקנות.
  • נקודות קצה של Agent Platform שמוגדרות לפרסום המודל, עם סוגי מכונות ומדיניות התאמה לעומס מוגדרים.
  • קטגוריות של Cloud Storage לנתונים ולארטיפקטים.

שימוש בתבניות הגדרה

ארגון ההגדרות של Terraform כתבניות מודולריות. כדי להאיץ את הקצאת המשאבים של AI ולמידת מכונה, אפשר להשתמש ב-Cluster Toolkit. ערכת הכלים מספקת תבניות לדוגמה, שהן תבניות Terraform שאצורות על ידי Google, שבעזרתן אפשר לפרוס אשכולות HPC, ‏ AI ו-ML מוכנים לשימוש ב-Slurm או ב-GKE. אפשר להתאים אישית את קוד Terraform ולנהל אותו במערכת לניהול גרסאות. כדי לבצע אוטומציה של תהליך העבודה של הקצאת משאבים ועדכון, אפשר לשלב את הקוד בצינורות עיבוד הנתונים של CI/CD באמצעות Cloud Build.

אוטומציה של שינויים בהגדרות

אחרי שמקצים את התשתית, מנהלים את השינויים השוטפים בהגדרות באופן הצהרתי:

  • בסביבות שמתמקדות ב-Kubernetes, אפשר לנהל את המשאבים ב- Google Cloudכאובייקטים של Kubernetes באמצעות Config Connector.
  • הגדרת משאבים של Agent Platform וניהול שלהם, כמו מערכי נתונים, מודלים ונקודות קצה, מופעי Cloud SQL, נושאים ב-Pub/Sub וקטגוריות ב-Cloud Storage באמצעות מניפסטים של YAML.
  • פורסים את קובצי המניפסט באשכול GKE כדי לשלב את הגדרות האפליקציה והתשתית.
  • אפשר להשתמש בפייפליינים של CI/CD כדי לבצע אוטומציה של עדכוני הגדרות, ולהשתמש בתבניות כדי לטפל בהבדלים בין סביבות.
  • הטמעה של הגדרות למדיניות ניהול זהויות והרשאות גישה (IAM) ולחשבונות שירות באמצעות IaC.

שילוב עם CI/CD

  • הפיכת מחזור החיים של משאבי התשתית לאוטומטי באמצעות שילוב של IaC בצינורות עיבוד נתונים של CI/CD, בעזרת כלים כמו Cloud Build וInfrastructure Manager. Google Cloud
  • הגדרת טריגרים לעדכונים אוטומטיים של קומיטים של קוד.
  • הטמעת בדיקות ואימות אוטומטיים בצינור. לדוגמה, אפשר ליצור סקריפט להרצה אוטומטית של הפקודות validate ו-plan של Terraform.
  • מאחסנים את ההגדרות כארטיפקטים ומפעילים את ניהול הגרסאות.
  • להגדיר סביבות נפרדות, כמו פיתוח, הכנה לייצור וייצור, עם הגדרות שונות בבקרת גרסאות, ולהפוך את קידום הסביבה לאוטומטי.

אימות ההתנהגות של המודל

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

  • הגדרת צינורות עיבוד נתונים לאימון רציף, שמופעלים על ידי נתונים חדשים ואותות מעקב כמו סחף נתונים, או שפועלים לפי לוח זמנים.
    • כדי לנהל משימות אימון אוטומטיות, כמו ניסויים של כוונון היפר-פרמטרים והגדרות של אימון מבוזר למודלים גדולים יותר, משתמשים באימון מותאם אישית ב-Agent Platform.
    • כדי לבצע כוונון עדין של מודלים בסיסיים, כדאי להפוך את תהליך הכוונון העדין לאוטומטי ולשלב את המשימות בצינורות הנתונים.
  • הטמעה של ניהול גרסאות אוטומטי של מודלים ואחסון מאובטח של ארטיפקטים של מודלים מאומנים אחרי כל הרצת אימון מוצלחת. אפשר לאחסן את הארטיפקטים ב-Cloud Storage או לרשום אותם ב-מרשם המודלים.
  • הגדירו מדדי הערכה וקבעו ספים ברורים, כמו דיוק מינימלי, שיעור שגיאות מקסימלי וציון F1 מינימלי.
    • מוודאים שהמודל עומד בסף הנדרש כדי לעבור את ההערכה באופן אוטומטי ולהיחשב כמתאים לפריסה.
    • אפשר להפוך את ההערכה לאוטומטית באמצעות שירותים כמו הערכת מודלים ב-Agent Platform.
    • חשוב לוודא שההערכה כוללת מדדים שספציפיים לאיכות הפלט שנוצר, לדיוק העובדתי, למאפייני הבטיחות ולעמידה בסגנון או בפורמט שצוינו.
  • כדי לרשום ולעקוב באופן אוטומטי אחרי הפרמטרים, גרסאות הקוד, גרסאות מערך הנתונים והתוצאות של כל הרצה של אימון והערכה, משתמשים בExperiments on Gemini Enterprise Agent Platform. הגישה הזו מספקת היסטוריה שימושית להשוואה, לניפוי באגים ולשחזור.
  • כדי לבצע אופטימיזציה של כוונון היפר-פרמטרים ולהפוך את החיפוש אחר תצורות מודל אופטימליות לאוטומטי בהתבסס על היעד שהגדרתם, אתם יכולים להשתמש ב-Vertex AI Vizier.
  • כדי להציג באופן חזותי את מדדי האימון ולבצע ניפוי באגים במהלך הפיתוח, משתמשים ב-Vertex AI TensorBoard.

אימות של קלטים ופלטים של צינורות עיבוד נתונים של AI ו-ML

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

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

איך מבצעים אימות נתונים אוטומטי

  • להטמיע אימות נתונים אוטומטי בצינורות העיבוד להטמעת נתונים ובצינורות העיבוד המקדים באמצעות TensorFlow Data Validation (TFDV).
    • לביצוע בדיקות איכות נתונים מבוססות-SQL בקנה מידה גדול, כדאי להשתמש בשירותי עיבוד נתונים ניתנים להרחבה כמו BigQuery.
    • כדי לבצע אימות מורכב ותכנותי של נתונים באצווה או בסטרימינג, צריך להשתמש ב-Dataflow.
  • מעקב אחרי התפלגות הנתונים לאורך זמן באמצעות היכולות של TFDV.
    • אפשר להשתמש בכלים שמשולבים עם Cloud Monitoring כדי להציג מגמות בתצוגה חזותית ולזהות סחף נתונים. אתם יכולים להגדיר הפעלה אוטומטית של צינורות (pipelines) לאימון מחדש של מודלים, כשדפוסי הנתונים משתנים באופן משמעותי.
  • אחסון של תוצאות האימות ומדדים ב-BigQuery לצורך ניתוח, מעקב היסטורי וארכיון של פריטי אימות ב-Cloud Storage.

אימות ההגדרות של צינור הנתונים ונתוני הקלט

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

  • כדי להגדיר סכימות ברורות לקובצי ההגדרות כמו YAML או JSON, אפשר להשתמש בספריות לאימות סכימות כמו jsonschema ל-Python. לפני שמתחילים להריץ צינור ולפני שמפעילים רכיב, צריך לאמת את אובייקטי ההגדרה מול הסכימות האלה.
  • כדי להטמיע אימות של קלט לכל הארגומנטים של שורת הפקודה ולכל הפרמטרים של צינור עיבוד הנתונים, צריך להשתמש בספריות לניתוח ארגומנטים כמו argparse. באימות צריך לבדוק את סוגי הנתונים הנכונים, את הערכים התקינים ואת הארגומנטים הנדרשים.
  • במסגרת Agent Platform Pipelines, מגדירים את הסוגים והמאפיינים הצפויים של פרמטרים של רכיבים באמצעות תכונות מובנות של אימות קלט של רכיבים.
  • כדי להבטיח שניתן יהיה לשחזר את ההרצות של צינורות העיבוד ולשמור על נתיב ביקורת, כדאי לאחסן קובצי הגדרה מאומתים עם ניהול גרסאות ב-Cloud Storage או ב-Artifact Registry.

אימות של קובצי קלט ופלט

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

  • אפשר להשתמש בספריות כדי לאמת פורמטים של קבצים כמו CSV‏, Parquet וסוגי תמונות.
  • כדי לזהות קבצים פגומים או העברות לא מלאות של קבצים גדולים או של ארטיפקטים קריטיים, אפשר לאמת את גודל הקבצים ואת סכומי הביקורת שלהם באמצעות אימות נתונים וזיהוי שינויים ב-Cloud Storage.
  • אפשר לבצע אימות של קובץ באמצעות פונקציות Cloud Run (לדוגמה, על סמך אירועים של העלאת קבצים) או בתוך צינורות של Dataflow.
  • אחסון תוצאות האימות ב-BigQuery כדי לאחזר ולנתח אותן בקלות.

אוטומציה של פריסה והטמעה של ניטור רציף

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

ניהול גרסאות המודלים

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

  • כדי לעקוב אחרי גרסאות של מודלים ומטא-נתונים ולקשר לארטיפקטים של מודלים בסיסיים, משתמשים במרשם המודלים.
  • הטמעת תוכנית ברורה לניהול גרסאות (למשל, ניהול גרסאות סמנטי). לכל גרסת מודל, צריך לצרף מטא-נתונים מקיפים כמו פרמטרים של אימון, מדדי הערכה מצינורות אימות וגרסת מערך הנתונים.
  • מאחסנים ארטיפקטים של מודלים, כמו קובצי מודלים, משקלים שאומנו מראש וקובצי אימג' של קונטיינרים להצגת מודלים ב-Artifact Registry, ומשתמשים בתכונות של ניהול גרסאות ותיוג.
  • כדי לעמוד בדרישות האבטחה והניהול, צריך להגדיר מדיניות מחמירה של בקרת גישה למרשם המודלים ול-Artifact Registry.
  • כדי לרשום ולנהל גרסאות באופן פרוגרמטי ולשלב גרסאות בפייפליינים אוטומטיים של CI/CD, צריך להשתמש ב-Agent Platform SDK או ב-API.

ביצוע פריסה מבוקרת

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

  • אפשר להטמיע פריסה מדורגת באמצעות התכונה 'פיצול תנועה' של נקודות קצה ב-Agent Platform.
  • אם פורסים את המודל ב-GKE, כדאי להשתמש בטכניקות מתקדמות לניהול תעבורת נתונים כמו פריסה של גרסה ראשונית (canary):
    1. הפניית תת-קבוצה קטנה של תנועת הייצור לגרסה חדשה של המודל.
    2. עוקבים אחרי הביצועים ושיעורי השגיאות באופן שוטף באמצעות מדדים.
    3. לוודא שהמודל מהימן.
    4. השקת הגרסה לכל התנועה.
  • עורכים בדיקות A/B של סוכני AI:
    1. פריסת שתי גרסאות שונות של סוכן מודל או מודלים שונים לחלוטין באותה נקודת קצה.
    2. פיצול התנועה בין הפריסות.
    3. ניתוח התוצאות בהשוואה ליעדים העסקיים.
  • כדאי להטמיע מנגנונים אוטומטיים להחזרה למצב הקודם, שיכולים להחזיר במהירות את התנועה בנקודת הקצה לגרסה קודמת ויציבה של המודל אם מופעלות התראות מהמעקב או אם לא מתקיימים ספי ביצועים.
  • אפשר להגדיר את חלוקת התנועה והגדרות הפריסה באופן פרוגרמטי באמצעות Agent Platform SDK או API.
  • שימוש ב-Cloud Monitoring כדי לעקוב אחרי הביצועים והתנועה בגרסאות השונות.
  • אוטומציה של פריסה באמצעות צינורות עיבוד נתונים של CI/CD. אפשר להשתמש ב-Cloud Build כדי ליצור קונטיינרים, ארטיפקטים של גרסאות ולהפעיל פריסה לנקודות קצה של Agent Platform.
  • מוודאים שצינורות ה-CI/CD מנהלים גרסאות ושולפים מ-Artifact Registry.
  • לפני שמעבירים את התנועה, מבצעים בדיקה אוטומטית של נקודת הקצה כדי לוודא שהתחזית נכונה, שהחביון נמוך, שהתפוקה גבוהה ושהפונקציה של ה-API תקינה.
  • אחסון כל ההגדרות בניהול גרסאות.

מעקב רציף

  • אפשר להשתמש במעקב אחרי מודלים ב-Agent Platform כדי לזהות באופן אוטומטי ירידה בביצועים, סחף נתונים (שינויים בהתפלגות הקלט בהשוואה לאימון) וסחף תחזיות (שינויים בפלט של המודל).
    • הגדרת משימות לזיהוי סחף עם ספים והתראות.
    • מעקב אחרי הביצועים בזמן אמת: זמן האחזור של החיזוי, התפוקה, שיעורי השגיאות.
  • הגדרת מדדים מותאמים אישית ב-Cloud Monitoring למדדי KPI עסקיים.
  • שילוב של מעקב אחרי מודלים בתוצאות של Agent Platform ובמדדים מותאמים אישית עם Cloud Monitoring לצורך התראות ומרכזי בקרה.
  • הגדרת ערוצי התראות כמו אימייל, Slack או PagerDuty והגדרת תיקון אוטומטי.
  • כדי לנפות באגים ביומני התחזיות, משתמשים ב-Cloud Logging.
  • שילוב של מעקב עם ניהול אירועי אבטחה.

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

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

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

שמירה על אמון ושליטה באמצעות ניהול נתונים ומודלים

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

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

יצירת קטלוגים של נתונים ומודלים לצורך מעקב

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

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

  • אפשר ליצור קטלוג של נכסי הנתונים בכל הארגון באמצעות Knowledge Catalog. כדי לגלות באופן אוטומטי את נכסי הנתונים ולבנות מלאי שלהם, משלבים את Knowledge Catalog עם מערכות האחסון, כמו BigQuery,‏ Cloud Storage ו-Pub/Sub.
  • כדי לוודא שהנתונים זמינים ועמידים, כדאי לאחסן אותם בקטגוריות של Cloud Storage שמוגדרות למספר אזורים או לשני אזורים. הנתונים שמעלים לקטגוריות האלה מאוחסנים ביתירות בשני מיקומים גיאוגרפיים נפרדים לפחות. היתירות הזו מספקת חוסן מובנה מפני הפסקות חשמל אזוריות, ועוזרת להבטיח את תקינות הנתונים.
  • תייגו את מערכי הנתונים והוסיפו להם הערות עם מטא-נתונים עסקיים רלוונטיים, פרטי בעלות, רמות רגישות ופרטי שושלת נתונים. לדוגמה, אפשר לקשר מערך נתונים מעובד למקור הגולמי שלו ולצינור (pipeline) שיצר את מערך הנתונים.
  • כדי ליצור מאגר מרכזי של גרסאות מודלים, משתמשים ב-מרשם המודלים. רושמים כל גרסה של מודל שאומן ומקשרים אותה למטא-נתונים המשויכים. המטא-נתונים יכולים לכלול את הפרטים הבאים:
    • פרמטרים של אימון.
    • מדדי הערכה מצינורות אימות.
    • גרסת מערך הנתונים ששימשה לאימון, עם שיוך שחוזר אחורה לרשומה הרלוונטית ב-Knowledge Catalog.
    • גרסת הקוד שיצרה את מערך הנתונים.
    • פרטים על המסגרת או מודל הבסיס שנעשה בהם שימוש.
  • לפני שמייבאים מודל ל-Model Registry, צריך לאחסן ארטיפקטים של מודלים, כמו קובצי מודלים ומשקלים שאומנו מראש, בשירות כמו Cloud Storage. אחסון תמונות של קונטיינרים בהתאמה אישית להצגה או למשימות אימון בהתאמה אישית במאגר מאובטח כמו Artifact Registry.
  • כדי לוודא שנכסי הנתונים והמודלים נרשמים ומתעדכנים באופן אוטומטי בקטלוגים המתאימים כשהם נוצרים או משתנים, צריך להטמיע תהליכים אוטומטיים בצינורות MLOps. הקטלוג המקיף הזה מספק מעקב מקצה לקצה מנתונים גולמיים ועד לתחזית, ומאפשר לכם לבדוק את הקלטים והתהליכים שהובילו לגרסה ספציפית של מודל או לתחזית מסוימת. יכולת הביקורת חיונית לניפוי באגים בהתנהגות לא צפויה, להבטחת תאימות למדיניות שימוש בחבילת הגלישה ולהבנת ההשפעה של שינויים בנתונים או במודל לאורך זמן.
  • במקרה של AI גנרטיבי ומודלים בסיסיים, הקטלוג צריך לכלול גם פרטים על המודל הבסיסי הספציפי שבו נעשה שימוש, פרמטרים של כוונון עדין ותוצאות הערכה שספציפיות לאיכות ולבטיחות של הפלט שנוצר.

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

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

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

חשוב להחיל מדיניות IAM באופן עקבי על כל הנכסים והמשאבים הרלוונטיים במערכות ה-AI וה-ML, כולל:

  • קטגוריות של Cloud Storage שמכילות מידע אישי רגיש או ארטיפקטים של מודלים.
  • מערכי נתונים ב-BigQuery.
  • משאבים של Agent Platform, כמו מאגרי מודלים, נקודות קצה, צינורות ומשאבים של Feature Store.
  • משאבי מחשוב, כמו אשכולות GKE ושירותי Cloud Run.

שימוש בביקורת וביומנים כדי לתעד, לעקוב ולנתח פעילות של גישה:

  • מפעילים את יומני הביקורת של Cloud לכל השירותים שבהם נעשה שימוש במערכת ה-AI וה-ML. Google Cloud
  • כדאי להגדיר יומני ביקורת כדי לתעד מידע מפורט על קריאות ל-API, על אירועי גישה לנתונים ועל שינויים בהגדרות שבוצעו במשאבים. עוקבים אחרי היומנים כדי לזהות פעילות חשודה, ניסיונות גישה לא מורשים או שינויים לא צפויים בנתונים קריטיים או בנכסי מודלים.
  • כדי לבצע ניתוח בזמן אמת, לקבל התראות ולהציג את הנתונים בתצוגה ויזואלית, אפשר להזרים את יומני הביקורת אל Cloud Logging.
  • כדי לאחסן את היומנים לטווח ארוך בצורה חסכונית ולנתח את האבטחה או לבצע ביקורות תאימות, אפשר לייצא את היומנים ל-BigQuery.
  • כדי לבצע ניטור אבטחה מרכזי, משלבים את יומני הביקורת עם מערכות לניהול אירועים ופרטי אבטחה (SIEM). חשוב לבדוק באופן קבוע את מדיניות הגישה ואת נתיבי הביקורת כדי לוודא שהם תואמים לדרישות השליטה והניהול שלכם, וכדי לזהות הפרות פוטנציאליות של המדיניות.
  • באפליקציות שמטפלות בנתונים רגישים, כמו פרטים אישיים מזהים (PII) לצורך אימון או הסקה, כדאי להשתמש בבדיקות של הגנה על נתונים רגישים בצינורות או באחסון נתונים.
  • בפתרונות גנרטיביים של AI ופתרונות מבוססי-סוכנים, כדאי להשתמש בנתיבי ביקורת כדי לעקוב אחרי מי ניגש למודלים או לכלים ספציפיים, אילו נתונים שימשו לכוונון עדין או ליצירת הנחיות, ואילו שאילתות נשלחו לנקודות קצה של ייצור. יומני הביקורת עוזרים לכם לוודא שיש אחריות על הנתונים, והם מספקים נתונים חשובים שיעזרו לכם לחקור שימוש לרעה בנתונים או הפרות מדיניות.

טיפול בהטיות, בשקיפות ובהסברים

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

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

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

  • כדי ליצור שיוכי תכונות למודלים טבלאיים שנפרסו בנקודות קצה של Agent Platform, צריך להשתמש ב-Vertex AI ניתן להסברה. שיוכי תכונות מציינים את תכונות הקלט שתורמות הכי הרבה לתחזית.
  • כדי לבחון באופן אינטראקטיבי את התנהגות המודל וההטיות הפוטנציאליות שלו במערך נתונים, אפשר להשתמש בכלים שמתאימים לכל המודלים, כמו What-If Tool, שמשולב ב-TensorBoard.
  • שילוב של הסברים בלוחות הבקרה שלכם למעקב. במצבים שבהם חשוב להבין את החשיבה הרציונלית של המודל כדי לבסס אמון או לקבל החלטות, כדאי לספק נתונים ליכולת הסברה ישירות למשתמשי הקצה דרך ממשקי האפליקציה.
  • למודלים מורכבים כמו LLM שמשמשים למודלים של AI גנרטיבי, צריך להסביר את התהליך שהסוכן ביצע, למשל באמצעות יומני מעקב. יכולת הסברה של מודלים כאלה היא יחסית מאתגרת, אבל היא עדיין חיונית.
  • באפליקציות RAG, צריך לספק ציטוטים למידע שאוחזר. אפשר גם להשתמש בטכניקות כמו הנדסת הנחיות כדי להנחות את המודל לספק הסברים או להציג את שלבי הנימוק שלו.
  • כדי לזהות שינויים בהתנהגות המודל או בתפוקות שלו שעשויים להצביע על הטיות או על חוסר הוגנות, כדאי להטמיע מעקב רציף בסביבת הייצור. מגבלות של מודל המסמך, תרחישי שימוש מיועדים והטיות פוטנציאליות ידועות כחלק מהמטא-נתונים של המודל במאגר המודלים.

הטמעה של שיטות מקיפות לניראות (observability) ולאמינות של AI ו-ML

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

  • אימוץ עקרונות SRE.
  • הגדרת יעדי מהימנות ברורים.
  • מעקב אחר מדדים בשכבות שונות של המערכת.
  • התובנות מניראות (observability) עוזרות לכם לשפר באופן מתמשך את המערכת ולנהל אותה באופן פרואקטיבי.

כדי להטמיע שיטות הוליסטיות לניראות (observability) ולמהימנות של עומסי עבודה של AI ו-ML ב- Google Cloud, כדאי לפעול לפי ההמלצות הבאות.

הגדרת יעדי מהימנות ומדדים עסקיים

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

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

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

באימון של AI ו-ML, מדדי המהימנות יכולים לכלול את ניצול FLOPS של המודל (MFU), איטרציות לשנייה, טוקנים לשנייה וטוקנים לכל מכשיר.

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

דוגמאות ליעדי SLO:

  • 99.9% מקריאות ה-API צריכות להחזיר תגובה תקינה.
  • זמן האחזור של ההסקה במאיון ה-95 צריך להיות מתחת ל-300 אלפיות השנייה.
  • זמן התגובה הראשוני (TTFT) צריך להיות מתחת ל-500 אלפיות שנייה ב-99% מהבקשות.
  • שיעור הפלט המזיק צריך להיות נמוך מ-0.1%.

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

מעקב אחרי הביצועים של התשתית והאפליקציה

לעקוב אחרי מדדי התשתית בכל המשאבים שבהם נעשה שימוש במערכות ה-AI וה-ML. המדדים כוללים את השימוש במעבד (CPU,‏ GPU ו-TPU), השימוש בזיכרון, קצב העברת הנתונים והחביון ברשת וקלט/פלט (I/O) בדיסק. מעקב אחרי המדדים של סביבות מנוהלות כמו אימון והצגה של Gemini Enterprise Agent Platform ושל משאבים בניהול עצמי כמו צמתי GKE ומופעי Cloud Run.

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

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

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

  • איסוף, אחסון והצגה חזותית של מדדי התשתית והאפליקציה באמצעות Cloud Monitoring. אתם יכולים להשתמש במרכזי בקרה מוגדרים מראש לשירותי Google Cloud וליצור מרכזי בקרה בהתאמה אישית שמותאמים למדדי הביצועים הספציפיים ולתקינות התשתית של עומס העבודה שלכם.
  • אפשר לאסוף יומנים מפורטים מהאפליקציות שלכם מבוססות-AI ומלמידת מכונה, ומהתשתית הבסיסית באמצעות Cloud Logging. היומנים האלה חיוניים לפתרון בעיות ולניתוח ביצועים. הם מספקים הקשר לגבי אירועים ושגיאות.
  • אפשר להשתמש ב-Cloud Trace כדי לזהות בעיות שקשורות לזמני האחזור ולהבין את זרימות הבקשות בשירותי מיקרו מבוססי-AI ו-ML מבוזרים. היכולת הזו חשובה מאוד לניפוי באגים באינטראקציות מורכבות של סוכני שיחות או בצינורות הסקה מרובי רכיבים.
  • איתור צווארי בקבוק בביצועים בתוך בלוקים של פונקציות בקוד של אפליקציה באמצעות Cloud Profiler. זיהוי צווארי בקבוק בביצועים יכול לעזור לכם לייעל את השימוש במשאבים ואת זמן הביצוע.
  • אפשר לאסוף מדדים ספציפיים שקשורים למאיצים, כמו נתוני שימוש מפורטים ב-GPU לכל תהליך, שימוש בזיכרון לכל תהליך וטמפרטורה, באמצעות כלים כמו NVIDIA Data Center GPU Manager (DCGM).

הטמעה של ניראות (observability) של נתונים ומודלים

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

  • אפשר לעקוב אחרי קצב הטמעת הנתונים, נפחי הנתונים שעברו עיבוד וזמני האחזור של הטרנספורמציה באמצעות שירותים כמו Dataflow.
  • מעקב אחרי שיעורי ההצלחה והכישלון של משימות בצינורות MLOps, כולל צינורות שמנוהלים על ידי Agent Platform Pipelines.

חשוב לבצע הערכה רציפה של איכות הנתונים.

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

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

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

כדי לעקוב אחרי מדדי המודל, אפשר להשתמש ב-TensorBoard או ב-MLflow. כדי לבצע ניתוח מעמיק וליצור פרופיל לפתרון בעיות בביצועים, אפשר להשתמש ביצירת פרופיל של PyTorch XLA או ב-NVIDIA Nsight.

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

מחברים:

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

הקודם
אבטחה
הבא
הוזלת עלויות