Evaluare LLM multi-turn: 5 metrici, 3 frameworkuri, 1 workflow

Evaluare LLM multi-turn: 5 metrici, 3 frameworkuri, 1 workflow

Evaluarea LLM multi-turn este singura metodă de a prinde bug-ul amneziei din tura 8: utilizatorul și-a dat numărul de comandă în tura 3, iar botul îl cere din nou. Fiecare tură în parte a trecut; conversația tot a eșuat. DeepEval 4.0 și RAGAS 0.4 au lansat API-uri dedicate de evaluare conversațională exact pentru asta, iar după două incidente de eval în propriul nostru pipeline de la Techsy, iată cele cinci metrici, trei frameworkuri și un workflow cu care să începi.

Idei principale

• Evaluarea multi-turn notează conversații întregi, nu perechi izolate de input-output.
• Modelele din vârful benchmarkurilor single-turn se degradează măsurabil de la o tură la alta.
• Începe cu patru metrici: completimea, retenția cunoștințelor, respectarea rolului, relevanța turei.
• DeepEval, RAGAS și Langfuse rezolvă diferit eval-ul multi-turn; tabelul de mai jos le compară.

De ce te mint scorurile single-turn?

Eval-urile single-turn notează câte o pereche input-output o dată, deci nu pot vedea eșecurile care apar doar de-a lungul turelor: uitarea, contradicția, deriva. Un model poate obține un scor puternic în benchmark și totuși să piardă firul unei conversații live. Laban et al. documentează asta în LLMs Get Lost In Multi-Turn Conversation, 353 de citări: performanța se degradează în scenarii multi-turn chiar și atunci când rezultatele single-turn arată sănătos.

Problema de fond este non-determinismul: al n-lea răspuns depinde de toate cele n-1 ture anterioare, deci prompturi identice se comportă diferit în funcție de istoric. Un dataset de perechi izolate nu exercită niciodată această dependență. Survey-ul arXiv Evaluating LLM-based Agents for Multi-Turn Conversations, o revizuire PRISMA a circa 250 de surse, împarte domeniul în ce evaluezi (managementul contextului, planificare, coerență) și cum (metrici, judecători LLM, revizuire umană). Ambele axe lipsesc dintr-o suită single-turn.

Nimic din toate astea nu face inutilă suita ta single-turn. Dacă rulezi metrici single-turn precum BLEU, ROUGE și G-Eval, păstrează-le pentru ce măsoară bine: conformitatea formatului, toxicitatea, recall-ul factual pe un prompt fix. Doar nu le mai citi ca verificare de sănătate a conversației pe care o ating utilizatorii tăi.

Interpretarea noastră a acelor studii, într-o singură linie:

Eval-urile single-turn măsoară răspunsul, evaluarea multi-turn măsoară conversația, iar un model care excelează în tura unu poate fi pierdut până în tura cinci.

Ce este evaluarea LLM multi-turn? Cele două moduri de evaluare

Evaluarea LLM multi-turn este practica de a nota o conversație întreagă, sau ferestre din ea, în locul perechilor izolate prompt-răspuns. Se întreabă dacă modelul a păstrat contextul, a rămas în rol și a rezolvat problema utilizatorului de-a lungul turelor. Două moduri fac treaba: scorul la nivel de conversație și scorul pe ture cu fereastră glisantă, iar majoritatea echipelor le rulează pe ambele.

Scorul la nivel de conversație înmânează judecătorului transcriptul complet și pune o singură întrebare: a fost această conversație un succes? Prinde închiderea prematură și buclele nerezolvate, pentru că doar firul întreg arată că utilizatorul nu și-a primit niciodată rambursarea. Slăbiciunea lui este granularitatea: „eșec" pe un fir de 12 ture nu spune unde s-au rupt lucrurile.

Scorul pe ture cu fereastră glisantă mută o fereastră de N ture de-a lungul transcriptului, câte un verdict per fereastră. O fereastră de 3 pe o conversație de 10 ture produce 8 verdicte legate de regiuni ale chatului, deci „eșec" vine cu coordonate: ruptura s-a întâmplat în turele 6-8. Diagrama din vârful acestui articol arată ambele moduri pe același fir: o acoladă pentru verdictul conversației, un cadru glisant pentru verdictele pe fereastră.

