ms-ai-architect/skills/ms-ai-engineering/references/mlops-genaiops/model-drift-performance-degradation.md

Model Drift and Performance Degradation 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

Model drift og performance degradation er kritiske fenomener som oppstår når en maskinlæringsmodells ytelse forverres over tid i produksjon. Dette skjer fordi virkeligheten endrer seg – input-data får andre distribusjoner, forretningslogikk endres, sensorer kalibreres feil, eller brukernes atferd endrer seg. Uten kontinuerlig overvåking kan modeller raskt bli utdaterte og levere feil prediksjoner som undergraver forretningsmål eller skaper compliance-problemer i regulerte sektorer.

Azure Machine Learning tilbyr et omfattende modell-monitoring-rammeverk som oppdager drift og degradering gjennom:

• Data drift – endringer i input-data sammenlignet med treningsdata eller nylig produksjonsdata
• Prediction drift – endringer i modellens output-distribusjon
• Data quality – deteksjon av null-verdier, datatype-feil, out-of-bounds-verdier
• Feature attribution drift – endringer i feature importance under produksjon
• Model performance – objektiv ytelse mot ground truth (krever faktiske utfall)

Rammeverket er integrert med Azure Event Grid for automatisert respons (f.eks. modell-retraining) og støtter både online endpoints og batch deployments.

Verified (MCP): Azure Machine Learning Model Monitoring er GA-status per februar 2026, med støtte for tabular classification og regression tasks.

---

Kjernekomponenter

1. Monitoring Signals

Azure Machine Learning støtter flere built-in signals (med GA- eller preview-status):

Signal	Beskrivelse	Status	Metrics
Data Drift	Sporer endringer i input-distribusjon	GA	Jensen-Shannon Distance, Population Stability Index, Normalized Wasserstein Distance, Two-Sample Kolmogorov-Smirnov Test, Pearson's Chi-Squared Test
Prediction Drift	Sporer endringer i output-distribusjon	GA	Jensen-Shannon Distance, Population Stability Index, Normalized Wasserstein Distance, Chebyshev Distance, Two-Sample Kolmogorov-Smirnov Test, Pearson's Chi-Squared Test
Data Quality	Null rates, data type errors, out-of-bounds	GA	Null value rate, Data type error rate, Out-of-bounds rate
Feature Attribution Drift	Feature importance-endringer	Preview	Normalized Discounted Cumulative Gain
Model Performance	Objektiv ytelse (krever ground truth)	Preview	Accuracy, Precision, Recall (classification); MAE, MSE, RMSE (regression)

Verified (MCP): Metrics og signal-typer hentet fra offisiell Microsoft Learn-dokumentasjon (2026-04).

2. Reference Data

Modell-monitoring krever sammenligningsgrunnlag (baseline):

• Training data – opprinnelig treningsdata (anbefalt for data drift og data quality)
• Validation data – valideringsdata (anbefalt for prediction drift)
• Recent past production data – nylig produksjonsdata (for rolling baseline)
• Ground truth data – faktiske utfall (påkrevd for model performance)

3. Production Inference Data

Produksjonsdata kan samles inn via:

• Azure ML Data Collector – automatisk innsamling fra online endpoints med correlationid for join
• Manuell innsamling – selvregistrerte data assets (krever custom preprocessing component)

Verified (MCP): Azure ML Data Collector støtter automatisk correlation ID-generering for data joining.

4. Serverless Spark Compute

Monitoring-jobber kjører på serverless Spark compute pools:

• Støttede VM-typer: Standard_E4s_v3, Standard_E8s_v3, Standard_E16s_v3, Standard_E32s_v3, Standard_E64s_v3
• Runtime version: 3.3 eller 3.4 (Spark)
• Skalerer automatisk basert på data-volum

5. Lookback Windows

Konfigurerbare tidsperioder for produksjons- og referansedata:

• Lookback window size – varighet av data-vindu (ISO 8601-format, f.eks. P7D = 7 dager)
• Lookback window offset – offset fra monitor-kjøretid (f.eks. P0D = ingen offset, P2D = 2 dagers offset)

Best practice: Unngå overlapping mellom produksjons- og referansedata-vindu for meningsfull sammenligning.

