2026-06-10 · Bijgewerkt 2026-07-22

[!NOTE] Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

Evaluatie van AI Agents in productieomgevingen: van Traces tot testsets

Een chatbot geeft je één antwoord ter beoordeling. Een agent levert je een volledige boom van beslissingen op: plannen, tool calls, herproberingen, en het moment waarop het heeft besloten dat de taak is voltooid.

Die verschillen vereisen een andere evaluatiemethode. Een eindantwoord kan er correct uitzien, zelfs wanneer de agent een vereiste tool heeft weggelaten, een aanroep 17 keer heeft herhaald, een resultaat verkeerd heeft geïnterpreteerd, of een pad heeft gevolgd dat volgens de productiebeleid niet is toegestaan. Beoordeling op basis alleen van het antwoord verbergt dergelijke fouten.

TL;DR: Agent evals vereisen drie lagen: resultaatmetrieken, trajectmetrieken en componentmetrieken. Bouw dit op rondom de volgende cyclus: trace -> labeleren -> clusteren -> duplicaten verwijderen -> versiegeven van dataset -> CI-poort -> continue online monitoring. Gebruik deterministische controles voor de volgorde van tools, argumenten, lussen en invarianten. Pas LLM judges alleen toe wanneer de controle afhankelijk is van interpretatie; vorm deze judges met Schema-Guided Reasoning (SGR) en kalibreer ze tegen menselijke labels voordat je ze vertrouwt.

Waarom agent evals verschillen

Traditionele LLM evals beoordelen doorgaans één invoer-uitvoerpaar: relevantie, getrouwheid, correctheid, veiligheid en eventueel stijl. Agents voegt planning, tool calls, herproberingen en beëindigingscontroles toe, waardoor elke stap een nieuwe mogelijkheid vormt om te falen.

Vraag een teruggave aan voor agent. Het transcript kan goed eindigen, zelfs wanneer de trace onjuist is:

lookup_order -> issue_refund -> final_answer

De uitvoer eval is acceptabel. Een traject eval zou moeten falen omdat verify_identity Is nog nooit eerder uitgevoerd. issue_refundVoor het gebruik van tools door agents zijn alleen antwoordgevende evals-opdrachten slechts smoke tests: ze detecteren een complete foutfunctie, maar negeren alle andere mogelijk problemen.

Er is nog een tweede probleem: fouten stapelen zich op. Als een workflow 20 vereiste stappen heeft, waarbij elke stap onafhankelijk succesvol is en elke stap dezelfde betrouwbaarheid van 95% heeft, ligt het eindresultaat in termen van succesratio rond de 36%.

Dus kan de agent in afzonderlijke tests solide overkomen, maar blijft hij toch falen bij de meeste volledige uitvoeringen. De oorzaak ligt meestal ergens halverwege, en om deze te vinden is inzicht op componentniveau nodig, in plaats van nogmaals alleen naar het resultaat te kijken.

Twee onderzoeksteams hebben hier cijfers voor opgesteld.

tau-bench Het biedt taken voor klantenservice bij luchtvaartmaatschappijen en detailhandel via agent. agent communiceert met een gesimuleerde gebruiker, voert APIs uit en moet zich houden aan de specifieke richtlijnen van het domein. Na het gesprek controleert de beoordelaar of de database het gewenste, gecodeerde doestaat heeft bereikt. Zelfs een geloofwaardig transcript met onjuiste gegevens leidt tot een mislukking.

Onder die beoordelingsschaal slaagde zelfs GPT-4o bij minder dan de helft van de taken. Het artikel introduceerde tevens pass^k: uitvoeren van dezelfde taak k Tel het aantal keren en tel een passage alleen als agent in alle gevallen succesvol is. k werkt.

De retailscores die bij een eerste poging nog acceptabel leken, daalden onder de 25% bij k = 8. Hetzelfde agent kreeg acht keer dezelfde taak toegewezen en leverde grotendeels verschillende resultaten op. Een enkele uitvoering van een eval kan deze inconsistentie niet onthullen.

