LLMOps: LLM's monitoren in productie

LLMOps is de discipline van het draaien van large language model-features in productie: het bewaken van kwaliteit, kosten, latency en gedrag, het onderscheppen van regressies voordat gebruikers ze zien, en het opzetten van een echte on-call-praktijk voor AI-systemen — net zoals je dat voor elke kritieke dienst zou doen. Heeft je team een chatbot, een RAG-assistent of een agent gelanceerd en vervolgens gemerkt dat "het werkt op mijn prompt" iets heel anders is dan "het werkt in productie"? Dan is LLMOps de ontbrekende helft van het werk. Deze gids is een praktische, stack-onafhankelijke uitleg van wat LLMOps inhoudt en hoe je het inricht.

Het vervelende is dat de feature lanceren de makkelijke 20% is. Hem góéd houden — terwijl modellen onder je veranderen, gebruikersinvoer verschuift, je promptbibliotheek groeit en de kosten ongemerkt oplopen — is de andere 80%. De meeste teams leren dit op de harde manier, meestal via een boze screenshot van een klant of een cloudrekening die van de ene op de andere dag verdrievoudigt.

LLMOps versus MLOps: wat verandert er echt

Heb je MLOps gedaan, dan bezit je al de helft van de spieren: versiebeheer, deployment, monitoring, hertrainen. Maar LLM's breken een aantal aannames waar traditionele machine learning stilletjes op leunde, en juist daar verdient LLMOps zijn naam.

Ten eerste is het model meestal niet van jou. Je roept een externe API aan waarvan de gewichten kunnen veranderen zonder een versienummer dat jij beheert, dus "het model is niet veranderd" is geen veilige aanname meer. Ten tweede is de uitvoer vrije tekst, geen klasse-label of getal, dus je kunt de nauwkeurigheid niet met één regel code tegen een ground truth afzetten — kwaliteit is vaag en heeft vaak een beoordelaar nodig. Ten derde kan dezelfde invoer per keer een andere uitvoer geven, wat reproduceerbaarheid oprecht lastig maakt. Ten vierde zijn de kosten per token en niet verwaarloosbaar, dus een inefficiënte prompt is een kostenpost, geen voetnoot. En ten vijfde zijn de faalvormen nieuw: hallucinatie, prompt injection en sluipende kwaliteitsdaling in plaats van een nette foutmelding.

LLMOps is dus geen nieuwe verpakking van MLOps. Het is MLOps plus een set praktijken die specifiek voor probabilistische, tekstgenererende, extern gehoste systemen zijn gebouwd. De governance-ruggengraat blijft gelden — het NIST AI Risk Management Framework biedt een verstandige Govern-Map-Measure-Manage-structuur die naadloos op het draaien van LLM's aansluit — maar de dagelijkse instrumentatie is anders.

Tracing: één verzoek door de hele keten volgen

Een moderne LLM-feature is zelden één enkele call. Een gebruikersvraag zet een retrieval-stap in gang, misschien een re-ranking-stap, een prompt die uit meerdere templates is samengesteld, één of meer modelaanroepen, wat tool- of functieaanroepen en een nabewerking. Als het antwoord fout is, is "de LLM hallucineerde" meestal de verkeerde diagnose. Vaker haalde de retrieval het verkeerde fragment op, gaf een tool verouderde data terug, of liet de prompt-template stilletjes een variabele vallen.

Met tracing zie je de hele keten voor één verzoek: elke span, de in- en uitvoer, de latency en de tokenkosten. Dit is het meest renderende dat je kunt toevoegen, want zonder tracing debug je blind. Bemoedigend is dat dit nu standaardiseert: OpenTelemetry heeft semantische conventies voor generative AI-spans gepubliceerd, zodat je modelaanroepen, agent-stappen en tool-uitvoeringen leveranciersneutraal kunt instrumenteren in plaats van je vast te leggen aan één observability-product. Adopteer die conventies vroeg — ze zijn nog in ontwikkeling, maar bouwen op de standaard is beter dan bouwen op een propriëtair schema dat je later moet migreren.

De praktische regel: elke LLM-call en elke stap eromheen hoort een span uit te zenden met de prompt, het antwoord, het model en de versie, de tokenaantallen en de latency. Kun je een misgelopen gesprek volledig uit je traces afspelen, dan heb je het fundament. Kan dat niet, los dat dan eerst op.

Prompts en uitvoer loggen — en het privacyprobleem

