Flerturns LLM-utvärdering: 5 mått, 3 ramverk, 1 arbetsflöde

Flerturns LLM-utvärdering: 5 mått, 3 ramverk, 1 arbetsflöde

Flerturns LLM-utvärdering är enda sättet att fånga amnesibuggen vid tur 8: användaren lämnade sitt ordernummer vid tur 3, och boten frågar efter det igen. Varje enskild tur klarade sig isolerat; konversationen misslyckades ändå. DeepEval 4.0 och RAGAS 0.4 levererade dedikerade konversations-eval-API:er för just detta, och efter två eval-incidenter i vår egen pipeline på Techsy följer här de fem måtten, tre ramverk och ett arbetsflöde att börja med.

Det viktigaste

• Flerturnsutvärdering bedömer hela konversationer, inte isolerade indata-utdata-par.
• Modeller som toppar singelturns-benchmark försämras mätbart över konversationsturer.
• Börja med fyra mått: fullständighet, kunskapsbevarande, rollföljsamhet, turrelevans.
• DeepEval, RAGAS och Langfuse löser flerturns-eval på olika sätt; ramverkstabellen nedan jämför dem.

Varför ljuger singelturns-poäng för dig?

Singelturns-eval bedömer ett indata-utdata-par i taget, så de kan inte se fel som bara dyker upp över turerna: glömska, motsägelser, drift. En modell kan sätta ett starkt benchmarkresultat och ändå tappa tråden i en pågående konversation. Laban et al. dokumenterar detta i LLMs Get Lost In Multi-Turn Conversation, 353 citeringar: prestandan försämras i flerturnsmiljöer även när singelturnsresultaten ser friska ut.

Kärnproblemet är icke-determinism: det n:te svaret beror på alla n-1 föregående turer, så identiska promptar beter sig olika beroende på historiken. Ett dataset med isolerade par provar aldrig det beroendet. arXiv-översikten Evaluating LLM-based Agents for Multi-Turn Conversations, en PRISMA-granskning av ungefär 250 källor, delar upp fältet i vad man utvärderar (kontexthantering, planering, sammanhang) och hur (mått, LLM-domare, mänsklig granskning). Båda axlarna saknas i en singelturns-svit.

Inget av detta gör din singelturns-stack värdelös. Kör du singelturns-mått som BLEU, ROUGE och G-Eval, behåll dem för det de mäter bra: formatföljsamhet, toxicitet, faktaminne på en fast prompt. Sluta bara läsa dem som en hälsokontroll för konversationen dina användare faktiskt har.

Vår tolkning av studierna, på en rad:

Singelturns-eval mäter svaret, flerturnsutvärdering mäter konversationen, och en modell som spikar tur ett kan ha tappat bort sig vid tur fem.

Vad är flerturns LLM-utvärdering? De två utvärderingslägena

Flerturns LLM-utvärdering är praktiken att bedöma en hel konversation, eller fönster i den, i stället för isolerade prompt-svar-par. Den frågar om modellen behöll kontexten, höll sig i rollen och löste användarens problem över turerna. Två lägen gör jobbet: bedömning på konversationsnivå och glidande fönsterbedömning på turnivå, och de flesta team kör båda.

Bedömning på konversationsnivå ger domaren hela transkriptet och ställer en fråga: var den här konversationen framgångsrik? Den fångar för tidig avslutning och olösta loopar, eftersom bara hela tråden avslöjar att användaren aldrig fick sin återbetalning. Svagheten är granularitet: "misslyckades" på en 12-turstråd säger inte var det brast.

Glidande fönsterbedömning på turnivå flyttar ett fönster på N turer över transkriptet, en dom per fönster. Ett fönster på 3 över en 10-turskonversation ger 8 domar bundna till regioner av chatten, så "misslyckades" får koordinater: brottet skedde i tur 6 till 8. Diagrammet överst i det här inlägget visar båda lägena på en tråd: en klammer för konversationsdomen, en glidande ram för domar per fönster.

Använd bedömning på konversationsnivå som grind, fönsterbedömning för att lokalisera fel när den slår ut. DeepEvals flerturnsguide ramar in arbetsenheten som ett scenario snarare än ett indata-utdata-par (deras ConversationalGolden-typ): du testar en situation, inte en fråga.

Illustrerande exempel (syntetiskt; visar mekaniken, inte en riktig körning): ett glidande fönster på 3 över en 8-turs chatt om en returbegäran.

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?

Dom på konversationsnivå: underkänd. Fem av sex fönster godkändes, och tråden brast ändå i kunskapsbevarande, exakt det fel en singelturns-svit aldrig visar.

Vilka flerturnsmått spelar roll? De 5 som gör det

