Monitoring van AI-diensten: welke signalen doen er echt toe?
Een AI-dienst kan technisch volledig "up" zijn terwijl gebruikers trage, dure of inhoudelijk foute antwoorden krijgen. Welke signalen naast uptime — latency, kosten, drift, hallucinaties — je monitoring wél moet vangen.
Bij AI-diensten is het niet genoeg om te weten of de server bereikbaar is. De signalen die er echt toe doen zijn latency, foutpercentages, kosten per request, token-verbruik, rate-limit hits, beschikbaarheid van onderliggende modellen en providers, en signalen die iets zeggen over de inhoudelijke kwaliteit van antwoorden. Een AI-dienst kan technisch volledig "up" zijn terwijl gebruikers ondertussen trage, dure of inhoudelijk slechte antwoorden krijgen.
Goede monitoring kijkt daarom naar drie lagen tegelijk: technische beschikbaarheid, operationele prestaties en antwoordkwaliteit. Vooral die laatste laag maakt AI-monitoring anders dan klassieke applicatiemonitoring. Een HTTP 200-status zegt niets over de vraag of een model de juiste bron gebruikte, begon te hallucineren of plotseling systematisch andere antwoorden geeft.
Waarom alleen uptime niet genoeg is
Bij een traditionele webdienst is uptime vaak een redelijke eerste indicator. Als de applicatie reageert, de database bereikbaar is en foutpercentages laag blijven, functioneert het systeem meestal zoals verwacht.
Bij AI-diensten ligt dat anders. Een request kan technisch succesvol zijn, terwijl het antwoord onbruikbaar is. Een model kan bijvoorbeeld relevante RAG-context negeren, een bron verkeerd interpreteren of een antwoord produceren dat qua vorm correct lijkt maar inhoudelijk afwijkt van wat verwacht wordt.
Een dashboard waarop alleen "API online", CPU-belasting en geheugenverbruik staan, mist daardoor een belangrijk deel van de werkelijkheid. Monitoring moet niet alleen aantonen dat infrastructuur draait, maar ook dat de AI-dienst zich binnen verwachte grenzen gedraagt.
Latency: meet meer dan alleen gemiddelde responstijd
Latency is een van de meest zichtbare signalen voor gebruikers. Toch zegt een gemiddelde responstijd vaak te weinig. Een dienst kan gemiddeld snel zijn, terwijl een klein maar belangrijk deel van de requests uitzonderlijk traag wordt.
Daarom is het nuttig om responstijden als verdeling te volgen, bijvoorbeeld via percentielen. Daarnaast moet je onderscheid maken tussen verschillende onderdelen van de keten: tijd voor retrieval uit een vector- of zoekindex, wachttijd bij de modelprovider, tijd tot het eerste gegenereerde token, totale generatietijd, en uitvoeringstijd van tools of externe API's door een agent.
Voor streaming interfaces is vooral "time to first token" belangrijk. Een gebruiker ervaart een systeem dat snel begint te antwoorden vaak als responsiever dan een systeem dat pas na enkele seconden de volledige output retourneert.
Foutpercentages: technisch succes is niet hetzelfde als functioneel succes
HTTP-fouten, time-outs en mislukte tool calls moeten vanzelfsprekend worden gemonitord. Maar bij AI-systemen is een bredere definitie van fout nodig.
Denk bijvoorbeeld aan een agent die een tool niet kan aanroepen, een RAG-pipeline die geen relevante documenten vindt, een model dat output genereert die niet aan het vereiste JSON-schema voldoet, een workflow die meerdere retries nodig heeft, of een fallback-model dat onverwacht vaak wordt gebruikt.
Door fouten per component te registreren, wordt zichtbaar waar problemen werkelijk ontstaan. Eén totaalpercentage voor "failed requests" is meestal te grof.
Token-verbruik en kosten per request
Token-verbruik is zowel een technische als financiële metric. Meer tokens betekenen meestal meer verwerkingstijd, hogere kosten en soms ook een grotere kans dat irrelevante context wordt meegestuurd.
Monitor daarom niet alleen totale maandelijkse kosten, maar ook het verbruik per request, workflow, model of type taak. Een plotselinge stijging kan wijzen op een gewijzigde prompt, een retrieval-probleem of een agent die onnodig veel stappen uitvoert.
Bij agents is vooral de volledige keten belangrijk. Eén gebruikersvraag kan tientallen modelcalls, zoekacties en tool calls veroorzaken. Alleen de kosten van de laatste modelresponse meten geeft dan een vertekend beeld.
Rate limits en quota
Veel AI-diensten zijn afhankelijk van externe modelproviders en API's met limieten voor requests, tokens of gelijktijdige verwerking. Daarom zijn rate-limit hits een belangrijke operationele metric.
Een incidentele HTTP 429 hoeft geen probleem te zijn als retries en wachtrijen correct zijn ingericht. Een structurele stijging is wel relevant. Dat kan betekenen dat de belasting groeit, batching ontbreekt, een agent te agressief paralleliseert of de gebruikte capaciteit niet meer aansluit op het werkelijke verkeer.
Monitor ook retries en wachttijd na throttling. Anders blijft verborgen dat een systeem technisch succesvol reageert, maar steeds meer tijd kwijt is aan wachten.
Beschikbaarheid van providers en modellen
Als een AI-dienst afhankelijk is van een externe provider, is de beschikbaarheid van die provider onderdeel van je eigen operationele risico.
Het is daarom nuttig om providerfouten apart te onderscheiden van fouten in de eigen applicatie. Denk aan time-outs, overbelasting, authenticatieproblemen, verdwenen modelversies of wijzigingen in endpoints.
Bij systemen met meerdere modellen of providers moet bovendien zichtbaar zijn wanneer een fallback wordt gebruikt. Een fallback kan de beschikbaarheid verhogen, maar mogelijk ook andere latency, kosten of antwoordkwaliteit opleveren.
Drift in antwoordkwaliteit
Een van de lastigste vormen van degradatie is quality drift: het systeem blijft technisch werken, maar antwoorden veranderen geleidelijk of plotseling van kwaliteit.
Dat kan verschillende oorzaken hebben. Een provider kan een model aanpassen, de inhoud van een kennisbank kan veranderen, retrieval kan minder nauwkeurig worden of een nieuwe promptversie kan onverwachte effecten hebben.
Kwaliteit moet daarom periodiek worden gemeten aan de hand van representatieve testvragen. Vergelijk bijvoorbeeld of het juiste brondocument wordt gevonden, of verplichte informatie aanwezig is, of antwoorden overeenkomen met bekende referentie-antwoorden, of citaties daadwerkelijk de beweringen ondersteunen, en of de AI buiten toegestane onderwerpen antwoordt. Dat hoeft niet uitsluitend automatisch. Voor belangrijke workflows blijft handmatige steekproefcontrole waardevol.
Hallucinatie- en afwijkingsdetectie
Hallucinaties zijn moeilijk rechtstreeks als één metric te meten. In de praktijk werkt het beter om concrete afwijkingen te detecteren.
Bij een RAG-systeem kun je bijvoorbeeld controleren of feitelijke claims worden ondersteund door opgehaalde bronnen. Je kunt ook signaleren dat een antwoord citaties bevat naar documenten die niet zijn geraadpleegd, of dat het model antwoordt terwijl retrieval geen relevante context opleverde.
Bij agents zijn andere afwijkingen belangrijk: onverwachte tool calls, veel meer stappen dan normaal, herhaalde acties, afwijkende uitvoervolgorde of acties buiten vooraf gedefinieerde grenzen. Het doel is niet om één universele "hallucinatiescore" te creëren, maar om meetbare situaties vast te leggen waarin gedrag afwijkt van wat de toepassing hoort te doen.
Monitor de hele keten, niet alleen het model
Een productieprobleem zit lang niet altijd in het taalmodel. Een AI-dienst bestaat vaak uit meerdere onderdelen: authenticatie, applicatielogica, vector database, documentopslag, embeddings, modelprovider, externe tools en soms meerdere agents.
Voor een bruikbaar beeld moet een request daarom door de hele keten gevolgd kunnen worden. Met tracing kun je terugzien welke componenten zijn aangeroepen, hoeveel tijd iedere stap kostte en waar fouten ontstonden. Voor agents is dit nog belangrijker: zonder een audit trail is achteraf nauwelijks te reconstrueren waarom een agent een bepaalde actie uitvoerde.
Wanneer moet er een alert afgaan?
Niet iedere afwijking verdient onmiddellijk een melding. Te veel alerts leiden ertoe dat echte problemen minder opvallen.
Alerts zijn vooral nuttig bij signalen die directe actie kunnen vereisen: plotseling sterk stijgende latency, veel mislukte requests, structurele rate-limit hits, provideruitval, onverwachte kostenstijging of een duidelijke kwaliteitsafwijking.
Andere metrics zijn geschikter voor trendanalyse. Token-verbruik, retrievalkwaliteit of gemiddelde agentstappen kunnen bijvoorbeeld over dagen of weken worden gevolgd om geleidelijke veranderingen te herkennen. Goede AI-monitoring combineert realtime alerts met periodieke kwaliteitscontrole.
Veelgestelde vragen
Welke metrics zijn het belangrijkst voor een AI-dienst? Latency, foutpercentages, token-verbruik, kosten per request, rate-limit hits, providerbeschikbaarheid en signalen voor antwoordkwaliteit vormen samen de belangrijkste basis.
Hoe monitor je hallucinaties van een AI-model? Meestal indirect, door te controleren of claims door bronnen worden ondersteund, of citaties kloppen en of antwoorden binnen vooraf bepaalde kwaliteits- en gedragsregels blijven.
Waarom is gewone uptime-monitoring niet voldoende voor AI? Omdat een AI-dienst technisch beschikbaar kan zijn terwijl antwoorden inhoudelijk fout, traag, te duur of afwijkend zijn. AI-monitoring moet daarom ook gedrag en outputkwaliteit volgen.
Conclusie
De belangrijkste monitoringvraag bij een AI-dienst is niet alleen "draait het systeem?", maar ook "gedraagt het zich nog zoals bedoeld?" Daarom moeten infrastructuurmetrics worden gecombineerd met signalen over latency, fouten, tokens, kosten, rate limits, providerbeschikbaarheid en inhoudelijke kwaliteit. Vooral bij RAG-systemen en agents zijn tracing, broncontrole en afwijkingsdetectie noodzakelijk om problemen te zien die traditionele uptime-monitoring volledig mist.