Финальная сборка: проверка и экспорт workflow
Содержание курса
В предыдущем уроке классификатор научился разбирать текст заявки и направлять её в нужную ветку по смыслу. Теперь всё собрано вместе: нормализация, валидация, классификация, сохранение. Единственный способ убедиться, что цепочка работает как единое целое, а не по частям, — прогнать её на заявках, которые намеренно покрывают каждую из веток.
Четыре типа тестовых заявок и что каждая проверяет
Случайный запуск одной тестовой заявки не даёт никаких гарантий: он проверяет только один путь прохождения данных. Итоговый workflow содержит несколько развилок — узел IF проверяет наличие обязательного поля, Text Classifier разделяет поток на категории, Stop and Error обрывает невалидные заявки. Чтобы убедиться, что каждая из этих веток настроена правильно, нужно осознанно подобрать входные данные под каждый сценарий.
Четыре типа заявок — это не произвольный список, а минимальный набор, при котором каждая ветка цепочки получает хотя бы один прогон.
Обычная заявка — содержит все обязательные поля с корректными значениями, тема не требует срочной обработки. Такая заявка должна пройти нормализацию, успешно пройти валидацию, получить категорию от классификатора и попасть в Data Table. Это базовый «зелёный» путь.
Горячая заявка — тоже валидная, но с текстом, который классификатор должен отнести к приоритетной категории (например, «сервер недоступен уже два часа, клиенты не могут войти»). Проверяет, что ветка «горячих» заявок действительно отделяется от обычных и данные уходят в нужный выход Text Classifier.
Нецелевая заявка — валидная по форме, но тема не входит ни в одну из настроенных категорий (например, запрос о скидке при поддержке по технической части). Проверяет, что классификатор корректно обрабатывает случай «ни одна категория не подошла» и не ломается, а маршрутизирует в ветку по умолчанию или явно помечает заявку.
Некорректная заявка — намеренно содержит пустое или отсутствующее обязательное поле. Проверяет, что узел IF на этапе валидации ловит проблему и передаёт управление в Stop and Error, а не пропускает данные дальше с пустым значением.
Каждый из этих четырёх кейсов нацелен на конкретную развилку. Если пропустить хотя бы один, остаётся непроверенная ветка: она может содержать ошибку в условии, опечатку в имени поля или неподключённый выход — и это выяснится только в продакшене, когда придёт реальная заявка именно этого типа.