Как тестировать LLM-чатбота: кейсы, диалоги, golden set, покрытие и версионирование

Соберите golden set из реальных вопросов и разбейте его на корзины (типовые, пограничные, вне области, adversarial, регрессии). Для многоходовых диалогов опишите сценарий: реплики пользователя и ожидаемое поведение бота на каждом шаге. Оценивайте шаги LLM-судьёй по рубрике, считайте pass rate по корзинам, а каждый прогон записывайте вместе с версиями промпта, модели, базы знаний и набора.

Тестирование чатбота — это конвейер, похожий на обычный автотест, но с двумя отличиями: вместо точного ассерта вердикт выносит судья, а результат прогона нужно привязать к версиям всего, что могло повлиять на ответ.

Увеличить

Ниже — типы кейсов, которые стоит иметь в наборе для любого чатбота. Примеры даны для ассистента интернет-магазина, база знаний которого описывает доставку, оплату и возврат.

Одиночный вопрос проверяет знание, а диалог проверяет поведение: умеет ли бот уточнить, запомнить и не запутаться. Идея сценарного теста в том, чтобы подводить разговор к нужной ситуации заранее записанными репликами и проверять реакцию бота на каждом шаге, а не только в конце.

1# evals/scenarios.py
2from dataclasses import dataclass
3
4
5@dataclass
6class Step:
7    user: str      # реплика пользователя
8    expect: str    # что должен сделать бот на этом шаге (для судьи)
9
10
11@dataclass
12class Scenario:
13    id: str
14    bucket: str    # корзина golden set
15    intent: str    # тема: возврат, доставка, оплата...
16    steps: list[Step]
17
18
19# База знаний примера: срок возврата 14 дней; при браке действуют условия гарантии.
20SCENARIOS = [
21    Scenario(
22        id="return-expired-then-defect",
23        bucket="edge_cases",
24        intent="возврат",
25        steps=[
26            Step("Хочу вернуть куртку",
27                 "Задаёт уточняющий вопрос о сроке покупки, не отказывает и не обещает возврат"),
28            Step("Купил 20 дней назад",
29                 "Сообщает, что 14-дневный срок истёк, и предлагает обратиться к менеджеру"),
30            Step("А если она с браком?",
31                 "Учитывает новый факт, объясняет, что для брака другие условия, предлагает заявку с фото"),
32        ],
33    ),
34]

1# evals/test_scenarios.py
2import pytest
3
4from evals.judge import judge_step   # судья видит всю историю и ожидание шага
5from evals.scenarios import SCENARIOS
6from myapp import chat               # chat(history: list[dict]) -> str
7
8
9def run(scenario):
10    history, verdicts = [], []
11    for step in scenario.steps:
12        history.append({"role": "user", "content": step.user})
13        answer = chat(history)
14        history.append({"role": "assistant", "content": answer})
15        verdicts.append(judge_step(history, step.expect))
16    return verdicts
17
18
19@pytest.mark.parametrize("scenario", SCENARIOS, ids=lambda s: s.id)
20def test_scenario(scenario):
21    verdicts = run(scenario)
22    failed = [
23        f"шаг {i}: {v['reasoning']}"
24        for i, v in enumerate(verdicts, start=1)
25        if v["verdict"] == "fail"
26    ]
27    assert not failed, "\n".join(failed)

Сценарный подход хорошо показывает, где именно диалог ломается: шаг за шагом видно, на какой реплике бот потерял контекст или дал обещание, которого нет в правилах. Оценка многоходовых диалогов судьёй — не выдумка автора статьи: на этом построен, например, бенчмарк MT-Bench, где модель оценивается на многоходовых вопросах [1].

Чтобы подвести бота к ситуации, а не дожидаться её в проде, придумывайте сценарии от конца: какая реакция бота опасна? Выдуманный срок возврата? Раскрытие внутренней инструкции? Обещание компенсации? Затем разложите диалог на шаги, при которых такая реакция становится вероятной, и запишите ожидаемое поведение на каждом.

Покрытие кода здесь не работает, но у набора кейсов тоже есть понятие покрытия: какие темы и типы ситуаций проверены. Удобная модель — матрица, где по строкам темы бота, а по столбцам корзины. Пустые ячейки — это непроверенные риски.

