Multi-turn LLM-evaluatie: 5 metrics, 3 frameworks, 1 workflow

Multi-turn LLM-evaluatie: 5 metrics, 3 frameworks, 1 workflow

Multi-turn LLM-evaluatie is de enige manier om de beurt-8-amnesiabug te vangen: de gebruiker gaf zijn ordernummer in beurt 3, en de bot vraagt er opnieuw naar. Elke afzonderlijke beurt slaagde; het gesprek faalde toch. DeepEval 4.0 en RAGAS 0.4 brachten precies hiervoor speciale conversationele eval-API's uit, en na twee eval-incidenten in onze eigen pipeline bij Techsy volgen hier de vijf metrics, drie frameworks en één workflow om mee te beginnen.

Belangrijkste punten

• Multi-turn evaluatie beoordeelt hele gesprekken, geen losse input-outputparen.
• Modellen die single-turn benchmarks aanvoeren, gaan meetbaar achteruit over de gespreksbeurten.
• Begin met vier metrics: volledigheid, kennisbehoud, roltrouw, beurtrelevantie.
• DeepEval, RAGAS en Langfuse lossen multi-turn eval verschillend op; de frameworktabel hieronder vergelijkt ze.

Waarom liegen single-turn scores tegen je?

Single-turn evals scoren één input-outputpaar tegelijk, dus ze zien fouten niet die pas over meerdere beurten verschijnen: vergeten, tegenspraak, drift. Een model kan een sterke benchmarkscore neerzetten en toch de draad van een live gesprek kwijtraken. Laban et al. documenteren dit in LLMs Get Lost In Multi-Turn Conversation, 353 citaties: prestaties dalen in multi-turn settings, ook wanneer de single-turn resultaten er gezond uitzien.

Het kernprobleem is niet-determinisme: de n-de respons hangt af van alle n-1 eerdere beurten, dus identieke prompts gedragen zich anders op basis van de geschiedenis. Een dataset met losse paren oefent die afhankelijkheid nooit. De arXiv-survey Evaluating LLM-based Agents for Multi-Turn Conversations, een PRISMA-review van ruwweg 250 bronnen, verdeelt het veld in wat je evalueert (contextbeheer, planning, coherentie) en hoe (metrics, LLM-judges, menselijke review). Beide assen ontbreken in een single-turn suite.

Dit maakt je single-turn stack nog niet nutteloos. Draai je single-turn metrics zoals BLEU, ROUGE en G-Eval, behoud ze dan voor wat ze goed meten: formatcompliance, toxiciteit, feitelijke recall op een vaste prompt. Lees ze alleen niet meer als gezondheidscheck voor het gesprek dat je gebruikers voeren.

Onze interpretatie van die studies, in één regel:

Single-turn evals meten het antwoord, multi-turn evaluatie meet het gesprek, en een model dat beurt één haalt, kan in beurt vijf al verdwaald zijn.

Wat is multi-turn LLM-evaluatie? De twee evaluatiewijzen

Multi-turn LLM-evaluatie is het beoordelen van een heel gesprek, of vensters daarbinnen, in plaats van losse prompt-responsparen. Ze vraagt of het model de context bewaarde, in zijn rol bleef en het probleem van de gebruiker over de beurten heen oploste. Twee wijzen doen het werk: scoring op conversatieniveau en sliding-window-scoring op beurtniveau, en de meeste teams draaien beide.

Scoring op conversatieniveau geeft de judge het volledige transcript en stelt één vraag: was dit gesprek succesvol? Het vangt voortijdige afsluiting en onopgeloste loops, want alleen de hele draad onthult dat de gebruiker zijn refund nooit kreeg. De zwakte is granulariteit: "gefaald" op een draad van 12 beurten zegt niet waar het brak.

Sliding-window-scoring op beurtniveau schuift een venster van N beurten over het transcript, één oordeel per venster. Een venster van 3 over een gesprek van 10 beurten levert 8 oordelen die aan regio's van de chat gebonden zijn, dus "gefaald" krijgt coördinaten: de breuk lag in beurt 6 tot en met 8. Het diagram bovenaan dit bericht toont beide wijzen op één draad: een haak voor het gespreksoordeel, een schuivend kader voor de vensteroordelen.