Folosește scorul la nivel de conversație ca poartă și scorul pe ferestre pentru a localiza eșecurile când aceasta cedează. Ghidul DeepEval de evaluare multi-turn definește unitatea de lucru ca scenariu, nu ca pereche input-output (tipul său ConversationalGolden): testezi o situație, nu o întrebare.

Exemplu ilustrativ (sintetic; arată mecanica, nu o rulare reală): o fereastră glisantă de 3 pe un chat de retur de 8 ture.

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?

Verdict la nivel de conversație: eșuat. Cinci din șase ferestre au trecut, iar firul tot s-a rupt la retenția cunoștințelor, exact eșecul pe care o suită single-turn nu îl scoate niciodată la suprafață.

Care metrici multi-turn contează? Cele 5 care chiar contează

Rulează mai întâi patru metrici: completimea conversației, retenția cunoștințelor, respectarea rolului și relevanța turei. Adaugă o a cincea, un criteriu custom (G-Eval în DeepEval, AspectCritic în RAGAS), pentru orice produsul tău nu are voie să greșească. Primele patru se transferă între proiecte; a cincea este locul unde trăiesc modurile tale de eșec.

1. Completimea conversației. Scopul utilizatorului a fost rezolvat sau botul și-a declarat victoria prea devreme? Detectorul tău de închidere prematură.
2. Retenția cunoștințelor. Își amintește modelul faptele enunțate mai devreme în fir? Bug-ul amneziei din tura 8 este un eșec de retenție a cunoștințelor.
3. Respectarea rolului. Asistentul rămâne în persona lui și refuză cererile din afara scopului? Critic atunci când există o graniță de conformitate.
4. Relevanța turei. Fiecare răspuns este pe subiect, date fiind turele precedente? Prinde deriva și buclele.
5. Un criteriu custom. O regulă în limbaj natural pentru domeniul tău: „nu cita niciodată un preț care diferă de lista de prețuri". DeepEval implementează asta ca ConversationalGEval; RAGAS ca AspectCritic.

Ghidul de metrici DeepEval definește fiecare cu clase rulabile, dar conceptele sunt independente de framework: tabelul rămâne valabil chiar dacă îți construiești judecătorul manual.

Un criteriu custom se citește ca o propoziție:

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

Aceeași regulă ca cod DeepEval real:

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: care framework se potrivește?

Toate trei evaluează conversații multi-turn, dar unitatea lor de evaluare diferă: DeepEval simulează scenarii offline, RAGAS notează aspecte ale conversațiilor pe care le ai deja, iar Langfuse evaluează trace-uri reale din producție. Alege după originea conversațiilor tale, nu după numărul de funcții.

Mai întâi logica independentă de framework, ca să poți purta codul de vendor de mai jos:

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: scenarii și un simulator cu toate bateriile incluse

DeepEval este singurul cu un simulator de conversații de primă clasă: descrii un scenariu și o persona, iar el joacă rolul utilizatorului în fața botului tău. Ghidul său de evaluare multi-turn este referința canonică pentru tiparul scenariu-nu-perechi. Confident AI vinde dashboard-ul găzduit; recenzia noastră Confident AI acoperă ce adaugă stratul plătit.

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: condus de analiza erorilor, aspect cu aspect

RAGAS pornește de la conversațiile pe care le ai deja și le notează aspect cu aspect. Ghidul său how-to multi-turn se împerechează cu analiza manuală a erorilor: citești chat-urile eșuate, scrii un AspectCritic per mod de eșec, notezi.

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: evaluare N+1 pe trace-uri reale

Langfuse merge pe drumul opus: tracer mai întâi. Cookbook-ul său N+1 evaluează trace-ul fiecărei ture plus conversația ca întreg, pe trafic de producție, nu pe simulări. Dacă încă alegi stratul de observabilitate, comparația noastră Langfuse vs LangSmith acoperă acea decizie.

Verdictul nostru, fără stat pe gard: pentru un proiect nou de chatbot, începe cu DeepEval. Simulatorul îți permite să porți regresiile înainte de a avea trafic de producție, exact când ai cea mai mare nevoie de teste. Adaugă Langfuse când există fire reale; apelează la RAGAS când echipa ta preferă să citească conversațiile eșuate și să codifice ce găsește.

Cum treci de la analiza erorilor la automatizare?

