Ewaluacja wieloturowa LLM: 5 metryk, 3 frameworki, 1 workflow

Ewaluacja wieloturowa LLM: 5 metryk, 3 frameworki, 1 workflow

Ewaluacja wieloturowa LLM to jedyny sposób, żeby wyłapać błąd amnezji z 8. tury: użytkownik podał numer zamówienia w turze 3, a bot znów o niego pyta. Każda pojedyncza tura przeszła w izolacji, a cała konwersacja i tak się nie udała. DeepEval 4.0 i RAGAS 0.4 wprowadziły dedykowane API do ewaluacji konwersacyjnej właśnie po to, a po dwóch incydentach eval w naszej własnej pipeline w Techsy przedstawiamy pięć metryk, trzy frameworki i jeden workflow na start.

Najważniejsze wnioski

• Ewaluacja wieloturowa ocenia całe konwersacje, nie izolowane pary wejście-wyjście.
• Modele ze szczytu benchmarków jednoturowych zauważalnie degradują się z każdą turą rozmowy.
• Zacznij od czterech metryk: kompletność konwersacji, retencja wiedzy, zgodność z rolą, trafność tur.
• DeepEval, RAGAS i Langfuse rozwiązują ewaluację wieloturową inaczej; poniższa tabela porównuje frameworki.

Dlaczego wyniki jednoturowe kłamią?

Ewaluacje jednoturowe punktują jedną parę wejście-wyjście naraz, więc nie widzą błędów, które pojawiają się dopiero na przestrzeni tur: zapominania, sprzeczności, dryfu. Model może mieć świetny wynik w benchmarku, a mimo to gubić wątek w żywej rozmowie. Laban i in. dokumentują to w pracy LLMs Get Lost In Multi-Turn Conversation, 353 cytowania: wydajność spada w ustawieniach wieloturowych, nawet gdy wyniki jednoturowe wyglądają zdrowo.

Sednem problemu jest niedeterminizm: n-ta odpowiedź zależy od wszystkich n-1 wcześniejszych tur, więc identyczne prompty zachowują się różnie w zależności od historii. Zbiór danych złożony z izolowanych par nigdy nie testuje tej zależności. Przegląd arXiv Evaluating LLM-based Agents for Multi-Turn Conversations, analiza PRISMA około 250 źródeł, dzieli dziedzinę na co oceniać (zarządzanie kontekstem, planowanie, spójność) i jak (metryki, sędziowie LLM, weryfikacja ludzka). W zestawie jednoturowym brakuje obu tych osi.

Nic z tego nie czyni Twojego stosu jednoturowego bezużytecznym. Jeśli używasz metryk jednoturowych takich jak BLEU, ROUGE i G-Eval, zostaw je do tego, co mierzą dobrze: zgodność z formatem, toksyczność, przywoływanie faktów dla stałego promptu. Przestań tylko traktować je jako test zdrowia konwersacji, z którymi stykają się Twoi użytkownicy.

Nasza interpretacja tych badań w jednym zdaniu:

Ewaluacje jednoturowe mierzą odpowiedź, ewaluacja wieloturowa mierzy konwersację, a model, który bryluje w turze pierwszej, może zgubić się do piątej.

Czym jest ewaluacja wieloturowa LLM? Dwa tryby oceny

Ewaluacja wieloturowa LLM to praktyka oceniania całej konwersacji albo okien w jej wnętrzu, zamiast izolowanych par prompt-odpowiedź. Sprawdza, czy model utrzymał kontekst, pozostał w roli i rozwiązał problem użytkownika na przestrzeni tur. Pracę wykonują dwa tryby: ocena na poziomie konwersacji i ocena na poziomie tur w oknie przesuwnym, a większość zespołów stosuje oba.

