AI-Agents Evalueren in Productie: Ons 3-Lagensysteem voor Live Traces

AI-Agents Evalueren in Productie: Ons 3-Lagensysteem voor Live Traces

AI-agents evalueren in productie betekent dat je het volledige multi-stap traject van de agent scoort, niet alleen het eindantwoord, op live verkeer: je checkt elke redeneerstap, valideert of de juiste tools met de juiste argumenten zijn aangeroepen, en monitort continu de taakslagingsgraad, kosten en veiligheid na livegang, want agents falen stil en niet-deterministisch.

Op een run van onze eigen Techsy-contentpipeline in juni 2026 leverde de agent een perfect ogende blogpost af, en de eindscore keurde hem goed. Brandschoon. Behalve dat de brief-creator drie stappen eerder de verkeerde interne-link-lookup-tool had aangeroepen, waardoor de helft van de clusterlinks nergens naartoe leidde. Weten hoe je AI-agents evalueert in productie betekent dat je het hele pad scoort dat een agent aflegde, niet alleen het antwoord waar hij toevallig op uitkwam.

Belangrijkste inzichten:

• Scoor het hele traject, niet alleen het eindantwoord: een juist antwoord via het verkeerde pad is nog steeds mislukt.
• Valideer tool calls op drie assen: de juiste tool, de juiste argumenten, de juiste stap.
• Draai dezelfde metrics offline én online, op live productietraces, in een continue lus.
• Blokkeer releases op security-kwetsbaarheden (jailbreak, PII, tool-misbruik), niet alleen op lage accuracy-scores.

Waarom Verschilt het Evalueren van AI-Agents in Productie van LLM-Evaluatie?

AI-agents evalueren in productie is lastiger dan model-evaluatie, omdat een agent meerdere stappen zet, externe tools aanroept en echte state muteert, en dat allemaal niet-deterministisch doet. Dezelfde input kan van run tot run een andere tool-call-volgorde opleveren, dus één verkeerde stap vroeg in het traject kan elke stap erna corrumperen.

Deze gids gaat ervan uit dat je algemene LLM-evaluatie al kent. Zo niet, begin dan met onze complete LLM-evaluatiegids en kom daarna terug voor wat er verandert zodra het model een agent wordt. (Ben je nog bezig de agents te bouwen die je straks gaat beoordelen? Ons overzicht van de beste AI-agent-frameworks behandelt de laag eronder.)

Vier dingen breken zodra je LLM zelfstandig gaat handelen:

• Multi-stap. Een support-agent doorzoekt misschien eerst een kennisbank, roept dan een order-API aan en stelt vervolgens een antwoord op. Scoor je alleen het antwoord, dan mis je de twee stappen die het bepaalden.
• Niet-deterministisch. Temperature, model-weight-updates en tool-latency zorgen ervoor dat hetzelfde verzoek elke run een ander pad aflegt. Je eval moet een bewegend doelwit overleven.
• Stateful. Agents schrijven naar databases, sturen e-mails, verwerken terugbetalingen. Een verkeerde actie is geen slechte zin, het is een neveneffect dat je niet kunt terugdraaien.
• Cumulatief. Een licht foute stap 2 in een run van 12 stappen vergiftigt alles daarna, en het eindantwoord kan alsnog prima ogen.

Uit het State of Eval Engineering-rapport van Galileo (februari 2026), gebaseerd op 500+ vakmensen, bleek dat 84,9% van de teams binnen zes maanden na livegang een AI-incident meemaakte. Het engineeringteam van Anthropic zegt het ronduit in hun essay over agent-evals: agents falen over stappen, tools en intentie heen, niet alleen bij de eindoutput.

Een agent die het juiste antwoord geeft via het verkeerde traject, is niet geslaagd. Hij is stilletjes mislukt, en zal de volgende keer luidruchtig mislukken zodra het geluk niet meezit.

Welke Metrics Zijn Écht Belangrijk voor AI-Agents in Productie?

