Flerturns LLM-evaluering: 5 metrikker, 3 rammeverk, 1 arbeidsflyt

Flerturns LLM-evaluering: 5 metrikker, 3 rammeverk, 1 arbeidsflyt

Flerturns LLM-evaluering er den eneste måten å fange runde-8-amnesi-feilen på: brukeren ga ordrenummeret sitt i runde 3, og boten spør om det igjen. Hver enkelt runde besto isolert; samtalen feilet likevel. DeepEval 4.0 og RAGAS 0.4 lanserte dedikerte samtale-eval-API-er for nøyaktig dette, og etter to eval-hendelser i vår egen pipeline hos Techsy, her er de fem metrikker, tre rammeverk og én arbeidsflyt å starte med.

Nøkkelpoenger

• Flerturns-evaluering scorer hele samtaler, ikke isolerte input-output-par.
• Modeller som topper enkeltturns-benchmarker degraderer målbart på tvers av samtalerunder.
• Start med fire metrikker: fullstendighet, kunnskapsbevaring, rolleoverholdelse, runderelevans.
• DeepEval, RAGAS og Langfuse løser flerturns-eval ulikt; rammeverk-tabellen nedenfor sammenligner dem.

Hvorfor lyver enkeltturns-skårer for deg?

Enkeltturns-evaluer scorer ett input-output-par om gangen, så de kan ikke se feil som bare oppstår på tvers av runder: glemsel, selvmotsigelse, drift. En modell kan oppnå en sterk benchmark-skår og likevel miste tråden i en live samtale. Laban et al. dokumenterer dette i LLMs Get Lost In Multi-Turn Conversation, 353 siteringer: ytelsen degraderer i flerturns-settinger selv når enkeltturns-resultater ser sunne ut.

Kjerneproblemet er ikke-determinisme: den n-te responsen avhenger av alle n-1 foregående runder, så identiske prompts oppfører seg ulikt basert på historikk. Et datasett med isolerte par tester aldri den avhengigheten. arXiv-oversikten Evaluating LLM-based Agents for Multi-Turn Conversations, en PRISMA-gjennomgang av omtrent 250 kilder, deler feltet inn i hva man evaluerer (kontekstforvaltning, planlegging, koherens) og hvordan (metrikker, LLM-dommere, menneskelig gjennomgang). Begge aksene mangler i en enkeltturns-suite.

Ingenting av dette gjør enkeltturns-stakken din ubrukelig. Hvis du kjører enkeltturns-metrikker som BLEU, ROUGE og G-Eval, behold dem for det de måler godt: formatoverholdelse, toksisitet, faktagjengivelse på en fast prompt. Bare slutt å lese dem som en helsesjekk for samtalen brukerne dine faktisk har.

Vår tolkning av disse studiene, på én linje:

Enkeltturns-evaluer måler svaret, flerturns-evaluering måler samtalen, og en modell som aceer runde én kan være vill i runde fem.

Hva er flerturns LLM-evaluering? De to evalueringsmodusene

Flerturns LLM-evaluering er praksisen med å score en hel samtale, eller vinduer innenfor den, i stedet for isolerte prompt-respons-par. Den spør om modellen beholdt kontekst, holdt seg i rollen og løste brukerens problem på tvers av runder. To moduser gjør jobben: samtale-nivå scoring og glidende-vindu turnivå-scoring, og de fleste team kjører begge.

Samtale-nivå scoring gir dommeren hele transkriptet og stiller ett spørsmål: var denne samtalen vellykket? Den fanger for tidlig avslutning og uløste løkker, siden bare hele tråden avslører at brukeren aldri fikk refusjonen sin. Svakheten er granularitet: "feilet" på en 12-runders tråd sier ikke hvor ting brøt.

Glidende-vindu turnivå-scoring flytter et vindu på N runder over transkriptet, én dom per vindu. Et vindu på 3 over en 10-runders samtale gir 8 dommer knyttet til regioner av chatten, så "feilet" kommer med koordinater: bruddet skjedde i runde 6 til 8. Diagrammet øverst i dette innlegget viser begge moduser på én tråd: en parentes for samtale-dommen, en glidende ramme for per-vindu dommer.

