Modeldrift is een structurele eigenschap van LLM's

Je moet modeldrift als een structurele eigenschap van frontier-modellen inrichten, niet als incidentiële storing. Dit betekent dat je governance verankert in continue benchmarking, gedragscontracten met updatedrempels, en verificatie op werkstroomniveau die per zaak vastlegt welke modelversie welk antwoord gaf.

De aanleiding is recente academische analyse van 18 september 2026 van stille updates aan taalmodellen die applicatiegedrag breken, die aantoont dat nauwkeurigheid, weigerpatronen en uitvoerformaten veranderen zonder dat de opdracht wijzigt. De onderzoekers stellen een governance-patroon voor met risicogebonden benchmarksuites en gedragscontracten. In onze inschatting is dat de belangrijkste verschuiving: drift wordt een meetbaar, contracteerbaar risico in plaats van een onverklaarbare hapering.

Welke vormen van drift moet je onderscheiden?

Uit de bronnen komt naar voren dat modeldrift geen enkel verschijnsel is, maar minstens vier onderscheiden vormen kent. Elke vorm vraagt om een ander controlepunt.

• Response-drift — dezelfde prompt levert op verschillende momenten verschillende antwoorden op, zonder dat het model of de prompt is gewijzigd.
• Context-drift — modelgedrag verandert afhankelijk van de volgorde of inhoud van eerdere berichten in dezelfde sessie.
• Non-deterministische drift — sampling- en serving-infrastructuur veroorzaken variatie tussen identieke runs, zelfs met temperatuur nul.
• Update-drift — stille updates aan het onderliggende model breken gedrag op applicatieniveau, zonder dat je dat ziet aankomen.

Waarom eenmalige tests onvoldoende zijn

Veel professionals gaan ervan uit dat een vaste prompt met temperatuur nul een reproduceerbaar antwoord oplevert. Dit klopt niet. Sampling- en serving-infrastructuur veroorzaken variatie tussen identieke runs. Een eenmalige benchmark meet dus maar één toevallige uitkomst, niet de spreiding.

De consequentie is dat governance niet kan steunen op periodieke, losstaande tests. Wie wil weten hoe een model zich gedraagt, moet herhaald en continu meten. Dat sluit aan bij de bredere gedachte dat multi-model verificatie zonder schijnzekerheid inrichten meer waarde biedt dan blind vertrouwen op één modeluitkomst.

Hoe manifesteert drift zich in langdurige werkstromen?

Prestaties dalen en het aantal meltdowns stijgt naarmate taken langer en complexer worden, juist bij frontier-modellen. Dit is direct relevant voor de beroepspraktijk. Juridische reviews, financiële analyses en compliance-controles zijn lange, meerstaps processen. Daarin uit drift zich als overgeslagen stappen, inconsistent redeneren of plotseling falen na een reeks correcte handelingen. Korte-taakscores zijn daar structureel blind voor.

Wie een fout wil kunnen herleiden, moet kunnen achterhalen waar in de keten het misging. Dit is precies waarom een fout AI-antwoord traceerbaar maken per werkstroom onderdeel van governance wordt. Je hebt dus niet alleen nodig dat het antwoord juist is, maar ook dat je kunt bewijzen welk model het gaf, wanneer, en onder welke omstandigheden.

Welke concrete controlepunten moet je instellen?

1. Documenteer per werkstroom welk model en welke versie wordt gebruikt — vastleggen welke modelversie welk antwoord gaf, zodat je drift later kunt traceren.
2. Stel benchmarksuites in die langdurige taken simuleren — test niet alleen korte prompts, maar ook meerstaps processen die typisch voor je werk zijn.
3. Definieer acceptabele drift-drempels in contracten met leveranciers — leg vast welke mate van verandering je accepteert en welke meldplichten gelden bij updates.
4. Meet continu, niet periodiek — zet monitoring in die herhaald dezelfde tests uitvoert, zodat je spreiding en trends ziet.
5. Traceer updates en hun gevolgen — wanneer een model wordt bijgewerkt, test je eerst of dit je werkstromen breekt voordat je het in productie neemt.

Hoe breng je dit in de praktijk?

De rode draad in het recente onderzoek is nuchter: modellen veranderen ook wanneer de opdracht gelijk blijft. Governance die uitgaat van statisch modelgedrag loopt daarom achter de feiten aan. De verschuiving die deze bronnen mogelijk maken, is dat drift meetbaar en contracteerbaar is geworden — en daarmee bestuurbaar.

Wat tooling kan doen, is meten en trends zichtbaar maken. Wat je zelf moet bepalen, is welke drift je accepteert, hoe je die in contracten vastlegt, en hoe je je werkstromen inricht zodat fouten traceerbaar zijn. Geen tool kan voor je beslissen welke nauwkeurigheid je werk vereist of welke risico's je bereid bent te nemen.