Checklist voor LLM-testen: een gids voor pre-launch

Air Canada verloor een rechtszaak omdat hun chatbot een terugbetalingsbeleid verzon. Het tribunaal oordeelde dat de luchtvaartmaatschappij moest instaan voor wat de bot beloofde. Klarna keerde zijn AI-first klantenservice strategie om nadat zijn chatbot slechtere service leverde dan menselijke medewerkers, en begon opnieuw met het aannemen van agenten. Beide verhalen haalden de krantenkoppen omdat het onderliggende probleem hetzelfde was. Een groot taalmodel dat in productie werd genomen zonder het QA-proces dat de technologie daadwerkelijk nodig heeft.

Het patroon is wijdverbreid. Het 2025 State of AI report van McKinsey toonde aan dat 78% van de organisaties nu AI gebruikt in ten minste één bedrijfsfunctie, maar slechts ongeveer een derde heeft het opgeschaald naar het niveau van de gehele onderneming. De meeste andere organisaties voeren pilots uit die ofwel stilvallen tijdens de ontwikkeling, ofwel te vroeg worden gelanceerd, zonder gestructureerde manier om te weten welke van de twee er aan de hand is.

Deze checklist voor LLM-testen is opgesteld voor de tweede groep. Deze omvat zeven pre-launch fasen, de drempels die “klaar” scheiden van “nog niet klaar”, de tools die elke fase nodig heeft, en de faalpatronen die het vaakst voorkomen bij LLM-testen voor productieklare producten. Beschouw het als een gestructureerde controle voor de lancering.

Waarom LLM-testen traditionele QA-aannames doorbreekt

Traditionele software is deterministisch. Dezelfde invoer levert dezelfde uitvoer op, dus testasserties slagen of falen zuiver. Grote taalmodellen gedragen zich niet op deze manier. Stel dezelfde vraag twee keer en u krijgt twee geldige, maar verschillende antwoorden. Wijzig een woord in de systeemprompt en het gedrag op de achtergrond verschuift op manieren die u niet volledig kunt voorspellen.

Dat niet-determinisme verandert de manier waarop u het gedrag van LLM’s test. U vervangt binaire asserties door gescoorde drempels. U meet hoe vaak het model zich correct gedraagt, in plaats van of het dat wel of niet doet bij een enkele uitvoering. En u houdt rekening met een nieuwe klasse van fouten waar traditionele QA nooit over heeft hoeven nadenken: hallucinaties, promptinjectie, jailbreaks, datalekken uit trainingsgegevens, biasdrift en stille regressies na elke modelupdate.

Het resultaat is een andere testdiscipline, verankerd aan de LLM-evaluatiemetrieken die ertoe doen en een bredere reikwijdte dan alleen functionele correctheid. De onderstaande checklist ordent die discipline in zeven stadia die op elkaar voortbouwen.

De 7-stappenchecklist voor LLM-testen

Voer deze fasen in volgorde uit. Elk produceert een uitvoer die de volgende fase nodig heeft. Sla de vroege fasen over en u betaalt daar later voor, wanneer het corrigeren van een gebrekkige dataset of het herschrijven van een systeemprompt tien keer zoveel kost als op dag één. De zeven onderstaande fasen weerspiegelen de reeks die de meeste LLM-evaluatieprogramma’s voor productie volgen, en ze kunnen worden opgeschaald of afgeschaald afhankelijk van het risiconiveau.

Fase 1: Definieer uw evaluatiecontract

Voordat u een enkele test schrijft, documenteert u drie zaken: de use case, de risicocategorie en de acceptabele drempelwaarden voor elke metriek die u wilt volgen. Zorg voor goedkeuring van product, engineering en QA voor alle drie. Zonder dit contract wordt elk volgend argument over “is dit goed genoeg om te verzenden?” een kwestie van mening.

De risicocategorie is het belangrijkst. Een chatbot voor klanten kan een hallucinatiepercentage van ongeveer 5% tolereren. Een medische of juridische assistent moet onder de 1% blijven. Kies eerst de categorie, daarna volgen de drempelwaarden. Gangbare startpunten voor productie-implementaties:

• Trouw: 0,75 of hoger op een genormaliseerde schaal van 0-1.
• Relevantie van het antwoord: 0,70 of hoger.
• Toxiciteit: 0,10 of lager.
• Hallucinatiepercentage: 5% of lager voor algemeen gebruik, 1% voor situaties met hoge inzet.

Het contract wordt het acceptatiecriterium. Als een model een drempelwaarde niet haalt, wordt het niet verzonden.

Fase 2: Creëer uw ideale dataset

De dataset is de basis van elke test die volgt. Een zwakke dataset levert u cijfers op die betrouwbaar lijken, maar in de praktijk niets betekenen.

Voor een basislancering maakt u ten minste 50 voorbeelden. Voor een evaluatie van productieniveau streeft u naar 500 of meer. De beste bron is echte gebruiksdata, geanonimiseerd en gelabeld. Als u die nog niet hebt, simuleert u representatieve invoer over drie categorieën: normale gevallen die gebruikers het grootste deel van de tijd zullen tegenkomen, randgevallen zoals zeldzame scenario’s en ongeldige invoer, en adversariële invoer, waaronder pogingen tot jailbreaking en prompts die de scope schenden.

Wanneer teams vragen hoe ze LLM-applicaties kunnen testen zonder eerst een gouden dataset te bouwen, is het eerlijke antwoord dat ze dat niet kunnen. De dataset moet eerst komen, zelfs als deze klein begint, en groeien naarmate productielogboeken nieuwe faalpatronen blootleggen tijdens de eerste weken van gebruik.

Fase 3: Test de uitvoerkwaliteit

Dit is waar de meeste teams beginnen, vaak nog voordat het eigenlijk nodig is. Outputkwaliteit testen omvat drie onderling samenwerkende metrieken:

• Trouw meet of het antwoord van het model binnen het bronmateriaal blijft. Niet-onderhandelbaar voor elk RAG-systeem.
• Relevantie van het antwoord meet of het antwoord daadwerkelijk de vraag van de gebruiker beantwoordt. Een getrouw antwoord kan nog steeds de verkeerde vraag beantwoorden.
• Hallucinatiepercentage meet hoe vaak outputs feitelijk onjuiste beweringen bevatten, met drempels die schalen naar uw risicocategorie.

Voor RAG-pipelines komt retrieval testen vóór generatie testen. Industriële analyses tonen consequent aan dat de meerderheid van de RAG-fouten voortkomt uit retrieval, niet uit het model zelf. Een praktische stack van RAG-evaluatietools vangt retrieval-hiaten op voordat deze de antwoorden bereiken die voor de gebruiker zichtbaar zijn.

Tools die in dit stadium goed werken zijn onder meer DeepEval, Ragas en G-Eval voor LLM-as-a-judge scoring. Plan één tot twee weken voor deze fase bij een klantgericht product.

Fase 4: Test op bias en veiligheid

Veiligheidstesten omvat twee verschillende gebieden. Toxiciteitsscores vangen schadelijke, aanstootgevende of discriminerende outputs op het moment van generatie. Bias-testen brengt systematische verschillen aan het licht in hoe het model omgaat met verschillende demografische groepen, zelfs wanneer individuele antwoorden op zichzelf prima lijken.

Geautomatiseerde scanners vangen de voor de hand liggende gevallen op. De Perspective API van Google is een veelgebruikte basislijn voor toxiciteit, en bibliotheken zoals AIF360 helpen bij scans voor demografische eerlijkheid. Maar geautomatiseerde tools missen subtiele, contextspecifieke schade. Daarom roept het NIST AI Risk Management Framework en het bijbehorende Generative AI Profile op om geautomatiseerde evaluatie te combineren met menselijke beoordeling gedurende de gehele AI-levenscyclus. De sterkste programma’s koppelen elke geautomatiseerde scan aan een handmatige beoordeling van 50 of meer grensgevallen die voor menselijk oordeel zijn gemarkeerd.

Druk vanuit de regelgeving versterkt dit stadium nu. De EU AI Act vereist van AI-systemen met een hoog risico dat ze documentatie aanleveren van testen op nauwkeurigheid, biasmitigatie en menselijk toezicht. Voor producten die in de EU opereren, is dit stadium niet langer optioneel, zelfs als u het voorheen oversloeg.

