ms-ai-architect/skills/ms-ai-engineering/references/mlops-genaiops/ab-testing-llm-applications.md

# A/B Testing and Experimentation for AI Models

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

---

**Verified:** MCP 2026-06-19

## Introduksjon

A/B-testing og eksperimentering er kritiske teknikker for å validere og optimalisere AI-modeller i produksjon. I motsetning til tradisjonell programvareutvikling, hvor funksjonalitet er binær (fungerer/fungerer ikke), er AI-modeller probabilistiske — ytelsen deres varierer med data, kontekst og bruksmønster. A/B-testing gjør det mulig å sammenligne modelversjoner, fine-tuning-strategier, prompt-varianter eller RAG-konfigurasjoner under reelle forhold, med ekte brukere og reell trafikk.

For LLM-baserte applikasjoner er eksperimentering spesielt utfordrende. Tradisjonelle metrics (accuracy, F1) fanger ikke subjektive kvaliteter som relevans, tonalitet eller coherence. A/B-testing i GenAI-kontekst krever derfor hybride tilnærminger som kombinerer automatiserte scorers (LLM-as-judge, BLEU, ROUGE), bruker-feedback (thumbs up/down, kvalitative reviews) og business metrics (conversion rate, time-to-resolution).

Azure Machine Learning tilbyr innebygd støtte for A/B-testing via **managed online endpoints** med **traffic splitting**, som gjør det mulig å fordele trafikk mellom flere deployments (f.eks. "blue" for eksisterende modell, "green" for ny kandidat). Dette mønsteret kalles også **canary deployment** eller **progressive rollout** — en liten andel trafikk sendes til den nye modellen først, og andelen økes gradvis etter hvert som confidence i modellen bygges.

---

## Kjernekomponenter

### Azure Machine Learning Managed Online Endpoints

| Komponent | Beskrivelse | Bruk |
|-----------|-------------|------|
| **Endpoint** | En stabil HTTPS-URL for inferens | Klienter kaller samme URL uavhengig av hvilken modell som kjører bak |
| **Deployment** | En spesifikk modellversjon med environment og compute | En endpoint kan ha flere deployments (f.eks. "blue", "green") |
| **Traffic splitting** | Prosentvis fordeling av requests mellom deployments | `{"blue": 90, "green": 10}` sender 90% av trafikken til blue, 10% til green |
| **Data collection** | Logger input/output for monitoring og evaluering | Brukes til drift detection, model decay, evaluering av A/B-resultater |

**Eksempel: Opprett endpoint med to deployments**

```python
from azure.ai.ml import MLClient
from azure.ai.ml.entities import ManagedOnlineEndpoint, ManagedOnlineDeployment, Model, Environment
from azure.identity import DefaultAzureCredential

ml_client = MLClient(DefaultAzureCredential(), subscription_id="<sub>", resource_group_name="<rg>", workspace_name="<ws>")

# Opprett endpoint
endpoint = ManagedOnlineEndpoint(name="my-endpoint")
ml_client.online_endpoints.begin_create_or_update(endpoint).result()

# Deployment 1: Blue (existing model)
blue_deployment = ManagedOnlineDeployment(
    name="blue",
    endpoint_name="my-endpoint",
    model=Model(path="./model-v1"),
    instance_type="Standard_DS3_v2",
    instance_count=1
)
ml_client.online_deployments.begin_create_or_update(blue_deployment).result()

# Deployment 2: Green (new model candidate)
green_deployment = ManagedOnlineDeployment(
    name="green",
    endpoint_name="my-endpoint",
    model=Model(path="./model-v2"),
    instance_type="Standard_DS3_v2",
    instance_count=1
)
ml_client.online_deployments.begin_create_or_update(green_deployment).result()

# Sett traffic split: 90% til blue, 10% til green
endpoint.traffic = {"blue": 90, "green": 10}
ml_client.online_endpoints.begin_create_or_update(endpoint).result()
```

### Evaluering av LLM-baserte eksperimenter

For GenAI-applikasjoner er automatisert evaluering utfordrende. Microsoft tilbyr flere tilnærminger:

| Metode | Teknologi | Styrke | Svakhet |
|--------|-----------|--------|---------|
| **LLM-as-judge** | Microsoft Foundry evaluators, Databricks judges | Fanger subjektive kvaliteter (relevans, coherence) | Kan være bias, kostbar |
| **Rule-based scorers** | BLEU, ROUGE, exact match | Rask, reproducerbar | Fanger ikke semantikk eller tonalitet |
| **Human evaluation** | Microsoft Foundry thumbs up/down, red teaming | Gullstandard for kvalitet | Skalerer ikke, dyr |
| **Business metrics** | Conversion rate, task completion, bounce rate | Måler faktisk verdi | Påvirkes av faktorer utenfor modellen |

**Microsoft Foundry safety evaluations** støtter automatisert vurdering av:
- Groundedness (hallucination detection)
- Relevance (til brukerspørsmål)
- Safety (harmful content, jailbreaks)
- Coherence, fluency

Disse kan kjøres som del av CI/CD-pipeline eller kontinuerlig monitoring.

---

## Arkitekturmønstre

### Mønster 1: Canary Deployment (Progressive Rollout)

**Beskrivelse:** Start med liten trafikk-andel til ny modell, øk gradvis ved suksess.

**Fordeler:**
- Minimerer risiko ved feil i ny modell
- Gir tidlig signal på ytelse i produksjon
- Reversibel (kan raskt gå tilbake til 100% gammel modell)

**Ulemper:**
- Krever tilstrekkelig trafikk for statistisk signifikans
- Krever robust logging og monitoring
- Kan ta lang tid før full rollout

**Implementering i Azure ML:**

```python
# Uke 1: 5% til ny modell
endpoint.traffic = {"blue": 95, "green": 5}
ml_client.online_endpoints.begin_create_or_update(endpoint).result()

# Uke 2: Hvis metrics er gode, øk til 20%
endpoint.traffic = {"blue": 80, "green": 20}
ml_client.online_endpoints.begin_create_or_update(endpoint).result()

# Uke 3: Full rollout
endpoint.traffic = {"green": 100}
ml_client.online_endpoints.begin_create_or_update(endpoint).result()
```

**Når bruke:** For produksjonssystemer med høy risiko (kritiske beslutninger, mange brukere).

---

### Mønster 2: Shadow Deployment (Parallel Testing)

**Beskrivelse:** Ny modell kjører parallelt med gammel modell, men kun gammel modell returnerer svar til bruker. Ny modell logger prediksjoner for offline-analyse.

**Fordeler:**
- Ingen risiko for brukeropplevelse
- Full trafikk til ny modell for testing
- Kan sammenligne direkte på samme input

**Ulemper:**
- Dobbelt compute-kostnad
- Ingen feedback fra brukere på ny modell
- Krever custom logging-logikk

**Implementering:** Krever egendefinert scoring script som kaller begge modeller:

```python
# I score.py
def run(data):
    input_data = json.loads(data)

    # Kall primær modell (blue)
    primary_response = blue_model.predict(input_data)

    # Kall shadow modell (green) i bakgrunnen, ikke returner
    try:
        shadow_response = green_model.predict(input_data)
        log_shadow_prediction(input_data, shadow_response)
    except Exception as e:
        log_error(e)

    return primary_response
```

**Når bruke:** Når det er null toleranse for feil i produksjon, men du vil teste ny modell med reell trafikk.

---

### Mønster 3: Multi-Armed Bandit (Adaptive A/B Testing)

**Beskrivelse:** Trafikkfordeling justeres dynamisk basert på observert ytelse. Bedre modell får gradvis mer trafikk.

**Fordeler:**
- Minimerer "regret" (tap fra dårlig modell)
- Automatisk optimal trafikkfordeling
- Rask konvergens til beste modell

**Ulemper:**
- Krever sanntids metrics og feedback
- Kompleks å implementere
- Kan være ustabil ved støyende metrics

**Implementering:** Ikke innebygd i Azure ML, krever custom logic (f.eks. Azure Functions som justerer endpoint.traffic basert på metrics fra Azure Monitor).

