AI Agent-evaluatie in productie: van traces naar testsuites

Viacheslav Dubrov

2026-06-10 · Bijgewerkt 2026-09-06 · 26 min · AI-agenten

Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

Artikel bijgewerkt

Oorspronkelijk gepubliceerd op 10 juni 2026. Beoordeeld en bijgewerkt op 6 september 2026. De update behandelt nieuwere agent benchmarks, revisies van graders en bewijs voor de invloed van infrastructuur op scores.

Een final answer kan zeggen dat een terugbetaling is voltooid, terwijl de trace laat zien dat verify_identity nooit is uitgevoerd, issue_refund 17 keer opnieuw is geprobeerd, of de agent succes meldde voordat de database was gewijzigd. Grading op alleen het antwoord verbergt die fouten.

Voor engineers die tool-using agents in productie beheren, is de oplossing om herhaalbare traces om te zetten in afgebakende regression cases: deterministische checks dwingen toolvolgorde, argumenten, loops en invariants af; calibrated judges behandelen beslissingen die interpretatie vereisen. Het resultaat is een versioned suite die dezelfde fout vóór de volgende release detecteert.

Zie voor de korte vergelijking van tools Best AI Agent Evaluation Tools.

Waarom agent-evals anders zijn

Traditionele LLM-evals scoren doorgaans één input-outputpaar: relevantie, faithfulness, correctheid, safety en soms stijl. Agents voegen planning, tool calls, retries en termination checks toe, waarbij elke stap een nieuwe faalplek vormt.

Neem een refund agent. Het transcript kan goed eindigen terwijl de trace fout is:

lookup_order -> issue_refund -> final_answer

De output-eval slaagt. Een trajectory-eval zou moeten falen omdat verify_identity nooit vóór issue_refund is uitgevoerd. Voor tool-using agents kunnen answer-only evals fouten in contentkwaliteit detecteren, maar ze kunnen niet aantonen dat de agent een geldige trajectory heeft gevolgd of de vereiste side effects heeft geproduceerd.

Er is een tweede probleem: fouten stapelen zich op. Als een workflow 20 vereiste stappen heeft, elke stap onafhankelijk slaagt en elke stap dezelfde betrouwbaarheid van 95% heeft, komt het end-to-end succespercentage uit op ongeveer 36%:

De agent kan dus solide lijken in geïsoleerde checks en toch in de meeste volledige runs falen. De breuk zit meestal ergens in het midden. Die vinden vereist visibility op componentniveau, niet nog een inspectie van het antwoord.

Twee onderzoeksteams hebben dit gekwantificeerd.

tau-bench geeft een agent airline- en retail-klantenservicetaken. De agent praat met een gesimuleerde gebruiker, roept APIs aan en moet het domeinbeleid volgen. Na het gesprek controleert de grader of de database de geannoteerde goal state heeft bereikt. Een plausibel transcript met de verkeerde rows faalt nog steeds.

Onder die grading loste GPT-4o slechts 35,2% van de airline-taken op en iets meer dan 60% van de retail-taken. Het paper introduceerde ook pass^k: de kans dat alle k onafhankelijke trials slagen, gemiddeld over de taken.

Retail, de eenvoudigere split, had pass^8 onder 25%. Voor een willekeurig geselecteerde retail-taak en acht onafhankelijke trials lag de kans dat alle acht runs slaagden onder 25%. Een eval met één run kan die consistentie niet meten.

MAST onderzoekt waarom agents falen. De auteurs bouwden een taxonomy met 14 modes op basis van 150 handmatig geannoteerde traces en pasten die vervolgens toe op meer dan 1.600 traces uit 7 populaire multi-agent frameworks. De taxonomy omvat vage role definitions (system design), een agent die negeert wat een andere agent heeft gerapporteerd (inter-agent misalignment) en succes melden zonder het resultaat te controleren (no verification). Deze fouten wijzen op prompts, orchestration-logica en ontbrekende checks in de harness. Een sterker base model kan geen verification step uitvoeren die nooit is gebouwd. Het evaluatiedoel moet daarom ook de harness rond het model omvatten.

De adoptiekloof

De State of Agent Engineering-survey van LangChain (1.340 respondenten, uitgevoerd eind 2025) suggereert dat veel teams al over het ruwe materiaal voor betere evals beschikken. Volgens de survey had 89% enige observability, voerde 52,4% offline evals uit en voerde 37,3% online evals uit.

De survey meldt ook dat 57,3% van de respondenten al agents in productie heeft. Op de vraag wat productie blokkeert, noemde 32% quality en 20% latency. Dit is een vendor survey onder zijn respondenten, geen census van agent-teams, maar de resultaten maken een nuttige kloof zichtbaar tussen trace collection en systematische evaluatie.

