AI-basismodel wisselen zonder kwaliteitsverlies: Evals, Canary en Rollback

Een nieuw AI-basismodel belooft vaak betere antwoorden, lagere kosten of snellere reactietijden. Voor een productieve website-chatbot is de overstap echter meer dan zomaar een software-update. Een nieuwe modelversie kan instructies al anders wegen, antwoorden uitgebreider formuleren, gestructureerde data afwijkend genereren of tools in een andere volgorde aanroepen. Een migratie is daarom pas geslaagd als de chatbot zijn taken minstens zo betrouwbaar uitvoert als voorheen – én wanneer het team bij problemen binnen enkele minuten kan terugschakelen.

Aanbieders kondigen modellen regelmatig af. De OpenAI-documentatie over uitfaseringen vermeldt einddata en aanbevolen vervangende modellen; Anthropic onderscheidt in zijn model-lifecycle de status 'Active', 'Legacy', 'Deprecated' en 'Retired'. Zulke deadlines vormen de aanleiding voor een migratie, maar zijn geen bewijs van kwaliteit. Dat bewijs wordt enkel geleverd door een test- en uitrolprocedure die aansluit bij je eigen chatbot.

Wat er daadwerkelijk verandert bij een wissel van het basismodel

Dit proces moet duidelijk worden gescheiden van een migratie van het embedding-model . Bij een embedding-wissel moeten documenten opnieuw worden gevectoriseerd en moeten zoekindexen compatibel worden gehouden. Bij een wissel van het basismodel blijft de retrieval-index normaal gesproken intact; het model dat de uiteindelijke reactie genereert op basis van de systeeminstructie, het gesprek, de gevonden bronnen en tool-resultaten, wordt gewijzigd. Daarom testen we het antwoordgedrag, de bronbinding, de opmaak, het tool-gebruik, de veiligheid, de latentie en de kosten.

Ook een algemene shadow-mode-test voor de website-launch lost slechts een deel van de taak op. Shadow traffic kan twee modellen van dezelfde invoer voorzien zonder het nieuwe antwoord daadwerkelijk aan de gebruiker te tonen. De hier beschreven wissel van het basismodel gaat verder: er wordt vooraf een acceptatiematrix gedefinieerd, een klein deel van het echte verkeer wordt naar de kandidaat geleid, gebruiker- en systeemsignalen worden gemonitord en er staat een geteste rollback-procedure klaar.

Vóór het testen: leg een helder migratieverdrag vast

Vergelijkingen zijn waardeloos als er ondertussen meerdere variabelen veranderen. Houd daarom voor de eerste ronde de systeemprompt, retrieval-configuratie, tool-schema's, temperatuur, maximale outputlengte en veiligheidsregels zo consistent mogelijk en documenteer onvermijdelijke parameterwijzigingen, zoals niet-ondersteunde sampling-opties. Documenteer het huidige model als basis en het nieuwe model als kandidaat. Gebruik waar mogelijk expliciete modelversies in plaats van een dynamische alias. Een alias kan later namelijk naar een andere snapshot verwijzen en zo de vergelijking beïnvloeden.

Het migratieverdrag bevat ook de gebruikersgroepen en functionaliteiten die voorlopig worden uitgesloten. Een FAQ-chatbot kan bijvoorbeeld al vroeg naar de canary-fase, terwijl schrijftoegang voor bestellingen, contractinformatie of bijzonder gevoelige supportgevallen langer op de basis blijven draaien. Zo wordt het risico beperkt op basis van zakelijke impact en niet alleen op basis van technische complexiteit.

De testset moet het daadwerkelijke verkeer weerspiegelen

