Model drift bij Codex en GPT in 2026: waarom modelversies binnen dezelfde naam veranderen

Je kunt niet op de modelnaam alleen vertrouwen. Wanneer een model onder dezelfde naam stille wijzigingen ondergaat, moet je via eigen metingen vaststellen of het gedrag en de prestaties voor jouw workflow onveranderd blijven. Zonder die metingen kan drift onopgemerkt doorwerken in beslissingen, uitleg en compliance.

De aanleiding is een analyse van 4 september 2026 van stille wijzigingen in Codex-agents en contextvensters in juli 2026, die aantoont dat modelnamen niet langer een betrouwbare indicator zijn voor modelgedrag. In juli 2026 documenteerden meerdere bronnen dat OpenAI's Codex-lijn en GPT-versies substantiële veranderingen ondergingen zonder dat de naam wijzigde: contextvensters werden verkleind, reasoning-experimenten aangepast en agentgedrag hersteld. Een concreet voorbeeld: het effectieve contextvenster van GPT-5.6 Sol Codex daalde van ongeveer 353.000 naar ongeveer 258.000 tokens zonder prominente aankondiging. In onze inschatting betekent dit voor wie met gevoelige of hoog-trust informatie werkt dat je niet langer kunt aannemen dat dezelfde modelnaam dezelfde prestaties garandeert. Drift is niet één fenomeen, maar meerdere lagen die elk apart gemeten moeten worden.

Welke soorten drift moet je onderscheiden?

Drift manifesteert zich op verschillende niveaus. Prestatie-drift is het meest zichtbaar: een model levert lagere scores, meer fouten of minder relevante output. Maar er is ook interpretatie-drift, waarbij een model dezelfde uitkomsten geeft, maar op basis van andere interne logica en andere redeneringen. Voor werk waarin uitleg en verantwoording tellen—juridische analyses, compliance-beoordelingen, incidentreconstructies—is dat onderscheid cruciaal. Een peer-reviewde studie uit maart 2026 toont aan dat modellen onder bepaalde omstandigheden hun interne redeneringsprofiel substantieel kunnen verschuiven terwijl hun F1-score en voorspellende prestaties grotendeels stabiel blijven. Dat betekent dat een prestatiegrafiek die vlak blijft geen garantie is dat het model hetzelfde blijft redeneren.

Een praktisch raamwerk onderscheidt vier soorten drift:

• Quality drift — de nauwkeurigheid van de output per taaktype daalt of stijgt.
• Coverage drift — het model geeft vaker "geen antwoord" of weigert bepaalde soorten input.
• Judge drift — de evaluatiecriteria of de manier waarop het model zichzelf beoordeelt verschuift.
• Production drift — de omgeving, configuratie of infrastructuur verandert op een manier die het gedrag beïnvloedt.

Elk type vereist andere metingen. Zonder die onderscheiding weet je niet wat je meet en kun je niet bepalen of een verandering in jouw workflow door het model, de evaluator of de productieomgeving komt.

Hoe meet je drift per workflow?

Drift is alleen zichtbaar via eigen metingen. Je hebt drie dingen nodig: een golden dataset per workflow, regressietests en een log van welke modelversie en configuratie actief waren op welk moment. De golden dataset is een kleine verzameling representatieve inputs met bekende, gewenste outputs. Die test je regelmatig tegen het model dat je in productie hebt. Als de scores afwijken van je baseline, weet je dat er iets veranderd is.

Regressietests zijn herhaalde runs van dezelfde inputs onder dezelfde omstandigheden. Je draait ze op vaste momenten—bijvoorbeeld wekelijks—en vergelijkt de resultaten met vorige runs. Dat helpt je om te zien of de verandering geleidelijk is of plotseling, en of die verandering naar boven of beneden gaat. Het loggen van modelversie en configuratie is essentieel: je moet later kunnen reconstrueren welke versie op welk moment actief was, zodat je drift aan een specifieke update kunt koppelen.

De concrete controles die je moet kunnen aantonen zijn:

1. Definieer een golden dataset per workflow — verzamel representatieve inputs met bekende outputs voordat je het model in productie zet.
2. Voer wekelijkse regressietests uit — run dezelfde inputs tegen het huidige model en vergelijk de scores met je baseline.
3. Log modelversie, configuratie en timestamp — documenteer welke versie op welk moment actief was, zodat je drift aan updates kunt koppelen.
4. Stel alertdrempels in — bepaal vooraf welke afwijking van je baseline onacceptabel is en trigger een handmatige review als die drempel wordt overschreden.
5. Onderzoek onenigheden tussen modellen — als je meerdere modellen als verificatiesignaal gebruikt, documenteer waarom ze het oneens zijn en of dat drift aangeeft.

Waarom is drift in high-trust workflows een risico?

Voor lange juridische dossiers, compliance-analyses of incidentreconstructies raakt drift direct de betrouwbaarheid. Een kleiner contextvenster kan betekenen dat een deel van een lang dossier buiten beeld valt en dus niet in de analyse meegenomen wordt. Een verschoven reasoning-profiel kan andere fouten opleveren dan de week ervoor, wat betekent dat je niet kunt vertrouwen op consistentie. Het risico zit niet in de verandering zelf, maar in het feit dat die verandering onopgemerkt blijft. Zonder eigen metingen kan drift weken of maanden doorwerken voordat je het merkt.

Dat is waarom verificatielagen praktisch bruikbaar zijn. Een verificatielaag kan een taak door meerdere onafhankelijke modellen routeren en onenigheden, correcties en bronnen zichtbaar maken voor inspectie. Dat garandeert geen correctheid en elimineert geen hallucinaties, maar het helpt om per workflow zichtbaar te maken welke modelversies en configuraties draaiden en hoe uitkomsten zich verhouden tot baseline-gedrag. Het professionele eindoordeel blijft altijd bij jou.

Wat kunnen tools doen en wat blijft jouw verantwoordelijkheid?

Tools kunnen drift meten, alerteren en onenigheden tussen modellen zichtbaar maken. Ze kunnen je helpen om snel te zien dat iets veranderd is en waar. Maar tools kunnen niet bepalen wat je met die informatie doet. Het blijft jouw verantwoordelijkheid om vast te stellen of een verandering acceptabel is voor jouw use case, of je moet terugschakelen naar een vorige versie, of je je workflow moet aanpassen. Tools geven je zichtbaarheid; ze geven je geen automatisch antwoord op de vraag of drift een probleem is. Behandel model drift als een verifieerbare risicolaag, niet als een statistisch effect dat je voor lief neemt.