MLOps versus LLMOps: infrastructuur voor foundation models

Viacheslav Dubrov

2025-05-06 · Bijgewerkt 2026-07-15 · 7 min · AI-infrastructuur

Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

Wanneer een release van een foundation model regressies vertoont, hoeft het weight file niet gewijzigd te zijn: een prompt, retrieval-index, tool-permission, route of policy kan de veranderde component zijn. Voor ML-, platform- en AI application engineers die al conventionele MLOps opereren, is het praktische artifact daarom een release manifest waarin deze dependencies worden benoemd en wordt verwezen naar de eerste control die moet worden geïnspecteerd zodra er een failure optreedt.

Dit is een editorial operating model, geen bewering dat elke application hetzelfde platform nodig heeft. Behoud MLOps lineage, staged delivery, monitoring en rollback; breid de eenheid die je versioneert uit wanneer gegenereerde antwoorden of tool actions ervoor zorgen dat gedrag van meer afhankelijk is dan alleen de weights.

TL;DR. Behoud MLOps lineage, automation, staged delivery, monitoring en rollback. Breid het release manifest uit met provider of weights, prompts, schemas, retrieval state, tools, routing en policy. Promoveer dat manifest via layered evaluations en gebruik vervolgens privacy-aware traces om production failures om te zetten in nieuwe tests.

Wat MLOps al heeft opgelost

MLOps heeft controls gevestigd die niet verouderd raken wanneer het model tekst genereert:

• lineage van data, code, configuratie en model naar een release
• repeatable training- of build-pipelines
• offline validation vóór promotion
• registries en immutable artifact identity
• staged rollout, service-level objectives, rollback en incident response
• infrastructure telemetry en capacity planning
• access control, retention en audit policy voor data

Foundation models nemen deze behoeften niet weg. Ze maken de oude term “modelversie” simpelweg te beperkt.

De release-eenheid werd een system manifest

Voor een systeem met een foundation model raad ik een manifest aan waarin ten minste het volgende wordt vastgelegd:

application code revision
model provider + model/revision + serving configuration
system and task prompts
response schema + decoding parameters
retrieval corpus snapshot + parser + chunker + embedding model + index
tool definitions + implementation revisions + permission policy
routing, fallback, caching, and budget policy
safety and business-rule revisions
evaluation dataset + scorer revisions

De exacte lijst hangt af van het systeem. De editorial rule is dat je elke component identificeert die onafhankelijk kan wijzigen en user-visible behavior kan beïnvloeden.

Behandel een provider model name als veranderlijk, tenzij de provider een immutable revision documenteert. Een checkpoint hash helpt om self-hosted weights te identificeren, maar ik zou ook de runtime, quantization, template en parallelism configuration vastleggen.

Vijf uitgebreide failure surfaces

Het verschil tussen MLOps en LLMOps wordt duidelijker in failure analysis dan in tool lists.

1. Model en serving

Splits voor planning hosted-model concerns (provider availability, quotas, regional processing en usage cost) van self-hosted concerns (weight supply, GPU capacity, batching, cache policy, quantization en serving). De relevante controls hangen af van de gekozen deployment.

Neem in beide modi latency, errors, throughput, saturation, cost en task-quality checks op in de release decision.

2. Prompt, schema en orchestration

Voor een systeem dat requests at runtime assembleert, versioneer je de assembled request in plaats van alleen prompt text: message ordering, tool descriptions, response schema, decoding, retries, truncation en omliggende code kunnen elk het gedrag veranderen.

Behandel parseerbare JSON als een transport check en test de business invariants van de task afzonderlijk.

3. Retrieval en context

Retrieval voegt een onafhankelijk data product toe tussen de source of truth en het model:

Bewaar voor een retrieval-augmented systeem de source revision, parser- en chunker-versies, embedding identity, index build, access-control metadata en deletion state. Het oorspronkelijke RAG-design scheidt retrieval van generation; gebruik die scheiding om evidence retrieval, authorization filtering en evidence use onafhankelijk te testen. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks beschrijft de retrieve-then-generate-architectuur.

Gebruik een vector index niet als vervanging voor een feature store of warehouse: similarity retrieval, point-in-time features en analytical facts hebben verschillende query- en consistency-behoeften.

4. Tools en actions

Wanneer een model APIs kan aanroepen, vallen tool authentication, least privilege, argument validation, timeouts, idempotency, approval policy en postcondition checks binnen de operationele boundary. NIST’s Generative AI Profile identificeert risico’s rond harmful content, privacy en security; de genoemde controls zijn een scoped engineering recommendation, geen volledige control catalog.

Trace welke tool werd aangeboden, geselecteerd, aangeroepen, afgewezen, opnieuw geprobeerd en gecommit. Een vloeiend final answer bewijst niet dat het action path correct was.

5. Safety, security en policy

Content filters zijn één control, geen complete guardrail layer. Tot de threats behoren ook prompt injection, cross-tenant retrieval, secret disclosure, excessive agency, untrusted model- of node-code en unsafe tool arguments.

Leg deterministic business rules waar mogelijk buiten het model vast. Definieer residual risks, test adversarial cases en wijs een owner aan voor policy changes. NIST’s Generative AI Profile is een nuttige risk inventory, geen kant-en-klare acceptance test.

Evaluation wordt een release gate

Vertrouw voor release decisions over free-form output niet op één geaggregeerd accuracy-cijfer. Gebruik meerdere evidence types en definieer welke daarvan authoritative is voor elke failure mode.