MAST Er worden onderzoeken gedaan naar de oorzaken van het falen van agents. De auteurs hebben meer dan 1.600 uitvoerings traces uit 7 populaire multi-agent frameworks geanalyseerd en de fouten ingedeeld in 14 herhaalde patronen. De taxonomie omvat vage definities van rollen (systeemontwerp), een agent die wat een andere agent rapporteerde negeert (inter-agent misalignement), en het verklaren van succes zonder de resultaten te controleren (geen verificatie). Deze fouten hebben invloed op prompts, orchestration logica en het ontbreken van controles in de harness. Een krachtiger basis model kan geen verificatiestap uitvoeren die nooit is ontwikkeld; daarom moet het evaluatieobject de harness rondom de model omvatten.

De adoptiegap

Uit het onderzoek van LangChain blijkt dat veel respondenten al over de benodigde grondstoffen beschikken voor betere evals: 89% gaf aan enige vorm van observability te hebben, terwijl 52,4% offline evals uitvoerde en 37,3% online evals.

Hetzelfde Toestand van de Agent-engineeringsafdeling Uit onderzoeken blijkt dat 57,3% van de ondervraagden agents al in productie gebruikt. Toen werd gevraagd wat de productie belemmert, noemden 32% kwaliteit als oorzaak en 20% latency. Het gaat hier om een enquête onder klanten van de leverancier, en niet om een volledige inventarisatie van alle agent-teams, maar het toont wel een belangrijk verschil op tussen het verzamelen van trace en een systematische evaluatie daarvan.

Dat brengt teams in een ongemakkelijke tussenpositie: ze kunnen na afloop een mislukte uitvoering onderzoeken, maar ze kunnen dezelfde fout toch nog twee keer leveren.

Bij elke gediagnosticeerde productiefout moet een trace, een label, een dataset-rij en een scorer achterblijven. Een herhaalbare fout past binnen het regressietestpakket.

Kies metrics op basis van het fallemode

De juiste metriek hangt af van het fallemode, en niet van de framework. De nuttige indeling kent drie scope’s:

1. Uitkomst evals geeft aan of de taak is geslaagd.
2. Traject evals geeft aan of het pad geldig, efficiënt en in overeenstemming met de beleidsregels was.
3. Component evals geeft aan welk hulpmiddel, retriever, sub-agent of beslissingsstap heeft gefaald.

Elke scope kan offline worden uitgevoerd op vaste, herhaalbare gevallen voordat de release plaatsvindt, of online op geselecteerde productiegegevens traces na het genereren van een antwoord. De onderstaande guardrails-sectie behandelt deze indeling in detail. Offline evals-uitvoeringen kunnen gouden voorbeelden vereisen. Online evals-processen moeten prioriteit geven aan invarianten, distributies en asynchrone controles die buiten de request-pas blijven.

Begin met deterministische metrics. Ze zijn goedkoop, snel en ze vertonen geen drift.

Correctheid van tool-aanroepen

De correctheid van de tool vergelijkt de opgeroepen tools met de verwachte tools. Kies de strengheid bewust:

• Exacte overeenkomst: de sequentie moet precies overeenkomen. Gebruik dit wanneer de volgorde van belang is, bijvoorbeeld lookup_order -> verify_identity -> issue_refund.
• In-orde overeenstemming: de vereiste hulpmiddelen moeten in de juiste relatieve volgorde verschijnen, maar extra, onschadelijke aanroepen zijn toegestaan.
• Elke-orde overeenstemming: de vereiste hulpmiddelen moeten aanwezig zijn, maar de volgorde mag verschillen.

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 not expected:
        return 1.0
    if mode == "exact":
        return float(called == expected)
    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

