Vícekolová evaluace LLM: 5 metrik, 3 frameworky, 1 workflow

Vícekolová evaluace LLM: 5 metrik, 3 frameworky, 1 workflow

Vícekolová evaluace LLM je jediný způsob, jak odhalit bug amnézie v 8. kole: uživatel sdělil číslo objednávky ve 3. kole a bot se na něj ptá znovu. Každé jednotlivé kolo prošlo samo o sobě; konverzace přesto selhala. DeepEval 4.0 a RAGAS 0.4 vydaly přesně pro tento účel dedikovaná konverzační eval API a po dvou eval incidentech v naší vlastní pipeline v Techsy následuje pět metrik, tři frameworky a jedno workflow pro začátek.

Klíčové body

• Vícekolová evaluace hodnotí celé konverzace, ne izolované páry vstup-výstup.
• Modely na špici single-turn benchmarků se napříč koly konverzace měřitelně zhoršují.
• Začněte se čtyřmi metrikami: úplnost, udržení znalostí, dodržování role, relevantnost kol.
• DeepEval, RAGAS a Langfuse řeší vícekolový eval odlišně; tabulka frameworků níže je porovnává.

Proč vám single-turn skóre lžou

Single-turn evaluace hodnotí vždy jeden pár vstup-výstup, takže nevidí selhání, která se projeví až napříč koly: zapomínání, rozpor, únik od tématu. Model může dosáhnout silného benchmarkového skóre, a přesto ztratit nit živé konverzace. Laban a kol. to dokumentují v LLMs Get Lost In Multi-Turn Conversation, 353 citací: výkon se ve vícekolovém prostředí zhoršuje, i když single-turn výsledky vypadají zdravě.

Jádrem problému je nedeterminismus: n-tá odpověď závisí na všech n-1 předchozích kolech, takže identické prompty se chovají různě podle historie. Dataset izolovaných párů tuto závislost nikdy neověří. arXiv survey Evaluating LLM-based Agents for Multi-Turn Conversations, PRISMA review zhruba 250 zdrojů, dělí pole na co se hodnotí (správa kontextu, plánování, koherence) a jak (metriky, LLM judgové, lidská kontrola). Obě osy v single-turn sadě chybí.

Nic z toho nedělá váš single-turn stack zbytečným. Pokud používáte single-turn metriky jako BLEU, ROUGE a G-Eval, nechte si je na to, co měří dobře: dodržování formátu, toxicitu, vybavení faktů u pevného promptu. Jen je přestaňte číst jako zdravotní prohlídku konverzace, které se vaši uživatelé skutečně dotýkají.

Naše interpretace těchto studií jednou větou:

Single-turn evaluace měří odpověď, vícekolová evaluace měří konverzaci a model, který zvládne první kolo, může být v pátém kole ztracený.

Co je vícekolová evaluace LLM? Dva režimy hodnocení

Vícekolová evaluace LLM je praxe hodnocení celé konverzace, případně oken uvnitř ní, místo izolovaných párů prompt-odpověď. Ptá se, zda model udržel kontext, zůstal v roli a vyřešil problém uživatele napříč koly. Práci odvádějí dva režimy: skórování na úrovni konverzace a skórování po kolech klouzavým oknem a většina týmů provozuje oba.

Skórování na úrovni konverzace předá judgovi celý přepis a položí jednu otázku: byla tato konverzace úspěšná? Odhalí předčasné ukončení a nevyřešené smyčky, protože jen celé vlákno ukáže, že uživatel nikdy nedostal refundaci. Jeho slabina je granularita: „neúspěch" u 12kolového vlákna neříká, kde se věci pokazily.

Skórování po kolech klouzavým oknem posouvá okno N kol napříč přepisem, jeden verdikt na okno. Okno 3 u 10kolové konverzace dá 8 verdiktů svázaných s oblastmi chatu, takže „neúspěch" nese souřadnice: k selhání došlo v kolech 6 až 8. Diagram na začátku tohoto článku ukazuje oba režimy na jednom vláknu: závorka pro verdikt konverzace, posuvný rám pro verdikty po oknech.

