ms-ai-architect/skills/ms-ai-governance/references/monitoring-observability/model-performance-drift-detection.md

Model Performance Monitoring and Drift Detection

Last updated: 2026-06-24 | Verified: MCP 2026-06-24 Status: GA Category: Monitoring & Observability Type: reference Source: https://learn.microsoft.com/azure/foundry/concepts/observability

---

Innhold

• Introduksjon
• Kjernekomponenter
• Arkitekturmønstre
• Beslutningsveiledning
• Integrasjon med Microsoft-stakken
• Offentlig sektor (Norge)
• Kostnad og lisensiering
• For arkitekten (Cosmo)
• Kilder og verifisering

Introduksjon

Model Performance Monitoring og Drift Detection er den siste, kritiske fasen i machine learning-livssyklusen. I motsetning til tradisjonelle programvaresystemer, avhenger ikke machine learning-systemers oppførsel bare av regler spesifisert i kode, men også av data. Når et AI-modell blir "gammel" (stale), kan ytelsen degraderes til det punktet at den mister forretningsverdi eller skaper alvorlige compliance-problemer i regulerte miljøer.

Azure Machine Learning tilbyr omfattende model monitoring capabilities som sporer modell-ytelse i produksjon fra både data science- og operasjonelle perspektiver. Systemet detekterer når produksjonsdata drifter fra treningsdata, når prediksjoner endrer seg, når datakvalitet forringes, eller når modellens faktiske performance (målt mot ground truth) avviker fra forventninger.

Model monitoring handler om to kritiske typer drift: data drift (endringer i input-data distribusjonen) og concept drift (endringer i sammenhengen mellom features og target). Data drift kan oppstå på grunn av oppstrøms prosessendringer, datakvalitetsproblemer, naturlig tidsserieutvikling, eller covariate shift. Concept drift oppstår når eksterne forhold endrer seg slik at modellens prediksjoner ikke lenger reflekterer virkeligheten — for eksempel når konkurrenter lanserer nye produkter som endrer salgsadferd.

Kjernekomponenter

Monitoring Signals

Azure Machine Learning støtter følgende built-in monitoring signals:

Signal	Beskrivelse	Metrics	Produksjonsdata	Referansedata
Data Drift	Sporer endringer i distribusjon av model inputs	Jensen-Shannon Distance, Population Stability Index, Normalized Wasserstein Distance, Two-Sample Kolmogorov-Smirnov Test, Pearson's Chi-Squared Test	Model inputs	Training data eller recent production data
Prediction Drift	Sporer endringer i distribusjon av model outputs	Jensen-Shannon Distance, Population Stability Index, Normalized Wasserstein Distance, Chebyshev Distance, Two-Sample Kolmogorov-Smirnov Test, Pearson's Chi-Squared Test	Model outputs	Validation data eller recent production data
Data Quality	Sporer dataintegritet i model inputs	Null value rate, Data type error rate, Out-of-bounds rate	Model inputs	Training data eller recent production data
Feature Attribution Drift	Sporer endringer i feature importance over tid	Normalized Discounted Cumulative Gain	Model inputs + outputs	Training data (påkrevd)
Model Performance (Classification)	Sporer objektiv ytelse mot ground truth	Accuracy, Precision, Recall	Model outputs	Ground truth data (påkrevd)
Model Performance (Regression)	Sporer objektiv ytelse mot ground truth	MAE, MSE, RMSE	Model outputs	Ground truth data (påkrevd)

Data Quality Metrics

Azure Machine Learning støtter tre data quality metrics med opptil 0.00001 presisjon:

1. Null value rate: Andel null-verdier per feature
2. Data type error rate: Andel data type-avvik vs. referansedata
3. Out-of-bounds rate: Andel verdier utenfor akseptabelt range (numerisk) eller set (kategorisk)

Lookback Windows

Monitoring benytter rolling eller fixed data windows:

• Lookback window size: Varighet av data window i ISO 8601-format (f.eks. P7D = 7 dager)
• Lookback window offset: Offset fra monitoring run-tid (f.eks. P2D = ekskluder siste 2 dager)

