LLM-applicaties evalueren: een praktische gids

LLM-evaluatie is hoe je erachter komt of een wijziging aan je taalmodel-functie die echt beter maakte — of stiekem slechter. Pas je prompts aan, wissel je van model of voeg je een tool toe, en beoordeel je het resultaat door een paar uitvoer met het oog te bekijken, dan evalueer je niet; je gokt. Deze gids laat zien hoe je een praktische evaluatieharnas voor LLM-applicaties bouwt: taakspecifieke metrieken, offline evals, LLM-as-judge gebruiken zonder je te laten misleiden, evals als regressietests in je CI, en je wapenen tegen de prompt- en modeldrift die systemen in stilte laat verslechteren.

Een korte afbakening. Is je systeem retrieval-augmented, dan heeft de retrieval-helft eigen metrieken nodig — recall@k, faithfulness, context-precisie — die we uitgebreid behandelen in onze gids over RAG-evaluatie en retrieval-kwaliteit. Dit stuk gaat over het bredere probleem: elke LLM-aangedreven functie evalueren, met of zonder RAG, als software die je in productie moet kunnen vertrouwen.

Waarom "het lijkt beter" geen evaluatie is

LLM's zijn niet-deterministisch. Stel dezelfde vraag twee keer en je krijgt twee verschillende antwoorden, beide aannemelijk. Dat ene feit breekt de manier waarop engineers software normaal verifiëren. Je kunt het niet één keer draaien, een goede uitvoer zien en concluderen dat het werkt — de volgende gebruiker, de volgende formulering of de volgende modelupdate levert iets heel anders op. En mensen zijn slecht in eerlijk steekproeven: we onthouden de demo die verbluffte en vergeten de drie die floppten.

Dus "het lijkt beter na mijn wijziging" is geen bevinding. Het is een gevoel. Echte evaluatie vervangt dat gevoel door een herhaalbare meting: een vaste set invoer, een gedefinieerd begrip van een goede uitvoer, en een score die meebeweegt met de kwaliteit. Zonder dat is elke prompt-wijziging een muntworp waarvan je de uitkomst niet ziet, en elke model-upgrade een sprong in het duister. Dat is de discipline achter elke LLM-optimalisatie die we doen — je finetunet niet wat je niet meet.

Begin bij de taak, niet bij de metriek

Er bestaat geen enkele "LLM-score". Wat goed is, hangt volledig af van wat de functie doet, dus de eerste taak is de taak benoemen en daaruit de metrieken afleiden. De meeste LLM-functies vallen in een handvol vormen, elk met een eigen manier om gemeten te worden.

Classificatie en routering

Sorteert het model invoer in categorieën — intentieherkenning, ticketroutering, sentiment, moderatie — dan zit je in klassiek machine-learning-terrein en gelden de klassieke metrieken. Accuracy, precision, recall en een confusion matrix vertellen precies waar het misgaat: welke categorieën in elkaar overlopen. Ze zijn goedkoop te berekenen en laten weinig ruimte voor discussie, dus bouw ze eerst waar je functie discrete juiste antwoorden heeft.

Extractie en gestructureerde uitvoer

Haalt het model velden uit tekst of levert het JSON, evalueer dan op veldniveau. Parseert de uitvoer überhaupt tegen het verwachte schema? Komt per veld de geëxtraheerde waarde overeen met de goudwaarde, exact of binnen een tolerantie? Schema-validiteit en accuratesse per veld vangen de fout die één totaalscore verbergt — een antwoord dat klopt maar stilletjes één veld op de twintig laat vallen.

Samenvatten en open generatie

Dit is het lastige geval, want er is geen enkel juist antwoord. Hier leun je op faithfulness (verzint de samenvatting iets dat niet in de bron staat?), relevantie (dekt ze wat ertoe doet?), en rubric-scoring tegen expliciete criteria die je zelf bepaalt — toon, volledigheid, formaat. Referentie-gebaseerde stringmetrieken als BLEU of ROUGE zijn zwakke proxy's voor open generatie; een consequent beoordeelde criteria-rubric is veel informatiever.

Agents en tool-gebruik