---

Arkitekturmønstre

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

Scenario: Modell deployed til Azure ML online endpoint med data collection aktivert.

Komponenter:

1. Online endpoint med data collection (azureml.monitoring.ModelDataCollector)
2. Automatisk datainnsamling til Azure Blob Storage
3. Smart defaults for data drift, prediction drift, data quality
4. Scheduled monitoring job (daglig/ukentlig)
5. Email alerts ved threshold-brudd

Setup (Python SDK):

from azure.ai.ml import MLClient
from azure.ai.ml.entities import (
    AlertNotification,
    MonitoringTarget,
    MonitorDefinition,
    MonitorSchedule,
    RecurrencePattern,
    RecurrenceTrigger,
    ServerlessSparkCompute
)

spark_compute = ServerlessSparkCompute(
    instance_type="standard_e4s_v3",
    runtime_version="3.3"
)

monitoring_target = MonitoringTarget(
    ml_task="classification",
    endpoint_deployment_id="azureml:credit-default:main"
)

alert_notification = AlertNotification(
    emails=['abc@example.com', 'def@example.com']
)

monitor_definition = MonitorDefinition(
    compute=spark_compute,
    monitoring_target=monitoring_target,
    alert_notification=alert_notification
)

recurrence_trigger = RecurrenceTrigger(
    frequency="day",
    interval=1,
    schedule=RecurrencePattern(hours=3, minutes=15)
)

model_monitor = MonitorSchedule(
    name="credit_default_monitor_basic",
    trigger=recurrence_trigger,
    create_monitor=monitor_definition
)

ml_client.schedules.begin_create_or_update(model_monitor)

Verified (MCP): Kode-eksempel fra Microsoft Learn (azure-ai-ml SDK v2).

Pattern 2: Advanced Monitoring med Feature Importance

Scenario: Overvåk kun top N viktigste features for å redusere noise og compute-kostnad.

Komponenter:

1. Training data som reference baseline
2. Target column definert (f.eks. DEFAULT_NEXT_MONTH)
3. Top N feature importance (f.eks. top 10 features)
4. Custom metric thresholds per feature-type

Setup (Python SDK):

from azure.ai.ml.entities import (
    DataDriftSignal,
    DataDriftMetricThreshold,
    NumericalDriftMetrics,
    CategoricalDriftMetrics,
    MonitorFeatureFilter,
    ReferenceData,
)

reference_data_training = ReferenceData(
    input_data=Input(
        type="mltable",
        path="azureml:credit-reference:1"
    ),
    data_column_names={
        "target_column":"DEFAULT_NEXT_MONTH"
    },
    data_context=MonitorDatasetContext.TRAINING,
)

features = MonitorFeatureFilter(top_n_feature_importance=10)

metric_thresholds = DataDriftMetricThreshold(
    numerical=NumericalDriftMetrics(
        jensen_shannon_distance=0.01
    ),
    categorical=CategoricalDriftMetrics(
        pearsons_chi_squared_test=0.02
    )
)

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

Verified (MCP): Feature importance-basert filtering er dokumentert i Microsoft Learn.

Pattern 3: Model Performance Monitoring med Ground Truth

Scenario: Objektiv ytelses-tracking når ground truth data er tilgjengelig.

Forutsetninger:

• Unique ID i både model output og ground truth (f.eks. correlationid)
• Ground truth data asset oppdatert kontinuerlig
• Join column for å koble output og ground truth

Setup (Python SDK):

from azure.ai.ml.entities import (
    ModelPerformanceSignal,
    ModelPerformanceMetricThreshold,
    ModelPerformanceClassificationThresholds,
    ProductionData,
)

production_data = ProductionData(
    input_data=Input(
        type="uri_folder",
        path="azureml:credit-default-main-model_outputs:1"
    ),
    data_column_names={
        "target_column": "DEFAULT_NEXT_MONTH",
        "join_column": "correlationid"
    },
    data_window=BaselineDataRange(
        lookback_window_offset="P0D",
        lookback_window_size="P10D",
    )
)