Eksempel: Monitor kjører 31. januar kl. 15:15 UTC med production data lookback P7D og offset P0D → bruker data fra 24. januar 15:15 til 31. januar 15:15.

Best practice: Sørg for at referansedata og produksjonsdata windows ikke overlapper. Referansedata lookback offset bør være ≥ summen av produksjonsdata lookback size + offset.

Arkitekturmønstre

Pattern 1: Out-of-Box Monitoring (Online Endpoints)

Bruk når: Modell er deployet til Azure ML online endpoint med data collection aktivert.

Fordeler:

• Automatisk data collection via model data collector
• Smart defaults for metrics og thresholds
• Built-in signals: data drift, prediction drift, data quality
• Minimal konfigurasjon

Ulemper:

• Begrenset til online endpoints
• Mindre fleksibilitet i metric-valg

Arkitektur:

Azure ML Online Endpoint
  ↓ (auto data collection)
Blob Storage (production inference data)
  ↓
Serverless Spark Compute (scheduled monitoring job)
  ↓ (metrics computation)
Azure ML Studio (dashboard + alerts)
  ↓ (event-driven)
Azure Event Grid → Event Hubs / Logic Apps / Functions

Pattern 2: Advanced Monitoring (Custom Signals + Feature Importance)

Bruk når: Du trenger granular kontroll over hvilke features som monitores, custom metrics, eller feature importance-basert drift detection.

Fordeler:

• Monitor top-N viktigste features
• Custom metric thresholds
• Kombiner multiple signals (drift + quality + performance)
• Støtte for training/validation data som baseline

Ulemper:

• Krever mer konfigurasjon
• Mer kompleks tolkning av resultater

Konfigurasjon:

• Bruk training data som reference_data med target_column for å aktivere feature importance
• Konfigurer top_n_feature_importance eller spesifikk feature list
• Set custom metric thresholds per signal

Pattern 3: Model Performance Monitoring (Ground Truth)

Bruk når: Du har tilgang til ground truth data (actuals) og vil måle objektiv modell-performance.

Fordeler:

• Direkte måling av accuracy, precision, recall, MAE, MSE, RMSE
• Objektiv view av modell-ytelse i produksjon
• Trigger retraining basert på faktisk performance degradation

Ulemper:

• Krever ground truth data med unique ID per row
• Delay mellom prediksjoner og ground truth availability
• Ekstra data engineering for å samle og matche ground truth

Data Requirements:

• Production model output med unique ID (correlation ID fra data collector eller custom ID)
• Ground truth data med samme unique ID
• Join-kolonne for å koble production + ground truth

Eksempel workflow (credit card fraud detection):

1. Deploy modell med data collector → logger is_fraud predictions
2. Logg unique ID per inference (enten fra data collector eller application)
3. Når ground truth is_fraud er tilgjengelig → map til samme unique ID
4. Registrer ground truth som Azure ML data asset
5. Opprett model performance signal som joiner output + ground truth på unique ID
6. Compute accuracy, precision, recall

Beslutningsveiledning

Når bruke hvilken signal?

Scenario	Anbefalt signal	Rasjonale
Nylig deployet modell uten ground truth	Data Drift + Data Quality	Tidlig warning om input-endringer
Modell med tilgjengelig ground truth	Model Performance + Data Drift	Objektiv ytelsesmåling + root cause analysis
Høyt antall features (>50)	Feature Attribution Drift (top-N)	Fokuser på viktigste features, reduser noise
Tidsseriedata med sesongvariasjon	Recent past production data som baseline	Unngå false positives fra naturlig drift
Regression-oppgaver	Prediction Drift + Model Performance (MAE/MSE/RMSE)	Spor både output-distribusjon og faktisk error
Classification-oppgaver	Prediction Drift + Model Performance (accuracy/precision/recall)	Spor både output-distribusjon og faktisk performance

Frekvensvalg

Traffic Volume	Data Accumulation	Anbefalt frekvens
Heavy daily traffic	Sufficient daily	Daily (frequency: day, interval: 1)
Moderate weekly traffic	Sufficient weekly	Weekly (frequency: week, interval: 1)
Low monthly traffic	Sufficient monthly	Monthly (frequency: month, interval: 1)