Voor alles dat acties onderneemt — tools aanroepen, API's bevragen, meerstaps-plannen uitvoeren — is de metriek die telt taaksucces: bereikte het het doel? Daaronder meet je correctheid per stap en tool-call-accuratesse (koos het de juiste tool met de juiste argumenten?). Een agent kan een vloeiend slotbericht produceren terwijl het drie stappen eerder een verkeerde actie nam, dus evalueer het traject, niet alleen de laatste zin.

De evaluatieharnas bouwen

Een evalharnas heeft drie delen, en geen ervan is exotisch. Eén: een dataset — een set invoer gekoppeld aan de verwachte uitvoer of de criteria voor een goede. Twee: een of meer metrieken passend bij de taak. Drie: een runner die elke invoer door de huidige versie van je systeem voert, de uitvoer scoort en het totaal rapporteert. Draaien, iets veranderen, opnieuw draaien, vergelijken. Die lus is het hele spel.

Je hoeft de runner niet vanaf nul te bouwen. Open frameworks als OpenAI Evals en de lm-evaluation-harness van EleutherAI geven je herbruikbare templates, consistente scoringsprotocollen en model-graded judging kant-en-klaar, zodat je snel een taakspecifieke eval opzet en resultaten vergelijkbaar houdt over runs heen. In de dataset zit je echte werk: put uit werkelijk gebruik, dek de lastige en dubbelzinnige gevallen bewust af, en houd hem geversioneerd zodat de score van vandaag vergelijkbaar is met die van vorige maand. Vijftig goedgekozen voorbeelden verslaan vijfhonderd luie — hetzelfde principe dat een goede RAG-testset stuurt, geldt voor elke LLM-taak.

LLM-as-judge, met beleid gebruikt

Voor open taken kun je uitvoer vaak niet met een simpele stringvergelijking scoren, dus vraag je een ander model ze te beoordelen — het LLM-as-judge-patroon. Het is oprecht nuttig en het schaalt, maar het is een instrument dat kalibratie nodig heeft, geen orakel. Jury's prefereren vaak langere antwoorden, kunnen de stijl van hun eigen modelfamilie bevoordelen, en schuiven als je het jurymodel of de prompt verandert. We gaan hier dieper op in in de RAG-evaluatiegids; de korte regel voor elke LLM-app is dezelfde — toets de jury periodiek aan menselijke beoordelingen op een steekproef, rapporteer scores als trends in plaats van als absolute waarheid, en laat nooit één automatisch getal alleen een release bewaken.

Maak van evals regressietests

Hier houdt LLM-evaluatie op onderzoek te zijn en wordt het engineering. Een eval die je één keer met de hand draait, is interessant; een eval die automatisch bij elke wijziging draait, is een vangnet. Koppel je evalsuite aan CI zodat een pull request die een prompt, een modelkeuze of een tool-definitie raakt, de evals opnieuw draait en de merge blokkeert als een kernmetriek onder een afgesproken drempel zakt. Behandel een kwaliteitsval precies als een falende unittest — iets om te repareren vóór het live gaat, geen verrassing die je van gebruikers verneemt.

Dit is eval-driven development, en volwassen teams draaien het zoals ze testsuites draaien: een snelle smoke-set bij elke commit, een vollere batterij 's nachts, en een harde poort vóór release. Een batterij evals draaien tegen elk nieuw modelcheckpoint om regressies te vangen vóór ze gebruikers bereiken, is inmiddels standaardpraktijk, geen luxe. Zodra evals een poort zijn in plaats van een rapport, wordt prompt-engineering een beheerst, meetbaar proces in plaats van een zenuwslopend spelletje mollenmeppen — en kan het hele team het systeem met vertrouwen veranderen, want de harnas vangt wat ze breken.

Een uitgewerkt voorbeeld: een e-mailassistent

Abstract advies is makkelijk om instemmend bij te knikken en lastig toe te passen, dus maak het concreet. Stel je bouwt een functie die antwoorden opstelt op inkomende klant-e-mails. Hoe ziet evalueren er dan werkelijk uit?

Begin met de dataset. Haal vijftig echte inkomende e-mails uit je historie, over de hele breedte die je werkelijk ontvangt: simpele vragen, boze klachten, meerdelige verzoeken, off-topic berichten, en een paar zonder redelijk antwoord. Schrijf voor elk op wat een goed antwoord moet doen — niet de exacte woorden, maar de criteria: elke gestelde vraag beantwoorden, de feiten juist hebben, de juiste toon treffen, en nooit iets beloven dat je niet kunt waarmaken.

