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

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

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

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

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

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

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

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

  • צינורות לעיבוד נתונים: יצירת צינורות נתונים ב-Dataflow. מגדירים את צינורות הנתונים כך שישתמשו בתכונה התאמה אוטומטית לעומס (autoscaling) אופקית של Dataflow, שמתאימה באופן דינמי את מספר המופעים של העובדים על סמך ניצול המעבד, מקביליות צינורות הנתונים והנתונים שממתינים לעיבוד. אתם יכולים להגדיר פרמטרים של התאמה אוטומטית לעומס באמצעות אפשרויות של פייפליין כשאתם מפעילים משימות.
  • משימות אימון: אפשר להשתמש באימון מותאם אישית של Vertex AI כדי להפוך את שינוי הגודל של משימות האימון לאוטומטי. אפשר להגדיר מפרטים של מאגר worker, כמו סוג המכונה, הסוג והמספר של המאיצים ומספר מאגרי ה-worker. כדי להפחית את העלויות של משימות שיכולות לעמוד בהפרעות, ושל משימות שבהן קוד ההדרכה מיישם שמירת נקודות ביקורת, אפשר להשתמש במכונות Spot VM.
  • הסקת מסקנות אונליין: להסקת מסקנות אונליין, משתמשים בנקודות קצה (endpoints) של Vertex AI. כדי להפעיל את ההתאמה האוטומטית לעומס, צריך להגדיר את המספר המינימלי והמקסימלי של העותקים. כדי להגדיר זמינות גבוהה, צריך לציין לפחות שני עותקים משוכפלים. ‫Vertex AI מתאים אוטומטית את מספר הרפליקות על סמך תעבורת הנתונים ומדדי ההתאמה האוטומטית לעומס שהוגדרו, כמו ניצול מעבד (CPU) וניצול רפליקות.
  • עומסי עבודה בקונטיינרים ב-Google Kubernetes Engine: הגדרת התאמה אוטומטית לעומס ברמת הצומת וברמת ה-Pod. הגדרת מידרוג אוטומטי של האשכול והקצאת צמתים אוטומטית (NAP) כדי לשנות את מספר הצמתים על סמך בקשות למשאבי Pod בהמתנה, כמו CPU, זיכרון, GPU ו-TPU. שימוש ב-Horizontal Pod Autoscaler‏ (HPA) לפריסות כדי להגדיר מדיניות התאמה לעומס על סמך מדדים כמו ניצול CPU וזיכרון. אפשר גם לשנות את הגודל על סמך מדדי AI ו-ML מותאמים אישית, כמו ניצול GPU או TPU ובקשות חיזוי לשנייה.
  • שירותים מבוססי-קונטיינר ללא שרת: אפשר לפרוס את השירותים ב-Cloud Run ולהגדיר התאמה אוטומטית לעומס על ידי ציון מספר המינימום והמקסימום של מופעי הקונטיינר. אפשר להשתמש בשיטות מומלצות כדי להתאים אוטומטית את המופעים שמופעלים באמצעות GPU לעומס על ידי ציון סוג המאיץ. מערכת Cloud Run מתאימה אוטומטית את המופעים לעומס בין מגבלות המינימום והמקסימום שהוגדרו על סמך בקשות נכנסות. כשאין בקשות, המערכת מצמצמת את מספר המופעים לאפס. אפשר להשתמש בהתאמה האוטומטית לעומס של Cloud Run שמבוססת על בקשות כדי לפרוס סוכני Vertex AI ולפרוס עומסי עבודה של צד שלישי כמו מודלים שעברו קוונטיזציה באמצעות 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):

    • למשימות שדורשות עמידות בכשלים, כמו עומסי עבודה של הערכה וניסויים, כדאי להשתמש בVM במודל Spot. יכול להיות שתתבצע ל-VM במודל 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 ב-Vertex AI מסתיר את תשתית המחשוב המבוזר. הוא מאפשר לאפליקציות לבקש משאבים לאימון ולשימוש בלי צורך בניהול ישיר של מכונות וירטואליות וקונטיינרים.

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

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

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

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

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