Vanlige feil

❌ Anti-patterns:

• Kjøre monitoring uten data collection aktivert
• Bruke overlappende lookback windows (referanse + produksjon)
• Sette for lave thresholds → alert fatigue
• Monitore alle features når top-N ville vært nok
• Ignorere feature importance ved drift analysis
• Ikke koble monitoring til Event Grid for automatisk retraining

✅ Best practices:

• Start model monitoring umiddelbart etter deployment
• Involver data scientists i threshold-setting
• Kombiner multiple signals for bred + granular view
• Bruk training data som baseline for data drift/quality
• Bruk validation data som baseline for prediction drift
• Spesifiser monitoring frequency basert på data growth
• Monitor top-N features eller subset (ikke alle) ved mange features
• Bruk model performance signal når ground truth er tilgjengelig

Røde flagg

🚩 Symptom: Data drift magnitude nær 100% Diagnose: Radikal endring i input-distribusjoner Action: Undersøk top drifting features, sjekk oppstrøms datapipeline

🚩 Symptom: Høy null value rate plutselig Diagnose: Data quality issue, broken sensor, upstream data issue Action: Sjekk datakilde, upstream dependencies

🚩 Symptom: Model performance (accuracy) < threshold Diagnose: Concept drift, model staleness Action: Trigger retraining job med nyere data inkludert ground truth

🚩 Symptom: Feature attribution drift høy Diagnose: Feature importance har endret seg, modell bruker features annerledes Action: Undersøk hvilke features har endret importance, vurder retraining eller feature engineering

Integrasjon med Microsoft-stakken

Azure Machine Learning

• Model Data Collector: Automatisk innsamling av production inference data fra online endpoints
• Serverless Spark Compute: Kjører monitoring jobs (Standard_E4s_v3 til E64s_v3)
• ML Datasets: Registrer training/validation/ground truth som data assets
• Azure ML Studio: Visualiser monitoring results, trend lines, feature-level drill-down

Azure Monitor + Event Grid

• Event Grid System Topic: Subscribe til Run status changed events
• Event Filter: Filter på data.RunTags.azureml_modelmonitor_threshold_breached
• Event Handlers: Azure Event Hubs, Azure Functions, Logic Apps
• Automated Actions: Trigger retraining pipeline, send notifications, update dashboards

Event-driven retraining workflow:

Model Monitor detects drift/performance degradation
  ↓
Event Grid emits "Run status changed" event
  ↓
Azure Function triggered
  ↓
Execute ML pipeline for retraining
  ↓
Deploy new model version

Microsoft Foundry

• Foundry Observability: Continuous evaluation for generative AI applications
• AI Red Teaming: Scheduled adversarial testing for safety/security
• Application Insights: Real-time operational metrics
• Evaluators: Groundedness, Relevance, Fluency, Coherence for generative AI

Python SDK v2

from azure.ai.ml.entities import (
    DataDriftSignal,
    DataQualitySignal,
    ModelPerformanceSignal,
    FeatureAttributionDriftSignal,
    MonitorSchedule,
    MonitorDefinition
)

Azure CLI v2

az ml schedule create -f ./monitoring-config.yaml

Offentlig sektor (Norge)

GDPR og personvern

• Data retention: Definer retention policies for production inference data
• Anonymisering: Vurder anonymisering av production data før monitoring (spesielt ved ground truth)
• Databehandleravtale: Sikre at monitoring data håndteres i tråd med GDPR Article 28
• Logging: Audit logs for hvem som har tilgang til monitoring dashboards med sensitive data

AI Act (EU)

• High-risk AI systems: Model monitoring er påkrevd for high-risk AI (Article 15)
  • Healthcare, critical infrastructure, law enforcement, biometric identification, education, employment
• Logging: Automatisk logging av input data, output decisions, monitoring events
• Performance monitoring: Kontinuerlig evaluering mot accuracy, bias, fairness metrics
• Drift detection: Dokumenter når modell drifter og hvilke tiltak som ble iverksatt

Forvaltningsloven og Digdir-prinsipper

