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

Last reviewed 2026-10-29 UTC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • בצמתים של GKE ובמכונות וירטואליות של Compute Engine, השתמשו ביכולות של VM במודל Spot ושל מתזמן משימות לפריסת workload דינמית (DWS):

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

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

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

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

חלוקת התנועה הנכנסת בין כמה מכונות

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

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

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

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

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

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

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

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

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

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

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

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

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

למשימות מבוססות-אירועים שיכולות להפיק תועלת מהתאמה אוטומטית לעומס (automatic scaling) בלי שרת (serverless), השתמשו ב-Cloud Run או בפונקציות Cloud Run. השירותים האלה מתאימים למשימות אסינכרוניות כמו עיבוד מקדים או למשימות הסקה קטנות יותר. להפעיל פונקציות Cloud Run באירועים, כמו קובץ נתונים חדש שנוצר ב-Cloud Storage או עדכוני מודלים ב-Artifact Registry. למשימות או לשירותים של לפעולות לפיתוח API (webhook) שצריכים סביבת קונטיינר, השתמשו ב-Cloud Run.

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

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

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

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

אפליקציות מבוססות-סוכנים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בידוד תקלות

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

יתירות של רכיבים

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

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

מעקב יזום

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

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

שיטות SRE

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

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

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

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

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

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

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

  • משתמשים ב-Agent Platform Pipelines בתור כלי הניהול המרכזי:
    • להגדיר תהליכי עבודה מקצה לקצה עם רכיבים מודולריים לעיבוד נתונים, לאימון, להערכה ולפריסה.
    • להפעיל אוטומטית את צינורות עיבוד הנתונים באמצעות לוחות זמנים או טריגרים, כמו נתונים חדשים או שינויים בקוד.
    • להטמיע פרמטריזציה וניהול גרסאות אוטומטיים לכל הרצה של צינור עיבוד נתונים, וליצור היסטוריית גרסאות.
    • מעקב אחרי ההתקדמות של צינור עיבוד הנתונים והשימוש במשאבים באמצעות רישום ביומן ומעקב מובנים, ושילוב עם התראות מעקב.
  • מגדירים את צינורות ה-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 ו-Cloud TPU. בעזרת IaC אפשר לצמצם את הסיכונים בניהול ידני של התשתית, כי הוא מבטיח עקביות, מאפשר החזרות למצב קודם והופך את הפריסות לניתנות לחזרה.

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

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

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

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

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

לארגן את ההגדרות של Terraform כתבניות מודולריות. כדי להאיץ את הקצאת המשאבים של AI ו-ML, אתם יכולים להשתמש ב-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

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

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

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

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

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

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

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

אימות נתונים אוטומטי

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

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

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

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

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

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

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

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

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

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

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

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

פריסה מבוקרת

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

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

מעקב רציף

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

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

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

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

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

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

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

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

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

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

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

הטמעת בקרת גישה חזקה ונתיבי ביקורת

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

זהו את מדדי הביצועים המרכזיים (KPI) שמושפעים ישירות ממערכת ה-AI וה-ML שלכם. מדדי ה-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 ו-Cloud TPU), שימוש בזיכרון, תפוקת הרשת והזמן שלה, וקלט/פלט (I/O) בדיסק. מעקב אחרי המדדים של סביבות מנוהלות, כמו אימון והצגה של Agent Platform, ושל משאבים בניהול עצמי, כמו צומתי GKE ומכונות Cloud Run.

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

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

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

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

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

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

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

חשוב לבדוק באופן קבוע את איכות הנתונים.

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

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

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

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

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

מחברים:

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

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