Kies nu metrieken per criterium. Feitelijke juistheid en "beantwoordde het elke vraag" lenen zich goed voor een LLM-as-judge die tegen een rubric beoordeelt. Toon kan ook een juryscore zijn, gekalibreerd tegen een handvol menselijke beoordelingen. Een harde regel — "mag geen restitutiebeleid verzinnen" — kan een deterministische controle zijn die op verboden beweringen scant. Draai alle vijftig door de huidige prompt, scoor ze, en je hebt een nulmeting. Verander de prompt om de boze-klacht-gevallen te verbeteren, draai opnieuw, en je ziet meteen of je die hielp zonder de simpele te schaden. Koppel die suite aan CI met een drempel — zeg, geen metriek mag meer dan twee punten zakken — en elke toekomstige wijziging is automatisch beschermd. Dat is de hele methode, en hij schaalt van één functie naar honderd.

Veelgemaakte fouten

• Alleen op het gelukkige pad evalueren. Een dataset met makkelijke vragen bewijst niets. De lastige, dubbelzinnige en buiten-scope-gevallen zijn waar functies falen en waar evaluatie haar brood verdient.
• Eén totaalscore. Eén getal verbergt welke taak of categorie regresseerde. Scoor per taaktype en per criterium, zodat een fout naar zijn oorzaak wijst.
• De jury blind vertrouwen. Een ongekalibreerde LLM-jury kan driften of het verkeerde belonen. Toets hem periodiek aan menselijke beoordelingen.
• Een bevroren dataset. Een evalset die nooit nieuwe productiefouten opneemt, weerspiegelt de werkelijkheid steeds minder.
• Een perfecte score najagen. Stel doelen die bij je risicoprofiel passen en steek moeite in de gevallen die echt falen, niet in het uitknijpen van punten uit gevallen die al werken.

Het driftprobleem: je systeem verandert terwijl jij er niet aan zit

De meest verontrustende faalvorm in LLM-applicaties is die waarbij niets in je code veranderde en de kwaliteit tóch daalde. LLM-systemen driften, en er zijn drie bronnen die aandacht verdienen.

• Prompt-drift. Naarmate prompts bewerkingen van verschillende mensen opstapelen, verzamelen ze tegenstrijdigheden en dode instructies die de uitvoer stilletjes verslechteren. Evals vangen dit zodra een wijziging een score verlaagt.
• Modelversie-drift. Aanbieders updaten gehoste modellen — gewichten, veiligheidsbeleid, serving-infrastructuur — vaak zonder het API-endpoint te veranderen. Gedocumenteerde incidenten van grote aanbieders laten zien dat zulke stille updates gedrag kunnen verschuiven, taakaccuratesse verlagen en weigeringen verhogen op verzoeken die eerder werkten. Je code is identiek; het model eronder niet.
• Data-drift. De invoer die je gebruikers sturen verandert in de tijd — nieuwe onderwerpen, nieuwe formuleringen, nieuwe randgevallen die je oorspronkelijke dataset nooit zag.

De verdediging is praktisch. Pin in productie op gedateerde model-snapshots in plaats van een zwevende "latest"-alias, zodat een upgrade een besluit is dat je neemt en evalueert, niet iets dat je overkomt. Houd een canary op het nieuwste model draaien tegen je evalsuite, zodat je zijn gedrag kunt vergelijken vóór je het promoveert. En voer nieuw ontdekte fouten uit productie terug in je dataset, zodat de harnas de werkelijkheid bijhoudt. Welk model je überhaupt kiest, is een besluit op zich — onze vergelijking van OpenAI vs Anthropic vs open-source-LLM's zet de afwegingen op een rij, inclusief de controle die zelf-hosten je geeft over precies dit soort stille verandering.

Stel drempels die je kunt verdedigen

Een score op zichzelf vertelt niet of je moet uitrollen. Je hebt een beslisregel nodig, en dat betekent vooraf afspreken wat "goed genoeg" is voor elke metriek — vóór je de cijfers ziet, zodat het doel niet stilletjes wordt verschoven naar wat het model toevallig produceerde. Koppel de drempel aan het risico van de taak: een functie die interne notities opstelt mag een lagere lat hebben dan een die prijzen aan klanten noemt of iets gereguleerds raakt.

