ניטור מודלי ML: זיהוי סחיפת נתונים וסחיפת מודל

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

מודל ניקוד אשראי שנפרס לייצור השיג דיוק של 94% במשך 6 החודשים הראשונים. לאחר 8 חודשים, שיעור האישורים עלה ב-15% והפיגורים ב-20%. מדדי המודל עדיין נראו תקינים, אבל העסק הפסיד 55,000 דולר בחודש. הסיבה: data drift — פרופיל הלווה השתנה עקב מוצר אשראי חדש של הבנק. המודל העריך שהסיכון נמוך, אבל בפועל הוא היה גבוה. יישמנו ניטור באמצעות Evidently ו-Grafana, הגדרנו התראות על PSI > 0.2, ואוטומציה של אימון מחדש. תוך חודש המצב תוקן, וחסכנו לחברה כ-45–65 אלף דולר (כ-55,000 דולר).

ניטור מודלי ML מזהה הידרדרות לפני שהיא הופכת לקטסטרופה. אנחנו עושים זאת כבר למעלה מ-5 שנים ויישמנו יותר מ-30 פרויקטים של ניטור מודלי ML. זיהוי drift בזמן יכול לחסוך לחברות כ-9–13 אלף דולר בשנה.

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

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

הידרדרות בביצועים (model drift) — איכות החיזוי ירדה. Accuracy, F1, AUC ROC יורדים. זיהוי דורש ground truth — תוצאות אמיתיות. עיכוב ב-ground truth הוא האתגר המרכזי: בניקוד אשראי, התשובה "ההלוואה הוחזרה" מגיעה חודשים לאחר מכן. ניתן לזהות data drift מיד (ללא צורך בתוויות), ואילו model drift רק כשמגיע ה-ground truth.

מה לבחור: Evidently AI או Arize AI?

לרוב הפרויקטים אנחנו בוחרים ב-Evidently + Grafana + Prometheus ML — גמיש, זול, ומתארח עצמאית. לפתרונות ארגוניים עם תמיכה, Arize. Evidently נפרס פי 2 מהר יותר מהמתחרים, ו-TCO נמוך פי 3.

הגדרת ניטור drift שלב אחר שלב עם Evidently

1. הכנת מערך נתוני ייחוס — תמונת מצב של נתוני האימון או 2 השבועות הראשונים של הייצור.
2. הגדרת דוח — בחירת מדדי drift לכל מאפיין.
3. אינטגרציה עם Prometheus ML — ייצוא מדדים כ-gauges.
4. יצירת דשבורד Grafana — ויזואליזציה של drift לכל מאפיין.
5. הגדרת התראות — ערכי סף והודעות ל-Slack/Telegram.

אנחנו מבטיחים הגדרה תוך 1–2 ימים למודלים בסיסיים.

from evidently import ColumnMapping
from evidently.report import Report
from evidently.metric_preset import DataDriftPreset
from evidently.metrics import ColumnDriftMetric

reference_data = pd.read_parquet("s3://ml-data/reference/reference_data.parquet")
current_data = fetch_recent_predictions(hours=24)

column_mapping = ColumnMapping(
    target='label',
    prediction='prediction',
    numerical_features=['age', 'income', 'credit_score'],
    categorical_features=['region', 'product_type'],
)

report = Report(metrics=[
    DataDriftPreset(),
    ColumnDriftMetric(column_name='income'),
    ColumnDriftMetric(column_name='credit_score'),
])

report.run(
    reference_data=reference_data,
    current_data=current_data,
    column_mapping=column_mapping,
)

Evidently משתמש במבחנים סטטיסטיים: PSI (Population Stability Index) — סף > 0.2 מצביע על drift; מרחק Wasserstein — למאפיינים מספריים; מבחן Chi-square — למאפיינים קטגוריאליים; מבחן KS — למאפיינים מספריים, רגיש לשינויים מקומיים.

תיעוד Evidently (evidentlyai.com) והמאמר בוויקיפדיה על Concept drift הם משאבים שימושיים ללימוד מעמיק יותר.

באיזה מבחן לבחור?

אם הנתונים קטנים (< 1000 שורות), השתמשו במבחן KS. אם גדולים, השתמשו ב-PSI. למאפיינים קטגוריאליים, Chi-square. ל-Evidently יש בחירה אוטומטית כברירת מחדל, אבל אנחנו ממליצים להגדיר זאת במפורש לכל מאפיין.

ייצוא מדדים ל-Prometheus ML

from prometheus_client import Gauge, start_http_server
import schedule

drift_score = Gauge('model_feature_drift_score', 'PSI drift score per feature', ['feature', 'model'])
data_quality_score = Gauge('model_data_quality_score', 'Data quality score', ['model'])

def run_drift_check():
    report = generate_drift_report()
    results = report.as_dict()
    for metric in results['metrics']:
        if metric['metric'] == 'ColumnDriftMetric':
            feature = metric['result']['column_name']
            score = metric['result']['drift_score']
            drift_score.labels(feature=feature, model='credit-scoring-v2').set(score)

schedule.every(1).hours.do(run_drift_check)
start_http_server(8080)

התראות על הידרדרות מודל

---
- alert: FeatureDataDrift
  expr: model_feature_drift_score{model="credit-scoring-v2"} > 0.2
  for: 2h
  labels:
    severity: warning
    team: ml
  annotations:
    summary: "Data drift detected in feature {{ $labels.feature }}"
    description: "PSI = {{ $value }}, threshold 0.2. Consider retraining."
- alert: ModelAccuracyDegradation
  expr: model_accuracy_rolling_7d < 0.85
  for: 1h
  labels:
    severity: critical
---

מצב Shadow: השוואת מודלים בטוחה

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

def predict(features: dict) -> float:
    result = production_model.predict(features)
    if shadow_mode_enabled():
        shadow_result = new_model.predict(features)
        log_shadow_prediction(
            features=features,
            production_pred=result,
            shadow_pred=shadow_result,
        )
    return result

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

למה data drift מסוכן לעסק?

data drift שלא זוהה מוביל להפסדים כספיים. בפרויקט אחד, גילינו ש-drift במודל ניקוד אשראי גרם לאישור לווי סיכון, מה שהוביל להפסדים של 15% בתיק (~18–26 אלף דולר, או 22,000 דולר). יישום ניטור צמצם את ההפסדים ב-80% ב-30 הימים הראשונים.

מה כלול בהגדרת ניטור מודלים

לוחות זמנים וניסיון

העלות תלויה במורכבות: נבחן את הפרויקט שלכם. מהנדסי MLOps המוסמכים שלנו מבטיחים שהניטור שלכם אמין ומובטח לזהות drift תוך 24 שעות. צרו קשר לייעוץ. אנחנו צוות עם למעלה מ-5 שנות ניסיון ב-ML ו-DevOps, שיישמנו יותר מ-30 מערכות ניטור. פנו אלינו — נעזור להקים ניטור איכותי שבאמת חוסך לעסק שלכם מהפסדים. הזמינו יישום כבר עכשיו.