מדריך

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

→סביבת עבודה של Azure Machine Learning.

למה: זהו השירות הבסיסי המשלב את כל הרכיבים הנדרשים: compute, datastores, environments, מעקב אחר ניסויים, רישום מודלים, ו-endpoints.

מקור↗

דרישה שכל תעבורת סביבת העבודה של ML, כולל למשאבים תלויים כמו Storage ו-ACR, תישאר ברשת הפרטית של Azure ולא תיחשף לאינטרנט הציבורי.

→הגדרת סביבת העבודה של Azure ML עם רשת וירטואלית מנוהלת ושימוש ב-private endpoints עבור סביבת העבודה וכל המשאבים התלויים בה (Storage, Key Vault, ACR).

למה: Private endpoints מספקים קישוריות מאובטחת ופרטית לשירותי Azure, ומבטיחים שהתעבורה אינה עוברת דרך האינטרנט הציבורי. VNet מנוהלת מפשטת הגדרה זו עבור compute של ML.

מקור↗

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

→יצירת סביבת העבודה של Azure ML, כל חשבונות ה-Storage המשויכים לה ומשאבי ה-compute באזור בתוך הגיאוגרפיה הנדרשת. שימוש בבידוד רשתי כדי למנוע דליפת נתונים.

למה: משאבי Azure קשורים לאזור שבו הם נוצרו. זה מבטיח עמידה במיקום פיזי של הנתונים. בידוד רשתי (VNet מנוהלת) מונע עיבוד נתונים מחוץ לגבול זה.

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

→שימוש ב-Azure Policy ליישום ואכיפת כללים ליצירת משאבים ולקונפיגורציה.

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

מקור↗

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

→יצירת חיבור ה-datastore באמצעות אימות מבוסס זהות. הענקת הזהות המנוהלת של סביבת העבודה (או זהות המשתמש/compute) את תפקיד ה-RBAC המתאים (לדוגמה, Storage Blob Data Reader) בחשבון ה-storage.

למה: זהו דפוס נטול פרטי זיהוי, Zero-Trust, המשתמש ב-Azure AD לאימות, משפר אבטחה ומפשט את ניהול פרטי הזיהוי.

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

→יצירת סביבות עבודה נפרדות של Azure ML לכל גבול אבטחה. סביבת עבודה לפרויקטי PII צריכה להיות בעלת בידוד רשתי מחמיר יותר מאשר לפרויקטים שאינם רגישים.

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

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

→שימוש בסביבות עבודה נפרדות של Azure ML עבור סביבות פיתוח וייצור.

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

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

→שימוש ב-compute cluster של Azure ML עם VMs בעדיפות נמוכה, ספירת צמתים מינימלית של 0, ו-auto-scaling מוגדר.

למה: VMs בעדיפות נמוכה מספקים חיסכון משמעותי בעלויות עבור עומסי עבודה ניתנים להפסקה. מינימום של 0 צמתים מבטיח שלא תשלם כלום כאשר ה-cluster אינו פעיל.

מקור↗

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

→הקצאת Compute Instances לפיתוח אינטראקטיבי (אחד לכל משתמש). הקצאת Compute Clusters למשימות אימון אצווה.

למה: Compute Instances הם VMs חד-משתמשים וקבועים המותאמים לעבודה אינטראקטיבית. Compute Clusters הם משאבים מרובי צמתים עם auto-scaling המותאמים למשימות אצווה.

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

→הגדרת Azure ML Environment באמצעות קובץ YAML של סביבת conda או Dockerfile. רישום וניהול גרסאות של סביבה זו לשימוש במשימות אימון.

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

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

→שימוש ב-Azure ML Managed Feature Store כדי להגדיר, לחשב ולהגיש תכונות.

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

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

→שימוש ב-MLflow, המשולב באופן מובנה ב-Azure ML. הפעלת autologging או שימוש בפקודות `mlflow.log_*` מפורשות בסקריפט האימון.

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