Traces zijn waardeloos als ze niet vastleggen wat er werkelijk in- en uitging. Log de volledige prompt (inclusief de opgehaalde context en systeeminstructies) en de volledige completion. Dat is wat je de "waarom zei het dat"-vragen laat debuggen die je week gaan vullen.

Maar hier zit de spanning waar niemand je voor waarschuwt: die logs bevatten gebruikersdata, soms gevoelige gebruikersdata, en die sla je nu op. Voor een Europees bedrijf is dat geen optioneel klusje — het is een verplichting op het gebied van gegevensbescherming. Bepaal bewust wat je bewaart, hoe lang, en wie het mag zien. Anonimiseer of hash persoonsgegevens waar het kan, stel bewaartermijnen in en houd een toegangslog bij. Het Generative AI Profile van NIST is hier de moeite waard, omdat het dataprivacy en confabulatie als eersteklas risico's benoemt, niet als randgevallen. Je data-engineering op orde hebben — pijplijnen, opslag, governance — is wat compliant loggen haalbaar maakt in plaats van een noodgreep.

Dit artikel is algemene technische begeleiding, geen juridisch advies; bevestig je specifieke verplichtingen rond gegevensbescherming bij een gekwalificeerde professional.

De metrics die ertoe doen: kwaliteit, kosten en latency

Je kunt niet sturen wat je niet meet, en voor LLM's verdienen drie dashboards een permanente plek op je scherm.

Kwaliteit is de lastige, want er is geen enkel getal. In de praktijk combineer je meerdere proxies: geautomatiseerde evaluaties op een steekproef van het verkeer, gestructureerde gebruikersfeedback (duimpjes, correcties, escalaties) en periodieke menselijke review. Jaag niet op één "kwaliteitsscore" — volg een klein mandje aan signalen en houd de trend in de gaten. We gaan dieper op de methoden in onze gids over het evalueren van LLM-applicaties, en bij retrieval-systemen is de retrieval-kwaliteit vaak de echte hefboom.

Kosten horen zichtbaar te zijn per feature, per gebruikerssegment en idealiter per gesprek. Tokengebruik is de meter, en die beweegt om redenen die makkelijk te missen zijn: een langere systeemprompt, een grotere opgehaalde context, een spraakzamer model, een retry-lus die vaker afgaat dan je denkt. Een kostendashboard maakt van "waarom is de rekening 40% hoger" geen forensisch onderzoek maar een blik van vijf minuten.

Latency is een producteigenschap, niet alleen een ops-metric. Meet in percentielen, niet in gemiddelden — de p95 is wat je gefrustreerde gebruikers echt voelen. Volg de tijd tot het eerste token los van de totale tijd, want bij een streaming-interface is dat eerste token wat het levend laat aanvoelen. Trage, correcte antwoorden verliezen alsnog gebruikers.

Drift opsporen terwijl er aan jouw kant niets veranderde

Dit is de faalvorm die teams verrast. Je code is ongewijzigd, je prompts zijn ongewijzigd, en tóch zakt de kwaliteit. Twee dingen driften onder je vandaan. De aanbieder kan het model achter hetzelfde endpoint bijwerken en het gedrag subtiel veranderen. En je gebruikers driften — ze vragen naar nieuwe producten, in nieuwe formuleringen, in talen waar je niet op testte.

Je vangt drift door doorlopend een vaste set representatieve gevallen te evalueren en op beweging te letten, en door de verdeling van echte in- en uitvoer over tijd te monitoren. Verschuift je gemiddelde uitvoerlengte, weigeringspercentage of eval-score zonder een deploy aan jouw kant, dan is dat je sein om te onderzoeken. Pin modelversies vast waar je aanbieder dat toelaat, en behandel een modelupdate van de aanbieder als elke andere dependency-upgrade — test hem in een staging-eval voordat hij gebruikers bereikt.

Evals in CI: vang regressies voordat je gebruikers dat doen

De ene praktijk die teams die 's nachts slapen onderscheidt van teams die branden blussen, is evaluaties draaien in continuous integration. Elke keer dat je een prompt wijzigt, een model verwisselt of retrieval bijstelt, hoort een geautomatiseerde eval-suite te draaien tegen een samengestelde set gevallen en de wijziging te blokkeren als de kwaliteit onder een drempel zakt. Dit is unit testing voor probabilistische systemen, en op elke serieuze schaal is het niet onderhandelbaar.