Teams blijven daardoor in een ongemakkelijke tussenfase steken: ze kunnen achteraf een slechte run inspecteren en vervolgens nog steeds twee keer dezelfde fout shippen.

Elke gediagnosticeerde production failure moet een trace, een label, een dataset row en een scorer achterlaten. Een herhaalbare fout hoort in de regression suite.

Kies metrics op basis van de failure mode

De juiste metric hangt af van de failure mode, niet van het framework. De nuttige verdeling bestaat uit drie niveaus:

1. Outcome evals beantwoorden of de taak is geslaagd.
2. Trajectory evals beantwoorden of het pad geldig, efficiënt en policy-compliant was.
3. Component evals beantwoorden welke tool, retriever, sub-agent of decision step faalde.

Elk niveau kan offline worden uitgevoerd op vaste, replayable cases vóór een release, of online op sampled production traces na het antwoord. De sectie over guardrails behandelt dat onderscheid in detail. Offline evals kunnen goldens vereisen: opgeslagen cases die een input koppelen aan de outcome, tool invariants en argumenten die een correcte run moet produceren. Online evals geven de voorkeur aan invariants, distributions en async checks die buiten het request path blijven.

Begin met deterministische metrics. Ze zijn reproduceerbaar voor vaste inputs en code en kosten weinig om uit te voeren. Hun regels kunnen wel verouderd raken wanneer tools of policy veranderen. Versioneer daarom de scorer samen met de specificatie die hij controleert.

Tool-call correctness

Tool correctness vergelijkt de aangeroepen tools met de verwachte tools. Kies de strictness bewust:

• Exact match: de sequence moet exact overeenkomen. Gebruik dit wanneer volgorde policy is, bijvoorbeeld lookup_order -> verify_identity -> issue_refund.
• In-order match: required tools moeten in de juiste relatieve volgorde voorkomen, maar extra onschadelijke calls zijn toegestaan.
• Any-order match: required tools moeten voorkomen, maar de volgorde mag variëren.

Een kleine lokale scorer is voldoende om te beginnen:

from collections import Counter

def tool_correctness(called: list[str], expected: list[str], mode: str = "in_order") -> float:
    if mode not in {"exact", "in_order", "any_order"}:
        raise ValueError(f"unknown matching mode: {mode}")
    if mode == "exact":
        return float(called == expected)
    if not expected:
        return 1.0
    if mode == "any_order":
        matched = sum((Counter(called) & Counter(expected)).values())
        return matched / len(expected)

    rows = [[0] * (len(expected) + 1) for _ in range(len(called) + 1)]
    for i, tool in enumerate(called):
        for j, wanted in enumerate(expected):
            if tool == wanted:
                rows[i + 1][j + 1] = rows[i][j] + 1
            else:
                rows[i + 1][j + 1] = max(rows[i][j + 1], rows[i + 1][j])
    return rows[-1][-1] / len(expected)

called = ["lookup_order", "check_refund_policy", "issue_refund"]
expected = ["lookup_order", "verify_identity", "issue_refund"]

print(round(tool_correctness(called, expected, "exact"), 3))     # 0.0
print(round(tool_correctness(called, expected, "in_order"), 3))  # 0.667
assert tool_correctness(["issue_refund"], [], "exact") == 0.0
assert tool_correctness([], [], "exact") == 1.0
assert tool_correctness(["a", "b"], ["a", "a", "b"], "any_order") == 2 / 3
try:
    tool_correctness([], [], "typo")
except ValueError:
    pass
else:
    raise AssertionError("unknown modes must fail")

De score van in_order is longest-common-subsequence recall: welk percentage van de vereiste sequence in de juiste volgorde behouden bleef. Let op wat deze metric negeert. Junk calls verlagen de score niet. Een agent kan hier dus 1.0 scoren terwijl hij twee keer zoveel calls doet als nodig. Wanneer extra calls geld kosten of state muteren, moet je daarnaast precision bijhouden (gematchte required calls gedeeld door het totale aantal calls) en beide metrics samen interpreteren. Recall detecteert de ontbrekende stap; precision detecteert het rondzwerven. Noch een recall-score van 1.0, noch hoge precision geeft toestemming voor extra mutaties. Controleer elke state-changing call op permissions, resource, argumenten en de vereiste voorafgaande verification. Bij een lege expected list betekent alleen exact mode “geen calls toegestaan”; de andere modes hebben geen positieve requirements.

DeepEval’s Tool Correctness metric biedt dezelfde instelmogelijkheden via should_consider_ordering en should_exact_match.

Argument correctness

De juiste tool aanroepen met de verkeerde argumenten is vaak erger dan de verkeerde tool aanroepen, omdat de trace er normaal uitziet.

