Elk model wordt uitgefaseerd: uw lock-in zit in uw testset

De klinisch verantwoordelijke van een AI-gezondheidscompanion voor vrouwen in de overgang die wij draaien, stuurde de e-mail door met één regel erboven: kunnen we gewoon overstappen? Daaronder kondigde onze modelaanbieder aan dat de versie van het model waarop de companion draaide, over een paar maanden op een vaste datum zou worden uitgefaseerd. De aanbevolen opvolger was nieuwer, sneller en beter op elke gepubliceerde benchmark.

Dezelfde middag lieten we de opvolger los op de acceptatieset van de companion. De totale nauwkeurigheid ging omhoog, en dat was het makkelijke deel. Maar de opvolger stuurde sommige berichten minder vaak door naar het portaal voor clinici, maakte de samenvattingen die clinici lezen korter, waardoor details waarop zij vertrouwden wegvielen, en vulde een ontbrekend detail in het bericht van een gebruiker eerder in met een plausibele gok. In een gezondheidsproduct zit het risico precies in die gevallen.

Lock-in bij een model wordt minder bepaald door het contract of de API van de aanbieder dan door de vraag of u een set echte, gelabelde gevallen bezit waarmee een opvolger binnen een paar dagen te kwalificeren is. Zonder zo'n set blijft een workflow meestal op het huidige model, tot de uitfaseringsdatum een overhaaste overstap afdwingt.

Elk gehost model heeft een uitfaseringsdatum, of die nu al is aangekondigd of niet. Anthropic schrijft in "Commitments on model deprecation and preservation" (november 2025) dat het uitfaseren van oudere modellen op dit moment nodig is om nieuwe beschikbaar te maken, en verplicht zich om de gewichten van alle publiek uitgebrachte modellen te bewaren. Bewaarde gewichten zijn geen blijvende toegang. Een workflow die op een model draait, is gebouwd op een onderdeel met een beperkte levensduur, en de architectuur moet op vervanging zijn voorbereid.

Zet de hele bundel vast, nooit een alias

De meeste aanbieders werken met aliassen die naar de nieuwste versie van een modelfamilie verwijzen. Tijdens de ontwikkeling is dat handig, in productie gevaarlijk, want het model achter de alias kan veranderen zonder dat er aan uw kant iets wijzigt. De workflow die vorige maand voor zijn acceptatierun slaagde, draait vandaag misschien op een ander model.

Een productieworkflow verwijst naar een exacte, gedateerde versie van het model. Die wordt vastgezet samen met alles wat erop is afgestemd: de prompt, het uitvoerschema, de decoding-instellingen en elke drempel die gevallen doorstuurt. Die bundel is één release, wordt vastgelegd in het bewijs voor die release en verandert alleen via een nieuwe release. Een rollback zet de hele bundel terug, niet alleen de naam van het model. Een oud model onder een nieuwe prompt is een derde configuratie die niemand heeft getest.

Vastzetten heeft een prijs. Een vastgezet model krijgt geen van de latere correcties van de aanbieder, dus de workflow ruilt ongemerkte drift in voor bekende veroudering. Voor alles wat bij een clinicus of een gebruiker terechtkomt, is die ruil het waard, en de vastgezette versie wordt herzien zodra de aanbieder een correctie publiceert die de taak raakt. Bij een interne opzet die een mens toch herschrijft, zouden we minder streng zijn.