Ocena na poziomie konwersacji przekazuje sędziemu pełny zapis i zadaje jedno pytanie: czy ta konwersacja zakończyła się sukcesem? Łapie przedwczesne zamknięcia i nierozwiązane pętle, bo tylko cały wątek ujawnia, że użytkownik nigdy nie dostał zwrotu. Jej słabością jest granulacja: „nie powiodło się" dla 12-turowego wątku nie mówi, gdzie coś się zepsuło.

Ocena na poziomie tur w oknie przesuwnym przesuwa okno N tur po zapisie, jeden werdykt na okno. Okno o szerokości 3 dla 10-turowej konwersacji daje 8 werdyktów przypisanych do regionów rozmowy, więc „nie powiodło się" ma współrzędne: awaria nastąpiła w turach 6-8. Diagram na górze tego wpisu pokazuje oba tryby na jednym wątku: klamra dla werdyktu konwersacji, przesuwająca się ramka dla werdyktów okien.

Używaj oceny na poziomie konwersacji jako bramki, a oceny okienkowej do lokalizowania błędów, gdy bramka zawiedzie. Przewodnik po ewaluacji wieloturowej DeepEval definiuje jednostkę pracy jako scenariusz, a nie parę wejście-wyjście (jego typ ConversationalGolden): testujesz sytuację, nie pytanie.

Przykład ilustracyjny (syntetyczny; pokazuje mechanikę, nie rzeczywisty przebieg): okno przesuwne o szerokości 3 na 8-turowej rozmowie o zwrocie towaru.

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?

Werdykt na poziomie konwersacji: niezaliczone. Pięć z sześciu okien przeszło, a wątek i tak złamał się na retencji wiedzy, dokładnie ten typ błędu, którego zestaw jednoturowy nigdy nie pokaże.

Które metryki wieloturowe mają znaczenie? Te pięć

Uruchom najpierw cztery metryki: kompletność konwersacji, retencję wiedzy, zgodność z rolą i trafność tur. Dodaj piątą, kryterium własne (G-Eval w DeepEval, AspectCritic w RAGAS), na to, czego Twój produkt nie może zepsuć. Pierwsze cztery przechodzą między projektami; piąta to miejsce, gdzie żyją Twoje tryby awarii.

1. Kompletność konwersacji. Czy cel użytkownika został osiągnięty, czy bot ogłosił zwycięstwo za wcześnie? Twój detektor przedwczesnego zamknięcia.
2. Retencja wiedzy. Czy model pamięta fakty podane wcześniej w wątku? Błąd amnezji z 8. tury to właśnie awaria retencji wiedzy.
3. Zgodność z rolą. Czy asystent trzyma się swojej persony i odmawia próśb spoza zakresu? Kluczowe przy granicy compliance.
4. Trafność tur. Czy każda odpowiedź jest na temat w świetle poprzednich tur? Łapie dryf i zapętlenia.
5. Kryterium własne. Jedna zasada w prostym języku dla Twojej domeny: „nigdy nie podawaj ceny innej niż w cenniku". DeepEval implementuje to jako ConversationalGEval; RAGAS jako AspectCritic.

Przewodnik po metrykach DeepEval definiuje każdą z nich jako uruchamialną klasę, ale pojęcia są niezależne od frameworka: tabela obowiązuje, nawet jeśli sędziego piszesz sam.

Kryterium własne czyta się jak zdanie:

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

Ta sama zasada jako prawdziwy kod 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: który framework wybrać?

Wszystkie trzy oceniają konwersacje wieloturowe, ale różnią się jednostką ewaluacji: DeepEval symuluje scenariusze offline, RAGAS punktuje aspekty konwersacji, które już masz, a Langfuse ocenia rzeczywiste ślady produkcyjne. Wybieraj według tego, skąd pochodzą Twoje konwersacje, a nie liczby funkcji.

Najpierw logika niezależna od frameworka, żeby kod dostawcy poniżej był przenośny:

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: scenariusze i kompletny symulator

