LLM observability: zo bouw je een productie-ready monitoring stack

Executive Summary / Direct Antwoord: LLM-systemen in productie zijn een blinde vlek voor de meeste teams. Zonder observability zie je pas dat kosten exploderen op de maandrekening, en kwaliteitsproblemen pas als klanten klagen. Dit artikel geeft je een concrete implementatiegids voor traces, evaluaties en cost attribution, inclusief code en toolkeuzes, zodat je morgen al visibility hebt.

Waarom standaard monitoring tekortschiet voor LLM-systemen

Traditionele APM-tools meten HTTP-statuscodes en latency. Voor deterministische applicaties is dat voldoende: dezelfde input levert altijd dezelfde output, en een fout is een fout. Maar LLM-systemen breken deze aanname fundamenteel. Een klantenservicebot die twee identieke vragen op verschillende dagen verwerkt, kan bij de eerste 800 tokens verbruiken en bij de tweede 3.200 tokens, afhankelijk van hoe de context-window is samengesteld, welke documenten het retrieval-systeem ophaalde, of er een nieuwe modelversie actief is.

Dit schept een observability-kloof die op twee niveaus pijn doet. Op infrastructuurniveau kun je prima zien dat een request 2,4 seconden duurde. Maar op semantisch niveau, waar het werkelijk om gaat, heb je nul zicht: was het antwoord feitelijk correct? Halluceerde het model? Is de kwaliteit de laatste twee weken stilletjes gedegradeerd zonder dat iemand het merkte?

De tweede dimensie is kostenbeheersing. LLM-API-prijzen zijn token-afhankelijk, wat betekent dat een slecht geconfigureerde agent-loop of een te groot contextvenster je nachtbudget kan verdubbelen. Zonder visibility per request weet je pas aan het einde van de maand wat er misging. Zoals eerder beschreven in de architectuur van production-ready AI agents, is observability geen optioneel laagje maar een structurele bouwsteen.

De oplossing rust op drie pijlers die samen de volledige lifecycle van een LLM-request dekken.

Wat zijn de drie pijlers van LLM observability?

De drie pijlers zijn structurele tracing, output-evaluatie en cost attribution. Ze zijn onderling afhankelijk: tracing vertelt je wat er gebeurde, evaluatie beoordeelt of dat acceptabel was, en cost attribution koppelt elk verzoek aan een kostenverantwoordelijke entiteit.

Pijler 1: Structurele tracing en request-reconstructie

Een trace is de complete levensloop van één LLM-request, opgedeeld in hiërarchische spans. De root span omvat het hele verzoek. Kindspans dekken afzonderlijke stappen: het samenstellen van de prompt, het ophalen van documenten via retrieval, de daadwerkelijke model-inferentie, en eventuele tool-calls van een agent.

Elke span heeft inputs, outputs, een statussignaal en duur. Die hiërarchie is de sleutel: wanneer een request mislukt of traag is, kun je exact zien in welke span het misging. Is de retrieval-latency normaal maar de inferentie-latency driemaal zo hoog? Dan is de LLM-provider langzaam, niet je vector-database. Is de retrieval-latency gesprongen? Dan moet je je vector-database onderzoeken. Zonder spans vlieg je blind.

Belangrijker nog: spans geven je de reproduceerbaarheid die LLM-debugging vereist. Je kunt de exacte prompt reconstrueren die het model ontving, de documentfragmenten die werden meegegeven, de temperatuurinstelling, en de ruwe output. Dat maakt het verschil tussen een uur debuggen en een week puzzelen.

Pijler 2: Output-evaluatie en kwaliteitsscoring

Tracing vertelt je dat een request plaatsvond. Evaluatie beoordeelt of het resultaat klopte. Die beoordeling kan op drie niveaus plaatsvinden.

Deterministische evaluatoren passen regelgebaseerde checks toe: bevat de output een e-mailadres (PII-lek)? Is de response-lengte meer dan drie keer de verwachte lengte (duidt op runaway output)? Staat er een verboden woord in? Deze checks zijn razendsnel en spotgoedkoop.