De in_order De score geeft de recall van de langste gemeenschappelijke ondervolgorde weer: het aandeel van de vereiste volgorde dat in de juiste volgorde is behouden. Let op wat hierbij wordt genegeerd. Onbelangrijke oproepen verlagen deze score niet, zodat een agent hier een waarde van 1,0 kan krijgen, zelfs wanneer er twee keer zoveel oproepen worden gedaan als nodig was. Wanneer extra oproepen geld kosten of de toestand veranderen, moet je de precisie daarnaast bijhouden (het aantal benodigde oproepen dat overeenkomt met de vereisten, gedeeld door het totale aantal oproepen) en deze twee waarden samen bekijken. Recall vangt de ontbrekende stappen op; precisie vangt de afwijkingen op.

De metric voor correctheid van de tool van DeepEval stelt dezelfde instellingen via beschikbaar should_consider_ordering en should_exact_match.

Correctheid van argumenten

Het gebruik van het juiste hulpprogramma met verkeerde argumenten is vaak erger dan het gebruik van het verkeerde hulpprogramma, omdat de trace er normaal uitziet.

Voor eenvoudige gevallen wordt JSON schema en de exacte waarden geverifieerd. In semantische gevallen worden de verwachte argumenten opgeslagen en worden de verschillen geëvalueerd:

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

Een metriek gebaseerd op de toolnaam kan dit niet detecteren 2026-06-17 waar de beleidsregels dit vereisen 2026-06-19. De dataset moet ook argumenten opslaan.

De score die bij dataset hoort, is parameter-match: het aandeel van de verwachte (tool, key, value) Drievoudigt het aantal correct beantwoorde agent-vragen.

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 called_args.get(tool, {}).get(key) == want:
                matched += 1
    return matched / total if total else 1.0

Exacte gelijkheid is geschikt voor IDs, enums en data. Het is onjuist voor vrije tekst en getallen met decimaaldeel, waar == Het markeert een juist antwoord als fout. Beoordeel deze velden op basis van hun eigen criteria: een genormaliseerde stringovereenkomst, een datumparsing en een numerieke tolerantie. De metriek blijft hetzelfde; de vergelijkingsmethode per veld verandert.

Efficiëntie, lussen en doodlopende paden

Een agent die de taak na vijf overbodige tool calls-acties toch voltooit, duidt nog steeds op een planning-probleem en is duurder in gebruik.

Goedkope signalen waar je mee kunt beginnen:

• Frequentie van redundante oproepen: identieke tool calls met dezelfde argumenten die meer dan twee keer worden herhaald.
• Anomalieën in de vorm van Trace: plotselinge stijgingen in de diepte, het aantal uitgevoerde tool-oproepen, het aantal token, latency of de kosten.
• Convergentie van het pad: in hoeverre de uitvoering overeenkomt met het kortste bekende geldige pad voor de taak.
• Correctheid van beëindiging: of de agent te vroeg stopt, na succes doorwerkt, of succes verklart zonder de vereiste staatswijziging.
• Naar het plan handelen: als de agent een plan opstelt voordat hij actie onderneemt, moet worden gecontroleerd of de trace daaraan heeft voldaan. Zowel een goed plan dat wordt genegeerd als een slecht plan dat perfect wordt nageleefd leiden tot falen, om tegenovergestelde redenen; het verschil tussen het plan en trace geeft aan welk het geval is.

Voer deze op voordat u een judge uitvoert, wanneer dat mogelijk is. Een lusdetecteur bevindt zich een paar regels verderop in de trace. Hij heeft geen model nodig.

Voltooiing van de taak en beoordeling van het resultaat

Van begin tot eind is de vraag: “Kreeg de gebruiker wat hij vroeg?”

Twee patronen werken het beste:

• Beoordeling van taakvoltooiing zonder referentie: haal het doel uit de invoer en judge vast of de trace samen met het eindantwoord dit doel hebben bereikt. Dit werkt online omdat productietraffic zelden beschikt over gouden referentie-outputten.
• Beoordeling op basis van omgevingsstatus: vergelijk de eindgegevens in de database, bestanden, tickets, boekingen of records met een gemarkeerde gewenste staat. Deze aanpak is robuuster dan transcriptvergelijking, omdat agents geldige paden kan vinden die je niet zelf hebt opgeschreven.