DeepEval jako jedyny ma pełnoprawny symulator konwersacji: opisujesz scenariusz i personę, a on gra użytkownika przeciwko Twojemu botowi. Jego przewodnik wieloturowy to kanoniczne źródło wzorca „scenariusz, nie pary". Confident AI sprzedaje hostowany dashboard; nasza recenzja Confident AI opisuje, co dodaje płatna warstwa.

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: analiza błędów, aspekt po aspekcie

RAGAS wychodzi od konwersacji, które już masz, i punktuje je aspekt po aspekcie. Jego instrukcja wieloturowa łączy się z ręczną analizą błędów: czytasz nieudane rozmowy, piszesz AspectCritic na każdy tryb awarii, punktujesz.

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: ewaluacja N+1 na rzeczywistych śladach

Langfuse idzie odwrotną drogą: najpierw tracer. Jego cookbook N+1 ocenia ślad każdej tury plus całą konwersację, na ruchu produkcyjnym zamiast symulacji. Jeśli wciąż wybierasz warstwę obserwowalności, nasze porównanie Langfuse vs LangSmith omawia tę decyzję.

Nasz werdykt, bez asekuracji: przy nowym projekcie chatbota zacznij od DeepEval. Symulator pozwala blokować regresje, zanim masz ruch produkcyjny, czyli wtedy, gdy testy są najbardziej potrzebne. Dodaj Langfuse, gdy istnieją już prawdziwe wątki; sięgnij po RAGAS, gdy Twój zespół woli czytać nieudane konwersacje i kodyfikować to, co w nich znajdzie.

Jak przejść od analizy błędów do automatyzacji?

Układasz to w sekwencję. Przeczytaj 20-30 prawdziwych konwersacji, ręcznie oznacz tryby awarii, napisz binarne testy zaliczone/niezaliczone dla oczywistych przypadków, zautomatyzuj je, i dopiero potem dodaj metryki sędziowane przez LLM dla subiektywnej reszty. Hamel Husain argumentuje dokładnie za tą kolejnością: najpierw ręczna analiza błędów i decyzje binarne, bo test, który umiesz wyjaśnić, bije wynik, którego nie umiesz.

Najpierw binarnie, potem sędzia: kolejność, która nas uratowała

To nie jest benchmark chatbotów, który przeprowadziliśmy; to nasza interpretacja tego samego wzorca wewnątrz naszej własnej pipeline treści, która uruchamia bramkowane ewaluacją testy regresji przy każdej zmianie promptu i narzędzi. Dwa incydenty potwierdziły nam tę kolejność.

13 czerwca 2026 błąd republikacji wybił nowe zlokalizowane slugi i wypuścił 54 zduplikowane dokumenty na produkcji. Znaleźliśmy je i wycofaliśmy 5 lipca 2026 (kopia zapasowa w techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json). Poprawką nie był mądrzejszy model; był deterministyczny test przed publikacją: rozwiąż istniejący dokument po kanonicznym wpisie i języku przed jakimkolwiek tworzeniem. Bramka binarna.

Drugi incydent: LLM-y tłumaczące czasami emitują ASCII zamiast Unicode, zamieniając „karşılaştırma" na „karsilastirma". Żaden sędzia niepotrzebny; łapie to bramka grep:

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

Oba złapały testy, które kosztują ułamki centa i drukują dokładnie, dlaczego zawiodły. Przenieś to na ewaluacje wieloturowe: „czy bot ponownie zapytał o pole, które użytkownik już podał?" to dopasowanie łańcucha do transkrypcji, nie wywołanie sędziego. Uruchamiaj najpierw tanie, deterministyczne bramki; łapią brzydkie awarie, zanim Twój drogi sędzia w ogóle wystartuje.

Kiedy sędzia LLM jest właściwym narzędziem

