ms-ai-architect/skills/ms-ai-engineering/references/mlops-genaiops/automated-retraining-pipelines.md

# Automated Retraining Pipelines and Scheduling

**Last updated:** 2026-06-19
**Status:** GA
**Category:** MLOps & GenAIOps

---

## Introduksjon

Maskinlæringsmodeller degraderes over tid på grunn av data drift, concept drift og endringer i produksjonsmiljøet — et fenomen kjent som **model decay**. Automatisert retraining av modeller er derfor en kritisk komponent i moderne MLOps-arkitekturer, som sikrer at produksjonsmodeller opprettholder ytelse og relevans uten manuell intervensjon.

Azure Machine Learning og Azure Databricks tilbyr komplementære løsninger for automatiserte retraining pipelines med planlegging (scheduling), hvor Azure ML fokuserer på code-first MLOps-workflows med integrert pipeline-orkestrering, mens Databricks tilbyr en lakehouse-basert tilnærming med Unity Catalog som sentralt governance-lag.

**Verified (MCP):** Azure Machine Learning SDK v2 og CLI v2 tilbyr native støtte for recurrence-baserte og cron-baserte schedules for pipeline-kjøringer, mens Azure Databricks støtter både scheduled og triggered retraining via Databricks Jobs og SQL-alerts.

Automatisert retraining omfatter tre hovedkomponenter:

1. **Training pipeline** — kode som transformerer data, trener modellen og logger artefakter
2. **Scheduling mechanism** — tidsbaserte triggere (recurrence eller cron) eller event-baserte triggere (data drift, performance degradering)
3. **Validation & deployment pipeline** — automatisk validering av ny modellversjon og deployment til produksjon

**Baseline:** GenAI-modeller (LLM-er) har typisk annen retraining-strategi enn tradisjonelle ML-modeller, med fokus på prompt engineering, RAG-optimalisering og fine-tuning i stedet for full retraining.

---

## Kjernekomponenter

### 1. Pipeline Scheduling i Azure Machine Learning

Azure ML tilbyr to triggeringsmekanismer for pipeline-schedules:

**Recurrence-basert scheduling:**
- Enkel tidsbasert repetering (minutter, timer, dager, uker, måneder)
- Støtter komplekse mønstre (f.eks. "hver mandag og onsdag kl. 18:30")
- YAML-eksempel:

```yaml
trigger:
  type: recurrence
  frequency: day
  interval: 1
  schedule:
    hours: [4,5,10,11,12]
    minutes: [0,30]
  start_time: "2026-02-10T10:00:00"
  time_zone: "Europe/Oslo"
```

**Verified (MCP):** Python SDK v2 tilbyr `RecurrenceTrigger` med `RecurrencePattern` for å definere komplekse mønstre:

```python
from azure.ai.ml.entities import JobSchedule, RecurrenceTrigger, RecurrencePattern
from azure.ai.ml.constants import TimeZone

recurrence_trigger = RecurrenceTrigger(
    frequency="day",
    interval=1,
    schedule=RecurrencePattern(hours=10, minutes=[0, 1]),
    start_time=datetime.utcnow(),
    time_zone=TimeZone.UTC,
)

job_schedule = JobSchedule(
    name="daily_retraining_schedule",
    trigger=recurrence_trigger,
    create_job=pipeline_job
)

ml_client.schedules.begin_create_or_update(schedule=job_schedule).result()
```

**Cron-basert scheduling:**
- Standard crontab-syntaks for fleksible mønstre
- Format: `MINUTES HOURS * * DAYS-OF-WEEK` (DAYS og MONTHS behandles alltid som `*`)
- Eksempel: `15 16 * * 1` = hver mandag kl. 16:15 UTC

```python
from azure.ai.ml.entities import CronTrigger

cron_trigger = CronTrigger(
    expression="0 2 * * *",  # Hver natt kl. 02:00
    start_time=datetime.utcnow(),
    time_zone="Eastern Standard Time",
)

job_schedule = JobSchedule(
    name="nightly_retraining",
    trigger=cron_trigger,
    create_job=pipeline_job
)
```

**Verified (MCP):** Schedules kan oppdatere pipeline-parametere ved hver kjøring, f.eks. via `${{name}}` (job-navn) eller `${{creation_context.trigger_time}}` (trigger-tid) som makroer i input-stier eller string-parametere.