reference_data_ground_truth = ReferenceData(
    input_data=Input(
        type="mltable",
        path="azureml:credit-ground-truth:1"
    ),
    data_column_names={
        "target_column": "ground_truth",
        "join_column": "correlationid"
    },
    data_context=MonitorDatasetContext.GROUND_TRUTH_DATA,
)

metric_thresholds = ModelPerformanceMetricThreshold(
    classification=ModelPerformanceClassificationThresholds(
        accuracy=0.50,
        precision=0.50,
        recall=0.50
    ),
)

model_performance = ModelPerformanceSignal(
    production_data=production_data,
    reference_data=reference_data_ground_truth,
    metric_thresholds=metric_thresholds,
    alert_enabled=True
)

Verified (MCP): Model performance monitoring krever unique ID i både output og ground truth for join-operasjon.

Pattern 4: Event-Driven Retraining (Event Grid Integration)

Scenario: Automatisk retraining når drift eller performance-degradation detekteres.

Komponenter:

1. Event Grid system topic for Azure ML workspace
2. Event subscription med advanced filter
3. Event handler (Azure Functions, Logic Apps, Event Hubs)
4. ML pipeline for retraining

Event Filter (avansert):

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

Verified (MCP): Event Grid-integrasjon støttes for å trigge automatisk respons ved drift-deteksjon.

Pattern 5: Custom Signal med Egendefinerte Metrics

Scenario: Implementer egne metrics som ikke dekkes av built-in signals (f.eks. std_deviation).

Forutsetninger:

• Custom component registrert som Azure ML component
• Input signature: production_data (mltable), <metric>_threshold (literal)
• Output signature: signal_metrics (mltable) med kolonnene group, metric_name, metric_value, threshold_value

Setup (Azure CLI YAML):

create_monitor:
  monitoring_signals:
    customSignal:
      type: custom
      component_id: azureml:my_custom_signal:1.0.0
      input_data:
        production_data:
          input_data:
            type: uri_folder
            path: azureml:my_production_data:1
          data_context: test
          data_window:
            lookback_window_size: P30D
            lookback_window_offset: P7D
          pre_processing_component: azureml:custom_preprocessor:1.0.0
      metric_thresholds:
        - metric_name: std_deviation
          threshold: 2

Verified (MCP): Custom signals støttes via registrerte Azure ML components.

---

Beslutningsveiledning

Når bruke hvilken monitoring signal?

Scenario	Anbefalt Signal	Begrunnelse
Nylig deployed modell	Data Drift + Data Quality	Rask deteksjon av input-endringer
Høy business-kritikalitet	Data Drift + Prediction Drift + Feature Attribution Drift	Bred overvåking fra flere vinkler
Ground truth tilgjengelig	Model Performance	Objektiv ytelse-tracking
Mange features (100+)	Top N Feature Importance	Reduserer noise og compute-kostnad
Regulert sektor	Alle signals + Custom metrics	Full audit trail og compliance

Valg av reference data

Reference Data	Best For	Tradeoff
Training data	Data drift, data quality	Statisk baseline – oppdager endringer fra opprinnelig distribusjon
Validation data	Prediction drift	Sammenligner mot test-distribusjon
Recent past production data	Rolling baseline	Adaptiv – følger endringer over tid, men kan skjule gradvis drift
Ground truth data	Model performance	Krever kontinuerlig innsamling av faktiske utfall

Monitoring-frekvens

Data-volum	Anbefalt Frekvens	Rationale
Høy trafikk (1000+ requests/dag)	Daglig	Nok data for statistisk signifikans
Moderat trafikk (100-1000/dag)	Ukentlig	Samle nok data før analyse
Lav trafikk (<100/dag)	Månedlig	Unngå falske positiver fra små samples

Best practice: Start med daglig monitoring og juster basert på alert fatigue og datainnsamling.

---

Integrasjon med Microsoft-stakken

Azure Machine Learning

• Online Endpoints: Automatisk data collection med azureml.monitoring.ModelDataCollector
• Batch Endpoints: Manuell datainnsamling (krever custom preprocessing component)
• MLflow: Modell-registrering med lineage tracking
• Azure ML Pipelines: Automatisk retraining-workflows

Verified (MCP): Data collector støtter online endpoints; batch endpoints krever custom preprocessing.

Azure Event Grid