Sędziowie zarabiają na swoje tokeny przy kryteriach, których nie da się sprowadzić do reguły: „czy ton był odpowiednio przepraszający?", „czy rozwiązanie pasowało do sytuacji?". Jeśli umiesz napisać asercję, napisz asercję. Rubryka pełna osądów to terytorium sędziego.

Granica, do której ciągle wracamy:

Zacznij od binarnych testów zaliczone/niezaliczone, które umiesz wyjaśnić koledze z zespołu, a sędziów LLM dodaj tylko do tego, czego nie da się sprowadzić do reguły.

Jak symulować konwersacje na dużą skalę i ile kosztuje sędziowanie?

Symuluj ze scenariuszy, nie z wyeksportowanych logów. Scenariusze testują, co może się zdarzyć; logi pokazują tylko to, na co Twój obecny system już pozwolił. Wytyczne DeepEval ostrzegają, że historyczne konwersacje ukształtował system, który je wygenerował, więc benchmarkowanie względem nich betonuje status quo.

Scenariusze, nie transkrypcje

Pisz każdy scenariusz jako cel plus persona: „niecierpliwy klient zwracający uszkodzone zamówienie", „użytkownik, który zmienia zdanie w trakcie rezerwacji". Ustaw limit tur (10 to rozsądna wartość) i warunek stopu: cel osiągnięty, użytkownik rezygnuje albo limit. DeepEval zaleca co najmniej 20 zróżnicowanych scenariuszy obejmujących główne przypadki użycia, przypadki brzegowe i sytuacje awariogenne; poniżej tego Twój zestaw mierzy anegdoty.

Adwersaryjne persony

Dołącz persony, które próbują zepsuć bota: zdenerwowany użytkownik, który eskaluje, zdezorientowany użytkownik, który sam sobie przeczy, użytkownik iniekcyjny, który przemyca instrukcje w turze 4. Iniekcja wieloturowa to osobna dyscyplina; nasz przewodnik po barierach ochronnych LLM omawia warstwę defensywną, która łączy się z tymi testami, a cookbook symulacji Langfuse pokazuje pętlę symulatora użytkownika.

Ile kosztuje ewaluacja 100 konwersacji

Każda liczba poniżej to szacunek z podanych liczb tokenów i publicznych cenników, nie pomiar, który wykonaliśmy. Chodzi o arytmetykę: podstaw własne liczby.

Mniej niż dolar za 100 w pełni osądzonych konwersacji. Droższy sędzia przesuwa to 10-50 razy, a taktyki z naszego przewodnika po redukcji kosztów API LLM działają: buforuj tekst kryteriów, grupuj okna, używaj taniego modelu do bramek binarnych.

6-etapowy workflow ewaluacji wieloturowej

Pętla działa tak: zdefiniuj scenariusze z prawdziwych awarii, wybierz cztery metryki rdzeniowe plus jedną własną, symuluj co najmniej 20 scenariuszy, ustal bazę dla bieżącej wersji, bramkuj regresje w CI i zasilaj zbiór scenariuszy awariami z produkcji.

1. Zdefiniuj scenariusze z awarii. Przeczytaj 20-30 transkrypcji (albo, przed startem, napisz je z ticketów wsparcia). Każdy scenariusz dostaje cel, personę i limit tur. Właściciel: Ty i metoda „najpierw analiza błędów" Hamela.
2. Wybierz cztery metryki, jedną własną. Kompletność, retencja wiedzy, zgodność z rolą, trafność tur i jedno ConversationalGEval lub AspectCritic na kosztowny błąd Twojej domeny.
3. Symuluj. Uruchom co najmniej 20 scenariuszy, w tym zestaw adwersaryjny. Właściciel: ConversationSimulator DeepEval albo cookbook symulacji Langfuse.
4. Ustal bazę dla bieżącej wersji. Zapisz średnie na metrykę z 3 przebiegów, bo modele są niedeterministyczne i pojedynczy przebieg to szum. Właściciel: Twój skrypt ewaluacyjny, wyniki commitowane do repo.
5. Bramkuj regresje w CI. Ustaw próg na metrykę i wywal build przy regresji poza tolerancję:

# 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. Monitoruj wątki produkcyjne. Grupuj żywe ślady po wątku, oceniaj asynchronicznie i zamieniaj każdy niepomyślny wątek w nowy scenariusz. Właściciel: Langfuse lub Twój tracer; nasze przewodniki po ewaluacji agentów AI na produkcji i obserwowalności AI omawiają połowę monitoringową.

Zestaw nigdy nie jest skończony: krok 6 zasila krok 1, a zbiór scenariuszy rośnie z każdą złapaną awarią produkcyjną.

Jak oceniać ton w różnych językach?

Metryka zgodności z rolą dostrojona na angielskich danych przepuści transkrypcję turecką lub japońską, którą native speaker uzna za niegrzeczną, bo rejestr grzecznościowy jest specyficzny dla języka. Twoja angielska rubryka nie ma na to słów. Poprawka: jedno kryterium aspektowe na oczekiwanie rejestru, napisane dla każdego języka, a nie jedna globalna metryka tonu.

Jedno kryterium na rejestr

Nasza interpretacja wzorca AspectCritic RAGAS, rozszerzona z prowadzenia pipeline w 23 językach, nie opublikowany wynik 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żde kryterium to osobny binarny krytyk na tej samej transkrypcji. Nie opublikowaliśmy międzyjęzykowych wyników tonu i nie zaufalibyśmy artykułowi, który drukuje je bez rubryki. Z pracy nad pipeline: awarie grupują się w turach przeprosin i eskalacji, gdzie rejestr załamuje się pierwszy.

O autorze

Mert Batur jest współzałożycielem Techsy.io, gdzie zespół dostarcza agentów AI, systemy automatyzacji i pipeline głosowe/SDR dla klientów B2B. Pisze o stosie narzędzi LLM, którego zespół Techsy faktycznie używa na produkcji. Kwalifikacje: współzałożyciel Techsy.io. Połącz się na LinkedIn.

Najczęściej zadawane pytania

Czym jest wieloturowy LLM konwersacyjny?

To model językowy, którego n-ta odpowiedź zależy od wszystkich wcześniejszych tur, nie tylko od ostatniego promptu. Warunkuje się na całym wątku, więc zachowanie zmienia się wraz z historią konwersacji. Ta zależność od kontekstu to coś, czego testy jednoturowe nie potrafią sprawdzić, a ewaluacja wieloturowa istnieje po to, by to punktować.

Co oznacza ewaluacja LLM?

Mierzenie jakości wyników względem zdefiniowanych kryteriów, automatycznie i powtarzalnie, zamiast na wyczucie. Ewaluacja jednoturowa punktuje izolowane pary prompt-odpowiedź względem metryk takich jak BLEU czy sędzia LLM. Ewaluacja wieloturowa rozszerza to na całe konwersacje, punktując retencję kontekstu i osiągnięcie celu na przestrzeni tur, a nie na prompt.

Jak benchmarkować wydajność wieloturową LLM?

Zbuduj co najmniej 20 scenariuszy z celami i personami, symuluj je przeciw modelowi i punktuj metrykami na poziomie konwersacji plus testami okna przesuwnego. Zapisuj bazy z wielu przebiegów, żeby wchłonąć niedeterminizm, a potem porównuj każdą nową wersję z bazą w CI. Ślady produkcyjne rozszerzają benchmark później.

Jakie są najlepsze sposoby ewaluacji LLM?

Ułóż to w sekwencję: najpierw ręczna analiza błędów, potem binarne bramki zaliczone/niezaliczone dla wszystkiego, co da się sprowadzić do reguły, a potem LLM-jako-sędzia dla kryteriów subiektywnych, jak ton i jakość rozwiązania. Testy binarne są tańsze, debugowalne i nie dryfują; sędziowie należą się kryteriom, które naprawdę wymagają osądu, po przejściu tanich bramek.