• Åpenhet: Dokumenter monitoring setup, thresholds, og alert-triggers i ADR (Architecture Decision Records)
• Etterprøvbarhet: Oppretthold audit trail for monitoring results, alerts, og retraining decisions
• Forsvarlighet: Definer akseptable thresholds basert på domain expertise og risiko
• Informasjonssikkerhet: Sikre at monitoring data ikke eksponerer sensitive data (PII)

Schrems II og datasuverenitet

• Data residency: Velg Azure regions innenfor EU/EEA for production data + monitoring jobs
  • Norway East, Sweden Central, France Central
• Encryption: Bruk Customer-Managed Keys (CMK) for monitoring data i Blob Storage
• Access control: Implementer RBAC for monitoring dashboards (minimum: Reader role på workspace)

Kostnad og lisensiering

Prismodell

Model monitoring er inkludert i Azure Machine Learning workspace, men du betaler for:

Ressurs	Prismodell	Estimat (NOK/mnd)*
Serverless Spark Compute	Per vCPU-time	Standard_E4s_v3: ~40-80 NOK/time (4 vCPU)
Blob Storage	Per GB + transactions	~0.20 NOK/GB/mnd + ~0.05 NOK/10k transactions
Azure Monitor Application Insights	Per GB ingested data	~25 NOK/GB (første 5 GB gratis/mnd)
Event Grid	Per event	~0.005 NOK/event (første 100k gratis/mnd)

*Estimater basert på Norway East region, februar 2026. Valutakurs: 1 USD ≈ 10 NOK.

Kostnadsoptimalisering

Reduser Spark compute-tid:

• Monitor top-N features (ikke alle)
• Øk monitoring interval (weekly/monthly vs. daily) hvis traffic er lav
• Bruk mindre Spark instance (E4s_v3 vs. E64s_v3) for mindre datasett

Reduser storage-kostnader:

• Definer data retention policies (f.eks. slett production data > 90 dager)
• Bruk Archive tier for historical monitoring data

Reduser alert noise:

• Sett realistiske thresholds for å unngå false positives
• Filtrer Event Grid events på specifikt monitor navn (ikke alle monitors i workspace)

Budsjett-eksempel (daglig monitoring, 100k requests/dag, 50 features):

• Spark compute: ~2-4 timer/uke × 50 NOK/time = ~200-400 NOK/mnd
• Blob storage: ~10 GB × 0.20 NOK = ~2 NOK/mnd
• Application Insights: ~5 GB/mnd = gratis (under 5 GB tier)
• Total: ~200-400 NOK/mnd

Lisensiering

• Azure Machine Learning: Enterprise Agreement eller Pay-As-You-Go
• MCP-servere (hvis brukt): Vurder kostnader for microsoft-learn MCP (gratis), context7 MCP (avhenger av plan)
• Microsoft Foundry: Separate SKU for generative AI monitoring (safety evaluations hosted i East US 2, France Central, UK South, Sweden Central)

For arkitekten (Cosmo)

Spørsmål å stille klienten

1. Data availability: Har klienten allerede data collection aktivert for production models? Hvis nei, må vi aktivere model data collector først.
2. Ground truth: Har klienten tilgang til ground truth data? Hvor raskt er ground truth tilgjengelig etter predictions? (kritisk for model performance monitoring)
3. Frekvens: Hvor mye production traffic har modellen? (daglig, ukentlig, månedlig) → bestemmer monitoring frequency
4. Alerts: Hvem skal motta alerts? Skal alerts trigge automatiske actions (retraining, notifications)?
5. Baseline: Skal vi bruke training data, validation data, eller recent production data som comparison baseline?
6. Feature importance: Har klienten mange features (>50)? Skal vi fokusere på top-N viktigste features?
7. Budget: Hva er budsjett for monitoring compute + storage? (viktig for frequency og lookback window sizing)
8. Compliance: Er dette en high-risk AI system under AI Act? (krever model monitoring)

Fallgruver å unngå

🚨 Drift detection uten action plan: Ikke sett opp monitoring uten plan for hva som skjer når drift detekteres. Definer retraining triggers, approval workflows, rollback-strategier.

🚨 Overlapping windows: Hvis referansedata og produksjonsdata windows overlapper, får du spurious drift detection. Bruk formelen: reference_offset ≥ production_size + production_offset.