Gebruik scoring op conversatieniveau als gate, en scoring met vensters om fouten te lokaliseren wanneer die gate faalt. DeepEval's multi-turn evaluatiegids kadert de werkeenheid in als een scenario in plaats van een input-outputpaar (het ConversationalGolden-type): je test een situatie, geen vraag.

Illustratief voorbeeld (synthetisch; toont de mechanica, geen echte run): een sliding window van 3 over een retourverzoek-chat van 8 beurten.

Turn 1  user:      I want to return an order that arrived damaged.
Turn 2  assistant: Sorry about that. Can you share the order number?
Turn 3  user:      It's #4471.
Turn 4  assistant: Got it. Damaged on arrival, or after use?
Turn 5  user:      On arrival. The screen was cracked.
Turn 6  assistant: Understood. Replacement or refund?
Turn 7  user:      Refund. How long does that take?
Turn 8  assistant: 3-5 business days. Can you share the order number again?

Oordeel op conversatieniveau: falen. Vijf van de zes vensters slaagden, en toch brak de draad op kennisbehoud, precies de fout die een single-turn suite nooit aan het licht brengt.

Welke multi-turn metrics doen ertoe? Deze 5

Draai eerst vier metrics: gespreksvolledigheid, kennisbehoud, roltrouw en beurtrelevantie. Voeg een vijfde toe, een custom criterium (G-Eval in DeepEval, AspectCritic in RAGAS), voor alles wat jouw product zich niet kan veroorloven fout te doen. De eerste vier dragen over tussen projecten; de vijfde is waar jouw foutmodi wonen.

1. Gespreksvolledigheid. Werd het doel van de gebruiker bereikt, of riep de bot te vroeg de overwinning uit? Je detector voor voortijdige afsluiting.
2. Kennisbehoud. Onthoudt het model feiten die eerder in de draad genoemd zijn? De beurt-8-amnesiabug is een kennisbehoudfout.
3. Roltrouw. Blijft de assistent binnen zijn persona en weigert hij verzoeken buiten scope? Kritiek bij een compliancegrens.
4. Beurtrelevantie. Is elke respons on-topic gegeven de voorgaande beurten? Vangt drift en loops.
5. Een custom criterium. Eén regel in gewone taal voor jouw domein: "noem nooit een prijs die afwijkt van de officiële prijslijst." DeepEval implementeert dit als ConversationalGEval; RAGAS als AspectCritic.

De DeepEval-metricsgids definieert ze elk met uitvoerbare classes, maar de concepten zijn frameworkneutraal: de tabel houdt stand, ook als je je judge zelf bouwt.

Een custom criterium leest als een zin:

criterion "price_accuracy":
  question: Does the assistant quote prices matching the official
            list, and self-correct when the user flags a mismatch?
  scale: 0 (wrong, no correction) to 1 (correct throughout)
  verdict: pass if score >= 0.5

Dezelfde regel als echte DeepEval-code:

from deepeval.metrics import ConversationalGEval
from deepeval.test_case import LLMTestCaseParams

price_accuracy = ConversationalGEval(
    name="Price Accuracy",
    criteria=(
        "Does the assistant quote prices that match the official "
        "price list, and correct itself immediately when the user "
        "points out a discrepancy?"
    ),
    evaluation_params=[
        LLMTestCaseParams.INPUT,
        LLMTestCaseParams.ACTUAL_OUTPUT,
    ],
    threshold=0.5,
)

DeepEval vs RAGAS vs Langfuse: welk framework past?

Alle drie evalueren ze multi-turn gesprekken, maar hun evaluatie-eenheid verschilt: DeepEval simuleert scenario's offline, RAGAS scoort aspecten van gesprekken die je al hebt, en Langfuse evalueert echte productietraces. Kies op basis van waar je gesprekken vandaan komen, niet op basis van het aantal features.

