Chat agent benchmarks: de vier cijfers die release bepalen

Het is een dinsdag in mei. De demo bij de klant staat voor vrijdag. De pilot chat agent draait al drie weken in shadow mode en schrijft een conceptantwoord op elk binnenkomend ticket, terwijl het supportteam nog steeds zelf de klant beantwoordt. De head of support van de klant stelt de vraag die altijd komt. "Is hij eigenlijk wel goed?"

Kun je dat niet met vier cijfers beantwoorden, dan ga je niet live. Dat hebben we de langzame weg geleerd.

De vier cijfers

We benchmarken elke chat agent tegen het supportteam dat hij zou vervangen of ondersteunen, op dezelfde tickets, over dezelfde periode. Vier cijfers bepalen of hij live gaat of niet.

1. Resolution rate
2. Kwaliteitsscore
3. Tijd tot het eerste bruikbare antwoord
4. Wrong-confident rate

De eerste drie zijn voor de hand liggend. De vierde is degene waarop agents na drie maanden alsnog uit productie gehaald worden.

Resolution rate

Het aandeel gesprekken dat de agent afsloot zonder te escaleren, waarbij de klant het ticket binnen zeven dagen niet opnieuw opende.

De valkuil: resolution rate is makkelijk te manipuleren. Escaleer agressief en elke lastige vraag gaat naar een mens, dus de tickets die de agent zelf afhandelt zien er schoon uit. Sluit langzame gesprekken vroeg af en de klant opent volgende week gewoon een nieuwe. We verwerken beide gedragingen in de metric. Escalatie boven 40% van het binnenkomend volume triggert een aparte gate. Heropende tickets tellen als fout.

De baseline telt zwaarder dan het eindgetal. We meten het menselijke team eerst twee weken op dezelfde definitie. Een agent die op 78% uitkomt terwijl het team op 81% zit, is een prima agent. Een agent die 95% scoort omdat hij nooit escaleert, is stuk.

Kwaliteitsscore

Een cijfer van 1 tot 5 op een gestratificeerde sample van 200 afgesloten gesprekken, gescoord in twee passes. Eerst een LLM-as-judge met een rubric voor behulpzaamheid, juistheid, toon en volledigheid. Daarna een handmatige spot-check op 30 daarvan, om de judge te kalibreren.

Het judge-model mag niet hetzelfde model zijn dat het antwoord schreef. We gebruiken een andere modelfamilie als judge om sycophancy te beperken, een failure mode die goed gedocumenteerd is in de publieke evaluation research en in de originele LLM-as-a-Judge paper. We verankeren de rubric ook met drie echte voorbeelden per score, zodat de judge halverwege de pilot niet kan afdrijven. Drijft de judge af, dan drijft de score af, en lever je rotzooi af achter een groen dashboard.

Tijd tot het eerste bruikbare antwoord

Niet de tijd tot het eerste antwoord. Iedereen kan "dankjewel, ik kijk ernaar" in 200 milliseconden afvuren. We meten de tijd tot het eerste bericht dat een concreet antwoord, een uitvoerbare instructie of een verhelderingsvraag bevat die het ticket echt vooruit helpt.

Bij een menselijk team zit dit tijdens kantooruren meestal tussen de 4 en 12 minuten, 's nachts vaak uren. Bij een chat agent moet dit onder de 8 seconden landen. Lukt dat niet, dan zit er iets fout in je architectuur. Vrijwel altijd is het een trage retrieval call die je niet synchroon had hoeven doen.

Wrong-confident rate

Dit is het cijfer waar niemand het over heeft tot het pijn doet.

Het aandeel antwoorden van de agent dat feitelijk fout was, gegeven zonder enige slag om de arm, zonder "ik denk", zonder "ik check even". Een zelfverzekerd fout antwoord is erger dan een zelfverzekerd "ik weet het niet". Een klant die één zelfverzekerd fout antwoord krijgt, vertrouwt ook het volgende zelfverzekerde foute antwoord, en uiteindelijk bied je excuses aan voor twee fouten in plaats van één.

We meten dit door wekelijks 100 afgesloten gesprekken te samplen, elk agent-antwoord op juistheid te labelen, en dat label te kruisen met een toon-classifier die voorzichtigheidstaal opmerkt. Alles boven 2% is een fail.

De shadow-mode opzet

We draaien twee weken shadow mode voordat er handmatig gescoord wordt. De agent ziet elk binnenkomend ticket en produceert een concept-antwoord, maar het werkelijke antwoord van het team gaat naar de klant. Dat geeft ons een paired sample (zelfde ticket, agent-antwoord plus mensenantwoord), nul risico voor klanten in productie, en een natuurlijke baseline voor de latency-metric.