Denk in error budgets in plaats van perfectie. Perfecte scores zijn meestal een teken dat je dataset te makkelijk is, niet dat je systeem foutloos is, dus bepaal liever hoeveel regressie je op één metriek accepteert en hoeveel totale kwaliteit je voor een release eist. Een gangbare, verdedigbare regel is dat geen kernmetriek meer dan een kleine vaste marge onder de huidige nulmeting mag zakken, en dat elke hoofdmetriek boven zijn ondergrens moet blijven. Rapporteer de cijfers als een korte trendlijn die het hele team kan lezen, geen muur van getallen — het doel van evaluatie is een besluit, en een drempel maakt van een score een besluit. Steek je verbeterinspanning in de gevallen die onder de lijn vallen, en laat de gevallen die er al boven zitten met rust.

Verder dan offline: evalueer ook in productie

Offline evals op een vaste dataset vertellen hoe het systeem presteert op de gevallen die je voorzag. Productie vertelt hoe het presteert op de gevallen die je niet voorzag. Volwassen LLM-evaluatie draait op beide. In productie kun je niet elk antwoord labelen, dus leun je op goedkopere signalen: expliciete duim-omhoog en duim-omlaag, impliciete signalen zoals of een gebruiker herformuleert of afhaakt, taakvoltooiing en conversie voor de workflows die de functie ondersteunt, en periodieke LLM-as-judge-scoring op een steekproef van echt verkeer.

Twee technieken overbruggen offline en live. Shadow-evaluatie draait een nieuwe prompt of model op echte invoer zonder de gebruiker het resultaat te tonen, zodat je het risicovrij tegen het huidige systeem op live verkeer kunt vergelijken. A/B-testen legt de wijziging vervolgens voor aan een deel van de gebruikers en meet de uitkomst die er voor het bedrijf echt toe doet. Zakken de live signalen, dan gaan de nieuw opgedoken lastige gevallen terug in je offline dataset, en versterken de twee lussen elkaar. Een evalset die nooit van productie leert, veroudert langzaam.

Houd mensen waar het telt

Geautomatiseerde evaluatie is onmisbaar voor snelheid en schaal, maar ze meet proxy's, geen grondwaarheid. Een functie kan goed scoren en gebruikers tóch frustreren omdat de uitvoer de verkeerde lengte, toon of mate van detail heeft — en LLM-jury's hebben hun eigen blinde vlekken. Houd dus periodieke menselijke review in de lus voor de oordelen die automatisering niet kan maken, en gebruik de harnas waar hij goed in is: regressies snel vangen en opties op schaal vergelijken. De twee zijn aanvullend. Elke leverancier die beweert dat één dashboardgetal bewijst dat hun LLM-functie "accuraat" is, verkoopt een proxy vermomd als garantie.

Evaluatie is ook governance

Voor Europese organisaties is evaluatie niet alleen goede engineering — het is steeds meer zorgvuldigheidsplicht. De EU AI Act legt verplichtingen rond nauwkeurigheid, robuustheid en dossiervorming op aan AI-systemen met hoger risico, en nauwkeurigheid die je nooit hebt gemeten, kun je niet aantonen. Een gedocumenteerd evaluatieproces — een geversioneerde dataset, bijgehouden metrieken, een verslag van wat er veranderde en wat dat met de kwaliteit deed — is precies het bewijs dat zulke verplichtingen verwachten. Dezelfde logica draagt de meetfuncties van het NIST AI Risk Management Framework, dat meetbare, toetsbare prestaties als voorwaarde voor betrouwbare AI ziet. Evaluatie is hoe je "het model lijkt in orde" verandert in iets waar je achter kunt staan.

Hier is geen onderzoekslab voor nodig — alleen de discipline om de juiste dingen te meten en naar de cijfers te handelen. Zo pakken we elke LLM-bouw aan: zie hoe het werkt in onze modelvergelijking, bekijk onze transparante prijzen, of boek een gratis consult en we brengen de evaluatie in kaart die jouw applicatie echt nodig heeft. Kun je nog niet met cijfers zeggen of je laatste wijziging hielp of schaadde, dan is dat de plek om te beginnen.

Veelgestelde vragen