Eerst frameworkneutrale logica, zodat de vendorcode hieronder overdraagbaar is:

for scenario in scenario_set:
    transcript = run_chatbot(scenario, max_turns=10)
    for window in sliding_windows(transcript, 3):
        scores.append(judge(window, criteria))
    scores.append(judge(transcript, completeness))
fail_if(mean(scores) < baseline - tolerance)

DeepEval: scenario's en een compleet uitgeruste simulator

DeepEval is de enige met een first-class gespreksimulator: beschrijf een scenario en een persona, en hij speelt de gebruiker tegen je bot. Zijn multi-turn gids is de canonieke referentie voor het scenario-niet-paren-patroon. Confident AI verkoopt het gehoste dashboard; onze Confident AI review behandelt wat de betaalde laag toevoegt.

from deepeval.dataset import ConversationalGolden
from deepeval.synthesizer import ConversationSimulator
from deepeval.metrics import (
    ConversationCompletenessMetric,
    KnowledgeRetentionMetric,
)
from deepeval import evaluate

scenario = ConversationalGolden(
    additional_context="Customer wants to return a damaged order",
    user_persona="Impatient customer, second contact this week",
)
simulator = ConversationSimulator(model="gpt-4o-mini", max_turns=10)
test_case = simulator.simulate(scenario, your_chatbot_fn)

evaluate(
    test_cases=[test_case],
    metrics=[
        ConversationCompletenessMetric(threshold=0.7),
        KnowledgeRetentionMetric(threshold=0.7),
    ],
)

RAGAS: foutanalyse-gedreven, aspect voor aspect

RAGAS vertrekt vanuit gesprekken die je al hebt en scoort ze aspect voor aspect. Zijn multi-turn how-to gaat samen met handmatige foutanalyse: lees falende chats, schrijf een AspectCritic per foutmodus, score.

from ragas.dataset_schema import MultiTurnSample
from ragas.metrics import AspectCritic
from ragas.llms import llm_factory

user_input = [
    {"role": "user", "content": "Can I return a damaged order?"},
    {"role": "assistant", "content": "Yes, within 30 days."},
    {"role": "user", "content": "It arrived broken. Do I pay shipping?"},
    {"role": "assistant", "content": "No, we cover it."},
]
sample = MultiTurnSample(user_input=user_input)

critic = AspectCritic(
    name="policy_consistency",
    definition="Does the assistant stay consistent with the stated return policy across all turns? Answer yes or no.",
    llm=llm_factory("gpt-4o-mini"),
)
score = await critic.multi_turn_ascore(sample)  # binary 0 or 1

Langfuse: N+1-evaluatie op echte traces

Langfuse kiest de tegenovergestelde weg: tracer first. Zijn N+1 cookbook evalueert de trace van elke beurt plus het gesprek als geheel, op productieverkeer in plaats van simulaties. Kies je nog voor de observabiliteitslaag, dan behandelt onze Langfuse vs LangSmith-vergelijking die beslissing.

Ons oordeel, zonder hekkenzitten: begin voor een nieuw chatbotproject met DeepEval. De simulator laat je regressies afvangen vóórdat je productieverkeer hebt, precies wanneer je tests het hardst nodig hebt. Voeg Langfuse toe zodra er echte draden bestaan; grijp naar RAGAS wanneer je team liever falende gesprekken leest en vastlegt wat het vindt.

Hoe ga je van foutanalyse naar automatisering?

Je sequencet het. Lees 20-30 echte gesprekken, label foutmodi met de hand, schrijf binaire slagings-/falingschecks voor de voor de hand liggende, automatiseer die, en voeg pas dan LLM-judge-metrics toe voor het subjectieve restant. Hamel Husain bepleit precies deze volgorde: eerst handmatige foutanalyse en binaire beslissingen, want een check die je kunt uitleggen wint van een score die dat niet kan.

Binair vóór judge: de volgorde die ons redde