Bruk samtale-nivå scoring som porten, vindus-scoring for å lokalisere feil når den utløses. DeepEvals flerturns-evalueringsguide rammer inn arbeidsenheten som et scenario i stedet for et input-output-par (dens ConversationalGolden-type): du tester en situasjon, ikke et spørsmål.

Illustrerende eksempel (syntetisk; viser mekanikken, ikke en reell kjøring): et glidende vindu på 3 over en 8-runders returforespørsel-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?

Samtale-nivå dom: feilet. Fem av seks vinduer besto, og tråden brøt likevel på kunnskapsbevaring, nøyaktig den feilen en enkeltturns-suite aldri avdekker.

Hvilke flerturns-metrikker betyr noe? De 5 som gjør det

Kjør fire metrikker først: samtalefullstendighet, kunnskapsbevaring, rolleoverholdelse og runderelevans. Legg til en femte, et egendefinert kriterium (G-Eval i DeepEval, AspectCritic i RAGAS), for det produktet ditt ikke kan gjøre feil. De fire første overføres mellom prosjekter; den femte er der feilmodusene dine bor.

1. Samtalefullstendighet. Ble brukerens mål løst, eller erklærte boten seier for tidlig? Din for-tidlig-avslutning-detektor.
2. Kunnskapsbevaring. Husker modellen fakta som ble oppgitt tidligere i tråden? Runde-8-amnesi-feilen er en kunnskapsbevaringsfeil.
3. Rolleoverholdelse. Holder assistenten seg innenfor sin persona og avslår forespørsler utenfor scope? Kritisk med en compliance-grense.
4. Runderelevans. Er hver respons på tema gitt de foregående rundene? Fanger drift og løkker.
5. Et egendefinert kriterium. Én klartekst-regel for domenet ditt: "aldri siter en pris som avviker fra prislisten." DeepEval implementerer dette som ConversationalGEval; RAGAS som AspectCritic.

DeepEval metrikk-guiden definerer hver med kjørbare klasser, men konseptene er rammeverk-nøytrale: tabellen gjelder selv om du håndruller din egen dommer.

Et egendefinert kriterium leser som en setning:

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

Samme regel som ekte 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 vs RAGAS vs Langfuse: Hvilket rammeverk passer?

Alle tre evaluerer flerturns-samtaler, men evalueringsenheten deres er ulik: DeepEval simulerer scenarier offline, RAGAS scorer aspekter av samtaler du allerede har, og Langfuse evaluerer reelle produksjonsspor. Velg ut fra hvor samtalene dine kommer fra, ikke antall funksjoner.

Rammeverk-nøytral logikk 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 batteri-inkludert simulator

DeepEval er den eneste med en førsteklasses samtale-simulator: beskriv et scenario og en persona, og den spiller brukeren mot boten din. Flerturns-guiden er den kanoniske referansen for scenario-ikke-par-mønsteret. Confident AI selger det hostede dashbordet; vår Confident AI-anmeldelse dekker hva det betalte laget legger til.

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

RAGAS starter fra samtaler du allerede har og scorer dem aspekt for aspekt. Flerturns-how-to-en kombineres med manuell feilanalyse: les feilende chatter, skriv en AspectCritic per feilmodus, 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 spor

Langfuse tar den motsatte veien: tracer først. N+1-cookbooken evaluerer hver rundes spor pluss samtalen som helhet, på produksjonstrafikk i stedet for simuleringer. Hvis du fortsatt velger observabilitetslag, dekker vår Langfuse vs LangSmith-sammenligning den beslutningen.

Vår dom, uten gjerdesitting: for et nytt chatbot-prosjekt, start med DeepEval. Simulatoren lar deg fange regresjoner før du har produksjonstrafikk, når du mest trenger tester. Legg til Langfuse når reelle tråder eksisterer; grip etter RAGAS når teamet ditt foretrekker å lese feilende samtaler og kodifisere det de finner.