De metrics die er het meest toe doen voor agents in productie gaan verder dan accuracy: taakslagingsgraad, kosten per geslaagde taak, latency-percentielen, tool-call-accuracy, faithfulness, mens-interventiegraad, drift en de slagingsgraad van de safety-gate. Samen vangen deze ai agent evaluatiemetrics de stille, niet-deterministische fouten die één enkele outputscore mist.

Dit zijn de acht metrics die we daadwerkelijk in de gaten houden op onze eigen runs. Let op hoe weinig ervan zich bekommeren om of het eindantwoord lekker leest:

De meeste hiervan leunen op een LLM-as-a-judge (één model dat de output van een ander scoort). Het is de standaardtruc en schaalt goed, maar is ruisgevoelig: de judge deelt vaak de blinde vlekken van de agent, dus behandel de scores als signaal, niet als evangelie. We komen terug op het kalibreren van de judge in sectie zeven.

Eén metric verdient extra aandacht. Kosten per geslaagde taak is het cijfer dat een budgetreview overleeft. Platte kosten per taak belonen goedkope mislukkingen, omdat een agent die snel en verkeerd opgeeft er op de spreadsheet efficiënt uitziet.

Hoe Scoor Je het Traject van een Agent in plaats van het Eindantwoord?

Om het traject van een agent te scoren, evalueer je de trace: het geordende overzicht van elke redeneerstap, tool call en tussenoutput die de agent produceerde. Span-niveau-evaluatie scoort elke afzonderlijke stap (span), zodat je precies kunt aanwijzen welke stap faalde, in plaats van alleen te weten dat de hele run misging.

Zie een trace als een stack trace voor redeneren. Elke span is één stap: een retrieval, een tool call, een overdracht naar een sub-agent. Observability legt die spans vast; evaluatie scoort ze. (Nog geen tracing? Onze AI-observabilitygids behandelt de observatielaag waar scoring bovenop zit, en onze vergelijking van LangGraph, CrewAI en de OpenAI Agents SDK laat zien hoe een trace er in elk van die frameworks uitziet.)

Waarom elke span scoren in plaats van alleen het eindpunt? Cumulatieve fouten. Als stap 2 het verkeerde document ophaalt, bouwen stappen 3 tot en met 12 voort op onzin, en kan een gelukkige eindformulering alsnog langs een output-only check glippen. Span-niveau-scoring vertelt je dat de run bij stap 2 faalde, niet alleen dat hij ergens faalde.

Hier is eerst de framework-onafhankelijke versie (een simpele assertion over een trace-object), gevolgd door de DeepEval-kortere weg met de trace-gebaseerde Task Completion-metric:

# Framework-onafhankelijk: bereikte het traject het doel via geldige stappen?
def score_trace(trace):
    assert trace.steps[-1].status == "success", "final step failed"
    assert all(s.error is None for s in trace.steps), "a mid-run step errored"
    assert "internal_link_lookup" in [s.tool for s in trace.steps], "skipped a required step"

# DeepEval: scoor de hele multi-stap trace op taakvoltooiing
from deepeval.tracing import observe
from deepeval.metrics import TaskCompletionMetric

@observe(metrics=[TaskCompletionMetric(threshold=0.7, model="gpt-4o")])
def content_pipeline(topic):
    ...  # jouw researcher -> brief -> writer -> validator-run
    return final_post

De framework-onafhankelijke assert is prima voor harde, deterministische checks. Task Completion pak je erbij wanneer succes vager is dan een gelijkheidscheck: het haalt de bedoelde taak en het behaalde resultaat uit de trace en scoort hoe goed ze op elkaar aansluiten.

Hoe Valideer Je dat een Agent de Juiste Tool Heeft Aangeroepen?

Om de tool calls van een agent te valideren, check je drie dingen los van elkaar: toolselectie (koos hij de juiste tool), argumentcorrectheid (gaf hij de juiste parameters en waarden mee) en uitvoeringspad-validiteit (riep hij die tool aan op de juiste stap, in de juiste volgorde). Een geslaagd eindantwoord met een verkeerde tool call is een bug die nog niet aan het licht is gekomen.