• System Topics: Azure ML workspace events
• Event Types: Run status changed (ikke Dataset drift detected – deprecated v1)
• Event Handlers: Azure Functions, Logic Apps, Event Hubs
• Advanced Filters: Filter på azureml_modelmonitor_threshold_breached tag

Eksempel Event Grid-integrasjon:

1. Opprett Event Grid system topic for workspace
2. Opprett event subscription med filter:
   • Key: data.RunTags.azureml_modelmonitor_threshold_breached
   • Operator: String contains
   • Value: <monitor-name>_<signal-description> (f.eks. credit_monitor_data_drift)
3. Konfigurer endpoint (Event Hubs, Azure Function)
4. Trigger ML pipeline for retraining ved drift

Verified (MCP): Event Grid-integrasjon er dokumentert for automated response.

Azure Monitor & Application Insights

• Metrics: Online endpoint metrics (CPU, memory, RequestsPerMinute)
• Logs: Monitoring job execution logs
• Alerts: Custom alerting på metrics (komplementær til built-in alerts)
• Dashboards: Visualisering av drift metrics over tid

Azure Blob Storage

• Production inference data: Automatisk lagring fra data collector
• Monitoring artifacts: Metrics i JSON-format
• Ground truth data: Manuell opplasting av faktiske utfall

---

Offentlig sektor (Norge)

Utredningsinstruksen (§ 13)

Modell-monitoring adresserer flere krav:

• § 13.1 (Konsekvensvurdering): Kontinuerlig validering av modellens faktiske effekt i produksjon
• § 13.5 (Evaluering): Systematisk oppfølging av modellytelse mot fastsatte mål
• § 13.6 (Revidering): Automatisk varsling ved degradering som kan trigge revidering

Anbefaling: Sett alert thresholds i samsvar med målkriterier fra konsekvensvurdering.

Digdir AI-prinsipper

Prinsipp	Hvordan Model Monitoring Støtter
Transparens	Loggfør alle drift-deteksjoner og threshold-brudd for audit trail
Ansvarlig bruk	Objektiv ytelse-tracking mot ground truth sikrer kvalitet
Personvern	Data drift detection kan identifisere endringer i sensitive features
Robusthet	Kontinuerlig validering av modell-stabilitet i produksjon

DPIA og ROS-analyser

• Datakvalitet: Data quality signal detekterer null-verdier og out-of-bounds som kan være privacy-risiko
• Bias-deteksjon: Feature attribution drift kan indikere endret bias i produksjon
• Incident response: Event Grid-integrasjon muliggjør rask respons ved avvik

NSM Grunnprinsipper for IKT-sikkerhet

• Logging (GP4): Alle monitoring-kjøringer logges med timestamp og resultat
• Overvåking (GP5): Kontinuerlig overvåking av modell-atferd i produksjon
• Incident management (GP7): Automatisk varsling via Event Grid ved threshold-brudd

Anbefaling: Integrer monitoring alerts med SIEM/SOC for koordinert respons.

---

Kostnad og lisensiering

Azure Machine Learning Pricing

Komponent	Kostnadsdriver	Estimat (NOK/måned)
Serverless Spark Compute	VM-timer (Standard_E4s_v3: ~$0.54/time)	Avhenger av data-volum og frekvens
Storage (Blob)	Production inference data (Standard, hot tier: ~$0.02/GB)	Lav kostnad for de fleste workloads
Data Collector	Ingen ekstra kostnad (inkludert i endpoint)	0 NOK
Event Grid	Events ($0.60 per million operations)	Neglisjerbar

Eksempel-beregning (daglig monitoring, 100K rows/dag):

• Spark job (15 min/dag): ~0.5 timer/måned × $0.54 = ~$0.27 ≈ 3 NOK/måned
• Storage (3 GB/måned): 3 × $0.02 = ~$0.06 ≈ 0.60 NOK/måned
• Total: ~3.60 NOK/måned (ekskl. endpoint-kostnader)

Baseline: Modell-monitoring er relativt billig sammenlignet med kostnaden av modell-degradering.

Lisensiering

