MLOps, Deploy ו-Monitor מודלים | בית הספר של Claude

למה מודל שעובד ב-test נופל ב-production?

חברת fintech ישראלית בנתה מודל לזיהוי הונאות עם accuracy של 94% ב-test set. שישה חודשים אחרי הפריסה, accuracy ירד ל-71%. איש לא שם לב עד שלקוחות התחילו להתלונן. הסיבה: data drift. דפוסי ההונאה השתנו, המודל לא עודכן, ואף אחד לא הגדיר monitoring.

לפי Gartner, 85% מפרויקטי AI נכשלים להגיע ל-production או מדרדרים משמעותית אחרי פריסה. זו לא בעיה של מודל גרוע, זו בעיה של תשתית לא בשלה. MLOps הוא הדיסציפלינה שסוגרת את הפער בין "עובד ב-notebook" לבין "עובד בproduction ב-12 חודשים מהיום".

Claude יכול לעזור בכל שלב: לתכנן serving architecture, לכתוב monitoring scripts, לתכנן CI/CD ל-ML, ולדקר holes בתוכנית שלך לפני שproduction יעשה את זה. בשיעור זה נכסה את הנושאים הקריטיים עם prompts מוכנים.

שלב 1: Model Serving, הגשת מודל לproduction

Serving הוא הצעד הראשון: כיצד חושפים מודל לבקשות real-time. אפשרויות נפוצות:

Framework	מתאים ל	יתרון עיקרי	חיסרון
FastAPI + Uvicorn	מודלים מבוססי Python (XGBoost, scikit-learn)	גמישות מלאה, קל לתחזוקה	צריך לבנות הכל ידנית
BentoML	ML models + APIs	packaging מובנה, Batch support	עקומת למידה
TorchServe	PyTorch models בלבד	אופטימיזציה ל-PyTorch	ספציפי ל-framework
Ray Serve	scale גבוה, multi-model	distributed serving מובנה	complexity גבוה

פרומפט לתכנון serving:

אתה MLOps engineer עם ניסיון בproduction ML systems.
תכנן serving infrastructure לחברת ביטוח ישראלית:

מפרט:
- מודל: XGBoost לסיווג תביעות ביטוח (legit/fraud)
- Model size: 80MB
- עסקאות: 300 לשניה, peak: 800 לשניה
- Latency SLA: p99 < 150ms
- Availability: 99.9%
- Rollback נדרש: תוך 60 שניות

ספק:
1. FastAPI endpoint עם Pydantic validation, feature preprocessing,
   prediction + confidence score, ו-structured request/response logging
2. Kubernetes deployment.yaml עם HPA (min 2, max 15),
   resource limits, liveness + readiness probes
3. Blue-Green deployment strategy לzero-downtime updates
4. Circuit breaker pattern למניעת cascading failures

שימו לב: הפרומפט מציין latency SLA ספציפי, scale מדויק, ו-availability target. בלי מספרים כאלה, Claude מייצר architecture גנרי שלא מתאים לcase.

שלב 2: Monitoring ו-Drift Detection, מה שמבדיל production מ-demo

לפי מחקר 2025: מודלים ללא monitoring שנשארו בproduction 6+ חודשים ראו קפיצה של 35% בשגיאות. הבעיה: infrastructure metrics (CPU, latency, errors) נשארים ירוקים בזמן שביצועי המודל מדרדרים בשקט.

שלושה סוגי drift שצריך לנטר:

Data Drift, distribution של input features משתנה. דוגמה: מודל אשראי אומן על לקוחות גיל 25-45, אבל עכשיו מגיעים יותר לקוחות גיל 55+. PSI (Population Stability Index) מכמת את גודל השינוי, PSI < 0.1 יציב, PSI > 0.2 דורש retraining.
Concept Drift, הקשר בין features לoutcome משתנה. דוגמה: אחרי אוקטובר 2023, דפוסי תשלום בישראל השתנו, מודלים שאומנו לפני לא הצליחו לזהות הונאות חדשות.
Prediction Drift, distribution של outputs משתנה למרות שinputs נראים זהים. לרוב סימן לbug בpipeline.

כתוב Python DataDriftDetector class:

ממש:
1. calculate_psi(baseline_df, current_df, feature_cols) -> dict
   - PSI לכל feature
   - flag אם PSI > 0.2
2. generate_drift_report(psi_results) -> dict
   - features שדורשות תשומת לב
   - המלצה: monitor / investigate / retrain
3. send_slack_alert(webhook_url, report) -> bool
4. main() שרץ כל שעה דרך cron,
   מייצא Prometheus metrics,
   ושומר logs בJSON structured format

כלול unit tests עם fake data ו-example usage

איך עושים model monitoring?

אתה MLOps engineer. יש לי sentiment analysis model בproduction על ביקורות לקוחות בעברית ואנגלית, 8,000 predictions/day. יש לי baseline stats משמירה ביום האימון. כתוב Python monitoring system שמחשב PSI לכל input feature, מזהה prediction drift, שולח Slack alert כשPSI > 0.2, ויוצר Prometheus metrics. הוסף unit tests עם synthetic data.

שלב 3: CI/CD ל-ML, שונה מ-DevOps רגיל

ב-software רגיל CI/CD בודק קוד. ב-ML, הצינור צריך לבדוק גם את המודל עצמו, accuracy, fairness, latency. זה ה-pipeline שClude יכול לתכנן עבורך:

תכנן GitHub Actions ML CI/CD pipeline לפרויקט Python/XGBoost:

שלבים נדרשים:
1. code_quality: pytest, flake8, mypy type checking
2. data_validation: great_expectations על training data
   - אפס null values בfeatures קריטיות
   - distributions בטווח היסטורי