### 2. Retraining Pipeline Arkitektur

En komplett retraining-pipeline består typisk av flere **tasks** orkestrert som en multi-task workflow:

**Task 1: Model Training**
- Last inn nyeste produksjonsdata fra data catalog (Unity Catalog eller Azure ML datastores)
- Kjør feature engineering (on-demand features eller feature tables)
- Tren modellen med valgte hyperparametere (kan være statiske eller dynamiske)
- Logg modell, metrics og parametere til MLflow Tracking Server
- Registrer modellen til Unity Catalog (Databricks) eller Azure ML Model Registry

**Verified (MCP):** Azure ML støtter `AutoMLStep` for automatisk feature selection og algorithm selection i pipelines, men for produksjonsretraining anbefales det å begrense tuning til top-performing options for å redusere variance.

**Task 2: Model Validation**
- Last modell fra registry via model URI (fra Task 1)
- Kjør pre-deployment checks:
  - Format- og metadata-validering
  - Performance-evaluering på test-sett eller data slices
  - Compliance-sjekker (regulatoriske krav, organisatoriske policies)
- Sett "Challenger"-alias hvis validering lykkes
- Logg resultat som tags/annotations på modellversjon

**Task 3: Model Deployment**
- Sammenlign "Challenger" mot eksisterende "Champion"-modell
  - **Offline:** Evaluer begge på holdt-ut datasett
  - **Online:** A/B-testing eller gradvis rollout
- Oppdater "Champion"-alias til ny modell hvis performance er bedre
- Oppdater Model Serving endpoint (real-time) eller batch inference pipeline

**Verified (MCP):** Azure ML støtter `task values` for å sende model URI mellom tasks i en pipeline, f.eks.:

```python
from azureml.pipeline.core import Pipeline

pipeline = Pipeline(ws, [train_step, validate_step, deploy_step])
```

### 3. Triggered Retraining (Event-Driven)

**Scheduled retraining** er enklest å implementere, men **triggered retraining** gir raskere respons på endringer:

**Databricks-mønster (Verified MCP):**
1. **Data profiling pipeline** leser logs fra batch/streaming/online inference
2. Beregner metrics (data drift, model performance, infrastructure)
3. Skriver metrics til tabeller i production catalog
4. **SQL alert** sjekker om metric overskrider threshold
5. Alert konfigureres med **webhook destination** som trigger training workflow

Eksempel SQL-alert som trigger retraining:

```sql
-- Alert trigger hvis accuracy faller under 85%
SELECT AVG(accuracy) as avg_accuracy
FROM prod.monitoring.model_metrics
WHERE timestamp >= current_date() - INTERVAL 7 DAYS

-- Webhook destination: <databricks-job-url>
```

**Azure ML-mønster (Baseline):**
Azure ML SDK v2 støtter ikke event-based triggers natively, men kan integreres med:
- **Azure Event Grid** for lifecycle events (model registered, deployment completed)
- **Azure Data Factory** for external orchestration med event triggers
- **Azure Functions** med HTTP triggers som starter Azure ML pipelines via REST API

**Verified (MCP):** Azure ML schedules kan kalles via REST endpoint:

```python
# Publish pipeline to get REST endpoint
published_pipeline = pipeline_run.publish_pipeline(
    name="Retraining Pipeline",
    description="Automated model retraining"
)

rest_endpoint = published_pipeline.endpoint
# Use with OAuth 2.0 bearer token for authentication
```

### 4. Pipeline Inputs og Runtime Settings

**Verified (MCP):** Ved scheduling kan du overstyre pipeline-settings, inputs og outputs:

```yaml
create_job:
  type: pipeline
  job: ./pipeline.yml
  settings:
    continue_on_step_failure: true
    default_compute: azureml:cpu-cluster
  inputs:
    training_data: ${{name}}  # Dynamisk satt til schedule-navn
  tags:
    schedule: nightly_retraining
```

Dette gjør det mulig å opprette **multiple schedules** for samme pipeline med forskjellige parametere (f.eks. forskjellige datasett eller hyperparametere).

---

## Arkitekturmønstre

### Mønster 1: Periodic Scheduled Retraining (Azure ML)

**Use case:** Ny treningsdata tilgjengelig med jevne intervaller (daglig, ukentlig).

