ms-ai-architect/skills/ms-ai-engineering/references/mlops-genaiops/llm-evaluation-production.md

LLM Evaluation in Production Contexts

Kategori: MLOps & GenAIOps Sist oppdatert: 2026-04 Confidence: High (basert på offisiell Microsoft dokumentasjon, Azure AI Foundry SDK, og MLflow 3)

---

Verified: MCP 2026-04

Introduksjon

LLM-evaluering i produksjonsmiljø er fundamentalt forskjellig fra tradisjonell ML-evaluering. Mens klassiske ML-modeller evalueres med deterministiske metrikker på statiske test-sett, krever generative AI-applikasjoner kontinuerlig evaluering av åpne, ikke-deterministiske output i dynamiske produksjonsscenarioer.

Viktige forskjeller:

• Non-determinisme: LLM-er genererer ulike svar for samme input på grunn av sampling og temperatur-parametere
• Subjektiv kvalitet: "Riktig" svar er ikke binært – relevans, koherens, tone og fullstendighet er alle evaluerings-dimensjoner
• Multi-turn kontekst: Agenter og chat-applikasjoner krever evaluering på tvers av flere samtale-runder
• Emergent behavior: Komplekse agentsystemer med retrieval, tool-calling og reasoning viser adferd som ikke kan forutsees i pre-prod testing
• Safety & security: Produksjons-trafikk kan inneholde adversarial inputs som krever kontinuerlig overvåkning

Når bruke production evaluation:

• Post-deployment quality monitoring for deployed AI agents og applikasjoner
• Drift detection – identifisere når modellkvalitet degraderer over tid
• A/B testing av nye prompt-variasjoner eller modellversjoner
• Compliance & audit trails for regulerte sektorer (finans, helse, offentlig sektor)
• Incident response – rask root cause analysis ved problematiske outputs

---

Kjernekomponenter

Production evaluation i Microsoft AI-stakken består av fem hovedkomponenter som samarbeider for å levere kontinuerlig kvalitets- og sikkerhetsovervåkning.

1. Tracing Infrastructure

Azure AI Foundry Tracing og MLflow Tracing gir den datainfrastrukturen som all evaluering bygger på. Tracing logger automatisk:

• Input prompts og kontekst
• Mellomsteg (retrieval-resultater, tool calls, reasoning)
• Final outputs
• Metadata (latency, token usage, model version)

Implementering med Azure AI Projects SDK:

from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential

project = AIProjectClient.from_connection_string(
    conn_str=os.environ["AIPROJECT_CONNECTION_STRING"],
    credential=DefaultAzureCredential()
)

# Tracing er automatisk aktivert for alle agent-interaksjoner
# Data lagres i Application Insights koblet til prosjektet

Key insight: Tracing er forutsetningen for all evaluering – uten strukturerte traces kan du ikke kjøre evaluatorer på production traffic. (High confidence)

2. Evaluators (Scorers & LLM Judges)

Evaluatorer er spesialiserte funksjoner som scorer kvalitet og sikkerhet basert på trace-data. Microsoft tilbyr tre hovedtyper:

A. Built-in LLM Judges (AI-assisted evaluators)

Bruker LLM-er som "judges" til å score kvalitet basert på chain-of-thought reasoning. Eksempler:

• Groundedness: Er svaret støttet av gitt context? (1-5 skala)
• Relevance: Er svaret relevant for spørsmålet? (1-5 skala)
• Coherence: Flyter teksten naturlig? (1-5 skala)
• Safety evaluators: Violence, Sexual, Self-harm, Hate/Unfairness (0-7 skala)

Implementering:

from azure.ai.evaluation import (
    GroundednessEvaluator,
    RelevanceEvaluator,
    ViolenceEvaluator
)

# Quality evaluator (krever GPT model som judge)
model_config = {
    "azure_endpoint": os.environ["AZURE_OPENAI_ENDPOINT"],
    "api_key": os.environ["AZURE_OPENAI_API_KEY"],
    "azure_deployment": "gpt-4o",  # anbefalt: gpt-4o eller gpt-4o-mini
}

groundedness = GroundednessEvaluator(model_config)
relevance = RelevanceEvaluator(model_config)

# Safety evaluator (krever Azure AI Project connection)
azure_ai_project = {
    "subscription_id": "<sub_id>",
    "resource_group_name": "<rg_name>",
    "project_name": "<project_name>",
}

violence = ViolenceEvaluator(azure_ai_project)

B. NLP-baserte scorers (deterministiske metrikker)

Matematisk-baserte metrikker for tekstlikhet (krever ground truth):

• F1 Score, BLEU, ROUGE, METEOR: Token overlap metrics
• Exact match, format validation: Custom code-based scorers

C. Agentic evaluators (spesialisert for agent workflows)

• IntentResolutionEvaluator: Identifiserer agenten brukerens intensjon korrekt?
• TaskAdherenceEvaluator: Følger agenten system instructions?
• ToolCallAccuracyEvaluator: Velger agenten riktige verktøy med korrekte parametere?