Dit is de meest agent-specifieke eval die er is, en degene die bijna niemand grondig behandelt. Multi-agent tool-usage-evaluatie valt uiteen in drie vragen:

1. Selectie. Koos de agent, van alle beschikbare tools, de juiste? Willekeurig welke tool aanroepen is niet hetzelfde als de juiste aanroepen.
2. Argumenten. Gaf hij de juiste parameters mee? De juiste tool met een verkeerde slug of een misvormde datum is nog steeds een mislukking.
3. Uitvoeringspad. Riep hij die tool aan op de juiste stap, in de juiste volgorde? Terugbetalen voordat je de order verifieert is de juiste tools in de verkeerde volgorde.

DeepEval's Tool Correctness-metric behandelt alle drie: hij vergelijkt tools_called met expected_tools, kan matchen op inputparameters, en met should_consider_ordering=True beoordeelt hij ook de volgorde.

# Framework-onafhankelijk: juiste tool, juiste argumenten, juiste stap
call = trace.steps[2].tool_call
assert call.name == "internal_link_lookup", f"wrong tool: {call.name}"
assert call.args == {"slug": "llm-evals-guide"}, f"wrong args: {call.args}"

# DeepEval: scoor toolselectie + argumenten, met volgordebewustzijn
from deepeval.test_case import LLMTestCase, ToolCall, ToolCallParams
from deepeval.metrics import ToolCorrectnessMetric

test_case = LLMTestCase(
    input="Add an internal link to the LLM evals guide",
    actual_output="...",
    tools_called=[ToolCall(name="sitemap_search")],
    expected_tools=[ToolCall(name="internal_link_lookup")],
)
metric = ToolCorrectnessMetric(
    evaluation_params=[ToolCallParams.INPUT_PARAMETERS],
    should_consider_ordering=True,
)
metric.measure(test_case)
print(metric.score, metric.reason)  # 0.0  "verwachte tool niet aangeroepen"

Die 0.0 is precies de mislukking die we op onze eigen pipeline betrapten: de agent greep naar sitemap_search terwijl de verwachte tool internal_link_lookup was. De afgeronde post haalde nog steeds zijn outputscore. Alleen de tool-call-metric vlagde het gebroken pad.

Hoe Voer Je Evals Online Uit, op Live Productietraces?

Online evaluatie draait je metrics in real time tegen live productietraces, in plaats van alleen tegen een testset vóór livegang. Het is de derde laag van een 3-lagensysteem: offline tests op een golden set, een pre-deployment-QA-gate, en dan online evals op live verkeer, waarbij productietraces worden teruggebracht in datasets zodat de lus zich blijft verbeteren.

Offline tests vangen regressies af voordat ze live gaan. Maar agents ontmoeten in productie inputs die geen enkele golden set had voorzien, dus moeten dezelfde metrics na livegang blijven draaien. Hier is de volledige lus die het diagram bovenaan in kaart brengt:

1. Offline. Draai je metrics op een golden dataset in CI. Laat de build falen bij een regressie.
2. Pre-deployment-QA-gate. Een door mensen beheerd controlepunt: haalt dit de accuracy-lat én de safety-lat (sectie zes)?
3. Online. Scoor live productietraces in real time met dezelfde metrics.
4. Curateer. Verzamel automatisch echte traces (vooral de mislukkingen) terug in je evaluatiedatasets.
5. Herhaal. Je golden set groeit vanuit de realiteit in plaats van uit de 20 voorbeelden die je op dag één met de hand schreef.

Een online eval opzetten is dezelfde instrumentatie als tracing, plus een metric collection. Confident AI draait de 50+ scorers van DeepEval tegen live traces, en is OpenTelemetry-compatibel, dus LangGraph, CrewAI, OpenAI en de Vercel AI SDK exporteren zonder maatwerk-adapters:

# Dezelfde metrics die je in dev draaide, nu scorend op live productieverkeer
from deepeval.tracing import observe, update_current_span
from deepeval.test_case import LLMTestCase

@observe(metric_collection="Production Agent Quality")
def support_agent(query: str) -> str:
    answer = run_agent(query)  # jouw live agent
    update_current_span(
        test_case=LLMTestCase(input=query, actual_output=answer)
    )
    return answer