Biedt een aanbieder geen vaste versies met een tijdige aankondiging van uitfasering, dan draait een workflow met echte gevolgen niet bij die aanbieder. Yan, Bischof, Frye, Husain, Liu en Shankar geven in "What We Learned from a Year of Building with LLMs" (O'Reilly, mei 2024) hetzelfde advies, zet de versie van het model in productie vast, met als voorbeeld een team waarvan de intentclassificatie zo'n 10% slechter werd bij de overstap tussen twee versies van hetzelfde model. De regel is niet nieuw. Lastiger is de uitfasering die volgt te behandelen als een gepland moment met een datum en een budget.

Een dunne interface maakt het model vervangbaar

De workflow praat nooit rechtstreeks met een model. Hij praat met een kleine interface per taak: vat dit bericht samen voor het portaal voor clinici, deel dit bericht in bij een van deze routes. Elke interface heeft een vast invoer- en uitvoerschema, en elk antwoord wordt daartegen gevalideerd. Achter de interface zitten het model, de prompt en de instellingen.

De rest van het systeem weet niet welk model er in gebruik is. Een model wisselen is een wijziging achter één interface, getest op de gevallen van die interface, en twee modellen kunnen naast elkaar op dezelfde invoer draaien. Zo wordt een opvolger gekwalificeerd voordat hij echt werk doet.

Kwalificatie vergelijkt foutprofielen en verschuivingen

Een kandidaat-opvolger draait eerst op de volledige acceptatieset en daarna op een recente steekproef van productiegevallen waarvan de uitkomst bekend is. De totale nauwkeurigheid is daarbij het minst interessante cijfer. Twee getallen doen er meer toe.

Het eerste is het foutprofiel: welke gevallen het oude model goed had en het nieuwe fout, en in welke velden en segmenten die zitten. Een opvolger die over de hele linie beter is, maar nieuwe fouten maakt bij berichten in één taal of bij berichten die bij een clinicus horen te komen, gaat pas live als die gevallen zijn afgevangen, met een aangepaste prompt, een validatieregel of een beperktere inzet.

Het tweede is de verschuiving (churn): het aandeel gevallen waarin het nieuwe model een ander antwoord geeft dan het oude, los van de vraag of een van beide juist is. De nauwkeurigheid kan stijgen terwijl de verschuiving groot is, omdat het nieuwe model een deel van de oude fouten oplost en elders nieuwe maakt. De verschuiving is wat de mensen in de workflow merken. Een clinicus die heeft geleerd welke soorten berichten het systeem slecht samenvat, ontdekt dat die lijst ongemerkt is veranderd, en de eigen ervaring is ineens minder waard. Een grote verschuiving betekent een langere shadow run en een briefing voor de beoordelaars, ook als de lijn van de nauwkeurigheid er als goed nieuws uitziet.

De set met verschillen maakt de beoordeling ook betaalbaar. Alleen gevallen waarin de twee modellen verschillen, hebben een mens nodig, dus de klinisch verantwoordelijke beoordeelt de verschillen, gegroepeerd per soort, in plaats van de hele set, en tekent voor de wissel zoals bij de oorspronkelijke livegang.

Drempels zijn niet over te zetten

Elke drempel in de workflow is afgesteld op het gedrag van het oude model: de score waaronder een bericht naar een clinicus gaat, de mate van overeenkomst waarbij twee berichten als dezelfde vraag gelden. Een nieuw model verdeelt die scores anders. Een drempel die ongewijzigd wordt meegenomen, is een nieuwe, ongeteste regel met een oud getal. Daarom wordt elke drempel opnieuw gekalibreerd op de kwalificatiegevallen, en die herkalibratie hoort bij de wijziging waarvoor de klinisch verantwoordelijke tekent.

Elke uitgelezen waarde verwijst naar haar bron

Het gevaarlijkste verschil van die middag zat niet in de doorverwijzing of de kortere samenvattingen. Die vangt de acceptatieset op, omdat ze zichtbaar worden als verschillen met bekende antwoorden. Het gevaarlijkste was het gegokte detail. Een plausibele verzonnen waarde komt per definitie door elke formaatcontrole.

Daarom moet elke waarde die een model uitleest, verwijzen naar de plek in het bronbericht waar ze staat: de exacte tekstpassage. De validatielaag controleert of de waarde daar echt staat. Een waarde zonder vindplaats geldt als ontbrekend, niet als gevonden. Voor deze controle maakt het niet uit welk model er draait, en juist daardoor is ze bij een wissel zo waardevol. Wat een nieuw model creatief invult, wordt zo een gewone, zichtbare uitzondering.

Opvolgers draaien eerst in shadow mode

Na de kwalificatie draait de kandidaat in shadow mode mee op live verkeer, lang genoeg om de gebruikelijke variatie aan berichten te zien. Hij krijgt dezelfde invoer als het productiemodel, zijn uitvoer wordt veld voor veld vergeleken en niets van wat hij oplevert, komt bij een gebruiker of in het portaal voor clinici terecht. Shadow mode laat ook zien wat een afgerond geval kost bij echt volume, en een nieuw model kan die kosten beide kanten op bewegen: een andere prijs per token, een ander aantal tokens voor dezelfde prompt, een ander aandeel gevallen dat een tweede ronde nodig heeft.

Reken terug vanaf de uitfaseringsdatum

De uitfaseringsdatum is niet de deadline. De deadline is de laatste datum waarop de kwalificatie kan beginnen en nog veilig af kan komen. Reken terug: de uitfaseringsdatum, min het aftekenen, min een shadow run die lang genoeg is om de gebruikelijke variatie aan gevallen te zien, min de kwalificatie en het werk aan de prompts. Voor een product als de companion ligt de echte startdatum dan vaak maar een paar weken na de e-mail van de aanbieder. De overdracht legt die berekening vast, zodat het team van de klant er niet pas een maand voor het einde achter komt.

Een uitfasering is ook het goedkoopste moment om te vragen of de taak het model dat ze had nog wel nodig heeft. De workflow moet toch opnieuw gekwalificeerd worden. Soms slaagt een kleiner model voor dezelfde gevallen tegen lagere kosten per geval. Soms kan een stap die het model deed, nu door deterministische code worden gedaan, omdat de informatie die vroeger als vrije tekst binnenkwam, nu gestructureerd binnenkomt. De opvolger is zelden alleen een één-op-één vervanging.

Een beter model is een riskantere migratie

De opvolger die het best oogt, verdient de scherpste blik. Als een nieuw model duidelijk sterker is, ontspannen beoordelaars, worden steekproeven dunner en wil de sponsor de wissel snel afronden, allemaal op het moment dat de fouten zijn verhuisd naar plekken waar nog niemand heeft leren kijken. Een zwakke opvolger zakt voor de kwalificatie en wordt verbeterd. Een sterke slaagt, en zijn paar nieuwe fouten komen terecht in segmenten waar het oude model betrouwbaar was en de controle allang was gestopt. De eerste weken na een wissel krijgen daarom meer controle, niet minder, gericht op precies de segmenten waar de verschuiving het grootst was.

De acceptatieset veroudert sneller dan het model

Een acceptatieset die bij de livegang is opgebouwd, beschrijft de mensen, documenten en vragen van dat jaar. Twee jaar later is een deel van het bedrijf dat ze beschrijft verdwenen en zijn er nieuwe delen bijgekomen. Een opvolger die slaagt voor een oude set, is gekwalificeerd voor een bedrijf dat in die vorm niet meer bestaat. Daarom wordt de set doorlopend ververst vanuit productie: elk geval dat een medewerker heeft gecorrigeerd, wordt een kandidaat, en elk kwartaal voegen de eigenaren recente gevallen toe en halen ze gevallen weg die niet meer voorkomen. Een set die een jaar niet is veranderd, geeft valse zekerheid op precies het moment dat hij nodig is.

De acceptatieset bepaalt wat overstappen kost

Bij een model zijn het contract en de API de goedkope onderdelen van lock-in, en met de interface erbij is de wissel een kleine codewijziging. Duur zijn de kwalificatierun, de beoordeling van de verschillen, de herkalibratie, de aanpassingen aan de prompts en het aftekenen, en dat alles leunt op een set echte, gelabelde gevallen waarop de klant vertrouwt. Met een goed bijgehouden set kost een wissel een paar dagen. Zonder wordt het een klein project dat steeds wordt uitgesteld, en zo ziet lock-in er in de praktijk uit. Een abstractielaag voor meerdere leveranciers draagt minder bij aan de onafhankelijkheid van een bedrijf dan die set, actueel gehouden en met aangewezen eigenaren.

De exit hoort bij de overdracht

Herkwalificatie is een post in de doorlopende kosten van de workflow, minstens één keer per jaar verwacht, en het eigen team van de klant voert haar uit zonder ons te bellen. In de overdracht staan de modellen waarop de workflow is gekwalificeerd, niet alleen het model dat nu draait. Waar de hostingafspraken het toelaten, is een daarvan een open-weight model dat de klant op eigen infrastructuur kan draaien. Zo is er altijd een route die niet afhangt van de roadmap van één aanbieder. De overdracht legt ook de aankondigingstermijn van de aanbieder vast en de terugrekening hierboven. En tijdens de overdracht wordt de kwalificatie één keer geoefend, met een echte kandidaat, terwijl de bouwers er nog bij zijn.

Twee dingen doen we niet. Upgraden omdat publieke benchmarks beter zijn geworden, want daarin zitten geen van de eigen gevallen, talen of indelingen van de klant. En een gehost model finetunen, tenzij de klant accepteert dat de finetune samen met het basismodel wordt uitgefaseerd.

Gewoon gepland onderhoud

Het model waarmee een workflow begint, is zelden het model waarmee hij eindigt, en wat meegaat is de acceptatieset. Komt de volgende aankondiging van uitfasering binnen, reken dan terug naar de laatste veilige startdatum en zet die datum in de planning.