Fase 5: Voer beveiligings- en Red Team-tests uit

LLM’s introduceren een aanvalsoppervlak waarvoor traditionele beveiligingstests niet ontworpen zijn. De vijf meest voorkomende aanvalsvectoren om te onderzoeken vóór de lancering:

• Directe promptinjectie, waarbij de invoer van de gebruiker de systeemprompt overschrijft.
• Indirecte promptinjectie via kwaadaardige instructies ingebed in opgehaalde documenten, URL’s of geüploade bestanden.
• Jailbreaks met behulp van rollenspellen, hypothetische kaders of DAN-achtige prompts die veiligheidsfilters omzeilen.
• Pogingen tot het extraheren van systeemprompts die uw sjabloon en eventuele gevoelige context daarin onthullen.
• Lekkage van trainingsgegevens onder speciaal opgestelde queries die fragmenten uit de trainingsset van het model terughalen.

Geautomatiseerde scanners zoals Garak en PyRIT dekken bekende aanvalspatronen op de input- en outputlaag. Ze zijn noodzakelijk, maar niet voldoende. Indirecte injectie via vertrouwde inhoud en geëxploiteerde ketenfunctionaliteiten vereisen doorgaans menselijke red teamers om aan het licht te komen, aangezien ze afhankelijk zijn van context die de scanner niet kan zien.

Voor productie-implementaties combineert u de geautomatiseerde basis met gerichte penetration testing services. Dit is het stadium waarin teams die externe expertise overslaan het meeste verliezen, aangezien de LLM-aanvallen met de hoogste impact zelden de aanvallen zijn die in de documentatie staan.

Fase 6: Prestaties, latentie en kosten valideren

Prestatie-testen voor op LLM gebaseerde producten gaan verder dan de vraag “voelt het antwoord snel aan”. Drie getallen zijn het belangrijkst. Tijd tot het eerste token (TTFT) bepaalt de waargenomen snelheid voor streaming-interfaces en moet voor chat onder de seconde liggen. De totale responslatentie, met name het p95-cijfer, vertelt u meer dan het gemiddelde over de gebruikerservaring. Kosten per verzoek moeten worden bijgehouden als basislijn en bij tien keer het verwachte productievolume, omdat de architectuur die 10 testgebruikers voor tweehonderd dollar per maand afhandelt, zich heel anders gedraagt bij vijftigduizend gelijktijdige sessies.

Dit is waar teams die vragen hoe LLM’s onder realistische belasting te testen, ontdekken dat hun pilotarchitectuur niet kan schalen. Cachinglagen, fallback-modellen, rate limiting en load balancers hervormen allemaal het latentie- en kostenprofiel in productie. Voer belastingtesten uit tegen de productiearchitectuur, niet tegen de pilot.

Fase 7: Vastleggen van regressietestsuite en observabiliteit

De laatste fase is degene die de meeste teams als optioneel beschouwen, en dat is ook waarom ze implementeren en dan stilletjes achteruitgaan. Elke promptupdate, modelwissel en wijziging in de kennisbank kan breken wat gisteren werkte.

Verpak de tests van elke eerdere fase in een regressietestsuite die bij elke wijziging wordt uitgevoerd, niet bij elke release. Maak een momentopname van de basisscores, zodat toekomstige regressies onmiddellijk zichtbaar worden in plaats van na een klacht van een klant. Voeg productie-observability toe vóór de lancering, niet na het eerste incident. Tracing, responslogging en driftwaarschuwingen horen er allemaal vanaf dag één te zijn.

Regressietesten voor LLM-gestuurde producten zien er anders uit dan traditionele regressietesten. De suite is probabilistisch, de drempelwaarden worden gescoord en de vergelijkingen vinden plaats over distributies in plaats van exacte overeenkomsten. Het principe is echter hetzelfde: vang de regressie in CI, niet in een screenshot van een klant op sociale media.

Waar LLM-testen misgaat, zelfs met de checklist

Een complete AI-testchecklist biedt nog steeds ruimte voor voorspelbare fouten. Drie patronen komen herhaaldelijk naar voren in pre-launch-beoordelingen van door LLM’s aangedreven producten.

