Als het model onder uw software verdwijnt

Software die u aanschaft, gaat jaren mee en verandert in kleine stappen. Een AI-model heeft een ander ritme: er komt elk kwartaal iets beters, en aanbieders halen oudere versies na verloop van tijd weg omdat het draaien ervan geld kost.

Dat betekent dat de laag onder uw applicatie sneller beweegt dan de applicatie zelf. Uw software blijft hetzelfde doen, maar het model dat de antwoorden geeft, wordt vervangen door een ander — met andere eigenschappen.

Bij een gewone versie-update verwacht u dat gedrag hetzelfde blijft of beter wordt. Bij een modelwissel is dat niet vanzelfsprekend: nieuwer betekent gemiddeld beter, en niet noodzakelijk beter op precies uw taak.

Het patroon is bij de grote aanbieders inmiddels vergelijkbaar. Er komt een aankondiging, meestal maanden vooraf, met een datum waarop het oude model niet meer beschikbaar is en een aanbeveling voor de opvolger.

Wat daarbij zelden wordt genoemd, is wat er precies anders wordt. U krijgt een naam en een datum, niet een overzicht van gedragsverschillen. Dat overzicht bestaat ook niet echt; het enige dat werkt is het zelf uitproberen op uw eigen gevallen.

Voor u betekent dat: de aankondiging is het startsein voor uw eigen toets, niet voor het overzetten. Wie meteen overzet en daarna kijkt, ontdekt de verschillen bij de gebruiker.

• De toon van antwoorden verschuift, wat opvalt bij alles wat naar klanten gaat.
• Instructies die u zorgvuldig had afgestemd, werken net anders en moeten opnieuw worden getest.
• De vorm van de uitvoer kan wijzigen, wat verwerkende systemen erachter kan laten struikelen.
• Kosten en snelheid veranderen, meestal in uw voordeel maar niet altijd.
• Gedrag in randgevallen verschuift het meest, en dat merkt u het laatst.

De belangrijkste afspraak is een aankondigingstermijn. U wilt weten dat een model wordt uitgefaseerd voordat het gebeurt, met genoeg tijd om te toetsen en aan te passen. Wat redelijk is, hangt af van hoe kritisch de functie is; voor iets dat klanten raakt, denkt u eerder in maanden dan in weken.

Daarnaast wilt u het recht om opnieuw te toetsen voordat een wijziging live gaat, en de mogelijkheid om tijdelijk op de oude versie te blijven terwijl u dat doet. Die overlapperiode is het onderdeel dat het vaakst ontbreekt en dat het meeste rust geeft.

Leg tot slot vast dat aanpassingen die voortvloeien uit een modelwissel binnen het onderhoud vallen. Anders komt de rekening voor werk dat u niet heeft veroorzaakt alsnog bij u terecht.

• Een set voorbeelden met verwachte uitkomsten, die u na elke wijziging opnieuw draait.
• Vastleggen welk model welke versie wanneer werd gebruikt, zodat u een verschil kunt herleiden.
• Weten welke functies in uw software van een model afhangen — dat zijn er vaak meer dan gedacht.
• Een terugvaloptie: wat doet uw applicatie als het model niet beschikbaar is?

De eenvoudigste maatregel is ook de saaiste: zorg dat de plek waar uw software met een model praat, één plek is. Zit die aanroep op veertien plaatsen verspreid, dan is een wissel veertien keer werk en veertien keer risico.

Een tweede maatregel is uw instructies uit de code halen en als configuratie beheren. Dan kunt u ze aanpassen zonder een nieuwe versie uit te brengen, en dat scheelt bij een wissel dagen.

Beide zijn architectuurkeuzes die u het beste bij de bouw maakt. Achteraf zijn ze duurder, en ze staan zelden op een wensenlijst omdat ze voor de gebruiker niets doen. Ze zijn wel het verschil tussen een middag en een sprint.

Van alle maatregelen levert deze het meest op en hij wordt het vaakst overgeslagen. Verzamel twintig tot vijftig realistische gevallen uit uw eigen praktijk, met daarbij wat een goed antwoord zou zijn. Niet perfect geformuleerd, wel inhoudelijk juist.

Die set draait u bij elke wijziging opnieuw. Het punt is niet dat de antwoorden identiek zijn — dat zijn ze nooit — maar dat u ziet of ze nog steeds kloppen. Een verschuiving die u met het blote oog niet opmerkt, valt in zo'n set direct op.

Zorg dat er lastige gevallen in zitten: onvolledige invoer, uitzonderingen, dingen die net buiten het normale vallen. Dat is waar modellen het meest van elkaar verschillen en waar uw gebruikers het eerst tegenaan lopen.

Als uw applicatie zonder het model helemaal stilvalt, is de vraag niet of maar wanneer u daar last van krijgt. Aanbieders hebben storingen, en uw contract met hen is meestal geen garantie op beschikbaarheid.

De terugval hoeft niet even goed te zijn. Een eenvoudiger antwoord, een wachtrij, of een nette melding dat deze functie nu niet beschikbaar is — alles is beter dan een scherm dat blijft draaien.

Voor functies die alleen ondersteunen, is die melding genoeg. Voor functies die in een proces zitten waar mensen op wachten, wilt u een alternatief pad. Dat onderscheid maakt u het beste voordat u de functie bouwt.

Een leverancier die zijn eigen model draait, heeft dit probleem anders dan een die een model van een grote aanbieder gebruikt. In het eerste geval is de continuïteit zijn verantwoordelijkheid; in het tweede geval geeft hij een risico door dat hij zelf ook niet beheerst.

Dat is geen reden om voor het een of het ander te kiezen, wel om te vragen hoe hij ermee omgaat. Een leverancier die kan vertellen welke modellen hij gebruikt, hoe hij een wissel test en wat zijn terugval is, heeft erover nagedacht.

Een leverancier die zegt dat het nooit voorkomt, heeft dat niet. Modellen worden uitgefaseerd, dat is een gegeven van deze markt en niet iets wat met goede wil te vermijden is.

De organisaties die dit goed hebben geregeld, hebben er een tweede voordeel bij gekregen: ze kunnen een nieuw model uitproberen zonder risico. Dezelfde set voorbeelden die u gebruikt om te controleren of het nog werkt, gebruikt u om te zien of iets nieuws beter is.

Dat verandert de modelkeuze van een eenmalige beslissing in iets wat u periodiek herziet. Gezien hoe snel de prijzen dalen en de kwaliteit stijgt, is dat de laatste jaren telkens in uw voordeel geweest.

Het maakt de hele afhankelijkheid daarmee ook minder eng. Niet omdat het risico weg is, maar omdat u er iets tegenover heeft staan dat u zelf beheerst.

• Wat u vraagt aan een AI-leverancier
• De AI Act en uw organisatie
• Het onderhoudscontract

Wilt u eerst weten of het idee werkt voordat u groot investeert? Bij OneDayBuild laat u in één dag een werkend prototype bouwen.