Hvordan går du fra feilanalyse til automatisering?

Du sekvenserer det. Les 20-30 reelle samtaler, merk feilmoduser for hånd, skriv binære bestått/feilet-sjekker for de åpenbare, automatiser dem, og legg deretter til LLM-dømte metrikker for den subjektive resten. Hamel Husain argumenterer for nøyaktig denne rekkefølgen: manuell feilanalyse og binære beslutninger først, fordi en sjekk du kan forklare slår en skår du ikke kan.

Binært før dommer: sekvenseringen som reddet oss

Dette er ikke en chatbot-benchmark vi kjørte; det er vår tolkning av det samme mønsteret i vår egen innholdspipeline, som kjører eval-portede regresjonssjekker på hver prompt- og verktøyendring. To hendelser beviste sekvenseringen for oss.

Den 2026-06-13 skapte en republiseringsbug nye lokaliserte sluger og sendte 54 dupliserte live dokumenter. Vi fant og avpubliserte dem den 2026-07-05 (backup på techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json). Fiksen var ikke en smartere modell; det var en deterministisk forhåndspubliseringssjekk: løs det eksisterende dokumentet per kanonisk innlegg pluss språk før noen opprettelse. En binær port.

Andre hendelse: oversetter-LLM-er sender av og til ASCII i stedet for Unicode, og gjør "karşılaştırma" til "karsilastirma." Ingen dommer trengs; en grep-port fanger det:

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

Begge ble fanget av sjekker som koster brøkødelutter og skriver ut nøyaktig hvorfor de feilet. Kartlegg det til flerturns-evaluer: "spurte boten om et felt brukeren allerede ga?" er en strengmatch mot transkriptet, ikke et dommerkall. Kjør billige deterministiske porter først; de fanger de stygge feilene før din dyre dommer noensinne kjører.

Når en LLM-dommer faktisk er riktig verktøy

Dommere tjener sin tokenkostnad på kriterier du ikke kan redusere til en regel: "var tonen passende beklagende?", "passet løsningen til situasjonen?" Hvis du kan skrive en assert, skriv en assert. En rubrikk full av domsskjønn er dommerterritorium.

Linjen vi stadig kommer tilbake til:

Start med binære bestått/feilet-sjekker du kan forklare til en kollega, og legg deretter til LLM-dommere bare for det du ikke kan redusere til en regel.

Hvordan simulerer du samtaler i skala, og hva koster dømming?

Simuler fra scenarier, ikke eksporterte logger. Scenarier tester hva som kan skje; logger viser bare hva ditt nåværende system allerede tillot. DeepEvals veiledning advarer om at historiske samtaler ble formet av systemet som produserte dem, så benchmarking mot dem sementrerer status quo.

Scenarier, ikke transkripter

Skriv hvert scenario som mål pluss persona: "utålmodig kunde som returnerer en skadet ordre," "bruker som ombestemmer seg midt i bestillingen." Sett en maks-runder-grense (10 er fornuftig) og en stoppbetingelse: mål nådd, bruker forlater, eller taket. DeepEval anbefaler minst 20 varierte scenarier på tvers av primære brukstilfeller, kanttilfeller og feilutsatte situasjoner; under det måler suiten din anekdoter.

Adversarielle personaer

Inkluder personaer som prøver å knekke boten: en sint bruker som eskalerer, en forvirret bruker som motsier seg selv, en injeksjonsbruker som smugler instruksjoner inn i runde 4. Flerturns-injeksjon er sin egen disiplin; vår LLM-guardrails-guide dekker det defensive laget som kombineres med disse testene, og Langfuses simulerings-cookbook viser brukersimulator-løkken.

Hva 100 evaluerte samtaler koster

Hvert tall nedenfor er et estimat fra oppgitte tokenantall og offentlig prising, ikke en måling vi kjørte. Aritmetikken er poenget: bytt inn dine egne tall.

