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,365 @@
|
|||
# Data Drift Monitoring and Detection
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** MLOps & GenAIOps
|
||||
|
||||
---
|
||||
|
||||
## 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:
|
||||
|
||||
```python
|
||||
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.
|
||||
|
||||
```python
|
||||
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`
|
||||
|
||||
**Azure AI Foundry (tidligere Azure AI Studio)** (Baseline + Verified)
|
||||
For generative AI workloads: Azure AI 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 Azure AI 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-02):**
|
||||
- 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
|
||||
Loading…
Add table
Add a link
Reference in a new issue