Een Golden Set moet niet alleen uit schone standaardvragen bestaan. Verzamel geanonimiseerde of synthetisch nagebootste scenario's uit de belangrijkste intents: duidelijke vragen, dubbelzinnige formuleringen, vervolgvragen, ontbrekende documenten, tegenstrijdige bronnen, tool-fouten en invoer die moet worden overgedragen aan een medewerker. Verdeel de situaties naar taal, apparaat, klanttype en risicoklasse. Zo blijft zichtbaar of een goed algemeen cijfer kleine, maar bedrijfskritische subgroepen aan het oog onttrekt.

De officiële Anthropic-handleiding over succescriteria en evals beveelt specifieke, meetbare en op de toepassing afgestemde criteria aan, evenals realistische randgevallen. Ook de OpenAI-handleiding over evals beschrijft tests als een essentieel onderdeel van betrouwbare toepassingen, vooral bij upgrades of bij het uitproberen van nieuwe modellen. Omdat OpenAI op dezelfde pagina het voormalige Evals-platform afkondigt, is het verstandig om je eigen Golden Set in een overdraagbaar formaat op te slaan en niet te koppelen aan één enkel dashboard.

Een beoordelingsmatrix in plaats van één enkel gemiddelde

De volgende grenswaarden zijn een voorbeeld en geen universele regel. Stel ze vast op basis van de huidige prestaties in productie en de potentiële schade van een fout. Een kandidaat mag een lagere tokenprijs niet compenseren met een slechtere bronbinding.

Automatische controles zijn geschikt voor JSON-schema's, verplichte formuleringen, linkdoelen, tool-argumenten en deterministische bedrijfsregels. Voor de juiste toon, volledigheid en nuttige uitleg is aanvullend een duidelijke beoordelingsrubriek nodig; steekproeven door domeinexperts kalibreren een op LLM gebaseerde beoordelaar. Sla de resultaten op per intent en risicoklasse, niet alleen als één totale score. Hoe zo'n set wordt opgebouwd, lees je ook in onze gids over antwoordkwaliteit met een Golden Set.

Concreet voorbeeld: modelwissel bij B2B-support

Stel dat een B2B-softwareleverancier een chatbot inzet voor productvragen, accountbeheer en het voorbereiden van supporttickets. Het team stelt 240 testcases samen: 120 veelgestelde kennisvragen, 40 dubbelzinnige vervolgvragen, 30 scenario's met ontbrekende bronnen, 25 tool-simulaties en 25 veiligheids- of overdrachtsgevallen. Beide modellen krijgen exact dezelfde prompts, bronresultaten en gesimuleerde tool-outputs.

De kandidaat beantwoordt standaardvragen sneller en goedkoper, maar verliest bij vijf vervolgvragen de context van het vorige bericht. De algehele score zou alsnog hoger uitvallen. De segmentanalyse laat echter een duidelijke kwaliteitsbreuk zien. Het team voegt geen willekeurige uitzondering toe, maar verfijnt de conversatieregel, breidt de testset uit met vergelijkbare situaties en test beide modellen opnieuw. Pas nadat de kandidaat aan alle harde gates voldoet, start de canary-fase in productie.

Om te beginnen wordt twee procent van de geschikte nieuwe gesprekken toegewezen aan de kandidaat. Deze toewijzing wordt bij de start van het gesprek afgeleid van bijvoorbeeld een hash van het Conversation-ID en blijft het gehele gesprek behouden; hogere canary-niveaus gelden alleen voor nieuwe gesprekken. Schrijvende tool-aanroepen en hoog-risicointents blijven voorlopig op het basismodel. Na een voldoende lange observatieperiode volgen stappen naar tien, 25, 50 en ten slotte 100 procent – maar alleen als elke gate groen blijft. De fasen en minimale steekproefgrootten worden vooraf vastgelegd, zodat tijdsdruk de regels achteraf niet versoepelt.

Online signalen die er echt toe doen

