Drift meten in productie: modelprestaties over tijd volgen

Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini)

Een taalmodel dat bij uitrol een nauwkeurigheid van 92% behaalt op een afgebakende validatieset, blijft die prestaties zelden oneindig vasthouden. Waar traditionele software deterministisch faalt met duidelijke foutcodes en stacktraces, degraderen generatieve AI-systemen geruisloos. Een API-wijziging bij een externe leverancier, een subtiele verschuiving in het taalgebruik van eindgebruikers, of een seizoensgebonden verandering in de aangeleverde context kan ertoe leiden dat antwoorden geleidelijk omslachtiger, minder feitelijk of structureel incorrect worden.

Dit artikel behandelt het kwantificeren en continu bewaken van modeldegradatie in productiesystemen. We bakenen deze analyse expliciet af van eenmalige kwaliteitsmetingen vóór de uitrol: hier staat niet de initiële geschiktheid centraal, maar de continue dynamiek tussen invoer, externe API-gedragingen en uitvoerkwaliteit over weken en maanden. Met een systematische meetopzet transformeer je vage gebruikersklachten over "de AI werkt sinds vorige week minder goed" naar harde statistische drempelwaarden en gerichte herstelacties.

De drie verschijningsvormen van drift bij LLM-systemen

Om prestatieverlies doeltreffend te isoleren, moeten we drie fundamenteel verschillende vormen van drift onderscheiden. Het mengen van deze categorieën leidt vaak tot verkeerde interventies, zoals het herschrijven van prompts wanneer het onderliggende probleem in de brondata zit.

Data drift ontstaat wanneer de verdeling van de invoer verandert ten opzichte van de initiële testfase. Denk aan een klantenservice-toepassing waar gebruikers na een productlancering plotseling vragen stellen over nieuwe functies die niet in de embedding-index zijn opgenomen. Het model zelf is niet veranderd, maar de representativiteit van de invoer wel.

Concept drift treedt op wanneer de statistische relatie tussen invoer en het correcte antwoord verschuift. Een juridische vraag over arbeidsrecht kan exact dezelfde bewoordingen behouden, maar door nieuwe wetgeving vereist het antwoord een andere redeneerlijn. Zelfs als de invoer identiek blijft, is de historische grondwaarheid niet langer geldig.

Model drift, specifiek voor LLM-applicaties die draaien op externe closed-source API's, ontstaat door wijzigingen aan de leverancierszijde. Externe aanbieders passen geregeld achterwaartse optimalisaties toe: routing naar kleinere gespecialiseerde submodellen, agressievere kwantisatie om rekenkracht te besparen, of aangescherpte veiligheidsfilters. Deze wijzigingen worden zelden aangekondigd onder een nieuw versienummer, maar hebben directe gevolgen voor parameters zoals JSON-volgzaamheid, antwoordlengte en determinisme.

Synthetische referentievraagstukken: de vaste ijklijn

De meest betrouwbare methode om zuivere model drift te isoleren van data drift, is het periodiek uitvoeren van een ongewijzigde, synthetische testset: de zogeheten golden probe suite. Omdat productiedata continu fluctueert, kan live monitoring nooit met zekerheid vaststellen of een dalende kwaliteitsscore wordt veroorzaakt door moeilijkere gebruikersvragen of door een degradatie in het model zelf.

Een golden probe suite bestaat uit een representatieve steekproef van minimaal 100 tot 250 gestandaardiseerde invoervragen waarvan de verwachte outputkenmerken vooraf exact zijn vastgelegd. Deze set wordt geautomatiseerd verzonden via een scheduled job (bijvoorbeeld elke vier uur) met identieke systeemparameters: vaste temperatuur (bij voorkeur temperature=0 voor maximale deterministische reproduceerbaarheid), identieke systeemprompt en vaste API-parameters.

import json
import statistics
from typing import List, Dict