**Arkitektur:**
1. **Schedule** trigger pipeline hver natt kl. 02:00 (cron: `0 2 * * *`)
2. **Training pipeline** henter latest data fra registered dataset eller datastore
3. **Validation** sammenligner ny modell mot baseline metrics
4. **Deployment** oppdaterer batch inference endpoint eller Model Serving

**Fordeler:**
- Enkel å implementere og forstå
- Forutsigbar ressursbruk (kan bruke reserved capacity)
- God for use cases med regular data refresh

**Ulemper:**
- Reagerer ikke umiddelbart på drift eller performance issues
- Kan trene unødvendig ofte hvis data ikke har endret seg

**Kodeeksempel (Verified MCP):**

```python
from azure.ai.ml import MLClient, load_job
from azure.ai.ml.entities import JobSchedule, CronTrigger

ml_client = MLClient.from_config()

# Last eksisterende pipeline
pipeline_job = load_job("./training_pipeline.yml")

# Opprett nattlig schedule
cron_trigger = CronTrigger(
    expression="0 2 * * *",
    time_zone="Europe/Oslo"
)

schedule = JobSchedule(
    name="nightly_model_retraining",
    trigger=cron_trigger,
    create_job=pipeline_job
)

ml_client.schedules.begin_create_or_update(schedule).result()
```

### Mønster 2: Triggered Retraining via Monitoring (Databricks)

**Use case:** Retraining kun når data drift eller performance degradering detekteres.

**Arkitektur (Verified MCP):**
1. **Inference pipeline** logger predictions til Unity Catalog tables
2. **Data profiling pipeline** (scheduled hourly) beregner:
   - Data drift metrics (distribution changes)
   - Model performance (accuracy, F1-score vs. ground truth)
   - Infrastructure metrics (latency, throughput)
3. **SQL alert** trigger når metric overskrider threshold:
   ```sql
   SELECT AVG(drift_score) as avg_drift
   FROM prod.monitoring.data_drift
   WHERE timestamp >= current_timestamp() - INTERVAL 1 HOUR
   HAVING avg_drift > 0.3  -- Threshold for retraining
   ```
4. Alert webhook starter **training workflow** via Databricks Jobs API
5. Training pipeline kjører full training → validation → deployment cycle

**Fordeler:**
- Rask respons på faktiske endringer
- Redusert ressursbruk (ingen unødvendig retraining)
- Self-healing system (automatic recovery fra model decay)

**Ulemper:**
- Mer kompleks å sette opp
- Krever robust monitoring infrastructure
- Potensiale for "thrashing" hvis thresholds ikke er riktig kalibrert

### Mønster 3: Hybrid Scheduled + Triggered (Azure ML + Event Grid)

**Baseline:** Kombinerer periodic baseline retraining med event-driven responses.

**Arkitektur:**
1. **Baseline schedule:** Ukentlig full retraining (søndag natt)
2. **Event-driven:** Azure Event Grid subscriber på:
   - Dataset updated events (når ny data publiseres)
   - Custom metrics events (fra monitoring system)
3. Event trigger Azure Function som kaller Azure ML pipeline REST endpoint
4. Pipeline har conditional logic for å hoppe over retraining hvis siste versjon er nylig (<24h gammel)

**Fordeler:**
- Best of both worlds (forutsigbarhet + responsiveness)
- Unngår duplicate retraining ved overlappende triggers

**Ulemper:**
- Krever flere Azure-tjenester (Event Grid, Functions)
- Mer kompleks dependency management

---

## Beslutningsveiledning

### Når bruke scheduled vs. triggered retraining?

| Kriterium | Scheduled | Triggered |
|-----------|-----------|-----------|
| **Data refresh-frekvens** | Regulær (daglig/ukentlig) | Uregelmessig eller kontinuerlig |
| **Model decay rate** | Langsom og forutsigbar | Rask eller uforutsigbar |
| **Compliance-krav** | Trenger dokumentert retraining-kadanse | Trenger bevis for continuous monitoring |
| **Ressursbudsjettering** | Reserved capacity (forutsigbar kostnad) | On-demand (variabel kostnad) |
| **Time-to-recovery** | Akseptabelt med dager/uker | Krever timer eller mindre |
| **Kompleksitet** | Lav (enkelt å vedlikeholde) | Høy (krever monitoring infrastructure) |