Under en dollar for 100 fullstendig dømte samtaler. En dyrere dommer flytter dette 10-50x, og taktikkene i vår reduser LLM API-kostnader-guide gjelder: cach kriterieteksten, batch vinduer, bruk den billige modellen for binære porter.

En 6-trinns flerturns-eval arbeidsflyt

Løkken kjører slik: definer scenarier fra reelle feil, velg fire kjernemetrikker pluss én egendefinert, simuler minst 20 scenarier, baseline den nåværende versjonen, port regresjoner i CI, og mat produksjonsfeil tilbake i scenariosettet.

1. Definer scenarier fra feil. Les 20-30 transkripter (eller, før lansering, skriv dem fra støttesaker). Hvert scenario får et mål, en persona og en maks-runder-grense. Eier: du og Hamels feilanalyse-først-metode.
2. Velg fire metrikker, én egendefinert. Fullstendighet, kunnskapsbevaring, rolleoverholdelse, runderelevans, og én ConversationalGEval eller AspectCritic for domenet ditt sin dyre feil.
3. Simuler. Kjør minst 20 scenarier inkludert det adversarielle settet. Eier: DeepEvals ConversationSimulator, eller Langfuses simulerings-cookbook.
4. Baseline den nåværende versjonen. Registrer per-metrikk gjennomsnitt over 3 kjøringer, siden modeller er ikke-deterministiske og én kjøring er støy. Eier: eval-skriptet ditt, resultater committet til repoet.
5. Port regresjoner i CI. Sett en terskel per metrikk og feil bygget ved regresjon utover en toleranse:

# 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åk produksjonstråder. Grupper live spor per tråd, evaluer asynkront, og gjør hver feilende tråd om til et nytt scenario. Eier: Langfuse eller traceren din; våre guider om evaluering av AI-agenter i produksjon og AI-observabilitet dekker overvåkingshalvdelen.

Suiten blir aldri ferdig: trinn 6 mater trinn 1, og scenariosettet vokser med hver produksjonsfeil du fanger.

Hvordan evaluerer du tone på tvers av språk?

En rolleoverholdelsesmetrikk kalibrert på engelske data vil bestå et tyrkisk eller japansk transkript som en morsmålstaler synes er uhøflig, fordi høflighetsregister er språkspesifikt. Din engelske rubrikk har ingen ord for det. Fiksen: ett aspektskriterium per registerforventning, skrevet per språk, ikke én global tone-metrikk.

Ett kriterium per register

Vår tolkning av RAGAS AspectCritic-mønsteret, utvidet fra å kjøre en 23-språks pipeline, ikke et publisert 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å det samme transkriptet. Vi har ikke publisert tverrspråklige tone-skårer, og ville ikke stolt på en artikkel som skriver dem ut uten rubrikken. Fra pipeline-arbeidet: feil klumper seg ved beklagelses- og eskaleringsrunder, der registeret kollapser først.

Ofte stilte spørsmål

Hva er en flerturns samtale-LLM?

En språkmodell der den n-te responsen avhenger av alle foregående runder, ikke bare den siste prompten. Den betinger seg på hele tråden, så atferden endres med samtalehistorikken. Den kontekstavhengigheten er det enkeltturns-tester ikke kan trene og flerturns-evaluering eksisterer for å score.

Hva betyr LLM-evaluering?

Å måle output-kvalitet mot definerte kriterier, automatisk og repeterbart, i stedet for på magefølelse. Enkeltturns-evaluering scorer isolerte prompt-respons-par mot metrikker som BLEU eller en LLM-dommer. Flerturns-evaluering utvider det til hele samtaler, og scorer kontekstbevaring og måloppnåelse på tvers av runder i stedet for per prompt.

Hvordan benchmarker du flerturns LLM-ytelse?

Bygg minst 20 scenarier med mål og personaer, simuler dem mot modellen, og score med samtale-nivå metrikker pluss glidende-vindu-sjekker. Registrer baseliner over flere kjøringer for å absorbere ikke-determinisme, og sammenlign deretter hver ny versjon mot baselinen i CI. Produksjonsspor utvider benchmarken senere.