מקור↗

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

→יישום טכניקות כמו SMOTE (Synthetic Minority Over-sampling Technique) על נתוני האימון. הערכת המודל באמצעות מדדים שאינם רגישים לחוסר איזון, כגון Precision-Recall AUC או F1-score.

למה: שימוש פשוט בדיוק (accuracy) מטעה. SMOTE יוצר דגימות מיעוט סינתטיות כדי לעזור למודל ללמוד, ו-PR-AUC/F1-score מודדים נכון את הביצועים על המחלקה החיובית.

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

→שימוש במשימת sweep עם Bayesian sampling ומדיניות סיום מוקדם (לדוגמה, Bandit או Median Stopping).

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

בניית מודל חיזוי סדרות זמן באמצעות AutoML.

→הגדרת משימת AutoML עם `task='forecasting'`, ציון ה-`time_column_name`, והגדרת ה-`forecast_horizon`.

למה: ציון המשימה כ-"forecasting" מאפשר ל-AutoML ליישם טכניקות ספציפיות לסדרות זמן כמו יצירת תכונות lagged, זיהוי עונתיות, ואימות צולב מודע לזמן.

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

→שימוש ב-compute cluster עם צמתים בעלי יכולת GPU. במשימת ה-command, הגדרת המאפיין `distribution` (לדוגמה, `type: "PyTorch"`, `process_count_per_instance: <# GPUs>`).

למה: Azure ML מפשט אימון מבוזר על ידי ניהול הגדרת הצמתים והתקשורת. תצורת ה-`distribution` אומרת ל-Azure ML כיצד להפעיל את תהליכי האימון המבוזרים.

מקור↗

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

→הגדרת pipeline של Azure ML באמצעות components לכל שלב. שימוש ב-pipeline inputs לפרמטריזציה של זרימת העבודה.

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

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

→זהו סימן קלאסי ל-overfitting. ניתן למתן על ידי יישום רגולריזציה (לדוגמה, dropout, L2), שימוש בהעשרת נתונים, יישום early stopping, או הפחתת מורכבות המודל.

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

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

→יישום checkpointing בתוך סקריפט האימון כדי לשמור באופן תקופתי את המודל ואת מצב ה-optimizer לתוך ספריית ה-`./outputs`.

למה: ספריית ה-`./outputs` נשמרת אוטומטית על ידי Azure ML. שמירת checkpoints מאפשרת למשימה להתחדש מהמצב השמור האחרון בעת דחיקה, משמרת התקדמות וחוסכת עלויות.

לארגון יש מדיניות שרק אלגוריתמים מסוימים של ML יכולים לשמש בייצור. יש צורך לאכוף זאת במהלך ריצות AutoML.

→בתצורת ה-AutoML, השתמשו בפרמטר `blocked_models` כדי להוציא במפורש אלגוריתמים לא מאושרים ממרחב החיפוש.

למה: זה מספק דרך ישירה וניתנת לאכיפה ליישור קו של AutoML עם מדיניות ממשל, ומונע בחירה של מודלים לא תואמים.

פריסת מודל לחיזויים בזמן אמת, עם לייטנסי נמוך (<100ms) וזמינות גבוהה.

→פריסת המודל ל-Azure ML Managed Online Endpoint.

למה: Managed online endpoints הם שירות מנוהל במלואו המותאם להסקה בזמן אמת, מספקים auto-scaling, איזון עומסים, פריסות blue-green, וניטור מובנה.

מקור↗

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

→פריסת המודל ל-Azure ML Batch Endpoint.

למה: Batch endpoints מיועדים לניקוד אסינכרוני ובעל תפוקה גבוהה של מערכי נתונים גדולים. הם יכולים להשתמש ב-compute clusters ניתנים להרחבה שיורדים לאפס כשהם אינם פעילים, ובכך מייעלים עלויות.

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