Valideer in eenvoudige gevallen JSON Schema en exacte waarden. Sla voor semantische gevallen de verwachte argumenten op en grade de deltas:

{
    "trace_id": "tr_2417",
    "input": "Reschedule order A-100 for June 19, 2026.",
    "expected_tools": ["lookup_order", "reschedule_delivery"],
    "expected_arguments": {
        "reschedule_delivery": {
            "order_id": "A-100",
            "date": "2026-06-19"
        }
    }
}

Een tool-name metric kan 2026-06-17 niet detecteren wanneer de policy 2026-06-19 vereist. De dataset moet dus ook argumenten opslaan.

Voor deze illustratie met één call per tool is parameter-match het aandeel van de verwachte (tool, key, value)-triples dat de agent correct heeft. De onderstaande dictionaries zijn alleen geldig wanneer elke relevante tool maximaal één invocation heeft. Bouw ze niet door eerdere calls met dezelfde naam te overschrijven: daarmee verberg je een verkeerde refund gevolgd door een correcte. Bewaar bij repeated calls de call IDs en volgorde, match de bedoelde invocation en valideer elke mutatie afzonderlijk.

def argument_correctness(called_args: dict, expected_args: dict) -> float:
    total = matched = 0
    for tool, params in expected_args.items():
        for key, want in params.items():
            total += 1
            if key in called_args.get(tool, {}) and called_args[tool][key] == want:
                matched += 1
    return matched / total if total else 1.0

assert argument_correctness({}, {"reschedule_delivery": {"date": None}}) == 0.0
assert argument_correctness({"reschedule_delivery": {}},
                            {"reschedule_delivery": {"date": None}}) == 0.0
assert argument_correctness({"reschedule_delivery": {"date": None}},
                            {"reschedule_delivery": {"date": None}}) == 1.0

Exact equality is correct voor IDs, enums en dates die al naar één format zijn genormaliseerd. Het is verkeerd voor free text, floats en dates in de vorm die het model toevallig produceerde, waarbij == een correct antwoord als fout markeert. Grade zulke fields volgens hun eigen regels: een normalized string match, een date parse of een numeric tolerance. De metric blijft hetzelfde; alleen de comparator per field verandert.

Efficiency, loops en dead ends

Een agent die de taak voltooit na vijf redundante tool calls laat nog steeds een planningprobleem zien en kost meer om uit te voeren.

Begin met deze goedkope signalen:

• Redundant-call rate: identieke tool calls met identieke argumenten die meer dan twee keer worden herhaald.
• Trace-shape anomalies: plotselinge pieken in depth, het aantal tool calls, het aantal tokens, latency of cost.
• Path convergence: hoe dicht de run bij het kortste bekende geldige pad voor de taak ligt.
• Termination correctness: of de agent te vroeg stopte, na succes bleef werken of succes meldde zonder de vereiste state change.
• Plan adherence: als de agent vóór het handelen een plan schrijft, controleer dan of de trace dat plan volgde. Een goed plan dat wordt genegeerd en een slecht plan dat perfect wordt gevolgd, falen beide om tegengestelde redenen. Het verschil tussen plan en trace laat zien welke situatie van toepassing is.

Voer deze checks waar mogelijk vóór een judge uit. Een loop detector bestaat uit enkele regels over de trace. Daar is geen model voor nodig.

Task completion en outcome grading

Bij grading op de outcome luidt de vraag: “heeft de gebruiker gekregen waar die om vroeg?”

Twee patronen werken het best:

• Referenceless task-completion judging: haal het doel uit de input en beoordeel of de trace plus het final answer dat doel heeft bereikt. Dit werkt online omdat production traffic zelden golden outputs heeft.
• Environment-state grading: vergelijk de uiteindelijke database rows, files, tickets, bookings of records met een geannoteerde goal state. Dit is robuuster dan transcript matching, omdat agents geldige paden kunnen vinden die je niet vooraf hebt uitgeschreven.

De tweede optie is beter wanneer je die kunt bouwen. De final state is het contract. Het transcript is slechts evidence.

Twee kanttekeningen houden dit eerlijk. Een 2025 audit van agentic benchmarks stelde vast dat tau-bench sommige taken puur op basis van de database state gradeert. Bij sommige taken vereist de geannoteerde outcome geen state change en geen specifieke tekst. Een agent die niets doet kan dan een pass scoren: 38% op de airline-split en 6,0% op retail, bij elke k. Anthropic rapporteerde een run met Opus 4.5 die een booking task in tau2-bench, de opvolger van de benchmark, “faalde”. De agent vond een policy loophole die voor de gebruiker feitelijk de betere outcome was. State grading is beter dan transcript matching, maar de goal state blijft een annotatie en annotaties kunnen bugs bevatten. Audit ook cases die te gemakkelijk slagen, niet alleen cases die falen.