Evaluatie behandelen als een lanceringsritueel. Teams voeren de checklist één keer uit, halen hun drempels, lanceren en zetten de suite aan de kant. De eerste modelupdate verbreekt in stilte de helft van de winst, en niemand merkt het op totdat een gebruiker dat wel doet. De oplossing is om de regressiesuite onderdeel te maken van elke implementatie, niet van een mijlpaal die u afvinkt en vergeet.

Het model geïsoleerd testen. Een model dat goed scoort in een sandbox kan nog steeds falen in productie omdat de retrieval defect is, de systeemprompt verouderd is, of een toolintegratie op het verkeerde moment wordt beperkt door rate-limiting. De checklist werkt alleen wanneer deze wordt toegepast op de volledige geïntegreerde stack, inclusief de orchestratielaag, de RAG-pipeline en alle downstream API’s die het model kan bereiken.

Adversarial testen overslaan omdat het product een laag risico lijkt. Interne tools worden ook gehackt. Elke LLM die is verbonden met echte gegevens, tools of gebruikersinvoer, hoort thuis in Fase 5, ongeacht of uw publiek één team of één miljoen gebruikers is. De zaak van Klarna is hier leerzaam. Een supportbot die gebruikers ertoe brachten Python te schrijven, was geen implementatie met hoge inzet, maar de reputatieschade leverde nog steeds wereldwijde dekking op.

Van checklist naar lancering

Een testronde vóór de lancering duurt doorgaans drie tot zes weken voor een klantgericht product. Interne tools kunnen binnen één tot twee weken worden geleverd als de dataset gereed is. Implementaties met hoge inzet in gereguleerde sectoren vereisen doorgaans zes tot twaalf weken om te voldoen aan de compliance-beoordeling.

Het zevenfasenproces biedt u de structuur. De drempels bieden u de poort. De regressietestsuite en de observatielaag bieden u een manier om te behouden wat u in de eerste plaats met testen hebt bereikt. Wat deze checklist u niet kan geven, is de tijd die u oorspronkelijk niet voor testen hebt gebudgetteerd.

Als u dichter bij de lancering bent dan u zou willen, neem dan contact met ons op en wij vertellen u welke fasen u het eerst kunt uitvoeren tegen uw planning. De LLM-testdiensten van QAwerk dekken de volledige reeks met ervaren senior engineers, gespecialiseerd in pre-launch evaluatie voor productie-LLM’s.

Veelgestelde vragen

Wat is het verschil tussen LLM-testen en LLM-evaluatie?

Evaluatie meet de kwaliteit van de output aan de hand van gedefinieerde metrieken zoals getrouwheid, relevantie van antwoorden en toxiciteit. Testen is het bredere proces dat evaluatie omvat, plus controles op beveiliging, prestaties, integratie en regressie. De meeste productieteams hebben beide nodig, opeenvolgend uitgevoerd, voordat een groot taalmodel in een klantgerichte context wordt gelanceerd.

Hoe lang duurt LLM-testen?

Een standaard pre-launch doorlooptijd voor een klantgericht product bedraagt drie tot zes weken. Interne tools kunnen binnen één tot twee weken worden geleverd als de dataset gereed is. Implementaties met hoge inzet in de medische, juridische of financiële sectoren duren doorgaans zes tot twaalf weken om te voldoen aan de regelgevende en compliance-eisen.

Hoe verschilt LLM-testen van traditioneel softwaretesten?

Traditionele software is deterministisch, dus tests slagen of mislukken op basis van een exacte outputovereenkomst. Large language models produceren probabilistische outputs, wat betekent dat dezelfde invoer verschillende geldige antwoorden kan opleveren. Testen vervangt binaire assertions door gescoorde drempels voor nauwkeurigheid, veiligheid, latentie en consistentie, en voegt een compleet nieuwe categorie van adversariële controles toe.

Welke tools worden gebruikt voor LLM-testen?

Veelgebruikte tools zijn DeepEval en Ragas voor outputkwaliteit, Promptfoo voor promptregressie, Garak en PyRIT voor adversariële beveiliging, LangSmith en OpenAI Evals voor evaluatiepijplijnen, en Guardrails AI voor runtime-veiligheidshandhaving. De meeste productieteams combineren er drie of vier, afhankelijk van hun use case en budget.