Kör fyra mått först: konversationsfullständighet, kunskapsbevarande, rollföljsamhet och turrelevans. Lägg till ett femte, ett anpassat kriterium (G-Eval i DeepEval, AspectCritic i RAGAS), för det som din produkt inte får att få fel. De fyra första överförs mellan projekt; det femte är där dina felformer bor.

1. Konversationsfullständighet. Blev användarens mål löst, eller förklarade boten seger för tidigt? Din detektor för för tidig avslutning.
2. Kunskapsbevarande. Kommer modellen ihåg fakta som angivits tidigare i tråden? Amnesibuggen vid tur 8 är ett kunskapsbevarandefel.
3. Rollföljsamhet. Håller sig assistenten inom sin persona och nekar begäranden utanför ramen? Kritiskt vid en efterlevnadsgräns.
4. Turrelevans. Är varje svar i ämnet givet föregående turer? Fångar drift och loopar.
5. Ett anpassat kriterium. En regel på vanlig svenska för din domän: "ange aldrig ett pris som skiljer sig från prislistan." DeepEval implementerar detta som ConversationalGEval; RAGAS som AspectCritic.

DeepEvals måttguide definierar varje mått med körbara klasser, men koncepten är ramverksoberoende: tabellen gäller även om du bygger din domare själv.

Ett anpassat kriterium läses som en mening:

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

Samma regel som riktig DeepEval-kod:

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: Vilket ramverk passar?

Alla tre utvärderar flerturnskonversationer, men deras utvärderingsenhet skiljer sig: DeepEval simulerar scenarier offline, RAGAS bedömer aspekter av konversationer du redan har, och Langfuse utvärderar riktiga produktionsspår. Välj efter var dina konversationer kommer ifrån, inte efter antal funktioner.

Ramverksoberoende logik först, så att leverantörskoden nedan är 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 och en komplett simulator

DeepEval är det enda med en förstklassig konversationssimulator: beskriv ett scenario och en persona, så spelar den användaren mot din bot. Dess flerturnsguide är standardreferensen för mönstret scenario-inte-par. Confident AI säljer den hostade dashboarden; vår Confident AI-recension täcker vad det betalda lagret lägger till.

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: felanalysdriven, aspekt för aspekt

RAGAS utgår från konversationer du redan har och bedömer dem aspekt för aspekt. Dess flerturns-how-to paras med manuell felanalys: läs misslyckade chatter, skriv en AspectCritic per felform, poängsätt.

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-utvärdering på riktiga spår

Langfuse tar motsatt väg: tracer först. Dess N+1-cookbook utvärderar varje turs spår plus konversationen som helhet, på produktionstrafik snarare än simuleringar. Om du fortfarande väljer observabilitetslager täcker vår jämförelse Langfuse vs LangSmith det beslutet.

Vår dom, utan att sitta på staketet: för ett nytt chatbotprojekt, börja med DeepEval. Simulatorn låter dig grinda regressioner innan du har produktionstrafik, när du som mest behöver tester. Lägg till Langfuse när riktiga trådar finns; ta till RAGAS när ditt team hellre läser misslyckade konversationer och kodifierar det de hittar.

Hur går du från felanalys till automatisering?

Du sekvensierar det. Läs 20-30 riktiga konversationer, märk felformer för hand, skriv binära godkänd/underkänd-kontroller för de uppenbara, automatisera dem, och lägg först då till LLM-dömda mått för den subjektiva resten. Hamel Husain menar exakt denna ordning: manuell felanalys och binära beslut först, eftersom en kontroll du kan förklara slår ett poäng du inte kan.

Binärt före domare: sekvenseringen som räddade oss

Det här är inte en chatbot-benchmark vi körde; det är vår tolkning av samma mönster i vår egen content-pipeline, som kör eval-grindade regressionskontroller på varje prompt- och verktygsändring. Två incidenter bevisade sekvenseringen för oss.

Den 2026-06-13 myntade en återpubliceringsbugg nya lokaliserade slugs och skeppade 54 dubblettdokument live. Vi hittade och avpublicerade dem den 2026-07-05 (backup i techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json). Fixen var inte en smartare modell; det var en deterministisk förpubliceringskontroll: lös upp det befintliga dokumentet via canonical post plus språk före varje create. En binär grind.

Andra incidenten: översättar-LLM:er matar ibland ut ASCII i stället för Unicode, och gör "karşılaştırma" till "karsilastirma." Ingen domare behövs; en grep-grind fångar det:

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

Båda fångades av kontroller som kostar bråkdelar av ett öre och skriver ut exakt varför de misslyckades. Översätt det till flerturns-eval: "frågade boten efter ett fält användaren redan lämnat?" är en strängmatchning mot transkriptet, inte ett domaranrop. Kör billiga deterministiska grindar först; de fångar de fula felen innan din dyra domare någonsin kör.

När en LLM-domare faktiskt är rätt verktyg