Tijdens de canary-fase zijn HTTP-fouten en de gemiddelde latentie niet voldoende. Monitor het no-answer-percentage, afhakers na het eerste antwoord, herhalingsvragen, het handoff-percentage, bronkliks, schemafouten en afgebroken tool-acties gescheiden voor de basis en de kandidaat. Eén centrale trace koppelt de modelversie, promptversie, retrieval-resultaten en tool-stappen aan elkaar, zonder onnodige persoonsgegevens op te slaan. Ons artikel over chatbot-observability legt dit controlepad in detail uit.

Vergelijk bovendien de kosten per succesvol opgelost geval in plaats van alleen de kosten per miljoen tokens. Een goedkoper model dat vaker tot verduidelijkingsvragen of menselijke tussenkomst leidt, kan operationeel duurder uitvallen. Omgekeerd kan een lichte stijging van de latentie acceptabel zijn als dit in een belangrijke risicoklasse aantoonbaar nauwkeurigere antwoorden oplevert.

Rollback is een functionaliteit, geen document

De weg terug moet technisch zijn getest vóór de eerste canary-stap. Het model-ID en bijbehorende parameters horen thuis in een geversioneerde configuratie of een gecontroleerde feature flag. Zolang de leverancier de oude versie nog ondersteunt, blijft deze tijdens de canary beschikbaar als fallback; voor de einddatum van de ondersteuning is bovendien een nieuw ondersteund fallback-model nodig. Bestaande gesprekken moeten óf consistent op hun oorspronkelijke model blijven draaien óf overstappen volgens een expliciet geteste regel.

Definieer harde triggers: bijvoorbeeld een schemafout bij een schrijvende actie, een verslechtering bij een veiligheidsrelevante intent, een duidelijke stijging van het foutpercentage of het overschrijden van het latentiebudget. Bij zo'n signaal wordt er automatisch of door een toegewezen piketdienst direct teruggeschakeld. Vervolgens blijven de logs, de kandidaatversie en de betreffende steekproef bewaard, zodat de oorzaak geanalyseerd kan worden. Een voorbereide procedure is aanzienlijk betrouwbaarder dan een spontane code-deploy; aanvullend helpt een compleet incident-response-playbook.

Checklist voor de vrijgave

• Einddatum van de ondersteuning, vervangend model en betrokken eindpunten uit de officiële leveranciersdocumentatie vastleggen.
• Basis en kandidaat vastzetten met een ongewijzigde prompt-, retrieval- en tool-configuratie.
• Golden Set onderverdelen naar intent, taal en risicoklasse; randgevallen en echte foutpatronen toevoegen.
• Harde gates definiëren voor bronbinding, gestructureerde uitvoer, tools, veiligheid en handoff.
• Latentie, foutpercentage, tokens en kosten per opgelost geval meten.
• Canary-toewijzing voor volledige gesprekken stabiel houden en gevoelige functies voorlopig uitsluiten.
• Stappen, minimale steekproefomvang, observatieduur en afbreekcriteria documenteren vóór de uitrol.
• Rollback technisch testen, verantwoordelijken aanwijzen en een door de leverancier ondersteunde fallback beschikbaar houden.
• Na het bereiken van 100 procent blijven monitoren en de Golden Set uitbreiden met nieuw ontdekte situaties uit productie.

Conclusie: De modelnaam is pas het begin

Een gecontroleerde wissel van het basismodel verbindt productkwaliteit met operationele zekerheid. Officiële lifecycle-informatie geeft de deadline aan, evals leveren het bewijs van geschiktheid, canary-verkeer beperkt de impact van onvoorziene fouten en een geteste rollback verkort de reactietijd. Wie deze vier bouwstenen als een herhaalbaar proces inricht, kan nieuwe modellen benutten zonder van de website-chatbot een experiment voor alle gebruikers te maken.

Wil je de modelversie, kwaliteitsgates en uitrol van je website-chatbot gestructureerd aanpakken? ChatReact helpt je bij het inrichten van je kennisbank, antwoordgedrag en overdrachten, zodat alle wijzigingen meetbaar en onder controle blijven.