Benchmarkversies en environments veranderen het resultaat

De oorspronkelijke tau-bench-cijfers hierboven verklaren repeated-trial reliability; ze zijn niet de huidige model leaderboard. De onderhouden tau-bench repository presenteert nu tau3-bench, met knowledge retrieval en full-duplex voice. De grading fix in v1.0.1 van juli 2026 verandert de banking_knowledge-scores: resultaten uit eerdere versies zijn voor dat domein niet vergelijkbaar. Pin de task- en grader-revisies naast het model en re-score opgeslagen trajectories wanneer een annotatie wordt gecorrigeerd.

Kies een benchmark die de gedeployde interface test. Text-only klantenservicetests kunnen interruption handling in een voice agent niet aantonen. Knowledge-retrievaltaken hebben ook de corpus, search configuration en beschikbare evidence op elke turn nodig. Gebruik deze task shapes als basis voor lokale regression cases in plaats van een public leaderboard-rank als releasecriterium te importeren.

De sandbox is eveneens onderdeel van de test. Anthropic’s infrastructuurstudie van februari 2026 vond een verschil van zes procentpunten op Terminal-Bench 2.0 tussen de strict en uncapped resource setups met hetzelfde model, dezelfde harness en dezelfde taken. Extra headroom verminderde zowel infrastructure failures als maakte andere solution strategies mogelijk. Leg CPU- en RAM-guarantees en -limits, timeouts, concurrency, network access en de afhandeling van infrastructure errors vast. Rapporteer deze failures afzonderlijk en laat ze niet stilzwijgend weg uit de denominator van expected tasks.

Component evals

Outcome- en trajectory metrics vertellen je dat de run faalde en ongeveer waar. Component evals scoren één span: was de retrieved chunk relevant, retourneerde de sub-agent het schema dat de caller verwachtte, kon de eigen response van de tool worden geparsed? Koppel de score aan de span in plaats van aan de run, zodat “welke tool is deze week slechter geworden?” een query is en geen re-run.

Drie checks dekken het grootste deel:

• Per-span scoring: voer de metric uit die bij het type span past. Retrieval-spans krijgen recall en precision tegen de geannoteerde chunk, sub-agent-spans krijgen schema validation plus hun eigen tool-correctness score, tool-spans krijgen error rate en latency.
• Tool-result interpretation: geef de agent een correct maar lastig tool output (een lege lijst, een partial match, een stale timestamp) en controleer wat hij daarna doet. Een tool kan correct zijn terwijl de agent die verkeerd leest; die fout wordt twee stappen later zichtbaar.
• Failure attribution: de zichtbare failure is doorgaans downstream van de werkelijke fout. Ken de fout toe aan de vroegste span waarvan de output al verkeerd was, niet aan de stap die de error opwierp.

Hier komt ook de compounding math uit de opening terug. Als 20 stappen er afzonderlijk goed uitzien, kan de run nog steeds meestal falen. Per-span pass rates laten zien welke stap op 95% draait en welke op 70%.

De trace-to-eval flywheel

Mine production failures voordat je extra eval-cases gaat bedenken.

De loop:

1. Verzamel voldoende trace evidence om de failure te reconstrueren, met gecontroleerde sensitive content.
2. Label wat er faalde.
3. Group vergelijkbare failures.
4. Behoud representative goldens, inclusief varianten die verschillende outcomes vereisen.
5. Versioneer de dataset.
6. Voer die uit in CI.
7. Blijf sampled production traces online scoren.

De companion repository trace2evals implementeert de volledige loop voor een faulty support agent. De repository verzamelt OpenTelemetry GenAI-spans, detecteert failures met deterministische regels, dedupliceert cases tot een versioned golden dataset en draait elke golden opnieuw in CI. De default backend vervangt het model door deterministische regels die de beslissingen van de buggy agent opnieuw uitvoeren, zodat make demo de volledige loop offline zonder API key reproduceert. Voer uv sync --extra live uit en stel een API key in; dezelfde commands sturen dan in plaats daarvan een echt model aan.

Dit is een teaching pipeline. De revisie die op 6 september 2026 is beoordeeld bevat nog scorer edge cases, authorization checks op basis van namen en gedeelde trial state. De trace adapter verwacht zijn eigen span attributes en message shapes. De gecorrigeerde voorbeelden hier werken de repository niet bij en vormen geen production authorization; valideer de geslaagde, resource-bound authorization van elke mutatie en isoleer trials voordat je op het CI-verdict vertrouwt.

Mine failures met error analysis

Hamel’s field guide laat de workflow zien: inspecteer echte gesprekken, maak open-ended notes, categoriseer failures en bouw specifieke tests.