Od których metryk ewaluacji wieloturowej zacząć?

Kompletność konwersacji, trafność tur i retencja wiedzy; łapią najczęstsze awarie (nierozwiązane cele, dryf, zapominanie) w każdym produkcie czatowym. Dodaj zgodność z rolą, jeśli Twój bot ma granicę compliance, a potem jedno kryterium własne G-Eval lub AspectCritic na błąd, na który Twojego biznesu nie stać.

Ile kosztuje LLM-jako-sędzia na konwersację?

Przy oknie przesuwnym o szerokości 5 na 10 tur plus jednym wywołaniu na poziomie konwersacji wykonujesz 7 wywołań sędziego na konwersację. Przy około 2000 tokenów wejściowych na wywołanie na GPT-4o-mini, nasz szacunek z pokazaną arytmetyką wychodzi około 0,29 USD za 100 konwersacji. Modele sędziujące premium podnoszą to 10-50 razy.

DeepEval czy RAGAS do ewaluacji wieloturowej: co wybrać?

DeepEval, jeśli chcesz testy regresji offline z wbudowanym symulatorem konwersacji, zwłaszcza zanim masz ruch produkcyjny. RAGAS, jeśli Twój workflow zaczyna się od czytania prawdziwych nieudanych konwersacji i kodyfikowania każdego trybu awarii jako AspectCritic. Częsty podział: DeepEval w CI, krytycy w stylu RAGAS na logach produkcyjnych.

Ile scenariuszy potrzebuje zestaw testów wieloturowych?

Co najmniej 20, obejmujących główne przypadki użycia, przypadki brzegowe i sytuacje awariogenne; ten próg pochodzi z opublikowanych wytycznych DeepEval i zgadza się z naszym doświadczeniem. Poniżej 20 odsetek zaliczeń faluje w zależności od tego, które scenariusze akurat trafiły do zestawu. Powiększaj zbiór z każdą awarią produkcyjną.

Czy można uruchamiać ewaluację wieloturową w CI/CD?

Tak. Trzymaj stały zbiór scenariuszy w repo, uruchamiaj go przy każdej zmianie promptu lub modelu i wywalaj build, gdy metryka zregreduje poza tolerancję względem bazy. Ponieważ modele są niedeterministyczne, porównuj średnie z 3 przebiegów z tolerancją (my używamy 0,03), nie dokładne progi.

Jak ewaluować konwersacje wieloturowe na produkcji?

Grupuj ślady po wątku konwersacji, punktuj każdy wątek asynchronicznie, żeby ewaluacja nigdy nie blokowała odpowiedzi, i kieruj niepomyślne wątki do kolejki przeglądu. Każda potwierdzona awaria staje się nowym scenariuszem w Twoim zestawie offline, domykając pętlę między monitoringiem a testami regresji.

W skrócie

• Wyniki jednoturowe nie widzą błędów konwersacji; badania pokazują degradację modeli na przestrzeni tur mimo zdrowych benchmarków.
• Stosuj ocenę na poziomie konwersacji jako bramkę, a ocenę okna przesuwnego do lokalizowania awarii.
• Cztery metryki rdzeniowe plus jedno kryterium własne pokrywają większość produktów czatowych; najpierw testy binarne, potem sędziowie, zawsze.
• DeepEval do symulowanych testów regresji, RAGAS do krytyków napędzanych analizą błędów, Langfuse do śladów produkcyjnych.
• Koszty sędziowania są małe (mniej niż dolar za 100 konwersacji na modelu mini); koszt rzadko jest blokadą.

Po szerszy obraz narzędzi: uszeregowaliśmy całą stawkę w naszym zestawieniu najlepszych narzędzi ewaluacji LLM. A jeśli wolisz budować pipeline ewaluacyjną z kimś, umów bezpłatną konsultację z zespołem Techsy.