Bouw de eval-set uit echte, interessante gevallen: de lastige vragen, de eerdere missers, de randgevallen die je ooit voor schut zetten. Neem adversariële gevallen op voor veiligheid — pogingen tot prompt injection en jailbreaks — want een promptwijziging die de behulpzaamheid verbetert kan stilletjes je guardrails verzwakken. Ben je een systeem tegen zulke aanvallen aan het harden, dan past ons stuk over LLM-guardrails natuurlijk bij een eval-in-CI-discipline. Gebruik een mix van deterministische checks (bevat de uitvoer de vereiste disclaimer, is het geldige JSON, citeert het een bron) en modelbeoordeelde checks voor het vage werk, en houd altijd een mens in de lus voor de gevallen waar de beoordelaars het oneens zijn.

Feedbackloops: gebruikerssignaal omzetten in verbetering

Je gebruikers draaien de beste eval die je ooit krijgt, gratis, de hele dag. De teams die het snelst verbeteren zijn degene die dat signaal vastleggen en terug het systeem in sturen. Een duim omlaag, een handmatige correctie door een supportmedewerker, een escalatie naar een mens, een afgebroken gesprek — elk is een gelabeld voorbeeld van iets dat niet werkte.

Sluit de lus bewust. Voer bevestigde missers terug in je eval-set, zodat dezelfde fout niet opnieuw live kan. Gebruik correcties om je retrieval-content of prompt-instructies te verbeteren. Let op escalatieredenen voor patronen die op een oplosbaar gat wijzen. Hier houdt LLMOps op defensieve monitoring te zijn en wordt het een echt vliegwiel — het systeem wordt meetbaar beter omdat je systematisch van productie leert, precies de lus die we inbouwen in agents in productie.

On-call voor AI: incidenten, alerts en runbooks

Als je LLM-feature om 2 uur 's nachts ontspoort, moet iemand het weten en moet iemand handelen. AI-systemen verdienen dezelfde operationele ernst als elke andere productiedienst, maar de alerts zijn anders. Je let niet alleen op fouten en uitval; je let op een piek in weigeringen, een instortende eval-score, een uitschieter in tokenkosten, een sprong in latency of een golf van duimen omlaag.

Definieer wat een AI-incident is voor jouw product en schrijf runbooks voor de gangbare gevallen. Wat doe je als de aanbieder een storing heeft — schakel je over op een backupmodel, degradeer je netjes, of zet je verzoeken in de wachtrij? Wat is je rollback-pad als een promptwijziging de kwaliteit onderuithaalt? Wie wordt gepiept als de kosten door een drempel schieten? Die antwoorden vóór het incident op papier hebben is het verschil tussen een fix van vijf minuten en een chaos van vijf uur. Een prompt terugdraaien hoort net zo snel en saai te zijn als code terugdraaien.

Monitoren op security en misbruik

Kwaliteit en kosten zijn de metrics waar teams als eerste naar grijpen, maar een LLM in productie is ook een aanvalsoppervlak, en je monitoring moet dat weerspiegelen. Twee categorieën verdienen speciale aandacht. De eerste is prompt injection: gebruikers (of content die via retrieval binnenkomt) die je systeeminstructies proberen te overschrijven en het model iets laten doen wat niet de bedoeling is. De tweede is datalekkage: het model dat informatie uit zijn context prijsgeeft die deze specifieke gebruiker nooit had mogen zien.

Je vangt niet wat je niet in de gaten houdt, dus voeg signalen toe die specifiek op misbruik letten. Markeer gesprekken waarin de modeluitvoer fragmenten van de systeemprompt bevat, waarin weigeringspatronen plots pieken of instorten, of waarin één gebruiker het endpoint op een geautomatiseerd ogende manier bestookt. Stel rate limits per gebruiker in, en log genoeg om een incident te reconstrueren zonder ruwe persoonsgegevens op te potten. Behandel een sprong in guardrail-triggers zoals je een sprong in 500-fouten zou behandelen — als een piepwaardig signaal, geen curiositeit. De schadelijkste storingen zijn zelden luide crashes; het zijn stille, plausibel ogende antwoorden die gemanipuleerd zijn of iets privés blootlegden, en alleen bewuste monitoring brengt ze aan het licht.

Een uitgewerkt voorbeeld: een kwaliteitsdaling opsporen

