2025-05-06 · Bijgewerkt 2026-07-15

[!NOTE] Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

MLOps versus LLMOps: Infrastructuur voor Foundation Models en LLM-systemen

Foundation models heeft verschillende aannames ten grondslag aan traditionele MLOps veranderd. Teams passen vaak een vooraf getrainde model aan of maken daar gebruik van, in plaats van elke model vanaf nul te trainen; bovendien moeten de gegenereerde antwoorden en toolacties worden geëvalueerd op basis van meer dan alleen een vaste voorspellingsmeter.

De MLOps-discipline is nog steeds van toepassing. Wat is veranderd, is de operationele eenheid: het gedrag van een taalgebaseerde model-toepassing kan afhangen van prompts, decodificatie, retrieval, contracten voor tools, rechten, routing en beleidsregels, evenals model weights. In dit artikel wordt uitgelegd wat nog steeds nuttig is en welke nieuwe LLM-systemen zijn toegevoegd.

Kort samengevat. Houd de MLOps-lijnages, automatisering, gefaseerde levering, monitoring en mogelijkheid tot terugzetten in stand. Breid het release-manifest uit door provider of weights, prompts, schema’s, de retrieval-status, hulpmiddelen, routing en beleidsregels op te nemen. Zorg ervoor dat dit manifest via gestapelde evaluaties wordt goedgekeurd, en gebruik vervolgens privacybewuste traces om productiefouten om te zetten in nieuwe tests.

Wat MLOps al heeft opgelost

De gevestigde MLOps-controles blijven geldig, zelf wanneer de model tekst genereert:

• Linie van afkomst van gegevens, code, configuraties en model tot een release
• Herhaalbare training of pipelines van modellen
• Offline-validatie vóór publicatie
• Registers en onveranderlijke identiteit van artefacten
• Gecontroleerde implementatie, serviceleveldoelstellingen, mogelijkheid tot terugdraaien en incidentbeheer
• Infrastructuurtelemetrie en capaciteitsbeheer planning
• Toegangsbeheer, opslagbeleid en auditrichtlijnen voor gegevens

De Foundation models mag deze vereisten niet weghalen. Zij zorgen er namelijk voor dat de oude uitdrukking “model versie” te beknopt wordt.

De release-eenheid is omgevormd tot een systeemmanifest

Bij een conventionele voorspellingsdienst zijn de code, de feature-logica en de identiteit van model meestal verantwoordelijk voor de grootste veranderingen in het gedrag. Bij een foundation-model systeem moet u ten minste het volgende vastleggen:

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. Het onveranderlijke principe is dat één manifest iedere component die op zichzelf kan veranderen en daardoor het voor de gebruiker zichtbare gedrag kan beïnvloeden, moet identificeren.

De alias model van een provider is niet per se een onveranderlijk artefact. Een zelf gehost checkpoint hash is nauwkeuriger, maar runtime-, quantization-, sjabloon- en paralleliteitsinstellingen moeten nog steeds in het releaseverslag worden opgenomen.

Vijf uitgebreide foutoppervlakken

Het verschil tussen MLOps en LLMOps wordt duidelijker bij het analyseren van fouten dan wanneer men alleen naar lijsten met tools kijkt.

1. Model en serving

Bij gehosteerde models oplossingen spelen beschikbaarheid van providers, quota’s, regionale verwerking, wijzigingen van aliases en een pay-per-token-model een belangrijke rol. Bij zelfgehosteerde models oplossingen zijn factoren als weight-ketens, GPU-capaciteit, batchverwerking, cachebeleid, quantization en gedistribueerde serving-architecturen van cruciaal belang.

Beide hebben behoefte aan latency, d.w.z. fouten, throughput, oftewel verzadiging, en aan kostenbeheersing. Geen enkele deployment-modus schaft de kwaliteitsevaluatie af.

2. Prompt, schema en orchestration

Een prompt is een configuratie die op code lijkt, maar alleen prompt-tekst definieert niet het gedrag. De volgorde van berichten, beschrijvingen van tools, het responsschema, de decodering, herproberingen, truncatie en de bijbehorende code spelen allemaal een belangrijke rol.

Maak een versie aan van de samengestelde verzoek en de orchestration-policy. Test structured outputs met parsers en bedrijfsinvarianten, in plaats van ‘geldige JSON’ als succesvolle uitvoering van de taak te beschouwen.

3. Retrieval en context

Retrieval voegt een afzonderlijk dataproduct toe tussen de bron van waarheid en de model:

De pipeline moet de oorspronkelijke revisie, de versies van de parser en chunker, de embedding-identiteit, de opbouw van de index, de metadata voor toegangsbeheer en de verwijderingsstatus behouden. Evalueer vóór generatie de retrieval: of het systeem het juiste bewijs heeft gevonden, of de autorisatiefiltering is toegepast, en of het antwoord het verstrekte bewijs correct heeft gebruikt.

Een vectorindex vervangt geen featurestore of -warehouse. Het dient ter bepaling van gelijkenis retrieval; gestructureerde kenmerken op een specifiek tijdstip en analytische feiten hebben namelijk andere vereisten met betrekking tot consistentie en query’s.

4. Hulpmiddelen en acties

Wanneer een model een APIs kan aanroepen, kunnen kwaliteitsproblemen tot bijwerkingen leiden. De operationele grenzen omvatten nu ook de authenticatie van hulpprogramma’s, het principe van minimale rechten, validatie van argumenten, tijdslimieten, idempotentie, goedkeuringsbeleid en controles op de postconditie.

Trace Welk hulpmiddel werd aangeboden, geselecteerd, opgeroepen, afgewezen, opnieuw geprobeerd en gecommitteerd. Een vloeiend eindantwoord kan niet aantonen dat het actiepad correct was.

5. Veiligheid, beveiliging en beleid

Inhoudsfilters vormen slechts één vorm van controle en maken geen geheel van een guardrail-laag uit. Bedreigingen omvatten ook prompt injection, cross-tenant retrieval-problemen, lekken van geheime informatie, ongecontroleerd handelen van agenten, onbetrouwbare model-of knoopcode, evenals onveilige argumenten voor hulpprogramma’s.

Probeer deterministische bedrijfsregels waar mogelijk buiten model te formuleren. Definieer residuele risico’s, teste adversarische gevallen en wijst iemand aan die verantwoordelijk is voor eventuele wijzigingen in de beleidsregels. Het generatieve AI Profiel van NIST vormt een nuttig overzicht van risico’s, maar is geen compleet acceptatieproces.

Evaluatie vormt een releasegate

Vrije vorm van uitvoer maakt het onvoldoende om slechts één algemeen accuraatheidsgetal te gebruiken. Het betekent echter niet dat de kwaliteit onmeetbaar is.

Bouw een evaluatiestack met verschillende typen bewijsmateriaal:

1. Deterministische controles: validiteit van het schema, aanwezigheid van citaten, toegestane hulpmiddelen, beperkingen voor argumenten, beleidsregels, latency, en het budget.
2. Metricen voor componenten: retrieval-recall en rangschikking, nauwkeurigheid bij keuze van hulpmiddelen, correctheid van argumenten van hulpmiddelen, en selectie van routes.
3. End-to-end taken: representatieve invoergegevens met expliciete succescriteria en labelen voor afzonderlijke delen.
4. Scoring gebaseerd op Model: oordelen gebaseerd op een rubriek die is gekalibreerd aan de hand van labels van experts, waarbij ook wordt gecontroleerd op judge-drift.
5. Menselijke beoordeling: ambiguïteit, hoge impact, nieuwe gevallen of geselecteerde casussen waarin automatisering geen autoriteit heeft.
6. Adversariale tests: injectietests, tests rondom gegevensgrenzen, misbruik, weigeringsscenarios en gevolgen die verband houden met de dreiging model.

Sla de resultaten per voorbeeld op, en niet alleen de gemiddelden. Een nieuwe versie kan het gemiddelde verbeteren, terwijl dit tegelijkertijd negatieve effecten heeft voor een bepaalde taal, gebruiker, documenttype of actieklasse.

De deployment-poort vergelijkt een kandidaatmanifest met de huidige versie van hetzelfde geversioneerde pakket. De drempelwaarden moeten gezamenlijk rekening houden met kwaliteit, veiligheid, latency en kosten; een goedkopere route die de taak niet voltooit, vormt geen optimalisatie.

Traces de productieomgeving opnieuw verbinden met de evaluatieomgeving

Infrastructuurmeters kunnen een trage model-aanroep weergeven. Ze kunnen echter niet aantonen dat retrieval een niet-geautoriseerd document heeft teruggestuurd of dat een hulpmiddel is opgeroepen met het verkeerde account.

Vang een trace op langs het beslissingspad:

• Identiteit van het release-manifest en correlatie van verzoeken
• model en aanroepen door providers, latency, gebruik en afsluitingsstatus
• retrieval-query’s, documentidentificatoren, scores en beslissingen voor filtering
• prompt/template-revisies zonder willekeurige opslag van gevoelige inhoud
• Hulpprogramma’s, argumenten, goedkeuringen, resultaten en identificatoren van bijwerkingen
• Beleidsbeslissingen, herproberingen, fallback-mogelijkheden en uiteindelijke uitkomst

Tracing genereert een nieuwe interface voor data-governance. Voer minimalisatie, redactie, isolatie van tenants, encryptie, sampling, retentie en toegangscontrole uit voordat er volledige prompts of documenten worden verzameld. De generatieve-AI conventies van OpenTelemetry kunnen de interoperabiliteit bevorderen, maar hun schema’s blijven zich ontwikkelen; houd dus de versies van de instrumentatie en verzamelaars vast.

De verbeteringscyclus is:

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

Gebruikersfeedback kan de prioriteit van een onderzoek bepalen, maar een positieve reactie vormt nog geen betrouwbare feitenbasis. Houd de omliggende tekst trace intact en verkrijg deskundige labels voor gevallen met ernstige gevolgen.

De serving gateway vormt een grens voor beleidsregels

Een gateway kan applicatieclients loskoppelen van providers of zelf gehoste engines. Tot de nuttige taken behoren onder andere:

• authenticatie, budgetten voor gebruikers, quota’s en snelheidsbeperkingen
• stabiele contracten voor verzoeken en antwoorden
• routekeuze op basis van capaciteit, regio, latency, of geëvalueerde kwaliteit
• begrensde herproberingen, circuit breakers en expliciete fallback-semantiek
• partitieerden van caches en beleid met betrekking tot gevoelige gegevens
• toewijzing van gebruik en verspreiding van release-manifesten

Een fallback is een verandering in gedrag, en niet louter een mechanisme voor betrouwbaarheid. Als een kleinere model, een alternatieve provider of een verminderde context de kwaliteit van de taak beïnvloedt, dient die tak te worden geëvalueerd en trace als aparte route te worden behandeld.

Plaats niet elke beslissing die wordt genomen met orchestration in de gateway. Houd de domeinregels dicht bij de applicatie en zorg ervoor dat de verantwoordelijkheden duidelijk zichtbaar zijn.

Fine-tuning is één interventie, en niet een ladder van volwassenheidsniveaus

Kies de interventie op basis van de waargenomen fout:

LoRA en andere parameter-efficiënte methoden verminderen het aantal te trainen parameters; ze verwijderen echter niet de dataset governance, de licentievereisten op basis van model, de evaluatie, de serving compatibiliteit, noch de vereisten voor terugvalbeheer.

Een praktische implementatievolgorde

1. Definieer de gebruikersopdracht, de grenzen van schade, de doelstellingen van de dienst en het budget voor kosten.
2. Maak eerst het release-manifest aan voordat er een prompt register, vector database of gateway-product wordt geïntroduceerd.
3. Bouw een klein, gefragmenteerd evaluatiebestand op samen met deterministische componenttesten.
4. Instrumenteer één end-to-end trace-omgeving met privacybeheersmaatregelen en stabiele releaseidentiteiten.
5. Zet de implementatie in om via shadow-, canary- of beperkt verkeer, waarbij er een duidelijke trigger voor terugval is.
6. Zorg ervoor dat gemonitoreerde productiefouten worden omgezet in regressietestgevallen en herhaal dit proces.

Voeg infrastructuur alleen toe wanneer deze een genoemde controller bevat of een gemeten bottleneck verwijdert. Een “LLMOps-platform” vormt geen vereiste voor de architectuur.

Conclusie

LLMOps is MLOps toegepast op een grotere gedragsunit. De model blijft belangrijk, maar prompts, de opgehaalde bewijzen, de rechten van tools, routing en beleidsregels kunnen het resultaat veranderen zonder de weights aan te passen.

De versie die de hele eenheid omvat, moet worden geëvalueerd voordat deze wordt vrijgegeven; trace deze moet worden afgeschermd met privacymaatregelen, waarna de gehele systeemstructuur weer op de oorspronkelijke staat wordt gezet. Dat is het operationele verschil dat van belang is.

Referenties

• MLflow: evaluatie van in productie gebruikte modellen traces
• MLflow: LLM en agent tracing
• OpenTelemetry generatieve-AI register van semantische conventies
• NIST AI 600-1: Generatieve AI Profiel