Een AI-model vervangen en in hetzelfde proces toetsen

Onderzoek bij een modelwissel de volledige betrokken workflow. Een nieuwe modelaanduiding in de configuratie is op zichzelf onvoldoende bewijs. Gebruik een bestaande evaluatieset en leg vast welke wijziging u daadwerkelijk vergelijkt.

Beide configuraties duidelijk vastleggen

Documenteer modelaanduiding, promptversie, aangeboden bronnen, tools en instellingen van beide varianten. Als invoer, regels en verwerking gelijk blijven, kunt u de modelwissel gerichter onderzoeken. Moet u ook prompt, adapter of beoordeling wijzigen, dan vergelijkt u twee applicatieconfiguraties; schrijf het verschil niet alleen aan het model toe.

Microsoft beschrijft het vergelijken van opgeslagen varianten met dezelfde gevallen en het bekijken van afzonderlijke fouten. De verwachte inhoudelijke beslissingen voor uw workflow moeten vóór de vergelijking vaststaan.

Verschillen per geval zichtbaar maken

Het volgende voorbeeld is volledig fictief. Een applicatie moet een projectcode uit een bericht halen of handmatige controle vragen. Ze verleent geen projecttoegang. De veldnamen zijn ons eigen interne schema, geen API van een aanbieder.

De tabel bevat veronderstelde uitvoer ter toelichting. Het is geen uitgevoerde modeltest. De gevalsbeschrijvingen vervangen niet de originele invoer met versiebeheer van een echte vergelijking.

In het tweede geval kiest de nieuwe variant ondanks onduidelijkheid een project. In het derde schendt ze het veldcontract. Een samengevoegde beoordeling kan die verschillende foutoorzaken verbergen. Formeel geldige uitvoer moet ook inhoudelijk kloppen.

Fouten vóór verdere verwerking afhandelen

OWASP adviseert modeluitvoer te valideren voordat deze naar achterliggende componenten gaat. In het voorbeeld mag een ontbrekend verplicht veld niet als geslaagde extractie verdergaan. De applicatie moet de uitvoer afwijzen of naar het bedoelde controlepad leiden. Een aanwezig projectveld verleent nog steeds geen toegangsrecht.

Controleer naast inhoud en formaat ook werkelijk benodigde talen, uitval en herhalingen. Eén uitvoering toont geen stabiele foutfrequentie. Worden bekende fouten gebruikt om de nieuwe variant aan te passen, dan zijn extra achtergehouden gevallen nodig voor een onafhankelijke controle.

Vrijgave en terugkeer samen plannen

Bepaal vóór vrijgave welke fouten de overstap verhinderen en wie openstaande verschillen beoordeelt. In het tabelvoorbeeld moeten eerst de overhaaste projectkeuze op basis van een onduidelijk bericht en het ontbrekende verplichte veld worden opgelost.

Bewaar de vorige applicatieconfiguratie en een gecontroleerd terugkeerpad. Verduidelijk ook of het vorige model beschikbaar blijft en de opgeslagen gegevens compatibel blijven. Volg na de overstap de werkelijke resultaten van de betrokken workflow; drie illustratieve gevallen bewijzen geen algemene productierijpheid.

Bronnen

• Microsoft — Evaluate models, prompts, and agents

• OWASP 2025 — Improper Output Handling