ms-ai-architect/skills/ms-ai-engineering/references/mlops-genaiops/data-drift-monitoring-detection.md

Data Drift Monitoring and Detection

Last updated: 2026-04 Status: GA Category: MLOps & GenAIOps Type: reference Source: https://learn.microsoft.com/azure/machine-learning/concept-model-monitoring

---

Innhold

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

Introduksjon

Data drift er endringer i statistisk fordeling av modellinput-data over tid som kan føre til forringet modellprestasjon. For machine learning-modeller er kontinuerlig overvåking av data drift avgjørende for å opprettholde produksjonskvalitet. Azure Machine Learning tilbyr innebygd drift detection som sammenligner produksjonsdata mot baseline-datasett (typisk treningsdata eller nylig produksjonsdata) og beregner statistiske avstandsmål.

Data drift oppstår av flere årsaker: upstream prosessendringer (f.eks. sensor byttet ut, endret måleenhet), datakvalitetsproblemer (defekt sensor som alltid leser 0), naturlig drift (temperatur endres med sesong), eller covariate shift (endring i relasjoner mellom features). Uten deteksjon kan drift føre til at modeller blir utdaterte og leverer dårlige prediksjoner i produksjon.

Azure Machine Learning Model Monitoring forenkler drift detection ved å beregne én enkelt metric som abstraherer kompleksiteten i datasett med hundrevis av features og titusener av rader. Når drift detekteres, kan du drille ned til feature-nivå for å identifisere root cause. Dette top-down approach gjør overvåking enklere enn tradisjonelle regelbaserte teknikker som kan være tidkrevende og feilutsatte.

Kjernekomponenter

Monitoring Signals Azure Machine Learning støtter flere overvåkingssignaler som kjøres som scheduled jobs:

• Data drift – sammenligner distribusjon av modell-input mot baseline (training data eller recent production data)
• Prediction drift – sporer endringer i distribusjon av modellens output
• Data quality – overvåker data-integritet (null values, type errors, out-of-bounds rate)
• Feature attribution drift – sporer endringer i feature importance mellom trening og produksjon
• Model performance – objektiv prestasjonsmåling mot ground truth data (krever labeled data)

Drift Detection Metrics (Verified — Azure ML docs) For numeriske features:

• Jensen-Shannon Distance – symmetrisk divergens mellom to sannsynlighetsfordelinger
• Population Stability Index (PSI) – misure endring i distribusjoner
• Normalized Wasserstein Distance – minimum "arbeid" for å transformere baseline til target distribution
• Two-Sample Kolmogorov-Smirnov Test – tester om to samples kommer fra samme fordeling

For kategoriske features:

• Pearson's Chi-Squared Test – tester uavhengighet mellom kategoriske variabler
• Euclidean Distance – beregnet på empiriske fordelinger av kategoriske kolonner

Lookback Windows og Offset (Verified — Azure ML docs) Lookback window size definerer tidsperiode for produksjonsdata (ISO 8601 format, f.eks. P7D = 7 dager). Lookback window offset forskyvver slutten av datavindu fra kjøretidspunkt (f.eks. P2D for å ekskludere helgedata).

Best practice: Sørg for at reference data window og production data window ikke overlapper. Sett reference offset ≥ production window size + production offset.

Data Quality Metrics (Verified — Azure ML docs)

• Null value rate – andel null-verdier per feature (støtter 0.00001 presisjon)
• Data type error rate – andel verdier som ikke matcher infererred datatype fra reference data (støtter PySpark types: IntegerType, DoubleType, StringType, etc.)
• Out-of-bounds rate – andel verdier utenfor akseptabelt range/set bestemt av reference data (for numerical: [min, max], for categorical: distinct values set)

Azure Event Grid Integration (Verified — Azure ML docs) Model monitoring genererer events som kan trigge workflows via Event Grid. Når drift, datakvalitetsproblemer eller performance degradation detekteres, kan du automatisk starte retraining pipelines eller varslingssystemer.

Arkitekturmønstre

Out-of-Box Monitoring for Online Endpoints (Verified — Azure ML docs) Hvis modellen deployes til Azure Machine Learning online endpoint:

1. Aktiver production inference data collection via model data collector
2. Azure ML samler automatisk model inputs/outputs
3. Sett opp model monitor via SDK/CLI eller Studio UI
4. Spesifiser monitoring signals (data drift, data quality, etc.)
5. Kjør scheduled monitoring jobs (daglig/ukentlig/månedlig)
6. Motta alerts når thresholds overskrides

Advanced Monitoring Setup (Verified — code samples) For finkornet kontroll:

from azure.ai.ml import MLClient
from azure.ai.ml.entities import (
    DataDriftSignal,
    DataQualitySignal,
    MonitorFeatureFilter,
    NumericalDriftMetrics,
    CategoricalDriftMetrics,
    DataDriftMetricThreshold,
    MonitorSchedule,
    ServerlessSparkCompute
)

# Definer data drift signal
features = MonitorFeatureFilter(top_n_feature_importance=20)
metric_thresholds = DataDriftMetricThreshold(
    numerical=NumericalDriftMetrics(jensen_shannon_distance=0.01),
    categorical=CategoricalDriftMetrics(pearsons_chi_squared_test=0.02)
)

advanced_data_drift = DataDriftSignal(
    production_data=production_data,
    reference_data=reference_data_training,
    features=features,
    metric_thresholds=metric_thresholds,
    alert_enabled=True
)

# Sett opp monitoring schedule
spark_compute = ServerlessSparkCompute(
    instance_type="standard_e4s_v3",
    runtime_version="3.3"
)

monitoring_signals = {'data_drift_advanced': advanced_data_drift}
monitor_definition = MonitorDefinition(
    compute=spark_compute,
    monitoring_signals=monitoring_signals,
    alert_notification=AlertNotification(emails=['team@example.com'])
)

recurrence_trigger = RecurrenceTrigger(frequency="day", interval=1)
model_monitor = MonitorSchedule(
    name="production_drift_monitor",
    trigger=recurrence_trigger,
    create_monitor=monitor_definition
)

ml_client.schedules.begin_create_or_update(model_monitor)

Top-N Feature Monitoring (Verified — Azure ML docs) For modeller med mange features: Overvåk kun topp-N viktigste features (basert på feature importance fra training) for å redusere compute cost og monitoring noise.

features = MonitorFeatureFilter(top_n_feature_importance=10)
# eller spesifikk feature-liste:
features = ['feature_A', 'feature_B', 'feature_C']

Custom Monitoring Signals (Baseline) Hvis built-in signals ikke passer: Definer custom monitoring signal component med egne metrics og thresholds. Krever implementering av Spark-basert beregningslogikk.

Legacy Dataset Monitors (v1) → Model Monitor Migration (Verified — Azure ML docs) Azure ML Dataset Monitors (preview, v1 SDK) er deprecated. Migrer til Model Monitor (v2 SDK):

• v1: DataDriftDetector.create_from_datasets()
• v2: DataDriftSignal + MonitorSchedule

Model Monitor har flere capabilities (multi-signal, feature attribution drift, generative AI metrics).

Beslutningsveiledning

Når bruke data drift monitoring?

• Modellen er deployed til produksjon (online eller batch endpoint)
• Input-data kan endre seg over tid (sesongvariasjoner, skiftende brukeratferd, upstream prosessendringer)
• Modellprestasjon er kritisk for forretningen
• Du har tilgang til baseline-data (training data eller historisk production data)

Valg av baseline-data (Verified — best practices)

• Data drift/quality: Bruk training data som baseline for mer meningsfull sammenligning
• Prediction drift: Bruk validation data eller labeled test data som baseline
• Nylig produksjonsdata: Kan brukes som baseline hvis du vil detektere kortsiktige endringer

Monitoring Frequency (Verified — best practices)

• Daglig: Modell med høy daglig trafikk og rask data-akkumulering
• Ukentlig: Moderat trafikk, ugentlig data-akkumulering tilstrekkelig
• Månedlig: Lav trafikk eller sesongbaserte mønstre

Unngå for hyppig monitoring hvis produksjonsdata-volumet er lavt (statistisk insignifikante resultater).

Alert Threshold-setting (Baseline + Verified) Samarbeid med data scientists som kjenner modellen for å sette riktige thresholds. For høye thresholds = missed drift, for lave = alert fatigue.

Start konservativt (f.eks. Jensen-Shannon distance threshold 0.1 for numerical), juster basert på false positive/negative rates.

Compute Resource Sizing (Baseline) Model monitoring bruker Spark for store datasett. Velg instance type basert på data volum:

• standard_e4s_v3: Små til medium datasett (<100K rows/dag)
• standard_e8s_v3 eller høyere: Store datasett (>1M rows/dag)

Multi-Signal Monitoring (Verified — best practices) Kombiner flere signals for bredere dekkning:

• Data drift + Feature attribution drift = tidlig warning om performance issues
• Data quality + Data drift = detekter både strukturelle og distribusjonelle problemer
• Model performance (hvis ground truth tilgjengelig) = objektiv måling

Integrasjon med Microsoft-stakken

Azure Machine Learning Workspace (Verified) Data drift monitoring krever:

• Azure ML workspace (v2 API)
• Compute resources (serverless Spark eller managed compute cluster)
• Datastore for production inference data (Azure Blob Storage eller ADLS Gen2)
• Optional: Application Insights for custom metrics logging

Authentication Options (Verified — Azure ML docs)

• Credential-based: Legg til credentials på datastore
• Credential-less (anbefalt): Bruk User-Assigned Managed Identity (UAMI)
  1. Opprett UAMI og attach til workspace
  2. Grant UAMI permissions til datastore
  3. Sett systemDatastoresAuthMode = 'identity'

Azure Monitor + Application Insights (Verified) Drift metrics emitteres til Application Insights (tilhører ML workspace). Bruk custom alerting for alle generated metrics.

Azure Event Grid for CI/CD Integration (Verified) Når model monitor detekterer drift og threshold overskrides:

1. Event Grid emitter "Run status changed" event
2. Filter på azureml_modelmonitor_threshold_breached tag
3. Trigger automated retraining pipeline (Azure ML pipeline eller Azure DevOps)
4. Redeploy oppdatert modell

Eksempel Event Grid filter (advanced filter):

• Key: data.RunTags.azureml_modelmonitor_threshold_breached
• Operator: String contains
• Value: has failed due to one or more features violating metric thresholds

Microsoft Foundry (tidligere Azure AI Studio) (Baseline + Verified) For generative AI workloads: Microsoft Foundry har egen monitoring med observability features og generation quality metrics (groundedness, relevance, fluency). Støtter også drift detection for grounding data i RAG scenarios.

Power BI Dashboards (Baseline) Export drift metrics fra Azure ML til Power BI for executive dashboards. Koble til workspace blob storage (JSON metrics output) eller Application Insights.

Offentlig sektor (Norge)

Krav til sporbarhet (Baseline + Verified) Offentlige virksomheter må kunne dokumentere hvordan AI-modeller oppfører seg over tid (Utredningsinstruksen §14, AI Act Article 12). Data drift monitoring gir:

• Tidsserie-logging av modellprestasjon og input-distribusjon
• Feature-level attribution for å forklare hvilke variabler som endrer seg
• Alert-historikk som viser når modellen ble degradert

DPIA-relevans (Baseline) Data Protection Impact Assessment (DPIA) krever kontinuerlig risikovurdering. Data drift kan indikere:

• Endringer i populasjonssammensetning (potensielt bias)
• Datakvalitetsproblemer som kan føre til feilaktige beslutninger
• Covariate shift som kan diskriminere mot underrepresenterte grupper

Dokumenter drift detection som del av "tiltak for å sikre rettmessighet" (GDPR Article 35).

AI Act Conformity Assessment (Baseline + Verified) AI Act krever risk management system for høyrisiko-AI (Article 9). Data drift monitoring er del av "technical and organizational measures" for å sikre accuracy, robustness, cybersecurity.

Spesifikt for offentlig sektor (høyrisiko use cases):

• Logg alle drift detection runs og alert events
• Etabler prosedyre for respons på drift alerts (retraining, model decommissioning)
• Dokumenter baseline-data valg og threshold-setting i teknisk dokumentasjon

NSM Grunnprinsipper for IKT-sikkerhet (Baseline) Prinsipp 2.1 (Kjenne seg selv) og 2.2 (Identifisere og kartlegge): Data drift monitoring gir innsikt i hvordan datagrunnlaget utvikler seg, kritisk for å vurdere om modellen fortsatt er egnet for formålet.

Digdir sine anbefalinger (Baseline) Kunstig intelligens og automatisering i offentlig sektor (veileder): "Systemer må overvåkes kontinuerlig for å sikre at de fungerer som forventet." Data drift monitoring oppfyller dette kravet.