Dit is geen chatbotbenchmark die we draaiden; het is onze interpretatie van hetzelfde patroon in onze eigen contentpipeline, die bij elke prompt- en toolingwijziging eval-gegatede regressiechecks draait. Twee incidenten bewezen de volgorde voor ons.

Op 2026-06-13 muntte een republishbug nieuwe gelokaliseerde slugs en leverde 54 dubbele live documenten af. We vonden ze en haalden ze offline op 2026-07-05 (backup in techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json). De fix was geen slimmer model; het was een deterministische pre-publish check: los het bestaande document op via canonical post plus taal vóór elke create. Een binaire gate.

Tweede incident: vertaler-LLM's geven af en toe ASCII in plaats van Unicode, waardoor "karşılaştırma" in "karsilastirma" verandert. Geen judge nodig; een grep-gate vangt het:

grep -cP '[çşğüöıİŞÇĞÜÖ]' file.md   # must be > 0

Beide werden gevangen door checks die fracties van een cent kosten en exact afdrukken waarom ze faalden. Vertaal dat naar multi-turn evals: "vroeg de bot opnieuw naar een veld dat de gebruiker al gaf?" is een string match tegen het transcript, geen judge-aanroep. Draai eerst goedkope deterministische gates; die vangen de lelijke fouten voordat je dure judge ooit draait.

Wanneer een LLM-judge wél het juiste gereedschap is

Judges verdienen hun tokenkosten op criteria die je niet tot een regel kunt reduceren: "was de toon gepast verontschuldigend?", "sloot de oplossing bij de situatie?" Kun je een assertie schrijven, schrijf dan een assertie. Een rubric vol oordeelsvragen is judge-terrein.

De regel waar we op blijven terugkomen:

Begin met binaire slagings-/falingschecks die je aan een teamgenoot kunt uitleggen, en voeg alleen LLM-judges toe voor wat je niet tot een regel kunt reduceren.

Hoe simuleer je gesprekken op schaal, en wat kost judgen?

Simuleer vanuit scenario's, niet vanuit geëxporteerde logs. Scenario's testen wat zou kunnen gebeuren; logs tonen alleen wat je huidige systeem al toestond. DeepEval's richtlijn waarschuwt dat historische gesprekken gevormd zijn door het systeem dat ze produceerde, dus benchmarken ertegen bakt de status quo vast.

Scenario's, geen transcripten

Schrijf elk scenario als doel plus persona: "ongeduldige klant die een beschadigde bestelling retourneert", "gebruiker die zich tijdens het boeken bedenkt". Stel een max-beurtenlimiet in (10 is gezond) en een stopconditie: doel bereikt, gebruiker haakt af, of limiet. DeepEval raadt minstens 20 diverse scenario's aan over primaire use cases, edge cases en foutgevoelige situaties; daaronder meet je suite anekdotes.

Adversariële persona's

Neem persona's op die de bot proberen te breken: een boze gebruiker die escaleert, een verwarde gebruiker die zichzelf tegenspreekt, een injection-gebruiker die instructies in beurt 4 smokkelt. Multi-turn injection is een eigen discipline; onze LLM guardrails-gids behandelt de defensieve laag die bij deze tests hoort, en Langfuse's simulatie-cookbook toont de gebruikerssimulator-loop.

Wat 100 geëvalueerde gesprekken kosten

Elk cijfer hieronder is een schatting op basis van genoemde tokenaantallen en publieke prijzen, geen meting die wij draaiden. De rekensom is het punt: vul je eigen getallen in.

Minder dan een dollar voor 100 volledig beoordeelde gesprekken. Een duurdere judge verschuift dit 10-50x, en de tactieken uit onze LLM-API-kosten verlagen-gids gelden: cach de criteriumtekst, batch vensters, gebruik het goedkope model voor binaire gates.

Een 6-staps multi-turn eval-workflow

De loop draait zo: definieer scenario's uit echte fouten, kies vier kernmetrics plus één custom, simuleer minstens 20 scenario's, baseline de huidige versie, gate regressies in CI, en voed productiefouten terug in de scenario-set.

