Держите LLM подальше от тестов чат-бота

Держите LLM подальше от тестов чат-бота

Кто тестировал чат-бота, знает: на одной реплике всё просто, а на третьей-четвёртой начинается боль. Бот должен помнить имя, которое вы назвали два хода назад, держать слоты и не сваливаться в «уточните ваш запрос» на ровном месте. И как только садишься это проверять, упираешься в развилку: чем, собственно, проверять ответы многоходового диалога.

Если коротко

• LLM, которая оценивает ответы вашего бота, — это вторая недетерминированная система. Теперь перед зелёным CI должны договориться сразу две, и договариваются они не всегда.

• Большая часть того, что вы реально хотите проверить в диалоге, скучна и проверяема: спросил ли бот город после того, как получил имя, удержал ли слот, вернул ли правильный ответ на третьей реплике.

• pytest-conversational даёт маленький объект Conversation, адаптер бота, который вы пишете сами, и pytest-фикстуры, которые держат порядок реплик и состояние по ходу диалога. На стороне теста никакой модели.

• Это alpha. Одиночные и многоходовые проверки работают уже сейчас; YAML-формат сценариев и async-адаптеры пока в планах, не в коробке.

Два способа тестировать ботов, и почему оба болят

Когда вы садитесь тестировать диалоговый интерфейс, обычно оказываетесь в одном из двух лагерей.

Первый лагерь — куча вызовов requests.post. Кидаете боту сообщение, читаете JSON, пишете проверку. Для одной реплики работает. К четвёртой реплике вы уже руками собираете payload с историей, протаскиваете состояние через локальные переменные и копируете один и тот же setup в каждый тест. Когда что-то ломается, сообщение об ошибке говорит, что один dict не равен другому dict, и вы идёте раскапывать, на какой реплике всё пошло не так.

Второй лагерь — полноценный фреймворк для тестирования диалогов, который забирает себе всю обвязку. Он умеет многоходовые сценарии, но привязывает вас к одной платформе и одному способу описывать бота. В день, когда бот переезжает за другой транспорт или вы хотите протестировать обычную Python-функцию, а не HTTP-сервис, вы начинаете бороться с фреймворком.

Есть и третий вариант, который всплывает снова и снова, и именно с ним я хочу поспорить: пусть языковая модель прочитает ответ бота и решит, хорош он или нет. Выглядит заманчиво, потому что модель прощает перефразирование. Бот сказал «конечно, какой город?» вместо «понял, какой город?», а проверяющая модель пожимает плечами и засчитывает ответ.

А теперь посмотрите, что получилось. В вашем наборе тестов теперь две недетерминированные системы, и CI зеленеет только когда обе согласны. Тестируемая модель плывёт, когда вы меняете промпт. Модель-судья плывёт, когда провайдер выкатывает новую версию. Тест, прошедший в понедельник, падает в четверг, хотя в коде вы ничего не трогали. Плюс вы платите задержкой и токенами на каждом прогоне и отдаёте единственное, ради чего тест и нужен: чёткое повторяемое «да» или «нет».

Коллега, который ведёт инженерную часть на платформе чат-ботов, хорошо это сформулировал, когда мы обсуждали тему онлайн. Держите сторону теста детерминированной. Пусть бот будет сколь угодно умным; то, что его проверяет, должно быть тупым и предсказуемым.

Разворот: сделать сторону теста скучной нарочно

Большая часть того, что вас волнует в диалоге, — это не «красиво ли сформулирован ответ». Это структура:

• После того как пользователь назвал имя, спрашивает ли бот следующий слот?

• Помнит ли бот имя три реплики спустя?

• На сообщении вне сценария он откатывается к fallback или выдумывает ответ?

• Содержит ли ответ номер заказа, попадает ли в известный паттерн или в известный набор вариантов?

Всё это проверяется без модели. Нужно что-то, что держит порядок реплик, хранит состояние диалога и печатает читаемый транскрипт, когда проверка падает. Это и есть вся работа, которую пытается делать pytest-conversational, и ничего сверх того.

Бота приносите вы. Плагин подключает его к pytest.

Как это выглядит

Установка:

pip install pytest-conversational

Python 3.10 и выше.

Бот — это любой callable, который принимает текст пользователя и диалог, а возвращает строку. Простейший тест:

def my_bot(text, convo):
    if "hello" in text.lower():
        return "hi"
    return "sorry, did not get that"

def test_greeting(conversation_factory):
    convo = conversation_factory(bot=my_bot)
    convo.say("hello there")
    assert convo.last.bot == "hi"

conversation_factory — это фикстура. Передаёте ей бота, получаете свежий Conversation, изолированный от всех остальных тестов.

Многоходовое состояние без глобалов

Вот где страдает лагерь одиночных реплик. Адаптер бота может читать convo.state и convo.turns, поэтому заполнение слотов остаётся внутри диалога, а не протекает в тело теста:

def slot_filling_bot(text, convo):
    slots = convo.state.setdefault("slots", {})
    if "name" not in slots:
        slots["name"] = text
        return "got it, what city?"
    if "city" not in slots:
        slots["city"] = text
        return f"hello {slots['name']} from {slots['city']}"
    return "done"

def test_two_slot_flow(conversation_factory):
    convo = conversation_factory(bot=slot_filling_bot)
    convo.say("Mikhail")
    convo.say("Hove")
    assert convo.state["slots"] == {"name": "Mikhail", "city": "Hove"}
    assert convo.last.bot == "hello Mikhail from Hove"

Тест читается сверху вниз как диалог, который он описывает. Когда он падает, вы зовёте convo.transcript() и видите каждую реплику, а не diff двух словарей.

Многоходовый тест ловит бота, который теряет имя на последней реплике. Сообщение об ошибке показывает ровно то, что бот сказал, против того, что ожидал тест. (вставить GIF из Dev.to-версии)

Матчеры для нечётких мест

Точное равенство строк хорошо работает, пока не перестаёт. Некоторые ответы законно варьируются, и вы хотите проверять форму, а не буквальный текст. Модуль expect закрывает частые случаи и кладёт фактический ответ в сообщение об ошибке, чтобы в выводе pytest было видно, что бот сказал против того, что вы хотели:

from pytest_conversational import expect

def test_replies(conversation_factory):
    convo = conversation_factory(bot=my_bot)
    convo.say("hi")

    expect.contains(convo.last.bot, "hello")
    expect.regex(convo.last.bot, r"^hello\s+\w+")
    expect.one_of(convo.last.bot, ["hello there", "hi there", "hey"])

contains по умолчанию делает регистронезависимую проверку вхождения подстроки. regex запускает re.search и отдаёт объект совпадения, чтобы вы могли заглянуть в захваченные группы. one_of сверяет ответ со списком альтернатив, с точным режимом и режимом подстроки. Ничему из этого не нужна модель, чтобы что-то решать. Правила ваши, и они не плывут.

Бот, который живёт за HTTP

Если ваш бот — развёрнутый сервис, писать транспорт руками не нужно. Есть встроенный webhook-адаптер:

pip install pytest-conversational

from pytest_conversational import Conversation
from pytest_conversational.adapters import http_webhook

def test_remote_bot():
    bot = http_webhook("https://my-bot.example.com/webhook", timeout=3.0)
    convo = Conversation(bot=bot)
    convo.say("hello")
    assert "hi" in convo.last.bot.lower()

Контракт по умолчанию: POST с {"user": text, "history": [[u, b], ...]} и 200 с {"reply": "..."}. Если эндпоинт говорит на другой форме, передайте колбэки request_builder и response_parser.

На одном моменте стоит притормозить. URL вебхука уходит в httpx ровно так, как написан. Если в тест когда-нибудь попадёт URL из данных фикстуры, конфига или откуда угодно, что вы не вписали руками сами, адаптер послушно по нему постучится. Сюда входит 127.0.0.1, облачный адрес метаданных 169.254.169.254 и всё на 10.x.x.x внутри вашей сети. Тест, дотянувшийся до эндпоинта метаданных, — не гипотетика; именно так начинается изрядная доля SSRF-инцидентов. Прибейте URL к литералу в тесте или прогоните его через свой allowlist, прежде чем он окажется рядом с адаптером.

Где это уместно, а где нет

Детерминизм на стороне теста — правильный выбор для структуры, состояния, маршрутизации и fallback-ов. Это основная часть того, что ломается в диалоговом продукте, и ровно та часть, с которой модель-судья справляется хуже всего.

Это не инструмент для оценки качества свободной генерации. Если ваш настоящий вопрос — «это хороший, полезный, в тоне бренда абзац», правило на него не ответит, и притворяться не надо. Для этого есть ревью человеком или отдельная оценочная обвязка, и держите её подальше от ворот, которые решают, сломана сборка или нет. Это две разные задачи. Их смешивание — путь к флакающему CI, которому никто не верит.

Честный статус: плагин в alpha, уже опубликован на PyPI (текущая версия 0.4.0), релиз 1.0 в планах. Одиночные и многоходовые проверки, матчеры и HTTP-адаптер работают сейчас. Формат сценариев, который можно грузить из YAML или текстовых фикстур, в планах, как и поддержка async-адаптеров для корутинных ботов. Этого пока нет в коробке, и я лучше скажу прямо, чем дам вам сделать pip install и пойти их искать.

Попробовать

pip install pytest-conversational

Наведите его на бота, который у вас уже есть, напишите один многоходовый тест и посмотрите, скажет ли транскрипт падения больше, чем ваша текущая обвязка. Код, issues и роадмап на GitHub: https://github.com/golikovichev/pytest-conversational

Если попробуете, самые полезные issue — это проверки, которых вам не хватило. Именно они формируют формат сценариев до версии 1.0.