# Model Performance Monitoring and Drift Detection

**Last updated:** 2026-02
**Status:** GA
**Category:** Monitoring & Observability

---

## 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
```

### Azure AI 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

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

### Azure CLI v2

```bash
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)
- **Azure AI 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 (Azure AI 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

## Kilder og verifisering

### Verified (Microsoft Learn MCP)

- [Azure Machine Learning model monitoring (concept)](https://learn.microsoft.com/en-us/azure/machine-learning/concept-model-monitoring?view=azureml-api-2) — **Verified** (fetched 2026-02)
- [Monitor performance of models deployed to production](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-monitor-model-performance?view=azureml-api-2) — **Verified** (fetched 2026-02)
- [Data drift monitoring (legacy, retiring)](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-monitor-datasets?view=azureml-api-1) — **Verified** (fetched 2026-02, kontext: migrering til Model Monitor)
- [Evaluate generative AI models (Azure AI Foundry)](https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/evaluate-generative-ai-app?view=foundry-classic) — **Verified** (fetched 2026-02)
- [Observability in generative AI (Azure AI Foundry)](https://learn.microsoft.com/en-us/azure/ai-foundry/concepts/observability?view=foundry-classic) — **Verified** (fetched 2026-02)
- [Test and evaluate AI workloads on Azure](https://learn.microsoft.com/en-us/azure/well-architected/ai/test) — **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) |