De scoring-code zelf is klein. Het punt is dat hij reproduceerbaar is en dat je hem wekelijks draait.

from dataclasses import dataclass

@dataclass
class Conversation:
    ticket_id: str
    agent_reply: str
    human_reply: str
    agent_latency_ms: int
    closed_by_agent: bool
    reopened_within_7d: bool
    quality_agent: float       # 1.0 to 5.0
    quality_human: float
    wrong_and_confident: bool

def benchmark(sample):
    n = len(sample)
    resolution = sum(
        c.closed_by_agent and not c.reopened_within_7d for c in sample
    ) / n
    quality_delta = (
        sum(c.quality_agent for c in sample) / n
        - sum(c.quality_human for c in sample) / n
    )
    p50_latency_s = sorted(c.agent_latency_ms for c in sample)[n // 2] / 1000
    wrong_confident = sum(c.wrong_and_confident for c in sample) / n

    return {
        "resolution_rate": resolution,
        "quality_delta_vs_human": quality_delta,
        "p50_latency_seconds": p50_latency_s,
        "wrong_confident_rate": wrong_confident,
        "ship": (
            resolution >= 0.70
            and quality_delta >= -0.3
            and p50_latency_s <= 8.0
            and wrong_confident <= 0.02
        ),
    }

Pas de thresholds aan op je domein. Vragen over prijzen, medische zaken en juridische kwesties verdienen strengere wrong-confident gates. Vragen over orderstatus laten meer ruimte.

De menselijke baseline kalibreren

Voordat de agent überhaupt draait, benchmarken we het supportteam twee weken op dezelfde vier cijfers. De baseline telt zwaarder dan je zou denken: de meeste teams hebben hun eigen wrong-confident rate nog nooit gemeten, en het antwoord is bijna nooit nul.

Zonder baseline is "78% resolution" betekenisloos. Het kan een sterke agent op een lastige inbox zijn, of een zwakke agent op een makkelijke. Met een baseline weet je welke van de twee.

Retrieval is de helft van de score

Een schone benchmark-opzet is verspilling als de agent het juiste document niet kan vinden. De agent weet alleen wat hij kan ophalen, en een slordige retrieval-pipeline zie je terug in zowel lagere kwaliteit als een hogere wrong-confident rate.

Twee praktische regels. Eén: versioneer je index op document-hash, zodat een verouderde PDF niet stilletjes drie weken antwoorden kan vergiftigen. Twee: scheid retrieval recall en generation quality in je dashboard. Als de agent slechter wordt, wil je weten of het model is gaan hallucineren of dat de index de verkeerde pagina is gaan teruggeven.

De graders zijn de bottleneck

Een schone rubric is het deel van het project dat mensen onderschatten. Als een menselijke grader het oneens is met de LLM judge, lezen we het gesprek samen en passen we het rubric-voorbeeld voor de betwiste score aan. Na twee weken zijn judge en mens het over ongeveer 85% van de samples eens, genoeg om de judge te vertrouwen voor bulk-scoring.

Zakt de overeenstemming halverwege de pilot onder de 80%, stop dan met het dashboard, herscore de afgelopen week met de hand, en zoek uit wat er veranderd is. Meestal is er een edge case bij gekomen die de judge nog nooit gezien heeft.

Wat live gaat, en wat niet

Een agent gaat live als alle vier de cijfers tegelijk door de gate komen. Drie van de vier is geen ship. Twee van de vier is niet eens in de buurt. Dat combinatorische karakter is precies het punt: een agent kan snel en behulpzaam zijn en toch fout, of accuraat en traag en onbruikbaar, of accuraat en snel maar alleen omdat hij alles wat lastig is wegescaleert.

Toen we de chat agent voor een Nederlandse logistieke klant bouwden, zat de wrong-confident rate de eerste drie weken op 6%, omdat de retrieval-index de verkeerde revisie van hun verzendtarieven-PDF teruggaf. We hebben het opgelost door de index te versioneren op document-hash, retrieval recall apart te scoren, en prijsvragen te weigeren zodra de retrieval-confidence onder een drempel zakte. Bouw je AI-agents voor een echte inbox, dan zijn deze vier cijfers de lat.

Wat je vandaag kunt doen: pak 50 afgesloten tickets van vorige week, scoor de antwoorden op een rubric van 1 tot 5, en tel hoeveel er fout waren zonder enig voorbehoud. Dat cijfer is je startpunt, en je kunt het pas verbeteren als je het gemeten hebt.