Statistische evaluatoren vergelijken outputs met referentie-antwoorden via metrics als exacte overeenkomst of semantische gelijkenis. Ze zijn nuttig voor Q&A-systemen met bekende antwoorden.

Model-gebaseerde evaluatoren, ook wel LLM-as-a-judge, gebruiken een kleiner en goedkoper model om de output van het hoofdmodel te beoordelen. Ze stellen vragen als: klopt dit antwoord feitelijk met de aangeboden context? Beantwoordt de response alle delen van de vraag? Deze methode is de krachtigste voor semantische kwaliteitsbewaking, maar heeft een eigen kostprijs.

"Traditioneel testen faalt bij AI: niet-deterministische outputs maken exacte reproduceerbaarheid onmogelijk. Evaluatie in productie, op een sample van live traffic, is de enige manier om kwaliteitsdrift vroegtijdig te signaleren."

De slimme aanpak: sample strategisch. Evalueer elke response van een nieuwe gebruiker gedurende de eerste tien verzoeken volledig, daarna tien procent. Zo behoud je vroegtijdige signaaldetectie zonder je evaluatiekosten te laten exploderen.

Pijler 3: Cost attribution en budget-governance

De derde pijler transformeert een nutteloos totaalcijfer, namelijk "we hebben deze maand vijftigduizend euro uitgegeven aan LLM-inference", naar operationeel inzicht: welke feature, welke gebruiker of welk workflow dreef die kosten?

Het technische patroon is rechttoe-rechtaan: voeg metadata toe aan elk API-verzoek (gebruikers-ID, feature-naam, workspace-ID), bereken de kosten per request op het moment van de call, en aggregeer in je observability-backend. Met dit inzicht kun je kostencontroles inbouwen: per-gebruikersbudgetten met soft alerts bij 75% en een hard limit bij 100%, automatisch routeren naar goedkopere modellen wanneer een gebruiker zijn budget nadert, en feature-level kosten vergelijken om inefficiënties te spotten.

Architectuurkeuze: gateway of instrumentatie?

Voordat je begint met implementeren, moet je één fundamentele architectuurkeuze maken. Die keuze bepaalt welke tools je integreert, hoeveel code je aanpast, en waar je observability-logica draait.

De gateway-aanpak

In het gateway-patroon stromen alle LLM-API-calls door een centrale proxy die tussen jouw applicatie en de LLM-provider zit. Die proxy onderschept elk verzoek en elke response, verrijkt ze met applicatiecontext (gebruikers-ID, feature-naam), en stuurt de data door naar je observability-backend. Tegelijkertijd handhaaft de gateway beleidsregels: budgetlimieten, rate-limits, guardrails en request-routing.

Het voordeel is dekking: elk LLM-verzoek wordt automatisch gecaptured, ongeacht uit welk code-pad het komt. Je bereikt cost attribution op request-niveau zonder applicatiecode aan te passen. Tools als Portkey en Helicone implementeren dit patroon.

Het nadeel is context-armoe: een gateway weet dat een verzoek 20.000 tokens gebruikte, maar niet dat die tokens afkomstig waren van slecht gecachunkte retrieval-resultaten.

De instrumentatie-aanpak

Bij instrumentatie instrumenteer je je applicatiecode expliciet met een observability-SDK. Je wikkelt LLM-calls in context managers of decorators die gestructureerde telemetrie uitsturen. Omdat de instrumentatie in je applicatie leeft, heeft ze toegang tot alle beschikbare context: sessiestatus, eerder ophaalresultaten, feature flags, A/B-testcohorten.

Het nadeel is volledigheid: als een ontwikkelaar vergeet instrumentatie toe te voegen, is die aanroep onzichtbaar. Tools als Langfuse, Phoenix (Arize) en W&B Weave implementeren dit patroon en zijn populair bij Nederlandse dev-teams.

De hybride aanpak: gateway plus instrumentatie