Domare tjänar sin tokenkostnad på kriterier du inte kan reducera till en regel: "var tonen lämpligt ursäktande?", "passade lösningen situationen?" Kan du skriva ett påstående, skriv ett påstående. En bedömningsmall full av omdömesbedömningar är domarterritorium.

Linjen vi ständigt återkommer till:

Börja med binära godkänd/underkänd-kontroller du kan förklara för en kollega, och lägg sedan till LLM-domare bara för det du inte kan reducera till en regel.

Hur simulerar du konversationer i skala, och vad kostar bedömningen?

Simulera från scenarier, inte exporterade loggar. Scenarier testar vad som kan hända; loggar visar bara vad ditt nuvarande system redan tillät. DeepEvals vägledning varnar för att historiska konversationer formades av systemet som producerade dem, så benchmarking mot dem bakar in status quo.

Scenarier, inte transkript

Skriv varje scenario som mål plus persona: "otålig kund som returnerar en skadad beställning", "användare som ändrar sig mitt i en bokning." Sätt en maxgräns för turer (10 är rimligt) och ett stoppvillkor: målet nått, användaren överger, eller gränsen. DeepEval rekommenderar minst 20 varierade scenarier över primära användningsfall, kantfall och felbenägna situationer; under det mäter din svit anekdoter.

Adversariella personor

Inkludera personor som försöker bryta boten: en arg användare som eskalerar, en förvirrad användare som motsäger sig själv, en injectionsanvändare som smyger in instruktioner vid tur 4. Flerturns-injection är en egen disciplin; vår guide om LLM-guardrails täcker det försvarslager som paras med dessa tester, och Langfuses simulerings-cookbook visar användarsimulator-loopen.

Vad 100 utvärderade konversationer kostar

Varje siffra nedan är en uppskattning från angivna tokenantal och offentliga priser, inte en mätning vi körde. Matteövningen är poängen: byt in dina egna siffror.

Under en dollar för 100 fullt bedömda konversationer. En dyrare domare flyttar detta 10-50 gånger, och knepen i vår guide om att minska LLM API-kostnader gäller: cacha kriterietexten, batcha fönster, använd den billiga modellen för binära grindar.

Ett 6-stegs arbetsflöde för flerturns-eval

Loopen körs så här: definiera scenarier från riktiga fel, välj fyra kärnmått plus ett anpassat, simulera minst 20 scenarier, sätt en baslinje för nuvarande version, grinda regressioner i CI och mata tillbaka produktionsfel i scenarieuppsättningen.

1. Definiera scenarier från fel. Läs 20-30 transkript (eller, före lansering, skriv dem från supportärenden). Varje scenario får ett mål, en persona och en maxgräns för turer. Ägare: du och Hamels felanalys-först-metod.
2. Välj fyra mått, ett anpassat. Fullständighet, kunskapsbevarande, rollföljsamhet, turrelevans, och en ConversationalGEval eller AspectCritic för din domäns dyra misstag.
3. Simulera. Kör minst 20 scenarier inklusive den adversariella uppsättningen. Ägare: DeepEvals ConversationSimulator, eller Langfuses simulerings-cookbook.
4. Sätt baslinje för nuvarande version. Spela in medelvärden per mått över 3 körningar, eftersom modeller är icke-deterministiska och en enda körning är brus. Ägare: ditt eval-skript, resultat committade till repot.
5. Grinda regressioner i CI. Sätt en tröskel per mått och fäll bygget vid regression utöver en tolerans:

# 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. Övervaka produktionstrådar. Gruppera livetraces per tråd, utvärdera asynkront och gör varje underkänd tråd till ett nytt scenario. Ägare: Langfuse eller din tracer; våra guider om att utvärdera AI-agenter i produktion och AI-observabilitet täcker övervakningshalvan.

Sviten blir aldrig klar: steg 6 matar steg 1, och scenarieuppsättningen växer med varje produktionsfel du fångar.

Hur utvärderar du ton över språk?

Ett rollföljsamhetsmått trimmat på engelsk data godkänner ett turkiskt eller japanskt transkript som en modersmålstalare upplever som oartig, eftersom artighetsregister är språkspecifikt. Din engelska mall har inga ord för det. Fixen: ett aspektskriterium per registerförväntan, skrivet per språk, inte ett globalt tonmått.

Ett kriterium per register

Vår tolkning av RAGAS AspectCritic-mönster, utökad från att driva en 23-språkig pipeline, inte ett publicerat 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?"

Varje kriterium är en separat binär kritiker på samma transkript. Vi har inte publicerat tvärspråkliga tonpoäng, och skulle inte lita på en artikel som skriver ut dem utan mallen. Från pipeline-arbetet: fel hopar sig vid ursäkts- och eskaleringsturer, där registret kollapsar först.

Vanliga frågor

Vad är en flerturns-konversations-LLM?