Cost consideration: LLM judges forbruker betydelig token usage (800-3000 tokens per evaluering avhengig av evaluator). Bruk sampling for store volumer. (High confidence)

3. Continuous Evaluation Engine

Kontinuerlig evaluering kjører evaluatorer automatisk på production traffic med konfigurerbar sampling rate.

Azure AI Foundry Continuous Evaluation (for Agents):

from azure.ai.projects.models import (
    EvaluationRule,
    ContinuousEvaluationRuleAction,
    EvaluationRuleFilter,
    EvaluationRuleEventType,
)

# 1. Definer evaluering (hvilke kriterier)
data_source_config = {"type": "azure_ai_source", "scenario": "responses"}
testing_criteria = [
    {
        "type": "azure_ai_evaluator",
        "name": "groundedness",
        "evaluator_name": "builtin.groundedness",
        "data_mapping": {
            "query": "{{item.query}}",
            "context": "{{sample.context}}",
            "response": "{{sample.output_text}}"
        }
    },
    {
        "type": "azure_ai_evaluator",
        "name": "violence_detection",
        "evaluator_name": "builtin.violence"
    }
]

eval_object = openai_client.evals.create(
    name="Production Quality Monitoring",
    data_source_config=data_source_config,
    testing_criteria=testing_criteria,
)

# 2. Opprett continuous evaluation rule (når og hvordan ofte)
continuous_eval_rule = project_client.evaluation_rules.create_or_update(
    id="my-continuous-eval-rule",
    evaluation_rule=EvaluationRule(
        display_name="Continuous Quality Monitor",
        description="Runs on every agent response completion",
        action=ContinuousEvaluationRuleAction(
            eval_id=eval_object.id,
            max_hourly_runs=100  # Rate limit for å kontrollere kostnader
        ),
        event_type=EvaluationRuleEventType.RESPONSE_COMPLETED,
        filter=EvaluationRuleFilter(agent_name="my-agent"),
        enabled=True,
    ),
)

MLflow 3 Production Monitoring (Databricks):

from mlflow.genai.scorers import Safety, Correctness, ScorerSamplingConfig

# Register scorers og start monitoring
safety_judge = Safety().register(name="safety_monitor")
safety_judge = safety_judge.start(
    sampling_config=ScorerSamplingConfig(sample_rate=0.3)  # 30% sampling
)

correctness_judge = Correctness().register(name="correctness_monitor")
correctness_judge = correctness_judge.start(
    sampling_config=ScorerSamplingConfig(sample_rate=0.5)  # 50% sampling
)

Key insight: Max 20 scorers per experiment i MLflow. Bruk sampling strategisk – høy sampling (50-100%) for safety, lavere (10-30%) for quality metrics. (High confidence)

4. Monitoring Dashboard & Alerts

Visualisering og alerting er kritisk for actionable insights.

Azure Monitor Application Insights integration:

• Foundry Observability Dashboard: Real-time visualisering av token usage, latency, success rate, evaluation scores
• Azure Workbooks: Kusto-baserte queries for dype analyser
• Azure Monitor Alerts: Automatiske varsler når pass rates faller under threshold

Eksempel alert-regel:

# Alert når groundedness pass rate < 70% over siste time
{
    "metric": "groundedness_pass_rate",
    "threshold": 0.7,
    "time_window": "PT1H",
    "action": {
        "email": ["team@example.com"],
        "severity": "High"
    }
}

MLflow UI (Databricks):

• Evaluations tab: Side-by-side sammenligning av evaluation runs
• Scorers tab: Oversikt over active scorers, sampling rates, og metrics
• Traces tab: Detaljert debugging av individuelle agent-interaksjoner

5. Human Feedback Loop

Production evaluation er ikke komplett uten human-in-the-loop validering.

Azure AI Foundry Review App:

• Domain experts kan review AI-genererte svar direkte fra dashboard
• Thumbs up/down feedback lagres som evaluation data for future training
• Feedback brukes til å tune custom evaluators og forbedre LLM judges

MLflow Review App:

• Integrert feedback UI for expert labeling
• Export feedback data til evaluation datasets for iterativ forbedring

Best practice: Kombiner automated evaluators med human feedback for å kalibrere evaluators mot menneskelig vurdering. (High confidence)

---

Arkitekturmønstre

Mønster 1: Sampled Continuous Evaluation

Når bruke: Standard production monitoring for de fleste AI-applikasjoner.

Hvordan:

Production Traffic (100%)
    ↓
Sampling Filter (10-50%)
    ↓
Evaluation Engine
    ↓
Metrics Storage (Application Insights)
    ↓
Dashboard + Alerts

Implementering:

# Azure AI Foundry: sampling via max_hourly_runs
action=ContinuousEvaluationRuleAction(
    eval_id=eval_object.id,
    max_hourly_runs=100  # Hvis traffic er 1000/hour → 10% sampling
)

# MLflow: sampling via sample_rate
scoring_config=ScorerSamplingConfig(sample_rate=0.2)  # 20% sampling

Fordeler:

• Kostnadseffektivt – reduserer evaluator token usage med 50-90%
• Rask implementering – ingen infrastruktur-endringer
• Statistisk representativt ved store volumer (>1000 req/day)