1. Inspect traces en schrijf open-ended notes over wat er misging.
2. Group recurring failures in benoemde categories.
3. Label traces volgens die taxonomy.
4. Build specific tests voor de grootste actionable clusters.

Begin niet met labels zoals reasoning_issue of tool_problem. Ze zijn te vaag om te testen. Gebruik labels zoals missing_identity_verification, date_argument_mismatch, retried_same_tool_after_429 of stopped_before_database_update. Een label met die specificiteit zegt precies wat de regression test moet asserten.

Deduplicate voordat je cases promoveert

De trace-mining loop heeft een valkuil: elke slechte trace voor altijd toevoegen. Daardoor ontstaat een dataset die groot, duur en smal is. De suite slaagt op near-duplicates uit maart, maar mist de nieuwe vorm van dezelfde bug in juni.

Group eerst. Begin met één representative golden per cluster en behoud daarna varianten met verschillende permissions, argumenten, recovery states of expected outcomes. Vergelijkbare bewoordingen maken twee policy cases niet equivalent. Sla gerelateerde trace IDs op in access-controlled metadata, zodat een reviewer de evidence later kan inspecteren.

Als een failure cluster na een fix opnieuw optreedt, heeft de regression case niet voldoende gegeneraliseerd. Herzie de cluster en voeg de ontbrekende behavioral variants toe in plaats van near-identieke transcripts te verzamelen.

Versioneer de dataset

Versioneer datasets zoals je prompts en code versioneert. Wanneer er iets betekenisvols verandert (model, prompt, tool schema, judge prompt of app behavior), wil je dezelfde datasetversie vóór en na de wijziging uitvoeren.

De CI-check moet het volgende pinnen:

• datasetversie
• appversie
• promptversie
• judge model
• judge prompt
• versie van de evaluatorcode
• tool schemas, policy, harness en context-managementconfiguratie
• modelrevisie, reasoning- en samplinginstellingen
• initiële environment fixture en toegestane external effects

Als een van die onderdelen verandert, wordt je before/after comparison onduidelijk. Een goldens-v3.json-bestand in git is op kleine schaal prima. Tool-native snapshots in Langfuse, Phoenix, Braintrust of LangSmith helpen zodra de dataset collaborative wordt.

Houd development regressions, judge-calibration examples, held-out validation en monitoring samples gescheiden. Group gerelateerde sessions, users en tasks vóór het splitten, zodat near-duplicates niet over de sets lekken. Zodra een case een prompt of rubric beïnvloedt, behandel je die als development evidence. Een mined failure suite test bekende regressions; het gemiddelde ervan schat de production success rate niet.

Reset mutable state voor elke trial: files, database rows, caches en tool fixtures. Isoleer credentials en external effects en houd candidate- en baseline-budgets gelijk. Rapporteer het aantal tasks afzonderlijk van trials, samen met alle gestarte attempts, timeouts, crashes en unscorable outcomes. Vergelijk paired results op dezelfde tasks. Deze keuzes volgen de aanpak met clean trials en outcome grading uit Anthropic’s evaluation guide.

Run evals in CI

Een release check moet de build laten falen wanneer een metric de afgesproken limiet overschrijdt. Anders is de eval suite slechts een dashboard.

Na het herstellen van de case fixture in een geïsoleerde trial moet de test de huidige agent opnieuw uitvoeren tegen de golden input. De test moet niet slechts de oude failed trace replayen (schets; de runnable versie staat in de companion repository):

@pytest.mark.parametrize("golden", GOLDENS, ids=[item["id"] for item in GOLDENS])
def test_agent_regression(golden: dict) -> None:
    answer, fresh_trace = run_agent_and_capture_trace(golden["input"])

    refired = set(flag_failures(fresh_trace)) & set(golden["failure_modes"])
    assert not refired, f"failure mode regressed: {sorted(refired)}"

    assert tool_correctness(
        called=[call["name"] for call in fresh_trace["tool_calls"]],
        expected=golden["expected_tools"],
        mode=golden.get("tool_match", "in_order"),
    ) >= golden.get("tool_threshold", 1.0)

Dit onderscheid is gemakkelijk verkeerd te implementeren. De taak van de dataset is de volgende versie van de agent betrappen wanneer die een oude fout opnieuw maakt, niet de fout zelf archiveren.

Kalibreer de judge voordat je erop vertrouwt

LLM-as-judge helpt. Je kunt jezelf er ook gemakkelijk mee voor de gek houden.

G-Eval evalueert drie meta-evaluation benchmarks. Dat zijn SummEval, opgebouwd uit CNN/DailyMail-nieuwssamenvattingen; Topical-Chat, een knowledge-grounded dialogue benchmark; en QAGS, dat factual consistency test op CNN/DailyMail- en XSum-samenvattingen. Met GPT-4 als backbone bereikte G-Eval-4 een Spearman-correlatie van 0,514 met human judgments op SummEval. De scoring function weegt rating levels op basis van token probability ($\text{score} = \sum_i p(s_i)\,s_i$).