Le pui în secvență. Citești 20-30 de conversații reale, etichetezi manual modurile de eșec, scrii verificări binare trecut/eșuat pentru cele evidente, le automatizezi pe acelea și abia apoi adaugi metrici judecate de LLM pentru reziduul subiectiv. Hamel Husain susține exact această ordine: întâi analiza manuală a erorilor și deciziile binare, pentru că o verificare pe care o poți explica bate un scor pe care nu îl poți explica.

Binare înaintea judecătorului: secvențierea care ne-a salvat

Asta nu este un benchmark de chatbot pe care l-am rulat; este interpretarea noastră a aceluiași tipar în propriul nostru pipeline de conținut, care rulează verificări de regresie cu poartă de eval la fiecare schimbare de prompt sau de tooling. Două incidente ne-au dovedit secvențierea.

Pe 13.06.2026, un bug de republicare a creat slug-uri localizate noi și a livrat 54 de documente live duplicate. Le-am găsit și retras pe 05.07.2026 (backup la techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json). Fix-ul nu a fost un model mai deștept; a fost o verificare deterministă pre-publicare: rezolvă documentul existent după postul canonic plus limbă înainte de orice creare. O poartă binară.

Al doilea incident: LLM-urile de traducere emit ocazional ASCII în loc de Unicode, transformând „karşılaştırma" în „karsilastirma". Nu e nevoie de judecător; o poartă grep îl prinde:

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

Ambele au fost prinse de verificări care costă fracțiuni de cent și afișează exact de ce au eșuat. Mapează asta pe eval-uri multi-turn: „botul a cerut din nou un câmp pe care utilizatorul l-a dat deja?" este o potrivire de șiruri pe transcript, nu un apel de judecător. Rulează întâi porțile deterministe ieftine; ele prind eșecurile urâte înainte ca judecătorul tău scump să ruleze vreodată.

Când este un judecător LLM unealta potrivită

Judecătorii își câștigă costul în tokeni pe criterii pe care nu le poți reduce la o regulă: „tonul a fost potrivit de plin de scuze?", „rezolvarea s-a potrivit situației?" Dacă poți scrie o aserțiune, scrie o aserțiune. Un rubric plin de judecăți de valoare este teritoriul judecătorului.

Linia la care ne întorcem mereu:

Începe cu verificări binare trecut/eșuat pe care le poți explica unui coleg, apoi adaugă judecători LLM doar pentru ce nu poți reduce la o regulă.

Cum simulezi conversații la scară și cât costă judecarea?

Simulează din scenarii, nu din jurnaluri exportate. Scenariile testează ce s-ar putea întâmpla; jurnalele arată doar ce sistemul tău actual a permis deja. Ghidul DeepEval avertizează că conversațiile istorice au fost modelate de sistemul care le-a produs, deci benchmarking-ul pe ele îngheață status quo-ul.

Scenarii, nu transcripte

Scrie fiecare scenariu ca scop plus persona: „client nerăbdător care returnează o comandă deteriorată", „utilizator care se răzgândește în mijlocul rezervării". Stabilește o limită de ture (10 este rezonabil) și o condiție de oprire: scop atins, utilizatorul abandonează sau limita. DeepEval recomandă cel puțin 20 de scenarii diverse, acoperind cazurile de utilizare principale, cazurile limită și situațiile predispuse la eșec; sub asta, suita ta măsoară anecdote.

Persona-uri adversariale

Include persona-uri care încearcă să spargă botul: un utilizator furios care escaladează, un utilizator confuz care se contrazice, un utilizator de injecție care strecoară instrucțiuni în tura 4. Injecția multi-turn este o disciplină în sine; ghidul nostru de guardrail-uri LLM acoperă stratul defensiv care se împerechează cu aceste teste, iar cookbook-ul Langfuse de simulare arată bucla simulatorului de utilizator.

Cât costă 100 de conversații evaluate

Fiecare cifră de mai jos este o estimare din numărul declarat de tokeni și prețuri publice, nu o măsurătoare pe care am rulat-o. Aritmetica este ideea: înlocuiește cu propriile tale numere.

Sub un dolar pentru 100 de conversații judecate complet. Un judecător mai scump mută asta de 10-50 de ori, iar tacticile din ghidul nostru de reducere a costurilor API LLM se aplică: pune în cache textul criteriilor, procesează ferestrele în loturi, folosește modelul ieftin pentru porțile binare.