**Når bruke:** Når du har høyfrekvent feedback (f.eks. click-through rate) og kan tolerere kompleksitet.

---

## Beslutningsveiledning

### Velge riktig A/B-strategi

| Scenario | Anbefalt strategi | Rationale |
|----------|-------------------|-----------|
| **Kritisk produksjonssystem, null feil-toleranse** | Shadow deployment → Canary | Test først uten risiko, deretter gradvis rollout |
| **Moderat risiko, klare metrics** | Canary deployment (10% → 50% → 100%) | Balanserer risiko mot tid-til-produksjon |
| **Høyfrekvent feedback, behov for rask beslutning** | Multi-armed bandit | Automatisk optimal trafikkfordeling |
| **LLM med subjektive outputs** | Canary + human evaluation + LLM-as-judge | Kombinerer automatisering med menneskelig vurdering |
| **Prompt engineering / RAG-tuning** | Online endpoint per variant + traffic split | Test flere prompt-strategier samtidig |

### Vanlige feil

| Feil | Konsekvens | Hvordan unngå |
|------|------------|---------------|
| **For rask rollout** | Feil i produksjon påvirker mange brukere | Bruk canary med klare stop-kriterier |
| **For liten sample size** | Ikke statistisk signifikans | Beregn minimum trafikk før test (power analysis) |
| **Kun automatiserte metrics** | Modell scorer bra på metrics, dårlig hos brukere | Kombiner automatiserte scorers med human evaluation |
| **Manglende data collection** | Kan ikke analysere resultater i ettertid | Aktiver data collection på alle deployments |
| **Ignorere latency/cost** | Ny modell er raskere men dårligere, eller motsatt | Inkluder latency, cost, throughput i evalueringskriterier |

### Røde flagg

- **Metrics divergerer:** Blue scorer bedre på accuracy, green på user satisfaction → trenger dypere analyse
- **Høy varians i LLM outputs:** Samme input gir svært ulike svar → vurder temperature, top-p tuning
- **Data drift i A/B-periode:** Trafikkmønster endres (f.eks. sesong) → kan invalidere sammenligningen
- **Manglende ground truth:** Ingen måte å verifisere korrekthet → må bygge evaluation dataset

---

## Integrasjon med Microsoft-stakken

### Azure Machine Learning

**Managed online endpoints** med traffic splitting er primærverktøyet for A/B-testing. Støtter:
- **Kubernetes-basert deployment** (AKS) for enterprise-scenarios
- **Serverless compute** for prototyping
- **Data collection** via `DataCollector` (logger input/output til Azure Storage)
- **Monitoring** via Azure Monitor og Application Insights

**Eksempel: Aktiver data collection**

```python
from azure.ai.ml.entities import DataCollector, DeploymentCollection

data_collector = DataCollector(
    collections={
        "model_inputs": DeploymentCollection(enabled="true"),
        "model_outputs": DeploymentCollection(enabled="true")
    }
)

deployment = ManagedOnlineDeployment(
    name="blue",
    endpoint_name="my-endpoint",
    model=Model(path="./model"),
    data_collector=data_collector,
    instance_type="Standard_DS3_v2",
    instance_count=1
)
```

### Microsoft Foundry (tidligere Azure OpenAI Studio)

For LLM-baserte applikasjoner tilbyr **Foundry Evaluations**:
- **Pre-built evaluators** for groundedness, relevance, safety
- **Custom evaluators** med egne prompts
- **Batch evaluation** på validation sets
- **A/B comparison** via Scorecards

**Workflow:**
1. Deploy to kandidat-modeller til online endpoints
2. Samle inn predictions fra begge (via data collection eller shadow deployment)
3. Kjør Foundry Evaluation på begge sett av predictions
4. Sammenlign scorecards

**Confidence markers:** Verified (fra MCP-dokumentasjon), Baseline (modellkunnskap)

### Prompt Flow

Støtter **Variants** — flere versjoner av samme prompt i samme flow. Kan brukes til A/B-testing av prompts:

```yaml
# flow.dag.yaml
nodes:
  - name: chat
    type: llm
    source:
      type: code
      path: chat.jinja2
    variants:
      variant_0:
        system_message: "You are a helpful assistant."
      variant_1:
        system_message: "You are a concise assistant who answers in one sentence."
```

**Deploy variants til separate endpoints**, eller kombiner med traffic splitting for automatisk A/B-test.

### PlayFab (for gaming scenarios)

Hvis AI-modellen er del av en spillopplevelse, kan **PlayFab Experiments** brukes til A/B-testing med integrert telemetri og scorecards. (Mindre relevant for enterprise AI, men kraftig for gaming/customer-facing apps.)

---

## Offentlig sektor (Norge)

### GDPR og Schrems II

A/B-testing innebærer logging av brukerinput og modell-output. Dette er personopplysninger hvis input inneholder identifiserbar informasjon (navn, personnummer, etc.).

**Krav:**
- **Hjemmel:** Behandling må ha hjemmel i GDPR Art. 6 (f.eks. legitimate interest for kvalitetsforbedring)
- **Informasjon:** Brukere må informeres om at data logges for testing/evaluering (personvernerklæring)
- **Lagringstid:** Loggdata må slettes etter definert periode (f.eks. 90 dager etter A/B-test er avsluttet)
- **Datasuverenitet:** Hvis modellen hostes i EU (Azure Europe), må logged data også lagres i EU (Azure Storage i EU-region)

**Anbefaling:** Bruk **pseudonymisering** eller **anonymisering** av input-data før logging, hvis mulig.

### AI-loven (EU AI Act)

Hvis AI-systemet er høyrisiko (f.eks. offentlig forvaltning, kritisk infrastruktur):
- **Menneske-i-loop:** A/B-test med høy impact må godkjennes av mennesker før full rollout
- **Dokumentasjon:** Logg hvilke modeller som ble testet, når, med hvilke resultater (traceability)
- **Bias monitoring:** Vurder om A/B-test favoriserer visse brukergrupper (f.eks. språk, dialekt)

**Anbefaling:** Bruk Microsoft Foundry **fairness evaluators** til å sjekke bias før og etter A/B-test.

### Utredningsinstruksen

Hvis A/B-testen involverer endring av tjenestekvalitet (f.eks. chatbot i NAV), kan det kreve utredning:
- **Virkningsvurdering:** Hvordan påvirker ny modell brukere?
- **Alternativer:** Er A/B-test eneste måte å validere, eller kan offline-evaluering være nok?

**Anbefaling:** Dokumenter A/B-test som del av ROS-analyse (risikovurdering).

---

## Kostnad og lisensiering

### Kostnadsmodell for A/B-testing

| Komponent | Prismodell | Typisk kostnad | Optimaliseringstips |
|-----------|------------|----------------|---------------------|
| **Managed online endpoint (compute)** | Per VM-time (Standard_DS3_v2: ~$0.27/h) | $200-500/måned per deployment | Bruk auto-scaling, stopp deployments utenfor arbeidstid |
| **Traffic splitting overhead** | Ingen ekstra kostnad | $0 | Gratis å ha flere deployments, betaler kun for compute |
| **Data collection (storage)** | Azure Blob Storage (~$0.02/GB/måned) | $5-20/måned | Slett logger etter 90 dager |
| **LLM-as-judge evaluations** | Per token (GPT-4: ~$0.03/1K tokens) | $50-200 for en evalueringsrunde | Bruk GPT-3.5 for pre-screening, GPT-4 for final validation |
| **Azure Monitor / App Insights** | Per GB innsamlet data (~$2.30/GB) | $10-50/måned | Filtrer logs, kun viktige events |

**Eksempel-scenario:**
- 2 deployments (blue, green), Standard_DS3_v2, 24/7: ~$400/måned
- Data collection, 10GB/måned: ~$0.20
- LLM-as-judge, 1 million tokens: ~$30
- **Total: ~$430/måned**

### Lisensiering

