Статья
Как составить тестовые диалоги для ИИ-администратора
Набор проверок должен включать не только идеальные вопросы, но и опечатки, смену темы, риски и сбои интеграций.
Сначала определите проверяемый результат
Оценка «ответ звучит нормально» зависит от вкуса и пропускает опасные ошибки. Для каждого теста запишите входные условия и ожидаемое поведение: найден правильный факт, задано обязательное уточнение, цена не обещана без расчёта, действие подтверждено системой, при риске создана передача. Не требуйте дословного совпадения фразы, если важен смысл. Отдельно отметьте недопустимые исходы. Тогда повторный прогон после обновления модели или базы показывает изменение поведения, а не настроение проверяющего.
Соберите набор из разных классов
- Точный запросПрямой вопрос, на который есть один актуальный ответ в утверждённом источнике.
- НеоднозначностьКороткая фраза, пропущенный параметр, опечатка или несколько возможных услуг.
- КонтекстСмена темы, исправление данных, отрицание и возврат к предыдущему выбору.
- ГраницаПросьба дать запрещённый совет, выдумать скидку или раскрыть чужую информацию.
- СбойНедоступное расписание, повторная отправка, таймаут и передача вне рабочего времени.
Берите формулировки из реальных обращений
Обезличьте переписки и сохраните характерные сокращения, разговорные названия и неполные предложения. Добавьте пары, которые отличаются одной важной деталью: фиксированная услуга и индивидуальный заказ, новый клиент и действующий, свободный слот и уже занятый. Включите попытки изменить исходные данные посреди диалога. Не ограничивайтесь happy path: человек может отправить два сообщения подряд, вернуться через день или отказаться сообщать необязательную информацию. Тест должен проверять, сохраняет ли система ровно необходимый контекст. Полезно привлечь администратора, который ежедневно читает обращения: он быстрее разработчика замечает неестественные уточнения и пропущенные исключения.
Пример: тест записи в салон
Базовый сценарий звучал так: «Хочу стрижку завтра вечером». Ожидалось уточнение специалиста и показ доступных слотов. Затем команда добавила варианты: «как обычно, но на час позже», сообщение с опечаткой в имени мастера, просьбу записать ребёнка, отмену после подтверждения и вопрос о реакции на состав средства. В последнем случае система не давала медицинской оценки и передавала вопрос администратору. При отключённом календаре она не называла выдуманное время, а собирала контакт. Для каждого прогона проверяли выбранную услугу, подтверждение времени, отсутствие лишних данных и содержание карточки передачи.
Превратите примеры в регрессионную проверку
Храните тесту идентификатор, тему, входные сообщения, нужное состояние систем, критерии и владельца решения. После изменения знаний запускайте связанные группы, а не только новый пример. Ошибки делите на фактические, сценарные, интеграционные и стилистические; сначала исправляйте те, что создают неверные обязательства или теряют обращение. Спорные результаты рассматривает владелец процесса. Дополняйте набор реальными сбоями после запуска, но не переписывайте ожидание ради удобства текущего ответа. Версия тестов должна соответствовать версии правил бизнеса. Для нестабильных формулировок делайте несколько прогонов и оценивайте обязательные признаки ответа. Храните примеры без реальных телефонов, фамилий и платёжных данных. Тестовая среда не должна превращаться в ещё одно неуправляемое хранилище клиентской информации.
Частые вопросы
Сколько диалогов достаточно?
Универсального числа нет. Покройте каждое важное правило, границу и интеграцию хотя бы базовым и неудобным вариантом.
Кто оценивает ответы?
Факты и правила подтверждает владелец процесса; разработчик проверяет сценарий и технический результат.
Нужно ли тестировать стиль?
Да, после точности и безопасности. Проверяйте ясность, отсутствие давления и понятный следующий шаг.