Elk model wordt uitgefaseerd: vaste versies, kwalificatieruns en een exitplan

Het financeteam stuurde de e-mail door met één regel erboven: kunnen we gewoon overstappen? Daaronder kondigde hun modelaanbieder aan dat de versie van het model waarop hun documentworkflow 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 hun acceptatieset. De totale nauwkeurigheid ging omhoog. Maar de opvolger las sommige Europese datums in een andere volgorde, rondde bedragen bij een handvol factuurindelingen van leveranciers anders af en vulde een ontbrekend inkoopordernummer eerder in met een plausibele gok. Gemiddeld beter, in de details anders. En in een financeworkflow zit het geld in de details.

Elk gehost model heeft een uitfaseringsdatum, of die nu al is aangekondigd of niet. Een workflow die op een model draait, is gebouwd op een onderdeel met een beperkte levensduur, en de architectuur moet ervan uitgaan dat het vervangen wordt.

Zet de exacte versie 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.

Elke productieworkflow die we bouwen, verwijst naar een exacte, gedateerde versie van het model. Die versie hoort bij de release, wordt vastgelegd in het bewijs voor die release en verandert alleen via een nieuwe release. Biedt een aanbieder geen vaste versies met een tijdige aankondiging van uitfasering, dan draait een workflow met echte gevolgen niet bij die aanbieder.

Een dunne interface maakt het model vervangbaar

De workflow praat nooit rechtstreeks met een model. Hij praat met een kleine interface per taak: haal deze velden uit dit document, deel dit ticket in bij een van deze wachtrijen. 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.

Prompts horen bij het model waarvoor ze zijn geschreven. De formulering, de voorbeelden en de opmaakinstructies zijn afgestemd op hoe dat model reageert. Zet u ze ongewijzigd over, dan werken ze vaak nog, maar soms gaan ze op subtiele punten mis. Een prompt krijgt daarom een versienummer samen met het model waarop hij is gekwalificeerd, en bij elke modelwissel wordt de prompt opnieuw beoordeeld.

Kwalificatie vergelijkt foutprofielen, geen scores

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. Het gaat om het verschil in fouten: 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 datums uit één markt of bij creditnota's, gaat pas live als die gevallen zijn afgevangen, met een aangepaste prompt, een validatieregel of een beperktere inzet. De eigenaar bij finance ziet de vergelijking en tekent voor de wissel, net zoals hij voor de oorspronkelijke livegang tekende.

Elke uitgelezen waarde verwijst naar haar bron

Het gevaarlijkste verschil van die middag zat niet in de datums of de afronding. Die vangt de validatie op, omdat een verkeerde datum of een verkeerd bedrag meestal niet door de controle tegen de inkooporder komt. Het gevaarlijkste was het verzonnen inkoopordernummer. Een plausibele verzonnen waarde komt per definitie door elke formaatcontrole.

Daarom moet elke waarde die een model uitleest, verwijzen naar de plek in het brondocument waar ze staat: de pagina en het tekstgebied. 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, gedurende een periode met een maandafsluiting erin. Hij krijgt dezelfde invoer als het productiemodel, zijn uitvoer wordt veld voor veld vergeleken en niets van wat hij oplevert, komt in het ERP terecht. Verschillen worden gebundeld per veld en segment, zodat de eigenaar bij finance een korte lijst met soorten verschillen beoordeelt en geen duizenden losse gevallen.

Shadow mode laat ook zien wat een afgerond geval kost bij echt volume. 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.

De acceptatieset bepaalt wat overstappen kost

Bestuurders zien lock-in bij een leverancier meestal als een kwestie van contracten en API's. Bij een model zijn dat juist de goedkope onderdelen. Dankzij de interface hierboven is de wissel een kleine codewijziging. De echte kosten zitten in de kwalificatierun, de beoordeling van de verschillen, de aanpassingen aan de prompts en het aftekenen, en dat alles staat of valt met één bezit: een set echte, gelabelde gevallen waarop de klant vertrouwt. Met een goed bijgehouden acceptatieset kost een wissel een paar dagen. Zonder wordt het een klein project, en in de praktijk blijft de klant dan bij wat hij heeft. Dat is wat lock-in in werkelijkheid betekent.

Wie onafhankelijk wil blijven van elke modelaanbieder, heeft dus niet in de eerste plaats een abstractielaag voor meerdere leveranciers nodig. Het waardevolste bezit is de eigen acceptatieset, actueel gehouden en met aangewezen eigenaren.

De exit hoort bij de overdracht

Herkwalificatie nemen we op in de doorlopende kosten van elke workflow die we overdragen, in de verwachting dat die minstens één keer per jaar nodig is, en het eigen team van de klant voert haar uit. Een klant die geen opvolger kan kwalificeren zonder ons te bellen, is niet volledig eigenaar van het systeem.

In elke 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, zodat iemand weet wanneer de volgende kwalificatie moet beginnen. 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 leveranciers, talen of factuurindelingen van de klant. En een gehost model finetunen, tenzij de klant accepteert dat de finetune samen met het basismodel wordt uitgefaseerd.

Gewoon gepland onderhoud

De modelkeuze voelt als hét besluit in een AI-project. Over de levensduur van een workflow is het een van de meest tijdelijke keuzes. De acceptatieset blijft, en daardoor is de volgende aankondiging van uitfasering een datum in de onderhoudsplanning en geen incident.