Un workflow de eval multi-turn în 6 pași

Bucla rulează așa: definești scenarii din eșecuri reale, alegi patru metrici de bază plus una custom, simulezi cel puțin 20 de scenarii, stabilești linia de bază a versiunii curente, porți regresiile în CI și alimentezi eșecurile din producție înapoi în setul de scenarii.

1. Definește scenarii din eșecuri. Citește 20-30 de transcripte (sau, înainte de lansare, scrie-le din tichete de suport). Fiecare scenariu primește un scop, o persona și o limită de ture. Responsabil: tu și metoda error-analysis-first a lui Hamel.
2. Alege patru metrici, una custom. Completime, retenția cunoștințelor, respectarea rolului, relevanța turei și un ConversationalGEval sau AspectCritic pentru greșeala scumpă a domeniului tău.
3. Simulează. Rulează cel puțin 20 de scenarii, inclusiv setul adversarial. Responsabil: ConversationSimulator din DeepEval sau cookbook-ul de simulare Langfuse.
4. Stabilește linia de bază a versiunii curente. Înregistrează mediile per metrică pe 3 rulări, pentru că modelele sunt non-deterministe și o singură rulare este zgomot. Responsabil: scriptul tău de eval, rezultatele comise în repo.
5. Pune poartă pe regresiuni în CI. Stabilește un prag per metrică și fă build-ul să eșueze la o regresie dincolo de toleranță:

# 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. Monitorizează firele din producție. Grupează trace-urile live pe fir, evaluează asincron și transformă fiecare fir eșuat într-un scenariu nou. Responsabil: Langfuse sau tracerul tău; ghidurile noastre despre evaluarea agenților AI în producție și observabilitate AI acoperă jumătatea de monitorizare.

Suita nu se termină niciodată: pasul 6 îl alimentează pe pasul 1, iar setul de scenarii crește cu fiecare eșec din producție pe care îl prinzi.

Cum evaluezi tonul în mai multe limbi?

O metrică de respectare a rolului reglată pe date în engleză va trece un transcript turcesc sau japonez pe care un vorbitor nativ îl consideră nepoliticos, pentru că registrul de politețe este specific limbii. Rubricul tău în engleză nu are cuvinte pentru asta. Soluția: un criteriu de aspect per așteptare de registru, scris per limbă, nu o singură metrică globală de ton.

Un criteriu per registru

Interpretarea noastră a tiparului AspectCritic din RAGAS, extinsă din rularea unui pipeline în 23 de limbi, nu un rezultat de test publicat:

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

Fiecare criteriu este un critic binar separat pe același transcript. Nu am publicat scoruri de ton între limbi și nu am avea încredere într-un articol care le afișează fără rubric. Din munca pe pipeline: eșecurile se grupează în turele de scuză și escaladare, unde registrul colapsează primul.

Despre autor

Mert Batur este Co-Founder al Techsy.io, unde echipa livrează agenți AI, sisteme de automatizare și pipeline-uri voce/SDR pentru clienți B2B. Scrie despre stack-ul de tooling LLM pe care echipa Techsy îl folosește efectiv în producție. Credite: Co-Founder, Techsy.io. Conectează-te pe LinkedIn.

Întrebări frecvente

Ce este un LLM de conversație multi-turn?

Un model de limbaj al cărui al n-lea răspuns depinde de toate turele anterioare, nu doar de ultimul prompt. Se condiționează pe firul complet, deci comportamentul se schimbă odată cu istoricul conversației. Acea dependență de context este ceea ce testele single-turn nu pot exercita și ceea ce evaluarea multi-turn există să noteze.

Ce înseamnă evaluarea LLM?

Măsurarea calității outputului față de criterii definite, automat și repetabil, în loc de a te baza pe simț. Evaluarea single-turn notează perechi izolate prompt-răspuns față de metrici precum BLEU sau un judecător LLM. Evaluarea multi-turn extinde asta la conversații întregi, notând retenția contextului și completarea scopului de-a lungul turelor, nu per prompt.

Cum faci benchmark pentru performanța LLM multi-turn?

