feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command
Add /ultraresearch-local for structured research combining local codebase analysis with external knowledge via parallel agent swarms. Produces research briefs with triangulation, confidence ratings, and source quality assessment. New command: /ultraresearch-local with modes --quick, --local, --external, --fg. New agents: research-orchestrator (opus), docs-researcher, community-researcher, security-researcher, contrarian-researcher, gemini-bridge (all sonnet). New template: research-brief-template.md. Integration: --research flag in /ultraplan-local accepts pre-built research briefs (up to 3), enriches the interview and exploration phases. Planning orchestrator cross-references brief findings during synthesis. Design principle: Context Engineering — right information to right agent at right time. Research briefs are structured artifacts in the pipeline: ultraresearch → brief → ultraplan --research → plan → ultraexecute. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen
commit
baa2d0220b
488 changed files with 213221 additions and 0 deletions
|
|
@ -0,0 +1,699 @@
|
|||
# Automated Retraining Pipelines and Scheduling
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**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-02-04.*
|
||||
Loading…
Add table
Add a link
Reference in a new issue