Hva er de beste måtene å evaluere en LLM på?

Sekvenser det: manuell feilanalyse først, deretter binære bestått/feilet-porter for alt som kan reduseres til en regel, så LLM-as-a-judge for subjektive kriterier som tone og løsningskvalitet. Binære sjekker er billigere, feilsøkbare og driver ikke; dommere hører hjemme på kriterier som genuint krever skjønn, etter at de billige portene passerer.

Hvilke flerturns-evalueringsmetrikker bør jeg starte med?

Samtalefullstendighet, runderelevans og kunnskapsbevaring; de fanger de vanligste feilene (uløste mål, drift, glemsel) i ethvert chatprodukt. Legg til rolleoverholdelse hvis boten din har en compliance-grense, og deretter ett egendefinert G-Eval eller AspectCritic-kriterium for feilen virksomheten din ikke har råd til.

Hvor mye koster LLM-as-a-judge per samtale?

Med et glidende vindu på 5 over 10 runder pluss ett samtale-nivå kall, gjør du 7 dommerkall per samtale. Med omtrent 2 000 input-tokens per kall på GPT-4o-mini, gir vårt vist-regnestykke-estimat omtrent $0,29 per 100 samtaler. Premium dommermodeller hever det 10-50x.

DeepEval vs RAGAS for flerturns-evaluering: hvilken bør jeg velge?

DeepEval hvis du vil ha offline regresjonstester med en innebygd samtale-simulator, spesielt før du har produksjonstrafikk. RAGAS hvis arbeidsflyten din starter med å lese reelle feilende samtaler og kodifisere hver feilmodus som en AspectCritic. Én vanlig oppdeling: DeepEval i CI, RAGAS-stil kritikere på produksjonslogger.

Hvor mange scenarier trenger jeg for en flerturns-eval-suite?

Minst 20, som dekker primære brukstilfeller, kanttilfeller og feilutsatte situasjoner; den terskelen kommer fra DeepEvals publiserte veiledning og matcher vår erfaring. Under 20 svinger bestått-rater på hvilke scenarier som tilfeldigvis ble inkludert. Voks settet med hver produksjonsfeil.

Kan jeg kjøre flerturns-evaluering i CI/CD?

Ja. Behold et fast scenariosett i repoet, kjør det på hver prompt- eller modellendring, og feil bygget når en metrikk regrererer forbi toleransen mot baselinen. Fordi modeller er ikke-deterministiske, sammenlign gjennomsnitt over 3 kjøringer med en toleranse (vi bruker 0,03), ikke eksakte terskler.

Hvordan evaluerer jeg flerturns-samtaler i produksjon?

Grupper spor per samtaletråd, score hver tråd asynkront slik at evaluering aldri blokkerer en respons, og rut feilende tråder inn i en gjennomgangskø. Hver bekreftet feil blir et nytt scenario i din offline suite, og lukker løkken mellom overvåking og regresjonstester.

Kortversjonen

• Enkeltturns-skårer kan ikke se samtalefeil; forskning viser modeller som degraderer på tvers av runder til tross for sunne benchmarker.
• Kjør samtale-nivå scoring som porten din og glidende-vindu scoring for å lokalisere brudd.
• Fire kjernemetrikker pluss ett egendefinert kriterium dekker de fleste chatprodukter; binære sjekker før dommere, alltid.
• DeepEval for simulerte regresjonstester, RAGAS for feilanalyse-drevne kritikere, Langfuse for produksjonsspor.
• Dommerkostnader er små (under en dollar per 100 samtaler på en mini-modell); kostnad er sjelden blokkereren.

For det bredere verktøylandskapet, rangerte vi hele feltet i vår beste LLM-evalueringsverktøy-oppsummering. Og hvis du heller vil bygge eval-pipen med noen, ta en gratis konsultasjon med Techsy-teamet.