Construiește cel puțin 20 de scenarii cu scopuri și persona, simulează-le împotriva modelului și notează cu metrici la nivel de conversație plus verificări pe ferestre glisante. Înregistrează linii de bază pe mai multe rulări pentru a absorbi non-determinismul, apoi compară fiecare versiune nouă cu linia de bază în CI. Trace-urile din producție extind benchmark-ul mai târziu.

Care sunt cele mai bune moduri de a evalua un LLM?

Pune-le în secvență: întâi analiza manuală a erorilor, apoi porți binare trecut/eșuat pentru tot ce se poate reduce la o regulă, apoi LLM-ca-judecător pentru criterii subiective precum tonul și calitatea rezolvării. Verificările binare sunt mai ieftine, depanabile și nu derivează; judecătorii aparțin criteriilor care chiar necesită judecată, după ce porțile ieftine trec.

Cu ce metrici de evaluare multi-turn ar trebui să încep?

Completimea conversației, relevanța turei și retenția cunoștințelor; ele prind cele mai frecvente eșecuri (scopuri nerezolvate, derivă, uitare) în orice produs de chat. Adaugă respectarea rolului dacă botul tău are o graniță de conformitate, apoi un criteriu custom G-Eval sau AspectCritic pentru greșeala pe care afacerea ta nu și-o permite.

Cât costă LLM-ca-judecător per conversație?

Cu o fereastră glisantă de 5 pe 10 ture plus un apel la nivel de conversație, faci 7 apeluri de judecător per conversație. La aproximativ 2.000 de tokeni input per apel pe GPT-4o-mini, estimarea noastră cu calculul la vedere ajunge la aproximativ 0,29 $ per 100 de conversații. Modelele judecător premium ridică asta de 10-50 de ori.

DeepEval vs RAGAS pentru evaluare multi-turn: pe care să îl aleg?

DeepEval dacă vrei teste de regresie offline cu un simulator de conversații integrat, mai ales înainte de a avea trafic de producție. RAGAS dacă workflow-ul tău pornește din citirea conversațiilor reale eșuate și codificarea fiecărui mod de eșec ca AspectCritic. O împărțire frecventă: DeepEval în CI, critici în stil RAGAS pe jurnalele din producție.

De câte scenarii am nevoie pentru o suită de eval multi-turn?

Cel puțin 20, acoperind cazurile de utilizare principale, cazurile limită și situațiile predispuse la eșec; acel prag vine din ghidul publicat de DeepEval și se potrivește cu experiența noastră. Sub 20, ratele de trecere oscilează în funcție de scenariile care au fost incluse. Crește setul cu fiecare eșec din producție.

Pot rula evaluare multi-turn în CI/CD?

Da. Ține un set fix de scenarii în repo, rulează-l la fiecare schimbare de prompt sau model și fă build-ul să eșueze când o metrică regresează dincolo de toleranță față de linia de bază. Pentru că modelele sunt non-deterministe, compară medii pe 3 rulări cu o toleranță (noi folosim 0,03), nu praguri exacte.

Cum evaluez conversațiile multi-turn în producție?

Grupează trace-urile pe fir de conversație, notează fiecare fir asincron ca evaluarea să nu blocheze niciodată un răspuns și direcționează firele eșuate într-o coadă de revizuire. Fiecare eșec confirmat devine un scenariu nou în suita ta offline, închizând bucla dintre monitorizare și testele de regresie.

Versiunea scurtă

• Scorurile single-turn nu pot vedea eșecurile conversaționale; cercetarea arată modele degradându-se de-a lungul turelor în ciuda unor benchmarkuri sănătoase.
• Rulează scorul la nivel de conversație ca poartă și scorul pe fereastră glisantă pentru a localiza rupturile.
• Patru metrici de bază plus un criteriu custom acoperă majoritatea produselor de chat; verificări binare înaintea judecătorilor, întotdeauna.
• DeepEval pentru teste de regresie simulate, RAGAS pentru critici conduse de analiza erorilor, Langfuse pentru trace-uri din producție.
• Costurile judecătorului sunt mici (sub un dolar per 100 de conversații pe un model mini); costul este rareori blocajul.

Pentru contextul mai larg al instrumentelor, am clasat întregul domeniu în sinteza noastră cu cele mai bune instrumente de evaluare LLM. Iar dacă preferi să construiești pipeline-ul de eval împreună cu cineva, obține o consultație gratuită cu echipa Techsy.