LLM evals: zo test je AI voor elke release

Een eval is een automatische test voor een AI-functie. Je stuurt een vaste set inputs door je systeem, geeft de output een score en vergelijkt het resultaat met de vorige release. Dit artikel is voor product- en engineeringteams die LLM-functies uitbrengen en prompts, modellen en retrieval willen aanpassen zonder te gissen wat er kapot is gegaan.

Gewone unittests gaan ervan uit dat dezelfde input dezelfde output geeft. LLM-systemen werken met kansen, en kleine wijzigingen hebben grote gevolgen. Een aangepaste prompt die één klacht oplost, kan ongemerkt twintig andere cases breken. Een nieuwe modelversie kan tegelijk de toon, de opmaak en het weigergedrag veranderen. Zonder evals is elke release een inschatting op basis van een paar uitgekozen voorbeelden.

Met evals krijg je:

• Een kwaliteitsscore die je in de tijd kunt volgen.
• Een releasecontrole die regressies tegenhoudt voordat gebruikers ze zien.
• Het vertrouwen om van model te wisselen of kosten te verlagen, omdat je het effect kunt meten.
• Een gedeelde definitie van "goed" voor product, engineering en vakexperts.

De bruikbaarste testsets komen uit echt verkeer en echt werk. Synthetische vragen van het team zijn vaak netjes en voorspelbaar. Echte gebruikers schrijven korte, dubbelzinnige vragen vol typfouten en plakken er een half document bij. Gebruik synthetische cases om gaten te vullen, nadat je de echte hebt verzameld.

Goede bronnen voor cases:

1. 01Productielogs, als steekproef over verschillende gebruikers en vraagtypen, met de persoonsgegevens verwijderd.
2. 02Supporttickets en escalaties, vooral die waarin de AI het fout had.
3. 03Voorbeelden van vakexperts voor zeldzame cases die veel uitmaken, zoals een schadeclaim die moet worden afgewezen.
4. 04Aanvallende cases: pogingen tot prompt injection, vragen buiten de scope en input in andere talen.

Begin met 50 tot 100 cases en groei naar een paar honderd. Label elke case op bedoeling, moeilijkheid en risico. Zo zie je wanneer een release eenvoudige vragen beter beantwoordt en tegelijk slechter scoort op risicovolle vragen. Maak van elke bug die je in productie vindt eerst een nieuwe case, en los hem daarna op.

Gebruik de goedkoopste controle die de fout betrouwbaar vindt. Deterministische controles zijn snel, gratis en herhaalbaar. Beoordeling door een model werkt voor kwaliteiten die code niet kan beoordelen. Die is wel trager, kost geld en moet zelf ook worden gecontroleerd.

In de praktijk combineren we ze. Controles in code draaien eerst en stoppen snel bij een fout. Daarna scoort een judge (een model dat beoordeelt) wat overblijft met een kort beoordelingsschema, met een referentieantwoord als dat er is. Beoordeel zo'n 50 cases met de hand en vergelijk, voordat je een judge vertrouwt. Is de judge het vaak oneens met je experts, verbeter dan eerst het beoordelingsschema. Pas daarna laat je releases van de judge afhangen. Ons artikel over RAG evalueren gaat dieper in op de valkuilen van judges.

Evals bewijzen hun waarde als ze automatisch draaien. We draaien een snelle suite bij elke pull request die prompts, tools, retrieval of modelconfiguratie raakt, en de volledige suite voor elke release. Een minimale runner ziet er zo uit:

import json, statistics, time
from dataclasses import dataclass

@dataclass
class Case:
    id: str
    input: str
    must_include: list[str]
    must_not_include: list[str]

def run_suite(cases: list[Case], answer_fn, threshold: float = 0.92) -> None:
    passed, latencies = 0, []
    for case in cases:
        start = time.perf_counter()
        output = answer_fn(case.input).lower()
        latencies.append(time.perf_counter() - start)
        ok = all(s.lower() in output for s in case.must_include) and not any(
            s.lower() in output for s in case.must_not_include
        )
        passed += ok
        if not ok:
            print(json.dumps({"case": case.id, "output": output[:200]}))
    score = passed / len(cases)
    p95 = statistics.quantiles(latencies, n=20)[18]
    print(f"pass rate {score:.1%}, p95 latency {p95:.2f}s")
    if score < threshold:
        raise SystemExit(1)

Met een paar regels wordt die controle betrouwbaar:

• Vergelijk met de baseline en ook met een absolute drempel. Dan zie je een daling van 96% naar 93%, ook als 93% nog slaagt.
• Markeer kritieke cases die altijd moeten slagen, wat de totaalscore ook is.
• Draai niet-deterministische cases meer dan eens en neem de uitkomst van de meerderheid, zodat één afwijkende output geen release tegenhoudt.
• Bewaar elke run met de promptversie, het model-ID en de commit-hash, zodat je elke verandering in de score kunt herleiden.

Een release die de nauwkeurigheid met twee punten verhoogt en de kosten per request verdubbelt, is misschien geen goede release. Leg bij elke run input- en outputtokens, kosten per case en latency-percentielen vast, naast de kwaliteitsscores. Een modelwissel wordt dan een afweging die je met cijfers kunt bespreken. Een nieuwer model kan bijvoorbeeld hoger scoren op risicovolle cases en tegelijk trager en duurder zijn. Het evaluatierapport laat zien hoeveel.

Neem budgetten op in de controle, zoals een limiet voor de p95-latency en maximale kosten per 1.000 requests. Kun je aantonen dat de kwaliteit gelijk blijft, dan kunnen eenvoudige vragen vaak naar een kleiner en goedkoper model.

Evals dekken wat je had voorzien. Productie laat je al het andere zien. Houd naast de automatische suite een kleine, vaste controleronde door mensen aan:

• Neem elke week een vast aantal gesprekken uit productie als steekproef, met extra gewicht voor cases met lage zekerheid, negatieve feedback en hoog risico.
• Laat vakexperts ze beoordelen met hetzelfde beoordelingsschema als de judge. Zo zie je ook hoe vaak de judge het met mensen eens is.
• Maak van elke bevestigde fout een nieuwe case in de testset.

De controle kost weinig tijd, en de testset blijft aansluiten bij hoe mensen het product in de praktijk gebruiken.

1. 01Haal 50 echte cases uit logs of tickets en schrijf bij elke case de verwachte uitkomst op.
2. 02Voeg deterministische controles toe voor opmaak, verplichte velden en verboden inhoud.
3. 03Voeg één beoordeling door een model toe met een kort beoordelingsschema, en vergelijk die met beoordelingen door mensen.
4. 04Draai de suite in CI bij wijzigingen in prompts, modellen en retrieval, met een drempel en kritieke cases.
5. 05Leg bij elke run de kosten en latency vast.
6. 06Begin met een wekelijkse steekproef en voeg fouten toe aan de set.

We zetten evals op aan het begin van elk AI-project, nog voordat we de eerste prompt bijstellen, omdat ze elk later besluit sneller maken. Onze case over een schadeassistent laat zien hoe wekelijkse releases met een evaluatiecontrole eruitzien, en onze aanpak legt uit waar evals in ons proces zitten.