def bereken_drift_statistieken(
    historische_scores: List[float], 
    huidige_batch_scores: List[float]
) -> Dict[str, float]:
    """
    Kwantificeert drift tussen een historische baseline en de actuele batch.
    Retourneert het absolute verschil in gemiddelde en de p-waarde indicatie.
    """
    gemiddelde_basis = statistics.mean(historische_scores)
    gemiddelde_actueel = statistics.mean(huidige_batch_scores)
    
    variantie_basis = statistics.variance(historische_scores)
    variantie_actueel = statistics.variance(huidige_batch_scores)
    
    delta = gemiddelde_actueel - gemiddelde_basis
    relatieve_verschuiving = (delta / gemiddelde_basis) * 100.0 if gemiddelde_basis != 0 else 0.0
    
    return {
        "gemiddelde_baseline": round(gemiddelde_basis, 4),
        "gemiddelde_actueel": round(gemiddelde_actueel, 4),
        "absolute_delta": round(delta, 4),
        "procentuele_afwijking": round(relatieve_verschuiving, 2),
        "variantie_ratio": round(variantie_actueel / variantie_basis, 4) if variantie_basis != 0 else 1.0
    }

Wanneer de prestaties op deze synthetische set plotseling dalen, is de diagnose eenduidig: de externe API vertoont model drift. Wie methodisch wil vergelijken of een gewijzigde modelversie of promptvariant bestand is tegen historische distributieverschuivingen, leest de handleiding over A/B-testen van prompts voor productie.

Semantische verschuivingen kwantificeren via embeddings

Om data drift in de live invoerstroom te meten zonder handmatige inspectie van duizenden interacties, maken we gebruik van vector-embeddings. Door elke inkomende gebruikersprompt te projecteren in een vectorruimte, ontstaat een meerdimensionale puntenwolk die het actuele toepassingsdomein representeert.

De kwantificering van data drift verloopt via twee wiskundige technieken:

• Centroid Distance: We berekenen het zwaartepunt (de gemiddelde vector $\mu_{\text{basis}}$) van een historische referentieperiode (bijvoorbeeld de eerste 10.000 gevalideerde interacties). Vervolgens berekenen we het zwaartepunt $\mu_{\text{actueel}}$ van een schuivend venster over de afgelopen 24 uur. De cosinusafstand tussen beide vectoren geeft een directe indicatie van macroscopische thematische verschuivingen.
• Maximum Mean Discrepancy (MMD) of Wasserstein Distance: Voor een fijnmazigere analyse toetsen we of de verdeling van afstanden tussen datapunten binnen de actuele batch significant afwijkt van de referentiebatch. Dit signaleert het ontstaan van nieuwe, geïsoleerde subclusters (zoals een nieuwe categorie foutmeldingen) die het algemene zwaartepunt nauwelijks beïnvloeden.

Om te voorkomen dat je referentietestset veroudert en de embedding-afstanden structureel gaan afwijken van de realiteit, beschrijft het stuk over productielogs omzetten naar evaluatiedata hoe je echte gebruikersvragen veilig filtert, anonimiseert en hergebruikt.

Proxy-metrieken en indirecte productiesignalen

Niet elke kwaliteitsverandering vereist een zware evaluatiestap met een extern keuringsmodel. In productieomgevingen leveren deterministische proxy-metrieken vaak de snelste en goedkoopste waarschuwingssignalen op. Deze indicatoren kosten vrijwel niets aan extra rekenkracht en detecteren acute anomalieën binnen enkele seconden.

De vier meest effectieve proxy-indicatoren zijn:

• JSON- en Schema-validiteit: Wanneer een model is geconfigureerd om gestructureerde data terug te geven, duidt elke stijging in parseerfouten of ontbrekende velden direct op een achteruitgang in instructievolgzaamheid.
• Token-lengte distributie (Input en Output): Een plotselinge toename in de gemiddelde uitvoerlengte wijst vaak op breedsprakigheid of herhalingslussen (repetitive loops). Een plotselinge daling duidt op vroegtijdige truncatie of ongewenste weigeringen ("Als AI-model kan ik hier niet...").
• Stop-sequence en Finish Reason distributie: De verhouding tussen finish_reason: "stop" en finish_reason: "length" moet stabiel blijven. Een toename in lengte-overschrijdingen signaleert dat het model vastloopt in redundante redeneerstappen.
• Downstream interactiesignalen: In klantensystemen zijn impliciete signalen waardevol: het aantal keren dat een gebruiker binnen 60 seconden een herformuleringsvraag stelt ("Nee, dat bedoel ik niet, ik vroeg..."), of een plotselinge daling in de doorklikratio op gegenereerde bronverwijzingen.

Omdat drift bij autonome AI-systemen niet alleen tekstkwaliteit raakt maar ook invloed heeft op gereedschapskeuze en redeneerlussen, behandelt het artikel over evaluatie van AI-agents hoe toolselectie, argumentvaliditeit en taakpaden over tijd worden gemonitord.

LLM-as-a-Judge over tijd: het ijkprobleem van de beoordelaar

Een gangbare praktijk voor continue kwaliteitsbewaking is het inzetten van een zwaarder taalmodel als geautomatiseerde beoordelaar (LLM-as-a-Judge). De beoordelaar krijgt de invoer, de gegenereerde uitvoer en een scoringsrubriek, en kent vervolgens een cijfer toe voor criteria zoals feitelijkheid, relevantie en toon.

Bij langdurige monitoring introduceert deze aanpak echter een gevaarlijke methodologische cirkelredenering: wie bewaakt de bewaker? Wanneer de leverancier van het beoordelende model een update doorvoert, kan de beoordelaar strenger, milder of bevooroordeeld raken ten aanzien van bepaalde zinsconstructies. Een geconstateerde prestatiedaling in het productiemodel kan in werkelijkheid een verschuiving in de beoordelingsschaal van het evaluatiemodel zijn.

Om deze meetonzekerheid te beheersen, moeten teams de volgende voorzorgsmaatregelen nemen:

1. Vaste ijkankers (Calibration Anchors): Voeg aan elke batch productie-evaluaties een vaste set van 20 historische antwoorden toe met een vooraf vastgestelde, menselijk gevalideerde score. Als de toegekende score op deze ijkankers afwijkt, is het evaluatiesysteem zélf gedrift en moeten de metingen over die periode worden gecorrigeerd.
2. Rubrieken met binaire criteria: Vermijd open schalen van 1 tot 10. Gebruik gedetailleerde checklists met binaire vragen ("Bevat het antwoord een bronvermelding? Ja/Nee", "Wordt de gevraagde datum genoemd? Ja/Nee"). Binaire criteria vertonen aanzienlijk minder subjectieve drift dan glijdende schalen.
3. Gedwongen redeneerstap vóór toekenning: Laat het beoordelende model eerst expliciet citeren welke passages uit de invoer en context het oordeel ondersteunen, voordat het eindoordeel wordt gegenereerd. Dit vermindert hallucinatieve variabiliteit in de beoordeling.

Statistische procesbeheersing en alerting-drempelwaarden

Een veelgemaakte fout bij drift-monitoring is het instellen van statische grenswaarden op daggemiddelden. Aangezien modelinteracties onderhevig zijn aan natuurlijke statistische ruis, leidt een harde ondergrens (zoals "alert wanneer de gemiddelde score onder 4.2 daalt") onvermijdelijk tot valse alarmen op dagen met een lager volume of complexere gebruikerscases.

In plaats van statische drempels passen we statistische procesbeheersing (Statistical Process Control, SPC) toe, zoals CUSUM (Cumulative Sum Control Chart) of EWMA (Exponentially Weighted Moving Average). Deze methoden detecteren kleine, aanhoudende verschuivingen in het gemiddelde veel sneller dan standaard control charts, terwijl ze ongevoelig blijven voor incidentele uitschieters.

