Multi-turn LLM-evaluering: 5 metrikker, 3 rammeværker, 1 arbejdsgang

Multi-turn LLM-evaluering: 5 metrikker, 3 rammeværker, 1 arbejdsgang

Multi-turn LLM-evaluering er den eneste måde at fange tur-8-amnesi-buggen på: brugeren gav sit ordrenummer i tur 3, og boten beder om det igen. Hver enkelt tur bestod isoleret set; samtalen fejlede alligevel. DeepEval 4.0 og RAGAS 0.4 leverede dedikerede konversations-eval-API'er til netop det, og efter to eval-hændelser i vores egen pipeline hos Techsy får du her de fem metrikker, tre rammeværker og én arbejdsgang at starte med.

Nøglepointer

• Multi-turn-evaluering scorer hele samtaler, ikke isolerede input-output-par.
• Modeller, der topper single-turn-benchmarks, degraderer målbart hen over samtalens ture.
• Start med fire metrikker: fuldstændighed, vidensfastholdelse, rolleoverholdelse, turrelevans.
• DeepEval, RAGAS og Langfuse løser multi-turn-eval forskelligt; rammeværkstabellen nedenfor sammenligner dem.

Hvorfor lyver single-turn-scores for dig?

Single-turn-eval scorer ét input-output-par ad gangen, så de kan ikke se fejl, der kun opstår på tværs af ture: glemsel, modsigelse, drift. En model kan levere en stærk benchmark-score og stadig miste tråden i en live samtale. Laban et al. dokumenterer det i LLMs Get Lost In Multi-Turn Conversation, 353 citationer: ydelsen degraderer i multi-turn-opsætninger, selv når single-turn-resultaterne ser sunde ud.

Kerneproblemet er ikke-determinisme: det n'te svar afhænger af alle n-1 foregående ture, så identiske prompts opfører sig forskelligt afhængigt af historikken. Et datasæt af isolerede par tester aldrig den afhængighed. arXiv-surveyet Evaluating LLM-based Agents for Multi-Turn Conversations, en PRISMA-gennemgang af cirka 250 kilder, deler feltet op i hvad man evaluerer (konteksthåndtering, planlægning, kohærens) og hvordan (metrikker, LLM-dommere, menneskelig gennemgang). Begge akser mangler i en single-turn-suite.

Intet af dette gør din single-turn-stak ubrugelig. Kører du single-turn-metrikker som BLEU, ROUGE og G-Eval, så behold dem til det, de måler godt: formatoverholdelse, toksicitet, faktahukommelse på et fast prompt. Stop bare med at læse dem som et sundhedstjek af den samtale, dine brugere faktisk har.

Vores tolkning af de studier, på én linje:

Single-turn-eval måler svaret, multi-turn-evaluering måler samtalen, og en model, der klarer tur 1 perfekt, kan være helt væk ved tur 5.

Hvad er multi-turn LLM-evaluering? De to evalueringsformer

Multi-turn LLM-evaluering er praksissen med at score en hel samtale, eller vinduer i den, i stedet for isolerede prompt-svar-par. Den spørger, om modellen beholdt konteksten, blev i rollen og løste brugerens problem på tværs af turene. To former gør arbejdet: scoring på samtaleniveau og scoring på turniveau med glidende vindue, og de fleste teams kører begge.

Scoring på samtaleniveau giver dommeren hele transskriptionen og stiller ét spørgsmål: var denne samtale en succes? Den fanger for tidlig afslutning og uløste løkker, da kun hele tråden afslører, at brugeren aldrig fik sin refusion. Svagheden er granulariteten: "fejlet" på en 12-turs tråd siger ikke, hvor det gik galt.

Scoring på turniveau med glidende vindue flytter et vindue på N ture hen over transskriptionen, én kendelse pr. vindue. Et vindue på 3 over en 10-turs samtale giver 8 kendelser bundet til regioner af chatten, så "fejlet" følger med koordinater: bruddet skete i tur 6 til 8. Diagrammet øverst i dette indlæg viser begge former på én tråd: en parentes for samtalekendelsen, en glidende ramme for vindueskendelserne.