En språkmodell vars n:te svar beror på alla föregående turer, inte bara den senaste prompten. Den vilar på hela tråden, så beteendet ändras med konversationshistoriken. Det kontextberoendet är vad singelturns-tester inte kan prova och vad flerturnsutvärdering finns till för att bedöma.

Vad betyder LLM-utvärdering?

Att mäta utdatakvalitet mot definierade kriterier, automatiskt och upprepningsbart, i stället för på känsla. Singelturnsutvärdering bedömer isolerade prompt-svar-par mot mått som BLEU eller en LLM-domare. Flerturnsutvärdering utökar det till hela konversationer och bedömer kontextbevarande och måluppfyllelse över turer snarare än per prompt.

Hur benchmarkar man flerturns-LLM-prestanda?

Bygg minst 20 scenarier med mål och personor, simulera dem mot modellen och bedöm med mått på konversationsnivå plus glidande fönster-kontroller. Spela in baslinjer över flera körningar för att absorbera icke-determinism, och jämför sedan varje ny version mot baslinjen i CI. Produktionsspår utökar benchmarken senare.

Vilka är de bästa sätten att utvärdera en LLM?

Sekvensiera det: manuell felanalys först, sedan binära godkänd/underkänd-grindar för allt som kan reduceras till en regel, sedan LLM-som-domare för subjektiva kriterier som ton och lösningskvalitet. Binära kontroller är billigare, felsökbara och driver inte; domare hör hemma på kriterier som verkligen kräver omdöme, efter att de billiga grindarna passerat.

Vilka flerturns-utvärderingsmått ska jag börja med?

Konversationsfullständighet, turrelevans och kunskapsbevarande; de fångar de vanligaste felen (olösta mål, drift, glömska) i vilken chattprodukt som helst. Lägg till rollföljsamhet om din bot har en efterlevnadsgräns, sedan ett anpassat G-Eval- eller AspectCritic-kriterium för misstaget ditt företag inte har råd med.

Hur mycket kostar LLM-som-domare per konversation?

Med ett glidande fönster på 5 över 10 turer plus ett konversationsnivåanrop gör du 7 domaranrop per konversation. Med ungefär 2 000 indatatokens per anrop på GPT-4o-mini landar vår uträknade uppskattning på ungefär $0,29 per 100 konversationer. Premiumdomarmodeller höjer det 10-50 gånger.

DeepEval vs RAGAS för flerturnsutvärdering: vilken ska jag välja?

DeepEval om du vill ha offline-regressionstester med en inbyggd konversationssimulator, särskilt innan du har produktionstrafik. RAGAS om ditt arbetsflöde börjar med att läsa riktiga misslyckade konversationer och kodifiera varje felform som en AspectCritic. En vanlig uppdelning: DeepEval i CI, RAGAS-stil-kritiker på produktionsloggar.

Hur många scenarier behöver jag för en flerturns-eval-svit?

Minst 20, som täcker primära användningsfall, kantfall och felbenägna situationer; den tröskeln kommer från DeepEvals publicerade vägledning och matchar vår erfarenhet. Under 20 svänger godkännandegraden beroende på vilka scenarier som råkade komma med. Väx uppsättningen med varje produktionsfel.

Kan jag köra flerturnsutvärdering i CI/CD?

Ja. Håll en fast scenarieuppsättning i repot, kör den vid varje prompt- eller modelländring, och fäll bygget när ett mått regredierar utöver toleransen mot baslinjen. Eftersom modeller är icke-deterministiska, jämför medelvärden över 3 körningar med en tolerans (vi använder 0,03), inte exakta trösklar.

Hur utvärderar jag flerturnskonversationer i produktion?

Gruppera spår per konversationstråd, bedöm varje tråd asynkront så att utvärderingen aldrig blockerar ett svar, och routa underkända trådar till en granskningskö. Varje bekräftat fel blir ett nytt scenario i din offline-svit, och sluter loopen mellan övervakning och regressionstester.

Den korta versionen

• Singelturns-poäng kan inte se konversationsfel; forskning visar att modeller försämras över turer trots friska benchmark.
• Kör bedömning på konversationsnivå som grind och glidande fönsterbedömning för att lokalisera brott.
• Fyra kärnmått plus ett anpassat kriterium täcker de flesta chattprodukter; binära kontroller före domare, alltid.
• DeepEval för simulerade regressionstester, RAGAS för felanalysdrivna kritiker, Langfuse för produktionsspår.
• Domarkostnaderna är små (under en dollar per 100 konversationer på en minimodell); kostnad är sällan hindret.

För det bredare verktygslandskapet rankade vi hela fältet i vår sammanställning av de bästa LLM-utvärderingsverktygen. Och om du hellre bygger eval-pipelinen med någon, boka en gratis konsultation med Techsy-teamet.