Bij het configureren van alerts geldt de regel: stuur nooit een notificatie op basis van een enkel datapunt. Een betrouwbare alerting-regel vereist dat een statistische afwijking ($p < 0.01$ of $\text{PSI} > 0.25$) gedurende ten minste drie opeenvolgende tijdvensters aanhoudt. Hoe je dergelijke regressietests structureel inricht voordat een modelversie live gaat, wordt gedetailleerd in het overzicht over evaluaties in de deployment-pijplijn.

Valkuilen in de Nederlandstalige context

Bij het monitoren van Nederlandstalige productieomgevingen treden specifieke fenomenen op die in Engelstalige literatuur over model drift over het hoofd worden gezien. Een model dat uitstekend presteert in het Engels kan bij subtiele backend-updates onevenredig veel kwaliteit verliezen op Nederlandse taalconstructies.

De belangrijkste aandachtspunten voor Nederlandse systemen zijn:

• Samenstellingen en spatiefouten: Nederlandstalige samenstellingen (zoals kwaliteitscontrolesysteem) worden door taalmodellen regelmatig opgesplitst (kwaliteit controle systeem). Bij model drift door zwaardere kwantisatie neemt deze neiging tot onjuist spatiegebruik (de zogenaamde Engelse ziekte) vaak als eerste toe, wat direct invloed heeft op de professionele perceptie van de output.
• Aanspreekvorm-inconsistentie (u vs. je): Een veelvoorkomend gevolg van externe provider-updates is het verloop in stijlvastheid. Waar een model voorheen consequent de formele beleefdheidsvorm hanteerde, kan na een update binnen één antwoord een willekeurige mix van "u", "uw", "je" en "jouw" ontstaan.
• Regionale terminologie en wetgeving: Vragen uit Vlaanderen versus Nederland hanteren vaak verschillende vaktermen (bijvoorbeeld omgevingsvergunning versus stedenbouwkundige vergunning). Wanneer het aandeel Belgische gebruikers toeneemt, kan de retrieval-kwaliteit dalen zonder dat de algehele systeemarchitectuur is gewijzigd.

Operationele interventies bij geconstateerde drift

Het meten van drift heeft uitsluitend waarde wanneer er een vooraf gedefinieerd escalatieprotocol klaarligt. Zodra de monitoringsystemen een statistisch significante degradatie signaleren, moeten geautomatiseerde of procesmatige maatregelen in werking treden.

Afhankelijk van de gediagnosticeerde oorzaak worden de volgende interventielagen geactiveerd:

1. Provider-level Fallback (bij acute model drift): Schakel via de API-gateway direct over naar een geverifieerd fallback-model of een eerdere, gepinde model-snapshot (bijvoorbeeld van gpt-4o naar een specifieke checkpoint-datum). Dit herstelt de basisfunctionaliteit terwijl het engineeringteam de afwijking onderzoekt.
2. Dynamische Retrieval-aanpassing (bij data drift): Wanneer de invoerdata nieuwe entiteiten vertoont die niet goed worden beantwoord, pas je de semantische similarity-drempelwaarde van de vectorindex aan of forceer je een herindexering van actuele documentatiebronnen.
3. Prompt-herkalibratie: Blijkt uit de foutanalyse dat het model na een provider-update de neiging heeft specifieke constraints te negeren (zoals het verplichte JSON-schema), dan worden gerichte few-shot voorbeelden aan de systeemprompt toegevoegd om de geobserveerde regressie te compenseren.

Voor organisaties die duidelijke verantwoordelijkheden willen beleggen voor monitoring, escalatie en incidentrespons, biedt het overzicht over beheer na go-live en eigenaarschap van AI-applicaties praktische handvatten om rollen tussen engineering en productteams scherp te verdelen.