• Azure ML Workspace: Ingen lisenskostnad (pay-per-use for compute/storage)
• Event Grid: Ingen lisenskostnad (pay-per-event)
• Azure Monitor: Inkludert i Azure-subscriptions

Verified (MCP): Pricing-estimater basert på Azure offentlig prisliste (januar 2026).

Kostnadsoptimalisering

1. Monitor top N features – reduser antall features som overvåkes
2. Juster monitoring-frekvens – ukentlig/månedlig for lav-trafikk-modeller
3. Lookback window size – balanser statistisk signifikans vs. compute-kostnad
4. Use recent past production data som baseline (ingen storage av treningsdata)

---

For arkitekten (Cosmo)

Quick Decision Framework

Spørsmål til kunde:

1. Er modellen deployed til Azure ML online endpoint?

   • Ja → Bruk out-of-box monitoring med data collector
   • Nei → Manuell datainnsamling + custom preprocessing component

2. Har dere tilgang til ground truth data?

   • Ja → Inkluder model performance signal
   • Nei → Data drift + prediction drift + data quality

3. Hvor mange features har modellen?

   • <20 → Monitor alle features
   • 20-100 → Monitor top N (N=10-20)

   • 100 → Feature subset eller top N (N=20-30)

4. Hvor kritisk er modellen for business?

   • Høy → Daglig monitoring + Event Grid + automatisk retraining
   • Moderat → Ukentlig monitoring + email alerts
   • Lav → Månedlig monitoring

5. Er dette regulert sektor?

   • Ja → Alle signals + custom metrics + full audit trail
   • Nei → Standard signals (data drift, prediction drift, data quality)

Typiske Anti-patterns

Anti-pattern	Hvorfor Dette er Dårlig	Anbefaling
Ingen monitoring	Modellen degraderer uten deteksjon	Start med out-of-box monitoring umiddelbart
For mange features	Alert fatigue, høy compute-kostnad	Top N feature importance
For høy frekvens	Unødvendig compute-kostnad for lav-trafikk	Juster til ukentlig/månedlig
Ingen Event Grid	Manuell respons ved drift	Automatiser retraining-workflow
Training data som baseline alltid	Kan være outdated etter år	Vurder rolling baseline (recent past production data)

Integration Checklist

• Data collection aktivert (online endpoints) eller custom preprocessing (batch/external)
• Reference data registrert som Azure ML data asset
• Monitoring signals konfigurert (minimum data drift + data quality)
• Alert thresholds satt basert på business-kritikalitet
• Email notifications til data science team
• Event Grid subscription for automatisk respons (optional men anbefalt)
• Monitoring frekvens justert til datainnsamling-rate
• Lookback windows konfigurert (ingen overlapping)
• Feature subset/top N valgt (hvis mange features)
• Ground truth pipeline etablert (hvis model performance signal)

Arkitektur-templates

Template 1: Basic Monitoring (Small Team, Low Complexity)

Azure ML Online Endpoint (data collector)
    ↓
Blob Storage (production inference data)
    ↓
Serverless Spark (daily monitoring)
    ↓
Email Alerts (threshold breach)

Template 2: Advanced Monitoring (Enterprise, High Criticality)

Azure ML Online Endpoint (data collector)
    ↓
Blob Storage (production + ground truth data)
    ↓
Serverless Spark (daily monitoring: drift + performance)
    ↓
Event Grid (threshold breach event)
    ↓
Azure Function (trigger retraining pipeline)
    ↓
Azure ML Pipeline (automated retraining + deployment)

Template 3: Batch/External Deployment

External Model (manual data collection)
    ↓
Azure ML Data Asset (registered production data)
    ↓
Custom Preprocessing Component (format to mltable)
    ↓
Serverless Spark (weekly monitoring)
    ↓
Email Alerts + Azure Monitor Dashboard

Conversation Starters

• "Har modellen din endret atferd siden den ble deployet?"
• "Hvor lang tid tar det før dere oppdager at modellen gir dårlige prediksjoner?"
• "Har dere tilgang til faktiske utfall (ground truth) for å validere modell-nøyaktighet?"
• "Hvor mange features monitorer dere – og er de alle like viktige?"
• "Hva skjer når en threshold brytes – har dere en plan for respons?"

---

Kilder og verifisering