→שימוש ב-managed online endpoint יחיד עם שתי פריסות (לדוגמה, "blue" למודל הישן, "green" לחדש). שימוש ב-traffic splitting לשליטה באחוז הבקשות שעוברות לכל פריסה.

למה: דפוס פריסת blue-green זה מאפשר פריסות בטוחות וללא השבתה. ניתן לאמת את המודל החדש על חלק קטן מתעבורה חיה לפני התחייבות למעבר מלא.

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

→שימוש בפורמט מודל MLflow. בעת רישום המודל, יש לכלול את קובץ ה-conda.yaml או requirements.txt וכל חפצי קוד נחוצים.

למה: MLflow מספק מוסכמת אריזת מודל סטנדרטית ש-Azure ML מבין באופן מובנה. זה מפשט את הפריסה שכן Azure ML יכול לבנות אוטומטית את הסביבה הנדרשת.

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

→העברת לוגיקת טעינת הקבצים מפונקציית ה-`run()` לפונקציית ה-`init()` בסקריפט הניקוד.

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

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

→הגדרת auto-scaling בפריסת ה-managed online endpoint. הגדרת מספר מינימלי ומקסימלי של מופעים והגדרת כלל קנה מידה המבוסס על ניצול CPU או לייטנסי בקשות.

למה: Auto-scaling מתאים אוטומטית את מספר מופעי ה-compute כדי להתאים לעומס התעבורה, מבטיח ביצועים בשיאים וחוסך עלויות בשפל.

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

→יצירת Dockerfile מותאם אישית המרחיב תמונת הסקה בסיסית של Azure ML, הוספת התלויות הנדרשות, בנייתה ודחיפתה ל-Azure Container Registry. הפניה לתמונה זו בסביבת הפריסה.

למה: הרחבת תמונה בסיסית מספקת שליטה מלאה על סביבת הריצה תוך שמירה על תאימות לתשתית ההגשה של Azure ML.

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

→שימוש ב-Azure DevOps או GitHub Actions המשולבים עם Azure ML CLI v2 ליצירת pipeline של CI/CD. ה-pipeline צריך לכלול quality gate המשווה את המודל החדש ל-baseline לפני הפריסה.

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

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

→הגדרת Azure ML data drift monitor ב-endpoint. הגדרת התראה שמפעילה Azure Logic App או Azure Function, אשר בתורן מתחילות את pipeline האימון מחדש.

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

גרסת מודל חדשה שנפרסה נמצאה פגומה בייצור. יש צורך לחזור במהירות לגרסה היציבה הקודמת.

→אם משתמשים בפריסת blue-green, העבירו 100% מהתעבורה חזרה לפריסה היציבה. לחלופין, עדכנו את ה-endpoint לפרוס מחדש את גרסת המודל הקודמת מרישום המודלים.

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

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

→הפעלת שילוב Application Insights ב-endpoint עבור מדדים תפעוליים. הגדרת איסוף נתונים וניטור data drift של Azure ML עבור מדדי איכות המודל.

למה: גישה דו-כיוונית זו מספקת תצוגה מלאה של בריאות המודל. App Insights עוקב אחר ביצועי המערכת, בעוד איסוף נתונים/ניטור drift עוקבים אחר ביצועי החיזוי של המודל.

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

→יישום לוגיקת אימות קלט בתוך פונקציית ה-`run()` של סקריפט הניקוד. בדיקת סוגי נתונים, טווחים ומבנים, והחזרת שגיאה משמעותית (לדוגמה, HTTP 400) עבור בקשות לא חוקיות.

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

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

→שימוש ב-Responsible AI dashboard ב-Azure ML ליצירת הסברים למודל. שימוש ב-SHAP להסברים מקומיים (חיזוי בודד) וחשיבות תכונות גלובלית להתנהגות המודל הכוללת.

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

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