De tweede optie is beter wanneer je deze zelf kunt bouwen. De uiteindelijke staat vormt het contract. Het transcript is slechts bewijsmateriaal.

Er zijn twee belangrijke aandachtspunten die de eerlijkheid van deze methode beperken, beide voortkomend uit benchmark, het concept dat het beoordelen van toestanden populair maakte. Tau-bench kan een voldoende-score toekennen aan een agent die op bepaalde ‘no-op’-taken niets doet, omdat de begintoestand al aan het doel voldeed. Bovendien rapporteerde Anthropic een uitvoering van Opus 4.5 waarbij een taak op de tau2-bench ‘faalde’, omdat er een strategische opening werd gevonden die voor de gebruiker eigenlijk tot een beter resultaat leidde. Hoewel toestandsevaluatie superieur is aan transcriptvergelijking, blijft de doeltoestand een annotatie, en annotaties bevatten vaak fouten. Controleer dus niet alleen de gevallen die te gemakkelijk slagen, maar ook die die falen.

De trace-naar-eval flywheel

Voorkom productiefouten in de mijn voordat er nader wordt nagedacht over extra eval gevallen.

De lus:

1. Vang de volledige trace op.
2. Geef aan wat is mislukt.
3. Groeper de vergelijkbare fouten.
4. Houd voor elke cluster één representatieve ‘gouden’ variant.
5. Maak een versie van dataset aan.
6. Voer deze uit in CI.
7. Blijf de scores van geselecteerde productie traces online bijhouden.

Het bijbehorende repository trace2evals voert de volledige lus uit voor een defecte ondersteuning agent. Het vangt OpenTelemetry GenAI spans op, detecteert fouten met deterministische regels, elimineert duplicaten door ze op te slaan in een geversioneerde gouden dataset, en voert elke gouden versie opnieuw uit in CI. De standaardscript vereist geen API sleutel, dus make demo Voert het proces offline uit.

Mijnfouten analyseren met foutanalyse

Hamel Husain en Shreya Shankar geven een uitleg over foutanalyse workflow voor deze specifieke stap; die van Hamel. handleiding voor het veld Hij loopt erdoorheen. De eerste twee stappen ontleenen hun naam aan kwalitatief onderzoek, maar de methode is eenvoudig: lees traces, maak aantekeningen en geef de patronen een naam.

1. Open coding: lees 30 tot 50 echte traces-voorbeelden en maak vrijvormige notities over waar fouten zijn opgetreden.
2. Axial coding: groeper deze notities in 5 of 6 genummerde categorieën voor fouten.
3. Label alles volgens de taxonomie.
4. Build metrics voor de grootste groepen.

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 dat specifiek aangeeft wat de regressietest precies moet bevestigen.

Duplicaten verwijderen voordat je promoot

De trace-mijnloop bevat een valkuil: er worden voortdurend alle slechte trace-waarden toegevoegd. Dit leidt tot een dataset die groot, kostbaar en beperkt is in zijn reikwijdte. Hierdoor worden bijna-identieke gevallen uit maart overgenomen, terwijl de nieuwe vorm van dezelfde fout in juni wordt over het hoofd gezien.

Groep ze eerst. Kies één representatieve ‘golden’ per cluster. Bewaar de bijbehorende trace ID’s in de metadata zodat een reviewer later de productiegegevens kan controleren.

Als een foutcluster zich na een oplossing opnieuw voordoet, betekent dit dat het regressiecase niet is gegeneraliseerd. Hercluster en breid de gouden set uit in plaats van 15 extra voorbeelden toe te voegen.

Versie maken van de dataset

Versie datasets op dezelfde manier als je prompts en code versioneert. Telkens wanneer er iets significants verandert (model, prompt, tool schema, judge prompt, of het gedrag van de applicatie), wil je dezelfde dataset versie voor en na de wijziging uitvoeren.

De CI-poort moet het volgende vastleggen:

• dataset versie
• app-versie
• prompt versie
• judge model
• judge prompt
• evaluator codeversie

