Багатотурнове оцінювання LLM: 5 метрик, 3 фреймворки, 1 робочий процес

Багатотурнове оцінювання LLM: 5 метрик, 3 фреймворки, 1 робочий процес

Багатотурнове оцінювання LLM це єдиний спосіб спіймати баг амнезії на 8-му турні: користувач назвав номер замовлення на 3-му турні, а бот питає його знову. Кожен окремий турн пройдено ізольовано, але діалог усе одно провалено. DeepEval 4.0 і RAGAS 0.4 випустили спеціальні API для оцінювання діалогів саме під це, і після двох інцидентів з оцінюванням у нашому власному конвеєрі в Techsy ось п'ять метрик, три фреймворки та один робочий процес для старту.

Ключові висновки

• Багатотурнове оцінювання виставляє бали цілим діалогам, а не ізольованим парам «ввід-вивід».
• Моделі, що лідирують в однотурнових бенчмарках, помітно деградують упродовж турнів діалогу.
• Почніть із чотирьох метрик: повнота, утримання знань, дотримання ролі, релевантність турну.
• DeepEval, RAGAS і Langfuse розв'язують багатотурнове оцінювання по-різному; таблиця фреймворків нижче порівнює їх.

Чому однотурнові бали брешуть вам?

Однотурнове оцінювання виставляє бал одній парі «ввід-вивід» за раз, тому воно не бачить збоїв, що виникають лише між турнями: забування, суперечності, дрейф. Модель може мати сильний бал у бенчмарку й водночас втрачати нитку живого діалогу. Laban et al. документують це у LLMs Get Lost In Multi-Turn Conversation, 353 цитування: продуктивність падає в багатотурнових сценаріях, навіть коли однотурнові результати виглядають здоровими.

Коренева проблема це недетермінізм: n-на відповідь залежить від усіх попередніх n-1 турнів, тож ідентичні промпти поводяться по-різному залежно від історії. Датасет із ізольованих пар ніколи не перевіряє цю залежність. Огляд arXiv Evaluating LLM-based Agents for Multi-Turn Conversations, PRISMA-огляд приблизно 250 джерел, ділить цю галузь на «що оцінювати» (управління контекстом, планування, узгодженість) і «як» (метрики, LLM-судді, людська перевірка). Обидва виміри відсутні в однотурновому наборі тестів.

Нічого з цього не робить ваш однотурновий стек даремним. Якщо ви використовуєте однотурнові метрики на кшталт BLEU, ROUGE і G-Eval, тримайте їх для того, що вони добре вимірюють: дотримання формату, токсичність, фактологічне відтворення на фіксованому промпті. Просто перестаньте читати їх як перевірку здоров'я діалогу, з яким взаємодіють ваші користувачі.

Наша інтерпретація цих досліджень в одному рядку:

Однотурнове оцінювання вимірює відповідь, багатотурнове оцінювання вимірює діалог, і модель, що блискуче проходить перший турн, може загубитися до п'ятого.

Що таке багатотурнове оцінювання LLM? Два режими оцінювання

Багатотурнове оцінювання LLM це практика виставлення балів цілому діалогу або вікнам у ньому, а не ізольованим парам «промпт-відповідь». Воно питає, чи зберегла модель контекст, чи залишилася в ролі та чи розв'язала проблему користувача впродовж турнів. Роботу виконують два режими: оцінювання на рівні діалогу та по-турнове оцінювання ковзним вікном, і більшість команд використовують обидва.

Оцінювання на рівні діалогу передає судді повний транскрипт і ставить одне питання: чи був цей діалог успішним? Воно ловить передчасне завершення та нерозв'язані цикли, оскільки лише ціла нитка показує, що користувач так і не отримав повернення. Його слабкість це гранулярність: «провалено» на нитці з 12 турнів не каже, де саме все зламалося.

По-турнове оцінювання ковзним вікном рухає вікно з N турнів уздовж транскрипту, один вердикт на вікно. Вікно з 3 на діалозі з 10 турнів дає 8 вердиктів, прив'язаних до ділянок чату, тож «провалено» має координати: злам стався на турнях 6-8. Діаграма на початку цієї статті показує обидва режими на одній нитці: дужка для вердикту діалогу, ковзна рамка для вердиктів по вікнах.