3. model_training: DVC pipeline, versioning עם MLflow
4. model_evaluation:
   - AUC >= baseline (threshold: 0.90)
   - Fairness check: accuracy gap < 5% בין segments
   - Latency test: p99 < 200ms תחת 100 concurrent requests
5. staging_deploy: canary deployment (10% traffic)
6. smoke_tests: integration tests על staging
7. production_deploy: blue-green אם staging עובר 24 שעות

כלול: rollback trigger אוטומטי אם accuracy יורד > 5%

הצעד החשוב ביותר שרוב הצוותים מדלגים עליו: fairness check בשלב 4. בישראל, מודלים לאשראי, ביטוח, וגיוס עובדים כפופים לחוקי אנטי-אפליה, CI/CD שמוסיף fairness gate הוא לא רק טכני, הוא משפטי.

שלב 4: Experiment Tracking ו-Model Registry

אחת הטעויות הנפוצות ביותר: 80% מ-ML practitioners לא יכולים לשחזר תוצאות אחרי 3 חודשים, כי לא תיעדו experiments. MLflow ו-DVC פותרים את זה. Claude יכול לעזור לתעד מיד:

תעד את הexperiment הבא בפורמט MLflow-compatible ו-Model Card:

Model: LightGBM לניבוי נטישת לקוחות (churn prediction)
Hyperparameters: learning_rate=0.05, max_depth=6, n_estimators=500
Dataset: עסקאות לקוחות סלולר ישראל 2023-2024, 2.1M rows
Results: AUC=0.89, F1=0.83, Precision=0.88, Recall=0.79
Compute: 38 min, 16 cores, 64GB RAM, no GPU
Limitations: לא נבדק על לקוחות עסקיים, רק פרטיים

הוסף:
1. MLflow logging code
2. Model Card בפורמט Hugging Face
3. comparison לbaseline הקודם
4. compliance notes לחוק הגנת הפרטיות הישראלי
5. המלצה לצעד הבא (hyperparameter tuning / feature engineering / production)

Rollback, הכלי שאף אחד לא בודק עד שצריך אותו

מחקרים מ-2025 מצביעים על טעות קריטית: רוב הצוותים לא בודקים rollback procedure לפני release. כשמודל גרוע נכנס לproduction, זה הרגע לpanicke. Blue-Green deployment פותר זה ברמה ארכיטקטונית: שני environments מלאים, traffic switch תוך שניות.

Blue-Green: שני environments מלאים זהים. מחליפים 100% traffic בבת אחת. rollback = החלפה חזרה. מהיר, נקי, יקר יותר בתשתית.
Canary: מנתבים % קטן (5-10%) לversion חדש, מגדילים בהדרגה. בטוח יותר, אם יש בעיה, רק 5% מהמשתמשים מושפעים.
Shadow mode: הmodel החדש רץ במקביל אבל התשובות שלו לא מוצגות ללקוח, רק לוגים. ה-safe option לmigrations גדולים.

כלל אצבע: השתמש ב-Canary כברירת מחדל. Blue-Green רק כשzero-downtime קריטי ולכם הבדגט הInfrastructure.

פריסה ישירה לproduction עם 100% traffic

Canary deployment, 5-10% מהtraffic לmodel חדש, מוגדל בהדרגה

Shadow mode בלבד, המודל רץ אבל לא מחזיר תשובות

Blue-Green deployment, החלפת 100% traffic בו-זמנית

ממשיכים בלי שינוי, PSI < 0.5 עדיין בסדר

כיבוי מיידי של המודל

חקור את הסיבה לdrift, הכן retraining, המשך monitoring אינטנסיבי

Retrain אוטומטי מיידי ללא בדיקה

Data Drift = dataset גדל, Concept Drift = dataset קטן

Data Drift = inputs משתנים; Concept Drift = הקשר בין inputs לoutput משתנה

Data Drift נדרש monitoring, Concept Drift לא

Data Drift = retraining, Concept Drift = ריצה מחדש של preprocessing

Model Card, תיעוד שהוא גם compliance

כל מודל שנכנס לproduction בישראל צריך תיעוד, לא רק לגורמים טכניים, אלא לcompliance עם חוק הגנת הפרטיות הישראלי ולאחריות משפטית. Model Card הוא המסמך הזה. Claude יכול לכתוב אותו:

כתוב Model Card בפורמט Hugging Face לmodel שמסווג
בקשות הלוואה (approve/reject) בבנק ישראלי:

פרטי model:
- אלגוריתם: XGBoost
- אומן על: עסקאות 2020-2024, 500K לקוחות
- Features: גיל, הכנסה, היסטוריית אשראי, מקצוע
- Accuracy: 0.91 overall

כלול בModel Card:
1. Intended Use ו-Out-of-scope Use
2. Training Data section
3. Performance metrics לsegments שונים (גיל, מגדר, מוצא)
4. Limitations ו-Risks
5. Compliance notes: חוק הגנת הפרטיות + חוק שוויון זכויות
6. שם אחראי מודל ואיש קשר לטיפול בתלונות

סיכום, מה חשוב לזכור

Monitor מהיום הראשון, לא "נוסיף monitoring מאוחר יותר". הגדר PSI alerts ו-accuracy alerts לפני שdeploy הראשון.
בדוק rollback לפני כל release, תרגל rollback בסביבת staging. מציאת בעיית rollback בproduction = nightmare.
Version הכל, קוד, data, ו-model. MLflow ו-DVC הם לא "nice to have", הם ה-safety net שלך כשמשהו ישבר.
CI/CD ל-ML כולל model evaluation, אל תdeploy model שלא עבר accuracy gate, fairness check, וlatency test.
Claude כ-MLOps architect, תן constraints ריאליים (scale, latency, stack) וקבל architecture שמתאים לcase שלך, לא דוגמא גנרית.