Een modeluitfasering draait uit op een paniekactie als de vervanger, de regressietest en de overstapdatum nog niet vastliggen op de dag dat het bericht binnenkomt. De aanbieder bepaalt de uiterste datum. Jouw uitfaseringsprotocol bepaalt de rest: welke routes van het model afhangen, ook waar het alleen fallback is; welke tests elke vervanger moet halen; waar het verkeer heen gaat als die faalt; en je eigen overstapdatum, vóór die van de aanbieder.
Daarin zit het verschil tussen een geplande uitfasering en een einde dat je overvalt. Bij een geplande uitfasering weet je welk model het werk overneemt en wat het moet halen voordat er verkeer verschuift. Bij een einde dat je overvalt, verstrijkt de termijn terwijl je nog afhankelijkheden zoekt of gokt of de opvolger het werk aankan.
Hoofdstuk 11 van Het model-portfolio behandelt een uitfaseringsbericht van de leverancier als buiten-cyclustrigger, reden voor een gerichte beoordeling zonder op de kwartaalkalender te wachten, en laat de uitfasering zes fasen doorlopen. De aanbieder bepaalt de datum. Het hoofdstuk raadt aan om voor het model met de oudste reviewdatum in je register de eerste twee fasen alvast uit te schrijven, nog voordat er een bericht is. Komt er dan echt een, dan begint de klok met twee fasen klaar.
Wat moet ik doen als een AI-model waar ik op vertrouw wordt uitgefaseerd?
Start meteen een gerichte beoordeling, beperkt tot de routes en afhankelijkheden van dát model; experimenten met andere modellen wachten op de gewone kalender. Leg de exacte modelversie, het bericht, de uitschakeldatum en één migratie-eigenaar vast. Breng daarna elke geraakte route in kaart: elke toewijzing van een bepaald soort werk aan een model. Neem ook fallback-ketens mee, waarin het model pas werk krijgt als een ander model faalt.
Het hoofdstuk noemt twee reactietermijnen: een impactanalyse binnen twee werkdagen na het bericht, en een vervangingsbesluit binnen het eerste derde deel van de termijn die de aanbieder je werkelijk geeft. Dat zijn streefwaarden, geen garantie dat een migratie in die tijd past. Krijg je in een denkbeeldig scenario dertig dagen, dan valt het besluit binnen de eerste tien.
Houd het kiezen van een kandidaat los van de vrijgave voor productie. Leg in het besluit vast welke tests nog openstaan, wie ze uitvoert en wanneer ze geslaagd moeten zijn.
Houdt niet het model maar de hele agentrol op, gebruik dan de checklist om een productie-agent buiten gebruik te stellen: die loopt de triggers, sleutels en lopende kosten langs die je moet afsluiten.
Wat is het verschil tussen gedegradeerd en definitief uitgeschakeld?
Leg het bericht van de aanbieder naast de status in je eigen modelregister: het bericht zegt wat de aanbieder verandert, je register wat jouw systeem nog toestaat. Een model dat een aanbieder “deprecated” noemt, kan nog gewoon verkeer aannemen, dus noteer de term van de aanbieder naast de jouwe.
Het hoofdstuk werkt met drie interne statussen:
| Status | Betekenis | Toegestaan gebruik |
|---|---|---|
active | Werkt onder zijn huidige mandaat | De routes die dat mandaat toestaat |
deprecated | Gedegradeerd uit zijn huidige rol | Alleen wat de reden van degradatie toestaat |
sunset | Uitgefaseerd en als inactief geregistreerd | Geen verkeer |
De reden telt. Volgens de regels in het hoofdstuk mag een model dat om kosten of verdringing door een goedkoper equivalent is gedegradeerd, fallback blijven zolang de vervanger wordt gevalideerd. Een model dat om kwaliteitsfalen is gedegradeerd, gaat uit elke fallback-keten. Het mag wel in een shadow-baan blijven: daar wordt de uitvoer beoordeeld zonder dat een gebruiker er iets van ziet.
Mag de host de data van een route niet meer verwerken, dan verdwijnt het model in één stap uit de fallback-keten én de shadow-baan van die route. Ook een kopie van een live verzoek bevat immers de beschermde gegevens. Test daarna alleen nog met materiaal dat de host wél mag ontvangen, zoals correct geclassificeerde synthetische of geschoonde voorbeelden.
Een gewone degradatie kan eindigen in zo’n beperkte rol. Een uitfaseringsbericht opent het volledige protocol.
Wat hoort er in het uitfaseringsprotocol?
Doorloop de zes fasen uit het hoofdstuk op volgorde. Elke fase levert een vastlegging op die de volgende fase gebruikt.
1. Trigger
Leg vast wat het protocol in gang zette en wanneer: een uitfaseringsbericht, bevestigd kwaliteitsfalen, een kostenstijging die het mandaat niet meer rechtvaardigt, een gevalideerde goedkopere vervanger of een wijziging in de privacyklasse. Het type trigger zet de klok voor alles wat volgt.
Noteer de uiterste datum van de aanbieder en je eigen migratiedatum apart. Het migratievenster is die uiterste datum min een vooraf benoemde buffer voor mislukte tests en herstelwerk.
2. Impactanalyse
Zet alle afhankelijkheden op een rij: primaire routes, fallback-ketens, cascades die naar het model escaleren, agentmandaten, batchtaken en evaluatiesuites die het als vergelijkingsbasis gebruiken. Geef elke afhankelijkheid een eigenaar en een vervangingsactie.
De werkregel uit het hoofdstuk: één registerquery hoort dit binnen een middag te beantwoorden, en lukt dat niet, dan herstel je eerst het register. Leg het antwoord daarna naast je werkelijke routeringsconfiguratie en de diensten die het model aanroepen, want een vergeten fallback of nachtelijke batchtaak kan het model nog steeds werk sturen.
3. Communicatie
Informeer de betrokken eigenaren voordat er verkeer verschuift: engineering voor de wijziging in het routebeleid, product voor elke gedragsverandering die gebruikers merken, finance voor de nieuwe kostenbasislijn en compliance voor de privacy- en gegevensverwerkingsreview. Het escalatiepad in het mandaat van het vertrekkende model noemt het model dat zijn fouten opvangt. Volg dat spoor naar de routes die de wijziging erven, en informeer ook hun eigenaren.
In een klein bedrijf heeft één persoon soms meerdere van die rollen. Leg vast wie je hebt geïnformeerd en wanneer.
4. Rollback
Bepaal voordat de migratie begint wat het verkeer terugstuurt: de meetwaarde, de drempel, de observatieperiode en het model dat het werk dan overneemt. Een bevestigde harde fout vraagt om direct ingrijpen.
Bij een vervanging om kosten of verdringing laat het boek de voorganger op deprecated staan, niet op sunset, tot de vervanger dertig dagen verscherpte bewaking bij volledig verkeer heeft doorstaan. Dat is een werkafspraak uit het boek, geen garantie dat elk probleem binnen dertig dagen boven water komt.
Een voorganger die op kwaliteit is afgekeurd of de data van de route niet meer mag verwerken, kan die terugvalrol niet vervullen. Hetzelfde geldt voor een endpoint dat de aanbieder uitschakelt voordat de bewaking afloopt. In die gevallen eist hoofdstuk 11 een tweede conforme host, aangetoond voordat het migratievenster opengaat. Controleer of die host de hele bewakingsperiode beschikbaar blijft.
5. Migratievenster
Verplaats het verkeer route voor route en in stappen; de regressiegate van elke route bepaalt of je de volgende stap zet. Valideer de prompts per route opnieuw voor de vervanger in plaats van ze te kopiëren: volgens het hoofdstuk zijn prompts gekoppeld aan het model waarvoor ze zijn geschreven.
Voeg de testresultaten en uitroldatums toe aan het besluit. Plan bij de goedkeuring meteen de veiligheidscontrole na één week in. Moet een volledige vergelijking wachten tot de route bij vol verkeer stabiel draait, leg die latere reviewdatum dan apart vast.
6. Grafsteenrecord
Voordat je het model op sunset zet, verwijder je elke actieve verwijzing uit je routebeleid, ook in fallbacks; pas je de evaluatiesuites aan die het als vergelijkingsbasis gebruiken; en noteer je de datum en reden van uitfasering. Stop ook de aanroepen vanuit shadow-banen: sunset betekent geen verkeer.
Archiveer welk model het werk overnam, wat de migratie werkelijk kostte en duurde tegenover de schatting, en wat je ervan leerde. Bewaar de statusgeschiedenis, zodat je een oud routeringslog later nog kunt duiden.
Hoe kwalificeert een vervanger zich per route?
Hoofdstuk 11 eist zes goedkeuringen voordat een model promoveert, en elk daarvan is blokkerend. Controleer of de host de data van de route mag ontvangen voordat je testverzoeken stuurt, en leg daarna per goedkeuring het bewijs vast.
| Goedkeuring | Wat je moet aantonen |
|---|---|
| Taakkwaliteit | Op dezelfde items uit de taakset van de route blijft het betrouwbaarheidsinterval van het gepaarde verschil binnen de kwaliteitsmarge die de route vooraf heeft vastgelegd. |
| Kosten | De kosten per verzoek zijn vergeleken bij dezelfde werklast en hetzelfde volume. Een hogere prijs is verantwoord met gemeten kwaliteitswinst op die route. |
| Regressie | De vastgelegde controles van de route slagen op apart gehouden live verzoeken, inclusief de nultolerantiecriteria. |
| Latentie | Het responstijdbudget van de route houdt stand op het percentiel dat de route voorschrijft, bijvoorbeeld P95. |
| Privacyklasse | De host van de vervanger mag de data van de route verwerken. |
| Routecompatibiliteit | De vervanger werkt binnen zijn escalatie- en fallback-ketens, en een eventueel herontwerp is getest en goedgekeurd. |
Deze controles gelden per toewijzing: slagen voor de extractietests maakt een model nog niet geschikt voor de fallback-plek van een samenvattingstaak, en een goede offline score zegt niets over de responstijd onder belasting.
Een uitgewerkt voorbeeld: de vergeten fallback
Neem een hypothetisch bedrijf dat supportsoftware maakt. Model A haalt velden uit binnenkomende tickets. Daarnaast is A de fallback voor een nachtelijke taak die tickets samenvat. De aanbieder geeft een denkbeeldige uitfaseringstermijn van dertig dagen. A, B en C zijn plaatshouders, geen echte modellen en geen echt leveranciersschema.
De verantwoordelijke engineer vindt op dag één beide afhankelijkheden. De samenvattingstaak draait normaal op een ander model. Dat die taak elke nacht slaagt, zegt dus niets over de vraag of een vervanger de fallback-rol van A aankan.
Model B is de kandidaat. Model C draait op een andere, toegestane host en is in dit voorbeeld al eerder gekwalificeerd voor beide taken bij de vereiste belasting. Toch oefent het team het terugvallen op C vóór de migratie. A verdwijnt tijdens de bewakingsperiode, dus het plan kan niet leunen op een terugkeer naar A.
Voor de samenvattingen legt het team vóór het testen één harde regel vast: elke onopgeloste klacht blijft herkenbaar en staat als onopgelost gemarkeerd. Eén bevestigde weglating of ten onrechte gesloten melding blokkeert de promotie.
B slaagt voor de extractietests, maar maakt bij de samenvatting deze hypothetische fout:
| Onderdeel | Inhoud |
|---|---|
| Testinvoer | T-41: terugbetaling gevraagd, onopgelost. T-42: inloggen hersteld, opgelost. |
| Samenvatting van B | Inloggen hersteld voor T-42. |
| Vereiste uitkomst | T-41 heeft nog een openstaand verzoek om terugbetaling. |
| Besluit | Afgekeurd. B laat T-41 weg en kan de fallback-plek van de samenvattingstaak niet overnemen. |
Het team past de samenvattingsprompt aan en neemt dit geval op als vaste regressietest. Alleen slagen voor het gerepareerde voorbeeld maakt B nog niet geschikt: B moet ook slagen voor de apart gehouden tests en de overige routecontroles.
Het illustratieve tijdpad maakt die beslissing expliciet:
| Moment | Vereiste vastlegging of actie |
|---|---|
| Eerste twee werkdagen | Afhankelijkheden, eigenaren, uiterste datum en communicatie vastgelegd. |
| Uiterlijk dag 10 | B aangewezen als kandidaat; C aangewezen als terugval; het falen van B op de samenvatting vastgelegd als blokkade. |
| Uiterlijk dag 15 | Alle zes goedkeuringen en hersteltests afgerond voor elke voorgestelde toewijzing. Elke route waarvoor B niet slaagt, gaat naar het al gekwalificeerde C. |
| Dag 16–21 | Gefaseerde migratie op de goedgekeurde routes; aan het eind van dag 21 is A uit alle primaire routes en fallback-ketens verwijderd. |
| Tijdens en na de uitrol | Geplande controle uitvoeren, grafsteenrecord van A afronden en verscherpte bewaking aanhouden met C beschikbaar. |
De laatste negen dagen zijn buffer, geen vrijbrief om een controle over te slaan. Schendt B tijdens de uitrol alsnog de harde samenvattingsregel, dan stopt het team met het uitbreiden van het verkeer naar B en gaat het geraakte vervolgwerk naar C.
Dit voorbeeld gaat uit van een reservemodel dat al gekwalificeerd is. Zonder zo’n reserve heeft het team een onopgelost continuïteitsprobleem, en eerdere datums opschrijven lost dat niet op.
Wat moet er klaarstaan vóór het volgende uitfaseringsbericht?
Leg in de kwartaalreview uit het hoofdstuk je gemeten vervangingsdoorlooptijd naast de aankondigingstermijnen die elke aanbieder in het verleden gaf. Het doel in het hoofdstuk is een vervangingscyclus van hooguit de helft van de historische aankondigingstermijn; een cyclus die langer duurt dan de termijn zelf is het alarmsignaal. Zit je in die situatie, beperk dan het werk dat een vervanging vraagt of houd een gevalideerd reservemodel paraat.
Lees per aanbieder het gepubliceerde beleid, inclusief de uitzonderingen, en leg vast wanneer je het las, wie het de volgende keer leest en welke aankondiging een eerdere herlezing uitlokt.
Kijk ook wat je primaire model en je fallback delen: twee modellen van dezelfde aanbieder gaan samen onderuit bij een storing op leveranciersniveau. Een tweede aanbieder kost extra evaluatie- en beheerwerk, dus voeg die toe waar een storing of uitfasering het hardst aankomt. Is één AI-model genoeg? gaat over die bredere portfoliokeuze; dit artikel vraagt alleen of het aangewezen alternatief de geraakte route kan overnemen.
Het protocol maakt je voorbereiding controleerbaar. Het hier besproken materiaal toont niet aan dat het protocol tot minder storingen of lagere kosten leidt, of dat een migratievenster altijd volstaat.
Probeer dit vandaag
Maak een lijst van elk model dat je product op naam en versie aanroept, inclusief fallbacks en batchtaken. Schrijf bij elk model welke vervanger je zou inzetten als het over dertig dagen verdwijnt, en of je die vervanger al hebt getest.
Kies daarna één geraakte route en doe een korte gereedheidstest:
- Vul de registerregel in. Noteer het huidige model en de host, de route, de eigenaar, de beoogde vervanger, het model waarop je terugvalt, het testbewijs en de testdatum. Een leeg bewijsveld betekent: ongetest.
- Leg één harde controle vast. Formuleer het vereiste resultaat voordat je de kandidaat laat draaien. In het voorbeeld hierboven moeten de ticketnummers van onopgeloste klachten en hun status in de samenvatting blijven staan. Controleer of de host de testdata mag ontvangen.
- Speel twee gevallen opnieuw af. Gebruik in een testomgeving één gewoon geval en één geval waarvan je weet dat het eerder misging, met toegestane data. Bewaar de invoer, de promptversie, de uitvoer en het oordeel: geslaagd of gezakt.
- Oefen het herstelpad. Maak het vertrekkende endpoint in je testopstelling onbereikbaar en activeer het beoogde herstelpad. Controleer de uitvoer én de logs: welk model en welke host hebben het verzoek echt afgehandeld?
- Leg het gat vast. Markeer elke controle als geslaagd, gezakt of niet uitgevoerd, en geef de eerste ontbrekende controle een eigenaar en een datum.
Twee gevallen laten zien wat er bij die twee gevallen gebeurde. Over de kwaliteit van de route, of over de vraag of die klaar is voor productie, zeggen ze niets. Houd dat bewijs dus los van de promotiebeslissing. Ongetest betekent dat er een verrassing op je wacht.
Citeer deze pagina:Uitfaseringsprotocol versus een einde dat je overvalt: kies zelf wanneer je overstapt.Len P. van der Hof. https://lenvanderhof.com/nl/blog/modeluitfasering-versus-verrassend-einde/ ·