Brug scoring på samtaleniveau som gaten og scoring med vinduer til at lokalisere fejl, når den slår ud. DeepEvals multi-turn-evalueringsguide definerer arbejdsheden som et scenarie frem for et input-output-par (typen ConversationalGolden): du tester en situation, ikke et spørgsmål.

Illustrerende eksempel (syntetisk; viser mekanikken, ikke en reel kørsel): et glidende vindue på 3 hen over en 8-turs returforespørgsels-chat.

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?

Samtalekendelse: fejlet. Fem ud af seks vinduer bestod, og tråden brød alligevel på vidensfastholdelse, præcis den fejl en single-turn-suite aldrig viser.

Hvilke multi-turn-metrikker betyder noget? De 5, der gør

Kør fire metrikker først: samtalefuldstændighed, vidensfastholdelse, rolleoverholdelse og turrelevans. Tilføj en femte, et custom-kriterium (G-Eval i DeepEval, AspectCritic i RAGAS), for det dit produkt ikke må få galt. De første fire overføres mellem projekter; den femte er dér, dine fejltilstande bor.

1. Samtalefuldstændighed. Blev brugerens mål løst, eller erklærede botten sejr for tidligt? Din detektor for for tidlig afslutning.
2. Vidensfastholdelse. Husker modellen fakta, der er nævnt tidligere i tråden? Tur-8-amnesi-buggen er en vidensfastholdelsesfejl.
3. Rolleoverholdelse. Bliver assistenten i sin persona og afviser forespørgsler uden for scope? Afgørende med en compliance-grænse.
4. Turrelevans. Er hvert svar on-topic givet de foregående ture? Fanger drift og løkker.
5. Et custom-kriterium. Én regel i almindeligt sprog for dit domæne: "angiv aldrig en pris, der afviger fra prislisten." DeepEval implementerer det som ConversationalGEval; RAGAS som AspectCritic.

DeepEval-metrik guiden definerer hver af dem med kørbare klasser, men koncepterne er rammeværksneutrale: tabellen holder, selvom du bygger din dommer selv.

Et custom-kriterium læses som en sætning:

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

Den samme regel som rigtig DeepEval-kode:

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 mod RAGAS mod Langfuse: Hvilket rammeværk passer?

Alle tre evaluerer multi-turn-samtaler, men deres evalueringsenhed er forskellig: DeepEval simulerer scenarier offline, RAGAS scorer aspekter af samtaler, du allerede har, og Langfuse evaluerer reelle produktionstraces. Vælg ud fra, hvor dine samtaler kommer fra, ikke antallet af features.

Rammeværksneutral logik først, så leverandørkoden nedenfor er portabel:

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: scenarier og en simulator med det hele

DeepEval er den eneste med en førsteklasses samtaleimulator: beskriv et scenarie og en persona, og den spiller brugeren mod din bot. Deres multi-turn-guide er den kanoniske reference for scenarie-ikke-par-mønstret. Confident AI sælger det hostede dashboard; vores Confident AI-anmeldelse dækker, hvad det betalte lag tilføjer.

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: fejlanalysedrevet, aspekt for aspekt

RAGAS tager udgangspunkt i samtaler, du allerede har, og scorer dem aspekt for aspekt. Deres multi-turn how-to spiller sammen med manuel fejlanalyse: læs fejlede chats, skriv en AspectCritic pr. fejltilstand, 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-evaluering på reelle traces

Langfuse går den modsatte vej: tracer først. Deres N+1-cookbook evaluerer hver turs trace plus samtalen som helhed på produktionstrafik frem for simuleringer. Hvis du stadig vælger observability-lag, dækker vores Langfuse mod LangSmith-sammenligning den beslutning.

Vores dom, uden at sidde på gærdet: til et nyt chatbot-projekt, start med DeepEval. Simulatoren lader dig gate regressioner, før du har produktionstrafik, dér hvor du mest har brug for tests. Tilføj Langfuse, når reelle tråde findes; gribe til RAGAS, når dit team foretrækker at læse fejlede samtaler og kodificere det, de finder.