Het paper schatte GPT-4’s token probabilities door 20 keer te samplen, omdat dat model ze in het experiment niet beschikbaar stelde. Een hosted model kan geen bruikbare logprobs aanbieden. Behoud daarom de rubric, maar suggereer niet dat je de probability weighting uit het paper hebt gereproduceerd. Deze resultaten vergelijken het protocol uit het paper met de NLG-baselines op die benchmarks. Ze ondersteunen het testen van een judge met een expliciete rubric, niet een algemene vervanging van automatic metrics of een production-agent trajectory benchmark.

MT-Bench liet zien dat GPT-4 ongeveer even vaak met human preferences overeenkwam als mensen onderling. Dat resultaat hielp LLM judging mainstream te maken. Later onderzoek bracht position-, length- en self-preference-biases aan het licht. Judge scores kunnen ook verschuiven wanneer de prompt- of modelversie verandert.

JudgeBench bouwde response pairs waarin één antwoord objectief fout is op het gebied van verifiable knowledge, reasoning, math en code. Met een gewone judge prompt scoorde GPT-4o 50,9%, nauwelijks boven een coin flip; de sterkere Arena-Hard prompt uit het paper bracht hetzelfde model slechts naar 56,6%. Het model verwisselen onder die sterkere prompt is belangrijker: Claude 3.5 Sonnet, de beste general-purpose judge in de test, bereikte 64,3%, en o3-mini met high reasoning effort 80,9%. Confident maar verkeerde antwoorden blijven moeilijk voor een judge die niet redeneert voordat hij gradeert.

Behandel de judge als een meetinstrument: kalibreer hem tegen human labels voordat hij iets gradeert en controleer opnieuw wanneer het judge model of de prompt verandert.

Wanneer een judge nodig is, maak het verdict structured. Schema-Guided Reasoning (SGR) geeft het verdict een schema voor de output shape en inspectability. Structured Outputs of constrained decoding kan object shape, required fields en value constraints afdwingen voor fields zoals evidence, passed_criteria, failed_criteria, failure_mode en score.

Zet evidence fields vóór de score als dat het record gemakkelijker inspecteerbaar maakt. Field order is presentatie, geen garantie voor reasoning. Een schema-valid verdict kan nog steeds unsupported evidence of een unreliable score bevatten. Gebruik calibration tegen human labels, deterministic validators en transcript review om judge reliability te testen. CI kan een stabiel JSON object diffen, maar dat controleert inspectability en shape; het bewijst niet dat rubric stages zijn gevolgd.

Een structured verdict kan ook de cost curve veranderen. Behandel een goedkoper model als kandidaat, niet als automatische replacement. Laat het over dezelfde human-labeled calibration set lopen. Vergelijk agreement, false-pass rate en false-fail rate met de grotere judge. Gebruik het alleen voor routine cases als het de thresholds van je applicatie haalt. Behoud de grotere judge voor disagreements, high-risk cases of calibration runs.

Standaardchecklist voor judge hygiene:

1. Geef waar mogelijk de voorkeur aan binary pass/fail. Schalen met vijf punten nodigen uit tot fake precision.
2. Label trajectories die de werkelijke failure modes afdekken voordat je de rubric definitief maakt. Kies de sample size op basis van coverage en de onzekerheid die de beslissing kan verdragen en reserveer afzonderlijke cases voor validation.
3. Meet judge-human agreement met Cohen’s kappa, een confusion matrix en positive/negative recall. Kappa meet agreement na correctie voor agreement die door toeval wordt verwacht; hoger is beter. Een judge die altijd “pass” zegt, discrimineert niet bruikbaar, waardoor kappa nul of undefined kan zijn. Bepaal wat je doet wanneer de metric undefined is voordat je hem gebruikt om een release goed te keuren.
4. Decompose coarse criteria. “Heeft de agent identity geverifieerd vóór de refund tool call?” is beter dan “Was de trajectory goed?”
5. Emit het verdict via een SGR-schema met evidence, failed criteria, failure mode en score.
6. Vergelijk same- en cross-family judges tegen held-out human labels; family separation alleen bewijst geen reliability.
7. Meet pairwise order sensitivity. Behoud randomization of swapped-order aggregation alleen als dit held-out decisions verbetert; een controlled study uit 2026 vond dat swapping op adversarial cases juist schadelijk kon zijn.
8. Geef geen credit voor extra tekst tenzij die correcte, relevante en ondersteunde content toevoegt. Een langer antwoord is geen beter antwoord.
9. Pin het judge model, de prompt, dataset, schema en appversie.
10. Recalibreer na wijzigingen aan model, prompt, tool, policy of schema.

