# Evals voor agents: waarom AI-agents falen zonder testen

[Naar de inhoud](#lm-inhoud)Netwerk/NL[EN](/en/)[Hubhub.llmnet.nlModellen vergelijken op taak, taal, kosten en licentie.](https://hub.llmnet.nl/)[Communitycommunity.llmnet.nlPrompttechnieken, patronen en systeemprompts.](https://community.llmnet.nl/)[APIapi.llmnet.nlLLM's robuust in software: rate limits, routing, structured output.](https://api.llmnet.nl/)[Consultancyconsultancy.llmnet.nlAI invoeren in een organisatie, van pilot tot productie.](https://consultancy.llmnet.nl/)[Nieuwsnieuws.llmnet.nlOntwikkelingen in AI, geduid voor Nederland.](https://nieuws.llmnet.nl/)[Benchmarkbenchmark.llmnet.nlZelf meten wat AI-kwaliteit is, voor jouw taken.](https://benchmark.llmnet.nl/)[Vacaturesvacatures.llmnet.nlAI-rollen, salarissen en carrièrepaden in Nederland.](https://vacatures.llmnet.nl/)[Lerenleren.llmnet.nlAI-concepten in gewoon Nederlands, van beginner tot bouwer.](https://leren.llmnet.nl/)[Gidsgids.llmnet.nlAI privé draaien op eigen Mac, pc, NAS of thuisserver.](https://gids.llmnet.nl/)[Directorydirectory.llmnet.nlHet AI-ecosysteem in kaart: tools, modellen, bedrijven.](https://directory.llmnet.nl/)[Radarradar.llmnet.nlSignalen uit X, onderzoek en communities voor indie developers.](https://radar.llmnet.nl/)[llmnet.nl — hoofdsite](https://llmnet.nl/)[](https://x.com/intent/post?url=https%3A%2F%2Fleren.llmnet.nl%2Fevals-voor-agents-waarom-tests-essentieel-zijn&text=Evals%20voor%20agents%3A%20waarom%20AI-agents%20falen%20zonder%20testen)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fleren.llmnet.nl%2Fevals-voor-agents-waarom-tests-essentieel-zijn)[](https://www.reddit.com/submit?url=https%3A%2F%2Fleren.llmnet.nl%2Fevals-voor-agents-waarom-tests-essentieel-zijn&title=Evals%20voor%20agents%3A%20waarom%20AI-agents%20falen%20zonder%20testen)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fleren.llmnet.nl%2Fevals-voor-agents-waarom-tests-essentieel-zijn&text=Evals%20voor%20agents%3A%20waarom%20AI-agents%20falen%20zonder%20testen)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fleren.llmnet.nl%2Fevals-voor-agents-waarom-tests-essentieel-zijn)[](https://www.reddit.com/submit?url=https%3A%2F%2Fleren.llmnet.nl%2Fevals-voor-agents-waarom-tests-essentieel-zijn&title=Evals%20voor%20agents%3A%20waarom%20AI-agents%20falen%20zonder%20testen)[](#)

 
 
 [leren.llmnet.nl](https://leren.llmnet.nl/)
 
 

 
 
 
# Evals voor agents: waarom je AI-agent kapot gaat zonder tests

 Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini)

 Het bouwen van een werkende demonstratie van een AI-agent is tegenwoordig een kwestie van enkele uren. Je koppelt een taalmodel aan een paar externe functies, geeft het systeem een doordachte systeeminstructie en ziet hoe het model zelfstandig beslissingen neemt. De echte uitdaging begint echter wanneer die agent in productie wordt geplaatst. Waar een eenvoudige prompt-toepassing hoogstens een verkeerd geformuleerd antwoord teruggeeft, heeft een autonome agent de mogelijkheid om acties uit te voeren in de buitenwereld. Zonder een solide testinfrastructuur leidt dit onvermijdelijk tot vastgelopen lussen, verminkte database-records, onnodig hoge API-kosten en onvoorspelbare fouten bij onverwachte invoer van gebruikers.

 Dit artikel valt binnen Module 6 — Verantwoord bouwen van de AI-leerlijn op leren.llmnet.nl. In deze module richten we ons op de architectonische en operationele waarborgen die nodig zijn om complexe taalmodel-toepassingen op een veilige en betrouwbare manier naar productie te brengen.

 
 
### Wat je hiervoor moet weten

 Om de concepten in dit artikel optimaal te begrijpen, is het handig als je vertrouwd bent met de basisprincipes van autonome AI-systemen en sturing:

 
 
- Lees eerst de uitleg over [het verschil tussen een agent en een chatbot](https://leren.llmnet.nl/wat-is-een-agent-vs-chatbot) als je wilt begrijpen hoe de autonome actielus van een agent precies verschilt van een lineaire gespreksinterface.
 
- Bekijk het overzicht over [de werking van guardrails bij AI-toepassingen](https://leren.llmnet.nl/guardrails-uitgelegd) voor inzicht in hoe je invoer en uitvoer op runtime kunt afkaderen.
 
- Raadpleeg de gids over [het laten redeneren van modellen met chain-of-thought](https://leren.llmnet.nl/chain-of-thought) om te zien hoe tussentijdse redeneerstappen de besluitvorming van een model beïnvloeden.
 
 

 
## Waarom traditionele unit tests niet werken voor AI-agents

 In klassieke softwareontwikkeling is een unit test deterministisch. Als je een functie aanroept met argument A en B, verwacht je exact uitkomst C. Als de code niet verandert, slaagt de test vandaag, morgen en over een jaar. AI-agents breken dit fundament op twee manieren: de onderliggende LLM is stochastisch en de omgeving waarin de agent opereert verandert dynamisch.

 Een AI-agent werkt volgens een continue lus van waarnemen, redeneren, gereedschap selecteren en uitvoeren. Tijdens elke stap in deze lus genereert het model een respons op basis van de huidige context. Omdat taalmodellen waarschijnlijkheidsverdelingen gebruiken over tokens, kan dezelfde prompt bij een identieke temperatuurinstelling alsnog subtiel verschillende redeneerpaden opleveren. Een klassieke bewering (assertion) die controleert op een exacte string zal hierdoor regelmatig falen, zelfs wanneer de agent de taak inhoudelijk perfect heeft uitgevoerd.

 Wanneer een agent een fout maakt in stap twee van een proces dat uit zes stappen bestaat, werkt die fout cumulatief door in de resterende stappen. De agent kan verstrikt raken in een verkeerde veronderstelling, wat leidt tot hallucinaties in het verdere verloop van de taak. Bekijk de gids over [het begrijpen van hallucinaties bij taalmodellen](https://leren.llmnet.nl/hallucinaties-begrijpen) als je wilt begrijpen hoe foutieve aannames in de redeneerstap ontstaan en de agent op het verkeerde spoor zetten. Om deze reden schieten standaard softwaretesten tekort en hebben we gespecialiseerde evaluatieframeworks nodig: zogenaamde agent-evals.

 
## De drie niveaus van agent-evaluatie

 Een doeltreffend testarchituur voor een agent controleert het systeem op drie verschillende niveaus. Elk niveau belicht een ander onderdeel van de besluitvormingsketen en helpt bij het lokaliseren van specifieke defecten.

 
### 1. Stap-voor-stap / Component-evaluatie

 Op het laagste niveau isoleer je de individuele beslissingen van het model. Je test niet het volledige proces, maar valideert één specifieke stap. Kan het model de juiste tool selecteren op basis van een specifieke gebruikersvraag? Genereert het model valide JSON dat exact voldoet aan het verwachte schema?

 Component-evaluaties zijn snel, goedkoop en grotendeels deterministisch. Als de agent hier faalt, ligt het probleem bijna altijd aan onduidelijke systeeminstructies of een slecht gedefinieerde interface van de tool. Raadpleeg deze handleiding als je wilt leren hoe verduidelijkte functie-omschrijvingen het aantal foutieve tool-calls drastisch verminderen door [het schrijven van effectieve tool-descriptions voor je agent](https://community.llmnet.nl/tool-descriptions-schrijven-de-prompt-die-je-agent-niet-leest).

 
### 2. Traject-evaluatie (Reasoning Trajectory)

 Op het middelste niveau beoordeel je de route die de agent aflegt om tot een eindresultaat te komen. Een agent kan de juiste oplossing vinden, maar daarvoor twaalf overbodige API-calls uitvoeren en drie keer in een verkeerde richting zoeken. Dat is ongewenst in een productieomgeving vanwege de opgelopen latentie en API-kosten.

 Bij traject-evaluatie analyseer je de opeenvolging van gedachten, acties en observaties. Je meet zaken als het aantal stappen, het opnieuw uitvoeren van reeds geslaagde acties en het herstellen van foutmeldingen. Lees dit verdiepingsartikel als je zoekt naar kwantitatieve protocollen om agent-trajecten over duizenden runs heen te vergelijken via [methodieken voor agent-evaluatie op benchmark-niveau](https://benchmark.llmnet.nl/agent-evaluatie).

 
### 3. Eindresultaat & Effect-evaluatie

 Op het hoogste niveau beoordeel je het uiteindelijke effect van de agent-run. Is de database-update daadwerkelijk correct doorgevoerd? Bevat het gegenereerde e-mailconcept alle verplichte klantinformatie? Is het opgeloste ticket afgesloten met de juiste status code?

 Eindresultaat-evaluatie focust niet op *hoe* de agent de taak heeft volbracht, maar uitsluitend op de kwaliteit en correctheid van de uiteindelijke toestandsverandering. Het combineert vaak fysieke controle van de omgeving (bijvoorbeeld een database query) met kwalitatieve controle via een evaluatiemodel.

 
## Traject-evaluatie: het analyseren van de agent-lus

 Het analyseren van het redeneertraject is de meest unieke uitdaging bij het testen van agents. Een traject kan worden weergegeven als een reeks van toestanden. Wanneer een gebruiker vraagt: "Annuleer mijn meest recente bestelling en stuur een bevestiging per e-mail", ziet het ideale traject er als volgt uit:

 [START] -> User Query
 │
 ├──> Thought: Zoek de klant-ID en meest recente bestelling op.
 ├──> Action: get_customer_orders(customer_id="123", limit=1)
 ├──> Observation: Bestelling #98765, status: "in behandeling", bedrag: € 45,00.
 │
 ├──> Thought: De bestelling kan worden geannuleerd. Roep de annulering-API aan.
 ├──> Action: cancel_order(order_id="98765")
 ├──> Observation: Bestelling #98765 succesvol geannuleerd.
 │
 ├──> Thought: Stuur nu een bevestigingsmail naar de klant.
 ├──> Action: send_email(customer_id="123", template="order_cancelled", order_id="98765")
 ├──> Observation: E-mail verzonden met id #abc12.
 │
 └──> Final Answer: Uw bestelling #98765 is geannuleerd en er is een bevestiging gemaild.
[EIND]

 Een defecte agent kan in deze lus op verschillende manieren ontsporen:

 
 
- Oneindige lus (Infinite Loop): De agent blijft `get_customer_orders` aanroepen omdat het antwoord niet goed verwerkt wordt in de context.
 
- Tool-hallucinatie: De agent probeert een niet-bestaande functie zoals `delete_order_permanently` aan te roepen.
 
- Vroegtijdige opgave: De agent stopt na de eerste stap en meldt de gebruiker dat de bestelling geannuleerd is, terwijl alleen de status is opgehaald.
 
- Context-vervuiling: De agent voegt onnodig grote hoeveelheden ruwe JSON toe aan zijn redeneercontext, waardoor het maximale tokenlimiet snel wordt overschreden.
 

 Bezoek de analyse van context-engineering voor strategieën om de prompt-history van je test-cases compact en representatief te houden via [het ontwerpen van een effectieve context-architectuur](https://leren.llmnet.nl/context-engineering-uitgelegd).

 
## Testdatasets en Mocks inschakelen voor agent-evals

 Het live laten uitvoeren van API-calls naar externe systemen tijdens geautomatiseerde test-runs is gevaarlijk en traag. Een testset van 100 scenario's die daadwerkelijk live e-mails verstuurt, betalingen verwerkt of CRM-records aanpast, vervuilt je productiedata en kost vermogens aan API-credits.

 Daarom werken professionele testinfrastructuren met twee lagen van isolatie:

 
### 1. Mocking van de externe omgeving

 Alle tools die de agent gebruikt, moeten in een testomgeving worden vervangen door zogenaamde mock-functions. Wanneer de agent de functie `get_customer_orders` aanroept, retourneert de mock een vastgelegd JSON-antwoord zonder een echte database te raadplegen. Dit garandeert dat de test consistent blijft, onafhankelijk van wijzigingen in live data.

 
### 2. Opnemen en afspelen van trajecten (Recorded Trajectories)

 Bij het bouwen van een regressietestset neem je een succesvolle run op. Zodra er een aanpassing wordt gedaan aan de systeeminstructie of de code van de agent, voer je exact dezelfde prompt opnieuw uit. Het testframework vergelijkt het nieuwe traject met het opgenomen traject. Afwijkingen in tool-selectie of redeneerstappen worden direct gemarkeerd voor inspectie.

 
## LLM-as-a-Judge vs. Deterministische Asserties

 Om te bepalen of een test slaagt of faalt, gebruik je een combinatie van deterministische controle en beoordeling door een secondant-model (LLM-as-a-judge).

 
 
 
 Evaluatietype | 
 Wanneer te gebruiken | 
 Voordelen | 
 Nadelen / Risico's | 
 

 
 
 
 Deterministische Asserties | 
 Controle van JSON-schema's, statuscodes, SQL-syntax en aanwezigheid van verplichte velden. | 
 Zeer snel, gratis, 100% reproduceerbaar en geen foutmarge in de controle. | 
 Kan de inhoudelijke intentie, stijl of nuance van menselijke taal niet beoordelen. | 
 

 
 LLM-as-a-Judge | 
 Beoordeling van klantvriendelijkheid, relevantie, correctheid van samenvattingen en logica in redenering. | 
 Begrijpt complexe context, taalnuances en kan beoordelen volgens een kwalitatieve rubriek. | 
 Hoge kosten, extra latentie, risico op oordeelfouten (bias) en niet 100% reproduceerbaar. | 
 

 
 

 Wanneer je een LLM als beoordelaar inzet, is het essentieel om een strikte rubriek op te stellen. Vraag een judge-model nooit simpelweg: "Is dit een goed antwoord?". Geef het model in plaats daarvan een heldere schaal met concrete criteria:

 Beoordeel het onderstaande antwoord van de agent op een schaal van 1 tot 5 op basis van de volgende criteria:
- 1 punt: De agent heeft de actie niet uitgevoerd en geeft foutieve informatie.
- 3 punten: De agent heeft de actie uitgevoerd, maar mist verplichte details in het antwoord.
- 5 punten: De agent heeft de actie correct uitgevoerd en geeft een volledig, correct antwoord.

Retourneer uitsluitend een JSON-object: {"score": integer, "reasoning": "string"}

 Blader door dit overzicht van testframeworks als je kant-en-klare bibliotheken zoekt voor automatische LLM-evaluaties in [een overzicht van evaluatie- en testtools voor LLM's](https://directory.llmnet.nl/evaluatie-en-testgereedschap-voor-llm-toepassingen-evals).

 
## Valkuilen bij het opzetten van agent-evals

 Het opzetten van een testnetwerk voor agents brengt specifieke valkuilen met zich mee die teams vaak pas ontdekken als hun testsuite onbetrouwbaar wordt:

 
 
- Overfitting op specifieke bewoordingen: Als je testset alleen vragen bevat die exact op dezelfde manier zijn geformuleerd, faalt je agent in productie bij de eerste gebruiker die een synoniem of typefout gebruikt. Neem variaties op in je test-dataset.
 
- Onstabiele testen (Flaky Tests): Vanwege de stochastische aard van modellen kan een test de ene run slagen en de volgende run falen. Gebruik metrieken zoals pass@k (hoe vaak slaagt de test over k pogingen) in plaats van te vertrouwen op een enkele geslaagde run.
 
- Het negeren van kosten en latentie: Een agent die een taak perfect uitvoert maar daarvoor 45 seconden en 8.000 tokens nodig heeft, is in de praktijk onbruikbaar. Neem harde drempelwaarden voor tijdsduur en tokenverbruik op in je testcriteria.
 
- Onbewaakte wijzigingen in tool-definities: Een kleine aanpassing in de docstring van een Python-functie die als tool dient, kan het gedrag van het model compleet veranderen. Zie tool-definities als onderdeel van je prompt-architectuur en neem ze op in versiebeheer.
 

 
## Een praktisch framework voor regressietesten in productie

 Om te voorkomen dat aanpassingen aan prompts of modelversies de werking van je agent slopen, integreer je evals direct in je CI/CD-pipeline. Elke pull request die de code, de prompts of de tool-sets raakt, moet automatisch de testsuite doorlopen.

 
 
- Snelle pre-commit checks (Deterministisch): Valideer of alle prompts en JSON-schema's syntactisch correct zijn en of alle tool-functies een geldige docstring hebben. Dit duurt enkele seconden.
 
- Kleine regressie-suite (Component & Traject): Draai een subset van 20 kritieke scenario's met gemockte API's. Hierbij controleer je of de agent nog steeds de verwachte tools aanroept en geen oneindige lussen veroorzaakt.
 
- Nachtelijke volledige evaluatie (Eindresultaat & LLM-as-a-judge): Draai honderden complexe scenario's door de volledige evaluatieketen met kwalitatieve beoordeling door een zwaar LLM-model. Dit levert een gedetailleerd dashboard op van prestatieveranderingen over tijd.
 

 
## Conclusie & Vervolgstappen

 Het bouwen van betrouwbare AI-agents is niet primair een prompt-engineering uitdaging, maar een software-engineering en evaluatie-uitdaging. Zonder systematische agent-evals is het onmogelijk om met vertrouwen updates uit te voeren aan je systeem. Door te testen op componentniveau, trajecten te analyseren en eindresultaten te controleren met een combinatie van harde asserties en kwalitatieve beoordelaars, transformeer je een onvoorspelbare demo tot een stabiele toepassing die klaar is voor productie.

 
 
### Hierna verder met

 Verdiep je kennis over het bouwen en onderhouden van AI-modellen met deze vervolgstappen uit de leerlijn:

 
 
- Raadpleeg de [complete AI- en LLM-begrippenlijst](https://leren.llmnet.nl/ai-begrippenlijst) om alle technische definities rondom agentic workflows en evaluatiemetrieken snel op te zoeken.
 
- Lees het artikel over [het implementeren van chain-of-thought redenering](https://leren.llmnet.nl/chain-of-thought) om te ontdekken hoe je de interne stap-voor-stap logica van je agent beter kunt structureren en observeren.
 
 

 
 

 
 © 2026 llmnet.nl — Kennisnetwerk over AI en LLM's