# De metrics van deze collectie draaien nu op elke trace, in real time.

De winst zit in de curatiestap. Elke echte productiemislukking wordt een permanente regressietest, dus je suite stopt met een statische momentopname te zijn en begint te volgen wat je agent daadwerkelijk in het wild tegenkomt.

Blokkeer Releases op Security, Niet Alleen op Accuracy

Een security-gate blokkeert een deploy bij een kwetsbaarheid, niet alleen bij een lage accuracy-score. Voor agents betekent dat adversariële en red-team-evals die zoeken naar jailbreaks, tool-misbruik en PII-lekken, uitgevoerd zowel vóór livegang als online. Een jailbreak is geen lage score die je wegmiddelt. Het is een blokkade voor de release.

Elke concurrent behandelt veiligheid als één metric tussen vele. Dat is achterstevoren voor agents, die overgehaald kunnen worden om een echte tool tegen een echt systeem aan te roepen. Scheid dus de gates: een accuracy-gate middelt scores; een security-gate is pass/fail op de vraag of er ook maar één adversariële probe doorheen kwam. Begin met het koppelen van de faalmodi van je agent aan de frameworks die auditors al herkennen:

Draai daarna adversariële evals tegen die categorieën. OWASP's Top 10 voor LLM-toepassingen, het NIST AI Risk Management Framework en MITRE ATLAS geven je de gedeelde vocabulaire; red-teaming geeft je de test. DeepTeam, het open-source red-teaming-framework van hetzelfde team achter DeepEval, levert 120+ kwetsbaarheden over 8 categorieën en 20+ aanvalsvectoren, elk gekoppeld aan OWASP, NIST AI RMF en MITRE ATLAS.

Eén eerlijke nuance over tooling: DeepTeam OSS is het gratis pad en dekt de kwetsbaarhedenset; de managed, in-platform red-teaming-module in Confident AI is een Enterprise-tier-feature, niet iets wat het Starter-plan van $9.99 bundelt. Bouw red-teaming hoe dan ook in als een eersteklas gate, niet als een bijgedachte die je één keer draait voor livegang.

Wat We Ontdekten Toen We Dit op Onze Eigen Pipeline Draaiden

We draaien dit 3-lagensysteem op onze eigen multi-agent contentpipeline: vier agents (researcher, brief-creator, content-writer, validator) die werk een keten door doorgeven. Het bedraden van DeepEval v4.0.5 in die pipeline, over juni en juli 2026, tegen onze Confident AI-workspace, is hoe we de mislukking uit de intro betrapten. De scorer-output zag er zo uit:

ToolCorrectnessMetric  score=0.00  threshold=0.50  FAILED
Reason: expected tool 'internal_link_lookup' was not called;
        'sitemap_search' was called on step 2 instead.

De post had zijn output-kwaliteitsscore al gehaald. Niets aan het afgeronde artikel oogde verkeerd. Alleen de traject-eval zag de gebroken stap, precies de klasse bug waar een output-only check zo langs zwaait.

Als je praktijkmensen volgt op r/LLMDevs, r/MachineLearning of r/LocalLLaMA, komt steeds dezelfde handvol klachten terug, en die sluiten bijna één-op-één aan bij wat het 3-lagensysteem is gebouwd om te vangen:

• Het werkt-maandag-faalt-woensdag-probleem. Niet-determinisme zorgt dat dezelfde input van run tot run een ander pad aflegt, waardoor teams leren om flaky evals te negeren. Span-niveau-scoring op live traces verslaat een grotere golden set.
• Golden-dataset-vermoeidheid. Weken besteed aan het met de hand labelen van een suite die één redeneerwijziging alweer overbodig maakt. Automatisch curateren van productietraces verslaat het met de hand onderhouden van een statisch bestand.
• Wantrouwen richting de LLM-judge. Het terugkerende refrein is dat de judge de blinde vlekken van de agent deelt, wat precies de reden is dat teams een mens in de lus houden.