Bouw een evaluation stack met meerdere evidence types:

1. Deterministic checks: schema validity, aanwezige citations, toegestane tools, argument constraints, policy rules, latency en budget.
2. Component metrics: retrieval recall en ranking, tool-selection accuracy, tool-argument correctness en route selection.
3. End-to-end tasks: representatieve inputs met expliciete success criteria en slice labels.
4. Model-based scoring: rubric-driven judgments die zijn gecalibreerd tegen expert labels en worden gemonitord op judge drift.
5. Human review: ambigue, consequential, nieuwe of gesamplede cases waarvoor automation niet authoritative is.
6. Adversarial tests: injection-, data-boundary-, abuse-, refusal- en side-effect-cases die aan het threat model zijn gekoppeld.

Sla resultaten per example op, niet alleen averages, zodat de release review regressies kan inspecteren per language, tenant, document type of action class.

Vergelijk voor een deployment gate een candidate manifest met de current release op dezelfde versioned suite. Stel thresholds voor quality, safety, latency en cost gezamenlijk vast; een goedkopere route die de task niet goed uitvoert, is geen optimization.

Traces verbinden production met evaluation

Infrastructure metrics kunnen een trage model call laten zien. Ze kunnen niet laten zien dat retrieval een unauthorized document retourneerde of dat een tool met het verkeerde account werd aangeroepen. MLflow’s tracing documentation beschrijft traces die de intermediate steps en metadata vastleggen die nodig zijn om dit path te inspecteren.

Leg een trace vast over het volledige decision path:

• identity van het release manifest en request correlation
• model- en provider calls, latency, usage en finish state
• retrieval query, document identifiers, scores en filtering decisions
• prompt/template revision zonder gevoelige content indiscriminately op te slaan
• tool offers, arguments, approvals, results en side-effect identifiers
• policy decisions, retries, fallbacks en final outcome

Tracing creëert een nieuw data-governance-oppervlak. Pas minimization, redaction, tenant isolation, encryption, sampling, retention en access review toe voordat je volledige prompts of documenten verzamelt. OpenTelemetry’s GenAI semantic conventions kunnen helpen met interoperability, maar bevinden zich nog in ontwikkeling. Pin de convention- of schema-versie, instrumentation en collector-versies.

De improvement loop is:

production trace → triaged failure → labeled regression case
                 → candidate change → offline comparison
                 → staged release → monitored outcome

User feedback kan investigation prioriteren, maar een thumbs-up is geen ground truth. Bewaar de omliggende trace en verzamel expert labels voor consequential cases.

De serving gateway is een policy boundary

Een gateway kan application clients loskoppelen van providers of self-hosted engines. Verantwoordelijkheden die je daar kunt onderbrengen zijn onder meer:

• authentication, tenant budgets, quotas en rate limits
• stabiele request- en response-contracten
• route selection op basis van capability, region, latency of evaluated quality
• bounded retries, circuit breakers en expliciete fallback-semantics
• cache partitioning en sensitive-data policy
• usage attribution en propagation van het release manifest

Fallback is evenzeer een behavior change als een reliability mechanism. Als een kleiner model, een alternatieve provider of reduced context de task quality verandert, evalueer en traceer je die branch als een afzonderlijke route.

Plaats niet elke orchestration decision in de gateway. Houd domain rules dicht bij de application en maak ownership zichtbaar.

Fine-tuning is één intervention, niet de maturity ladder

Kies de intervention op basis van de geobserveerde failure:

LoRA bevriest pretrained weights en voegt trainable low-rank matrices toe, waardoor het aantal trainable parameters voor de downstream task afneemt. Die optimization neemt dataset governance, base-model licensing, evaluation, serving compatibility of rollback requirements niet weg.

Een praktische adoption sequence

1. Definieer de user task, harm boundaries, service objectives en cost envelope.
2. Maak het release manifest voordat je een prompt registry, vector database of gateway-product introduceert.
3. Bouw een kleine, geslicede evaluation set en deterministic component tests.
4. Instrumenteer één end-to-end trace met privacy controls en stabiele release identities.
5. Promoveer via shadow, canary of limited traffic met een expliciete rollback trigger.
6. Zet gereviewde production failures om in regression cases en herhaal.

Voeg alleen infrastructure toe wanneer die een benoemde control bezit of een gemeten bottleneck wegneemt. “LLMOps platform” is geen architectuurvereiste.

Conclusie

LLMOps is MLOps toegepast op een grotere behavioral unit. Het model blijft belangrijk, maar prompts, retrieved evidence, tool permissions, routing en policy kunnen de uitkomst veranderen zonder dat de weights wijzigen.

Version die volledige unit, evalueer haar vóór release, trace haar met privacy boundaries en rol haar als één systeem terug.

References

• MLflow: evaluating production traces - Hergebruik production traces voor evaluation en score intermediate trace information.
• MLflow: LLM and agent tracing - Leg intermediate steps en trace metadata vast voor investigation.
• OpenTelemetry GenAI semantic conventions - Conventions in de huidige development-status voor GenAI spans, metrics, events en provider-specific data.
• NIST AI 600-1: Generative AI Profile - Risk categories voor prompt injection, privacy, security en gerelateerde generative-AI-concerns.
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks - De oorspronkelijke retrieve-then-generate-architectuur.
• LoRA: Low-Rank Adaptation of Large Language Models - Frozen pretrained weights plus trainable low-rank matrices voor downstream adaptation.