**Anbefaling for offentlig sektor (Norge):**
- **Start med scheduled retraining** (enklere å godkjenne i arkitekturgjennomgang)
- **Implementer triggered retraining** kun hvis dokumentert behov for rapid response
- Kombiner med **manual approval step** for kritiske modeller (compliance)

### Valg mellom Azure ML og Databricks

| Feature | Azure ML | Databricks |
|---------|----------|------------|
| **Native scheduling** | ✅ SDK v2 (recurrence + cron) | ✅ Databricks Jobs (cron + event) |
| **Event-driven triggers** | ❌ (via Event Grid/ADF) | ✅ (SQL alerts + webhooks) |
| **Data governance** | Azure ML datastores | Unity Catalog (bedre governance) |
| **Model registry** | Azure ML Model Registry | Unity Catalog Models (med aliaser) |
| **AutoML integration** | ✅ AutoMLStep i pipelines | ✅ AutoML på Databricks Runtime |
| **Hybrid cloud support** | ❌ (kun Azure) | ✅ (multi-cloud med Unity Catalog) |
| **Cost visibility** | Logic App charges (HOBO) | Databricks Jobs (transparent) |

**Verified (MCP):** Azure ML schedules oppretter en Logic App som hostes "on behalf of" (HOBO) brukeren, og kostnaden belastes via samme meter som Azure ML workspace.

**Anbefaling:**
- **Azure ML:** Hvis allerede investert i Azure ML ecosystem, enkle use cases, AutoML-behov
- **Databricks:** For lakehouse-arkitekturer, kompleks governance, multi-cloud requirements

---

## Integrasjon med Microsoft-stakken

### Azure Machine Learning Pipelines

**Verified (MCP):** Azure ML SDK v2 bruker **component-based pipelines** hvor hver komponent er en gjenbrukbar kode-modul:

```python
from azure.ai.ml import command, Input, Output
from azure.ai.ml.constants import AssetTypes

# Definer training component
train_component = command(
    name="train_model",
    display_name="Model Training",
    inputs={
        "training_data": Input(type=AssetTypes.URI_FOLDER),
        "max_epochs": Input(type="integer", default=20),
        "learning_rate": Input(type="number", default=0.001),
    },
    outputs={
        "model_output": Output(type=AssetTypes.MLFLOW_MODEL),
    },
    code="./src",
    command="python train.py --data ${{inputs.training_data}} --epochs ${{inputs.max_epochs}}",
    environment="azureml:my-training-env@latest",
)

# Bruk i pipeline
@pipeline()
def training_pipeline(training_data, max_epochs):
    train_step = train_component(
        training_data=training_data,
        max_epochs=max_epochs
    )
    validate_step = validate_component(model=train_step.outputs.model_output)
    deploy_step = deploy_component(model=validate_step.outputs.validated_model)
    return {"deployed_model": deploy_step.outputs.endpoint_url}
```

### Azure Databricks MLOps Workflow

**Verified (MCP):** Databricks anbefaler "deploy code, not models" — promoter kode fra dev → staging → prod branches:

1. **Dev catalog:** Data scientists har read-write access, trener modeller interaktivt
2. **Staging catalog:** CI/CD pipeline kjører integration tests på staging data
3. **Prod catalog:** Automated retraining pipeline kjører på production data, ML engineers har read-write access

**Unity Catalog model aliasing:**
```python
from databricks import unity_catalog

# Training pipeline output
model_uri = "models:/prod.ml_models.fraud_detection/12"  # Version 12

# Validation pipeline
uc_client = unity_catalog.get_client()
uc_client.set_model_version_tag(
    model_uri,
    key="validation_status",
    value="PASSED"
)

# Deployment pipeline - sammenlign Challenger vs Champion
challenger_uri = "models:/prod.ml_models.fraud_detection@Challenger"
champion_uri = "models:/prod.ml_models.fraud_detection@Champion"

if challenger_accuracy > champion_accuracy:
    uc_client.set_registered_model_alias(
        name="prod.ml_models.fraud_detection",
        alias="Champion",
        version=12
    )
```

### Azure DevOps / GitHub Actions Integration

**Baseline:** CI/CD pipelines kan automatisere deployment av retraining schedules:

```yaml
# .github/workflows/deploy-retraining-schedule.yml
name: Deploy Retraining Schedule

on:
  push:
    branches: [main]
    paths: [pipelines/training/**]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Deploy Azure ML Schedule
        run: |
          az ml schedule create \
            --file schedules/nightly-retraining.yml \
            --resource-group ${{ secrets.RG_NAME }} \
            --workspace-name ${{ secrets.WORKSPACE_NAME }}
```

---

## Offentlig sektor (Norge)

### Utredningsinstruksen og Retraining

**Relevant for:** Automatisert retraining i AI-systemer som behandler personopplysninger eller påvirker borgernes rettigheter.

**Krav:**
1. **Dokumentasjon av retraining-strategi** i AI-utredningen (kapittel 4: Teknisk løsning)
   - Frekvens for retraining (scheduled vs. triggered)
   - Validering av nye modellversjoner før deployment
   - Rollback-prosedyre ved performance degradering

2. **Logging og sporbarhet:**
   - Alle retraining-kjøringer må logges med timestamp, data version, model version
   - MLflow/Unity Catalog gir automatisk lineage tracking
   - Eksporter audit logs til langtidslagring (arkivloven)

3. **Human-in-the-loop for kritiske modeller:**
   - Automatisert retraining kan kjøre validation, men final deployment krever manuell godkjenning
   - Implementer approval gates i Azure DevOps Pipelines eller Databricks workflows

**Eksempel approval gate (Azure DevOps):**

```yaml
# azure-pipelines.yml
stages:
  - stage: Train
    jobs:
      - job: RunTraining
        steps:
          - script: az ml job create --file training-pipeline.yml

  - stage: Validate
    jobs:
      - job: ValidateModel
        steps:
          - script: python validate_model.py

  - stage: Deploy
    dependsOn: Validate
    jobs:
      - deployment: DeployModel
        environment: production  # Krever manual approval i Azure DevOps
        strategy:
          runOnce:
            deploy:
              steps:
                - script: python deploy_model.py
```

### DPIA-vurdering av Automatisert Retraining

**Personvernrisiko:**
- **Ny treningsdata kan introdusere bias** → krever automated bias detection i validation pipeline
- **Model drift kan påvirke beslutninger** → implementer A/B testing før full rollout
- **Logging av retraining kan inkludere persondata** → pseudonymiser eller anonymiser logs

**Tiltak:**
- Bruk Azure ML differential privacy features for sensitive data
- Implementer fairness metrics i validation pipeline (Fairlearn integration)
- Dokumenter data retention policy for training data og logs

### Digdir Cloud Strategy og Multi-Cloud Retraining

**Databricks fordel:** Unity Catalog støtter multi-cloud (Azure + AWS + GCP), nyttig for:
- **Data residency-krav** (treningsdata i Norge, inference i andre regioner)
- **Vendor lock-in avoidance** (kan flytte retraining pipeline mellom clouds)

**Azure ML begrensning:** Kun Azure-native, men kan integreres med Azure Arc for hybrid cloud.

---

## Kostnad og lisensiering

### Azure Machine Learning Schedule Costs

**Verified (MCP):** Schedules oppretter en Logic App (HOBO-ressurs) som belastes brukeren:

| Komponent | Kostnad | Forklaring |
|-----------|---------|------------|
| **Schedule (Logic App)** | ~$0.000025 per trigger | Standard Logic App pricing |
| **Pipeline compute** | Varierer (per SKU) | Compute for training/validation/deployment tasks |
| **Storage** | ~$0.02/GB/måned | MLflow artifacts, logs, model registry |

**Eksempel (nattlig retraining):**
- 30 triggers/måned × $0.000025 = $0.00075/måned (neglisjerbart)
- Compute (Standard_DS12_v2, 2 timer/natt): ~$0.28/time × 60 timer/måned = $16.80/måned
- **Total estimat:** ~$17/måned (eksklusive storage)

**Kostnadsoptimalisering:**
- Bruk **spot instances** (Azure ML low-priority compute) for training — 60-80% rabatt
- Reduser retraining-frekvens hvis mulig (ukentlig vs. daglig)
- Bruk **incremental learning** i stedet for full retraining hvis mulig

### Azure Databricks Schedule Costs

**Databricks Jobs (retraining):**
- **DBU cost:** ~$0.40/DBU (Jobs compute tier, region-avhengig)
- **VM cost:** Underliggende Azure VMs (f.eks. Standard_DS3_v2: ~$0.20/time)
- **Unity Catalog:** Inkludert i Databricks-lisens (ingen ekstra kostnad)