Hvordan kommer du fra fejlanalyse til automatisering?

Du sekventierer det. Læs 20-30 reelle samtaler, mærk fejltilstande op i hånden, skriv binære bestået/fejlet-tjek for de oplagte, automatisér dem, og tilføj først LLM-dømte metrikker for den subjektive rest bagefter. Hamel Husain argumenterer for præcis denne rækkefølge: manuel fejlanalyse og binære beslutninger først, fordi et tjek, du kan forklare, slår en score, du ikke kan.

Binært før dommer: rækkefølgen, der reddede os

Dette er ikke et chatbot-benchmark, vi kørte; det er vores tolkning af det samme mønster i vores egen content-pipeline, som kører eval-gatede regressionstjek ved hver prompt- og værktøjsændring. To hændelser beviste rækkefølgen for os.

Den 13. juni 2026 skabte en genudgivelsesbug nye lokaliserede slugs og sendte 54 duplikerede live dokumenter ud. Vi fandt og afpublicerede dem den 5. juli 2026 (backup på techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json). Fikset var ikke en klogere model; det var et deterministisk præ-publish-tjek: slå det eksisterende dokument op via kanonisk indlæg plus sprog før nogen oprettelse. En binær gate.

Anden hændelse: oversætter-LLM'er udsteder lejlighedsvis ASCII i stedet for Unicode og gør "karşılaştırma" til "karsilastirma". Ingen dommer nødvendig; en grep-gate fanger det:

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

Begge blev fanget af tjek, der koster brøkdele af en øre og printer præcis, hvorfor de fejlede. Oversæt det til multi-turn-eval: "spurgte botten igen om et felt, brugeren allerede har givet?" er et strengmatch mod transskriptionen, ikke et dommerkald. Kør billige deterministiske gates først; de fanger de grimme fejl, før din dyre dommer overhovedet kører.

Hvornår en LLM-dommer faktisk er det rigtige værktøj

Dommere tjener deres tokenomkostning på kriterier, du ikke kan koge ned til en regel: "var tonen passende beklagende?", "passede løsningen til situationen?" Kan du skrive en assertion, så skriv en assertion. En rubrik fuld af skøn er dommerterritorium.

Linjen, vi bliver ved med at vende tilbage til:

Start med binære bestået/fejlet-tjek, du kan forklare en kollega, og tilføj kun LLM-dommere for det, der ikke kan koges ned til en regel.

Hvordan simulerer du samtaler i stor skala, og hvad koster dommerne?

Simulér ud fra scenarier, ikke eksporterede logs. Scenarier tester, hvad der kunne ske; logs viser kun, hvad dit nuværende system allerede tillod. DeepEvals vejledning advarer om, at historiske samtaler er formet af systemet, der producerede dem, så benchmarking mod dem støber status quo fast.

Scenarier, ikke transskriptioner

Skriv hvert scenarie som mål plus persona: "utålmodig kunde, der returnerer en beskadiget ordre", "bruger, der skifter mening midt i en booking." Sæt en maks-ture-grænse (10 er fornuftigt) og en stopbetingelse: mål nået, brugeren opgiver, eller loftet. DeepEval anbefaler mindst 20 forskellige scenarier på tværs af primære use cases, edge cases og fejludsatte situationer; under det måler din suite anekdoter.

Adversarielle personaer

Inkludér personaer, der prøver at ødelægge botten: en vred bruger, der eskalerer, en forvirret bruger, der modsiger sig selv, en injectionsbruger, der smugler instruktioner ind i tur 4. Multi-turn-injection er sin egen disciplin; vores LLM-guardrails-guide dækker det forsvarslag, der hører sammen med disse tests, og Langfuses simulerings-cookbook viser brugersimulator-løkken.

Hvad 100 evaluerede samtaler koster

Alle tal nedenfor er estimater ud fra oplyste tokenantal og offentlige priser, ikke en måling vi har kørt. Regnestykket er pointen: byt dine egne tal ind.