Een panel is een andere kandidaat om te testen. PoLL rapporteerde betere alignment met human judgments, minder intra-model bias en lagere cost dan zijn single-GPT-4-baseline over zes datasets. Die resultaten horen bij de gebruikte models, tasks en historische prijzen. Ze tonen niet aan dat een panel veiliger is voor jouw task. Vergelijk false passes, false failures, cost en disagreement workload met één calibrated judge op held-out labels.

Er bestaat geen universele kappa-threshold die een judge geschikt maakt voor CI. Rapporteer de confusion matrix, label counts, false-pass rate onder human failures en false-fail rate onder human passes, inclusief onzekerheid. Kies release limits op basis van de gevolgen van die errors. Gebruik review queues wanneer evidence te zwak is voor automatische acceptatie en behoud human authorization voor consequential actions wanneer de workflow dat vereist.

Guardrails blokkeren inline, online evals observeren achteraf

Mensen halen deze zaken door elkaar omdat beide scores opleveren. Het verschil zit in de placement: inline in het request path, vóór de release of na de response.

Guardrails draaien inline. Ze zijn snel en zichtbaar voor de gebruiker. Een guardrail kan een tool call blokkeren, PII redigeren, prompt injection afwijzen of vóór de response je systeem verlaat een retry afdwingen. Een false positive is een production bug. Een false negative is stiller en erger, omdat niets in het request path dit rapporteert. Schema-, range- en policy-checks zijn deterministisch. Injection- en PII-detectie zijn classifiers. Behandel misses daarom als te verwachten en houd een async eval aan die controleert wat erdoorheen komt.

Offline evals draaien vóór een release. Ze zijn reproduceerbaar en controleren prompts, models, tools, retrievers en policies tegen een vaste dataset.

Online evals draaien na de response, meestal op sampled traffic. Ze kunnen tragere LLM judges gebruiken omdat ze niet in het latency path zitten. Hun taak is drift detecteren, nieuwe failure clusters vinden en de volgende offline dataset voeden.

De verkeerde placement doet in beide gevallen pijn:

• Een judge in het request path voegt latency en een nieuwe bron van flakiness toe.
• Een guardrail die naar async scoring is verbannen, laat policy violations gebruikers bereiken.

Maak bij security tests onderscheid tussen attack detection, een poging tot prohibited action en een harmful effect dat daadwerkelijk slaagt. Rapporteer successful harmful effects per attack trial, met threat model en attempt budget, naast legitimate task success en false blocks per benign trial. Een detector score alleen kan niet aantonen dat data privé is gebleven of dat een write is voorkomen. Gebruik geïsoleerde targets; Anthropic’s cybersecurity evaluation incident report documenteert waarom evaluation effects moeten worden ingeperkt.

Score voor high-volume systems een kleine sample met een sterkere judge en een bredere sample met goedkopere classifiers. Alarmeer op clusters en confidence bounds, niet op één noisy point estimate.

Toolkeuzes

Geen enkele tool beheert de volledige loop. Vergelijk een trace/dataset store en een CI/eval runner afzonderlijk. Eén product kan beide afdekken, maar je hoeft niet beide bij dezelfde vendor af te nemen.

Dit is een author snapshot, gecontroleerd op 2026-09-06. Elke link verwijst naar de actuele documentatie die ik voor de capability claim heb gebruikt. Plans, licenses, API keys, provider access en infrastructuurvereisten blijven van toepassing.

De trade-off-notes beschrijven waar de kosten vandaan komen, niet wat de kosten precies zijn. Pricing pages veranderen en vendors tellen verschillende zaken: traces, observations, spans, scores, users, retention of processed data. Controleer live pricing opnieuw vóór je commit.

Aanbevelingen per constraint:

• Kies Phoenix wanneer self-hosting, privacy en OTel-compatible tracing harde requirements zijn en je team de deployment kan beheren.
• Kies Langfuse wanneer je ook dataset versioning en experiments nodig hebt en je de storage stack kunt beheren of de vereiste add-ons kunt aanschaffen.
• Kies DeepEval wanneer Python/pytest CI pass-fail het primaire contract is.
• Kies Inspect AI wanneer het belangrijkste werk safety- of frontier-agent evaluation in configureerbare sandboxes is.
• Kies LangSmith wanneer LangChain/LangGraph-integratie in je workflow past; gebruik Cloud of houd rekening met de Enterprise-requirement voor BYOC of self-hosted platform hosting.
• Kies Braintrust wanneer managed pull-request feedback en experiment comparison een API-key-backed service rechtvaardigen.
• Kies Promptfoo wanneer prompt- of red-team checks de belangrijkste regression surface zijn en een trace store buiten scope valt.