Використовуйте оцінювання на рівні діалогу як гейт, а віконне оцінювання для локалізації збоїв, коли гейт спрацював. Гід DeepEval з багатотурнового оцінювання окреслює одиницю роботи як сценарій, а не пару «ввід-вивід» (його тип ConversationalGolden): ви тестуєте ситуацію, а не питання.

Ілюстративний приклад (синтетичний; показує механіку, а не реальний прогін): ковзне вікно з 3 на чаті повернення товару з 8 турнів.

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?

Вердикт на рівні діалогу: провалено. П'ять із шести вікон пройдено, а нитка все одно зламалася на утриманні знань, саме той збій, який однотурновий набір ніколи не виявить.

Які метрики багатотурнового оцінювання важливі? 5, що мають значення

Спочатку запустіть чотири метрики: повноту діалогу, утримання знань, дотримання ролі та релевантність турну. Додайте п'яту, власний критерій (G-Eval у DeepEval, AspectCritic у RAGAS), для того, що ваш продукт не може зробити неправильно. Перші чотири переносяться між проєктами; п'ята там, де живуть ваші режими збоїв.

1. Повнота діалогу. Чи розв'язано ціль користувача, чи бот зарано оголосив перемогу? Ваш детектор передчасного завершення.
2. Утримання знань. Чи пам'ятає модель факти, названі раніше в нитці? Баг амнезії на 8-му турні це збій утримання знань.
3. Дотримання ролі. Чи лишається асистент у своїй персоні та відмовляє запиту поза межами? Критично за наявності комплаєнс-межі.
4. Релевантність турну. Чи кожна відповідь у темі з огляду на попередні турні? Ловить дрейф і цикли.
5. Власний критерій. Одне правило простою мовою для вашої сфери: «ніколи не називай ціну, що відрізняється від прайс-листа». DeepEval реалізує це як ConversationalGEval; RAGAS як AspectCritic.

Гід з метрик DeepEval визначає кожну з них робочими класами, але концепції не залежать від фреймворку: таблиця справджується, навіть якщо ви напишете суддю вручну.

Власний критерій читається як речення:

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

Те саме правило як реальний код 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 проти RAGAS проти Langfuse: який фреймворк пасує?

Усі три оцінюють багатотурнові діалоги, але їхня одиниця оцінювання різна: DeepEval симулює сценарії офлайн, RAGAS виставляє бали аспектам діалогів, які у вас уже є, а Langfuse оцінює реальні продакшн-трейси. Обирайте за тим, звідки беруться ваші діалоги, а не за кількістю функцій.

Спершу логіка без прив'язки до фреймворку, тож код вендора нижче переноситься:

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: сценарії та симулятор «з батарейками в комплекті»

DeepEval єдиний має першокласний симулятор діалогу: опишіть сценарій і персону, і він грає користувача проти вашого бота. Його багатотурновий гід це канонічне джерело для патерну «сценарій, а не пари». Confident AI продає гостований дашборд; наш огляд Confident AI розбирає, що додає платний шар.

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: на основі аналізу помилок, аспект за аспектом

RAGAS починає з діалогів, які у вас вже є, і виставляє їм бали аспект за аспектом. Його багатотурновий how-to поєднується з ручним аналізом помилок: прочитайте провальні чати, напишіть AspectCritic на кожен режим збоїв, виставте бали.

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 на реальних трейсах

Langfuse йде протилежним шляхом: спершу трейсер. Його N+1 cookbook оцінює трейс кожного турну плюс діалог загалом, на продакшн-трафіку, а не симуляціях. Якщо ви ще обираєте шар спостережності, наше порівняння Langfuse проти LangSmith розбирає це рішення.

Наш вердикт, без хитань: для нового проєкту чатбота почніть із DeepEval. Симулятор дає змогу блокувати регресії до того, як у вас з'явиться продакшн-трафік, коли тести потрібні найбільше. Додайте Langfuse, коли існують реальні нитки; беріться за RAGAS, коли ваша команда надає перевагу читанню провальних діалогів і кодуванню того, що вони знаходять.

