Hoe je een model kiest — en waarom het antwoord meestal 'meer dan één' is

"Welk model moeten we gebruiken?" is de vraag die we het vaakst krijgen en die het minst bruikbare algemene antwoord heeft, omdat hij de verkeerde vorm heeft. Hij veronderstelt dat een systeem één model gebruikt.

Vrijwel geen goed gebouwd productiesysteem doet dat.

De framing die wél werkt: routeer per stap

Een supportsysteem bevat stappen met radicaal verschillende moeilijkheidsgraad:

Stap	Moeilijkheid	Volume	Modelklasse
Taal detecteren	Triviaal	Elk bericht	Kleinste
Intentie indelen in 12 categorieën	Makkelijk, smal	Elk bericht	Klein
Ordernummer uit vrije tekst halen	Makkelijk	Meeste berichten	Klein
Sentiment / escalatierisico bepalen	Middel, hoge inzet	Elk bericht	Klein–midden, zwaar geëvalueerd
Relevant beleid ophalen en rangschikken	Middel	Meeste berichten	Midden
Het klantantwoord schrijven	Vraagt oordeel	Meeste berichten	Midden–top
Beslissen over een dubbelzinnig retourverzoek	Hoge inzet, oordeel	~8%	Top
Een storing over meerdere systemen uitzoeken	Langlopend, agentisch	Zelden	Top, hoge diepte

Dat allemaal op je beste model draaien betekent topprijzen betalen om te detecteren dat een bericht Nederlands is.

Routeren per stap is geen compromis. Op de smalle taken is het vaak nauwkeuriger, omdat een taak met een vaste labelruimte en duizenden dagelijkse voorbeelden er een is waarvoor je een echte eval-set kunt bouwen en waarop je echt kunt tunen.

De drie klassen, functioneel

Even los van merknamen en versienummers vallen huidige modellen uiteen in drie praktische banden.

Klein / snel. Classificatie, extractie, routering, opmaak, simpele transformaties. Latency onder de seconde, ruwweg een orde van grootte goedkoper per token dan topmodellen. Zet ze in waar de taak smal en meetbaar is. Kun je de outputruimte precies definiëren, begin dan hier en klim alleen op als evals dat afdwingen.

Midden. Het werkpaard. Het meeste generatiewerk, het meeste retrieval-verankerde antwoorden, het meeste tool-gebruik. Recente middenklassemodellen hebben veel van het gat met topmodellen gedicht, specifiek op coderen en agentisch werk. Voor een groot deel van je productieverkeer is dit de juiste standaard, en hier beginnen in plaats van bovenaan is meestal het betere instinct.

Top. Diep redeneren, langlopend autonoom werk, complexe engineering over meerdere bestanden, en alles waar fout zijn duur is. Ook de juiste keuze voor echt moeilijke eenmalige taken waar de kosten van de aanroep verwaarloosbaar zijn naast de kosten van een slecht resultaat.

De praktische regel: begin in het midden, meet, klim alleen op waar evals dat eisen en daal overal waar ze het toestaan.

De tweede knop: redeneerdiepte

Deze is nieuwer, minder begrepen, en vaak een grotere hefboom dan de modelkeuze zelf.

Huidige topmodellen bieden een instelling voor hoeveel deliberatie in een antwoord gaat — hoe diep ze denken, hoeveel tool-aanroepen ze doen, hoeveel ze verifiëren. Hoger betekent betere resultaten op moeilijke problemen en substantieel meer tokens en latency. Lager betekent sneller, korter en letterlijker uitvoeren, strak binnen wat gevraagd is.

Drie dingen zijn het weten waard:

De relatie met kosten is niet monotoon. Op langlopend agentisch werk verlaagt hogere diepte vaak de totale kosten — betere planning betekent minder beurten, minder verkeerde paden, minder overdoen. Op korte interactieve taken is lagere diepte gewoon goedkoper. Je moet het per workload meten.

Lage standen zijn sterker dan mensen verwachten op huidige modellen. Een topmodel op lage diepte presteert vaak beter dan een vorige generatie op maximum. Heb je een workload gemigreerd en de oude instelling behouden, dan betaal je waarschijnlijk te veel.

Het is geen breedsprakigheidsknop. Teams grijpen naar lagere diepte om kortere antwoorden te krijgen en zijn verrast als dat niet werkt. Antwoordlengte is een promptvraagstuk; diepte stuurt deliberatie. Gebruik de juiste knop.

Sweep het bereik op je eigen eval-set. Standaardwaarden zijn afgestemd op een algemene populatie, niet op jouw workload.

Selectiecriteria die er echt toe doen

Taakspecifieke nauwkeurigheid, gemeten op jouw data. Publieke benchmarks vertellen je iets over publieke benchmarks. Een model dat een ranglijst aanvoert, kan slechter zijn dan een klein model op jouw specifieke classificatietaak met jouw specifieke labels. Twintig van je eigen voorbeelden verslaan elke ranglijst.

