Jaarlijks Betaal jaarlijks en krijg 2 maanden gratis bij elk betaald abonnement. Bekijk abonnementen
Aanmelden Gratis beginnen

Waarom één model nooit genoeg is

De val van het enkele model Elke grote AI-aanbieder wil dat je gelooft dat zijn topmodel het juiste antwoord is op elke vraag. Dat geloof is commercieel gerieflijk voor hem en technisch onjuist voor jou. Een model dat ui…

De val van het enkele model

Elke grote AI-aanbieder wil dat je gelooft dat zijn topmodel het juiste antwoord is op elke vraag. Dat geloof is commercieel gerieflijk voor hem en technisch onjuist voor jou.

Een model dat uitblinkt in juridisch redeneren met lange context is niet het juiste om een onderschrift van tien woorden te maken. Een model met zicht op het hoogste niveau is overdreven — en waarschijnlijk te duur — voor een batchtaak die gestructureerde JSON herformatteert. Een model waarvan de prijs op doorvoer is geoptimaliseerd, kan de slechtst denkbare keuze zijn wanneer je binnen twee seconden een antwoord nodig hebt.

Wanneer je op één model bouwt, kies je niet het beste gereedschap. Je kiest het beste beschikbare gereedschap binnen een kunstmatige beperking. Na verloop van tijd stapelt die beperking zich op: je betaalt te veel voor eenvoudige taken, je schiet tekort bij complexe, en wanneer die aanbieder een storing of een prijsverhoging heeft, staat je hele product stil.

Capaciteiten, geen namen

De bruikbare abstractie is niet «welk model», maar «welke capaciteiten heeft dit verzoek nodig». Die vraag heeft een precies antwoord.

Een chatbericht met een bijgevoegde schermafbeelding heeft zicht nodig. Een workflowstap die een externe API aanroept, heeft gereedschappen nodig. Een codeassistent die zijn eigen uitvoer moet verifiëren, heeft code-uitvoering nodig. Een nachtelijke samenvattingspijplijn die niet snel hoeft te zijn, kan batchprijzen gebruiken; een assistent in het product waar iemand op wacht, niet.

Wanneer je eerst de capaciteitseisen opsomt, wordt modelkeuze een filter-en-sorteervraagstuk. Gegeven een vereiste verzameling — zeg tekst, zicht en gestructureerde uitvoer — vind je alle modellen die alle drie ondersteunen en sorteer je ze vervolgens op kwaliteit en prijs voor de huidige verzoekcontext. Die sortering kan per verzoek verschillen, afhankelijk van wat iemand doet en hoe het met de middelen staat.

Dit is precies wat de routeringspijplijn van ToRun doet. De modus (Chat, Code, Beeld, Onderzoek en andere) beeldt af op een verzameling capaciteiten. De verzameling filtert de modelcatalogus. De rangschikking op prijs en kwaliteit kiest de winnaar. Het resultaat is dat je DeepSeek kunt gebruiken voor gestructureerde extractie op groot volume, Claude of modellen van de GPT-4-klasse voor genuanceerd redeneren, Google Gemini voor documentwerk met lange context en een gespecialiseerd beeldmodel voor generatie — allemaal vanaf hetzelfde productoppervlak, zonder zelf verdeellogica te schrijven.

Terugval is geen leuke extra

Storingen bij aanbieders zijn geen zeldzame randgevallen. Ze komen in de hele sector meerdere keren per maand voor. Heeft je product één aanbiedersafhankelijkheid en verslechtert diens API, dan verslechtert je product mee.

Een terugvalketen is het operationele minimum: geeft het primaire model voor een verzoek een tijdelijke fout terug, dan probeert het platform het opnieuw met het volgende beste geschikte model. Dat veronderstelt dat de routeringslaag al weet welke modellen geschikt zijn — precies wat capaciteitsgerichte routering levert.

Terugval heeft nog een minder voor de hand liggend voordeel: het houdt je factureringsgedrag voorspelbaar. Zit het eerstekeuzemodel tijdelijk boven een gebruikslimiet, dan houdt uitwijken naar het volgende geschikte model de kosten binnen bereik zonder dat er een fout aan de gebruiker wordt getoond.

De praktische conclusie

Stel bij het beoordelen van AI-platformen twee vragen: hoe kiest het een model voor elk verzoek, en wat gebeurt er wanneer dat model niet beschikbaar of te duur is?

Is het antwoord op een van beide «het gebruikt altijd model X», dan is dat een architectuurgeur. De modellen die vandaag beschikbaar zijn, zijn niet de beste modellen die er over zes maanden zullen zijn. Nieuwe aanbieders verschijnen. Prijzen verschuiven. Capaciteitsgrenzen veranderen. Een architectuur die modelkeuze als een routeringsvraagstuk behandelt — niet als een configuratiebesluit — veroudert beter, kost op termijn minder en verslechtert eleganter onder druk.

Eén model is een startpunt. Een routeringslaag is het echte fundament.

Delen LinkedIn X E-mail
Probeer het op je eigen werkElk antwoord laat zien wat het kostte. Begin met het gratis abonnement. Gratis beginnen
Krijg productupdates, geen ruis Nieuwe modellen, functies en changelog-hoogtepunten - een korte mail wanneer er echt iets live gaat.
Door je in te schrijven ga je ermee akkoord e-mails van ToRun over productupdates te ontvangen. Je kunt je op elk moment uitschrijven. Privacybeleid