Диалоги для чат бота готовят как проверяемый набор многошаговых сценариев: каждому разговору задают цель клиента, контекст, ожидаемое уточнение, допустимый ответ и условие передачи человеку. Такой набор нужен для приёмки после изменения логики или модели. Материал о промптах для ботов описывает правила поведения бота; здесь проверяют фактический ход разговора на сохранённых тестовых заданиях. Все примеры ниже служат проектной схемой будущего пилота с учебными данными.
Корпус диалогов
Единица проверки — сценарий с входными репликами, контекстом, ожидаемыми событиями и критерием приёмки. Качество диалога проверяют по продолжению разговора после первого ответа.
Начните с задач клиентского бота, которые владелец процесса готов принимать: уточнить запрос, найти основание ответа, передать сложный случай оператору или завершить простое обращение. Для каждой задачи составьте учебный диалог и отметьте, какой факт клиент сообщил, какие сведения нужны и какое действие допустимо. Ожидания выводят из утверждённых правил компании. В реальных переписках могут быть личные данные; разрешение на использование, удаление лишних сведений и состав тестового набора утверждают владельцы данных.
| Поле сценария | Что зафиксировать | Как проверить |
|---|---|---|
| Намерение | Цель клиента и допустимая категория | Сверить маршрут |
| Контекст | Факты из предыдущих реплик | Проверить сохранение смысла |
| Поворот | Уточнение, смена темы или отказ | Сверить реакцию бота |
| Эталон | Событие, источник ответа, передача человеку | Принять итог |
Корпус храните с версиями: идентификатор сценария, редакция правил, набор реплик и эталон. Удобно держать отдельно текст клиента и ожидаемые события, потому что допустимые формулировки ответа могут различаться. Название сценария должно объяснять проверяемый риск, например потерю контекста при смене темы. При исправлении бота прежний набор остаётся доступным для регрессионной проверки. Скрипт валидирует структуру и полноту записей по всему набору, редактор сверяет язык реплик с реальной задачей.
Общий маршрут работы бота описан в разборе алгоритма чат-бота. Тестовый корпус выделяет другую ответственность: доказать, что заявленный маршрут выдерживает конкретные повороты разговора и сохраняет правильный исход.
Повороты разговора
Разговор редко следует прямой линии. Клиент начинает с общего вопроса, добавляет условие, поправляет прежний ответ, перескакивает к другой теме или просит оператора. В тестовом наборе каждому повороту соответствует отдельный ожидаемый переход. Бот должен использовать уже сообщённые факты только в рамках разрешённого контекста и задавать уточнение, когда сведений недостаточно. Если вопрос относится к закрытому источнику, правильным исходом может быть отказ или передача сотруднику.
Полезен сценарий с исправлением клиента: сначала указан один адрес доставки, затем он заменён другим. Эталон фиксирует актуальное значение и запрещает действия по устаревшему. Для смены темы проверьте, сохранил ли бот исходное поручение в нужном статусе и открыл ли новое. Для эскалации запишите, какая краткая сводка видна оператору и что остаётся в исходной системе. Точные права на передачу переписки определяют сервер и владелец данных.
- Запишите исходное намерение клиента и факты, доступные боту на старте.
- Добавьте уточнение, которое меняет либо дополняет прежнее условие.
- Вставьте смену темы, отказ или запрос на связь с сотрудником.
- Опишите ожидаемое событие после каждого поворота и допустимый финальный ответ.
Если бот получает изображение, скан или файл, тестируйте границы отдельно. OCR даёт сигнал о прочитанном тексте, качество распознавания проверяет человек. Владелец прав решает, можно ли включать вложение в корпус. Скрипт сверяет извлечённые поля и полные таблицы, модель помогает объяснить исключение, оператор проверяет источник. Для теста пригодны учебные документы с явным ожидаемым фактом; таким способом видно, где ошибка связана с чтением, а где с логикой диалога.
Эталон и ошибки
Эталон лучше задавать через наблюдаемое поведение: нужный вопрос, сохранённый факт, разрешённый источник, вызванный маршрут или передача человеку. Точное совпадение всех слов ответа полезно для фиксированных фраз, а свободный текст оценивают по смыслу и основанию. Один сценарий может содержать несколько допустимых формулировок, но переход к оператору или запись в системе проверяют отдельно. Такая разметка даёт инженеру конкретное расхождение, а владельцу процесса — понятную причину отказа в приёмке.
Официальная документация Rasa описывает скриптовые сквозные тесты диалогов, проверки реплик, событий и состояния, а также возможность подменять внешние действия при тестировании. Это подтверждённая функция конкретной платформы. Общий формат корпуса для компании остаётся проектным выбором: другой стек потребует своего запускающего кода и проверок, сохраняя те же бизнес-критерии.
Фиксируйте отдельно неверный факт, потерю контекста, пропущенное уточнение, ошибочную эскалацию и лишнее действие. Модель может объяснить возможную причину, скрипт покажет расхождение, человек подтвердит классификацию ошибки.
Для каждого сбоя сохраняйте диалог, редакцию сценария, версию бота и факт в целевой системе. Счётчик успешно пройденных сценариев без списка ошибок скрывает важные риски. Вопрос о статусе заказа и просьба изменить заказ требуют разных проверок: первый оценивают по источнику, вторую дополнительно по правам и подтверждению. Сервер проверяет допуск к действию, а текст промпта задаёт только поведение. При спорной оценке владелец процесса перечитывает исходные реплики и утверждает эталонную формулировку.
Хороший эталон допускает честное «нет данных» и передачу оператору. Принудительное ожидание уверенного ответа подталкивает тест к выдуманному факту. Разметка отражает интерес клиента и реальные полномочия бота.
Регрессия и передача
После изменения промпта, сценария, базы знаний или модели запускайте сохранённый набор заново. Скрипт сравнивает ожидаемые события с фактическими, отмечает новые расхождения и формирует сводку по категориям ошибок. Свободные ответы проверяет человек на выборке спорных случаев и на сценариях с высоким риском. Так команда видит, какое исправление помогло одному диалогу и где оно нарушило другой. Список тестов расширяют при обнаружении нового вида поворота разговора.
Для передачи оператору нужен отдельный эталон: бот сообщает клиенту о следующем шаге, сохраняет контекст и передаёт сотруднику разрешённую сводку. Тест проверяет факт маршрута и содержание сводки без публикации лишних данных. В материале о консультационном боте раскрыт сам рабочий сценарий; здесь важна его повторяемая проверка после каждой правки. Если оператор отверг сводку, причина возвращается в корпус как новый пример.
- Закрепите версию корпуса и ожидаемые события перед изменением бота.
- Запустите сценарии в тестовом контуре с заглушками для внешних действий.
- Сравните события скриптом, а спорные ответы отдайте владельцу процесса.
- Добавьте подтверждённый новый случай в корпус и повторите проверку.
Автоматический прогон удобен для регрессии, но приёмка остаётся решением человека. Особенно внимательно смотрите на неверное действие с верным по форме ответом: клиент слышит подходящую фразу, а сервер получил лишний вызов. Журнал инструмента и состояние тестовой системы должны совпадать с эталоном. Для внешней записи используйте отдельное подтверждение и проверку серверных прав.
Если команда хочет связать корпус с процессом поддержки, можно обсудить разработку чат-бота для бизнеса с конкретными критериями приёмки.
Нужен корпус диалогов для проверки вашего бота?
Пилот и стоимость
Будущий пилот предложите на учебном наборе обращений с разрешёнными данными. Владелец поддержки выбирает намерения и типовые повороты, редактор формулирует реплики, инженер готовит запуск и журнал. До старта согласуйте, какие ответы допускают разную формулировку и какие события требуют точного совпадения. Для проверки отказа добавьте вопрос без основания в базе. Для эскалации добавьте случай, который должен перейти оператору. Это проектная схема проверки, без проведённого клиентского кейса.
Приёмка требует связи каждого проваленного сценария с его репликами, эталоном и фактическим событием. Скрипт сверяет полный набор по формальным правилам. Модель предлагает объяснение сложной ошибки и варианты новых тестов. Специалист подтверждает смысл ответа, права на данные и корректность передачи человеку. Обновление бота принимают после повторного прогона согласованного набора и проверки новых исключений. Такой порядок помогает отличить улучшение поведения от случайного удачного ответа.
Стоимость подготовки корпуса зависит от числа намерений, длины диалогов, требований к данным и набора внешних действий. Состав работ обсуждают после списка клиентских задач и критичных ошибок, без универсального тарифа. Для начала соберите разрешённые учебные реплики и карту маршрутов, затем назначьте владельца эталона. Выбор платформы и написание промпта можно вести параллельно с подготовкой проверок, сохраняя единый источник критериев для команды.
Корпус нуждается в сопровождении: новая политика ответа, свежий документ или изменившийся маршрут оператора меняют эталон. Владелец процесса утверждает новую редакцию, инженер сохраняет прежнюю для сравнения. Реальные переписки подключают только после решения о правах и обработке личных данных. Учебные сценарии позволяют сначала проверить механику без чужой переписки и без отправки действий в рабочие системы.
Выберите разрешённый диалог с уточнением и случай передачи оператору. Запишите ожидаемые события и источник ответа, затем проверьте их в тестовом контуре.