Kostnad og lisensiering

Compute Costs (Baseline + Verified) Data drift monitoring kjører på Spark compute. Kostnader beregnes per monitoring job run:

• Serverless Spark (anbefalt for starte):

  • standard_e4s_v3: ~100-150 NOK/time (4 cores, 32 GB RAM)
  • standard_e8s_v3: ~200-300 NOK/time (8 cores, 64 GB RAM)
  • Kun betaler for job runtime (typisk 5-20 minutter per run)

• Managed Compute Cluster (for store volumer):

  • Samme instans-priser, men kan holdes online (idle cost)
  • Anbefales kun hvis du kjører mange concurrent monitoring jobs

Daglig Drift Monitor (estimat):

• 1 daily job, 10 minutter runtime på standard_e4s_v3: ~2-3 NOK/dag = ~60-90 NOK/måned
• 1 hourly job, 10 minutter runtime: ~120-180 NOK/måned

Storage Costs (Baseline) Production inference data lagres i Azure Blob Storage eller ADLS Gen2:

• Inference data: ~0.15 NOK/GB/måned (hot tier)
• Drift metrics output (JSON): neglisjerbar (<1 MB per run)

Eksempel (medium-size deployment):

• 1M predictions/dag, 10 KB per record = ~10 GB/dag = ~300 GB/måned
• Storage: 300 GB × 0.15 NOK = 45 NOK/måned
• Daily monitoring (10 min/dag): 90 NOK/måned
• Total: ~135 NOK/måned

Application Insights Costs (Baseline) Metrics logging til App Insights: ~0.5 NOK/GB ingestion. Drift monitoring genererer minimal telemetry (<100 MB/måned for typical setup).

Lisensiering (Verified) Data drift monitoring er inkludert i Azure Machine Learning (ingen separat lisens):

• Krever Azure ML workspace (ingen cost for workspace selv)
• Compute og storage faktureres separat (consumption-based)

Cost Optimization Tips (Baseline)

• Bruk top-N feature monitoring istedenfor alle features
• Juster monitoring frequency basert på data growth rate
• Bruk lookback windows strategisk (ikke prosesser mer data enn nødvendig)
• Cleanup gamle inference data (retention policy)
• Bruk serverless Spark (kun betaler for runtime, ikke idle)

For arkitekten (Cosmo)

Når anbefale data drift monitoring:

• Alltid for production-deployed ML models (high-impact decisions)
• Spesielt kritisk: Finance (fraud detection), Healthcare (diagnostics), Public sector (benefit eligibility)
• Påkrevd hvis modellen brukes i automated decision-making (AI Act høyrisiko)

Implementeringsrekkefølge:

1. Uke 1: Aktiver data collection for online endpoint (model data collector)
2. Uke 2: Sett opp basic drift monitoring med default settings (out-of-box)
3. Uke 3: Tune thresholds basert på første runs (samarbeid med data scientists)
4. Uke 4: Integrer med Event Grid for automated retraining workflows

Arkitekturvalg:

Scenario	Anbefaling
Ny modell i prod	Start med out-of-box monitoring (data drift + data quality)
Modell med mange features (>100)	Bruk top-N feature importance filter
Kritisk modell (finance, healthcare)	Multi-signal monitoring (drift + attribution + performance)
Høy trafikk (>1M/dag)	Daglig monitoring med serverless Spark e8s_v3
Lav trafikk (<10K/dag)	Ukentlig monitoring med serverless Spark e4s_v3
Ground truth tilgjengelig	Legg til model performance signal (objektiv måling)
Generative AI (RAG)	Bruk Microsoft Foundry monitoring (groundedness, relevance)

Fallgruver å unngå:

• ❌ Ikke start monitoring uten å definere baseline-data (training data vs. recent production)
• ❌ Ikke sett thresholds uten data scientist input (risiko for alert fatigue eller missed drift)
• ❌ Ikke ignorer lookback window overlap (kan gi misleading results)
• ❌ Ikke bruk MLTable med Spark-based monitoring (limited support, bruk Spark API direkte)
• ❌ Ikke glem å sette opp response workflow (drift detection uten action er meningsløst)

Integrasjon med andre MLOps-komponenter:

• CI/CD pipeline: Event Grid → Azure DevOps → Automated retraining
• Model registry: Link drift alerts til model version (traceability)
• Experiment tracking: Logg drift metrics sammen med training metrics (MLflow)
• A/B testing: Bruk drift detection for å validere champion/challenger models

Offentlig sektor spesifikt:

• Dokumenter drift monitoring setup i teknisk dokumentasjon (AI Act krav)
• Etabler eskalasjonsprosedyre for kritiske drift alerts (hvem bestemmer om modell skal decommissioned?)
• Logg alle monitoring runs for audit trail (minimum 5 år retention for offentlig sektor)
• Inkluder drift metrics i årlig AI-system review (internal governance)

Migration fra v1 Dataset Monitors: Hvis kunden bruker legacy DataDriftDetector (azureml-datadrift SDK):

1. Map eksisterende baseline/target datasets til v2 reference/production data
2. Konverter frequency (Day/Week/Month) til RecurrenceTrigger
3. Migrer feature_list til MonitorFeatureFilter
4. Migrer drift_threshold til DataDriftMetricThreshold (velg metric type)
5. Test side-by-side før cutover (verifiser samme results)

Typical Conversation Flow:

1. Discover: "Bruker dere ML i prod? Hvordan overvåker dere modellprestasjon?"
2. Educate: "Data drift er en av hovedårsakene til model decay. Azure ML har innebygd drift detection."
3. Scope: "La oss starte med basic setup for én modell, tune thresholds, deretter scale ut."
4. Align: "For offentlig sektor må vi også dokumentere dette for DPIA og AI Act compliance."
5. Deliver: "Jeg setter opp monitoring, dere definerer response workflow sammen med data scientists."

Red Flags (når advare):

• Kunde ønsker å monitore 1000+ features real-time (cost explosion, bruk sampling)
• Ingen plan for hva som skal skje når drift detekteres (monitoring uten action)
• Forventer 100% accuracy i drift detection (statistiske metoder har usikkerhet)
• Vil bruke monitoring på modeller uten production traffic (ingen data å monitore)

Kilder og verifisering

Verified (Microsoft Learn MCP, 2026-04):

• Azure Machine Learning model monitoring concept: https://learn.microsoft.com/en-us/azure/machine-learning/concept-model-monitoring?view=azureml-api-2
• Monitor model performance in production: https://learn.microsoft.com/en-us/azure/machine-learning/how-to-monitor-model-performance?view=azureml-api-2
• Data drift (v1, deprecated): https://learn.microsoft.com/en-us/azure/machine-learning/how-to-monitor-datasets?view=azureml-api-1
• Python SDK examples (azure.ai.ml): Code samples verified via microsoft_code_sample_search
• Event Grid integration: https://learn.microsoft.com/en-us/azure/machine-learning/how-to-use-event-grid?view=azureml-api-2

Baseline (Model knowledge, januar 2025):

• Cost estimates (Spark compute pricing)
• Public sector compliance mapping (AI Act, DPIA, NSM)
• Custom monitoring signals implementation patterns
• Power BI integration for drift dashboards
• Migration patterns fra v1 til v2 API

MCP Calls: 5 (3 × microsoft_docs_search, 1 × microsoft_docs_fetch, 1 × microsoft_code_sample_search) Unique Sources: 12 Microsoft Learn URLs

Azure ML Model Monitoring — Data Drift Detection (2026) — Verified (MCP 2026-04)

Model monitoring signals (out-of-box for online endpoints):

Signal	What it detects
Data quality	Null values, out-of-range values, type mismatches in input features
Data drift	Statistical distribution change: training data vs production data
Prediction drift	Distribution shift in model output predictions
Feature attribution drift	Changes in which features drive predictions
Custom signals	User-defined metrics via Python scripts

Setup options:

• Out-of-box: Automatically configured for Azure ML online endpoints (no configuration required)
• Advanced: Custom monitoring for models deployed outside Azure ML (batch endpoints, external)
• Azure Event Grid integration: Route monitoring alerts for automated response

Statistical methods used:

• Jensen-Shannon divergence for categorical features
• Wasserstein distance (Earth Mover's Distance) for numerical features
• Population Stability Index (PSI) for feature stability

Reference dataset: Training dataset used as baseline; monitoring compares production distribution against it.

Alerting: Configure thresholds per signal; integrate with Azure Monitor alerts and Action Groups.