Dat laatste punt is het belangrijkste. Domeinexperts annoteren de outputs waar de judge onzeker over is, en die labels voeden terug in de metric-uitlijning, dezelfde gesloten lus die we beschreven in onze Confident AI review en die aansluit bij hoe we agent-geheugen behandelen. De judge schaalt; de mensen houden hem eerlijk.

Welk Platform Past bij Jouw Stack?

Geen enkele tool is goed voor elk team, dus match het platform bij waar je staat. Hier is hoe de belangrijkste opties zich verhouden op de vijf capabilities waar deze gids op leunde, plus hoe je binnenkomt:

Bovenaan voor het enterprise- en cross-teamgebruik staat Confident AI. Het dekt de volledige kwaliteitslevenscyclus op één plek (dev-time evals, productie-observability, adversariële security via DeepTeam, een org-brede kwaliteitsgate), en zijn echte onderscheidende factor is no-code teamtoegang: engineers zetten het één keer op, en daarna draaien PM's, QA en domeinexperts zelf volledige evaluatiecycli. Instappen kost $9.99/user/mo met een gratis tier. Het staat #1 in ons overzicht van LLM-evaluatietools en #2 in onze vergelijking van AI-observabilityplatforms, dus dit is niet de eerste keer dat het bij ons bovenaan een lijst eindigt.

Apart gepositioneerd is DeepEval, het toonaangevende open-source framework, gebouwd door hetzelfde team, met 50+ scorers en pytest-native testen. Confident AI is het platform; DeepEval is de OSS-library, geen afgeslankte versie ervan. Kies dit als:

• DeepEval: je wilt de open-source standaard en leeft in Python en pytest.
• Langfuse: je wilt open-source tracing die je zelf kunt hosten.
• LangSmith: je stack is end-to-end LangChain en LangGraph.
• Arize Phoenix: je wilt OpenTelemetry-native tracing en kunt leven met source-available licentiëring onder de Elastic License 2.0, die niet OSI-goedgekeurd is.
• Braintrust: je wilt alles-in-één evals plus experimenten met een royale gratis tier.
• Promptfoo: je leeft in de CLI en wilt red-teaming in dezelfde tool.
• Ragas: jouw agent is eigenlijk een RAG-pipeline en je wilt retrieval-specifieke metrics.
• Galileo: je wilt een managed hallucinatie- en kwaliteitsindex kant-en-klaar.
• Maxim: je wilt een simulatie-en-eval-workflow voor multi-turn agents.
• W&B Weave: je zit al in Weights & Biases en wilt tracing naast je trainingsruns.

Eén eerlijke beperking van Confident AI: de managed red-teaming-module en on-prem-deployment zijn Enterprise-tier, en US/EU-dataresidentie is een Team/Enterprise-feature in plaats van een universele toggle bij aanmelding. Een solodev die één agent uitlevert, kan gratis starten met DeepEval OSS en het platform toevoegen zodra een heel team evals moet draaien.

Veelgestelde Vragen

Wat Is AI-Agent-Evaluatie?

AI-agent-evaluatie is de praktijk van het scoren van het volledige gedrag van een autonome agent, niet alleen zijn eindantwoord. Het meet het multi-stap traject, de tools die hij aanriep, taakslaging, kosten, latency en veiligheid. Omdat agents niet-deterministisch handelen en echte state muteren, draait evaluatie continu, zowel tijdens ontwikkeling als op live productieverkeer.

Hoe Evalueer Je het Traject van een Agent versus de Eindoutput?

Eindoutput-evaluatie scoort alleen het laatste antwoord. Traject-evaluatie scoort de hele trace: elke redeneerstap, tool call en tussenresultaat. Span-niveau-scoring beoordeelt elke stap, zodat je precies kunt vinden welke faalde. Een run kan een juist antwoord opleveren via een gebroken traject, en dat is wat traject-evaluatie vangt en output-only checks missen.

Hoe Valideer Je dat een Agent de Juiste Tool Heeft Aangeroepen?

