De meeste apps kiezen één model, zetten de naam ergens in de code en komen daar nooit meer op terug. Dat werkt tot het model duurder wordt, verdwijnt of voor jouw taak wordt ingehaald. Inmiddels bieden platforms als Snowflake automatische modelkeuze per vraag aan. Hieronder hoe je die keuze zelf maakt, en waarom de belangrijkste beslissing niet gaat over welk model maar over hoe je hem kunt wisselen.
Wat je vandaag kiest is over een halfjaar achterhaald. Wat blijft is de manier waarop je het hebt aangesloten.
Modellen verschuiven sneller dan welk ander onderdeel van je stack. Een model dat vandaag het beste presteert op jouw taak, is over twee kwartalen ingehaald, duurder geworden of vervangen door een opvolger met andere eigenschappen. Wie de naam van het model op vijftien plekken in de code heeft staan, betaalt dat elke keer.
De eerste beslissing is daarom structureel: zet één laag tussen je applicatie en de aanbieder, waarin je per functie vastlegt welk model je gebruikt en met welke instructie. Alle aanroepen gaan door die laag. Wisselen wordt dan een configuratiewijziging in plaats van een zoek-en-vervangactie, en je kunt twee modellen naast elkaar draaien om te vergelijken.
Die laag is ook de plek waar je meet. Leg per aanroep vast welk model het was, hoe lang het duurde, hoeveel het kostte en of het antwoord bruikbaar was. Zonder die cijfers is elke discussie over modelkeuze een smaakdiscussie, en dat is precies waar de meeste teams in blijven hangen.
De taken in een app stellen tegengestelde eisen. Eén keuze voor alles betekent dat je overal een compromis sluit.
Classificeren, labelen, korte samenvattingen, een veld invullen. Hier telt reactietijd en kosten per aanroep, en is het verschil in kwaliteit tussen een klein en een groot model klein. Dit is waar de meeste apps geld verspillen door standaard het zwaarste model te gebruiken.
Langere teksten, meerstapsredeneringen, code, analyses waar de gebruiker op vertrouwt. Hier loont een groter model, want de fout die een klein model maakt kost je meer dan het prijsverschil. Vaak is dit maar een klein deel van je aanroepen.
Voor agents die functies aanroepen telt vooral hoe betrouwbaar het model zich aan een schema houdt en hoe het omgaat met een mislukte aanroep. Dat is een andere eigenschap dan taalvaardigheid, en modellen die goed schrijven zijn hier niet automatisch goed in. Test dit apart.
Automatisch het beste model kiezen klinkt aantrekkelijk, maar er zit een addertje onder.
Routing betekent dat niet jij maar het systeem per vraag bepaalt welk model wordt gebruikt: simpele vragen naar een klein model, moeilijke naar een groot. Bij veel volume en veel variatie in de vragen levert dat echt iets op, want het overgrote deel van de vragen is simpeler dan waar je het zware model voor nodig hebt.
Het addertje is voorspelbaarheid. Als dezelfde vraag vandaag door model A en morgen door model B wordt beantwoord, verandert de toon, de lengte en soms de conclusie. Voor een klantgerichte functie waar mensen op vertrouwen is dat vervelend, en voor iets dat door een ander systeem wordt uitgelezen kan het ronduit breken. Route je, doe dat dan per functie en niet over de hele app.
De eenvoudigste vorm die bijna altijd loont, is de omgekeerde: begin met het goedkope model en escaleer alleen als het resultaat niet voldoet aan een controle die je zelf uitvoert. Dat is voorspelbaarder dan een router die zelf inschat hoe moeilijk een vraag is, en je ziet in je eigen cijfers hoe vaak er wordt geëscaleerd. Wat de zware functies je uiteindelijk kosten, staat in wat kosten de AI-functies in je app.
Ongeacht welk model je kiest, dit is het minimum dat je nu regelt en niet later.
Die vraag is minder nuttig dan hij lijkt, omdat het antwoord per functie verschilt en binnen een halfjaar verandert. Nuttiger is de vraag hoe snel je kunt wisselen. Zet de modelkeuze per functie in configuratie in plaats van in je code, meet wat elke aanroep kost en oplevert, en de keuze zelf wordt een kwestie van vergelijken.
Dat kan, en voor een prototype is het vaak verstandig om niet meteen te optimaliseren. Zodra je volume krijgt, betaal je er wel voor: de meeste aanroepen in een app zijn eenvoudige taken die geen zwaar model nodig hebben. Het verschil tussen een klein en een groot model is daar in kwaliteit klein en in kosten groot.
Routing betekent dat het systeem per vraag bepaalt welk model wordt gebruikt, meestal om eenvoudige vragen goedkoop af te handelen en moeilijke naar een zwaarder model te sturen. Platforms bieden dit inmiddels als dienst aan. Het levert het meest op bij veel volume en veel variatie in de vragen.
Voorspelbaarheid. Als dezelfde vraag de ene keer door een klein en de andere keer door een groot model wordt beantwoord, verschilt de toon, de lengte en soms de conclusie. Voor klantgerichte functies is dat storend en voor uitvoer die door een ander systeem wordt gelezen kan het breken. Zet routing daarom per functie aan, niet over je hele app.
Ja, en eerder dan de meeste mensen doen. Storingen bij modelaanbieders komen voor, en zonder terugvaloptie staat je hele functie stil. Draai je alles al door één configuratielaag, dan is een tweede aanbieder toevoegen een kwestie van uren, mits je instructies niet te veel op één model zijn toegesneden.
Met een vaste set van twintig tot vijftig echte vragen uit je eigen app, met per vraag wat je een goed antwoord vindt. Draai die set door beide modellen en vergelijk. Dat kost je een uur en levert een onderbouwd oordeel op, terwijl vergelijken op gevoel altijd uitkomt bij het model waar iemand toevallig enthousiast over is.
Zeker. Bij agents telt vooral of een model zich betrouwbaar aan je schema houdt en fatsoenlijk omgaat met een mislukte aanroep. Dat is een andere eigenschap dan mooi schrijven, en een model dat goed schrijft is hier niet automatisch goed in. Test die functie apart van je tekstfuncties.
Voor de meeste apps niet. Zelf hosten wordt pas interessant bij grote, voorspelbare volumes, harde eisen over waar de gegevens staan, of een taak waarvoor je een eigen model traint. Voor alles daaronder is de rekensom vrijwel altijd in het voordeel van een aanbieder aanroepen.
Stuur ons je idee. Wij kijken in een intake mee welke flow je wilt testen en leveren in één werkdag een klikbaar prototype, met de juiste tools voor jouw geval.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.