Skórování na úrovni konverzace používejte jako bránu, okenní skórování k lokalizaci selhání, když brána spadne. Průvodce vícekolovou evaluací od DeepEval vymezuje pracovní jednotku jako scénář, ne jako pár vstup-výstup (jeho typ ConversationalGolden): testujete situaci, ne otázku.

Ilustrativní příklad (syntetický; ukazuje mechaniku, ne reálný běh): klouzavé okno 3 napříč 8kolovým chatem o vrácení zboží.

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?

Verdikt na úrovni konverzace: neúspěch. Pět ze šesti oken prošlo, a přesto se vlákno rozbilo na udržení znalostí, přesně na selhání, které single-turn sada nikdy neodhalí.

Na kterých vícekolových metrikách záleží? Těch 5 podstatných

Nejprve spusťte čtyři metriky: úplnost konverzace, udržení znalostí, dodržování role a relevantnost kol. Přidejte pátou, vlastní kritérium (G-Eval v DeepEval, AspectCritic v RAGAS), pro cokoli, co si váš produkt nesmí dovolit pokazit. První čtyři se přenášejí mezi projekty; ta pátá je tam, kde žijí vaše módy selhání.

1. Úplnost konverzace. Došel cíl uživatele naplnění, nebo bot vyhlásil vítězství předčasně? Váš detektor předčasného ukončení.
2. Udržení znalostí. Pamatuje si model fakta uvedená dříve ve vláknu? Bug amnézie v 8. kole je selhání udržení znalostí.
3. Dodržování role. Zůstává asistent ve své personě a odmítá požadavky mimo rozsah? Kritické u compliance hranice.
4. Relevantnost kol. Je každá odpověď k tématu vzhledem k předchozím kolům? Odhalí úniky a smyčky.
5. Vlastní kritérium. Jedno pravidlo prostým jazykem pro vaši doménu: „nikdy neuváděj cenu, která se liší od ceníku." DeepEval to implementuje jako ConversationalGEval; RAGAS jako AspectCritic.

Průvodce metrikami DeepEval definuje každou se spustitelnými třídami, ale koncepty jsou nezávislé na frameworku: tabulka platí, i když si judge napíšete sami.

Vlastní kritérium se čte jako věta:

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

Totéž pravidlo jako skutečný kód DeepEval:

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: který framework sedí?

Všechny tři hodnotí vícekolové konverzace, ale jejich jednotka evaluace se liší: DeepEval simuluje scénáře offline, RAGAS skóruje aspekty konverzací, které už máte, a Langfuse hodnotí reálné produkční trasy. Vybírejte podle toho, odkud vaše konverzace pocházejí, ne podle počtu funkcí.

Nejprve logika nezávislá na frameworku, aby kód vendorů níže byl přenositelný:

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: scénáře a plně vybavený simulátor

DeepEval je jediný s prvotřídním simulátorem konverzace: popište scénář a personu a on hraje uživatele proti vašemu botovi. Jeho vícekolový průvodce je kanonická reference pro vzor scénář-ne-páry. Confident AI prodává hostovaný dashboard; naše recenze Confident AI pokrývá, co placená vrstva přidává.

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: řízený analýzou chyb, aspekt po aspektu

RAGAS začíná u konverzací, které už máte, a skóruje je aspekt po aspektu. Jeho vícekolový návod se páruje s ruční analýzou chyb: čtěte selhávající chaty, napište AspectCritic pro každý mód selhání, skórujte.

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: evaluace N+1 na reálných trasách

Langfuse jde opačnou cestou: nejprve tracer. Jeho N+1 cookbook hodnotí trasu každého kola plus konverzaci jako celek, na produkčním provozu místo simulací. Pokud stále vybíráte observační vrstvu, naše srovnání Langfuse vs LangSmith pokrývá toto rozhodnutí.

Náš verdikt, bez sezení na plotě: pro nový chatbot projekt začněte s DeepEval. Simulátor vám umožní hlídat regrese, než máte produkční provoz, tedy kdy testy nejvíc potřebujete. Langfuse přidejte, jakmile existují reálná vlákna; po RAGAS sáhněte, když váš tým dává přednost čtení selhávajících konverzací a kodifikaci toho, co najde.