De meeste productieteams combineren beide. De gateway levert een basislaag van kost- en latency-visibility. Instrumentatie voegt semantische rijkdom toe: retrieval-details, tool call-sequenties, evaluatieresultaten. De koppeling werkt via een gedeeld trace_id: je observability-backend stitcht gateway-data en applicatietrace automatisch samen tot één coherent request-beeld.

Welke toolstack kies je in 2026?

De keuze voor je observability-fundament bepaalt de flexibiliteit op lange termijn. Hieronder een overzicht van de meest gebruikte opties in 2026:

Voor teams die vendor-onafhankelijkheid belangrijk vinden, is de aanbevolen aanpak voor 2026: begin met OpenTelemetry voor instrumentatie, Jaeger voor trace-opslag, en Langfuse als LLM-specifieke laag voor evaluaties en cost-dashboards. Zo bouw je met open standaarden en kun je later migreren naar een beheerd platform zonder je instrumentatielaag opnieuw te schrijven.

Hoe implementeer je traces stap voor stap?

Nadat je je toolstack hebt gekozen, is de eerste implementatiestap het wrappen van elke LLM-aanroep in een hiërarchisch span-patroon. Het basisprincipe: de root span omvat de hele operatie, kindspans dekken retrieval, prompt-assembly en model-inferentie afzonderlijk.

Bij elke span voeg je gestandaardiseerde metadata toe. Zorg dat deze attributen altijd aanwezig zijn:

Request-metadata: trace_id, user_id, feature_name, environment, request_timestamp.

Model-metadata: model_name, model_version, inference_provider, temperature.

Token-metadata: input_tokens, output_tokens, cache_read_tokens, total_tokens.

Kosten-metadata: cost_usd per request, uitgesplitst naar component (retrieval-kosten, inferentie-kosten).

Kwaliteits-metadata: hallucination_detected, toxicity_score, answer_relevance, task_completion.

Deze schema-discipline lijkt overdreven totdat je een productie-incident hebt. Op dat moment kun je in je observability-backend precies filteren op de gebruiker, het model en het tijdsvenster in kwestie, en de exacte trace terugvinden die het probleem veroorzaakte.

Bij frameworks als LangChain of LlamaIndex gaat instrumentatie vaak eenvoudiger via automatische integraties. Langfuse biedt bijvoorbeeld een @observe-decorator die je rond een functie plaatst; alle LLM-calls daarbinnen worden automatisch getraced met inputs, outputs en token-gebruik.

Hoe stel je real-time evaluatie in zonder de kosten te laten exploderen?

Evaluatie in productie is waardevol, maar heeft een kostprijs: je gebruikt een tweede model om het eerste te beoordelen. De sleutel is strategische sampling.

Begin met deterministiche checks die gratis draaien: is er PII in de output? Is de response-lengte abnormaal? Is de JSON valide? Deze checks kun je synchroon uitvoeren voor elke response, zonder extra API-kosten.

Voor semantische evaluatie, zoals hallucinatie-detectie of relevance-scoring, gebruik je een kleiner en goedkoper model als judge. Stel de sample-rate in op tien procent van het live verkeer voor bestaande gebruikers, en honderd procent voor de eerste tien requests van nieuwe gebruikers. Dit patroon geeft je vroegtijdig signaal bij nieuwe gebruikerspatronen en houdt evaluatiekosten beheersbaar.

De resultaten van evaluaties sla je op als attributen bij de trace-span. Zo kun je kwaliteitsmetrics over tijd plotten en direct een alert insturen als de hallucinatie-rate de vijf procent overschrijdt. In de context van enterprise AI ROI is dit precies het type meetbare kwaliteitsgrens die het verschil maakt tussen een experiment en een productieklaar systeem.

Kostenbesparing realiseren via observability-data

Observability biedt je drie directe hefbomen om LLM-kosten te verlagen. Samen realiseren ze een kostenreductie van 70 tot 85 procent ten opzichte van een niet-geoptimaliseerde baseline.

De eerste hefboom is context-compactie. Lange gespreksgeschiedenissen bevatten veel redundante tokens. Door context te samenvatten of te comprimeren voordat je een nieuw verzoek stuurt, bespaar je op elke volgende API-call. Met trace-data zie je exact hoeveel input-tokens elke aanroep verbruikt en kun je de besparing van compactie direct meten.