1. Definieer scenario's uit fouten. Lees 20-30 transcripten (of schrijf ze vóór launch vanuit supporttickets). Elk scenario krijgt een doel, een persona en een max-beurtenlimiet. Eigenaar: jij en Hamels foutanalyse-eerst-methode.
2. Kies vier metrics, één custom. Volledigheid, kennisbehoud, roltrouw, beurtrelevantie, en één ConversationalGEval of AspectCritic voor de dure fout van jouw domein.
3. Simuleer. Draai minstens 20 scenario's inclusief de adversariële set. Eigenaar: DeepEval's ConversationSimulator, of Langfuse's simulatie-cookbook.
4. Baseline de huidige versie. Leg per-metric gemiddelden vast over 3 runs, want modellen zijn niet-deterministisch en één run is ruis. Eigenaar: je evalscript, resultaten gecommit in de repo.
5. Gate regressies in CI. Stel een drempel per metric in en faal de build bij regressie voorbij een tolerantie:

# ci/multi-turn-eval-gate.sh
set -euo pipefail
python eval/run_multi_turn.py --scenarios eval/scenarios.yaml --out results.json
SCORE=$(jq -r '.aggregate.completeness' results.json)
BASELINE=0.82
TOLERANCE=0.03
if (( $(echo "$SCORE < $BASELINE - $TOLERANCE" | bc -l) )); then
  echo "FAIL: completeness $SCORE below baseline $BASELINE"
  exit 1
fi

1. Monitor productiedraden. Groepeer live traces per draad, evalueer asynchroon, en maak van elke falende draad een nieuw scenario. Eigenaar: Langfuse of je tracer; onze gidsen over AI-agents evalueren in productie en AI observability behandelen de monitoringshelft.

De suite is nooit af: stap 6 voedt stap 1, en de scenario-set groeit met elke productiefout die je vangt.

Hoe evalueer je toon over talen heen?

Een roltrouw-metric die op Engelse data is afgesteld, laat een Turks of Japans transcript slagen dat een moedertaalspreker grof vindt, want beleefdheidsregister is taalspecifiek. Je Engelse rubric heeft er geen woorden voor. De fix: één aspectcriterium per registerverwachting, per taal geschreven, niet één globale toon-metric.

Eén criterium per register

Onze interpretatie van het RAGAS AspectCritic-patroon, uitgebreid vanuit het draaien van een 23-talen pipeline, geen gepubliceerd testresultaat:

English:  "Is the assistant's tone friendly but professional?"
Turkish:  "Does the assistant use formal 'siz' address consistently,
           and avoid casual verb forms with an upset customer?"
Japanese: "Does the assistant keep keigo (polite form) throughout,
           including the apology at the resolution turn?"

Elk criterium is een aparte binaire critic op hetzelfde transcript. We hebben geen kruistaalse toonscores gepubliceerd, en zouden een artikel dat ze afdrukt zonder de rubric niet vertrouwen. Vanuit het pipelinewerk: fouten clusteren bij verontschuldigings- en escalatiebeurten, waar het register als eerste instort.

Veelgestelde vragen

Wat is een multi-turn conversatie-LLM?

Een taalmodel waarvan de n-de respons afhangt van alle eerdere beurten, niet alleen van de laatste prompt. Het conditioneert op de hele draad, dus het gedrag verandert met de gespreksgeschiedenis. Die contextafhankelijkheid is wat single-turn tests niet kunnen oefenen en wat multi-turn evaluatie bestaat om te scoren.

Wat betekent LLM-evaluatie?

Uitvoerkwaliteit meten tegen gedefinieerde criteria, automatisch en herhaalbaar, in plaats van op gevoel. Single-turn evaluatie scoort losse prompt-responsparen tegen metrics als BLEU of een LLM-judge. Multi-turn evaluatie breidt dat uit naar hele gesprekken, en scoort contextbehoud en doelbereik over beurten heen in plaats van per prompt.

Hoe benchmark je multi-turn LLM-prestaties?