Jak se dostat od analýzy chyb k automatizaci?

Držte se daného pořadí. Přečtěte 20-30 reálných konverzací, označte módy selhání ručně, napište binární kontroly prošel/neprošel pro ty zjevné, automatizujte je a teprve pak přidejte LLM-judge metriky pro subjektivní zbytek. Hamel Husain argumentuje přesně pro toto pořadí: nejprve ruční analýza chyb a binární rozhodnutí, protože kontrola, kterou dokážete vysvětlit, porazí skóre, které vysvětlit nedokážete.

Binární před judgem: pořadí, které nás zachránilo

Toto není benchmark chatbotů, který jsme spustili; je to naše interpretace téhož vzoru uvnitř naší vlastní obsahové pipeline, která spouští evaluací hradelné regresní kontroly při každé změně promptu a nástrojů. Dva incidenty nám toto pořadí potvrdily.

Dne 13. 6. 2026 bug republikace orazítkoval nové lokalizované slugy a expedoval 54 duplicitních živých dokumentů. Našli jsme je a zrušili jejich publikaci dne 5. 7. 2026 (záloha v techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json). Opravou nebyl chytřejší model; byla to deterministická kontrola před publikací: před jakýmkoli vytvořením vyřešit existující dokument podle kanonického příspěvku a jazyka. Binární brána.

Druhý incident: překladové LLM občas vypustí ASCII místo Unicode, změní „karşılaştırma" na „karsilastirma". Není třeba judge; odhalí to grep brána:

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

Obě odhalily kontroly, které stojí zlomky centu a přesně vypíší, proč selhaly. Přeneste to na vícekolové evaluace: „zeptal se bot znovu na pole, které uživatel už uvedl?" je porovnání řetězců proti přepisu, ne volání judge. Nejprve spusťte levné deterministické brány; odhalí ošklivá selhání dřív, než se váš drahý judge vůbec spustí.

Kdy je LLM judge skutečně ten správný nástroj

Judgové si svou tokenovou cenu zaslouží u kritérií, která nedokážete redukovat na pravidlo: „byl tón přiměřeně omluvný?", „odpovídalo řešení situaci?" Pokud dokážete napsat tvrzení, napište tvrzení. Rubrika plná posuzování je území pro judge.

Hranice, ke které se stále vracíme:

Začněte s binárními kontrolami prošel/neprošel, které dokážete vysvětlit kolegovi, a LLM judge přidejte jen pro to, co nedokážete redukovat na pravidlo.

Jak simulovat konverzace ve velkém a co stojí hodnocení?

Simulujte ze scénářů, ne z exportovaných logů. Scénáře testují, co se může stát; logy ukazují jen to, co váš současný systém už připustil. Doporučení DeepEval varuje, že historické konverzace formoval systém, který je vytvořil, takže benchmarkování proti nim zapeče status quo.

Scénáře, ne přepisy

Každý scénář pište jako cíl plus persona: „netrpělivý zákazník vracející poškozenou objednávku", „uživatel, který si to rozmyslí uprostřed rezervace". Nastavte limit kol (10 je rozumný) a podmínku zastavení: cíl dosažen, uživatel odchází, nebo limit. DeepEval doporučuje alespoň 20 rozmanitých scénářů napříč primárními případy použití, okrajovými případy a situacemi náchylnými k selhání; pod touto hranicí vaše sada měří anekdoty.

Adverzární persony

Zahrňte persony, které se snaží bota rozbít: rozzlobený uživatel, který eskaluje, zmatený uživatel, který si protiřečí, injekční uživatel, který ve 4. kole propašuje instrukce. Vícekolová injekce je vlastní disciplína; náš průvodce LLM guardrails pokrývá obrannou vrstvu, která se s těmito testy páruje, a simulační cookbook Langfuse ukazuje smyčku simulátoru uživatele.

Co stojí 100 vyhodnocených konverzací

Každá hodnota níže je odhad z uvedených počtů tokenů a veřejných cen, ne měření, které jsme provedli. Pointou je ta aritmetika: dosaďte vlastní čísla.

Méně než dolar za 100 plně hodnocených konverzací. Dražší judge to posune 10-50x a fungují taktiky z našeho průvodce snížením nákladů na LLM API: cachujte text kritérií, dávkujte okna, pro binární brány použijte levný model.