Als een van deze acties wordt uitgevoerd, wordt de vergelijking ‘voor/nadat’ onduidelijk. Een goldens-v3.json Een bestand in Git werkt prima op kleine schaal. De tool-specifieke snapshots in Langfuse, Phoenix, Braintrust of LangSmith is van groot nut zodra de dataset een gedeelde werkomgeving wordt.

Gate CI

Een mislukkende metriek moet leiden tot een mislukte build, anders is het eval-pakket slechts een dashboard dat niemand leest.

De test moet de huidige agent opnieuw uitvoeren tegen de gouden invoer. Het mag niet slechts de oude, mislukte trace opnieuw afspelen:

@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)

Deze onderscheiding is gemakkelijk verkeerd te begrijpen. De taak van de dataset is om te voorkomen dat de volgende versie van de agent dezelfde oude fout herhaalt, en niet om de fout zelf op te slaan.

Kalibreer de judge voordat je hem vertrouwt

LLM als judge is van groot nut. Het is echter ook gemakkelijk om jezelf voor de gek te houden met dit principe.

G-Eval Het vraagt een judge om expliciete stappen voor de beoordelingsrubriek op te stellen voordat er wordt gescoord. Vervolgens wordt elke beoordelingsniveau gewogen op basis van de bijbehorende token-waarschijnlijkheid ($\text{score} = \sum_i p(s_i)\,s_i$). Dit protocol leverde betere resultaten op bij het analyseren van menselijke beoordelingen dan de oudere, automatische metrieken die het verving.

Voor de stappen die gebruikmaken van waarschijnheidsweging zijn de judge logprobs vereist, maar sommige gehoste models diensten bieden deze niet beschikbaar. Desondanks maakt het uiteindelijke resultaat nog steeds het mogelijk om een duidelijke classificatiepath te gebruiken in plaats van enkel een ruwe score.

MT-Bench Er werd aangetoond dat GPT-4 ongeveer even vaak overeenstemt met de voorkeuren van mensen als mensen zelf met elkaar overeenkomen, waardoor LLM kan worden gebruikt om wat als ‘mainstream’ wordt beschouwd te beoordelen. Latere onderzoeken onthulden bias met betrekking tot positie, lengte en zelfvoorkeur. De Judge-scores kunnen ook veranderen wanneer er een wijziging optreedt in de prompt- of model-versie.

JudgeBench Er werden antwoordparen gegenereerd waarbij één van de antwoorden objectief onjuist was volgens betrouwbare kennisbronnen, reasoning, wiskundige principes en programmeertaal. GPT-4o behaalde 50,9% op deze set, terwijl de sterkste geteste judge-modellen ongeveer 64% scoorden. Zelfverzekerde, maar onjuiste antwoorden vormen nog steeds een uitdaging voor model-gebaseerde judges-systeem.

Behandel de judge als een metingstoestel: kalibreer het tegen menselijke labels voordat het iets beoordeelt, en controleer het opnieuw telkens wanneer de judge model of prompt verandert.

Wanneer een judge vereist is, moet het oordeel gestructureerd worden gegeven. Schema-gestuurde Reasoning (SGR) definieert het reasoning-pad van judge als een Pydantic-schema. Vervolgens vereisen Structured Outputs of constrained decoding velden zoals evidence, passed_criteria, failed_criteria, failure_mode, en score.

Plaats de bewijsvelden vóór de score. Vervolgens past judge dezelfde van tevoren gedefinieerde stappen van de beoordelingsmatrix toe, in dezelfde volgorde van velden, bij elke uitvoering en op alle compatibele model. Een reviewer kan genummerde velden bekijken in plaats van een paragraaf te analyseren. CI kan verschillen weergeven tussen stabiele JSON-objecten, terwijl de calibration-set aangeeft in welke beoordelingsstadia er onenigheid was met de menselijke labeling.

