ktg-plugin-marketplace/plugins/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-04 Verified: MCP 2026-04 Status: GA Category: MLOps & GenAIOps

---

Verified: MCP 2026-04

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

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	Azure AI 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	Azure AI 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

Azure AI 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:

# 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:

# 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

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
)

Azure AI 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:

# 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 Azure AI 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)
• Azure AI 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	Azure AI 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 Konfidensnivå: Verified Relevans: Forklarer traffic splitting for real-time endpoints

2. Architecture best practices for 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 Konfidensnivå: Verified Relevans: Data drift, concept drift, automated testing

4. How to safely rollout online endpoints Konfidensnivå: Verified (fra kodeeksempler) Relevans: Blue/green deployment pattern

5. LLMOps - Operational management of LLMs Konfidensnivå: Verified Relevans: A/B testing som del av "Validate & Deploy" fase

6. Azure AI Foundry safety and security evaluations Konfidensnivå: Verified Relevans: Built-in evaluators for LLM quality

7. Scorers and LLM judges (Databricks) 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:

# 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