Het formulier is succesvol verzonden.
Meer informatie vindt u in uw mailbox.
Inhuren
Over onsDienstenTechnologieënIndustrieënPortfolio
Uw LLM-app kan duizenden resultaten per uur genereren. Bij een dergelijk volume volstaat handmatige controle niet langer als belangrijkste kwaliteitscontrole. Metrieken zoals BLEU en ROUGE meten de oppervlakkige tekstgelijkenis, maar ze kunnen je niet vertellen of een antwoord de juiste feiten gebruikt of wel in het product thuishoort. En naarmate het systeem groeit, nemen ook de blinde vlekken toe.
De evaluatiemethode ‘LLM als rechter’ vult deze leemte door het ene taalmodel een ander te laten beoordelen aan de hand van door jou gedefinieerde criteria. Teams krijgen zo een signaal waarop ze kunnen reageren bij grote hoeveelheden output, zonder dat er achter elke prompt een menselijke beoordelaar hoeft te zitten. Deze aanpak werkt, maar alleen met de juiste opzet. Een zwakke beoordelingsrubriek, een bevooroordeelde prompt of een model dat zichzelf beoordeelt, kan ervoor zorgen dat de scores er bruikbaar uitzien, terwijl dezelfde kwaliteitsproblemen verborgen blijven.
Hier zal ik het volgende behandelen wat een LLM-as-a-judge precies is, hoe het werkt, waarom de scores nuttig of juist misleidend kunnen zijn, en in welke gevallen de methode vaak tekortschiet. We zullen ook bekijken welke voorbereidingen teams moeten treffen voordat ze op die scores kunnen vertrouwen in een daadwerkelijk AI-product.
Als je al bekend bent met de Uitleg over de LLM-als-rechter, dan kun je dit gedeelte overslaan. Zo niet, dan volgt hier een eenvoudige Definitie van „LLM als rechter”. LLM-as-a-judge is een evaluatiemethode waarbij het ene taalmodel de output van een ander model toetst aan de hand van een door het team vastgestelde beoordelingsrubriek. Deze aanpak kan ook worden toegepast op de output van een breder AI-systeem of een agent.
De beoordelaar krijgt doorgaans het verzoek van de gebruiker, het antwoord van het model en de beoordelingsrubriek te zien, waarin wordt uitgelegd waarop moet worden gelet. Afhankelijk van de opdracht kan hij of zij de output op verschillende manieren beoordelen:
De beoordelingscriteria maken de beoordeling nuttig. Zonder die criteria moet de beoordelaar raden wat er telt als goed. Met behulp van een rubriek kan het team het model wijzen op de kwaliteitsindicatoren die voor hun workflow van belang zijn.
Enkele veelvoorkomende criteria zijn nauwkeurigheid, relevantie, onderbouwing, veiligheid, duidelijkheid en bruikbaarheid. In een RAG-systeem kan de beoordelaar controleren of het antwoord wordt ondersteund door de opgehaalde bron. Bij klantenondersteuning kan worden gecontroleerd of het antwoord in overeenstemming is met het beleid en daadwerkelijk een antwoord biedt op de vraag van de klant. In contentworkflows kan worden gekeken naar toon, duidelijkheid en of het concept geschikt is voor het kanaal.
Waarom gebruiken bedrijven de LLM-als-rechter-evaluatiemethode? AI-systemen ontwikkelen zich sneller dan handmatige controle kan bijhouden. In het begin volstaat het om de resultaten handmatig te controleren. Je controleert een paar antwoorden, geeft feedback en corrigeert duidelijke fouten. Maar zodra het systeem honderden vragen over allerlei onderwerpen gaat verwerken, kan handmatige controle het tempo niet meer bijhouden.
Menselijke beoordeling blijft de beste manier om nuances op te merken, bedrijfsrisico’s in te schatten en ongebruikelijke gevallen af te handelen. De uitdaging ligt in de dekking. Beoordelaars kunnen een beoordelingsschema afstemmen, gevoelige resultaten controleren en fouten onderzoeken, maar ze kunnen niet elk antwoord na elke update beoordelen.
Traditionele meetcriteria zoals BLEU, ROUGE en controles op exacte overeenkomsten helpen ook, maar alleen bij strikte controles zoals exacte antwoorden, schema’s, formaten en bekende labels. Ze laten aspecten als betekenis, relevantie, aansluiting bij het beleid en de algehele kwaliteit van de taak buiten beschouwing.
LLM-beoordelaars kunnen grote testverzamelingen doorlopen en kwaliteiten beoordelen die door vaste meetcriteria over het hoofd worden gezien, zoals relevantie, realiteitsgebondenheid, toon, veiligheid en het opvolgen van instructies. Teams zetten ze in voor regressietests, releasecontroles, modelvergelijkingen en kwaliteitsbewaking na de lancering.
De meeste bedrijven vertrouwen niet op slechts één methode. Een goede opzet combineert deterministische controles voor strikte regels, LLM-beoordelingen voor open evaluaties en mensen voor kalibratie en beslissingen met een hoog risico.
| Methode | Geschikt voor | Beperkingen | Functie in de productie |
| Controle door een mens | Risicovolle resultaten, zakelijke nuances, randgevallen en beslissingen waarbij de context belangrijker is dan een score | Te traag om na elke aanpassing van de prompt, modelupdate, wijziging in het ophalen van gegevens of beleidsupdate te herhalen | Stelt beoordelingsschema’s af, beoordeelt omstreden gevallen, onderzoekt mislukkingen en keurt belangrijke werkprocessen goed |
| Traditionele meetcriteria en vaste controles | Toetsen met bekende antwoorden, schemavalidatie, verplichte velden, opmaakregels, labels die exact moeten overeenkomen en strikte goed/fout-controles | Het ontbreken van betekenis, bronvermelding, aansluiting bij het beleid, toon en antwoorden die op meer dan één manier juist kunnen zijn | Fungeren als harde filters voor controles die telkens moeten worden doorlopen |
| LLM-juryleden | Vrije antwoorden, RAG-kwaliteitscontroles, modelvergelijking, het opvolgen van instructies, toon, veiligheid en relevantie | Kan uitgebreide beschrijvingen belonen, een zwakke beoordelingsrubriek volgen of risico’s over het hoofd zien wanneer de opdracht van de jury vaag is | Geef teams snel een kwaliteitsindicatie voor grote testverzamelingen en stuur zwakke resultaten door voor beoordeling door een mens |
Laten we eens kijken hoe LLM-as-a-judge werkt in een productevaluatieproces. De opzet lijkt op het eerste gezicht eenvoudig. Het ene model schrijft een antwoord, en het andere controleert dit aan de hand van een beoordelingsschema. De beoordelaar bekijkt de opdracht, het antwoord en het beoordelingsschema, en levert vervolgens een gestructureerd resultaat op dat het team kan gebruiken.
Hier volgt een basis Schema van de evaluatieprocedure voor LLM-als-rechter:
Om het wat duidelijker te maken: stel je eens voor dat een bedrijf een AI-assistent voor klantenondersteuning test. In de praktijk verloopt het proces als volgt:
Het systeem ontvangt het oorspronkelijke verzoek. In ons voorbeeld wil een klant weten waarom zijn laatste factuur hoger uitvalt na een wijziging van het abonnement. Bij andere producten kan de taak bestaan uit een standaardvraag, een RAG-zoekopdracht of een instructie voor een AI-agent.
De hoofd-AI genereert drie mogelijke antwoorden op de vraag van de klant. Het ene antwoord is kort en bondig. Een ander antwoord legt de factureringslogica uitgebreider uit. Het derde antwoord heeft een vriendelijkere, meer informele toon.
Het systeem combineert de vraag van de klant, de drie antwoordopties en een strikte beoordelingsrubriek. Aangezien deze assistent gebruikmaakt van RAG, bevat het ook het factureringsbeleid, zodat de beoordelaar de feiten kan controleren.
De jury beoordeelt elk antwoord aan de hand van de beoordelingscriteria. Er wordt gecontroleerd of het antwoord de factuur correct uitlegt, de juiste bron gebruikt, giswerk vermijdt en aansluit bij de toon van het merk. Vervolgens geeft de jury een gestructureerd resultaat, vaak in JSON, met een score en een korte toelichting op die score.
Het systeem selecteert het antwoord met de hoogste score om naar de klant te sturen. Daarnaast worden de scores van de beoordelaar, de motivering, de versie van de prompt en de broncontext in een database opgeslagen. Aan de hand van dit logboek kan het team bijhouden hoe de kwaliteit van de antwoorden verandert wanneer ze het systeem bijwerken.
Antwoorden met een lage score, gelijkspelen en risicovolle gevallen worden doorgestuurd naar menselijke beoordelaars. Een beoordelaar kan bijvoorbeeld opmerken dat een antwoord weliswaar beleefd is, maar geen uitleg geeft over de werkelijke reden voor de prijswijziging. Feedback van mensen helpt om de beoordelingscriteria te verbeteren en eventuele blinde vlekken op te sporen die de beoordelaar over het hoofd heeft gezien.
Het systeem ontvangt het oorspronkelijke verzoek. In ons voorbeeld wil een klant weten waarom zijn laatste factuur hoger uitvalt na een wijziging van het abonnement. Bij andere producten kan de taak bestaan uit een standaardvraag, een RAG-zoekopdracht of een instructie voor een AI-agent.
De hoofd-AI genereert drie mogelijke antwoorden op de vraag van de klant. Het ene antwoord is kort en bondig. Een ander antwoord legt de factureringslogica uitgebreider uit. Het derde antwoord heeft een vriendelijkere, meer informele toon.
Het systeem combineert de vraag van de klant, de drie antwoordopties en een strikte beoordelingsrubriek. Aangezien deze assistent gebruikmaakt van RAG, bevat het ook het factureringsbeleid, zodat de beoordelaar de feiten kan controleren.
De jury beoordeelt elk antwoord aan de hand van de beoordelingscriteria. Er wordt gecontroleerd of het antwoord de factuur correct uitlegt, de juiste bron gebruikt, giswerk vermijdt en aansluit bij de toon van het merk. Vervolgens geeft de jury een gestructureerd resultaat, vaak in JSON, met een score en een korte toelichting op die score.
Het systeem selecteert het antwoord met de hoogste score om naar de klant te sturen. Daarnaast worden de scores van de beoordelaar, de motivering, de versie van de prompt en de broncontext in een database opgeslagen. Aan de hand van dit logboek kan het team bijhouden hoe de kwaliteit van de antwoorden verandert wanneer ze het systeem bijwerken.
Antwoorden met een lage score, gelijkspelen en risicovolle gevallen worden doorgestuurd naar menselijke beoordelaars. Een beoordelaar kan bijvoorbeeld opmerken dat een antwoord weliswaar beleefd is, maar geen uitleg geeft over de werkelijke reden voor de prijswijziging. Feedback van mensen helpt om de beoordelingscriteria te verbeteren en eventuele blinde vlekken op te sporen die de beoordelaar over het hoofd heeft gezien.
Mensen bekijken hun eigen werk vaak nog eens. We lezen het opnieuw, ontdekken zwakke punten en brengen verbeteringen aan. Waarom zou dat bij een model dan anders zijn?
Het lijkt misschien logisch om een model zijn eigen tekst te laten beoordelen en een cijfer te laten geven. Maar in werkelijkheid kan een model, wanneer het zijn eigen tekst controleert, een vloeiende formulering verwarren met echte kwaliteit. Dit wordt ‘zelfversterkende vertekening’ genoemd. Het model kan zwakke logica, herhaalde zinsdelen of saaie afsluitingen over het hoofd zien, omdat deze passen in dezelfde patronen die het zelf heeft gebruikt om het antwoord te schrijven. Daardoor kan de eigen output er beter uitzien dan hij in werkelijkheid is.
Sergei Molchanov, Business Unit Director bij Innowise, stuitte bijvoorbeeld op dit probleem tijdens het ontwikkelen van een geautomatiseerde content-engine voor X-berichten. Elke ochtend stuurde het systeem hem drie varianten van een bericht via Telegram. Hij koos er één uit, bewerkte die soms nog even en publiceerde het vervolgens handmatig. De vraag was simpel: welk concept was nu eigenlijk het sterkst?
In eerste instantie vroeg Sergei het generatormodel om zijn eigen concepten te beoordelen aan de hand van een rubriek. Maar dit leverde hem geen bruikbare informatie op. De scores lagen dicht bij elkaar, in het bereik van 36 tot 40. Een duidelijk zwakker concept scoorde slechts iets lager dan het favoriete concept, waardoor de keuze door de beoordeling eenvoudiger leek dan hij in werkelijkheid was.
Het resultaat veranderde toen Sergei de taken verdeelde. Het ene model schreef de berichten, terwijl een ander model, dat als beoordelaar fungeerde, deze beoordeelde aan de hand van een rubriek met negen onderdelen. Daarna kregen vergelijkbare concepten steeds meer uiteenlopende scores, zoals 26, 32 en 39. De aparte beoordelaar merkte problemen op die de generator had verdoezeld: afzwakkende woorden zoals zou kunnen en waarschijnlijk, metaforen die al in eerdere berichten zijn gebruikt, en inhoudsloze slotzinnen zoals de tijd zal het leren.
Verschillende beoordelingstaken vereisen verschillende opzetten. Sommige teams toetsen antwoorden aan een bekende referentie, terwijl andere teams antwoorden beoordelen waarbij meer dan één versie correct zou kunnen zijn. Daarom maken productieworkflows vaak gebruik van verschillende tSoorten LLM’s die als rechter fungeren systemen.
Comparator-beoordelaars vergelijken de output van een AI met een geverifieerd referentieantwoord, ook wel ‘ground truth’ genoemd. Ze controleren of het antwoord overeenkomt met de feiten, de juiste logica volgt of het verwachte resultaat oplevert.
Deze aanpak werkt het beste wanneer er een eenduidig antwoord is. Zo moet een supportbot bijvoorbeeld de exacte garantieregel vermelden, of moet een code-assistent een specifiek algoritme toepassen. Ook bij benchmarktests is er vaak slechts één juist resultaat om te controleren.
Het nadeel is dat vergelijkende beoordelaars niet erg flexibel zijn. Ze kunnen te streng zijn bij opdrachten waarbij meer dan één antwoord juist is, vooral wanneer de bewoording, de toon of de context van belang zijn.
Veel AI-taken hebben niet slechts één juist antwoord. Zo kunnen bijvoorbeeld een antwoord aan een klant, een samenvatting of een gegenereerd bericht allemaal op verschillende manieren goed zijn. In dit geval gebruikt de beoordelaar een beoordelingsschema in plaats van een referentieantwoord om de output te beoordelen.
Open vragen zijn geschikt om de toon, duidelijkheid, volledigheid, bruikbaarheid en kwaliteit van de inhoud te beoordelen. De beoordelaar kijkt of het antwoord aansluit bij de opdracht, de belangrijkste punten behandelt en geschikt is voor het beoogde doel.
De beoordelingsrubriek is hier bijzonder belangrijk. Als de instructie alleen luidt: “beoordeel de kwaliteit van het antwoord”, heeft de beoordelaar te veel vrijheid om te gissen. Maar als de rubriek luidt: “controleer of het antwoord alle gevraagde stappen omvat en geen ongefundeerde beweringen bevat”, is de score nuttiger.
Beoordelaars vergelijken verschillende resultaten voor dezelfde taak en kiezen daaruit het beste. Soms houdt dit in dat twee antwoorden naast elkaar worden vergeleken, of dat verschillende opties worden gerangschikt om de beste keuze te vinden.
Sergei gebruikte deze opzet in zijn content-engine. De opsteller maakte drie versies van een X-bericht voor dezelfde opdracht. De beoordelaar gebruikte dezelfde beoordelingsschema om ze te beoordelen en hielp bij het selecteren van het sterkste concept.
Deze manier van beoordelen is nuttig bij snelle tests, modelkeuze en inhoudsworkflows waarbij het team een keuze moet maken uit verschillende versies. De volgorde of lengte van de antwoorden kan echter nog steeds van invloed zijn op de resultaten, dus teams schudden de opties vaak in willekeurige volgorde en vergelijken de beslissingen van de beoordelaars met die van menselijke beoordelaars.
Daarom Beoordelingsmethodologie voor LLM’s in de rol van rechter is nuttig voor de evaluatie van RAG. Hierdoor kan het team elk onderdeel van de pijplijn afzonderlijk controleren, in plaats van alleen naar het uiteindelijke antwoord te kijken en te proberen te raden wat er mis is gegaan. Deze stapsgewijze evaluatie wordt vaak de RAG-triade genoemd.
Door deze indeling wordt het opsporen van fouten minder vaag. Een opvraagprobleem betekent dat het systeem niet de juiste informatie heeft opgehaald. Een grondingsprobleem betekent dat de juiste informatie wel aanwezig was, maar dat het model daar niet nauw genoeg bij is gebleven. Als het antwoord slechts oppervlakkig relevant is, moet het team nagaan hoe het model de context omzet in een antwoord.
LLM-beoordelaars helpen ook bij het trainen van het model. Hun taak hierbij is het creëren van een voorkeurssignaal, een trainingsaanwijzing die de lus aangeeft welk antwoord hoger moet worden gerangschikt en waarom.
In versterkend leren op basis van feedback van mensen, of RLHF, begint dit signaal meestal bij mensen. Beoordelaars vergelijken twee modelantwoorden en kiezen het beste antwoord. Deze keuzes vormen de voorkeursgegevens voor een beloningsmodel, dat er later voor zorgt dat de trainingslus de voorkeur geeft aan soortgelijke antwoorden.
Het knelpunt is de omvang. Naarmate de steekproef groter wordt, kunnen beoordelaars niet elk paar in hetzelfde tempo controleren. Een LLM-beoordelaar helpt eerst de resultaten te sorteren, zodat mensen zich kunnen concentreren op onduidelijke gevallen of voorbeelden waarbij een verkeerde voorkeur het model zou kunnen schaden.
Optimalisatie van groepsgerelateerde polissen, of GRPO, werkt met een groep antwoorden. Het model genereert meerdere reacties op dezelfde prompt, en de trainingslus heeft voor elk antwoord in die groep een beloningssignaal nodig. GRPO heeft niet altijd een LLM-beoordelaar nodig. Bij wiskunde of code kan een regel of verificatieprogramma de beloning bepalen. Bij taken zonder één vast antwoord beoordeelt een beoordelaar de reacties aan de hand van een rubriek. Dit is nuttig wanneer de kwaliteit afhangt van de mate waarin aan het beleid wordt voldaan en van het opvolgen van instructies.
Er bestaat een risico dat vergelijkbaar is met dat bij productevaluatie: zodra de scores van de beoordelaar in de training worden meegenomen, begint het model te leren van de voorkeuren van de beoordelaar. Als de beoordelaar uitgebreide beschrijvingen beloont, kan het model dit gedrag overnemen. Als de beoordelaar onveilige snelkoppelingen over het hoofd ziet, kan het model deze herhalen. Beloningen op basis van beoordelaars moeten worden gekalibreerd voordat ze invloed hebben op de training.
Bij redeneeropgaven kunnen ernstige fouten over het hoofd worden gezien bij het beoordelen op basis van het eindantwoord. Een model kan na een verkeerde stap toch het juiste resultaat opleveren. Bij het programmeren of wiskunde is die verborgen fout van belang, omdat diezelfde stap bij een moeilijkere opgave wel eens mis zou kunnen gaan.
Modellen voor procesbeloning, of PRM’s, beoordelen het redeneringstraject terwijl het model naar het uiteindelijke antwoord toewerkt. Een beoordelaar op procesniveau controleert elke stap en wijst aan waar de logica niet klopt.
Zodra de beoordelingsscores in de training worden ingevoerd, gaan ze het gedrag van het model beïnvloeden. Teams moeten de beoordelaar testen, mensen op voorbeelden met een hoog risico houden en de beoordelingsrubriek bijwerken wanneer het model verkeerde gewoontes begint aan te leren.
Nu we hebben besproken hoe deze systemen zijn opgezet en hoe ze zich gedragen in een daadwerkelijk evaluatieproces, gaan we het hebben over de daadwerkelijke voordelen. Waarom zou je überhaupt de moeite nemen om een LLM-beoordelaar in je project op te zetten, en wat levert het je op?
Menselijke QA-teams kunnen maar een beperkt aantal chatlogs of generaties per dag doorlezen. Een LLM-beoordelaar helpt bij het beoordelen van veel grotere steekproeven, waaronder productieverkeer dat te kostbaar zou zijn om handmatig te controleren. Hierdoor hebben teams een grotere kans om kwaliteitsproblemen op te sporen die bij kleine handmatige controles over het hoofd worden gezien.
Een beoordeling door een rechter duurt meestal slechts enkele seconden. Teams kunnen dit toevoegen aan CI/CD-controles of het gebruiken als filter voordat een bericht naar de gebruiker wordt verzonden. Ontwikkelaars zien direct wat er is veranderd na een kleine aanpassing, zonder dagen te hoeven wachten op een menselijke beoordeling.
Traditionele softwaremetriek is gebaseerd op exacte overeenkomsten van trefwoorden of overlappende tekens. Als een model bijvoorbeeld zegt: “De klant is tevreden” in plaats van “De gebruiker is tevreden,” Een strikt beoordelingsschema zou het misschien als fout markeren. Een LLM-beoordelaar kan herkennen dat de betekenis dicht genoeg in de buurt komt en controleren of het antwoord voldoet aan de beoordelingscriteria. Dat is van belang voor toon en structuur, waar reguliere expressies vrijwel geen bruikbare aanwijzingen geven.
Handmatige annotatie kan duur zijn, vooral bij complexe redeneer- of programmeertaken waarvoor deskundige beoordelaars nodig zijn. Beoordelingen via de LLM-API kosten doorgaans veel minder per voorbeeld.
In een recent project heeft een geautomatiseerd e-mailsysteem voor klantenondersteuning drie beleefde antwoordontwerpen opgesteld voor ongeveer $0.05 aan API-tokens. Het inhuren van een beoordelaar om alle drie de concepten te toetsen aan onze merkrubric en de beste te kiezen, kostte ongeveer $0.01. Die beoordelingsstap kostte ongeveer één cent.
Menselijke beoordelaars worden moe. Een labeler kan een tekst op vrijdag laat bijvoorbeeld anders beoordelen dan op maandagochtend vroeg. LLM-beoordelaars hebben hun eigen technische vooroordelen, zoals een voorkeur voor langere teksten, maar ze worden niet moe. Met vaste instellingen en een geteste beoordelingsrubriek passen ze dezelfde criteria consistenter toe dan een menselijk team dat een lange wachtrij moet verwerken.
Als je aanpast waarop je systeem test, hoef je vaak geen honderden regels Python-code te herschrijven. In veel gevallen volstaat het om de beoordelingscriteria bij te werken en de test opnieuw uit te voeren. Zo kan een beoordelaar die de feitelijke juistheid controleert, worden aangepast om empathie en de merkstem te beoordelen.
"Je moet een LLM-beoordelaar niet louter als een ‘black-box’-kwaliteitscontroleur beschouwen. Het werkt het beste als je team een duidelijke beoordelingsrubriek volgt, elke score bijhoudt en de beslissingen vergelijkt met beoordelingen door mensen. Anders krijg je alleen maar cijfers, in plaats van echt inzicht in de kwaliteit.."
Hoofd technische expertise AI
Het concept van de LLM als rechter is nuttig, maar heeft ook zijn tekortkomingen. Als je de ene AI een andere laat beoordelen, ontstaan er nieuwe blinde vlekken in het evaluatieproces. Zonder zorgvuldige controle zou het systeem wel eens hoge scores kunnen toekennen aan zwakke antwoorden.
Dit zijn de belangrijkste valkuilen waar ik op let bij het instellen van een geautomatiseerde beoordelaar.
Wanneer een jurylid meerdere concepten tegelijk vergelijkt, kan het zijn dat het de voorkeur geeft aan het eerste of laatste concept dat het te zien krijgt. Soms is de volgorde waarin een concept wordt gepresenteerd belangrijker dan de kwaliteit ervan. Om dit te voorkomen, kun je de volgorde van de concepten door elkaar husselen voordat je ze naar het jurylid stuurt.
LLM’s geven vaak de voorkeur aan langere antwoorden. Een beoordelaar zou een lang, omslachtig antwoord wel eens hoger kunnen waarderen dan een kort, duidelijk antwoord, zelfs als het kortere antwoord nuttiger is. Om dit te voorkomen, moet in de beoordelingsrubriek worden aangegeven dat de beoordelaar onnodige omslachtigheid moet afstraffen.
Een beoordelingsmodel zou de voorkeur kunnen geven aan antwoorden die door zijn eigen modelfamilie zijn geschreven. Als je bijvoorbeeld GPT-5.5 als beoordelaar gebruikt, kan het zijn dat GPT-5.5-antwoorden hoger worden beoordeeld dan die van Claude Sonnet 5 of Gemini. De beoordelaar geeft vaak de voorkeur aan vertrouwde bewoordingen en structuren, zelfs als een ander antwoord beter is. Om eerlijkere resultaten te verkrijgen, gebruiken teams doorgaans meerdere beoordelingsmodellen en vergelijken ze de scores.
Zelfs een kleine wijziging in de rubriek kan van invloed zijn op de eindscores. Als je bijvoorbeeld de instructie verandert van “Beoordeel de bruikbaarheid” naar “Beoordeel hoe nuttig dit is”, kan dat het gemiddelde slagingspercentage verlagen van 80% naar 60%. De beoordelaar is gevoelig voor de manier waarop je de regels formuleert, dus moeten instructies in verschillende versies worden opgesteld en door mensen worden gecontroleerd.
Als je een gehoste API zoals GPT-5.5 of Claude Sonnet 5 als beoordelaar gebruikt, kan de aanbieder het model zonder voorafgaande kennisgeving bijwerken. Wanneer dit gebeurt, kunnen je referentiescores van de ene op de andere dag veranderen. Een antwoord dat voorheen een score van 4 op 5 kreeg, kan nu een 3 krijgen, waardoor het moeilijker wordt om resultaten uit het verleden te vergelijken.
Als je een generatormodel blijft trainen met feedback van dezelfde LLM-beoordelaar, kan de generator leren het systeem te manipuleren. In plaats van de antwoorden voor gebruikers te verbeteren, gaat hij de woorden en opmaak gebruiken die de beoordelaar het liefst ziet. Hij kan zelfs de toon overnemen die hogere scores oplevert. De scores gaan omhoog, maar de werkelijke productkwaliteit kan achteruitgaan.
Het toevoegen van een LLM-beoordelaar aan je workflow is eenvoudig, maar het is een grotere uitdaging om de scores ervan betrouwbaar genoeg te maken voor beslissingen over publicatie. Als je alleen een eenvoudige prompt gebruikt en het model vraagt om deze tekst te beoordelen, zullen de resultaten vaak inconsistent zijn.
Tijdens het opzetten van deze pijplijnen heb ik populaire Technieken voor LLM’s in de rol van rechter die ervoor zorgen dat de judge-modellen stabiel blijven voor echte evaluatietaken.
Het is belangrijk om de beoordelingsresultaten vanaf het begin te structureren. Gebruik geen vrije opmerkingen, maar laat het model voor elk criterium scores, een korte toelichting en een eindcijfer retourneren in een formaat dat je verwerkingspijplijn gemakkelijk kan lezen.
Zorg er bijvoorbeeld voor dat de rechter geen vrije antwoorden geeft zoals “Deze tekst is best goed, ik geef hem een 8/10.” Dit soort antwoorden zijn moeilijk in code te verwerken. Laat het model in plaats daarvan een strikt JSON-schema met gestructureerde uitvoer gebruiken, of maak gebruik van het aanroepen van tools en Kengetallen voor LLM’s als rechter.
Onduidelijke instructies leiden tot onduidelijke scores. Als je een jurylid bijvoorbeeld vraagt om “creativiteit” te beoordelen op een schaal van 1 tot 5, zal het model alleen maar gissen. Gebruik in plaats daarvan specifieke criteria die de ruimte voor interpretatie beperken.
Bij het beoordelen van geschreven artikelen of berichten vermijd ik bijvoorbeeld algemene kwaliteitsscores. In plaats daarvan verdeel ik de beoordelingsschema in kleinere onderdelen, zoals deze:
Het is belangrijk om de beoordelingsresultaten vanaf het begin te structureren. Gebruik geen vrije opmerkingen, maar laat het model voor elk criterium scores, een korte toelichting en een eindcijfer retourneren in een formaat dat je verwerkingspijplijn gemakkelijk kan lezen.
Zorg er bijvoorbeeld voor dat de rechter geen vrije antwoorden geeft zoals “Deze tekst is best goed, ik geef hem een 8/10.” Dit soort antwoorden zijn moeilijk in code te verwerken. Laat het model in plaats daarvan een strikt JSON-schema met gestructureerde uitvoer gebruiken, of maak gebruik van het aanroepen van tools en Kengetallen voor LLM’s als rechter.
Houd de generator en de beoordelaar gescheiden. Dit is een van de belangrijkste controlemaatregelen in een opzet waarbij een LLM als beoordelaar fungeert, omdat het model dat het antwoord heeft geschreven zijn eigen patronen over het hoofd kan zien of bekende bewoordingen te hoog kan inschatten. Gebruik bijvoorbeeld GPT-5.5 om tekst te genereren en Claude Sonnet 5 als beoordelaar, of andersom. Je kunt voor de evaluatie ook een kleiner, fijnafgestemd open-weight-model gebruiken, zoals een gespecialiseerde variant van Llama 4 Maverick of Llama 4 Scout. Deze aanpak kan helpen de kosten te verlagen en de neiging tot zelfverheerlijking te verminderen.
Zoals we in het hoofdstuk over risico’s hebben besproken, kunnen modellen een positiebias vertonen. Om dit te voorkomen, moet je de volgorde van de antwoorden in elke vergelijking willekeurig bepalen. Bij het beoordelen van paren of meerdere uitkomsten kan een model het eerste antwoord kiezen, simpelweg vanwege de positie ervan. Schud de opties door elkaar voordat je ze beoordeelt, en koppel het gekozen antwoord vervolgens weer aan het oorspronkelijke model of de oorspronkelijke prompt in je code. Probeer bij belangrijke tests de volgorde eens om te wisselen en noteer eventuele gevallen waarin de winnaar na de wisseling verandert.
Om systematische vertekening te beperken, moet je ervoor zorgen dat de beoordelaar geen metadata over het generatieproces te zien krijgt. De beoordelaar mag niet weten welk model de tekst heeft geschreven of welke prompt is gebruikt. Geef de beoordelaar alleen de ruwe output en de beoordelingsrubriek.
Voor het schrijven en beoordelen zijn verschillende modelinstellingen nodig. Gebruik bij het genereren van tekst een hogere temperatuur, bijvoorbeeld 0,7 tot 0,9, om variatie en een natuurlijke tekststroom te bevorderen. Stel voor het beoordelen de temperatuur laag in, vaak op 0, zodat het model consistentere scores geeft voor dezelfde invoer.
Let wel: een temperatuur van 0 zorgt alleen voor stabielere herhaalde controles als de invoer hetzelfde blijft. Het lost de gevoeligheid van de prompt, wijzigingen in de beoordelingsrubriek of positievertekening niet op. Als je de beoordelingsrubriek herschrijft of de volgorde van de antwoorden omdraait, kan de score nog steeds veranderen.
Wanneer OpenAI, Anthropic of Google hun model-endpoints bijwerken, kan je beoordelingsmodel milder of strenger worden. Om dit op te merken, maak je een kleine ‘golden dataset’ aan van 50 tot 100 historische antwoorden die al door mensen zijn beoordeeld en goedgekeurd. Laat je LLM-beoordelaar deze dataset eens per week doorlopen. Als de scores plotseling stijgen of dalen, is het model mogelijk afgedwaald en moet je wellicht je prompts aanpassen of je API vastzetten op een statische versie.
Een geautomatiseerde beoordelaar is een hulpmiddel, geen vervanging voor menselijk toezicht. Houd het overeenstemmingspercentage bij tussen de LLM-beoordelaar en uw menselijke kwaliteitscontroleteam. Als u een overeenstemmingspercentage van 85% tot 90% als interne doelstelling hanteert, beschouw dit dan als een gezondheidscontrole en niet als een universele norm. Als die overeenstemming daalt, zijn uw producteisen mogelijk veranderd en is het tijd om de beoordelingsrubriek bij te werken.
Kennis van de risico’s van LLM-beoordelaars is alleen nuttig als het systeem over controles beschikt om deze risico’s op te sporen. Een beoordelaar kan bijvoorbeeld de voorkeur geven aan het eerste antwoord dat hij ziet, of hogere scores toekennen aan langere antwoorden. Soms kan een modelupdate de scores beïnvloeden, zelfs als je product helemaal niet is veranderd.
Hieronder staan de methoden die ik het vaakst gebruik om vooringenomenheid te verminderen en gebrekkige evaluatiegegevens op te sporen.
Zorg er bij het vergelijken van de resultaten voor dat de jurylid niet weet welk concept afkomstig is van welke prompt of welk model. Schud de opties altijd door elkaar voordat je ze naar de jurylid stuurt. Als de jurylid “Optie A” kiest, moet je code die keuze onopvallend koppelen aan de daadwerkelijke modelvariant.
Deze regel geldt ook voor metadata. De beoordelingsopdracht mag alleen de ruwe tekst en de beoordelingsrubriek bevatten, en niet de naam van het model of details over het generatieproces. Als de beoordelaar details ziet zoals de omvang van het model, het aantal tokens of de verwerkingstijd, kan hij of zij deze gebruiken als snelkoppelingen om de kwaliteit te beoordelen.
Voor belangrijke productiestatistieken is één beoordelingsmodel wellicht niet voldoende. Zo zou een op GPT gebaseerd beoordelingsmodel bijvoorbeeld andere voorkeuren kunnen hebben dan die van Claude of een geoptimaliseerd Llama-model.
Voor kritische evaluaties geef ik er de voorkeur aan om dezelfde output naar meerdere beoordelingsmodellen te sturen en hun scores te vergelijken. Je kunt het gemiddelde van de scores nemen of een meerderheidsbesluit hanteren, maar zorg ervoor dat de beoordelaars onafhankelijk zijn. Als de beoordelaars te veel op elkaar lijken, kan het panel betrouwbaarder lijken dan het in werkelijkheid is. Let goed op meningsverschillen. Als twee beoordelaars een score van 5 op 5 geven en een andere 1 op 5, leg dat geval dan ter beoordeling voor aan een mens. Grote verschillen betekenen meestal dat de beoordelingsrubriek te veel ruimte laat voor interpretatie.
Een geautomatiseerde beoordelaar moet op dezelfde manier werken als getrainde beoordelaars die de beoordelingsrubriek gebruiken. Om dat te controleren, neem je een willekeurige steekproef van 5% beoordeelde logboeken en laat je je interne team deze blind beoordelen aan de hand van dezelfde beoordelingsrubriek.
Vergelijk vervolgens de resultaten. Sommige teams gebruiken de Kappa-coëfficiënt van Cohen, terwijl andere alleen naar het overeenstemmingspercentage kijken. Als je streeft naar een overeenstemming van 85% en de beoordelaar blijft daaronder, ligt het probleem meestal in het feit dat de rubriek niet meer duidelijk genoeg is of dat je productvereisten zijn veranderd.
Bij sommige workflows is een extra controle nodig: het geheugen. Dit is van belang voor content-engines, systemen die dagelijkse rapporten genereren en andere systemen die in de loop van de tijd soortgelijke uitvoer produceren.
Een enkele output ziet er op zich misschien prima uit. Maar als de generator drie dagen achter elkaar dezelfde analogie gebruikt, zullen gebruikers dat opmerken. Bij een eenmalige controle door een beoordelaar zou dit over het hoofd kunnen worden gezien.
In deze gevallen voorzie ik de rechter van een overzicht van de afgelopen dagen. Bij het beoordelen van de concepten van vandaag bevat de prompt een doorlopende vectorindex of een korte samenvatting van goedgekeurde teksten van de afgelopen 7 tot 14 dagen. Zo kan de rechter herhaalde metaforen, hergebruikte openingszinnen, stopwoorden en zwakke slotzinnen opsporen die bij een beoordeling van één enkel document over het hoofd zouden worden gezien.
Waar passen engineeringteams deze aanpak toe? Het afgelopen jaar heb ik gezien hoe LLM-beoordelaars de overstap hebben gemaakt van kleine evaluatiescripts naar AI-workflows in de productieomgeving.
Laten we eens kijken naar de belangrijkste gebieden waarop ze tegenwoordig worden gebruikt.
Zoals eerder vermeld, vormen RAG-systemen een duidelijk toepassingsgebied voor geautomatiseerde beoordelaars. Teams maken gebruik van beoordelaars om te controleren of de retriever de juiste context vindt en of het uiteindelijke antwoord is gebaseerd op de brondocumenten. Dit helpt om ongefundeerde beweringen op te sporen voordat ze uitgroeien tot hallucinaties.
Bij geautomatiseerde content-engines is het zelden een goed idee om de eerste versie van een model direct te publiceren. In plaats daarvan genereren de pijplijnen verschillende versies en wordt er een beoordelaar ingezet om deze te toetsen aan een beoordelingsschema. De beoordelaar kiest de sterkste versie en wijst op algemene formuleringen voordat deze wordt gepubliceerd.
Ondersteuningsbots kunnen problemen veroorzaken als ze van het script afwijken. Teams zetten beoordelaars in om na afloop van het gesprek grote hoeveelheden chatlogs door te nemen. De beoordelaar controleert of de bot de vraag van de gebruiker heeft beantwoord en zich aan de bedrijfsregels heeft gehouden, waaronder het terugbetalingsbeleid, de escalatiestappen en de beloften met betrekking tot functies.
Traditionele blokkeerlijsten met trefwoorden en regex-filters zijn gemakkelijk te omzeilen. Een LLM-beoordelaar houdt rekening met betekenis en context, waardoor moderatieteams schadelijke inhoud kunnen opsporen waarin geen voor de hand liggende verboden woorden worden gebruikt. Het systeem kan zowel de invoer van gebruikers als de antwoorden van het model toetsen aan het beleid.
Nu AI-agenten via tools en API’s acties gaan ondernemen, volstaat het niet meer om alleen de uiteindelijke tekst te beoordelen. In deze workflows beoordelen beoordelaars het hele proces. Ze controleren het gebruik van de tools, de voortgang van de taak en of de agent de taak heeft voltooid zonder vast te lopen.
Je moet een judge-model niet alleen op basis van de benchmarkscore kiezen. Welk model het beste is, hangt af van de taak waarvoor je het nodig hebt. Een model dat bijvoorbeeld goed is in het snel beoordelen van supportlogs, is mogelijk niet krachtig genoeg om tijdens de training voorkeursgegevens te verwerken. Een topmodel kan uitstekend geschikt zijn voor evaluaties met een hoog risico, maar het kan te duur zijn om het elke nacht op duizenden outputs toe te passen.
Daarom kijk ik meestal eerst naar vier dingen: wat de scheidsrechter moet beoordelen, hoeveel context daarvoor nodig is, hoe snel de uitslag bekend moet zijn, en wat er gebeurt als de uitslag onjuist is.
Voor het genereren en evalueren zijn vaak verschillende modelinstellingen en sterktes nodig.
Het genereren van tekst is een creatieve taak. Hiervoor heb je meestal een krachtig model nodig, zoals GPT-5.5, Claude Sonnet 5 of Claude Opus 4.8, ingesteld op een hogere temperatuur om de tekst natuurlijker te laten klinken.
Beoordelen is een gerichte evaluatietaak, maar kwaliteit staat meestal voorop. Voor release-gates, voorkeursgegevens, RAG-controles of outputs met een hoog risico maken teams vaak gebruik van het krachtigste beoordelingsmodel dat ze zich kunnen veroorloven. Snellere modellen kunnen geschikt zijn voor batchcontroles met een laag risico, na kalibratie aan de hand van door mensen beoordeelde voorbeelden.
Houd bij het kiezen van een beoordelingsmodel eerst rekening met de kosten van een onjuiste score. In veel LLM-beoordelingsopstellingen is de kwaliteit van de evaluatie belangrijker dan snelheid of tokenkosten, vooral wanneer scores van invloed zijn op beslissingen over releases, trainingsgegevens of veiligheidsmaatregelen voor gebruikers.
Je zou geen onbewerkte tekst moeten hoeven ontleden om erachter te komen welke score de jurylid heeft gegeven. Bij het kiezen van een jurylidmodel is het essentieel dat het een strikt schema volgt. Je kunt gebruikmaken van OpenAI’s Structured Outputs, Anthropic’s Tool Use of een open-sourceframework zoals Outlines. In alle gevallen moet het model een zuivere JSON-respons retourneren. Als een model goedkoop en snel is, maar vaak de JSON-opmaak niet correct weergeeft, is het moeilijk te gebruiken in een geautomatiseerde beoordelingspijplijn.
Je hoeft niet altijd slechts één model te kiezen. Voor belangrijke taken kies ik meestal voor een ensemble-aanpak. In plaats van te vertrouwen op één enkel duur model, stuur ik dezelfde evaluatie naar verschillende beoordelingsmodellen van diverse aanbieders, zoals OpenAI, Anthropic en een open-source-optie.
Daarna kun je hun scores vergelijken, een gemiddelde berekenen of een meerderheidsstemming houden. Dit helpt om vooringenomenheid van een individuele beoordelaar te verminderen. De beoordelaars moeten echter wel voldoende van elkaar verschillen. Als ze allemaal dezelfde fouten maken, zal het berekenen van een gemiddelde of het houden van een stemming alleen maar dezelfde vooringenomenheid herhalen. Daarom let ik ook op meningsverschillen tussen juryleden en stuur ik onduidelijke gevallen ter beoordeling door naar een mens.
LLM-as-a-judge is nog steeds een nieuwe manier om modellen te evalueren. Veel teams gebruiken al ‘judges’ voor het toekennen van scores, het vergelijken van resultaten en het uitvoeren van RAG-controles, maar het instellen ervan vergt nog steeds veel handmatig werk. De volgende stap is om beoordelingssystemen betrouwbaarder te maken. Ze moeten aangeven wanneer een score onzeker is, tools gebruiken om outputs te verifiëren en beter presteren op specifieke domeinen.
Dit zijn de punten waar ik de meeste aandacht aan besteed.
Op dit moment kunnen LLM-beoordelaars soms te zelfverzekerd zijn. Als een beoordelaar een onduidelijke opdracht krijgt, kan het zijn dat hij of zij toch een definitieve score toekent in plaats van aan te geven dat de zaak onduidelijk is.
Ik verwacht dat steeds meer beoordelingssystemen naast de score ook betrouwbaarheidsniveaus zullen gaan weergeven. In plaats van alleen maar te zeggen sla over of mislukken, zou de rechter bijvoorbeeld iets kunnen zeggen als Score: 4, Betrouwbaarheid: 65%. Als het betrouwbaarheidsniveau te laag is, kan het systeem de zaak doorsturen naar een menselijke beoordelaar.
Algemene modellen zoals GPT-5.5 of Claude Sonnet 5 zijn geschikt voor taken als e-mails, samenvattingen en eenvoudige codecontrole. Maar voor complexe medische of juridische beoordelingen hebben we meer controle over het vakgebied nodig.
Daarom verwacht ik dat er meer gespecialiseerde ‘judge’-modellen zullen komen. Sommige zouden kunnen worden afgestemd op specifieke taken, zoals het beoordelen van medische antwoorden of het controleren van juridische contracten. Deze modellen zullen experts niet vervangen, maar ze kunnen wel helpen door routinematige zaken af te handelen en de lastige gevallen door te geven aan mensen.
De meeste hulpmiddel voor de evaluatie van LLM-as-a-judge zal waarschijnlijk in meer beoordelingsprocedures worden ingezet. Juryleden zouden niet alleen moeten vertrouwen op hun eigen kennis, terwijl ze taken ook aan externe bronnen kunnen toetsen.
Als een generator bijvoorbeeld een Python-script schrijft, kan de beoordelaar dit in een sandbox uitvoeren om te controleren op fouten. Als de generator iets beweert over een recente gebeurtenis, kan de beoordelaar een zoekopdracht uitvoeren of een betrouwbare gegevensbron raadplegen om dit te verifiëren. Het gaat erom de output af te zetten tegen bewijsmateriaal, in plaats van de tekst op zichzelf te beoordelen.
Wanneer teams beoordelaarscores gebruiken in trainingscycli, kunnen generatieve modellen leren om de beoordelaar tevreden te stellen in plaats van betere antwoorden aan gebruikers te geven. Dit is een vorm van ‘reward hacking’.
De generator zou bijvoorbeeld kunnen ontdekken dat de beoordelaar de voorkeur geeft aan opsommingen of zeer beleefde bewoordingen. Ook zou hij kunnen gaan herhalen welke opvulzinnen doorgaans hoge scores opleveren. Toekomstige beoordelingssystemen zullen betere manieren moeten vinden om dit op te sporen, zodat de scores een getrouwe weergave zijn van de werkelijke kwaliteit van de antwoorden.
Veel teams beschouwen evaluatie nog steeds als een afzonderlijk script dat ze uitvoeren na een prompt of modelupdate. Ik denk dat dit zal veranderen naarmate AI-systemen steeds meer in de productie worden geïntegreerd. De volgende stap is het opnemen van evaluatie in de leveringspijplijn. Vóór de release kunnen beoordelaars helpen bij het opsporen van regressies in testverzamelingen. Na de lancering kunnen ze steekproefsgewijze uitvoer controleren en risicovolle gevallen doorsturen naar mensen.
Als je tot hier hebt gelezen, ben je waarschijnlijk aan het nadenken over een evaluatieprobleem in je AI-systeem. Misschien verloopt de handmatige beoordeling te traag. Misschien laten je scores zien dat de kwaliteit is veranderd, maar geven ze geen uitleg over wat er nu precies mis is gegaan.
Daarom is de opzet zo belangrijk. Hetzelfde model mag niet zowel de antwoorden opstellen als beoordelen. Je hebt een duidelijke beoordelingsrubriek nodig, een gestructureerde manier om resultaten vast te leggen en regelmatige controle door mensen om het systeem goed afgestemd te houden.
Het echte risico is dat een vloeiende uitvoer toch niet aan de verwachtingen voldoet. Een model kan zelfverzekerd klinken, terwijl het de context van de bron over het hoofd ziet of een essentieel onderdeel van het verzoek van de gebruiker negeert. Met een goed opgezette evaluatielaag kun je die tekortkoming opmerken voordat je gebruikers dat doen.
Bij Innowise helpen we teams bij het opzetten van evaluatielagen voor LLM-producten, AI-agenten, en AI-systemen voor bedrijven. Als uw AI-product behoefte heeft aan duidelijkere kwaliteitscontroles, laten we dan eens praten.
LLM-as-a-judge is een evaluatiemethode waarbij een taalmodel (de ‘rechter’) de tekstuitvoer van andere AI-systemen beoordeelt, een score toekent en een onderbouwing geeft. Het vervangt kostbare menselijke beoordelingen door kwaliteitscontroles op nauwkeurigheid, relevantie, toon of veiligheid op grote schaal te automatiseren.
LLM-beoordelaars leveren vaak nauwkeurige resultaten op bij veel evaluatietaken, maar hun prestaties zijn afhankelijk van de taak, het model, de beoordelingsrubriek en de systeemkalibratie. Teams moeten de scores van de beoordelaars vergelijken met door mensen beoordeelde voorbeelden en letten op vooringenomenheid, gevoeligheid voor prompts en afwijkingen.
LLM-beoordelaars versnellen en schalen de evaluatieworkflow op zonder mensen volledig te vervangen. Menselijk toezicht blijft nodig bij gevoelige zaken, het samenstellen van trainingsdatasets en het vaststellen van beoordelingsnormen.
Wanneer een model zijn eigen werk beoordeelt, heeft het de neiging zichzelf te hoog in te schatten. Het ziet vaak zijn eigen fouten en schrijfproblemen over het hoofd, wat leidt tot te hoge scores die niet erg bruikbaar zijn.
De RAG-triade is een evaluatiekader dat is ontworpen voor generatiesystemen die gebruikmaken van retrieval-augmented generation. Het meet de prestaties op basis van drie specifieke axe’s: contextrelevantie, onderbouwing en relevantie van het uiteindelijke antwoord.
In de loops van reinforcement learning genereren LLM-beoordelaars snel geautomatiseerde voorkeurssignalen en stapsgewijze scores. Hierdoor kunnen beloningsmodellen de afstemming van het systeem veel sneller optimaliseren dan bij handmatige menselijke beoordelingen.
De belangrijkste risico’s vloeien voort uit inherente modelvertekeningen, waaronder de neiging om de voorkeur te geven aan langere antwoorden (uitgebreidheidsvertekening), de voorkeur te geven aan antwoorden die als eerste worden gepresenteerd (positievertekening) en een grote gevoeligheid te vertonen voor kleine wijzigingen in de formulering van de prompt.
Teams kunnen vertekening tot een minimum beperken door de generatie- en evaluatiemodellen van elkaar los te koppelen, de volgorde van antwoorden in vergelijkende opstellingen willekeurig te bepalen, metagegevens van modellen te verbergen en geautomatiseerde scores te toetsen aan door mensen beoordeelde referentiewaarden.