**Eksempel (nattlig retraining på cluster med 4 nodes):**
- 4 nodes × 2 DBU/node × 2 timer × 30 dager = 480 DBU/måned
- 480 DBU × $0.40 = $192/måned (DBU cost)
- VM cost: 4 nodes × $0.20/time × 2 timer × 30 dager = $48/måned
- **Total estimat:** ~$240/måned

**Kostnadsoptimalisering:**
- Bruk **job clusters** (auto-terminate etter kjøring) vs. all-purpose clusters
- Implementer **conditional retraining** (skip hvis data ikke har endret seg)
- Reduser cluster size (scale down nodes for mindre datasett)

### Lisensieringskrav

| Plattform | Lisens | Retraining Support |
|-----------|--------|-------------------|
| **Azure ML** | Gratis (betaler kun compute/storage) | ✅ Native scheduling |
| **Databricks** | Premium eller Enterprise | ✅ Jobs + Unity Catalog |
| **Azure DevOps** | Basic (gratis for <5 brukere) | ✅ CI/CD pipelines |
| **GitHub Actions** | Gratis (public repos, 2000 min/måned private) | ✅ CI/CD workflows |

**For offentlig sektor (Norge):**
- Azure ML er typisk allerede inkludert i enterprise agreement
- Databricks krever separat lisens (Premium tier minimum for Unity Catalog)
- Vurder **total cost of ownership** (TCO) over 3 år, ikke bare lisenskostnad

---

## For arkitekten (Cosmo)

### Spørsmål å stille klienten

1. **Data refresh-frekvens:**
   - "Hvor ofte får dere ny treningsdata?" (daglig/ukentlig/kontinuerlig)
   - "Hvor raskt må modellen respondere på endringer i data?" (timer/dager/uker)

2. **Model decay-karakteristikk:**
   - "Har dere erfaring med hvor raskt modellen degraderes i produksjon?"
   - "Finnes det sesongvariasjoner eller plutselige regime shifts?"

3. **Compliance og governance:**
   - "Krever modellendringer manuell godkjenning før deployment?"
   - "Må alle retraining-kjøringer dokumenteres for revisjon/arkivering?"

4. **Eksisterende infrastruktur:**
   - "Bruker dere allerede Azure ML eller Databricks for ML-utvikling?"
   - "Har dere etablert CI/CD-pipelines (Azure DevOps/GitHub Actions)?"

5. **Ressursbudsjettering:**
   - "Hva er budsjett for compute-ressurser til retraining?" (kan påvirke frekvens)
   - "Er det akseptabelt med variabel kostnad (triggered) eller foretrekkes forutsigbar (scheduled)?"

### Arkitekturvalg-flytdiagram

```
START: Trenger dere automatisert retraining?
  |
  ├─> JA → Hvor ofte kommer ny data?
  |         |
  |         ├─> Regulært (daglig/ukentlig) → SCHEDULED RETRAINING
  |         |     |
  |         |     └─> Plattformvalg:
  |         |           ├─> Har Azure ML? → Azure ML Schedules (recurrence/cron)
  |         |           └─> Har Databricks? → Databricks Jobs (scheduled)
  |         |
  |         └─> Uregelmessig/kontinuerlig → TRIGGERED RETRAINING
  |               |
  |               └─> Plattformvalg:
  |                     ├─> Azure ML → Hybrid (Event Grid + Azure Functions)
  |                     └─> Databricks → SQL alerts + webhooks
  |
  └─> NEI → Manual retraining workflow (out of scope)
```

### Trade-offs å kommunisere

| Dimensjon | Scheduled | Triggered |
|-----------|-----------|-----------|
| **Implementeringskompleksitet** | ⭐⭐ (Lav) | ⭐⭐⭐⭐ (Høy) |
| **Time-to-value** | 🟢 Rask (dager) | 🟡 Middels (uker) |
| **Operasjonell robusthet** | 🟢 Høy (enkel troubleshooting) | 🟡 Middels (krever monitoring expertise) |
| **Kostnadseffektivitet** | 🟡 Middels (kan trene unødvendig) | 🟢 Høy (kun når nødvendig) |
| **Compliance-vennlighet** | 🟢 Høy (forutsigbar, lett å dokumentere) | 🟡 Middels (krever event audit trail) |

