Een applicatie gebaseerd op een groot taalmodel (LLM) evalueren betekent deze systematisch testen, voor en na elke wijziging. De gids beschrijft hoe je scoringsmethoden kiest, een betrouwbare LLM-rechter ontwerpt, en vervolgens RAG-systemen en agents gedurende de hele publicatiecyclus evalueert.
Een paar antwoorden lezen en bevredigend vinden is niet genoeg. Een wijziging in de prompt, een modelwijziging of een verandering in de documentenretrieval kan een werking ongemerkt breken, en het wordt dan moeilijk te bepalen welke wijziging de oorzaak is. Evalueren komt neer op het opstellen van testgevallen, elk antwoord scoren volgens geschreven criteria, en vervolgens de scores voor en na elke wijziging vergelijken, naar het model van regressietesten in klassieke code.
De antwoorden van een LLM variëren van uitvoering tot uitvoering, en het begrip ‘goed antwoord’ hangt af van de context. Een unit test controleert op gelijkheid, terwijl ‘U kunt schoenen binnen 30 dagen retourneren’ en ‘Retourneren is toegestaan tot een maand na levering’ beide correct zijn. De gids maakt onderscheid tussen evaluatie, die een relatieve kwaliteit meet volgens vage criteria, en tests, die een productierelease valideren met binaire controles, zoals een geldige JSON of de afwezigheid van een verboden formulering. Een implementatie blokkeren op een trouw-score van 0,7 zou volgens de auteur neerkomen op wekelijks debatteren over een arbitraire drempel.
Drie manieren om een antwoord te scoren
Een scorer ontvangt een testgeval, bestaande uit een invoer, een antwoord en soms een context of referentie, en geeft vervolgens een oordeel of een getal terug. Code-scorers passen deterministische regels toe, om het formaat, de lengte of de aanwezigheid van bepaalde strings te controleren. Op referentie gebaseerde scorers vergelijken het antwoord met een bekend antwoord. Overlap-metrics zoals BLEU en ROUGE herkennen bijvoorbeeld een correcte parafrase niet. De LLM-rechter, ten slotte, is een model dat wordt belast met het toepassen van een set criteria op het antwoord van een ander model, nuttig voor toon, verankering in bronnen of nut.
De gids raadt aan om overal te beginnen met code waar een regel voldoende is, omdat deze scorers niets kosten en altijd hetzelfde resultaat geven. Drie configuraties voor de rechter worden beschreven: eenmalig, waarbij hij een label of score toekent aan een geïsoleerd antwoord; paarsgewijs, waarbij hij het beste van twee antwoorden kiest, een gebruikelijke methode om twee prompts of twee modellen te vergelijken; en referentie-gestuurd, wanneer hij een referentie-antwoord heeft.
De rechter betrouwbaar maken
Een goed geschreven set criteria bepaalt de kwaliteit van de rechter. De gids beschrijft deze in vier delen: de definitie van het criterium, de gegevens die de rechter mag gebruiken, de te volgen procedure en een strikt uitvoerformaat, bij voorkeur JSON. Redenering moet voorafgaan aan het oordeel, en de temperatuur wordt op 0 gezet om ruis door sampling te verminderen, zonder deze te elimineren. Voor gevoelige criteria suggereert de gids een oneven aantal uitvoeringen en het aanhouden van het meerderheidsoordeel.
De QAG-methode (vraag-antwoordgeneratie) vraagt de rechter om gesloten vragen met ja of nee te beantwoorden, waarna de berekening door de code wordt uitgevoerd. De trouw van een antwoord met vier beweringen waarvan er drie worden ondersteund is dus 0,75. Voor subjectieve criteria berekent de G-Eval-methode een gewogen gemiddelde op basis van de kansen van mogelijke scores, zodat een model dat 60/40 verdeeld is tussen 4 en 5 een 4,4 krijgt. Bias is gedocumenteerd in onderzoekswerk over het beoordelen van LLM-output: positiebias, verbositeitsbias en zelfvoorkeursbias voor modellen uit dezelfde familie. De gids stelt voor om de volgorde van antwoorden om te keren, gevallen van vergelijkbare lengte te testen en een rechter uit een andere modelfamilie te gebruiken.
Calibratie blijft de belangrijkste stap. De gids adviseert om zelf 30 tot 50 antwoorden te labelen en vervolgens deze labels te vergelijken met die van de rechter met behulp van de Cohen’s kappa, die corrigeert voor overeenkomst door toeval. Een score van 0 komt overeen met overeenkomst op toevalniveau, en 1 met perfecte overeenkomst. Boven ongeveer 0,6 wordt de overeenstemming over het algemeen als substantieel beschouwd.
RAG, agents en de publicatiecyclus
Een RAG-systeem (retrieval-augmented generation) combineert twee componenten die afzonderlijk kunnen falen: de zoekmachine, die de context terugvindt, en de generator, die het antwoord formuleert. De gids stelt voor om de precisie van de context, de recall, de trouw van het antwoord aan de opgehaalde documenten en de relevantie voor de vraag te meten. Een hoge trouw gecombineerd met een lage recall duidt bijvoorbeeld op onvoldoende retrieval.
Voor agents begint de gids met de voltooiing van de taak, en onderzoekt vervolgens de juistheid van het gekozen gereedschap, die van zijn argumenten en de gevolgde trajectorie, zonder redundante aanroepen of loops. Offline-evaluaties vinden plaats vóór productierelease, op een versiebeheerde set van 25 tot 50 gevallen, met vooraf vastgestelde publicatiecriteria. Online-evaluaties worden uitgevoerd op een steekproef van het echte verkeer. Elk falen dat in productie wordt waargenomen kan vervolgens een referentietestgeval worden.