Bouw minstens 20 scenario's met doelen en persona's, simuleer ze tegen het model, en score met metrics op conversatieniveau plus sliding-window-checks. Leg baselines vast over meerdere runs om niet-determinisme te absorberen, en vergelijk daarna elke nieuwe versie tegen de baseline in CI. Productietraces breiden de benchmark later uit.

Wat zijn de beste manieren om een LLM te evalueren?

Sequencen: eerst handmatige foutanalyse, dan binaire slagings-/falingsgates voor alles wat tot een regel te reduceren is, dan LLM-as-a-judge voor subjectieve criteria als toon en oplossingskwaliteit. Binaire checks zijn goedkoper, debugbaar en driften niet; judges horen bij criteria die echt oordeel vragen, nadat de goedkope gates slagen.

Met welke multi-turn evaluatie-metrics moet ik beginnen?

Gespreksvolledigheid, beurtrelevantie en kennisbehoud; ze vangen de meest voorkomende fouten (onopgeloste doelen, drift, vergeten) in elk chatproduct. Voeg roltrouw toe als je bot een compliancegrens heeft, en daarna één custom G-Eval- of AspectCritic-criterium voor de fout die jouw bedrijf zich niet kan veroorloven.

Wat kost LLM-as-a-judge per gesprek?

Met een sliding window van 5 over 10 beurten plus één aanroep op conversatieniveau doe je 7 judge-aanroepen per gesprek. Bij ruwweg 2.000 inputtokens per aanroep op GPT-4o-mini komt onze uitgeschreven rekensom uit op ongeveer $0,29 per 100 gesprekken. Premium judge-modellen verhogen dat 10-50x.

DeepEval vs RAGAS voor multi-turn evaluatie: welke kies ik?

DeepEval als je offline regressietests wilt met een ingebouwde gespreksimulator, zeker vóórdat je productieverkeer hebt. RAGAS als je workflow begint bij het lezen van echt falende gesprekken en het vastleggen van elke foutmodus als AspectCritic. Een veelgebruikte splitsing: DeepEval in CI, RAGAS-stijl critics op productielogs.

Hoeveel scenario's heb ik nodig voor een multi-turn eval-suite?

Minstens 20, over primaire use cases, edge cases en foutgevoelige situaties; die drempel komt uit DeepEval's gepubliceerde richtlijn en matcht onze ervaring. Onder de 20 zwaaien slagingspercentages op basis van welke scenario's er toevallig bijzaten. Laat de set groeien met elke productiefout.

Kan ik multi-turn evaluatie in CI/CD draaien?

Ja. Houd een vaste scenario-set in de repo, draai hem bij elke prompt- of modelwijziging, en faal de build wanneer een metric voorbij de tolerantie regresseert ten opzichte van de baseline. Omdat modellen niet-deterministisch zijn, vergelijk je gemiddelden over 3 runs met een tolerantie (wij gebruiken 0,03), geen exacte drempels.

Hoe evalueer ik multi-turn gesprekken in productie?

Groepeer traces per gespreksdraad, score elke draad asynchroon zodat evaluatie nooit een respons blokkeert, en stuur falende draden naar een reviewqueue. Elke bevestigde fout wordt een nieuw scenario in je offline suite, waarmee je de loop tussen monitoring en regressietests sluit.

De korte versie

• Single-turn scores zien gespreksfouten niet; onderzoek toont modellen die over de beurten degraderen ondanks gezonde benchmarks.
• Draai scoring op conversatieniveau als gate en sliding-window-scoring om breuken te lokaliseren.
• Vier kernmetrics plus één custom criterium dekken de meeste chatproducten; binaire checks vóór judges, altijd.
• DeepEval voor gesimuleerde regressietests, RAGAS voor foutanalyse-gedreven critics, Langfuse voor productietraces.
• Judge-kosten zijn klein (minder dan een dollar per 100 gesprekken op een mini-model); kosten zijn zelden de blokkade.

Voor het bredere toolaanbod rangschikten we het hele veld in onze roundup van beste LLM-evaluatietools. En bouw je de eval-pipeline liever samen met iemand op, plan een gratis consult met het Techsy-team.