→שימוש בהערכת הוגנות של Responsible AI dashboard לניתוח מדדי הוגנות (לדוגמה, demographic parity, equalized odds) על פני תכונות רגישות. יישום טכניקות מיתון כמו התאמות סף לאחר עיבוד אם נמצאו פערים.

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

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

→יישום דפוס Retrieval-Augmented Generation (RAG). שימוש ב-Azure AI Search ליצירת אינדקס וקטורי של המסמכים. בזמן השאילתה, אחזור פיסות מסמכים רלוונטיות והעברתן ל-LLM כהקשר ב-prompt.

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

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

→שימוש בהנדסת prompt של מערכת מפורטת. מתן פרסונה ברורה, כללים ומגבלות מפורשים, ודוגמאות few-shot של זוגות קלט/פלט רצויים.

למה: prompt מערכת מתוכנן היטב הוא הדרך הישירה והיעילה ביותר לכוון את התנהגות ה-LLM ללא העלות והמורכבות של fine-tuning.

צורך למדוד את איכות יישום LLM מבוסס RAG.

→שימוש במדדי הערכה ספציפיים ל-RAG, כגון Groundedness (האם התשובה נתמכת על ידי ההקשר?) ו-Relevance (האם התשובה עונה על שאלת המשתמש?).

למה: מדדי NLP סטנדרטיים כמו ROUGE אינם מספיקים. Groundedness ו-Relevance מודדים ישירות את האתגרים המרכזיים של RAG: מניעת הזיה ומתן תשובות שימושיות.

יישום LLM איטי מדי או יקר מדי לשימוש בייצור.

→יישום router לשימוש במודלים קטנים וזולים יותר (לדוגמה, GPT-3.5-Turbo) למשימות פשוטות. הפעלת response caching לשאילתות חוזרות. אופטימיזציה של אורך ה-prompt.

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

יישום LLM מעבד נתונים רגישים שאסור להם לעזוב את הרשת הארגונית או לשמש לאימון מודלים.

→פריסת שירות Azure OpenAI עם private endpoint. הגדרת המשאב שלא יתעד נתוני prompt/completion.

למה: Private endpoints מבטיחים בידוד רשתי. אפשרות אי-רישום (no-logging) מספקת שכבה נוספת של פרטיות נתונים, ועומדת בדרישות ציות מחמירות.

prompt flow שפותח ב-Azure AI Studio צריך להיפרס כ-endpoint ייצור זמין וניתן להרחבה.

→פריסת ה-prompt flow כ-Azure ML Managed Online Endpoint.

למה: זה מספק נתיב חלק מפיתוח לייצור, תוך ניצול אותה תשתית חזקה (auto-scaling, load balancing, monitoring) המשמשת למודלי ML מסורתיים.

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

→שימוש הן במסנני התוכן המובנים של Azure OpenAI והן בשירות Azure AI Content Safety למיתון עומק של prompts ו-completions.

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

chatbot AI שיחתי צריך לשמור על הקשר לאורך מספר פניות של המשתמש.

→מודלי LLM הם חסרי מצב (stateless). היישום חייב לנהל את היסטוריית השיחה (לדוגמה, ב-session או במסד נתונים) ולכלול חלקים רלוונטיים מההיסטוריה בכל prompt חדש ל-LLM.

למה: מתן הקשר מפורש בכל קריאת API הוא הדרך היחידה למודל LLM חסר מצב "לזכור" את השיחה.

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

→שימוש ב-prompt flow Variants. הגדרת מספר גרסאות prompt עבור צומת והרצת בדיקת אצווה מול מערך נתוני הערכה כדי להשוות מדדי ביצועים.

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

צורך לנטר יישום LLM בייצור הן לבריאות תפעולית והן לאיכות תגובה.

→שילוב Application Insights עבור טלמטריה תפעולית (לייטנסי, שיעורי שגיאות, שימוש באסימונים) עם משימות הערכת אצווה תקופתיות באמצעות flow הערכה כדי להעריך את איכות התגובה (groundedness, relevance).

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