De tweede hefboom is model-routing. Niet elk verzoek vereist het krachtigste en duurste model. Eenvoudige classificatietaken of FAQ-beantwoording presteren prima op kleinere modellen. Met observability zie je per request de complexiteit, het tokengebruik en de kwaliteitsscore, wat je in staat stelt automatische routing-regels te implementeren: routeer naar een goedkoper model als de complexiteitsscore onder een drempelwaarde valt.

De derde hefboom is provider-level caching. Anthropic's cache-feature verdiscontteert gecachte tokens met 90 procent. Als je dezelfde system-prompt tweehonderd keer per sessie verstuurt, omdat je een agent-loop hebt, betaal je voor de eerste aanroep de volle prijs en voor de overige 199 aanroepen slechts tien procent. Op Claude Opus kost een gecachte system-prompt van 2.000 tokens dan 0,50 euro in plaats van 5 euro. Zonder observability-data weet je niet eens of je caching correct hebt geconfigureerd.

"Een team dat een AI-gestuurde takenlijst bouwde, ontdekte via cost-tracing dat de meeste taken minder dan 1 euro kostten, maar een handvol onderzoekstaken 11 euro. Door elke taak een eigen budget van 1-2 euro te geven en complexe onderzoekstaken op te splitsen, daalden de gemiddelde kosten met meer dan 80 procent."

Hoe stel je alerting en dashboards in voor productie?

De waarde van observability-infrastructuur wordt pas volledig benut wanneer de data actieverbaar is via dashboards en alerts. Een productie-LLM-stack heeft drie dashboardlagen nodig.

Het executive dashboard toont totale LLM-uitgaven per dag, week en maand, de top-10 duurste features of gebruikers, en een kosten-trendlijn met afwijkingsalert wanneer de dagelijkse uitgave 150 procent van het gemiddelde overschrijdt.

Het operations-dashboard toont latency-percentielen (P50, P95, P99) per model en feature, foutpercentages per model, beschikbaarheid van externe services en cache-hitpercentages. Een dalend cache-hitpercentage signaleert toenemende diversiteit in queries en is een vroeg waarschuwingssignaal voor hogere kosten.

Het kwaliteitsdashboard toont hallucinatie-rate, toxicity-score distributie, task-completion percentage voor agents, en respons-lengte distributie. Pieken in respons-lengte duiden op truncatieproblemen of runaway agent-loops.

Concreet alertingbeleid voor een productie-LLM-stack:

• Kostpiek-alert: dagelijkse kosten overstijgen 150% van het 14-daags gemiddelde, actie: notificatie aan on-call engineer.
• Hallucinatie-alert: hallucinatie-detectie overschrijdt 5%, actie: page + automatisch feature uitschakelen.
• Latency-alert: P99 latency overschrijdt 120% van de baseline, actie: dashboardhighlight, onderzoek vector-database.
• Model-foutrate: foutpercentage voor een specifiek model overschrijdt 1%, actie: automatisch failover naar fallback-model.
• Budget-limiet: gebruiker bereikt 100% van maandbudget, actie: verzoeken weigeren met duidelijke foutmelding.

Wat zijn de EU AI Act-verplichtingen voor observability?

De deadline van 2 augustus 2026 maakt observability niet alleen een technische keuze maar een juridische verplichting voor hoge-risico AI-systemen. De EU AI Act (verordening 2024/1689) schrijft voor dat dit type systeem continu gemonitord wordt op drift, bias en prestatiedegradatie, en dat logs voldoende detail bevatten voor reproduceerbaarheid en auditonderzoek.