Як перейти від аналізу помилок до автоматизації?

Ви будуєте послідовність. Прочитайте 20-30 реальних діалогів, розмітьте режими збоїв вручну, напишіть бінарні перевірки пройдено/провалено для очевидних, автоматизуйте їх, і лише потім додайте LLM-суддів для суб'єктивного залишку. Hamel Husain обстоює саме такий порядок: спершу ручний аналіз помилок і бінарні рішення, бо перевірка, яку ви можете пояснити, б'є бал, якого ви не можете пояснити.

Бінарне перед суддею: послідовність, що нас врятувала

Це не бенчмарк чатботів, який ми прогнали; це наша інтерпретація того самого патерну всередині нашого власного контент-конвеєра, що запускає евал-гейтовані регресійні перевірки на кожній зміні промпту й інструментів. Два інциденти довели цю послідовність для нас.

13 червня 2026 року баг републікації накарбував нові локалізовані слаги й відправив 54 дублікатні живі документи. Ми знайшли й зняли їх з публікації 5 липня 2026 року (резервна копія в techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json). Виправленням була не розумніша модель; це була детермінована перевірка перед публікацією: розв'язати наявний документ за канонічним постом і мовою перед будь-яким створенням. Бінарний гейт.

Другий інцидент: LLM-перекладачі часом видають ASCII замість Unicode, перетворюючи «karşılaştırma» на «karsilastirma». Суддя не потрібен; grep-гейт ловить це:

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

Обидва спіймали перевірки, що коштують частки цента й друкують точно, чому вони провалилися. Перенесіть це на багатотурнове оцінювання: «чи бот знову спитав поле, яке користувач уже назвав?» це збіг рядків у транскрипті, а не виклик судді. Спершу запускайте дешеві детерміновані гейти; вони ловлять найнеприємніші збої до того, як ваш дорогий суддя взагалі запуститься.

Коли LLM-суддя насправді правильний інструмент

Судді виправдовують свою вартість у токенах на критеріях, які не зводяться до правила: «чи був тон доречно вибачливим?», «чи відповідало розв'язання ситуації?». Якщо можете написати твердження, напишіть твердження. Рубрика, повна суджень, це територія судді.

Межа, до якої ми повертаємося:

Почніть із бінарних перевірок пройдено/провалено, які ви можете пояснити колезі, потім додайте LLM-суддів лише для того, що не зводиться до правила.

Як симулювати діалоги масштабно й скільки коштує суддівство?

Симулюйте зі сценаріїв, а не з експортованих логів. Сценарії тестують, що може статися; логи лише показують, що ваша поточна система вже дозволила. Поради DeepEval застерігають, що історичні діалоги сформовані системою, що їх породила, тож бенчмаркінг проти них зацементовує статус-кво.

Сценарії, а не транскрипти

Пишіть кожен сценарій як ціль плюс персона: «нетерплячий клієнт повертає пошкоджене замовлення», «користувач, що передумує посеред бронювання». Встановіть ліміт турнів (10 розумно) й умову зупинки: ціль досягнуто, користувач покидає, або ліміт. DeepEval радить щонайменше 20 різноманітних сценаріїв у основних кейсах, крайніх випадках і вразливих до збоїв ситуаціях; нижче цього ваш набір вимірює анекдоти.

Адверсарні персони

Включіть персон, що намагаються зламати бота: злий користувач, що ескалує, розгублений користувач, що суперечить собі, ін'єкційний користувач, що підкидає інструкції на 4-му турні. Багатотурнова ін'єкція це окрема дисципліна; наш гід з гардрейлів LLM розбирає оборонний шар, що поєднується з цими тестами, а симуляційний cookbook Langfuse показує цикл симулятора користувача.

Скільки коштують 100 оцінених діалогів

Кожна цифра нижче це оцінка з заявленої кількості токенів і публічних цін, а не вимір, який ми прогнали. Арифметика й є сенсом: підставте власні числа.

Менше долара за 100 повністю оцінених діалогів. Дорожчий суддя зсуває це в 10-50 разів, і тактики з нашого гіда зі скорочення витрат на LLM API застосовні: кешуйте текст критеріїв, пакетуйте вікна, використовуйте дешеву модель для бінарних гейтів.