Krever:
- **Azure subscription** (Pay-as-you-go eller Enterprise Agreement)
- **Azure Machine Learning workspace** (gratis, betaler kun for underliggende compute)
- **Microsoft Foundry** (gratis portal, betaler for model inference og evaluations)

**Ingen ekstra lisens** for A/B-testing-funksjonen selv.

---

## For arkitekten (Cosmo)

### Spørsmål å stille kunden

1. **Hva er beslutningskriteriene for å rulle ut ny modell?**
   → Trenger klare metrics (accuracy, latency, user satisfaction) og thresholds (f.eks. "green må være minst 5% bedre enn blue på relevance score").

2. **Hvor mye trafikk har dere, og hvor lenge kan en A/B-test vare?**
   → Lav trafikk (< 1000 requests/dag) gjør det vanskelig å få statistisk signifikans på kort tid. Vurder offline-evaluering eller lengre test-periode.

3. **Har dere etablert ground truth for evaluering?**
   → For LLMs er dette utfordrende. Vurder å bygge et lite human-labeled dataset (100-500 eksempler) som baseline.

4. **Hva er konsekvensen av feil predictions?**
   → Høy konsekvens → bruk shadow deployment først, deretter canary. Lav konsekvens → kan gå direkte til 50/50 split.

5. **Kan dere logge bruker-feedback (thumbs up/down)?**
   → Dette er gull for LLM-evaluering. Implementer enkelt feedback-UI i applikasjonen.

6. **Har dere kompetanse til å analysere A/B-resultater?**
   → Statistisk signifikans, confidence intervals, p-verdier — krever datascience-kompetanse. Vurder å bruke Azure ML studio UI som forenkler dette.

7. **Er det sesongvariasjoner eller andre drifts i trafikken?**
   → Hvis ja, sørg for at A/B-test dekker hele syklusen (f.eks. hele uke hvis mandag/fredag har ulik trafikk).

8. **Hva er budsjettet for A/B-testing (compute + evaluering)?**
   → To parallelle deployments dobler compute-kostnaden. Vurder å bruke mindre VM-er for test, eller time-based scaling.

### Fallgruver

| Fallgruve | Hvordan unngå |
|-----------|---------------|
| **"Set and forget"** — starter A/B-test og glemmer å følge opp | Sett opp Azure Monitor alerts for anomalier (høy latency, error rate) |
| **Manglende rollback-plan** | Test rollback før A/B-test (sett traffic til 0% green, verifiser at blue fungerer) |
| **Kun tekniske metrics** | Modell kan være raskere men gi dårligere brukeropplevelse. Inkluder user feedback! |
| **Små sample sizes** | Beregn minimum antall requests før test (online calculators for A/B test power analysis) |
| **Bias i trafikkfordeling** | Verifiser at traffic split faktisk er 50/50 (logg hvilken deployment hver request traff) |

### Anbefalinger per modenhetsnivå

| Modenhet | Anbefalt tilnærming | Verktøy |
|----------|---------------------|---------|
| **Nivå 1: Ad-hoc** | Manuell canary deployment, offline-evaluering | Azure ML SDK, manual traffic adjustment |
| **Nivå 2: Repetitiv** | Automatisert canary via CI/CD, pre-defined metrics | Azure DevOps pipelines, Azure ML CLI, Prompt Flow |
| **Nivå 3: Definert** | Shadow deployment + canary, LLM-as-judge, human eval | Microsoft Foundry evaluations, custom scoring scripts |
| **Nivå 4: Styrt** | Multi-armed bandit, adaptive rollout, automatic rollback | Custom logic (Azure Functions), Azure Monitor alerts |
| **Nivå 5: Optimalisert** | Continuous experimentation, automated model selection | MLOps platform (Kubeflow, MLflow), integrated with Azure ML |

**For LLM-baserte applikasjoner:** Start med Nivå 2-3 (canary + LLM-as-judge). Multi-armed bandit (Nivå 4+) er overkill for de fleste enterprise-scenarios.

---

## Kilder og verifisering

**Microsoft Learn (Verified via MCP):**