Het kan ook de kostencurve veranderen. Beschouw een goedkopere model als een kandidaat, en niet als een automatische vervanging. Test hem op dezelfde set van door mensen gelaagde calibration-gegevens. Vergelijk zijn accuraatheid, foutpositieratio en foutnegatieratio met die van de grotere judge. Gebruik hem alleen voor routinematige gevallen wanneer hij aan de door uw applicatie vastgestelde drempels voldoet. Houd de grotere judge achter voor gevallen waarin er onenigheid is, voor risicovolle situaties of voor uitvoeringen van calibration.

Standaard judge hygiënekalender:

1. Gebruik waar mogelijk een binair ‘slagen/falen’-systeem. Vijfpuntsschaalverdelingen kunnen leiden tot schijnbare precisie.
2. Label 30 tot 50 trajecten handmatig voordat de definitieve beoordelingsmatrix wordt opgesteld.
3. Meet de judge-menselijke overeenstemming met Cohen’s kappa (een correctie voor toeval, zodat een judge die altijd ‘slagen’ aangeeft een score van nul heeft) of eenvoudigweg TPR/TNR.
4. Verdeel de grove criteria in kleinere onderdelen. “Heeft de agent de identiteit geverifieerd vóór de terugbetaling tool call?” is beter dan “Was het traject goed?”.
5. Geef het oordeel weer via een SGR-schema dat bewijsmateriaal, gefaalde criteria, de oorzaak van het falen en de score bevat.
6. Gebruik indien mogelijk een judge uit een andere model-familie dan die van de generator.
7. Randomiseer de volgorde van de paarwaardige vergelijkingen en neem de gemiddelden van beide richtingen.
8. Straf ongepaste lengte in de beoordelingsmatrix. Een langere antwoord is niet automatisch beter.
9. Vastleg de judge model, prompt, dataset, het schema en de appversie.
10. Pas de parameters aan na wijzigingen in model, prompt, tools, beleidsregels of schema’s.

Voor scores met hoge risico’s dient u een klein juryteam te gebruiken in plaats van één groot judge. PoLL Er werd een groep kleinere judges getest die afkomstig waren uit onderling onafhankelijke model-families, en de uitspraken van deze groep werden gecombineerd. Tijdens zes datasets bleek de groep betere resultaten te leveren bij het analyseren van menselijke oordelen dan één enkele GPT-4 judge. Bovendien vermijdde deze benadering het zelfvoordelenbias van één enkele judge en was de kosten zeven keer lager. Houd menselijke beoordelingen aan voor beslissingen die gevolgen hebben voor financiën, toegang, veiligheid of naleving van regelgeving.

Als een judge een kappa-waarde van 0,55 behaalt bij vergelijking met mensen voor uw taak, moet u het niet gebruiken om deployments te blokkeren. Gebruik het eerder om review-queues te ordenen. Wanneer de waarde dicht bij 0,75 ligt en de kosten van fouten gematigd zijn, is het veel eenvoudiger om een CI-gate te rechtvaardigen.

Guardrails blok inline, online evals observeren na afloop

Mensen verwarren deze met elkaar omdat ze allebei scores opleveren. Het verschil zit in de positie: inline in het requestpad, vóór de publicatie, of na de respons.

Guardrails worden inline uitgevoerd. Ze zijn snel, deterministisch en zichtbaar voor de gebruiker. Een guardrail kan een tool call blokkeren, PII verwijderen, prompt injection afwijzen, of een herprobering afdwingen voordat het antwoord uw systeem verlaat. Een valse positieve detectie wordt beschouwd als een productiefout.

Offline evals-uitvoeringen vóór de publicatie. Deze zijn reproduceerbaar. Ze zorgen ervoor dat prompts, models, tools, retrievers en beleidsregels worden gecontroleerd tegen een vaste dataset.

Online evals uitvoeringen na de respons, meestal op geselecteerd verkeer. Zij mogen langzamere LLM judges gebruiken omdat ze zich niet in de latency-route bevinden. Hun taak is om afwijkingen te detecteren, nieuwe foutclusters te identificeren en de gegevens door te geven aan de volgende offline dataset.