6-кроковий робочий процес багатотурнового оцінювання

Цикл працює так: визначте сценарії з реальних збоїв, оберіть чотири основні метрики плюс одну власну, симулюйте щонайменше 20 сценаріїв, встановіть базовий рівень для поточної версії, заблокуйте регресії в CI й подавайте продакшн-збої назад у набір сценаріїв.

1. Визначте сценарії зі збоїв. Прочитайте 20-30 транскриптів (або, до запуску, напишіть їх із тікетів підтримки). Кожен сценарій отримує ціль, персону та ліміт турнів. Відповідальний: ви та метод Hamel «аналіз помилок спершу».
2. Оберіть чотири метрики, одну власну. Повнота, утримання знань, дотримання ролі, релевантність турну та один ConversationalGEval або AspectCritic для дорогої помилки вашої сфери.
3. Симулюйте. Прогоніть щонайменше 20 сценаріїв, включно з адверсарним набором. Відповідальний: ConversationSimulator DeepEval або симуляційний cookbook Langfuse.
4. Встановіть базовий рівень поточної версії. Запишіть середні за метриками за 3 прогони, бо моделі недетерміновані й один прогін це шум. Відповідальний: ваш евал-скрипт, результати закомічені в репо.
5. Заблокуйте регресії в CI. Встановіть поріг на метрику й валіть збірку на регресії понад допуск:

# 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. Моніторте продакшн-нитки. Групуйте живі трейси за ниткою, оцінюйте асинхронно й перетворюйте кожну провальну нитку на новий сценарій. Відповідальний: Langfuse або ваш трейсер; наші гіди з оцінювання AI-агентів у продакшні та AI-спостережності розбирають половину моніторингу.

Набір ніколи не завершено: крок 6 живить крок 1, і набір сценаріїв росте з кожним продакшн-збоєм, який ви ловите.

Як оцінювати тон різними мовами?

Метрика дотримання ролі, налаштована на англійських даних, пропустить турецький чи японський транскрипт, який носій мови вважає грубим, бо регістр ввічливості специфічний для мови. Ваша англійська рубрика не має для цього слів. Виправлення: один критерій аспекту на кожне очікування регістру, написаний для кожної мови, а не одна глобальна метрика тону.

Один критерій на регістр

Наша інтерпретація патерну AspectCritic RAGAS, розширена з запуску конвеєра на 23 мови, а не опублікований результат тесту:

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

Кожен критерій це окремий бінарний критик на тому самому транскрипті. Ми не публікували міжмовних балів тону й не довіряли б статті, що друкує їх без рубрики. З роботи конвеєра: збої скупчуються на турнях вибачення та ескалації, де регістр сиплеться першим.

Про автора

Mert Batur співзасновник Techsy.io, де команда відправляє AI-агентів, системи автоматизації та голосові/SDR-конвеєри для B2B-клієнтів. Він пише про стек інструментів LLM, який команда Techsy реально використовує в продакшні. Кваліфікація: співзасновник Techsy.io. Контакти в LinkedIn.

Часті запитання

Що таке багатотурнова LLM-розмова?

Мовна модель, чия n-на відповідь залежить від усіх попередніх турнів, а не лише від останнього промпту. Вона спирається на всю нитку, тож поведінка змінюється з історією діалогу. Ця залежність від контексту саме те, що однотурнові тести не можуть перевірити й що багатотурнове оцінювання існує, щоб вимірювати.

Що означає оцінювання LLM?

Вимірювання якості виводу проти визначених критеріїв, автоматично й повторювано, а не на відчуття. Однотурнове оцінювання виставляє бали ізольованим парам «промпт-відповідь» проти метрик на кшталт BLEU або LLM-судді. Багатотурнове оцінювання розширює це на цілі діалоги, виставляючи бали утриманню контексту й досягненню цілі між турнями, а не на окремий промпт.

Як бенчмаркати багатотурнову продуктивність LLM?