Concreet betekent dit vier verplichtingen die rechtstreeks aansluiten op observability-infrastructuur. Ten eerste: continue monitoring met real-time alerts voor bias en kwaliteitsdrift, precies wat je kwaliteitsdashboard levert. Ten tweede: audit trails van inputs, outputs en beslissingen, exact wat structurele traces produceren. Ten derde: gedocumenteerde testprocedures, waarbij evaluatiepipelines en hun resultaten als bewijs dienen. Ten vierde: menselijk toezicht voor hoge-impact beslissingen, waarvoor observability sampling en review-workflows mogelijk maakt.

Toezicht in Nederland loopt via de Autoriteit Persoonsgegevens (AP) als nationale AI-autoriteit. Non-compliance riskeert boetes tot 35 miljoen euro of 7 procent van de wereldwijde omzet. Voor teams die meer willen begrijpen over de bredere governance-implicaties, biedt AI governance en strategische business impact een toegankelijk overzicht.

De observability-stack die je voor productiekwaliteit en kostenbeheersing bouwt, is dus tegelijkertijd je compliance-infrastructuur. Dat maakt de investering dubbel gerechtvaardigd.

Veelgestelde vragen (FAQ)

Wat is het verschil tussen LLM monitoring en LLM observability?

Monitoring detecteert bekende fouten via vooraf gedefinieerde drempels, zoals: is de API bereikbaar? Observability gaat verder: het geeft je de tools om ook onbekende problemen te onderzoeken door de interne toestand van een systeem te reconstrueren via traces, metrics en evaluaties.

Welke metrics zijn het meest kritiek om te tracken in een LLM-productieomgeving?

De vijf kernmetrics zijn: latency per component (P50/P95), tokengebruik en kosten per request, hallucinatie-rate, task-completion percentage (voor agents), en cache-hitpercentage. Begin met deze vijf voordat je uitbreidt.

Is Langfuse geschikt voor Nederlandse MKB-teams met beperkte infra-capaciteit?

Ja. Langfuse heeft een cloud-hosted optie met gratis tier, een simpele SDK-integratie en ingebouwde dashboards voor kosten en kwaliteit. Setup duurt minder dan een uur en vereist geen eigen backend-infrastructuur. Dat maakt het de meest toegankelijke instap voor kleinere teams.

Hoe hoog zijn de extra kosten voor LLM-as-a-judge evaluatie?

Bij een sample-rate van 10% en gebruik van een compact judge-model (Claude Haiku of GPT-4o-mini) voeg je gemiddeld 2-5% toe aan je totale inferentiekosten. Die overhead wordt typisch ruimschoots terugverdiend via de kostenoptimalisaties die evaluatiedata mogelijk maakt.

Welke observability-verplichting geldt er per augustus 2026 onder de EU AI Act?

Voor hoge-risico AI-systemen verplicht de EU AI Act continue prestatiemonitoring, log-bewaring voor audit-reproduceerbaarheid en gedocumenteerde testprocedures. Basis-observability-infrastructuur, bestaande uit traces, evaluaties en dashboards, voldoet aan de kern van deze vereisten mits je logs voldoende detail bevatten voor incident-reconstructie.

Conclusie: observability is geen luxe, het is de fundering

LLM-systemen in productie zonder observability zijn als autorijden met blinddoek. Je weet pas dat er iets mis is wanneer je ergens tegenaan rijdt. De drie pijlers die in dit artikel zijn uitgewerkt, namelijk structurele tracing, output-evaluatie en cost attribution, geven je de stuurinformatie die je nodig hebt om zowel kwaliteit als kosten proactief te beheren.

De investering is kleiner dan je denkt: een basale observability-stack met Langfuse of OpenTelemetry is in één tot twee werkdagen operationeel. De terugverdientijd via kostenoptimalisatie, gereduceerde incident-responstijd en compliance-gereedheid voor de EU AI Act ligt typisch ruim onder de eerste maand. Teams die nu observability-infrastructuur bouwen, bereiken een structureel voordeel ten opzichte van teams die blind varen, lagere LLM-kosten door visibility-gedreven optimalisatie, hogere kwaliteit door real-time evaluatie, en een verdedigbare governance-positie richting toezichthouders.

De vraag is niet of je observability nodig hebt. De vraag is hoe lang je het je kunt veroorloven om het niet te hebben.