Als de positie verkeerd wordt bepaald, leidt dat in beide gevallen tot problemen:

• Een judge in de requestpath zorgt voor het ontstaan van latency en een nieuwe bron van onvoorspelbaarheid.
• Een guardrail dat is overgebracht naar asynchrone scoring, maakt het mogelijk dat policy-overtreedingen bij gebruikers terechtkomen.

Voor systemen met hoge verwerkingsintensiteit kan men een klein steekproefdeel evalueren met krachtigere judge-modellen, terwijl voor grotere steekproeven goedkopere classificatormodellen worden gebruikt. Geef alarm wanneer er clusters of confidentie-intervalletjes worden gedetecteerd, in plaats van op basis van één enkele ruisige schatting.

Keuzes voor hulpprogramma’s

Geen enkel enkelvoudig hulpmiddel beheert de hele cyclus. De meest serieuze technologiestacks maken gebruik van twee componenten: een trace-opslag en een CI/eval-runner.

De notities over de afwegingen geven aan waar de kosten vandaan komen, en niet wat ze precies zijn. Prijspagina’s kunnen veranderen, en leveranciers houden rekening met verschillende factoren: traces, observaties, spans, scores, gebruikersaantal, retentie of verwerkte gegevens. Controleer de actuele prijzen opnieuw voordat u een beslissing neemt.

Besluitversnellingen:

• Er is behoefte aan een zelf gehoste tracing met OTel-portabiliteit: begin met Phoenix of Langfuse.
• Er is behoefte aan een CI-gate gebaseerd op code: begin met DeepEval.
• Men is al geïnvesteerd in LangGraph: LangSmith is zeer handig.
• Er wordt gewenst naar beheerde regressiecontrole van pull requests: Braintrust is onverslaanbaar.
• Veiligheid en red-team-oefeningen zijn belangrijk: Promptfoo is het meest geschikte hulpmiddel.
• Voor onderzoek naar veiligheid of gecontroleerde benchmark-activiteiten: Inspect AI is de betere keuze.

De keuze van het hulpmiddel is van secundair belang. Als productiefouten niet worden omgezet in testgevallen, betaal je voornamelijk voor de opslag van trace.

Een praktische controlelijst voor implementatie

Bouw eerst het bewijsmateriaal pipeline op voordat je de metric-stack uitbreidt. Begin daarbij met het bepalen van waar de voorbeelden vandaan zullen komen.

1. Verzamel eerst de historische uitvoeringen. Als de agent al aanwezig is, haal dan eerst traces, supporttickets, bugrapporten, negatieve sessions-beoordelingen, handmatige QA-transcripten en notities over interne gebruik van het systeem erbij voordat je de implementatie wijzigt. Als de agent nog niet bestaat, log dan elke prototype- en handmatige testuitvoering vanaf dag één.

2. Instrumenteer de trace-vorm. Vang berichten, tool calls, argumenten, uitvoer van hulpprogramma’s, fouten, token-aantallen, latency, kosten, gebruikersfeedback, appversie, prompt-versie, model-versie, tool schema-versie en de uiteindelijke staat van het omgevingssysteem op. Gebruik OpenTelemetry Conventies voor generatieve AI of in het geval van portabiliteit OpenInference-stijl spans. Gebruik Langfuse, LangSmith, Phoenix of Braintrust wanneer u onmiddellijk een trace gebruikersinterface en dataset workflow wilt hebben.

3. Verander echte fouten om in seedcases. Lees eerst de traces voordat je ze samenvat met een model. Voor elke bruikbare fout moet je de invoer, de bron-ID van trace, de verwachte staat, de verwachte tool-invarianten, de manier waarop de fout optreedt, de ernst en een opmerking van de reviewer opslaan. Langfuse kan dataset-items koppelen aan productieomgevingen traces; LangSmith kan datasets genereren op basis van getraceerde uitvoeringen. Houd de bronlink bij, zodat de case nog steeds te controleren is.

