Iedereen bouwt LLMs in zijn workflows. Vraag aan tien teams hoe ze meten of het werkt, en je krijgt tien keer hetzelfde antwoord: "het lijkt te werken."
Dat antwoord is geen meting. En je merkt het pas op het moment dat het niet meer werkt.
De val
Zolang je hetzelfde model gebruikt, op dezelfde prompt, met dezelfde input, lijkt alles stabiel. Maar dat duurt nooit lang. Anthropic releast een nieuwe Claude. OpenAI deprecieert je modelversie. De rekening loopt op en je wilt switchen naar een goedkopere variant. Een teamlid heeft "even de prompt verbeterd." De legal afdeling wil dat je naar een Europees model gaat.
Op dat moment moet je een beslissing maken. Verandert het wat eruit komt? Wordt het beter of slechter? Wat is het effect op je klant?
Zonder data is je antwoord een gok onderbouwd met een paar voorbeelden die je je herinnert. En als die LLM in productie staat met klanten erachter, gok je met meer dan je denkt.
Het saaie antwoord
Dit is geen nieuw probleem. Het is een hele oude, in een nieuwe jas.
LLM-evaluatie is gewoon standaard statistisch werk. Train, test, validatie split. Een gelabelde dataset. Een metriek die past bij je business. Mijn achtergrond in Economics en mijn MSc Data Science komen hier toch wel weer van pas. Andrew Ng schreef hier al jaren over: dezelfde discipline die toen werkte voor classifiers werkt nu voor LLMs.
Wat wel veranderd is: het pluche. LLMs zien er zo magisch uit dat we vergeten dat het modellen zijn. En modellen evalueer je. Hamel Husain noemt evals het belangrijkste dat je voor een AI-product kunt doen, en in de praktijk gaat dat over precies dezelfde dingen: gelabelde voorbeelden, een harness, een metriek, en de discipline om dat consistent door te zetten.
Het nieuws is dus dat het nieuws is.
In de praktijk
Een concreet voorbeeld uit mijn werk. Bij Reg4U bouw ik aan declaratiescan: een classificatiesysteem dat huisartsdossiers analyseert om te bepalen welke medische verrichtingen declarabel zijn bij de zorgverzekeraar.
De input is ruw. Afkortingen die per regio en per huisarts verschillen. Jargon. Halve zinnen. Geanonimiseerde namen. Een notitie van zes woorden waar een heel consult achter zit.
Grote modellen (Claude Opus, GPT-4-class) pakken die nuance vaak goed. Ze hebben genoeg medische context gezien om "BD 140/90" als bloeddrukmeting te lezen, om afkortingen in context te plaatsen, en om de impliciete logica achter een huisartsnotitie te volgen. Kleinere modellen (goedkoper, sneller) kunnen dat soms ook. Maar soms niet. En het verschil zit precies in het soort detail dat je niet opmerkt zonder meting.
Mijn golden dataset is hoe ik dat meet. Het is een set handmatig gelabelde records, input plus de juiste output, vastgelegd door domeinexperts. Voor elk nieuw model, elke prompt-iteratie en elke architectuurwijziging draai ik de hele set door de pipeline en vergelijk de voorspellingen met de labels.
De metriek die ik gebruik is F2, niet F1. Het verschil zit in hoe zwaar je recall meeneemt. Een gemiste declarabele verrichting is verloren omzet voor de klant: geld. Een vals-positieve is extra controlewerk: tijd. Geld weegt zwaarder. F2 maakt die afweging expliciet, en dwingt me om er ook expliciet over te zijn in plaats van impliciet "een beetje van allebei" te willen.
Het echte voordeel komt als je dit combineert met slimme modelkeuze. Denk aan performance marketing. Daar betaal je meer voor zoekwoorden waar je weet dat de ROI groot is, en minder voor zoekwoorden met een kleine kans op conversie. Hetzelfde principe geldt hier. Op een huisartsnotitie waar potentieel een hoge declaratie achter zit, gebruik je gerust een groot, duur model. Op routinegevallen met een lage waarde gebruik je een goedkoper model. Maar zonder eval-harness kun je dat onderscheid niet maken zonder het te raden.
Wat dit oplevert: modelkeuzes worden saai. Nieuwe Claude release? Run de eval, zie het delta, beslis op cijfers. Zonder eval-harness is elke beslissing een onderbuikgevoel onderbouwd met een paar cherry-picked voorbeelden. Met een eval-harness is het een experiment.
De kosten en de valkuilen
Dit is niet gratis. Een goede golden dataset bouwen kost tijd en domeinkennis. Iemand moet labelen, en die iemand moet weten waar hij naar kijkt. In ons geval is dat duur en traag. Maar het alternatief, modellen blind in productie wisselen, is duurder.
Twee dingen om in de gaten te houden.
Goodhart's law geldt ook hier: zodra je een metriek begint te optimaliseren, is de metriek niet meer de werkelijkheid. Je gaat de eval jagen, niet het echte probleem. Het tegenwicht is periodiek de set zelf herzien. Drift erin, scope-veranderingen, edge cases die je miste, nieuwe categorieën die in productie zijn opgedoken. Een eval-set die nooit verandert, is een eval-set die langzaam loskomt van wat je product eigenlijk doet.
En: een golden dataset is geen rotsvast iets. Hij groeit mee met je product. Elke keer dat je in productie iets vindt dat fout ging, is dat een kandidaat-record voor je eval-set. Op die manier wordt je harness scherper naarmate je product ouder wordt, en dat is precies de eigenschap die je wilt.
De échte moat van een LLM-product is niet je prompt. Prompts kopieer je. Modellen zijn voor iedereen beschikbaar. De moat is je eval-set: de gelabelde, domein-specifieke ground truth die niemand anders heeft. Dat is wat je in staat stelt om sneller én met minder risico te bewegen dan je concurrenten.
Of, simpeler: zonder golden dataset is elke modelkeuze een gok.