Byg en agentbaseret MLOps-pipeline med evalueringssløjfer

I klassisk MLOps bygges en lineær pipeline: data flyder én vej, modeller trænes, valideres og rulles ud i en sekvens af skridt, som alle kalder på det samme sæt af scripts eller notebooks. Denne model har tjent os godt, men den er også skrøbelig: Ét brud i kæden kan stoppe hele processen, og tilpasninger - nye datakilder, ændrede compliance-krav, andre mål - kræver ofte omfattende omlægninger.

Fra monolit til multi-agent

Med en agentbaseret tilgang brydes pipeline-monolitten op i autonome enheder:

Hver agent besidder:

• Klare mål (kvalitet, ydeevne, sikkerhed …).
• Egnet værktøjskasse (biblioteker, API-nøgler, compute).
• Politikker - kontraktligt definerede guardrails, som stopper eller eskalerer, når noget afviger.

Resultatet minder om et økosystem af mikrotjenester, men fokuseret på ML-domænet: agenter kommunikerer hændelses-drevet (message bus eller workflow-motor) og kan skaleres uafhængigt. Fejl lokaliseres hurtigt, og nye agenter kan tilføjes uden at røre resten af kæden.

Evalueringssløjfer som førsteprioritet

I stedet for at betragte evaluering som et sidste step, gør agentparadigmet den til en kontinuerlig sløjfe på tre niveauer:

1. Før træning - data readiness
   Datakvalitet kontrolleres via syntetiske tests (f.eks. outlier-score, missing value heatmap) og data contracts. Koden stopper tidligt, hvis datastamtræ eller PII-tags ikke stemmer. Resultat: færre ”garbage in, garbage out”-fejl.
2. Før udrulning - offline/shadow-evaluering
   Kandidatmodeller afvikles mod hold-out data, historiske logs eller real-time shadow traffic. Agenter scorer robusthed, bias og angrebsflader (prompt injection, adversarial examples) og sammenligner mod definerede baseline-metrikker. Kun modeller med ”grøn” rapport sendes videre til releaseagenten.
3. Efter udrulning - online drift
   I produktion udsættes nye versioner gradvist (A/B eller canary). Overvågningsagenten måler SLA, konceptdrift og omkostninger. Hvis performance falder, udløses automatisk rollback eller retrænings-trigger. På den måde bliver evaluering den levende puls i systemet, ikke en engangsøvelse.

Human-in-the-loop: Når automatik møder omtanke

Selv de skarpeste agenter må somme tider spørge om lov. To mekanismer sikrer sund menneskelig kontrol:

• Godkendelsespunkter: En risikobaseret policy engine kan kræve menneskelig sign-off, fx hvis bias-score > 0,05 eller modellen rører finansielle beslutninger. UI’en viser forklaringer, datasammenfatning og fairness-rapport.
• Feedback-kuratering: Driftsagenten indsamler brugerfeedback (thumbs up/down, support tickets). En human reviewer triagerer mislabeled events og føjer dem til næste træningsbatch. Det sikrer, at modellen lærer af virkelige fejl - ikke tilfældige støjkilder.

Hvorfor det betaler sig

Fordelene ved agentbaseret MLOps med indbyggede evalueringssløjfer er håndgribelige:

• Hurtigere iterationer: Hver agent kan deployes eller opgraderes isoleret, hvilket minimerer ventetid og “big-bang” releases.
• Bedre robusthed: Tidlig datavalidering og løbende driftsovervågning fanger fejl, før de bliver forretningskritiske.
• Styrket compliance: Audit-logs, versionerede artefakter og politikstyrede gates gør det lettere at efterleve GDPR, ISO 27001 m.m.
• Tættere kobling til forretningen: Evalueringsmetrikker defineres sammen med domæne-teams; agenternes mål er derfor direkte alignet med KPI’er som churn, konvertering eller kreditrisiko.

Kort sagt: agentbaseret MLOps flytter os fra én lang, skrøbelig pipeline til et adaptivt nervesystem, hvor kvalitetssikring er indbygget fra første datapunkt til sidste produktionskald. Det giver både ro i maven hos risk-manageren og højere tempo hos udvikleren - og det er præcis, hvad fremtidens ML-projekter kræver.

2. Infrastrukturlag

1. Datalake / Warehouse - rå, berigede og aggregerede lag (med isolerede “sandbox” domæner).
2. Artefaktlager - container-images, træningspakker, eval-rapporter (f.eks. OCI Registry + S3).
3. Modelregister - versions- & stage-labelled modeller med immutability.
4. Beskedbus & workflow-orkestrering - Kafka / NATS + Argo Workflows til event-drevet koordinering.
5. Hemmelighedsstyring - Vault / AWS Secrets Manager med least privilege.
6. Policy- & guardrail-motor - Rego (OPA) eller Kyverno til automatiske compliance-checks.

3. Datastrømme & kontrolsløjfer

• Event-drevet koordinering: Hver agent publicerer status-events (success, fail, metrics) på beskedbussen. Efterfølgende agenter abonnerer på relevante topics og reagerer asynkront.
• Kvalitetsporte (gates): Resultater fra Data-, Eval- og Sikkerhedsagent sendes til en Gatekeeper API, som kun lader flowet fortsætte ved “pass”.
• Automatiske retrænings-triggers:
  • Data drift > τ
  • Model performance < SLO
  • Ny business-regel / feature release