6krokové workflow vícekolové evaluace

Smyčka běží takto: definujte scénáře z reálných selhání, vyberte čtyři základní metriky plus jednu vlastní, simulujte alespoň 20 scénářů, zbaselineujte současnou verzi, hraďte regrese v CI a vracejte produkční selhání do sady scénářů.

1. Definujte scénáře ze selhání. Přečtěte 20-30 přepisů (nebo před startem napište ze support tiketů). Každý scénář dostane cíl, personu a limit kol. Vlastník: vy a metoda analýzy chyb jako první od Hamela.
2. Vyberte čtyři metriky, jednu vlastní. Úplnost, udržení znalostí, dodržování role, relevantnost kol a jeden ConversationalGEval nebo AspectCritic pro nákladnou chybu vaší domény.
3. Simulujte. Spusťte alespoň 20 scénářů včetně adverzární sady. Vlastník: ConversationSimulator od DeepEval nebo simulační cookbook Langfuse.
4. Zbaselineujte současnou verzi. Zaznamenejte průměry metrik ze 3 běhů, protože modely jsou nedeterministické a jeden běh je šum. Vlastník: váš eval skript, výsledky commitované v repu.
5. Hraďte regrese v CI. Nastavte práh pro každou metriku a nechte build spadnout při regresi nad toleranci:

# 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. Monitorujte produkční vlákna. Seskupte živé trasy podle vlákna, hodnotte asynchronně a převeďte každé selhávající vlákno na nový scénář. Vlastník: Langfuse nebo váš tracer; naši průvodci hodnocením AI agentů v produkci a AI observabilitou pokrývají monitorovací polovinu.

Sada není nikdy hotová: krok 6 sytí krok 1 a sada scénářů roste s každým produkčním selháním, které odhalíte.

Jak hodnotit tón napříč jazyky?

Metrika dodržování role vyladěná na anglických datech propustí turecký nebo japonský přepis, který rodilý mluvčí považuje za hrubý, protože registr zdvořilosti je jazykově specifický. Váš anglický hodnoticí rámec pro něj nemá slova. Oprava: jedno aspektové kritérium na každé očekávání registru, napsané pro daný jazyk, ne jedna globální metrika tónu.

Jedno kritérium na registr

Naše interpretace vzoru AspectCritic od RAGAS, rozšířená z provozování 23jazyčné pipeline, ne publikovaný výsledek testu:

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

Každé kritérium je samostatný binární kritik nad stejným přepisem. Skóre tónu napříč jazyky jsme nepublikovali a nedůvěřovali bychom článku, který je publikuje bez hodnoticího rámce. Z práce na pipeline: selhání se kupí v kolech omluvy a eskalace, kde se registr hroutí jako první.

O autorovi

Mert Batur je spoluzakladatel Techsy.io, kde tým dodává AI agenty, automatizační systémy a hlasové/SDR pipeline pro B2B klienty. Píše o stacku nástrojů LLM, který tým Techsy skutečně používá v produkci. Kvalifikace: spoluzakladatel, Techsy.io. Spojte se na LinkedIn.

Často kladené otázky

Co je vícekolová konverzační LLM?

Jazykový model, jehož n-tá odpověď závisí na všech předchozích kolech, ne jen na posledním promptu. Podmiňuje se celým vláknem, takže se chování mění s historií konverzace. Právě tuto závislost na kontextu nedokážou single-turn testy ověřit a vícekolová evaluace existuje, aby ji skórovala.

Co znamená evaluace LLM?

Měření kvality výstupu proti definovaným kritériím, automaticky a opakovatelně, místo podle pocitu. Single-turn evaluace skóruje izolované páry prompt-odpověď proti metrikám jako BLEU nebo LLM judge. Vícekolová evaluace to rozšiřuje na celé konverzace, skóruje udržení kontextu a naplnění cíle napříč koly místo po promptu.

Jak benchmarkovat výkon vícekolových LLM?

