Iedereen die een LLM-applicatie in productie heeft gebracht, kent het patroon: de demo loopt vlekkeloos, stakeholders zijn enthousiast, de eerste antwoorden klinken overtuigend. En dan komt er een klant met een vraag die je niet hebt getest, waarna het model met de zelfverzekerdheid van een expert iets zegt dat simpelweg onjuist is. Of na een prompt-update ontdek je dat een edge case die eerder werkte, plotseling kapot is. Je weet niet wanneer. Je weet niet waarom.
Het probleem zit niet in het model. Het probleem is het ontbreken van meting. Dit artikel gaat over hoe je een eval-infrastructuur opbouwt die je — met cijfers, niet met gevoel — vertelt of je LLM-applicatie beter of slechter presteert dan gisteren.
Waarom "ziet er goed uit" geen metric is
In traditionele software heb je unit tests, integratietests, een CI-pipeline. Vóór elke merge weet je of iets is stukgegaan. LLM-outputs zijn probabilistisch — dezelfde input kan een licht afwijkende output geven, en een fout antwoord gooit geen exception. Het falen is stil.
Teams zonder eval-proces vertrouwen op drie mensen die de applicatie af en toe doorklikken en zeggen "lijkt OK". Dat werkt tot de eerste 200 gebruikers. Daarna verbreedt de use-case space, wisselen modellen, worden prompts aangepast — en niemand weet wat er net is misgegaan.
Eval (evaluatie) is het systematisch meten van de kwaliteit van LLM-outputs ten opzichte van gedefinieerde criteria. Niet eenmalig, maar als continu proces: vóór deployment, na elke promptwijziging, na elke modelupgrade, regelmatig in productie.
Drie typen evals — elk op zijn plek
Voordat we naar tools gaan, is het belangrijk om drie verschillende contexten te onderscheiden waarin een eval plaatsvindt:
Offline eval — je draait dit vóór deployment op een vaste dataset. Je krijgt snel en reproduceerbaar antwoord. Geschikt voor regressietests in CI/CD.
Online eval — draait in productie op echte queries, doorgaans op een steekproef. Onthult distributieshifts: echte gebruikers gedragen zich anders dan testscenario's.
Fine-tuning eval — een specifiek geval waarbij je meet of een nagetrained model beter presteert dan het basismodel op doelgerichte taken. Dit wordt beschreven in een apart artikel (Hoe meet je of fine-tuning heeft geholpen). Valt buiten de scope hier.
RAG eval — meet faithfulness (heeft het model geantwoord op basis van wat het tot zijn beschikking had?), answer relevancy en context recall. De standaard is het RAGAS-framework, beschreven in het artikel Hoe evalueer je RAG (RAGAS). Valt hier ook buiten de scope.
Dit artikel richt zich op offline én online eval voor een productie-LLM-applicatie — chatbot, copilot, agent.
Hoe je een eval-set opbouwt uit echte gevallen
De meest gemaakte fout: een AI-engineer stelt de eval-set samen tijdens een weekendsessie. Het resultaat dekt wat hij denkt dat edge cases zijn — niet wat echte gebruikers werkelijk vragen.
De juiste aanpak:
- 1.Verzamel echte logs vanaf dag één. Log elke query en elk antwoord (met anonimisering van PII). Dit is je goudreserve.
- 2.Identificeer mislukkingen. Loop de eerste 200–500 echte interacties handmatig door. Waar heeft het model slecht geantwoord? Waar heeft het geweigerd te antwoorden terwijl het dat wel had moeten doen? Waar was het onnodig vaag?
- 3.Categoriseer mislukkingen naar type. Voorbeelden van categorieën: feitelijke hallucinatie, onterechte weigering, fout antwoordformaat, relevant maar onvolledig antwoord, omzeiling van beveiligingsregels.
- 4.Selecteer representatieve gevallen per categorie. Minimale gouden set (golden set): 100–300 voorbeelden met een correct antwoord of beoordelingscriterium. Voor een productiesysteem: 500–1 000+ gevallen.
- 5.Voeg een ground truth of rubric toe aan elk voorbeeld. Voor eenvoudige gevallen: een referentieantwoord of expected output. Voor complexe gevallen: een rubric (een set criteria waaraan het antwoord moet voldoen).
De gouden set is niet statisch. Voeg elke maand nieuwe mislukkingen uit productie toe. Een verouderde set die je niet bijwerkt, weerspiegelt het echte gebruikersgedrag niet meer.
Metrics — nauwkeurig wanneer je een referentie hebt
Voor eenduidige taken (extractie, classificatie, gestructureerde output) werken deterministische metrics:
- Exact match — de output klopt met de referentie of niet. Geschikt voor entiteitsextractie, klassenclassificatie, JSON-schema.
- F1-score — meet de token-overlap tussen output en referentie. Geschikt wanneer er meerdere correcte formuleringen bestaan.
- BLEU / ROUGE — standaard voor vertaling en samenvatting. In de praktijk weinig gebruikt voor algemene LLM-applicaties; beter voor specifieke NLP-taken.
Deze metrics zijn snel, goedkoop en deterministisch. Maar ze schieten tekort voor de meeste productie-use-cases, waarbij een "correct antwoord" tientallen formuleringen kan hebben.
LLM-as-judge — kracht en beperkingen
Voor open taken — waar een referentieantwoord niet bestaat of te variabel is — komt LLM-as-judge in beeld: een ander LLM (groter of even sterk) beoordeelt de output aan de hand van een rubric.
Waarom werkt dit? GPT-4-klasse modellen halen ongeveer 85 % overeenstemming met menselijke reviewers, wat een hogere consistentie is dan de typische mens-mens-overeenstemming (zo'n 81 %) op dezelfde taken. Tegen 500–5 000× lagere kosten dan menselijke annotatie.
Maar LLM-as-judge heeft vijf gedocumenteerde biassen die je actief moet compenseren:
1. Position bias — de judge geeft de voorkeur aan het antwoord dat als eerste (of als laatste) staat. Oplossing: vergelijk altijd met omgekeerde volgorde (A vs. B → dan B vs. A) en gebruik een meerderheidsstem.
2. Verbosity bias — een langer antwoord klinkt overtuigender, zelfs als het minder accuraat is. Een direct gevolg van hoe modellen zijn getraind op menselijke feedback. Oplossing: penaliseer onnodige lengte expliciet in de rubric.
3. Self-preference bias — het model geeft de voorkeur aan zijn eigen outputs. Claude v1 vertoonde bij zelfevaluatie een ongeveer 25 % hogere win rate voor eigen antwoorden; GPT-4 circa 10 %. Oplossing: gebruik nooit hetzelfde model als producent én als judge.
4. Format bias — antwoorden met markdown, bullet points of een nette structuur krijgen hogere scores. Oplossing: de rubric beoordeelt inhoud, niet presentatie.
5. Calibration drift — bij lange batch-evaluaties wordt de judge óf te soepel, óf te streng. Oplossing: voeg altijd een paar kalibratievooorbeelden met bekende scores toe aan de batch en monitor de drift.
Aanbevolen praktische structuur voor een LLM-as-judge-aanroep:
- Systeemprompt: rol van de judge, lijst van beoordelingsdimensies, numerieke schaal (bijv. 1–5 per dimensie)
- Gebruikersprompt: context van de vraag, het te beoordelen antwoord, rubric met definities per score
- Few-shot voorbeelden: 3–5 goed beoordeelde en 3–5 slecht beoordeelde voorbeelden (verhogen de consistentie van circa 65 % naar circa 77 %)
Overeenstemming van de judge met menselijke reviewers: als je meet en 75 %+ bereikt, heb je een bruikbaar signaal. Onder de 65 % produceert de judge meer ruis dan informatie — dan is het tijd om de rubric te herbouwen.
G-Eval en DAG-scoring
Moderne eval-frameworks zoals DeepEval implementeren benaderingen die verder gaan dan een simpele "geef een score van 1–5":
G-Eval — de judge genereert eerst een beoordelingsprocedure (chain-of-thought-stappen) en scoort daarna op basis daarvan. Dit vermindert de willekeurigheid van de beoordeling.
DAG-scoring — breekt de beoordeling op in een beslissingsboom. In plaats van "is het goed?" doorloopt het: "is het feitelijk correct?" → zo ja: "is het volledig?" → zo ja: "is het veilig?". Elk knooppunt kan een andere metric of LLM-as-judge-aanroep zijn.
Voor productiesystemen bevelen we een combinatie aan: deterministische metrics voor wat objectief meetbaar is, plus LLM-as-judge voor dimensies als coherentie, toon en volledigheid.
Regressietests in CI vóór elke release
Hier is het praktische workflow dat we klanten aanbevelen:
- 1.Golden set in de repository — de eval-dataset maakt deel uit van de code, versiebeheerd in git naast de prompts.
- 2.Eval CI-stap — voer vóór elke merge naar main de eval-pipeline uit. Als de totaalscore meer daalt dan een gedefinieerde drempel (bijv. 3 procentpunten), wordt de merge geblokkeerd.
- 3.Regressiespecifieke tests — voeg voor elke gevonden mislukking uit productie een testcase toe. Een eenmaal gevonden fout mag niet stilletjes terugkomen.
- 4.Aparte eval-omgeving — de eval-pipeline roept niet hetzelfde model/endpoint aan als productie. Isolatie voorkomt dat de eval productielogs beïnvloedt.
- 5.Resultaten zichtbaar — niet alleen pass/fail. Elke PR bevat een eval-diff: welke metrics zijn verbeterd, welke zijn gedaald, met hoeveel.
DeepEval is de de facto standaard voor CI/CD-gating — integreert als pytest-plugin, exporteert naar JUnit XML voor CI, drempelgebaseerde gating. Voor stakeholder-dashboards en productietraceerbaarheid wordt het aangevuld met Braintrust.
Online eval — wat offline tests missen
Offline eval vertelt je of je applicatie werkt op voorbeelden die je kent. Het vertelt je niet of echte gebruikers iets nieuws tegenkomen.
Online eval draait doorgaans op 5–10 % van de productiequerys (sampling vanwege kosten). Je zoekt naar:
- Distributieshift — gebruikers vragen dingen die niet in de golden set staan. Monitor categorieën waar de judge consistent laag scoort.
- Anomalieën — antwoorden die onverwacht kort of lang zijn, lage consistentie vertonen bij herhaalde uitvoering, of beveiligingspatronen bevatten.
- Latency vs. kwaliteit trade-off — een sneller model kan in bepaalde categorieën slechter presteren.
Online eval-data wordt regelmatig teruggevloeid naar de golden set. De cyclus: productie → mislukkingen → golden set → CI-tests → deployment.
Onderscheid met fine-tuning eval en RAG eval
Mensen verwarren deze drie typen evals regelmatig:
Fine-tuning eval — meet of een nagetrained model doet waarvoor het is nagetrained. Vergelijkt het basismodel met het fine-tuned model op een taakspecifieke dataset. Hoort niet thuis in de CI-pipeline van een productieapplicatie — het is een eenmalig (of per-run) experiment vóór modelregistratie. Meer in het artikel Hoe meet je of fine-tuning heeft geholpen.
RAG eval (RAGAS) — meet de RAG-pipeline: faithfulness (citeert het model alleen wat het in de context had?), answer relevancy, context precision en recall. Het tool RAGAS biedt 8 specifieke metrics. Dit is een extra laag — je beoordeelt retrieval en generation afzonderlijk. Meer in Hoe evalueer je RAG (RAGAS).
Productie-LLM eval (dit artikel) — meet de end-to-end kwaliteit voor de gebruiker. Je bent niet geïnteresseerd of het model een document correct heeft geciteerd; je wilt weten of het antwoord nuttig, veilig en in lijn met de businesscriteria was.
EU AI Act en eval als wettelijke verplichting
Vanaf 2 augustus 2026 geldt de volledige toepasselijkheid van de EU AI Act. Voor bedrijven die LLM-systemen inzetten in hoog-risico categorieën (gezondheidszorg, kritieke infrastructuur, HR, onderwijs) wordt eval-documentatie een wettelijke verplichting.
Concreet: voor hoog-risico systemen vereist de AI Act een gedocumenteerd en continu risicobeheer inclusief testen en validatie, monitoring van hallucinatieratio's, biaspatronen en prompt-injection-risico. Boetes voor de ernstigste overtredingen kunnen oplopen tot 35 miljoen euro of 7 % van de wereldwijde jaarlijkse omzet.
Praktische implicatie: als je evals ad hoc in een Notion-document bijhoudt, voldoe je niet aan de vereiste. Je hebt een audit trail nodig — promptversie, modelversie, datum van de eval-run, resultaten, wie de deployment heeft goedgekeurd. De exacte technische vereisten voor het documentatieformaat zijn nog niet gestandaardiseerd via implementing acts, maar de richting is duidelijk: zonder traceerbaarheid geen compliance.
Veelgestelde vragen
Hoe groot moet mijn golden set zijn om te beginnen?
Voor de eerste inzet zijn 100–200 voorbeelden uit echte interacties voldoende. Representativiteit is belangrijker dan omvang — dekking van de belangrijkste mislukkingscategorieën, niet alleen "typische" queries. Naarmate het productievolume groeit, groeit de golden set organisch: elke maand voeg je tientallen nieuwe gevallen toe uit mislukkingen.
Mag ik hetzelfde model gebruiken als producent én LLM-judge?
Nee. Self-preference bias is goed gedocumenteerd — modellen beoordelen hun eigen outputs consistent beter dan alternatieven. Als je outputs produceert met Claude, beoordeel ze dan met GPT-4-klasse en vice versa. Voor een open-weight stack: productie op Llama, judge op Qwen of DeepSeek.
Wat kost LLM-as-judge in productie?
Dat hangt af van het model en het volume. Ter indicatie: bij 1 000 queries per dag en een sampling rate van 10 % doe je 100 judge-aanroepen per dag. Met een frontier-model (invoer 2–5 USD, uitvoer 12–25 USD per miljoen tokens) bedragen de kosten bij een typische korte judge-prompt een paar dollar per dag. Veel minder dan equivalente menselijke annotatie.
Wat doe ik als de LLM-judge niet consistent is?
Eerste stap: voeg few-shot voorbeelden toe aan de judge-prompt — 3–5 goed en 3–5 slecht beoordeelde gevallen met toelichting. De consistentie zou moeten stijgen. Als dat niet helpt, ligt het probleem in de rubric: de criteria zijn te vaag of overlappen elkaar. Herschrijf ze als concrete, meetbare voorwaarden. Doel: overeenstemming van de judge met menselijke reviewers boven de 75 %.
Kan ik eval volledig automatiseren zonder menselijke controle?
Voor de meeste use-cases wel, maar met uitzondering. Voor hoog-stakes systemen (geneeskunde, recht, financiën) moet er minimaal een maandelijkse handmatige review zijn van een steekproef van de outputs. LLM-judges hebben blinde vlekken — met name voor subtiele feitelijke fouten in vakgebieden waar ze domeinkennis missen. Automatisering vermindert de werklast, maar vervangt geen expertbeoordeling voor kritieke beslissingen.
*Als je niet zeker weet waar je LLM-applicatie werkelijk faalt — en de meeste teams weten dat niet — is de eerste stap eenvoudig: kijk in de logs en zoek de vijf slechtste antwoorden van de afgelopen maand. Daar begint elk goed eval-programma. We helpen je graag het hele proces in te richten — van golden set via CI-gating tot productionmonitoring.*