Under en dollar for 100 fuldt dømte samtaler. En dyrere dommer flytter det 10-50x, og taktikkerne i vores reducér LLM-API-omkostninger-guide gælder: cach kriterieteksten, batch vinduer, brug den billige model til binære gates.

En 6-trins multi-turn eval-arbejdsgang

Løkken kører sådan her: definér scenarier ud fra reelle fejl, vælg fire kernemetrikker plus én custom, simulér mindst 20 scenarier, baseline den nuværende version, gate regressioner i CI, og fød produktionsfejl tilbage i scenariesættet.

1. Definér scenarier ud fra fejl. Læs 20-30 transskriptioner (eller, præ-lancering, skriv dem ud fra supporttickets). Hvert scenarie får et mål, en persona og et maks-ture-loft. Ansvarlig: dig og Hamels fejlanalyse-først-metode.
2. Vælg fire metrikker, én custom. Fuldstændighed, vidensfastholdelse, rolleoverholdelse, turrelevans og én ConversationalGEval eller AspectCritic for dit domænes dyre fejltagelse.
3. Simulér. Kør mindst 20 scenarier inklusive det adversarielle sæt. Ansvarlig: DeepEvals ConversationSimulator eller Langfuses simulerings-cookbook.
4. Baseline den nuværende version. Optag gennemsnit pr. metrik over 3 kørsler, da modeller er ikke-deterministiske, og én kørsel er støj. Ansvarlig: dit eval-script, resultater committet til repoet.
5. Gate regressioner i CI. Sæt en tærskel pr. metrik og fejle buildet ved regression ud over en tolerance:

# 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. Overvåg produktionstråde. Gruppér live traces pr. tråd, evaluér asynkront, og gør hver fejlet tråd til et nyt scenarie. Ansvarlig: Langfuse eller din tracer; vores guider om evaluering af AI-agenter i produktion og AI-observability dækker overvågningshalvdelen.

Suiten er aldrig færdig: trin 6 føder trin 1, og scenariesættet vokser med hver produktionsfejl, du fanger.

Hvordan evaluerer du tone på tværs af sprog?

En rolleoverholdelsesmetrik tunet på engelske data vil bestå en tyrkisk eller japansk transskription, som en indfødt taler finder uhøflig, fordi høflighedsregister er sprogspecifikt. Din engelske rubrik har ingen ord for det. Fikset: ét aspektkriterium pr. registerforventning, skrevet pr. sprog, ikke én global tonemetrik.

Ét kriterium pr. register

Vores tolkning af RAGAS' AspectCritic-mønster, udvidet fra at køre en 23-sprogs pipeline, ikke et publiceret testresultat:

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?"

Hvert kriterium er en separat binær kritiker på samme transskription. Vi har ikke publiceret tværsproglige tone-scores og ville ikke stole på et indlæg, der printer dem uden rubrikken. Fra pipeline-arbejdet: fejl hober sig op ved beklagelses- og eskalationsture, hvor registeret kollapser først.

Ofte stillede spørgsmål

Hvad er en multi-turn samtale-LLM?

En sprogmodel, hvis n'te svar afhænger af alle foregående ture, ikke kun det seneste prompt. Den betinger sig på hele tråden, så adfærden ændrer sig med samtalehistorikken. Den kontekstafhængighed er det, single-turn-tests ikke kan udøve, og som multi-turn-evaluering findes for at score.

Hvad betyder LLM-evaluering?

At måle outputkvalitet mod definerede kriterier, automatisk og reproducerbart, i stedet for på fornemmelsen. Single-turn-evaluering scorer isolerede prompt-svar-par mod metrikker som BLEU eller en LLM-dommer. Multi-turn-evaluering udvider det til hele samtaler og scorer kontekstfastholdelse og målopfyldelse på tværs af ture frem for pr. prompt.

Hvordan benchmarker man multi-turn LLM-ydelse?

