Een extra AI-model kan een applicatie goedkoper maken.
Als een gespecialiseerd model voldoende werk overneemt van een duurder taalmodel, dalen de totale kosten. Ook de snelheid gaat flink omhoog: in onze proef reageerde Jev in 0,32 seconde, tegenover 2,44 seconden voor de geteste LLM.
Dat principe onderzoeken we tijdens de ontwikkeling van onze nieuwe applicatie. Sommige onderdelen gebruiken AI voor veel terugkerende beoordelingen. Per beoordeling zijn de kosten klein, maar bij duizenden aanvragen tellen zowel de kosten als de verwerkingstijd op.
De mogelijke winst zit in de verdeling van het werk. Een gespecialiseerd model handelt afgebakende vragen af. Een uitgebreider taalmodel blijft beschikbaar voor gevallen die meer interpretatie nodig hebben. Hoeveel voordeel dat oplevert, hangt vooral af van hoeveel werk de eerste stap zelfstandig kan verwerken.
En van de kwaliteit. Een goedkopere beoordeling levert weinig op als iemand daarna extra tijd kwijt is aan het herstellen van fouten.
Een ander model voor terugkerend werk
De introductie van Jev van TypeSafe was voor ons aanleiding om dit te testen. Jev is een beslismodel: het ontvangt context en gerichte vragen, en retourneert keuzes, scores en waarschijnlijkheden.
Het interpreteert nog steeds taal, maar hoeft geen vrije tekst te genereren om een beoordeling terug te geven. Voor software die vooral een categorie of score nodig heeft, kan dat een efficiënte aanpak zijn.
Inmiddels zijn er meerdere kandidaten, waaronder Clef van Cloudflare. We wilden daarom verschillende opties naast elkaar zetten en onderzoeken hoe ze zich gedragen bij onze eigen voorbeelden.
Proef op de som
We begonnen met één onderdeel van de applicatie. We lieten 48 praktijkvoorbeelden tweemaal beoordelen door Jev, Clef Flash en Claude Haiku met een variant van onze bestaande prompt. In totaal waren dat 288 modelaanroepen.
De proef draaide los van de bestaande verwerking. We verzamelden de antwoorden voor vergelijking; er werden geen wijzigingen toegepast.
Dit waren de gemeten snelheid en geschatte API-kosten:
| Model | Mediane responstijd | Geschatte API-kosten per 1.000 aanroepen |
|---|---|---|
| Jev 1.13.0 | 0,32 seconde | $0,20 |
| Clef Flash | 0,68 seconde | $0,40 |
| Haiku 4.5 met onze promptvariant | 2,44 seconden | $3,56 |
Gemeten op 3 oktober 2026. Kosten zijn omgerekend vanuit het gerapporteerde verbruik en de geldende tarieven. Alle antwoorden tellen mee, ook antwoorden die onze controle afwees.
Jev was in deze proef de snelste en goedkoopste kandidaat. Wel leverden de modellen verschillende uitvoer: de beslismodellen beantwoordden classificatievragen, terwijl de LLM een uitgebreider voorstel met tekst produceerde. Deze cijfers vergelijken de afzonderlijke aanroepen binnen onze testopzet. Ze tonen nog geen besparing op de complete werkwijze.
De rekensom van de combinatie
Voor de businesscase is vooral interessant wat er gebeurt wanneer we die modellen combineren.
Stel dat we de modellen zo combineren:
Jev beoordeelt
Ieder geval wordt eerst door Jev beoordeeld.
De applicatie controleert
Is er voldoende informatie, passen de antwoorden bij elkaar en is verdere beoordeling nodig?
De LLM waar nodig
Alleen een deel gaat daarna nog naar de LLM.
Met onze gemeten kosten geeft dat de volgende rekenvoorbeelden:
| Werkwijze voor 1.000 gevallen | Geschatte API-kosten |
|---|---|
| Alles met de geteste LLM-variant | $3,56 |
| Alles eerst via Jev; 50% vervolgens naar de LLM | $1,98 |
| Alles eerst via Jev; 25% vervolgens naar de LLM | $1,09 |
De extra Jev-aanroepen verdienen zichzelf in deze scenario's terug doordat er minder LLM-aanroepen nodig zijn. Gaat alles alsnog naar de LLM, dan stijgen de kosten juist naar ongeveer $3,76. Voor doorgestuurde gevallen komt bovendien de verwerkingstijd van de eerste stap erbij.
Een extra model kan de totale kosten verlagen als het voldoende werk bij het duurdere model wegneemt.
Deze scenario's zijn nog geen gemeten besparing. We nemen aan dat een LLM-vervolgbeoordeling evenveel kost als in onze proef. Menselijke controle, infrastructuur en eventuele herbeoordelingen zijn niet meegerekend. Ook andere prompts en het bundelen of hergebruiken van aanvragen kunnen de verhouding veranderen.
Wat we meenemen naar de volgende proef
De eerste proef leverde ook concrete lessen op voor de inrichting van onze applicatie:
Vaste regels blijven in de software.
Een model herkende informatie soms correct, maar volgde vervolgens de bijbehorende bedrijfsregel onvoldoende.
Ieder onderdeel krijgt een duidelijke taak.
Het beslismodel classificeert, de software past regels toe en een LLM of mens behandelt onduidelijke of complexere gevallen.
Uitleg kan vaak via templates.
Vastgestelde feiten en beoordelingen vormen samen een begrijpelijk voorstel. De gebruiker houdt de uiteindelijke goedkeuring.
Antwoorden moeten bruikbaar zijn.
Onze controle wees 30 van de 96 Haiku-antwoorden af vanwege de antwoordstructuur. Dat zijn geen 30 bewezen inhoudelijke fouten, maar wel aanleiding om de aansluiting te verbeteren.
Het model blijft verwisselbaar.
We gebruiken vaste vragen en antwoordstructuren, zodat nieuwe kandidaten dezelfde test kunnen doorlopen. Een overstap vraagt opnieuw testen en afstellen.
De volgende proef omvat 300–1.000 menselijk beoordeelde voorbeelden, met een apart gehouden eindtest. Daarmee vergelijken we de volledige werkwijze op kwaliteit, kosten, snelheid en benodigde correcties. De huidige proef bevat nog te weinig gecontroleerde antwoorden om een betrouwbare kwaliteitswinnaar aan te wijzen.
Hoeveel werk zonder LLM kan worden afgehandeld, hebben we nog niet vastgesteld. Door ontbrekende bevestigde context bleven alle beslismodeluitkomsten in deze proef op aanvullende menselijke beoordeling staan. De volgende stap is meten hoeveel van de snelheids- en kostenwinst we met behoud van kwaliteit kunnen benutten.
Wie de ontwikkelingen wil volgen, kan terecht bij de communitybenchmark Decision Index op Hugging Face. Een Rubik's Cube-demo waarin verschillende typen modellen naast elkaar worden gezet, is daarnaast een leuke illustratie bij de discussie over taakverdeling. Het nut van de combinatie toetsen we met onze eigen praktijkvoorbeelden.
Werk je aan een applicatie met veel terugkerende AI-beoordelingen?
We denken graag mee over een praktische proef om snelheid, kosten en kwaliteit samen te vergelijken.