Latencybudget. Interactieve chat heeft eerste tokens binnen twee seconden nodig. Een nachtelijke batchjob niet. Betaal niet voor snelheid in een cronjob, en bouw geen interactieve functie op een model waarvan de denkfase minuten duurt.

Contextvenster versus wat je echt nodig hebt. Enorme vensters zijn nuttig en vaak een kruk. Moet je een miljoen tokens sturen om een vraag te beantwoorden, dan is je retrieval kapot en doet het model het zoekwerk voor je — duur en minder nauwkeurig.

Ondersteuning voor gestructureerde output. Heb je gegarandeerde schemanaleving nodig, controleer dan of het model die afdwingt en niet alleen meestal volgt. Dat telt zwaarder voor pipelinebetrouwbaarheid dan een paar punten benchmarkscore.

Kwaliteit van tool-gebruik. Voor agents is dit de onderscheidende factor — niet rauw redeneren, maar of het model de juiste tool met de juiste argumenten aanroept en weet wanneer hij er geen moet aanroepen. Modellen verschillen hier flink en dat verschil komt niet terug in algemene benchmarks. Let ook op hoe gretig modellen naar tools grijpen; een systeem dat is afgestemd op de terughoudendheid van het ene model, overtriggert op een gretiger model, en andersom.

Uitrolbeperkingen. Dataresidentie, on-premise-eisen, inkoopgoedkeuring, bestaande cloudverplichtingen. Die beslissen de vraag vaak vóórdat welk technisch criterium dan ook een stem krijgt. Zoek dat vroeg uit.

De wisselkosten die niemand meerekent

Modelmigratie is zelden een stringwijziging, en teams begroten hem structureel te laag.

Prompts gaan niet schoon over. Een prompt afgestemd op de neigingen van het ene model wordt een mis-afstemming op het andere. Agressieve tool-taal geschreven om een terughoudend model te overwinnen, levert overtriggeren op bij een gretig model. Breedsprakigheidsinstructies om een kort model te compenseren, overcorrigeren op een warmer model. Verificatiesteigers die een zwakker model hielpen, leveren overbodige lussen op bij een model dat zichzelf verifieert.

Tokenaantallen veranderen. Verschillende modellen tokeniseren verschillend — dezelfde tekst kan op het ene 30% meer tokens zijn dan op het andere. Dat verschuift je contextbudgetten, je max_tokens-limieten en je kostenbasislijn, zelfs als de prijs per token identiek is. Meet opnieuw met de tokenteller van het doelmodel in plaats van oude getallen te hergebruiken.

Standaardwaarden verschuiven stilletjes. Of redeneren standaard aanstaat, of redeneertekst wordt teruggegeven, wat de standaard-diepte is — die zijn tussen generaties veranderd, zonder foutmelding. Een workload die door weglating zonder redeneren draaide, kan na een versiesprong gaan redeneren, tokens verbruiken en mogelijk afkappen tegen een max_tokens die op het oude gedrag was afgestemd.

Caches zijn modelspecifiek. Wisselen maakt elke warme prefix ongeldig. De eerste verzoeken op het nieuwe model betalen de volle prijs.

API-oppervlakken evolueren. Parameters verdwijnen tussen generaties. Sampling-instellingen, vaste denkbudgetten, response-prefills — die zijn op recente topmodellen allemaal afgeschaft of verwijderd, en geven fouten in plaats van waarschuwingen.

De praktische verdediging: een eval-set die tegen elk model draait. Met zo'n set is migratie een middag: draai de suite op de kandidaat, vergelijk per geval, tune wat verslechterde. Zonder zo'n set is het een maand op gevoel.

Een standaardarchitectuur

Wil je een startpunt in plaats van een denkkader:

1. Klein, snel model voor classificatie, routering, extractie, taaldetectie, en elke smalle taak met een vaste outputruimte.
2. Middenklassemodel als standaard voor generatie en tool-gebruik, op gematigde redeneerdiepte.
3. Topmodel voor het escalatiepad, dubbelzinnige oordelen en langlopende agentische runs, op hogere diepte.
4. Een abstractie dun genoeg om te wisselen — één interface, modelconfiguratie per stap, geen provider-SDK-aanroepen verspreid door je businesslogica.
5. Een eval-set per stap, zodat je weet welke kant je elke stap op moet bewegen.

Meet vervolgens, en laat de getallen elke stap omhoog of omlaag duwen. Dat is de hele methode — en het is het deel dat de volgende modelrelease overleeft, wat je van geen enkele specifieke aanbeveling kunt zeggen.

---

Wij benchmarken per stap op klantdata en herhalen dat elk kwartaal — je zit nooit vast aan één provider. Plan een auditgesprek.