4. Als er geen geschiedenis beschikbaar is, genereer dan cold-start gevallen. Vraag een LLM om taken op te stellen op basis van productvereisten, beleidsregels, tool schemas, state machines en ondersteunende macros. Dek zowel succesvolle scenario’s als fouten af, zoals verkeerde rechten, ontbrekende identiteitscontroles, verouderde tool results-gegevens, dubbelzinnige data, herproberingen na snelheidsbeperkingen en tegenstrijdige uitvoer van hulpprogramma’s.

5. Vertrouw synthetische gevallen niet totdat ze door een mens zijn gecontroleerd. Synthetische voorbeelden zijn nuttig voor de dekking, maar niet voor de waarheid. Markeer ze met source: synthetic En er moet een reviewer zijn die het verwachte resultaat goedkeurt. Gebruik indien mogelijk een bekende, werkende referentieroute, en pas verschillende model-families toe om het geval te genereren en judge het resultaat te verkrijgen.

6. Bouw een klein, evenwichtig dataset. Inclusief voorbeelden van succesvolle uitvoeringen, mislukkingen, afwijzingen, randgevallen, gevallen met lange conversaties, gevallen die gevoelig zijn voor beleidsregels, en geldige alternatieve verlooppaden. Maak geen “ideale” versie die precies overeenkomt met het oorspronkelijke transcript. De ideale versie moet het vereiste resultaat, de toegestane invarianten en de manier waarop fouten kunnen optreden weergeven.

7. Voeg eerst deterministische controles toe. De vereiste volgorde van de tools – waarbij de volgorde zelf een beleidsregel vormt – omvat vereiste argumenten, schemavalidatie, verschillen tussen eindtoestanden, limieten voor lussen, plafonds voor token en latency, evenals taakspecifieke invarianten. Deze moeten allemaal worden uitgevoerd voordat er judge wordt gebruikt.

8. Voeg één SGR-vormig judge toe. Gebruik het uitsluitend voor het deel dat interpretatie vereist. Kalibreer het aan de hand van menselijke labels. Als het niet in staat is om goede en slechte voorbeelden in de calibration-set van elkaar te onderscheiden, corrigeer eerst de beoordelingscriteria voordat je het integreert in het CI-proces.

9. Verbind de lus. Voer het kleine offline-stel op in CI uit, voer het grotere stel uit vóór de publicatie, evalueer het gemonsterde productietraffic online, en breng herhalende online-faalfactoren terug naar het offline dataset.

Je eerste eval-suite zal op saaie manieren fouten bevatten. Zet hem toch op de markt. Een suite die je elke dag gebruikt, is gemakkelijker te corrigeren dan een perfect ontworpen document dat nooit een slechte pull request tegenhoudt.

Referenties

• demo-repo voor het trace2evals complement
• LangChain – Stand van zaken bij Agent-ontwikkeling
• Anthropic – Het ontrafelen van Evals voor AI Agents
• Hamel Husain - Een praktische gids voor het snel verbeteren van AI-producten
• OpenTelemetry semantische conventies voor generatieve AI systemen
• Correctheid van de DeepEval-tool
• Voltooiing van de DeepEval-taak
• Schema-gestuurde Reasoning op vLLM: Structured Outputs met xgrammar en Pydantic
• Langfuse datasets en versienummering
• LangSmith – Creëer en beheer datasets op programmeerbare manier
• Braintrust – Systematisch evalueren
• Phoenix LLM evals
• Integration van Promptfoo met GitHub Actions
• tau-bench: Een Benchmark voor interactie tussen tool-Agent en gebruikers in praktische omgevingen
• Waarom falen Multi-Agent LLM-systemen?
• G-Eval: Evaluatie van NLG met GPT-4 voor een betere alignement met menselijke behoeften
• Het beoordelen van LLM als een Judge met MT-Bench en Chatbot Arena
• Het vervangen van Judges door Juries: het evalueren van LLM generaties met een panel van diverse Models
• JudgeBench: Een Benchmark voor het evalueren van Judges-gebaseerde LLM
• Self-Preference Bias in LLM als een Judge