### Anti-patterns å unngå

1. **Over-engineering:** Ikke implementer triggered retraining hvis scheduled er tilstrekkelig
2. **Insufficient validation:** Aldri deploy retraining uten validation pipeline (minimum accuracy threshold check)
3. **Ignoring cost:** Monitor schedule costs (especially for high-frequency retraining)
4. **Manual steps i automated pipeline:** Bryt heller opp i "automated validation" + "manual approval" + "automated deployment"
5. **Missing rollback:** Ha alltid en plan for å rulle tilbake til forrige "Champion"-modell ved feil

### Anbefalinger for offentlig sektor

1. **Start konservativt:**
   - Implementer scheduled retraining først (ukentlig)
   - Legg til monitoring og alerting
   - Vurder triggered retraining etter 3-6 måneder med produksjonserfaring

2. **Dokumenter alt:**
   - Bruk Azure DevOps wiki eller Confluence til å dokumentere:
     - Retraining schedule rationale
     - Validation criteria
     - Deployment approval process
   - Eksporter MLflow logs til Azure Blob Storage (immutable, retention policy)

3. **Lag human-in-the-loop approval:**
   - For kritiske modeller (helse, rettigheter, økonomi): alltid manuell godkjenning før deployment
   - For lavrisiko modeller: automated deployment med post-deployment monitoring

4. **Implementer observability:**
   - Azure Monitor for pipeline failures
   - Application Insights for model serving latency/errors
   - Custom dashboards (Azure Dashboards eller Power BI) for stakeholders

### Integrasjon med andre AI Architect-filer

- **CI/CD for ML:** Les `cicd-for-ai.md` for pipeline deployment patterns
- **Model monitoring:** Les `model-monitoring.md` for drift detection og alerting
- **Cost optimization:** Les `token-caching-strategies.md` for generell kostnadsoptimalisering
- **Governance:** Les `norwegian-public-sector-checklist.md` for compliance-krav

---

## Kilder og verifisering

### Verified (MCP-kilder)

1. **Azure ML Schedule Documentation:**
   https://learn.microsoft.com/en-us/azure/machine-learning/how-to-schedule-pipeline-job?view=azureml-api-2
   *Verifisert 2026-02:* Recurrence/cron triggers, schedule management, RBAC, cost model (Logic App HOBO)

2. **Databricks MLOps Workflows:**
   https://learn.microsoft.com/en-us/azure/databricks/machine-learning/mlops/mlops-workflow
   *Verifisert 2026-02:* Scheduled vs. triggered retraining, SQL alerts, webhook triggers, Unity Catalog aliasing

3. **Azure ML Code Samples (Python SDK v2):**
   https://github.com/Azure/azureml-examples (via microsoft_code_sample_search)
   *Verifisert 2026-02:* RecurrenceTrigger, CronTrigger, JobSchedule, task values

4. **Azure ML AutoML in Pipelines:**
   https://learn.microsoft.com/en-us/azure/machine-learning/how-to-use-automlstep-in-pipelines?view=azureml-api-1
   *Verifisert 2026-02:* AutoMLStep configuration, data inputs, model registration

### Baseline (Modellkunnskap)

1. **Azure Event Grid integration** (ikke native i Azure ML SDK v2, men well-documented pattern)
2. **Azure DevOps approval gates** (standard DevOps practice, ikke ML-spesifikk)
3. **Databricks multi-cloud capabilities** (general knowledge om Unity Catalog)
4. **Differential privacy i Azure ML** (feature i preview, ikke fully GA)

### Leseverdi for dypere forståelse

- **The Big Book of MLOps** (Databricks): https://www.databricks.com/resources/ebook/the-big-book-of-mlops
- **MLOps Maturity Model:** https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/mlops-maturity-model
- **Azure ML CLI v2 Reference:** https://learn.microsoft.com/en-us/cli/azure/ml/schedule?view=azure-cli-latest

**Total MCP-kilder:** 4 unique URLs
**Total kodeeksempler verifisert:** 8 (Python SDK v2, YAML, SQL)

---

*Denne filen er generert av Cosmo Skyberg, Microsoft AI Solution Architect, som del av AI Architect Plugin kunnskapsbase. Sist oppdatert: 2026-06-19.*