1. [What is Azure Machine Learning? — Deploy models](https://learn.microsoft.com/en-us/azure/machine-learning/overview-what-is-azure-machine-learning?view=azureml-api-2#deploy-models)
   **Konfidensnivå:** Verified
   **Relevans:** Forklarer traffic splitting for real-time endpoints

2. [Architecture best practices for Azure Machine Learning — Operational Excellence](https://learn.microsoft.com/en-us/azure/well-architected/service-guides/azure-machine-learning#operational-excellence)
   **Konfidensnivå:** Verified
   **Relevans:** Anbefaler model registries for A/B testing og canary releases

3. [Test and evaluate AI workloads on Azure — Model training and fine-tuning](https://learn.microsoft.com/en-us/azure/well-architected/ai/test#guidance-for-testing-model-training-and-fine-tuning)
   **Konfidensnivå:** Verified
   **Relevans:** Data drift, concept drift, automated testing

4. [How to safely rollout online endpoints](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-safely-rollout-online-endpoints?view=azureml-api-2)
   **Konfidensnivå:** Verified (fra kodeeksempler)
   **Relevans:** Blue/green deployment pattern

5. [LLMOps - Operational management of LLMs](https://learn.microsoft.com/en-us/ai/playbook/technology-guidance/generative-ai/mlops-in-openai/)
   **Konfidensnivå:** Verified
   **Relevans:** A/B testing som del av "Validate & Deploy" fase

6. [Microsoft Foundry safety and security evaluations](https://learn.microsoft.com/en-us/azure/ai-studio/how-to/develop/flow-evaluate-sdk#built-in-evaluators)
   **Konfidensnivå:** Verified
   **Relevans:** Built-in evaluators for LLM quality

7. [Scorers and LLM judges (Databricks)](https://learn.microsoft.com/en-us/azure/databricks/mlflow3/genai/eval-monitor/concepts/scorers)
   **Konfidensnivå:** Verified
   **Relevans:** LLM-as-judge for GenAI evaluation

**Baseline (modellkunnskap):**
- Multi-armed bandit algorithms (Thompson Sampling, UCB)
- Statistical significance for A/B testing (p-values, confidence intervals, power analysis)
- Shadow deployment patterns

**Antall unike kilder:** 7 (Microsoft Learn) + 3 (baseline concepts) = **10 kilder**


### A/B Testing with Azure ML Managed Online Endpoints + MLflow 3 (2026)

**Traffic splitting via managed online endpoints**:
```bash
# Deploy challenger model with 10% traffic
az ml online-deployment create --name challenger --endpoint my-endpoint
az ml online-endpoint update --name my-endpoint --traffic control=90 challenger=10

# Monitor with MLflow 3 scorers — same metrics for both variants
# Use RelevanceToQuery, Correctness, custom business scorers
```

**MLflow 3 A/B evaluation pattern** — Verified (MCP 2026-04):
- Use `mlflow.genai.evaluate()` on traces from each variant
- Compare scorers: `Correctness`, `RelevanceToQuery`, `RetrievalGroundedness`, `ToolCallEfficiency`, `Fluency` — expanded scorer set in MLflow 3
- Multi-turn scorers available: `ConversationCompleteness`, `UserFrustration` for conversational AI A/B testing
- Statistical significance: MLflow tracks Cohen's Kappa against human baseline
- Aliases in Prompt Registry: `@control` and `@challenger` for prompt A/B testing

**Azure ML safe rollout progression** — Verified (MCP 2026-04):
1. **Shadow testing**: Mirror X% of traffic to new model (no user impact) — natively supported via `mirror_traffic` property on managed online endpoints
2. **Canary**: Route 10% live traffic, monitor bake time (hours/days)
3. **Progressive**: 10% → 50% → 100% with health gate at each step
4. **Rollback trigger**: Automatic halt on health signal degradation

**Evaluation metrics for LLM A/B tests**:
- Quality: Groundedness, Relevance, Correctness (MLflow judges)
- Latency: P50, P90, P99 response times
- Cost: Token usage per request
- Business: Task completion rate, user satisfaction