• Proaktiv alarmering: Driftsagenten emitterer Alert events, der rammer PagerDuty, Slack og automatisk skalerings-/rollback-workflow.

4. Governance & compliance-forankring

• Audit logs: Alle agenthandles persistenteres med request/response-payload, bruger-/servicekonto og tidsstempel.
• Reproducerbarhed: Kombinér code commit hash, Docker digest, data-snapshot og hyperparametre i én lineage-record.
• Datastamtavle: Automatisk “upstream-impact” og “downstream-usage” kortlægning via OpenLineage.
• Risikobaserede godkendelser: Model releases med risk score > X kræver human sign-off + DPO/infosec review. Lav-risiko releases kan auto-promoveres.

Resultatet er en modulær, selvforklarende arkitektur hvor hver agent er både specialist og teamplayer - bundet sammen af events, klare politikker og gennemsigtig governance.

Her er en hands-on byggeplan, som trin for trin fører dig fra det første proof-of-concept til en fuldt produktionsklar, agent-drevet MLOps-pipeline med evalueringssløjfer og solid governance.

1. Etabler infrastruktur med IaC/GitOps & definer SLO’er
   • Provisionér cloud- eller on-prem-klynge via Terraform/Pulumi og sæt GitOps med Argo CD eller Flux.
   • Dedikér namespaces til hver agenttype og læg RBAC-politikker i repoet.
   • Indfør Service Level Objectives (fx <150 ms inferens P95, <2 % data-fejl) og placer dem som .slo.yaml, der checks ind i CI-flowet.
   • Knyt Secrets Manager (Vault, AWS SM) og policy-motor (OPA/Kyverno) helt fra start.
2. Model agenternes mål, værktøjer og politikker
   • Beskriv hver agent i en deklarativ agent_spec.yml:
     • Goal (hvad skal der optimeres?)
     • Tools (API’er, SDK’er, scripts)
     • Policies/Guardrails (kvoter, privacy-krav, cost-budget)
   • Implementér reference-agenter som Python-pakker/kontainere med tydelige input/output-schemas.
   • Bind dem sammen via event bus (Kafka/PubSub) eller orkestrering (Temporal/KNative Events).
3. Opsæt data- og featureflow med validering & versionering
   • Lad data-/kvalitetsagenten trække rå data, køre Great Expectations tests og versionere snapshots med DVC eller lakeFS.
   • Gem features i en feature store (Feast, Tecton).
     Valider både online (low-latency) og offline (træning) konsistens.
   • Opsæt data contracts: skemaændringer skaber pull-requests, der kræver human review.
4. Implementér trænings- & evalueringspakker
   • Brug MLflow/Weights&Biases til eksperiment-tracking; gem artefakter i et artefaktlager.
   • Definér faste metrikker (accuracy, AUROC, latency, CO₂-footprint).
   • Tilføj baseline-tests: modellen må ikke være dårligere end sidste godkendte release ± tolerance.
   • Lav røde-team scenarier (adversarial input, toxic prompts, fairness-stress) som en del af CI-jobbet.
   • Evalueringsagenten skriver resultater til model_evals/; kun modeller med grønne checks ryger i model-registeret.
5. Tilføj udrulning med canary/shadow & automatiske rollback-kriterier
   • Releaseagenten deployer som shadow bag eksisterende service eller som canary til fx 5 % trafik via Istio/Linkerd.
   • Definér abort-kriterier: >x % 5xx-fejl, >y % degradering i forretnings-KPI → automatisk rollback.
   • Alle releases får en git tag, et modelVersion i registry og en audit-log.
6. Kobl telemetri, drift- & bias-monitorering samt feedbackindsamling
   • Driftsagenten eksponerer metrics til Prometheus; dashboards i Grafana/Datadog.
   • Brug Evidently/WhyLabs til data- & konceptdrift; alert hvis JS-divergens > threshold.
   • Log inference-payloads (PII-saniteret) i minio://inference-logs til senere re-træning.
   • Integrér human-in-the-loop: Product- eller Risk-owner modtager Slack-notifikationer om outliers og kan klas­sificere “false negatives”.
7. Automatisér retræning med klare triggers & sikkerhedsgodkendelser
   • Opsæt planlagte checks (cron) + event-drevne triggers (drift, nye labels, sikkerheds-patches).
   • Pipeline kører fuld evalueringssløjfe; ved major model-skift kræves manuel godkendelse (JIRA ticket → ArgoCD hold).
   • Tag højde for cost-kontrol: GPU-kvoter, caching af embeddings, spot-priser.

Hyppige faldgruber du skal styre uden om

• Data-lækage: Model ser fremtidige features under træning - brug tids-baserede split og datastamtavle.
• Overfitting til eval-sæt: Roter eval-data regelmæssigt og hold et hemmeligt hold-out.
• Prompt-/policy-drift (LLM-cases): Track prompts som kode og hold versionssporing på guardrails.
• Manglende cache-/omkostningskontrol: Implementér server-side caching og budget-alarmer.
• Svage rollback-planer: Øv “game-day” scenarier; test at kubectl rollout undo + feature-flags virker.

Afsluttende checkliste

Følger du denne køreplan-og husker løbende at inddrage mennesker dér, hvor risici og etik kræver det-har du et robust fundament til at levere agentbaserede modeller, der både performer, skalér og efterlever virksomhedens og lovgivningens krav.