Правило простое: для критичных тем в каждой ячейке должен быть хотя бы один кейс, а для остальных достаточно типовых и «вне области». Матрицу не нужно рисовать руками: пустые ячейки находятся скриптом.

1# evals/coverage.py
2import json
3from collections import Counter
4
5INTENTS = ["возврат", "доставка", "оплата", "гарантия"]
6BUCKETS = ["happy_path", "edge_cases", "out_of_scope", "multi_turn", "adversarial"]
7
8with open("evals/golden_set.jsonl", encoding="utf-8") as f:
9    cases = [json.loads(line) for line in f]
10
11covered = Counter((c["intent"], c["bucket"]) for c in cases)
12holes = [(i, b) for i in INTENTS for b in BUCKETS if covered[(i, b)] == 0]
13
14print(f"Кейсов: {len(cases)}, пустых ячеек: {len(holes)} из {len(INTENTS) * len(BUCKETS)}")
15for intent, bucket in holes:
16    print(f"  нет кейсов: тема «{intent}», корзина {bucket}")

Результат прогона имеет смысл только вместе с версиями всего, что на него влияет. Иначе, когда качество изменится, вы не сможете сказать почему. В LLM-приложении таких «точек изменения» больше, чем в обычном.

Про псевдонимы моделей: поведение и правила зависят от провайдера, поэтому сверяйтесь с его документацией. Универсальный принцип от этого не меняется: считайте смену модели релизом и прогоняйте полную регрессию, даже если вы её не выбирали.

1{
2  "run_id": "2026-09-19T10:42:00Z-3f9c1a2",
3  "git_sha": "3f9c1a2",
4  "app": {
5    "system_prompt": "prompts/support.v14.md",
6    "model": "provider-model-2026-08-15",
7    "params": { "temperature": 0.2, "top_p": 0.9, "max_tokens": 600 }
8  },
9  "knowledge_base": { "index_version": "kb-2026-09-18", "chunk_size": 500, "top_k": 5 },
10  "golden_set": "v7",
11  "judge": { "prompt": "judge/groundedness.v3.txt", "model": "provider-model-2026-08-15" },
12  "pass_rate": { "happy_path": 0.94, "edge_cases": 0.81, "out_of_scope": 0.97, "adversarial": 0.95, "regressions": 1.0 }
13}

Имея такие записи, сравнение двух версий сводится к diff: какие кейсы были pass и стали fail. Если между запусками поменялась только версия модели, причина регрессии очевидна. Если поменялось всё сразу, найти её почти невозможно, поэтому меняйте по одной вещи за раз.

• Проверять только одиночные вопросы

  Многие дефекты, например потеря контекста, проявляются только в диалоге

• Оценивать только последнюю реплику диалога

  Ошибка на шаге 2 может не быть видна в конце. Проверяйте каждый шаг сценария

• Не знать, какие темы не покрыты

  Нет матрицы покрытия, поэтому пустые ячейки остаются рисками

• Использовать псевдоним модели вместо конкретной версии

  Качество меняется, а в записях ничего не менялось

• Менять несколько компонентов между прогонами

  Невозможно понять, что вызвало регрессию

Как тестировать многоходовые диалоги с LLM?

Опишите сценарий: реплики пользователя и ожидаемое поведение бота на каждом шаге. Прогоните диалог через приложение, а после каждой реплики попросите LLM-судью оценить ответ с учётом всей истории. Так видно, на каком шаге бот потерял контекст или дал ложное обещание.

Как измерить покрытие тестами для чатбота?

Постройте матрицу «тема × тип кейса» (типовые, неполные, вне области, диалоги, атаки) и посчитайте, в каких ячейках нет ни одного кейса. Для критичных тем пустых ячеек быть не должно. Эти данные легко получить скриптом из метаданных golden set.

Как версионировать модель и промпт в LLM-приложении?

Храните системный промпт в git, фиксируйте конкретную версию модели вместо псевдонима, а параметры генерации, версию базы знаний, набора кейсов и судьи записывайте в каждый прогон. Тогда результаты разных прогонов можно сравнивать и находить причину регрессии.

Сколько кейсов должно быть в golden set чатбота?

Начните с 30–50 продуманных кейсов, разложенных по корзинам, и растите набор при каждой найденной ошибке. Важнее разнообразие и покрытие критичных тем, чем общее число.