Theorie is goedkoop, dus zo speelt het zich af op een gewone dinsdag. Het duim-omlaag-percentage van je supportassistent klimt in twee dagen van twee naar negen procent. Er is niets gedeployed. Waar kijk je?

Je begint bij je traces, gefilterd op de duim-omlaag-gesprekken. Als je er tien leest, valt op dat ze zich clusteren rond vragen over een producttier die vorige week is gelanceerd. Het model geeft vol overtuiging verouderde prijzen. Nu is de diagnose snel: dit is geen modelprobleem en geen promptprobleem — het is een retrieval- en contentprobleem. De documentatie van de nieuwe tier is nooit geïndexeerd, dus retrieval geeft de dichtstbijzijnde oude pagina terug en het model vat trouw verouderde feiten samen. Zonder tracing had je een dag lang het model verdacht; mét tracing vond je de echte oorzaak in vijftien minuten.

De oplossing is de nieuwe content indexeren én een van deze precies falende vragen aan je eval-set toevoegen, zodat een toekomstig gat als dit faalt in CI vóór het live gaat. Dat is de hele lus in het klein: een gebruikerssignaal, een trace-gestuurde diagnose, een content-fix en een permanente test zodat dezelfde soort fout niet kan terugkeren. Doe dit honderd keer en je systeem wordt echt betrouwbaar — niet omdat het model slimmer werd, maar omdat jouw operationele discipline dat werd.

Je LLMOps-stack: zelf bouwen of kopen

Je hoeft dit niet allemaal zelf te bouwen, en voor de meeste teams zou je dat ook niet moeten. Er is een gezonde markt van observability- en evaluatieplatforms die tracing, logging, dashboards en eval-tooling kant-en-klaar leveren. De eerlijke afweging: kopen brengt je in dagen op gang en geeft je een verzorgde UI; zelf bouwen geeft je controle en voorkomt dat je prompts en uitvoer (met de ingebedde gebruikersdata) naar wéér een derde partij stuurt.

Een pragmatische tussenweg werkt goed. Instrumenteer met de open standaard — de GenAI-conventies van OpenTelemetry — zodat je telemetrie overdraagbaar is, en kies dan een backend die je later kunt vervangen. Zo is de zelf-bouwen-of-kopen-keuze omkeerbaar in plaats van een lock-in waar je spijt van krijgt. Wat je ook kiest: bezit je eigen eval-set. Het is jouw institutionele kennis van wat "goed" betekent voor je product, en het hoort nooit alleen in de tool van een leverancier te leven.

Een pragmatische uitrol

Je hebt de volledige stack niet op dag één nodig, en alles tegelijk willen bouwen is precies hoe teams vastlopen. Fasering helpt. Begin met tracing en logging, want zichtbaarheid komt eerst en al het andere hangt ervan af. Voeg daarna kosten- en latency-dashboards toe, want die zijn goedkoop te bouwen en meteen nuttig. Bouw dan een kleine eval-set uit je echte missers en koppel die aan CI. Voeg vervolgens doorlopende evaluatie en drift-monitoring toe op een steekproef van het productieverkeer. Formaliseer als laatste alerting, on-call en runbooks. Elke stap is op zichzelf nuttig, en elke stap maakt de volgende makkelijker.

Nog één ding dat het waard is om helder te zeggen: hier begin je niet voor met een groot team of budget. De eerste versie kan een logging-middleware zijn, een spreadsheet met twintig testgevallen en een wekelijkse review van vijftien minuten op gemarkeerde gesprekken. Alleen dat al zet je voor op de meeste teams die hun LLM's blind draaien. Volwassenheid is een richting, geen poort — je verdient betrouwbaarheid door de lus elke maand strakker te maken, niet door een platform te kopen en te hopen.

De belangrijkste mentaliteitsverschuiving: behandel je LLM-feature als een levend systeem dat bediend moet worden, niet als een project dat je lanceert en vergeet. Het model verandert, je gebruikers veranderen, en je prompts stapelen zich op. LLMOps is simpelweg de discipline om in controle te blijven terwijl dat alles beweegt.

Bij Crux Digits helpen we teams precies deze discipline in te richten — bestaande LLM-features instrumenteren, evals en observability opzetten, en de fundamenten voor AI-implementatie en LLM-optimalisatie bouwen die productiesystemen betrouwbaar en kostenefficiënt houden. Bekijk onze transparante prijzen, of boek een gratis consult en we brengen samen je eerste monitoring-winst in kaart.

Veelgestelde vragen