open/ms-ai-architect
1
0
Fork 0
Code Issues Releases 4 Activity

feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command

Browse source 
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 2026-04-08 08:58:35 +02:00
commit baa2d0220b
488 changed files with 213221 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

440
skills/ms-ai-engineering/references/mlops-genaiops/ab-testing-llm-applications.md Normal file
View file

@ -0,0 +1,440 @@
# A/B Testing and Experimentation for AI Models
**Last updated:** 2026-02
**Status:** GA
**Category:** MLOps & GenAIOps
---
## 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** | 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:**
```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
)
```
### 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:
```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 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](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. [Azure AI 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**