🚨 Alert fatigue fra for lave thresholds: Begynn konservativt med thresholds, juster basert på historical data. Involver data scientists i threshold-setting.

🚨 Monitoring alle features: Ved mange features (>50), fokuser på top-N feature importance eller subset. Ellers får du høye compute-kostnader og noise.

🚨 Ignorere data quality: Fokus på drift alene er ikke nok. Data quality issues (null values, type errors, out-of-bounds) kan indikere upstream data problems.

🚨 Manglende Event Grid integration: Drift detection uten automated retraining pipeline er reaktivt, ikke proaktivt. Integrer med Event Grid for event-driven retraining.

Anbefalinger per modenhetsnivå

Level 1: Basic Monitoring (ad-hoc ML)

• Bruk out-of-box monitoring for online endpoints
• Aktiver data drift + data quality signals
• Sett email alerts til data science team
• Frekvens: weekly eller monthly

Level 2: Intermediate Monitoring (established MLOps)

• Legg til prediction drift + feature attribution drift
• Integrer med Event Grid → send alerts til Teams/Slack
• Monitor top-10 viktigste features
• Frekvens: daily eller weekly
• Dokumenter thresholds og rationale i ADR

Level 3: Advanced Monitoring (mature MLOps/GenAIOps)

• Implementer model performance monitoring med ground truth
• Event-driven retraining pipeline via Event Grid → Azure Functions → ML Pipeline
• Custom signals for domain-spesifikke metrics
• Frekvens: daily eller real-time
• A/B testing av retraining triggers (threshold tuning)
• Dashboard med trend analysis (Azure Monitor Workbooks)

Level 4: Enterprise Monitoring (AI Platform)

• Sentralisert monitoring for alle modeller (multi-workspace, multi-region)
• Automated retraining + automated deployment (CI/CD for ML)
• Red teaming for safety/security (Microsoft Foundry)
• Continuous evaluation for generative AI (Foundry observability)
• FinOps tracking: cost per model, cost per inference, budget alerts
• Compliance automation: GDPR audit logs, AI Act documentation

(Verified MCP 2026-04)

Kilder og verifisering

Verified (Microsoft Learn MCP)

• Azure Machine Learning model monitoring (concept) — Verified (fetched 2026-02)
• Monitor performance of models deployed to production — Verified (fetched 2026-02)
• Data drift monitoring (legacy, retiring) — Verified (fetched 2026-02, kontext: migrering til Model Monitor)
• Evaluate generative AI models (Microsoft Foundry) — Verified (fetched 2026-02)
• Observability in generative AI (Microsoft Foundry) — Verified (fetched 2026-02)
• Test and evaluate AI workloads on Azure — Verified (fetched 2026-02)

Baseline (Model knowledge)

• Data drift vs. concept drift: Jensen-Shannon Distance, Wasserstein Distance, Kolmogorov-Smirnov Test, Pearson's Chi-Squared Test — Baseline (standard statistical metrics)
• Model performance metrics: Accuracy, Precision, Recall, MAE, MSE, RMSE — Baseline (standard ML metrics)
• ISO 8601 date formats: P7D (7 dager), P1M (1 måned) — Baseline (standard)
• GDPR Article 28 (databehandleravtaler), AI Act Article 15 (high-risk AI monitoring) — Baseline (regulatory framework)

Confidence per seksjon

Seksjon	Confidence	Kilde
Introduksjon	High	Verified (concept-model-monitoring)
Kjernekomponenter	High	Verified (concept-model-monitoring, how-to-monitor-model-performance)
Arkitekturmønstre	High	Verified (how-to-monitor-model-performance)
Beslutningsveiledning	Medium	Baseline + Verified (best practices)
Integrasjon Microsoft-stakken	High	Verified (Event Grid integration, AI Foundry observability)
Offentlig sektor (Norge)	Medium	Baseline (AI Act, GDPR) + Verified (Schrems II data residency)
Kostnad og lisensiering	Medium	Baseline (Azure pricing estimates for Norway East, feb 2026)
For arkitekten (Cosmo)	High	Verified (best practices) + Baseline (enterprise architecture)