Microsoft Learn (MCP-verified)

1. Azure Machine Learning model monitoring (Concept) https://learn.microsoft.com/en-us/azure/machine-learning/concept-model-monitoring?view=azureml-api-2 Verified: 2026-04 via microsoft_docs_fetch

   • Monitoring signals, metrics, reference data, lookback windows

2. Monitor the 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: 2026-04 via microsoft_docs_fetch

   • Setup guides (CLI, SDK, Studio), Event Grid integration, interpret results

3. Data drift (preview) will be retired, and replaced by Model Monitor https://learn.microsoft.com/en-us/azure/machine-learning/how-to-monitor-datasets?view=azureml-api-1 Verified: 2026-04 via microsoft_docs_search (3 results)

   • Legacy DataDriftDetector (v1) vs. Model Monitor (v2)

4. Trigger applications, processes, or CI/CD workflows based on Azure Machine Learning events https://learn.microsoft.com/en-us/azure/machine-learning/how-to-use-event-grid?view=azureml-api-2 Verified: 2026-04 via microsoft_docs_search

   • Event Grid integration, advanced filters

5. Machine learning operations (MLOps v2) https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/machine-learning-operations-v2 Verified: 2026-04 via microsoft_docs_search (multiple references)

   • Data drift, prediction drift, resource monitoring

Code Samples (MCP-verified)

1. Model monitoring setup (Python SDK v2) https://learn.microsoft.com/en-us/azure/machine-learning/how-to-monitor-model-performance Verified: 2026-04 via microsoft_code_sample_search

   • Out-of-box monitoring, advanced monitoring, model performance

2. DataDriftDetector (Python SDK v1 – deprecated) https://learn.microsoft.com/en-us/python/api/azureml-datadrift/azureml.datadrift.datadriftdetector Verified: 2026-04 via microsoft_code_sample_search

   • Legacy API for comparison

3. Custom signal component examples https://github.com/Azure/azureml-examples/tree/main/cli/monitoring/components/custom_signal Referenced: 2026-04 in Microsoft Learn documentation

Confidence Markers

Seksjon	Confidence	Kilde
Introduksjon	Verified	MCP: concept-model-monitoring (GA status confirmed)
Kjernekomponenter	Verified	MCP: monitoring signals table, metrics, data collector
Arkitekturmønstre	Verified	MCP: code samples (Python SDK v2)
Beslutningsveiledning	Baseline	Cosmo's expertise + best practices fra docs
Integrasjon med Microsoft-stakken	Verified	MCP: Event Grid, Azure Monitor, Blob Storage
Offentlig sektor	Baseline	Cosmo's domain knowledge + norsk lovverk
Kostnad og lisensiering	Baseline	Azure offentlig prisliste (januar 2026)

Sist oppdatert

2026-04 – Basert på Microsoft Learn-dokumentasjon (azure-ai-ml SDK v2, API version 2).

Azure ML Model Drift & Performance Degradation Monitoring (2026)

Model monitoring provides continuous tracking of production model performance:

Degradation signals:

• Prediction drift: Output distribution shifts away from training baseline
• Feature attribution drift: Feature importance changes indicate concept drift
• Data quality degradation: Input data quality issues upstream
• Performance metric degradation: Track against ground truth when labels available

Monitoring configuration:

# Set up monitoring for deployed models on online endpoints
# Azure ML handles data collection and signal computation
# Monitoring jobs run on schedule (default: daily)

Alert thresholds (recommended):

• Data drift coefficient > 0.1: Investigate
• Data drift coefficient > 0.3: Retrain trigger
• Prediction drift > 15%: Production alert
• Unusable nodes > 0: Infrastructure alert (Azure Monitor)

Continuous learning loop:

1. Monitor signals → detect drift early
2. Critically evaluate inherent model risks
3. Identify hidden problems before business impact
4. Trigger retraining or model update workflow
5. Validate new model before rollout (blue-green/canary)

Integration: Azure Event Grid for alerting → Logic Apps / Functions → automated retraining trigger

For GenAI/LLM: MLflow 3 production monitoring reuses development scorers (Groundedness, Relevance) on production traces — consistent quality measurement throughout lifecycle.