שירותים מנוהלים של Vertex AI

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

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

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

לסוכני AI,‏ ערכה לפיתוח סוכנים (ADK) מספקת יכולות מודולריות כמו כלים ומצב. כדי לאפשר יכולת פעולה הדדית בין framework-ים כמו LangChain,‏ LangGraph,‏ LlamaIndex ו-Vertex AI, אפשר לשלב את ADK עם פרוטוקול A2A ועם Model Context Protocol‏ (MCP). יכולת הפעולה ההדדית הזו מאפשרת ליצור Agentic Workflows באמצעות רכיבים מגוונים.

אפשר לפרוס סוכנים ב-Vertex AI Agent Engine, שהוא סביבת זמן ריצה מנוהלת שעברה אופטימיזציה לפריסה של סוכנים שניתנת להרחבה. כדי להריץ סוכנים מבוססי-קונטיינר, אפשר להשתמש ביכולות של התאמה אוטומטית לעומס ב-Cloud Run.

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

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

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

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

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

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

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

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

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

  • ‫Vertex AI SDK מפשט את המשימות והאימות. משתמשים ב-SDK כשצריך ליצור אינטראקציה עם Vertex AI.
  • 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: ‫Apigee מספק ניהול מתקדם ומקיף של ממשקי API ל-AI ול-ML ברמת הארגון, במיוחד לממשקי API מתוחכמים של AI גנרטיבי. אפשר להשתמש ב-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.

מעקב יזום

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

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

שיטות SRE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • בסביבות שמתמקדות ב-Kubernetes, אפשר לנהל את המשאבים ב- Google Cloudכאובייקטים של Kubernetes באמצעות Config Connector.
  • הגדרה וניהול של משאבי Vertex AI כמו מערכי נתונים, מודלים ונקודות קצה, מכונות 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. האוטומציה הזו, בשילוב עם אימות קפדני, עוזרת להבטיח שהמודלים יתנהגו כמצופה עם נתונים רלוונטיים לפני הפריסה שלהם בסביבת הייצור.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מעקב רציף

  • אפשר להשתמש במעקב אחרי מודלים כדי לזהות באופן אוטומטי ירידה בביצועים, סחף נתונים (שינויים בהתפלגות הקלט בהשוואה לאימון) וסחף תחזיות (שינויים בפלט של המודל).
    • הגדרת משימות לזיהוי סחף עם ספים והתראות.
    • מעקב אחרי הביצועים בזמן אמת: זמן האחזור של התחזית, קצב העברת הנתונים, שיעורי השגיאות.
  • הגדרת מדדים מותאמים אישית ב-Cloud Monitoring למדדי KPI עסקיים.
  • שילוב של תוצאות המעקב אחרי מודלים ומדדים מותאמים אישית עם 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 שמוגדרות למספר אזורים או לשני אזורים. הנתונים שמעלים לקטגוריות האלה מאוחסנים ביתירות בשני מיקומים גיאוגרפיים נפרדים לפחות. היתירות הזו מספקת חוסן (resilience) מובנה מפני הפסקות זמניות בשירות אזוריות, ועוזרת להבטיח את תקינות הנתונים.
  • מתייגים ומבצעים הערות במערכי הנתונים עם מטא-נתונים עסקיים רלוונטיים, פרטי בעלות, רמות רגישות ופרטי שושלת. לדוגמה, מקשרים מערך נתונים שעבר עיבוד למקור הגולמי שלו ולצינור (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.
  • משאבי Vertex AI, כמו מאגרי מודלים, נקודות קצה, צינורות עיבוד נתונים ומשאבי Feature Store.
  • משאבי מחשוב, כמו אשכולות GKE ושירותי Cloud Run.

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

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

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

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

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

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

  • כדי ליצור שיוכי תכונות למודלים טבלאיים שנפרסו בנקודות קצה של Vertex AI, צריך להשתמש ב-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 ולמידת המכונה. ה-KPIs יכולים לכלול הכנסות שהושפעו מהמלצות מ-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%.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מחברים:

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

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