Ulemper:

• Kan misse edge cases ved lav trafikk
• Delayed detection ved sjeldne problemer

Trade-off: Øk sampling rate for kritiske safety evaluators, reduser for quality metrics. (High confidence)

Mønster 2: Scheduled Batch Evaluation

Når bruke: Kostnadsoptimalisering for store volumer, eller når real-time feedback ikke er kritisk.

Hvordan:

Production Traffic → Trace Storage
    ↓ (Scheduled trigger: daily/weekly)
Batch Evaluation Job
    ↓
Aggregated Metrics Report

Implementering med Azure ML SDK:

from azure.ai.ml.entities import MonitorSchedule, CronTrigger

trigger_schedule = CronTrigger(expression="0 2 * * *")  # Daglig kl 02:00

monitor = MonitorSchedule(
    name="daily_quality_batch",
    trigger=trigger_schedule,
    create_monitor=monitor_settings
)

ml_client.schedules.begin_create_or_update(monitor)

Fordeler:

• Lavere kostnad – batch processing er billigere enn real-time
• Egnet for post-hoc analysis og compliance reporting
• Kan kjøre tyngre evaluators (LLM judges med større context windows)

Ulemper:

• Delayed incident detection
• Krever storage for trace data

Best practice: Kombiner scheduled batch (daglig) med sampled real-time (kritiske safety metrics). (Medium-high confidence)

Mønster 3: A/B Testing med Evaluation

Når bruke: Testing av nye prompt-variasjoner, modellversjoner, eller agent-konfigurasjoner.

Hvordan:

Production Traffic
    ↓
    50% → Variant A (baseline)
    50% → Variant B (candidate)
    ↓
Separate Evaluation Pipelines
    ↓
Comparative Metrics Dashboard

Implementering:

# MLflow comparative evaluation
baseline_traces = mlflow.search_traces(
    filter_string="attributes.variant = 'baseline'"
)
candidate_traces = mlflow.search_traces(
    filter_string="attributes.variant = 'candidate'"
)

baseline_eval = mlflow.genai.evaluate(
    data=baseline_traces,
    scorers=[Groundedness(), Relevance()]
)

candidate_eval = mlflow.genai.evaluate(
    data=candidate_traces,
    scorers=[Groundedness(), Relevance()]
)

# Sammenlign metrics i MLflow UI

Fordeler:

• Data-drevet beslutningsgrunnlag for modell-/prompt-endringer
• Reduserer risiko ved deployment av nye versjoner
• Automatisert regression testing

Ulemper:

• Krever traffic splitting infrastructure
• Økt kompleksitet i deployment pipeline

Mønster 4: Red Teaming + Scheduled Probing

Når bruke: Proaktiv sikkerhetstesting for high-risk applications (finans, helse, offentlig sektor).

Hvordan:

Scheduled Red Team Scans (weekly)
    ↓
AI Red Teaming Agent (PyRIT)
    ↓
Adversarial Inputs → Production System
    ↓
Safety Evaluators
    ↓
Vulnerability Report

Implementering med Azure AI Red Teaming Agent:

from azure.ai.evaluation import AIRedTeamingAgent

red_team_agent = AIRedTeamingAgent(azure_ai_project)

# Kjør automated adversarial scans
scan_results = red_team_agent.run_scan(
    target_endpoint="https://my-agent.azure.com",
    attack_strategies=["jailbreak", "prompt_injection", "bias_elicitation"],
    max_iterations=100
)

# Analyser resultater
vulnerability_report = scan_results.get_vulnerability_summary()

Fordeler:

• Identifiserer sikkerhetshull før de utnyttes av ondsinnede aktører
• Compliance med AI Act og cybersecurity-regelverk
• Continous security posture assessment

Ulemper:

• Kan generere false positives
• Krever human review av resultater

Best practice: Kombiner automated red teaming med manual adversarial probing av security experts. (High confidence – basert på Microsofts Responsible AI framework)

---

Beslutningsveiledning

Når velge continuous vs. scheduled evaluation?

Kriterium	Continuous (Real-time)	Scheduled (Batch)
Traffic volume	< 10 000 req/day	> 10 000 req/day
Safety criticality	High (finans, helse)	Medium-low
Budget	Medium-high	Low-medium
Latency tolerance	< 1 hour incident detection	24h+ acceptable
Evaluator type	Safety-focused	Quality-focused

Anbefaling: Start med continuous evaluation for safety (Violence, Self-harm, Hate) ved 100% sampling. Bruk scheduled batch for quality metrics (Groundedness, Relevance) daglig. (High confidence)

Hvordan velge sampling rate?

Formula: sampling_rate = min(1.0, target_eval_cost / (traffic_volume * eval_cost_per_request))

Eksempel:

• Traffic: 5000 requests/day
• Evaluator: Groundedness (GPT-4o judge, ~1000 tokens/eval, $0.005 per eval)
• Budget: $100/month → $3.33/day
• Optimal sampling: 3.33 / (5000 * 0.005) = 0.13 → 13% sampling