Toolkeuze is secundair. Als production failures geen test cases worden, betaal je vooral voor trace storage.

Praktische rollout-checklist

Bouw eerst de evidence pipeline voordat je de metric stack uitbreidt. Begin met bepalen waar de voorbeelden vandaan komen.

1. Verzamel eerst historische runs. Als de agent al bestaat, haal dan traces, support tickets, bug reports, thumbs-down sessions, manual QA transcripts en dogfooding notes op voordat je de implementatie wijzigt. Bestaat de agent nog niet, log dan vanaf dag één elke prototype- en manual testrun.

2. Instrumenteer de trace shape. Leg messages, tool calls, argumenten, tool outputs, errors, token counts, latency, cost, user feedback, app version, prompt version, model version, tool schema version en final environment state vast. Gebruik OpenTelemetry GenAI conventions of OpenInference-style spans als je portability wilt en pin de convention version en adapter. Leg content selectief vast: redact secrets en personal data, beperk access en stel retention in vóór je traces naar datasets promoveert. Gebruik Langfuse, LangSmith, Phoenix of Braintrust als je direct een trace UI en datasetworkflow wilt.

3. Maak van echte failures seed cases. Lees de traces voordat je ze met een model samenvat. Sla voor elke bruikbare failure de input, source trace ID, expected state, expected tool invariants, failure mode, severity en reviewer note op. Langfuse kan dataset items teruglinken naar production traces; LangSmith kan datasets maken uit traced runs. Behoud de source link zodat de case auditable blijft.

4. Als er geen history is, genereer cold-start cases. Vraag een LLM om tasks op te stellen op basis van product requirements, policies, tool schemas, state machines en support macros. Dek happy paths en failures af, zoals verkeerde permissions, ontbrekende identity checks, stale tool results, ambigue dates, retries na rate limits en tegenstrijdige tool output.

5. Vertrouw synthetic cases pas na human review. Synthetic examples zijn nuttig voor coverage, niet voor truth. Markeer ze met source: synthetic en vereis dat een reviewer de expected outcome goedkeurt. Voer waar mogelijk een known-good reference path uit en valideer generated expectations onafhankelijk; het gebruik van een andere model family vervangt die check niet.

6. Bouw een kleine balanced dataset. Neem successes, failures, refusals, boundary cases, long-turn cases, policy-sensitive cases en valid alternate paths op. Maak de golden niet “het exacte oude transcript”. Sla op wat hierboven bij een golden hoort, plus de failure mode waardoor de case in de suite is opgenomen.

7. Voeg eerst deterministic checks toe. Required tool order wanneer order policy is, required arguments, schema validation, final-state diffs, loop limits, token- en latency ceilings en task-specific invariants moeten vóór elke judge draaien.

8. Voeg één SGR-shaped judge toe. Gebruik deze alleen voor het deel dat interpretatie nodig heeft. Kalibreer hem tegen human labels en test de gekozen rubric op untouched validation cases. Als de judge goede en slechte voorbeelden niet kan scheiden op de calibration set, herstel dan eerst de rubric voordat je hem aan CI koppelt.

9. Verbind de loop. Draai de kleine offline suite in CI, de grotere suite vóór release, score sampled production traffic online en promoveer terugkerende online failure clusters naar de offline dataset.

Je eerste eval suite zal cases missen. Voer hem toch uit en voeg daarna terugkerende failures als cases toe. Een suite die dagelijks draait levert evidence om hem te verbeteren.

Referenties

• trace2evals companion demo repository
• LangChain - State of Agent Engineering
• Anthropic - Demystifying Evals for AI Agents
• Hamel Husain - A Field Guide to Rapidly Improving AI Products
• OpenTelemetry semantic conventions for generative AI systems
• DeepEval Tool Correctness
• DeepEval Task Completion
• DeepEval unit testing in CI/CD
• Inspect running evals
• OpenAI Structured model outputs
• Schema-Guided Reasoning: vLLM, xgrammar, and Pydantic
• Phoenix self-hosting
• Langfuse datasets and versioning
• Langfuse experiments in CI/CD
• LangSmith platform setup
• LangSmith - Create and manage datasets programmatically
• Braintrust - Create experiments
• Phoenix LLM evals
• Promptfoo GitHub Action integration
• tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains
• Why Do Multi-Agent LLM Systems Fail?
• Establishing Best Practices for Building Rigorous Agentic Benchmarks
• G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment
• Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
• Replacing Judges with Juries: Evaluating LLM Generations with a Panel of Diverse Models
• JudgeBench: A Benchmark for Evaluating LLM-based Judges
• Self-Preference Bias in LLM-as-a-Judge