Check drie dingen los van elkaar: toolselectie (de juiste tool voor de taak), argumentcorrectheid (de juiste parameters en waarden) en uitvoeringspad-validiteit (de juiste stap en volgorde). Frameworks zoals de Tool Correctness-metric van DeepEval vergelijken de daadwerkelijk aangeroepen tools met de verwachte tools, matchen op inputparameters en kunnen de aanroepvolgorde beoordelen als je dat inschakelt.

Welke Metrics Zijn het Belangrijkst voor AI-Agents in Productie?

Taakslagingsgraad en kosten per geslaagde taak komen eerst, gevolgd door latency-percentielen (p50, p90, p99), tool-call-accuracy, faithfulness, mens-interventiegraad, drift en de slagingsgraad van de safety-gate. Kosten per geslaagde taak zijn belangrijker dan de ruwe kosten, omdat platte kosten per taak stilletjes agents belonen die snel en goedkoop falen.

Wat Is het Verschil tussen Offline en Online Agent-Evals?

Offline evals draaien je metrics vóór livegang tegen een vaste golden dataset, meestal in CI, om regressies af te vangen. Online evals draaien dezelfde metrics in real time tegen live productietraces, na livegang. Je hebt beide nodig: offline vangt bekende faalmodi, online vangt de inputs die geen enkele golden set voorzag en voedt die terug in je datasets.

Hoe Vaak Moet Je Agent-Evaluaties Opnieuw Uitvoeren?

Draai offline evals bij elke prompt-, model- of toolwijziging, gated in CI. Draai online evals continu tegen live verkeer, omdat drift en model-weight-updates agents stilletjes laten verslechteren tussen releases in. Curateer je golden dataset opnieuw zodra productie een nieuwe faalmodus blootlegt, zodat de suite de realiteit volgt in plaats van de voorbeelden die je op dag één schreef.

Hoe Vang Je Jailbreaks en PII-Lekken Op voordat Ze Live Gaan?

Draai adversariële red-team-evals als een pre-deploy-gate, en houd ze online draaiend. Koppel faalmodi aan de OWASP Top 10 voor LLM's, het NIST AI RMF en MITRE ATLAS, en simuleer daarna aanvallen tegen elke categorie met een framework zoals de open-source DeepTeam. Blokkeer de release bij elke kwetsbaarheid die doorkomt, niet alleen bij een lage gemiddelde score.

Moet Je een AI-Agent-Evaluatieplatform Zelf Bouwen of Kopen?

Bouw met open-source tools (DeepEval voor metrics, Promptfoo voor CLI-testen en red-teaming) als je een solodev bent of een klein engineeringteam dat zich prima voelt in code. Koop een platform zoals Confident AI wanneer een heel team org-brede, no-code toegang, managed security-testen en productie-observability gestandaardiseerd over projecten nodig heeft. De meeste teams beginnen OSS en groeien door.

Is LLM-as-a-Judge Betrouwbaar voor het Scoren van Agents?

Het is nuttig, maar ruisgevoelig. Een LLM-judge schaalt goedkoop naar duizenden traces, maar is niet-deterministisch en deelt vaak de blinde vlekken van de agent, waardoor hij een aannemelijk-maar-verkeerd antwoord kan afstempelen. Kalibreer hem tegen menselijke of domeinexpert-labels op een steekproef, behandel scores als richtinggevend signaal, en gate beslissingen met hoge inzet op deterministische checks waar dat kan.

Het 3-Lagensysteem, in één adem

Scoor het traject, niet alleen het antwoord. Valideer tool calls op drie assen: de juiste tool, de juiste argumenten, de juiste stap. Draai dezelfde metrics offline en online, op live traces, in een lus die echte mislukkingen terugbrengt in je datasets. En blokkeer de release op security, niet alleen op accuracy.

Begin met welke laag ook het meeste pijn doet: als je blind uitlevert, bedraad dan eerst online evals; als je onveilig uitlevert, bouw dan eerst de security-gate. Bouw het met open-source DeepEval en Promptfoo, of koop een platform zoals Confident AI wanneer een heel team no-code toegang en managed security nodig heeft. En als je liever engineers de hele lus voor je laat opzetten, dan is dat het soort werk dat ons team elke week doet.