Guideline sampling rates:

• Safety evaluators (critical): 50-100%
• Quality evaluators (standard): 10-30%
• Agentic evaluators (complex): 5-15% (høyere token cost)

Hvordan håndtere evaluation latency i production?

Problem: LLM judges introduserer latency (200ms-2s per evaluering) som ikke skal påvirke user-facing responstid.

Løsninger:

A. Async evaluation (anbefalt):

# Azure AI Foundry: Evaluation kjører async etter response er returnert
# Ingen user-facing latency impact
event_type=EvaluationRuleEventType.RESPONSE_COMPLETED  # Trigger AFTER response

B. Background workers:

# MLflow: Production monitoring kjører i separate compute cluster
safety_judge = Safety().register(name="safety_monitor")
safety_judge.start()  # Kjører i background, ikke i request path

Trade-off: Async evaluation gir delayed feedback (sekunder-minutter). For low-latency incident response, bruk real-time safety filters i request path (Azure AI Content Safety API). (High confidence)

Hvordan håndtere evaluation drift?

Problem: LLM judges kan bli inkonsistente over tid (modell-updates, prompt drift).

Løsninger:

1. Anchor på human feedback: Kalibrer LLM judges mot human-labeled golden dataset hver måned
2. Version evaluators: Lag nye scorer-versjoner i stedet for å oppdatere eksisterende
3. Monitor evaluator consistency: Track inter-evaluator agreement (Cohen's Kappa)

# MLflow: Track evaluator version i traces
with mlflow.start_run():
    mlflow.log_param("evaluator_version", "groundedness_v2.1")
    mlflow.log_param("judge_model", "gpt-4o-2024-11-20")

Best practice: Frys evaluator-versioner for compliance/audit use cases. For continuous improvement, oppdater quarterly med A/B testing mot baseline. (Medium-high confidence)

---

Integrasjon med Microsoft-stakken

Azure AI Foundry + Application Insights

Full stack monitoring:

Azure AI Agent (Copilot Studio / AI Foundry Agent Service)
    ↓ (OpenTelemetry tracing)
Application Insights (trace storage)
    ↓
Continuous Evaluation Engine
    ↓
Foundry Observability Dashboard
    ↓
Azure Monitor Alerts

Setup:

# 1. Koble Application Insights til Foundry Project (via portal eller Bicep)

# 2. Enable tracing i kode
from azure.ai.projects import AIProjectClient

project = AIProjectClient.from_connection_string(
    conn_str=os.environ["AIPROJECT_CONNECTION_STRING"],
    credential=DefaultAzureCredential()
)

# Tracing er auto-enabled – all agent activity logges til App Insights

# 3. Sett opp continuous evaluation (se tidligere eksempel)

# 4. Visualiser i Foundry portal → Monitoring → Application Analytics

Fordeler:

• Unified observability platform (logs, traces, metrics, evaluations)
• Seamless integration med existing Azure Monitor alerts og dashboards
• RBAC-styrt tilgang til evaluation data
• Compliance-ready (GDPR, ISO 27001)

Kostnad: Application Insights charges per GB ingested data. Forvent 1-5 MB/1000 requests for trace data, pluss evaluation results. Budget ~$50-200/month for medium production app (10k req/day). (Medium confidence – varies by app complexity)

MLflow 3 + Databricks Unity Catalog

MLflow 3 LLM Evaluation Framework (2026)

MLflow 3 (SDK mlflow[databricks]>=3.1) introduces a unified evaluation model:

Core architecture: Traces → Scorers → Feedback

• Traces from mlflow.genai.evaluate() or production monitoring service
• Scorers parse traces, assess quality, return Feedback objects
• Same scorers used in development AND production (consistent lifecycle)

Built-in LLM judges (research-validated):

Judge	Needs Ground Truth	Evaluates
RelevanceToQuery	No	Response relevance to user request
RetrievalRelevance	No	Retrieved context relevance to user request
RetrievalGroundedness	No	Hallucination detection
Safety	No	Harmful/toxic content
Correctness	Yes	Accuracy vs ground truth
Completeness	Yes	All questions addressed
Fluency	No	Grammatically correct and naturally flowing
Equivalence	Yes	Response equivalent to expected output
RetrievalSufficiency	Yes	Context provides all necessary information
ToolCallCorrectness	Yes	Tool calls and arguments
ToolCallEfficiency	No	Redundant tool usage
Guidelines	No	Custom natural-language rules
ExpectationsGuidelines	No (needs guidelines in expectations)	Per-example natural-language criteria

Verified (MCP 2026-04)

Multi-turn judges (conversation-level): ConversationCompleteness, UserFrustration, KnowledgeRetention, ConversationalSafety, ConversationalGuidelines, ConversationalRoleAdherence, ConversationalToolCallEfficiency

Verified (MCP 2026-04)

Production monitoring: Automatically runs scorers on production traces; uses Databricks-hosted LLM judges (EU workspaces: EU-hosted models). No prompts stored with Azure OpenAI (Abuse Monitoring opt-out).

Custom judges: Full control over evaluation criteria, scores (numerical/categorical/boolean), human feedback alignment via align_judges().

Key note: MLflow 3 replaced Agent Evaluation SDK — migrate with mlflow.genai.* functions.

Enterprise governance for AI:

Databricks Workspace
    ↓
MLflow Tracking (traces + evaluation results)
    ↓
Unity Catalog (governance layer)
    ↓
Lakehouse Storage (trace data for historical analysis)

Setup:

import mlflow

# 1. Set tracking to Databricks
mlflow.set_tracking_uri("databricks")
mlflow.set_experiment("/Shared/production-monitoring")

# 2. Enable tracing
mlflow.dspy.autolog(log_traces=True)  # For DSPy agents
# mlflow.langchain.autolog()  # For LangChain
# mlflow.openai.autolog()  # For direct OpenAI calls

# 3. Register scorers (se tidligere eksempel)

# 4. Query traces med Unity Catalog
traces = spark.read.table("catalog.schema.agent_traces")

Fordeler:

• Unity Catalog sikrer data lineage for AI assets (prompts, agents, traces, evaluations)
• Built-in versioning og rollback for scorers
• Lakehouse-basert lagring = billig historical storage for trend analysis
• Delta Lake = efficient querying av traces for root cause analysis

Best practice: Bruk Unity Catalog til å enforce data governance policies (PII masking, retention policies) på trace data. (High confidence – standard Databricks practice)

Power Platform AI Builder + Dataverse

Low-code production monitoring:

Power Platform har begrenset native support for LLM evaluation i production. Anbefalt mønster:

1. Lag custom connector til Azure AI Foundry Evaluation API
2. Lagre evaluation results i Dataverse
3. Bygg Power BI dashboard for visualisering

Alternativ: Bruk Azure Logic Apps til å kjøre scheduled evaluations på Dataverse-lagrede AI Builder logs.

Limitation: Ingen built-in continuous evaluation. Dette er et gap i Power Platform i dag (per feb 2026). (High confidence – basert på current product capabilities)

Copilot Studio + Dataverse for Teams

Production monitoring for custom copilots:

Copilot Studio logger conversations til Dataverse. Evaluering krever custom pipeline:

Copilot Conversations (Dataverse)
    ↓
Power Automate flow (daily trigger)
    ↓
Azure Function (calls Azure AI Evaluation SDK)
    ↓
Results → Dataverse custom table
    ↓
Power BI report

Gap: Ingen out-of-the-box production evaluation. Microsoft roadmap (Q2 2026) inkluderer native integration med Azure AI Foundry evaluation. (Medium confidence – based on public roadmap)

---

Offentlig sektor (Norge)

Compliance-krav for AI i produksjon

Utredningsinstruksen (2023):

• Krav om dokumentert kvalitetssikring av AI-systemer i produksjon
• Evaluering må dekke ikke-diskriminering (bias detection)
• Transparens – bruker må kunne få innsikt i hvordan beslutninger fattes

Implementering:

# Kontinuerlig bias monitoring
from azure.ai.evaluation import HateUnfairnessEvaluator

bias_evaluator = HateUnfairnessEvaluator(azure_ai_project)

# Log bias metrics til compliance database
eval_results = evaluate(
    data=production_traces,
    evaluators={"bias_detection": bias_evaluator},
    azure_ai_project=project_scope
)

# Export til DPIA-dokumentasjon
compliance_report = {
    "period": "2026-Q1",
    "total_requests": 50000,
    "bias_incidents": eval_results["metrics"]["hate_unfairness_violations"],
    "mitigation_actions": "Retrained with balanced dataset"
}

AI Act (EU) – High-Risk AI System Requirements:

For AI-systemer klassifisert som high-risk (helse, lov, kritisk infrastruktur):

• Article 9: Kontinuerlig overvåkning av accuracy, robustness, cybersecurity
• Article 15: Logging av input/output data – tracing er lovpålagt
• Article 61: Post-market monitoring plan – production evaluation er compliance requirement

Anbefaling: Bruk Azure AI Foundry continuous evaluation med 100% sampling for high-risk AI. Lagre evaluation logs i minimum 5 år for audit purposes. (High confidence – based on AI Act legal text)

GDPR & Privacy i Production Evaluation

Problem: LLM traces kan inneholde PII (persondata) som må håndteres GDPR-compliant.

Løsninger:

A. PII masking før evaluering:

from azure.ai.evaluation import PIIMaskingPreprocessor

pii_masker = PIIMaskingPreprocessor(
    mask_types=["email", "phone", "ssn", "name"]
)

# Apply før evaluation
masked_traces = pii_masker.process(production_traces)

eval_results = evaluate(
    data=masked_traces,
    evaluators=quality_evaluators
)

B. Separate storage for eval data:

• Trace data med PII → Azure Storage med encryption + access policies (30 day retention)
• Evaluation metrics (anonymized) → Application Insights (long-term storage)

C. User consent:

• Informer brukere at AI-interaksjoner evalueres for kvalitetssikring (privacy notice)
• Tilby opt-out fra evaluation (GDPR Article 21)

Best practice: Implementer PII detection som pre-evaluator filter. Drop traces med PII fra evaluation pipeline hvis consent ikke er innhentet. (High confidence – standard GDPR practice)

NSM Grunnprinsipper for IKT-sikkerhet

Prinsipp: Kjenn din tilstand

Production evaluation er kritisk for å oppfylle NSM-krav om kontinuerlig overvåkning av IKT-systemer.

Implementering:

# Security-focused evaluators
from azure.ai.evaluation import (
    ViolenceEvaluator,
    ProtectedMaterialEvaluator,
    CodeVulnerabilityEvaluator
)

security_evaluators = {
    "violence": ViolenceEvaluator(azure_ai_project),
    "copyright": ProtectedMaterialEvaluator(azure_ai_project),
    "code_vuln": CodeVulnerabilityEvaluator(azure_ai_project)
}

# Alert til sikkerhetsteam ved violations
eval_results = evaluate(
    data=production_traces,
    evaluators=security_evaluators
)

if eval_results["metrics"]["violence_violations"] > 0:
    send_security_alert(severity="HIGH")

Prinsipp: Sett grenser og håndter avvik

• Definer akseptable threshold-verdier for evaluation metrics (f.eks. groundedness > 4.0)
• Automatiser incident response ved threshold-brudd

---

Kostnad og lisensiering

Prismodell for Azure AI Foundry Evaluation

Komponenter:

1. LLM Judge API calls:

   • GPT-4o: $2.50 per 1M input tokens, $10 per 1M output tokens
   • Typisk evaluator bruker ~500 input + 500 output tokens = $0.00625 per evaluering

2. Application Insights (trace storage):

   • $2.30 per GB ingested data
   • Typisk trace: 2-5 KB → $0.0000115 - $0.000029 per trace

3. Safety Evaluators (Azure AI Content Safety backend):

   • $1 per 1000 text records (charged per evaluator run)
   • $0.001 per safety evaluation

Kostnadseksempel (10 000 requests/day, 30% sampling):

• 3000 evaluations/day
• 5 evaluators (2 quality LLM judges + 3 safety)
  • Quality: 2 × 3000 × $0.00625 = $37.50/day
  • Safety: 3 × 3000 × $0.001 = $9/day
  • Trace storage: 10000 × 3 KB × $2.30/GB = $0.07/day
• Total: ~$46.50/day = $1400/month

Optimalisering:

• Bruk gpt-4o-mini for quality evaluators: 50% kostnadsreduksjon ($700/month)
• Reduser sampling til 15%: 50% kostnadsreduksjon ($350/month)
• Kombiner: 75% reduksjon ($350/month)

(Medium-high confidence – pricing subject to change)

MLflow 3 på Databricks – Kostnad

All-Up Databricks Workspace Cost:

• Compute: Serverless SQL warehouse eller Jobs compute for batch evaluation

  • Standard E4s v3 (4 cores): ~$0.50/hour
  • Typical batch eval job (10k traces): 30 minutes = $0.25 per run

• Storage: Unity Catalog managed tables for trace data

  • Delta Lake storage: $0.023/GB/month
  • 10k traces/day × 5 KB × 30 days = 1.5 GB = $0.03/month

• LLM Judge API calls:

  • Same as Azure AI Foundry (charged by OpenAI/Azure OpenAI)

Total monthly cost (10k req/day, daily batch eval):

• Compute: 30 × $0.25 = $7.50
• Storage: $0.03
• LLM calls: $1000 (assume 3 evaluators, 100% sampling)
• Total: ~$1007.50/month

vs. Azure AI Foundry (continuous): MLflow batch er billigere for compute ($7.50 vs. $0 for serverless continuous), men krever samme LLM judge cost. Break-even: Hvis du kan leve med daily batch i stedet for real-time, spar ~$400/month på Application Insights og serverless overhead. (Medium confidence – varies by implementation)

Lisenskrav

Azure AI Foundry SDK:

• Open source (MIT license)
• Krever Azure subscription med:
  • Azure AI Services (for safety evaluators)
  • Azure OpenAI (for LLM judges)
  • Application Insights (for trace storage)

MLflow 3:

• Open source (Apache 2.0 license)
• Krever Databricks Workspace eller standalone MLflow Tracking Server
  • Databricks: Requires Premium or Enterprise workspace tier for Unity Catalog governance
  • Self-hosted MLflow: Gratis, men krever infrastruktur og vedlikehold

Recommendation for offentlig sektor: Azure AI Foundry for compliance-ready, managed service. MLflow for kostnadskontroll og data sovereignty (kan kjøres on-prem/Azure Gov Cloud). (High confidence)

---

For arkitekten (Cosmo)

Når anbefale production evaluation?

Alltid anbefale for:

• Customer-facing AI agents (chatbots, virtual assistants)
• High-stakes applications (finans, helse, juridisk rådgivning)
• Regulerte sektorer (offentlig sektor, kritisk infrastruktur)
• Systemer som bruker external data sources (RAG med ukontrollerte data)

Kan utelates for:

• Internal PoC/prototyper (men bygg inn fra dag 1 for production readiness)
• Batch-prosesserte workflows hvor output human-reviewes før bruk
• Systemer med deterministisk behavior (rules-based, ingen LLM)

Kritiske arkitekturbeslutninger

1. Sampling strategy:

Spør kunde:

• "Hva er akseptabel time-to-detection for quality issues?" (Real-time vs. daily batch)
• "Hva er evalueringsbudsjettet per måned?" (100% sampling vs. 10%)
• "Er alle requests like kritiske?" (Stratified sampling: 100% for VIP users, 10% for standard)

2. Evaluator selection:

Ikke bruk alle evaluatorer – velg strategisk:

• Minimum viable set: Groundedness + Violence (2 evaluators)
• Standard production set: Groundedness, Relevance, Violence, Self-harm (4 evaluators)
• Comprehensive monitoring: 8-10 evaluators (quality + safety + agentic)

Trade-off: Mer enn 5 evaluators gir diminishing returns og øker kostnad eksponentielt. (Medium-high confidence)

3. Storage & retention:

• Hot storage (Application Insights): 30 days (compliance minimum for GDPR)
• Warm storage (Azure Storage Archive): 1-3 years (audit trail)
• Cold storage (offline backup): 5+ years (AI Act high-risk requirement)

Automasjon:

# Azure Logic App eller Azure Function
# Trigger: Daily at 03:00
# Action: Export App Insights traces older than 30 days to Archive Storage

4. Human-in-the-loop integration:

Production evaluation er ikke komplett uten human review loop. Anbefal:

• Weekly review sessions hvor team går gjennom flagged traces (low scores)
• Monthly calibration av LLM judges mot human-labeled golden dataset
• Quarterly retrospective – oppdater evaluators basert på learnings

Tooling: Azure AI Foundry Review App eller custom Power Apps interface til Dataverse.

Red flags å se etter

1. "Vi evaluerer manuelt i produksjon"

• Problem: Ikke skalerbart, subjektivt, ingen audit trail
• Løsning: Start med scheduled batch evaluation (billig, non-invasive) for å bygge case for automation

2. "Vi bruker samme evaluators i dev og prod"

• Problem: Dev-evaluators er ofte optimized for edge cases, ikke representative production traffic
• Løsning: Separate evaluation pipelines – dev for quality iteration, prod for safety + compliance

3. "Vi kjører 100% sampling på alle evaluators"

• Problem: Uholdbar kostnad, ingen prioritering av critical vs. nice-to-have metrics
• Løsning: Tiered sampling (100% safety, 30% quality, 10% experimental evaluators)

4. "Vi har ingen alert thresholds definert"

• Problem: Evaluation data uten action er verdiløst
• Løsning: Start med konservative thresholds (f.eks. violence > 0.1 trigger alert) og tune basert på false positive rate

Sample architecture (high-level)

┌─────────────────────────────────────────────────────────────┐
│ Production AI Application (Azure AI Agent Service)          │
└────────────────┬────────────────────────────────────────────┘
                 │ OpenTelemetry traces
                 ▼
┌─────────────────────────────────────────────────────────────┐
│ Application Insights (Trace Storage + Metrics)              │
│ - Retention: 30 days hot, 90 days warm                      │
│ - RBAC: Data Reader for eval service identity               │
└────────────────┬────────────────────────────────────────────┘
                 │
       ┌─────────┴──────────┐
       ▼                    ▼
┌──────────────────┐  ┌──────────────────────────────────────┐
│ Continuous Eval  │  │ Scheduled Batch Eval                 │
│ (Real-time)      │  │ (Daily 02:00 UTC)                    │
│                  │  │                                      │
│ - Safety @ 100%  │  │ - Quality metrics                    │
│ - Groundedness   │  │ - Trend analysis                     │
│   @ 50%          │  │ - Historical comparison              │
└──────┬───────────┘  └───────┬──────────────────────────────┘
       │                      │
       └──────────┬───────────┘
                  ▼
┌─────────────────────────────────────────────────────────────┐
│ Evaluation Results Storage (App Insights Custom Events)     │
└────────────────┬────────────────────────────────────────────┘
                 │
       ┌─────────┴──────────┐
       ▼                    ▼
┌──────────────────┐  ┌──────────────────────────────────────┐
│ Foundry          │  │ Azure Monitor Alerts                 │
│ Observability    │  │ - Email team on threshold breach     │
│ Dashboard        │  │ - PagerDuty integration              │
└──────────────────┘  └──────────────────────────────────────┘
                                   │
                                   ▼
                         ┌──────────────────────┐
                         │ Incident Response    │
                         │ Playbook             │
                         └──────────────────────┘

Conversation flow med kunde

Åpning:

"For å sikre at deres AI-system opprettholder kvalitet og sikkerhet i produksjon, trenger vi en evalueringsstrategi. Dette er ikke optional for regulerte sektorer – det er en compliance requirement under AI Act for high-risk systems."

Discovery spørsmål:

1. "Hvor mange requests forventer dere daglig i produksjon?" (dimensjonerer sampling)
2. "Hva er kritiske failure modes dere er bekymret for?" (designer evaluator set)
3. "Har dere eksisterende monitoring infrastructure (App Insights)?" (avgjør integration approach)
4. "Hva er akseptabel kostnad for production quality assurance?" (setter budget constraints)
5. "Trenger dere real-time alerts eller er daglige rapporter tilstrekkelig?" (continuous vs. scheduled)

Rekommandasjon (standard scenario):

"Jeg anbefaler å starte med Azure AI Foundry continuous evaluation for safety metrics (Violence, Self-harm) ved 100% sampling, kombinert med scheduled daily batch evaluation for quality metrics (Groundedness, Relevance) ved 30% sampling. Dette gir dere incident detection innen 1 time for safety issues, mens dere holder evalueringskostnaden under $500/måned for en app med 5000 requests/dag. Vi integrerer med Application Insights dere allerede bruker, og setter opp Azure Monitor alerts for automatisk varsling når metrics faller under acceptable thresholds."

Trade-off diskusjon:

"Hvis budsjettet er en constraint, kan vi redusere sampling til 10% for quality metrics og kun kjøre safety evaluators – det kutter kostnaden med 70%, men gir lavere statistical confidence for quality trends. Alternativt kan vi implementere stratified sampling hvor vi evaluerer 100% av høyrisiko-interaksjoner (f.eks. financial transactions) og 10% av standard queries."

Do's and Don'ts

Do:

• Start enkelt (2-3 evaluators) og iterer basert på faktisk production issues
• Integrer evaluation med existing monitoring dashboards (don't create siloed tools)
• Definer alert thresholds i samarbeid med domain experts, ikke basert på arbitrary numbers
• Automasjon av incident response workflows (f.eks. auto-disable agent hvis violence > 0.5)
• Document evaluation methodology i ADR for audit trail

Don't:

• Bruk LLM judges som eneste quality gate – kombiner med human feedback
• Ignorer cost optimization – start med high sampling og juster ned basert på observed variance
• Implement production evaluation etter deployment – bygg inn fra dag 1
• Glem å tune evaluators – de drifter over tid og må kalibreres quarterly
• Evaluate for å evaluate – koble metrics til business outcomes (CSAT, task completion rate)

---

Kilder og verifisering

Primærkilder (Official Microsoft Documentation)

1. Azure AI Foundry Evaluation SDK: Evaluate your generative AI application locally with the Azure AI Evaluation SDK – Comprehensive guide til local og cloud evaluation

2. Continuous Evaluation for Agents: Continuously evaluate your AI agents (preview) – Production monitoring architecture og SDK examples

3. MLflow 3 Evaluation & Monitoring: Evaluate and monitor AI agents - Azure Databricks – MLflow 3 evaluation harness og production scorers

4. Observability Overview: Observability in generative AI - Azure AI Foundry – High-level GenAIOps lifecycle og evaluator taxonomy

5. Model Monitoring for Generative AI: Model monitoring for generative AI applications (preview) – Azure ML Prompt Flow monitoring approach

6. Azure AI Evaluation Python SDK Reference: Azure AI Evaluation client library for Python – API docs for all built-in evaluators

7. Agent Monitoring Dashboard: Monitor agents with the Agent Monitoring Dashboard (preview) – Setup guide for continuous evaluation in Foundry portal

Sekundærkilder (Community & Research)

8. MLflow Scorers Design: Scorers and LLM judges - Azure Databricks – LLM-as-a-judge architecture patterns

9. GenAIOps for MLOps Organizations: Generative AI operations for organizations with MLOps investments – Extending traditional MLOps to GenAI evaluation

Verifikasjonsstatus

High confidence areas (basert på offisiell dokumentasjon og code samples):

• Azure AI Foundry SDK API usage og evaluator configuration
• MLflow 3 production monitoring patterns
• Cost estimation for LLM judges (basert på Azure OpenAI pricing)
• Compliance requirements (AI Act, GDPR) – basert på legal text

Medium confidence areas (basert på inference og best practices):

• Optimal sampling rates (varies by use case)
• Databricks pricing for MLflow workloads (heavily dependent on configuration)
• Power Platform evaluation gaps (product evolves rapidly)
• Human feedback loop implementation (no single canonical pattern)

Ufullstendig informasjon (per april 2026):

• Native Copilot Studio production evaluation features (roadmap item, not released)
• Detailed pricing for Azure AI Content Safety evaluators (bundled pricing, not per-call transparent)
• Long-term accuracy drift for LLM judges (empirical research ongoing)

Oppdateringsfrekvens

Dette området utvikler seg raskt. Anbefalt re-verification:

• Quarterly: Pricing (Azure updates prices regularly)
• Bi-annually: SDK APIs og evaluator availability (new evaluators released frequently)
• Annually: Compliance requirements (AI Act implementation guidance evolves)

Siste research-dato: 2026-02-04 Kilder brukt: 7 Microsoft Learn articles, 15 code samples, Azure AI Evaluation SDK v1.14.0

---

Denne kunnskapsreferansen er sist oppdatert 2026-02-04 av Cosmo Skyberg, Microsoft AI Solution Architect.