Побудуйте щонайменше 20 сценаріїв із цілями й персонами, симулюйте їх проти моделі та виставте бали метриками на рівні діалогу плюс перевірками ковзним вікном. Запишіть базові рівні за кілька прогонів, щоб поглинути недетермінізм, потім порівнюйте кожну нову версію з базовим рівнем у CI. Продакшн-трейси розширюють бенчмарк пізніше.

Які найкращі способи оцінювати LLM?

Будуйте послідовність: спершу ручний аналіз помилок, потім бінарні гейти пройдено/провалено для всього, що зводиться до правила, потім LLM-як-суддя для суб'єктивних критеріїв на кшталт тону й якості розв'язання. Бінарні перевірки дешевші, налагоджувані й не дрейфують; судді належать критеріям, що справді потребують судження, після того як дешеві гейти пройдено.

З яких метрик багатотурнового оцінювання почати?

Повнота діалогу, релевантність турну та утримання знань; вони ловлять найпоширеніші збої (нерозв'язані цілі, дрейф, забування) у будь-якому чат-продукті. Додайте дотримання ролі, якщо ваш бот має комплаєнс-межу, потім один власний критерій G-Eval або AspectCritic для помилки, яку ваш бізнес не може дозволити.

Скільки коштує LLM-як-суддя на діалог?

З ковзним вікном з 5 на 10 турнях плюс один виклик на рівні діалогу ви робите 7 викликів судді на діалог. За приблизно 2 000 ввідних токенів на виклик на GPT-4o-mini наша оцінка з арифметикою виходить приблизно $0,29 на 100 діалогів. Преміальні моделі судді піднімають це в 10-50 разів.

DeepEval проти RAGAS для багатотурнового оцінювання: що обрати?

DeepEval, якщо хочете офлайн-регресійні тести з вбудованим симулятором діалогу, особливо до того, як у вас з'явиться продакшн-трафік. RAGAS, якщо ваш робочий процес починається з читання реальних провальних діалогів і кодування кожного режиму збоїв як AspectCritic. Один поширений поділ: DeepEval у CI, критики в стилі RAGAS на продакшн-логах.

Скільки сценаріїв потрібно для набору багатотурнового оцінювання?

Щонайменше 20, що покривають основні кейси, крайні випадки та вразливі до збоїв ситуації; цей поріг із опублікованих порад DeepEval і збігається з нашим досвідом. Нижче 20 відсотки проходження хитаються залежно від того, які сценарії випадково включено. Зрощуйте набір із кожним продакшн-збоєм.

Чи можна запускати багатотурнове оцінювання в CI/CD?

Так. Тримайте фіксований набір сценаріїв у репо, проганяйте його на кожній зміні промпту чи моделі й валіть збірку, коли метрика регресує понад допуск відносно базового рівня. Бо моделі недетерміновані, порівнюйте середні за 3 прогони з допуском (ми використовуємо 0,03), а не точні пороги.

Як оцінювати багатотурнові діалоги в продакшні?

Групуйте трейси за ниткою діалогу, виставляйте бали кожній нитці асинхронно, щоб оцінювання ніколи не блокувало відповідь, і скеровуйте провальні нитки в чергу перевірки. Кожен підтверджений збій стає новим сценарієм у вашому офлайн-наборі, замикаючи цикл між моніторингом і регресійними тестами.

Коротка версія

• Однотурнові бали не бачать збоїв діалогу; дослідження показують, що моделі деградують упродовж турнів попри здорові бенчмарки.
• Запустіть оцінювання на рівні діалогу як гейт і оцінювання ковзним вікном для локалізації зламів.
• Чотири основні метрики плюс один власний критерій покривають більшість чат-продуктів; бінарні перевірки перед суддями, завжди.
• DeepEval для симульованих регресійних тестів, RAGAS для критиків на основі аналізу помилок, Langfuse для продакшн-трейсів.
• Витрати на суддю малі (менше долара на 100 діалогів на міні-моделі); вартість рідко є блокувальником.

Для ширшого ландшафту інструментів ми ранжували всю галузь у нашому огляді найкращих інструментів оцінювання LLM. І якщо ви волієте будувати евал-конвеєр із кимось, отримайте безплатну консультацію з командою Techsy.