Byg mindst 20 scenarier med mål og personaer, simulér dem mod modellen, og score med metrikker på samtaleniveau plus glidende-vindue-tjek. Optag baselines over flere kørsler for at absorbere ikke-determinismen, og sammenlign så hver ny version mod baselinen i CI. Produktionstraces udvider benchmarket senere.

Hvad er de bedste måder at evaluere en LLM på?

Sekventiér det: manuel fejlanalyse først, så binære bestået/fejlet-gates for alt, der kan koges ned til en regel, så LLM-as-a-judge for subjektive kriterier som tone og løsningskvalitet. Binære tjek er billigere, fejlfindbare og driver ikke; dommere hører til på kriterier, der reelt kræver skøn, efter de billige gates består.

Hvilke multi-turn-evalueringsmetrikker skal jeg starte med?

Samtalefuldstændighed, turrelevans og vidensfastholdelse; de fanger de mest almindelige fejl (uløste mål, drift, glemsel) i ethvert chatprodukt. Tilføj rolleoverholdelse, hvis din bot har en compliance-grænse, og så ét custom G-Eval- eller AspectCritic-kriterium for den fejltagelse, din forretning ikke har råd til.

Hvad koster LLM-as-a-judge pr. samtale?

Med et glidende vindue på 5 over 10 ture plus ét kald på samtaleniveau laver du 7 dommerkald pr. samtale. Med cirka 2.000 input-tokens pr. kald på GPT-4o-mini lander vores vist-regnestykke-estimat på cirka 0,29 $ pr. 100 samtaler. Premium-dommermodeller hæver det 10-50x.

DeepEval mod RAGAS til multi-turn-evaluering: hvilken skal jeg vælge?

DeepEval, hvis du vil have offline regressionstests med en indbygget samtaleimulator, især før du har produktionstrafik. RAGAS, hvis din arbejdsgang starter med at læse reelle fejlede samtaler og kodificere hver fejltilstand som en AspectCritic. En almindelig opdeling: DeepEval i CI, RAGAS-lignende kritikere på produktionslogs.

Hvor mange scenarier kræver en multi-turn eval-suite?

Mindst 20, der dækker primære use cases, edge cases og fejludsatte situationer; den tærskel kommer fra DeepEvals publicerede vejledning og matcher vores erfaring. Under 20 svinger beståelsesprocenterne med, hvilke scenarier der tilfældigvis kom med. Udvid sættet med hver produktionsfejl.

Kan jeg køre multi-turn-evaluering i CI/CD?

Ja. Hold et fast scenariesæt i repoet, kør det ved hver prompt- eller modelændring, og fejle buildet, når en metrik regresserer ud over tolerancen mod baselinen. Da modeller er ikke-deterministiske, så sammenlign gennemsnit over 3 kørsler med en tolerance (vi bruger 0,03), ikke eksakte tærskler.

Hvordan evaluerer jeg multi-turn-samtaler i produktion?

Gruppér traces pr. samtaletråd, score hver tråd asynkront, så evaluering aldrig blokerer et svar, og diriger fejlede tråde ind i en gennemgangskø. Hver bekræftet fejl bliver et nyt scenarie i din offline-suite og slutter løkken mellem overvågning og regressionstests.

Den korte version

• Single-turn-scores kan ikke se samtalefejl; forskning viser, at modeller degraderer på tværs af ture trods sunde benchmarks.
• Kør scoring på samtaleniveau som din gate og scoring med glidende vindue for at lokalisere brud.
• Fire kernemetrikker plus ét custom-kriterium dækker de fleste chatprodukter; binære tjek før dommere, altid.
• DeepEval til simulerede regressionstests, RAGAS til fejlanalysedrevne kritikere, Langfuse til produktionstraces.
• Dommeromkostninger er små (under en dollar pr. 100 samtaler på en mini-model); pris er sjældent blokeringen.

For det bredere værktøjslandskab rangerede vi hele feltet i vores bedste LLM-evalueringsværktøjer-runde. Og vil du hellere bygge eval-pipelinen sammen med nogen, så få en gratis konsultation med Techsy-teamet.