Sestavte alespoň 20 scénářů s cíli a personami, simulujte je proti modelu a skórujte metrikami na úrovni konverzace plus kontrolami klouzavým oknem. Zaznamenejte baseline z více běhů, abyste absorbovali nedeterminismus, a pak v CI porovnávejte každou novou verzi s baseline. Produkční trasy benchmark později rozšíří.

Jaké jsou nejlepší způsoby evaluace LLM?

Držte pořadí: nejprve ruční analýza chyb, pak binární brány prošel/neprošel pro vše, co jde redukovat na pravidlo, pak LLM-as-a-judge pro subjektivní kritéria jako tón a kvalita řešení. Binární kontroly jsou levnější, laditelné a nedriftují; judgové patří na kritéria, která skutečně vyžadují úsudek, a to až poté, co projdou levné brány.

Kterými vícekolovými metrikami evaluace mám začít?

Úplnost konverzace, relevantnost kol a udržení znalostí; ty odhalí nejčastější selhání (nevyřešené cíle, únik, zapomínání) v libovolném chatovém produktu. Přidejte dodržování role, pokud má váš bot compliance hranici, a pak jedno vlastní kritérium G-Eval nebo AspectCritic pro chybu, kterou si váš byznys nemůže dovolit.

Kolik stojí LLM-as-a-judge na konverzaci?

Při klouzavém okně 5 přes 10 kol plus jednom volání na úrovni konverzace provedete 7 volání judge na konverzaci. Při zhruba 2 000 vstupních tokenech na volání na GPT-4o-mini vychází náš odhad s uvedenou aritmetikou na asi $0,29 na 100 konverzací. Prémiové modely judge to zvýší 10-50x.

DeepEval vs RAGAS pro vícekolovou evaluaci: který vybrat?

DeepEval, pokud chcete offline regresní testy s vestavěným simulátorem konverzace, zejména než máte produkční provoz. RAGAS, pokud váš workflow začíná čtením reálných selhávajících konverzací a kodifikací každého módu selhání jako AspectCritic. Jedno časté rozdělení: DeepEval v CI, kritici ve stylu RAGAS na produkčních lozích.

Kolik scénářů potřebuji pro vícekolovou eval sadu?

Alespoň 20, pokrývajících primární případy použití, okrajové případy a situace náchylné k selhání; tato hranice vychází z publikovaného doporučení DeepEval a odpovídá naší zkušenosti. Pod 20 se míra úspěšnosti houpe podle toho, které scénáře se zrovna dostaly do sady. Sadu rozšiřujte s každým produkčním selháním.

Mohu spustit vícekolovou evaluaci v CI/CD?

Ano. Držte pevnou sadu scénářů v repu, spusťte ji při každé změně promptu nebo modelu a nechte build spadnout, když metrika zregreduje za toleranci vůči baseline. Protože modely jsou nedeterministické, porovnávejte průměry ze 3 běhů s tolerancí (používáme 0,03), ne přesné prahy.

Jak hodnotit vícekolové konverzace v produkci?

Seskupte trasy podle vlákna konverzace, skórujte každé vlákno asynchronně, aby evaluace nikdy neblokovala odpověď, a směrujte selhávající vlákna do fronty kontroly. Každé potvrzené selhání se stane novým scénářem ve vaší offline sadě, čímž se uzavírá smyčka mezi monitoringem a regresními testy.

Krátká verze

• Single-turn skóre nevidí konverzační selhání; výzkum ukazuje, že se modely napříč koly zhoršují navzdory zdravým benchmarkům.
• Skórování na úrovni konverzace používejte jako bránu a skórování klouzavým oknem k lokalizaci zlomů.
• Čtyři základní metriky plus jedno vlastní kritérium pokryjí většinu chatových produktů; binární kontroly vždy před judgy.
• DeepEval pro simulované regresní testy, RAGAS pro kritiky řízené analýzou chyb, Langfuse pro produkční trasy.
• Náklady na judge jsou malé (méně než dolar na 100 konverzací na mini modelu); náklady zřídka bývají překážkou.

Pro širší krajinu nástrojů jsme celé pole seřadili v našem přehledu nejlepších nástrojů evaluace LLM. A pokud chcete eval pipeline raději postavit s někým, získejte bezplatnou konzultaci s týmem Techsy.